Einstellung des Geräteadministrators Ab Android 9 (API-Level 28) werden einige Administratorrichtlinien als veraltet markiert, wenn sie von einem Geräteadministrator aufgerufen werden. Wir empfehlen Ihnen, sich schon jetzt auf diese Änderung vorzubereiten. Weitere Informationen und die Migrationsoptionen finden Sie unter Einstellung des Geräteadministrators.
Android unterstützt über die Android Device Administration API Unternehmens-Apps. Die Device Administration API bietet Geräteverwaltungsfunktionen auf Systemebene. Mit diesen APIs können Sie sicherheitsbewusste Anwendungen erstellen, die für Unternehmen nützlich sind, in denen IT-Experten eine umfassende Kontrolle über die Geräte der Mitarbeiter benötigen. Diese APIs wurden beispielsweise von der integrierten Android-E-Mail-App genutzt, 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 verloren gegangene oder gestohlene Mobilgeräte auch per Fernzugriff auf die Werkseinstellungen zurücksetzen (d. h. die Werkseinstellungen wiederherstellen). 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. Dabei werden die verschiedenen Funktionen der Device Administration API erläutert, die eine höhere Sicherheit für Mitarbeitergeräte mit Android ermöglichen.
Hinweis: Informationen zum Erstellen eines Work Policy Controllers für Android for Work-Bereitstellungen finden Sie unter Device Policy Controller erstellen.
Monitorloser Modus für Geräteeigentümer
Mit Android 14 (API-Level 34) wird der monitorlose Systemnutzermodus eingeführt (Geräte, auf denen UserManager.isHeadlessSystemUserMode true zurückgibt). Im monitorlosen Systemnutzermodus ist der Systemnutzer ein Hintergrundnutzer und benötigt zusätzliche Nutzer im Vordergrund für die Endnutzerinteraktion. In Android 14 wird außerdem ein monitorloser Geräteinhaber-Verknüpfungsmodus eingeführt, der allen verknüpften Nutzern einen Profilinhaber hinzufügt, mit Ausnahme des Systemnutzers, für den der Geräteinhaber festgelegt ist.
Auf Geräten, die mit einem monitorlosen Systemnutzer konfiguriert sind (wo der Systemnutzer im Hintergrund ausgeführt wird), werden nur Geräterichtlinien mit globalem Geltungsbereich (Richtlinien, die für alle Nutzer gelten) auf den Vordergrundnutzer oder die Nutzer im Vordergrund angewendet. Weitere Informationen finden Sie unter addUserRestriction.
Hersteller von Android-Geräten können die Hinweise lesen, die auf source.android.com veröffentlicht wurden.
Übersicht zur Device Administration API
Hier sind Beispiele für die Arten von Apps, die die Device Administration API verwenden können:
- E-Mail-Clients
- Sicherheits-Apps zur Remote-Löschung
- Geräteverwaltungsdienste und -Apps
Wie funktioniert die Kanalmitgliedschaft?
Sie verwenden die Device Administration API, um Geräteverwaltungs-Apps zu schreiben, die Nutzer auf ihren Geräten installieren. Die Geräteverwaltungs-App erzwingt die gewünschten Richtlinien. Dies funktioniert folgendermaßen:
- Ein Systemadministrator schreibt eine Geräteverwaltungs-App, die Sicherheitsrichtlinien für Remote- bzw. lokale Geräte erzwingt. Diese Richtlinien können in der Anwendung hartcodiert sein oder die Anwendung kann Richtlinien dynamisch vom Server eines Drittanbieters abrufen.
- Die App ist auf den Geräten der Nutzer installiert. Android bietet derzeit keine automatisierte Bereitstellungslösung. Ein Systemadministrator kann die Anwendung unter anderem so an Nutzer verteilen:
- Mit Google Play.
- Installation aus einem anderen Speicher wird aktiviert.
- Die Bereitstellung der App über andere Mittel, z. B. per E-Mail oder über Websites.
- Der Nutzer wird vom System aufgefordert, 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 aktivieren, unterliegen sie deren Richtlinien. Die Einhaltung dieser Richtlinien bietet in der Regel Vorteile wie den Zugriff auf sensible Systeme und Daten.
Wenn Nutzer die App zur Geräteverwaltung nicht aktivieren, bleibt sie auf dem Gerät, jedoch im Status „Inaktiv“. Nutzer unterliegen nicht den Richtlinien und können umgekehrt keine Vorteile der App nutzen, z. B. können sie möglicherweise keine Daten synchronisieren.
Wenn ein Nutzer die Richtlinien nicht einhält, z. B. wenn er ein Passwort festlegt, das gegen die Richtlinien verstößt, muss die App entscheiden, wie damit umgegangen wird. Dies führt jedoch in der Regel dazu, dass der Nutzer keine Daten synchronisieren kann.
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 Teilbereitstellung. Mit anderen Worten: Wenn ein Gerät (z. B. ein Legacy-Gerät) nicht alle angegebenen Richtlinien unterstützt, gibt es keine Möglichkeit, dem Gerät eine Verbindung zu erlauben.
Wenn ein Gerät mehrere aktivierte Administrator-Apps enthält, wird die strengste Richtlinie erzwungen. Es gibt keine Möglichkeit, Anzeigen auf eine bestimmte Admin-App auszurichten.
Um eine vorhandene App zur Geräteverwaltung zu deinstallieren, müssen Nutzer zuerst die Registrierung der App als Administrator aufheben.
Richtlinien
In Unternehmen müssen Geräte von Mitarbeitern oft strengen Richtlinien für die Nutzung des Geräts entsprechen. Die Device Administration API unterstützt die in Tabelle 1 aufgeführten Richtlinien. Beachten Sie, dass die Device Administration API derzeit nur Passwörter für die Displaysperre unterstützt:
Tabelle 1 Von der Device Administration API unterstützte Richtlinien.
| Richtlinie | Beschreibung |
|---|---|
| Passwort aktiviert | Bei dieser Einstellung müssen Geräte nach einer PIN oder Passwörtern fragen. |
| Mindestlänge des Passworts | Legen Sie die erforderliche Anzahl von Zeichen für das Passwort fest. Beispielsweise können Sie festlegen, dass PINs oder Passwörter mindestens sechs Zeichen umfassen müssen. |
| Alphanumerisches Passwort erforderlich | Dafür müssen Passwörter eine Kombination aus Buchstaben und Zahlen enthalten. Sie können symbolische Zeichen enthalten. |
| Komplexes Passwort erforderlich | Passwörter müssen mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen enthalten. In Android 3.0 eingeführt. |
| Mindestanzahl der Buchstaben im Passwort erforderlich | Die Mindestanzahl von Buchstaben, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich ist. In Android 3.0 eingeführt. |
| Passwort muss mindestens Kleinbuchstaben enthalten | Die Mindestanzahl von Kleinbuchstaben, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich ist. In Android 3.0 eingeführt. |
| Passwort muss mindestens Zeichen enthalten, die keine Buchstaben sind | Die Mindestanzahl von Zeichen, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich sind. In Android 3.0 eingeführt. |
| Mindestanzahl der Ziffern im Passwort erforderlich | Die Mindestanzahl an Ziffern, die im Passwort für alle Administratoren oder für einen bestimmten Wert erforderlich sind. In Android 3.0 eingeführt. |
| Mindestanzahl von Symbolen im Passwort erforderlich | Die Mindestanzahl von Symbolen, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich sind. In Android 3.0 eingeführt. |
| Passwort muss mindestens einen Großbuchstaben enthalten | Die Mindestanzahl an Großbuchstaben, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich ist. In Android 3.0 eingeführt. |
| Zeitlimit für Ablauf des Passworts | Der Zeitpunkt, zu dem das Passwort abläuft, ausgedrückt als Delta in Millisekunden ab dem Zeitpunkt, zu dem der Geräteverwaltungszeitpunkt das Zeitlimit festlegt. In Android 3.0 eingeführt. |
| Beschränkung des Passwortverlaufs | Diese Richtlinie verhindert, dass Nutzer die letzten n eindeutigen Passwörter wiederverwenden.
Diese Richtlinie wird normalerweise in Verbindung mit setPasswordExpirationTimeout() verwendet, das Nutzer zwingt, ihre Passwörter nach einer bestimmten Zeit zu aktualisieren.
In Android 3.0 eingeführt. |
| Maximale Anzahl fehlgeschlagener Passworteingaben | Gibt an, wie oft ein Nutzer ein falsches Passwort eingeben kann, bevor die Gerätedaten gelöscht werden. Über die Device Administration API können Administratoren das Gerät auch per Fernzugriff auf die Werkseinstellungen zurücksetzen. Dies schützt die Daten für den Fall, dass das Gerät verloren geht oder gestohlen wird. |
| Maximale Inaktivitätszeitsperre | Legt fest, wie lange es dauert, bis der Nutzer den Bildschirm zuletzt berührt oder auf eine Schaltfläche geklickt hat, bevor das Gerät den Bildschirm sperrt. 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 erforderlich | Gibt an, dass der Speicherbereich verschlüsselt werden soll, wenn das Gerät dies unterstützt. In Android 3.0 eingeführt. |
| Kamera deaktivieren | Gibt an, dass die Kamera deaktiviert werden soll. Beachten Sie, dass es sich dabei nicht um eine dauerhafte Deaktivierung handeln muss. Die Kamera kann je nach Kontext, Zeit usw. dynamisch aktiviert bzw. deaktiviert werden. In Android 4.0 eingeführt. |
Weitere Funktionen
Zusätzlich zur Unterstützung der in der obigen Tabelle aufgeführten Richtlinien bietet die Device Administration API folgende Möglichkeiten:
- Nutzer auffordern, ein neues Passwort festzulegen.
- Gerät sofort sperren.
- Die Gerätedaten löschen, d. h. das Gerät auf die Werkseinstellungen zurücksetzen
Beispiel-App
Die auf dieser Seite verwendeten Beispiele basieren auf dem Device Administration API-Beispiel, das in den SDK-Beispielen enthalten ist, die über den Android SDK Manager verfügbar sind. Sie finden sie unter <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java auf Ihrem System.
Die Beispiel-App bietet eine Demo der Funktionen zur Geräteverwaltung. Nutzer sehen eine Benutzeroberfläche, über die sie die App zur Geräteverwaltung aktivieren können. Nachdem sie die App aktiviert haben, können sie über die Schaltflächen in der Benutzeroberfläche Folgendes tun:
- Legen Sie die Passwortqualität fest.
- Legen Sie Anforderungen für das Nutzerpasswort fest, z. B. die Mindestlänge oder die Mindestanzahl von numerischen Zeichen, die das Passwort enthalten muss.
- 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 fehlgeschlagene Passworteingaben passieren können, bevor das Gerät auf die Werkseinstellungen zurückgesetzt wird.
- Legen Sie fest, wie lange das Passwort ab jetzt abläuft.
- Legen Sie die Länge des Passwortverlaufs fest. Die Länge bezieht sich auf die Anzahl der im Verlauf gespeicherten alten Passwörter. Dadurch wird verhindert, dass Nutzer eines der letzten n Passwörter wiederverwenden, die sie zuvor verwendet haben.
- Legen Sie fest, dass der Speicherbereich verschlüsselt werden soll, wenn das Gerät dies unterstützt.
- Legen Sie die maximale Zeitspanne der Inaktivität fest, nach der das Gerät gesperrt wird.
- Sperren Sie das Gerät sofort.
- Löschen Sie die Daten des Geräts, d. h., stellen Sie die Werkseinstellungen wieder her.
- Deaktivieren Sie die Kamera.
Abbildung 1: Screenshot der Beispiel-App
Geräteverwaltungs-App entwickeln
Systemadministratoren können die Device Administration API verwenden, um eine App zu schreiben, die Remote- oder lokale Gerätesicherheitsrichtlinien erzwingt. In diesem Abschnitt werden die Schritte zum Erstellen einer Geräteverwaltungs-App zusammengefasst.
Manifest erstellen
Damit du die Device Administration API verwenden kannst, muss das Manifest der App Folgendes enthalten:
- Eine abgeleitete Klasse von
DeviceAdminReceiver, die Folgendes enthält:- Die Berechtigung
BIND_DEVICE_ADMIN. - Die Fähigkeit, auf den Intent
ACTION_DEVICE_ADMIN_ENABLEDzu antworten, ausgedrückt im Manifest als Intent-Filter.
- Die Berechtigung
- Eine Deklaration von Sicherheitsrichtlinien, die in Metadaten verwendet werden.
Hier ist 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 für die Beispielanwendung 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 vom Nutzer lesbare Label der Aktivität.android:label="@string/sample_device_admin"bezieht sich auf das vom Nutzer lesbare 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 eine Beschriftung.
android:permission="android.permission.BIND_DEVICE_ADMIN"ist eine Berechtigung, die eine abgeleiteteDeviceAdminReceiver-Klasse haben muss, damit nur das System mit dem Empfänger interagieren kann. Diese Berechtigung kann keiner App gewährt werden. Dadurch wird verhindert, dass andere Apps die App zur Geräteverwaltung missbrauchen.android.app.action.DEVICE_ADMIN_ENABLEDist die primäre Aktion, die eine abgeleiteteDeviceAdminReceiver-Klasse ausführen muss, um ein Gerät verwalten zu können. Diese wird auf den Empfänger festgelegt, wenn der Nutzer die App zur Geräteverwaltung aktiviert. Mit deinem Code wird dies normalerweise inonEnabled()erledigt. Für die Unterstützung muss der Empfänger außerdem die BerechtigungBIND_DEVICE_ADMINanfordern, damit sie von anderen Apps nicht missbraucht werden kann.- Wenn ein Nutzer die Geräteverwaltungs-App 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 festlegen. Wenn der Nutzer beispielsweise versucht, ein neues Passwort festzulegen, das nicht den Richtlinienanforderungen entspricht, kann die Anwendung ihn auffordern, ein anderes Passwort auszuwählen, das den Anforderungen entspricht.
- Ändern Sie den Namen des Empfängers nach der Veröffentlichung der App nicht. Wenn sich der Name im Manifest ändert, wird der Geräteadministrator deaktiviert, wenn Nutzer die App aktualisieren. Weitere Informationen finden Sie unter
<receiver>. android:resource="@xml/device_admin_sample"deklariert die in Metadaten verwendeten Sicherheitsrichtlinien. Die Metadaten liefern zusätzliche Informationen speziell für den Geräteadministrator, wie von derDeviceAdminInfo-Klasse geparst. 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>
Beim Entwerfen der Geräteverwaltungsanwendung müssen Sie nicht alle Richtlinien einschließen, sondern nur die, die für Ihre Anwendung relevant sind.
Weitere Informationen zur Manifestdatei finden Sie im Leitfaden für Android-Entwickler.Code implementieren
Die Device Administration API umfasst die folgenden Klassen:
DeviceAdminReceiver- Basisklasse für die Implementierung einer Komponente zur Geräteverwaltung. Diese Klasse erleichtert die Interpretation der unbearbeiteten Intent-Aktionen, die vom System gesendet werden. Die Geräteverwaltungsanwendung muss eine abgeleitete
DeviceAdminReceiver-Klasse enthalten. DevicePolicyManager- Kurs 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 Komponente für den Geräteadministrator angegeben.
Diese Klassen bilden die Grundlage für eine voll funktionsfähige App zur Geräteverwaltung. Im weiteren Verlauf dieses Abschnitts wird beschrieben, wie Sie mit den APIs DeviceAdminReceiver und DevicePolicyManager eine App zur Geräteverwaltung schreiben.
Abgeleitete Klassen von DeviceAdminReceiver
Zum Erstellen einer Geräteverwaltungs-App müssen Sie eine abgeleitete Klasse von DeviceAdminReceiver erstellen. Die Klasse DeviceAdminReceiver besteht aus einer Reihe von Callbacks, die ausgelöst werden, wenn bestimmte Ereignisse eintreten.
In ihrer abgeleiteten DeviceAdminReceiver-Klasse zeigt die Beispielanwendung einfach eine Toast-Benachrichtigung als Antwort 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));
}
...
}
Anwendung aktivieren
Eines der wichtigsten Ereignisse, die eine Geräteverwaltungs-App bewältigen muss, ist die Aktivierung der App durch den Nutzer. Der Nutzer muss die App explizit aktivieren, damit die Richtlinien erzwungen werden. Wenn der Nutzer die App nicht aktiviert, ist sie weiterhin auf dem Gerät vorhanden, aber die Richtlinien werden nicht erzwungen und der Nutzer kann nicht von den Vorteilen der App profitieren.
Der Prozess zum Aktivieren der Anwendung beginnt, wenn der Nutzer eine Aktion ausführt, die den Intent ACTION_ADD_DEVICE_ADMIN auslöst. In der Beispielanwendung passiert das, wenn der Nutzer auf das Kästchen Administrator aktivieren klickt.
Wenn der Nutzer auf das Kästchen Admin aktivieren klickt, wird er aufgefordert, die Geräteverwaltungs-App zu aktivieren (siehe Abbildung 2).
Abbildung 2: Beispiel-App: App aktivieren
Der folgende Code wird ausgeführt, wenn der Nutzer auf das Kästchen Administrator aktivieren klickt. Dadurch wird der onPreferenceChange()-Callback ausgelöst. Dieser Callback wird aufgerufen, wenn der Wert von Preference vom Nutzer geändert wurde und nun festgelegt und/oder beibehalten wird. Wenn der Nutzer die App aktiviert, wird er auf dem Display aufgefordert, die Geräteverwaltungs-App zu aktivieren (siehe Abbildung 2). Andernfalls ist 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;
}
Die Zeile intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,
mDeviceAdminSample) besagt, dass mDeviceAdminSample (eine DeviceAdminReceiver-Komponente) die Zielrichtlinie ist.
Mit dieser Zeile wird die in Abbildung 2 gezeigte Benutzeroberfläche aufgerufen. Dort werden Nutzer durch das Hinzufügen des Geräteadministrators zum System geführt (oder können ihn ablehnen).
Wenn die App einen Vorgang ausführen muss, der von der Aktivierung der Geräteadministrator-App abhängig ist, bestätigt sie, dass die App aktiv ist. Dazu wird die DevicePolicyManager-Methode isAdminActive() verwendet. Beachten Sie, dass die DevicePolicyManager-Methode isAdminActive() eine DeviceAdminReceiver-Komponente als Argument annimmt:
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 erhalten Sie einen Handle für DevicePolicyManager:
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 Verwaltungsaufgaben ausführen:
Passwortrichtlinien festlegen
DevicePolicyManager enthält APIs zum Festlegen und Erzwingen der Passwortrichtlinie für Geräte. 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 Buchstaben oder andere Symbole enthält.
PASSWORD_QUALITY_NUMERIC- Der Nutzer muss ein Passwort eingeben, das mindestens numerische Zeichen 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 setzt ein Passwort voraus, ist aber unabhängig davon, was es ist.
PASSWORD_QUALITY_UNSPECIFIED- Die Richtlinie enthält keine Anforderungen an das Passwort.
So können Sie beispielsweise die Passwortrichtlinie so einstellen, dass ein alphanumerisches Passwort erforderlich ist:
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 Inhalt von Passwörtern festlegen
Ab Android 3.0 enthält die Klasse DevicePolicyManager Methoden, mit denen Sie den Inhalt des Passworts optimieren können. Beispielsweise können Sie eine Richtlinie festlegen, die besagt, dass Passwörter mindestens n Großbuchstaben enthalten müssen. Dies sind die Methoden zur Feinabstimmung des Inhalts eines Passworts:
setPasswordMinimumLetters()setPasswordMinimumLowerCase()setPasswordMinimumUpperCase()setPasswordMinimumNonLetter()setPasswordMinimumNumeric()setPasswordMinimumSymbols()
Dieses Snippet besagt beispielsweise, 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 festlegen, 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 maximal zulässige Anzahl fehlgeschlagener Passworteingaben festlegen, bevor das Gerät 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);
Zeitlimit für Ablauf des Passworts festlegen
Ab Android 3.0 können Sie mit der Methode setPasswordExpirationTimeout() festlegen, wann ein Passwort abläuft. Dies wird als Delta in Millisekunden ab dem Zeitpunkt, zu dem ein Geräteadministrator das Ablaufdatum festgelegt hat, ausgedrückt. 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() einschränken, dass Nutzer alte Passwörter wiederverwenden können. Diese Methode verwendet einen length-Parameter, der angibt, wie viele alte Passwörter gespeichert werden. Wenn diese Richtlinie aktiviert ist, können Nutzer kein neues Passwort eingeben, das mit den letzten n Passwörtern übereinstimmt. Dadurch wird verhindert, dass Nutzer immer wieder dasselbe Passwort verwenden. Diese Richtlinie wird normalerweise in Verbindung mit setPasswordExpirationTimeout() verwendet, das Nutzer zwingt, ihre Passwörter nach einer bestimmten Zeit zu aktualisieren.
Das Snippet verhindert beispielsweise, dass Nutzer ihre 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 einrichten
Sie können den maximalen Zeitraum festlegen, in dem der Nutzer inaktiv sein darf, 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, es sofort zu sperren:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Java
DevicePolicyManager dpm; dpm.lockNow();
Daten löschen
Mit der DevicePolicyManager-Methode wipeData() können Sie das Gerät auf die Werkseinstellungen zurücksetzen. Dies ist nützlich, wenn das Gerät verloren geht oder gestohlen wird. Häufig ist die Entscheidung, das Gerät zu löschen, das Ergebnis bestimmter Bedingungen. Mit setMaximumFailedPasswordsForWipe() können Sie beispielsweise festlegen, dass ein Gerät nach einer bestimmten Anzahl fehlgeschlagener Passworteingaben gelöscht werden soll.
So löschen Sie Daten:
Kotlin
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Java
DevicePolicyManager dpm; dpm.wipeData(0);
Die Methode wipeData() verwendet als Parameter eine Bitmaske mit zusätzlichen Optionen. Derzeit muss der Wert 0 sein.
Kamera deaktivieren
Ab Android 4.0 können Sie die Kamera deaktivieren. Es muss sich dabei nicht um eine dauerhafte Deaktivierung handeln. Die Kamera kann je nach Kontext, Zeit usw. dynamisch aktiviert bzw. deaktiviert werden.
Mit der Methode setCameraDisabled() können Sie festlegen, ob die Kamera deaktiviert werden soll. Mit diesem Snippet wird die Kamera beispielsweise anhand eines Kästchens 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 diese unterstützt wird.
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);
Ein vollständiges Beispiel für die Aktivierung der Speicherverschlüsselung finden Sie im Device Administration API-Beispiel.
Zusätzliche Codebeispiele
In den Beispielen Android AppRestrictionEnforcer und DeviceOwner wird die Verwendung der auf dieser Seite behandelten APIs näher erläutert.