Einstellung von Device Admin Ab Android 9 (API-Ebene 28) werden einige Administratorrichtlinien als eingestellt gekennzeichnet, wenn sie von einem Geräteadministrator aufgerufen werden. Wir empfehlen Ihnen, sich jetzt auf diese Änderung vorzubereiten. Weitere Informationen und Migrationsoptionen finden Sie unter Einstellung der Geräteverwaltung.
Android bietet mit der Android Device Administration API Unterstützung für Unternehmens-Apps. Die Device Administration API bietet Funktionen zur Geräteverwaltung auf Systemebene. Mit diesen APIs können Sie sicherheitsbewusste Apps erstellen, die in Unternehmensumgebungen nützlich sind, in denen IT-Experten umfassende Kontrolle über die Geräte der Mitarbeiter benötigen. So wurden diese APIs beispielsweise in der integrierten Android-E-Mail-App verwendet, um die Exchange-Unterstützung zu verbessern. Über die E-Mail-App können Exchange-Administratoren Passwortrichtlinien – einschließlich alphanumerischer Passwörter oder numerischer PINs – geräteübergreifend erzwingen. Administratoren können verlorene oder gestohlene Smartphones auch aus der Ferne löschen, d. h. auf die Werkseinstellungen zurücksetzen. Exchange-Nutzer können ihre E-Mail- und Kalenderdaten synchronisieren.
Dieses Dokument richtet sich an Entwickler, die Unternehmenslösungen für Android-Geräte entwickeln möchten. Darin werden die verschiedenen Funktionen der Device Administration API beschrieben, die für eine bessere Sicherheit von Android-Geräten von Mitarbeitern sorgen.
Hinweis: Informationen zum Erstellen eines Work Policy Controllers für Android for Work-Bereitstellungen finden Sie unter Device Policy Controller erstellen.
Modus „Geräteeigentümer“ (ohne Monitor)
Mit Android 14 (API-Level 34) wird der Headless System User-Modus eingeführt. Auf Geräten, auf denen UserManager.isHeadlessSystemUserMode true zurückgibt, ist der Systemnutzer ein Nutzer im Hintergrund und benötigt zusätzliche Nutzer im Vordergrund für die Interaktion mit Endnutzern. Mit Android 14 wird außerdem ein modus für den Geräteeigentümer ohne Kopf eingeführt, bei dem allen mit dem Gerät verknüpften Nutzern, mit Ausnahme des Systemnutzers, für den der Geräteeigentümer festgelegt ist, ein Profilinhaber hinzugefügt wird.
Auf Geräten, die mit einem headless Systemnutzer konfiguriert sind (d. h. der Systemnutzer wird im Hintergrund ausgeführt), werden nur globale Geräterichtlinien (Richtlinien, die für alle Nutzer gelten) auf den oder die Nutzer im Vordergrund angewendet. Weitere Informationen finden Sie unter addUserRestriction.
Hersteller von Android-Geräten können sich an die Anleitung auf source.android.com halten.
Device Administration API – Übersicht
Hier sind Beispiele für die Arten von Apps, die die Device Administration API verwenden können:
- E-Mail-Clients
- Sicherheits-Apps, die Daten aus der Ferne löschen
- Geräteverwaltungsdienste und ‑Apps
Wie funktioniert das?
Mit der Device Administration API können Sie Geräteverwaltungs-Apps erstellen, die Nutzer auf ihren Geräten installieren. Die Device Admin App erzwingt die gewünschten Richtlinien. Das funktioniert so:
- Ein Systemadministrator schreibt eine App für die Geräteverwaltung, die Sicherheitsrichtlinien für Remote-/lokale Geräte erzwingt. Diese Richtlinien können in die App hartcodiert sein oder die App kann Richtlinien dynamisch von einem Drittanbieterserver abrufen.
- Die App ist auf den Geräten der Nutzer installiert. Android bietet derzeit keine automatisierte Bereitstellungslösung. Ein Systemadministrator kann die App auf folgende Arten an Nutzer verteilen:
- Mit Google Play.
- Installation aus einem anderen Store aktivieren
- Die App über andere Kanäle wie E-Mails oder Websites vertreiben.
- Das System fordert den Nutzer auf, die App zur Geräteverwaltung zu aktivieren. Wie und wann dies geschieht, hängt davon ab, wie die App implementiert ist.
- Sobald Nutzer die Geräteverwaltungs-App aktiviert haben, unterliegen sie ihren Richtlinien. Die Einhaltung dieser Richtlinien bietet in der Regel Vorteile, z. B. Zugriff auf sensible Systeme und Daten.
Wenn Nutzer die App für die Geräteverwaltung nicht aktivieren, bleibt sie auf dem Gerät, ist aber inaktiv. Für Nutzer gelten dann nicht die Richtlinien von Google und sie können auch keine Vorteile der App nutzen. So können sie beispielsweise keine Daten synchronisieren.
Wenn ein Nutzer die Richtlinien nicht einhält (z. B. ein Passwort festlegt, das gegen die Richtlinien verstößt), liegt es in der Entscheidung der App, wie damit umgegangen wird. In der Regel kann der Nutzer dann jedoch keine Daten mehr synchronisieren.
Wenn ein Gerät versucht, eine Verbindung zu einem Server herzustellen, für den Richtlinien erforderlich sind, die in der Device Administration API nicht unterstützt werden, wird die Verbindung nicht zugelassen. Die Device Administration API ermöglicht derzeit keine teilweise Bereitstellung. Wenn ein Gerät (z. B. ein älteres Gerät) also nicht alle angegebenen Richtlinien unterstützt, kann es keine Verbindung herstellen.
Wenn ein Gerät mehrere aktivierte Administrator-Apps enthält, wird die strengste Richtlinie erzwungen. Es gibt keine Möglichkeit, Anzeigen auf eine bestimmte Administrator-App auszurichten.
Wenn Nutzer eine vorhandene App zur Geräteverwaltung deinstallieren möchten, müssen sie die App zuerst als Administrator abmelden.
Richtlinien
In Unternehmen müssen Mitarbeitergeräte häufig strengen Richtlinien zur Nutzung des Geräts entsprechen. Die Device Administration API unterstützt die in Tabelle 1 aufgeführten Richtlinien. Die Device Administration API unterstützt derzeit nur Passwörter für die Displaysperre:
Tabelle 1 Von der Device Administration API unterstützte Richtlinien
| Richtlinie | Beschreibung |
|---|---|
| Passwort aktiviert | Erfordert, dass auf Geräten PINs oder Passwörter abgefragt werden. |
| Mindestlänge des Passworts | Legen Sie die erforderliche Anzahl von Zeichen für das Passwort fest. Sie können beispielsweise festlegen, dass PINs oder Passwörter mindestens sechs Zeichen lang sein müssen. |
| Alphanumerisches Passwort erforderlich | Passwörter müssen eine Kombination aus Buchstaben und Zahlen enthalten. Sie können auch Symbole enthalten. |
| Komplexes Passwort erforderlich | Passwörter müssen mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen enthalten. Einführung in Android 3.0. |
| Mindestanzahl der Buchstaben im Passwort | Die Mindestanzahl von Buchstaben, die das Passwort für alle Administratoren oder einen bestimmten Administrator enthalten muss. Einführung in Android 3.0. |
| Mindestanzahl der Kleinbuchstaben im Passwort | Die Mindestanzahl an Kleinbuchstaben, die für alle Administratoren oder einen bestimmten Administrator im Passwort erforderlich sind. Einführung in Android 3.0. |
| Mindestanzahl der Zeichen im Passwort, die keine Buchstaben sind | Die Mindestanzahl an Zeichen, die im Passwort für alle Administratoren oder einen bestimmten Administrator enthalten sein müssen. Einführung in Android 3.0. |
| Mindestanzahl der Ziffern im Passwort | Die Mindestanzahl von Ziffern, die das Passwort für alle Administratoren oder einen bestimmten Administrator enthalten muss. Einführung in Android 3.0. |
| Mindestanzahl an Symbolen im Passwort | Die Mindestanzahl von Symbolen, die das Passwort für alle Administratoren oder einen bestimmten Administrator enthalten muss. Einführung in Android 3.0. |
| Mindestanzahl der Großbuchstaben im Passwort | Die Mindestanzahl von Großbuchstaben, die im Passwort für alle Administratoren oder einen bestimmten Administrator erforderlich sind. Einführung in Android 3.0. |
| Zeitlimit für Ablauf des Passworts | Das Ablaufdatum des Passworts, ausgedrückt als Delta in Millisekunden ab dem Zeitpunkt, zu dem ein Geräteadministrator die Zeitüberschreitung für das Ablaufdatum festgelegt hat. Einführung in Android 3.0. |
| Einschränkung des Passwortverlaufs | Diese Richtlinie verhindert, dass Nutzer die letzten n eindeutigen Passwörter wiederverwenden.
Diese Richtlinie wird in der Regel in Verbindung mit setPasswordExpirationTimeout() verwendet, wodurch Nutzer gezwungen werden, ihre Passwörter nach Ablauf eines bestimmten Zeitraums zu aktualisieren.
Einführung in Android 3.0. |
| Maximale Anzahl fehlgeschlagener Passworteingaben | Gibt an, wie oft ein Nutzer ein falsches Passwort eingeben kann, bevor die Daten auf dem Gerät gelöscht werden. Mit der Device Administration API können Administratoren das Gerät auch aus der Ferne auf die Werkseinstellungen zurücksetzen. So werden Daten geschützt, falls das Gerät verloren geht oder gestohlen wird. |
| Maximales Zeitlimit für Inaktivität | Hiermit wird festgelegt, wie lange es dauert, bis das Gerät den Bildschirm sperrt, nachdem der Nutzer zuletzt den Bildschirm berührt oder eine Taste gedrückt hat. In diesem Fall müssen Nutzer ihre PIN oder Passwörter noch einmal eingeben, bevor sie ihre Geräte verwenden und auf Daten zugreifen können. Der Wert kann zwischen 1 und 60 Minuten liegen. |
| Speicherverschlüsselung erzwingen | Gibt an, dass der Speicherbereich verschlüsselt werden soll, sofern das Gerät dies unterstützt. Einführung in Android 3.0. |
| Kamera deaktivieren | Gibt an, dass die Kamera deaktiviert werden soll. Die Deaktivierung muss nicht dauerhaft sein. Die Kamera kann dynamisch aktiviert oder deaktiviert werden, je nach Kontext, Uhrzeit usw. Einführung in Android 4.0. |
Weitere Funktionen
Zusätzlich zu den in der Tabelle oben aufgeführten Richtlinien können Sie mit der Device Administration API Folgendes tun:
- Nutzer auffordern, ein neues Passwort festzulegen.
- Gerät sofort sperren
- Löschen Sie die Daten auf dem Gerät, d. h. setzen Sie es auf die Werkseinstellungen zurück.
Beispiel-App
Die auf dieser Seite verwendeten Beispiele basieren auf dem Beispiel für die Device Administration API, das in den SDK-Beispielen enthalten ist (über den Android SDK Manager verfügbar) und sich auf Ihrem System als <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java befindet.
Die Beispiel-App bietet eine Demo der Funktionen für die Geräteverwaltung. Sie bietet Nutzern eine Benutzeroberfläche, über die sie die Geräteverwaltungs-App aktivieren können. Nachdem sie die App aktiviert haben, können sie über die Schaltflächen auf der Benutzeroberfläche Folgendes tun:
- Legen Sie die Passwortqualität fest.
- Geben Sie Anforderungen für das Passwort des Nutzers an, z. B. die Mindestlänge und die Mindestanzahl an Ziffern.
- Legen Sie das Passwort fest. Wenn das Passwort nicht den angegebenen Richtlinien entspricht, gibt das System einen Fehler zurück.
- Legen Sie fest, wie viele falsche Passworteingaben zulässig sind, bevor das Gerät gelöscht (d. h. auf die Werkseinstellungen zurückgesetzt) wird.
- Legen Sie fest, wann das Passwort ablaufen soll.
- Legen Sie die Länge des Passwortverlaufs fest. length bezieht sich auf die Anzahl der alten Passwörter, die im Verlauf gespeichert sind. So wird verhindert, dass Nutzer eines der letzten n zuvor verwendeten Passwörter wiederverwenden.
- Geben Sie an, dass der Speicherbereich verschlüsselt werden soll, sofern das Gerät dies unterstützt.
- Legen Sie fest, wie lange das Gerät maximal inaktiv sein darf, bevor es gesperrt wird.
- Das Gerät wird sofort gesperrt.
- Löschen Sie die Daten auf dem Gerät, d. h. setzen Sie es auf die Werkseinstellungen zurück.
- Deaktivieren Sie die Kamera.
Abbildung 1. Screenshot der Beispiel-App
App zur Geräteverwaltung entwickeln
Systemadministratoren können mit der Device Administration API eine App erstellen, die die Durchsetzung von Sicherheitsrichtlinien für Remote-/lokale Geräte erzwingt. In diesem Abschnitt werden die Schritte zum Erstellen einer App zur Geräteverwaltung zusammengefasst.
Manifest erstellen
Damit die Device Administration API verwendet werden kann, muss das Manifest der App Folgendes enthalten:
- Eine Unterklasse von
DeviceAdminReceiver, die Folgendes enthält:- Die Berechtigung
BIND_DEVICE_ADMIN. - Die Möglichkeit, auf den
ACTION_DEVICE_ADMIN_ENABLED-Intent zu reagieren, der im Manifest als Intent-Filter angegeben ist.
- Die Berechtigung
- Eine Erklärung zu den Sicherheitsrichtlinien, die in Metadaten verwendet werden.
Hier ein Auszug aus dem Beispielmanifest für die Geräteverwaltung:
<activity android:name=".app.DeviceAdminSample"
android:label="@string/activity_sample_device_admin">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.SAMPLE_CODE" />
</intent-filter>
</activity>
<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver"
android:label="@string/sample_device_admin"
android:description="@string/sample_device_admin_description"
android:permission="android.permission.BIND_DEVICE_ADMIN">
<meta-data android:name="android.app.device_admin"
android:resource="@xml/device_admin_sample" />
<intent-filter>
<action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
</intent-filter>
</receiver>
Hinweise:
- Die folgenden Attribute beziehen sich auf Stringressourcen, die sich in der Beispiel-App in
ApiDemos/res/values/strings.xmlbefinden. Weitere Informationen zu Ressourcen finden Sie unter Anwendungsressourcen.android:label="@string/activity_sample_device_admin"bezieht sich auf das für Nutzer lesbare Label für die Aktivität.android:label="@string/sample_device_admin"bezieht sich auf das nutzerlesbare Label für die Berechtigung.android:description="@string/sample_device_admin_description"bezieht sich auf die für Nutzer lesbare Beschreibung der Berechtigung. Eine Beschreibung ist in der Regel länger und informativer als ein Label.
android:permission="android.permission.BIND_DEVICE_ADMIN"ist eine Berechtigung, die eineDeviceAdminReceiver-Unterklasse haben muss, damit nur das System mit dem Empfänger interagieren kann. Diese Berechtigung kann keiner App gewährt werden. So wird verhindert, dass andere Apps Ihre App zur Geräteverwaltung missbrauchen.android.app.action.DEVICE_ADMIN_ENABLEDist die primäre Aktion, die eineDeviceAdminReceiver-Unterklasse verarbeiten muss, um Geräte verwalten zu dürfen. Dieser wird auf den Empfänger festgelegt, wenn der Nutzer die Geräteverwaltungs-App aktiviert. In Ihrem Code wird dies normalerweise inonEnabled()verarbeitet. Damit die Funktion unterstützt wird, muss der Empfänger auch die BerechtigungBIND_DEVICE_ADMINbenötigen, damit andere Apps sie nicht missbrauchen können.- Wenn ein Nutzer die App „Geräteverwaltung“ aktiviert, erhält der Empfänger die Berechtigung, Aktionen als Reaktion auf die Übertragung bestimmter Systemereignisse auszuführen. Wenn ein geeignetes Ereignis eintritt, kann die App eine Richtlinie erzwingen. Wenn der Nutzer beispielsweise versucht, ein neues Passwort festzulegen, das nicht den Richtlinienanforderungen entspricht, kann die App ihn auffordern, ein anderes Passwort auszuwählen, das die Anforderungen erfüllt.
- Ändern Sie den Namen des Empfängers nach der Veröffentlichung Ihrer App nicht. Wenn sich der Name im Manifest ändert, wird die Geräteverwaltung deaktiviert, wenn Nutzer die App aktualisieren. Weitere Informationen finden Sie unter
<receiver>. android:resource="@xml/device_admin_sample"deklariert die Sicherheitsrichtlinien, die in Metadaten verwendet werden. Die Metadaten enthalten zusätzliche Informationen, die sich speziell auf den Geräteadministrator beziehen und von der KlasseDeviceAdminInfogeparst werden. Hier ist der Inhalt vondevice_admin_sample.xml:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
<uses-policies>
<limit-password />
<watch-login />
<reset-password />
<force-lock />
<wipe-data />
<expire-password />
<encrypted-storage />
<disable-camera />
</uses-policies>
</device-admin>
Bei der Entwicklung Ihrer App zur Geräteverwaltung müssen Sie nicht alle Richtlinien einbeziehen, sondern nur die, die für Ihre App relevant sind.
Weitere Informationen zur Manifestdatei finden Sie im Android-Entwicklerleitfaden.Code implementieren
Die Device Administration API umfasst die folgenden Klassen:
DeviceAdminReceiver- Basisklasse für die Implementierung einer Geräteverwaltungskomponente. Diese Klasse bietet eine praktische Möglichkeit, die vom System gesendeten Roh-Intent-Aktionen zu interpretieren. Ihre App zur Geräteverwaltung muss eine
DeviceAdminReceiver-Unterklasse enthalten. DevicePolicyManager- Eine Klasse zum Verwalten von Richtlinien, die auf einem Gerät erzwungen werden. Die meisten Clients dieser Klasse müssen eine
DeviceAdminReceiververöffentlicht haben, die der Nutzer derzeit aktiviert hat. DerDevicePolicyManagerverwaltet Richtlinien für eine oder mehrereDeviceAdminReceiver-Instanzen. DeviceAdminInfo- Mit dieser Klasse werden Metadaten für eine Geräteadministratorkomponente angegeben.
Diese Klassen bilden die Grundlage für eine voll funktionsfähige App zur Geräteverwaltung. Im restlichen Teil dieses Abschnitts wird beschrieben, wie Sie mit den APIs DeviceAdminReceiver und DevicePolicyManager eine App zur Geräteverwaltung erstellen.
DeviceAdminReceiver als untergeordnete Klasse definieren
Wenn Sie eine Geräteverwaltungs-App erstellen möchten, müssen Sie DeviceAdminReceiver unterordnen. Die DeviceAdminReceiver-Klasse besteht aus einer Reihe von Rückrufen, die bei bestimmten Ereignissen ausgelöst werden.
In der DeviceAdminReceiver-Unterklasse zeigt die Beispiel-App einfach eine Toast-Benachrichtigung als Reaktion auf bestimmte Ereignisse an. Beispiel:
Kotlin
class DeviceAdminSample : DeviceAdminReceiver() {
private fun showToast(context: Context, msg: String) {
context.getString(R.string.admin_receiver_status, msg).let { status ->
Toast.makeText(context, status, Toast.LENGTH_SHORT).show()
}
}
override fun onEnabled(context: Context, intent: Intent) =
showToast(context, context.getString(R.string.admin_receiver_status_enabled))
override fun onDisableRequested(context: Context, intent: Intent): CharSequence =
context.getString(R.string.admin_receiver_status_disable_warning)
override fun onDisabled(context: Context, intent: Intent) =
showToast(context, context.getString(R.string.admin_receiver_status_disabled))
override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) =
showToast(context, context.getString(R.string.admin_receiver_status_pw_changed))
...
}
Java
public class DeviceAdminSample extends DeviceAdminReceiver {
void showToast(Context context, String msg) {
String status = context.getString(R.string.admin_receiver_status, msg);
Toast.makeText(context, status, Toast.LENGTH_SHORT).show();
}
@Override
public void onEnabled(Context context, Intent intent) {
showToast(context, context.getString(R.string.admin_receiver_status_enabled));
}
@Override
public CharSequence onDisableRequested(Context context, Intent intent) {
return context.getString(R.string.admin_receiver_status_disable_warning);
}
@Override
public void onDisabled(Context context, Intent intent) {
showToast(context, context.getString(R.string.admin_receiver_status_disabled));
}
@Override
public void onPasswordChanged(Context context, Intent intent, UserHandle userHandle) {
showToast(context, context.getString(R.string.admin_receiver_status_pw_changed));
}
...
}
App aktivieren
Eines der wichtigsten Ereignisse, die eine App zur Geräteverwaltung verarbeiten muss, ist die Aktivierung der App durch den Nutzer. Der Nutzer muss die App explizit aktivieren, damit die Richtlinien erzwungen werden können. Wenn der Nutzer die App nicht aktiviert, ist sie zwar weiterhin auf dem Gerät vorhanden, die Richtlinien werden jedoch nicht erzwungen und der Nutzer kann die Vorteile der App nicht nutzen.
Die Aktivierung der App beginnt, wenn der Nutzer eine Aktion ausführt, die den ACTION_ADD_DEVICE_ADMIN-Intent auslöst. In der Beispiel-App geschieht dies, wenn der Nutzer das Kästchen Administrator aktivieren anklickt.
Wenn der Nutzer auf das Kästchen Administrator aktivieren klickt, ändert sich das Display und der Nutzer wird aufgefordert, die Geräteverwaltungs-App zu aktivieren (siehe Abbildung 2).
Abbildung 2. Beispielanwendung: App aktivieren
Unten sehen Sie den Code, der ausgeführt wird, wenn der Nutzer das Kästchen Administrator aktivieren anklickt. Dadurch wird der onPreferenceChange()-Callback ausgelöst. Dieser Callback wird aufgerufen, wenn der Wert dieses Preference vom Nutzer geändert wurde und kurz davor steht, festgelegt und/oder gespeichert zu werden. Wenn der Nutzer die App aktiviert, ändert sich das Display und der Nutzer wird aufgefordert, die App zur Geräteverwaltung zu aktivieren (siehe Abbildung 2). Andernfalls wird die App zur Geräteverwaltung deaktiviert.
Kotlin
override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
if (super.onPreferenceChange(preference, newValue)) return true
val value = newValue as Boolean
if (preference == enableCheckbox) {
if (value != adminActive) {
if (value) {
// Launch the activity to have the user enable our admin.
val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.getString(R.string.add_admin_extra_app_text))
}
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN)
// return false - don't update checkbox until we're really active
return false
} else {
dpm.removeActiveAdmin(deviceAdminSample)
enableDeviceCapabilitiesArea(false)
adminActive = false
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value)
}
return true
}
Java
@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
if (super.onPreferenceChange(preference, newValue)) {
return true;
}
boolean value = (Boolean) newValue;
if (preference == enableCheckbox) {
if (value != adminActive) {
if (value) {
// Launch the activity to have the user enable our admin.
Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample);
intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
activity.getString(R.string.add_admin_extra_app_text));
startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
// return false - don't update checkbox until we're really active
return false;
} else {
dpm.removeActiveAdmin(deviceAdminSample);
enableDeviceCapabilitiesArea(false);
adminActive = false;
}
}
} else if (preference == disableCameraCheckbox) {
dpm.setCameraDisabled(deviceAdminSample, value);
}
return true;
}
In der Zeile intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample) wird angegeben, dass mDeviceAdminSample (eine DeviceAdminReceiver-Komponente) die Zielrichtlinie ist.
Diese Zeile ruft die in Abbildung 2 dargestellte Benutzeroberfläche auf, über die Nutzer den Geräteadministrator zum System hinzufügen oder ablehnen können.
Wenn die App einen Vorgang ausführen muss, der von der Aktivierung der Geräteverwaltungs-App abhängt, wird bestätigt, dass die App aktiv ist. Dazu wird die Methode DevicePolicyManagerisAdminActive() verwendet. Beachten Sie, dass die DevicePolicyManager-Methode isAdminActive() eine DeviceAdminReceiver-Komponente als Argument verwendet:
Kotlin
private lateinit var dpm: DevicePolicyManager ... private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
Java
DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
return dpm.isAdminActive(deviceAdminSample);
}
Richtlinien verwalten
DevicePolicyManager ist eine öffentliche Klasse zum Verwalten von Richtlinien, die auf einem Gerät erzwungen werden. DevicePolicyManager verwaltet Richtlinien für eine oder mehrere DeviceAdminReceiver-Instanzen.
So rufen Sie einen Handle für die DevicePolicyManager ab:
Kotlin
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Java
DevicePolicyManager dpm =
(DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
In diesem Abschnitt wird beschrieben, wie Sie mit DevicePolicyManager administrative Aufgaben ausführen:
Passwortrichtlinien festlegen
DevicePolicyManager enthält APIs zum Festlegen und Durchsetzen der Richtlinie für Gerätepasswörter. In der Device Administration API gilt das Passwort nur für die Displaysperre. In diesem Abschnitt werden häufige passwortbezogene Aufgaben beschrieben.
Passwort für das Gerät festlegen
Mit diesem Code wird eine Benutzeroberfläche angezeigt, auf der der Nutzer aufgefordert wird, ein Passwort festzulegen:
Kotlin
Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
startActivity(intent)
}
Java
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent);
Passwortqualität festlegen
Die Passwortqualität kann eine der folgenden DevicePolicyManager-Konstanten sein:
PASSWORD_QUALITY_ALPHABETIC- Der Nutzer muss ein Passwort eingeben, das mindestens Buchstaben (oder andere Symbole) enthält.
PASSWORD_QUALITY_ALPHANUMERIC- Der Nutzer muss ein Passwort eingeben, das mindestens sowohl numerische als auch alphabetische (oder andere symbolische) Zeichen enthält.
PASSWORD_QUALITY_NUMERIC- Der Nutzer muss ein Passwort eingeben, das mindestens Ziffern enthält.
PASSWORD_QUALITY_COMPLEX- Der Nutzer muss ein Passwort eingegeben haben, das mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen enthält.
PASSWORD_QUALITY_SOMETHING- Die Richtlinie erfordert eine Art Passwort, aber es ist nicht festgelegt, wie es lauten muss.
PASSWORD_QUALITY_UNSPECIFIED- Die Richtlinie enthält keine Anforderungen an das Passwort.
So legen Sie beispielsweise fest, dass die Passwortrichtlinie ein alphanumerisches Passwort erfordert:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Anforderungen an den Passwortinhalt festlegen
Ab Android 3.0 enthält die Klasse DevicePolicyManager Methoden, mit denen Sie den Inhalt des Passworts optimieren können. Sie können beispielsweise eine Richtlinie festlegen, dass Passwörter mindestens n Großbuchstaben enthalten müssen. So können Sie den Inhalt eines Passworts optimieren:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
In diesem Snippet wird beispielsweise festgelegt, dass das Passwort mindestens zwei Großbuchstaben enthalten muss:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwMinUppercase = 2 ... dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwMinUppercase = 2; ... dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);
Mindestlänge des Passworts festlegen
Sie können angeben, dass ein Passwort mindestens die angegebene Mindestlänge haben muss. Beispiel:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwLength: Int = ... ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwLength; ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);
Maximale Anzahl fehlgeschlagener Passworteingaben festlegen
Sie können die maximale Anzahl der zulässigen fehlgeschlagenen Passworteingaben festlegen, bevor das Gerät gelöscht (d. h. auf die Werkseinstellungen zurückgesetzt) wird. Beispiel:
Kotlin
val dPM:DevicePolicyManager private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val maxFailedPw: Int = ... ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int maxFailedPw; ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Zeitüberschreitung für Ablauf des Passworts festlegen
Ab Android 3.0 können Sie mit der Methode setPasswordExpirationTimeout() festlegen, wann ein Passwort abläuft. Dieser Ablauf wird als Delta in Millisekunden angegeben, ausgehend vom Zeitpunkt, zu dem ein Geräteadministrator die Zeitüberschreitung für das Ablaufdatum festgelegt hat. Beispiel:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwExpiration: Long = ... ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; long pwExpiration; ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);
Passwort basierend auf dem Verlauf einschränken
Ab Android 3.0 können Sie mit der Methode setPasswordHistoryLength() die Möglichkeit für Nutzer einschränken, alte Passwörter wiederzuverwenden. Diese Methode nimmt den Parameter length an, der angibt, wie viele alte Passwörter gespeichert werden. Wenn diese Richtlinie aktiv ist, können Nutzer kein neues Passwort eingeben, das mit den letzten n Passwörtern übereinstimmt. So wird verhindert, dass Nutzer immer wieder dasselbe Passwort verwenden. Diese Richtlinie wird in der Regel in Verbindung mit setPasswordExpirationTimeout() verwendet, wodurch Nutzer gezwungen werden, ihre Passwörter nach Ablauf einer bestimmten Zeit zu aktualisieren.
Mit diesem Snippet wird beispielsweise verhindert, dass Nutzer eines ihrer letzten fünf Passwörter wiederverwenden:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwHistoryLength = 5 ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwHistoryLength = 5; ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);
Gerätesperre festlegen
Sie können festlegen, wie lange Nutzer maximal inaktiv sein dürfen, bevor das Gerät gesperrt wird. Beispiel:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val timeMs: Long = 1000L * timeout.text.toString().toLong() ... dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... long timeMs = 1000L*Long.parseLong(timeout.getText().toString()); dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);
Sie können das Gerät auch programmatisch anweisen, sich sofort zu sperren:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Daten löschen
Sie können das Gerät mit der Methode DevicePolicyManager
wipeData() auf die Werkseinstellungen zurücksetzen. Das ist nützlich, wenn das Gerät verloren geht oder gestohlen wird. Häufig wird die Entscheidung zum Löschen des Geräts getroffen, wenn bestimmte Bedingungen erfüllt sind. Mit setMaximumFailedPasswordsForWipe() können Sie beispielsweise angeben, dass ein Gerät nach einer bestimmten Anzahl von fehlgeschlagenen Passwortversuchen gelöscht werden soll.
So löschen Sie die Daten:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
Die Methode wipeData() nimmt als Parameter eine Bitmaske mit zusätzlichen Optionen an. Derzeit muss der Wert 0 sein.
Kamera deaktivieren
Ab Android 4.0 können Sie die Kamera deaktivieren. Die Deaktivierung muss nicht dauerhaft sein. Die Kamera kann dynamisch basierend auf Kontext, Uhrzeit usw. aktiviert oder deaktiviert werden.
Mit der Methode setCameraDisabled() kannst du festlegen, ob die Kamera deaktiviert ist. In diesem Snippet wird die Kamera beispielsweise basierend auf einer Kästcheneinstellung aktiviert oder deaktiviert:
Kotlin
private lateinit var disableCameraCheckbox: CheckBoxPreference private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)
Java
private CheckBoxPreference disableCameraCheckbox; DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());
Speicherverschlüsselung
Ab Android 3.0 können Sie mit der Methode setStorageEncryption() eine Richtlinie festlegen, die die Verschlüsselung des Speicherbereichs erfordert, sofern unterstützt.
Beispiel:
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setStorageEncryption(deviceAdminSample, true)
Java
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setStorageEncryption(deviceAdminSample, true);
Im Beispiel für die Device Administration API finden Sie ein vollständiges Beispiel dazu, wie die Speicherverschlüsselung aktiviert wird.
Weitere Codebeispiele
Die Beispiele Android AppRestrictionEnforcer und DeviceOwner veranschaulichen die Verwendung der auf dieser Seite beschriebenen APIs.