Geräteverwaltung – Übersicht

Einstellung von Device Admin Ab Android 9 (API-Level 28) werden einige Administratorrichtlinien als veraltet markiert, 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 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 von Mitarbeitern 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 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. 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 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. 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.

Hinweis: Unter Android 14 (API-Ebene 34) kann eine DPC-Anwendung nur dann als Geräteeigentümer auf einem Gerät festgelegt werden, das als Headless System User Mode device konfiguriert ist, wenn sie den verbundenen Modus unterstützt. Weitere Informationen finden Sie unter HEADLESS_DEVICE_OWNER_MODE_AFFILIATED.

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 Geräteadministratoren, 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 wie den 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. 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. 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 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 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 an Ziffern, die im Passwort für alle Administratoren oder für einen bestimmten Wert erforderlich sind. 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	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. 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. 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. So werden Daten geschützt, falls das Gerät verloren geht oder gestohlen wird.
Maximale Inaktivitätszeitsperre	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 erforderlich	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 je nach Kontext, Zeit usw. dynamisch aktiviert bzw. deaktiviert werden. Einführung in Android 4.0.

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
• 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 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 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.
• Kamera deaktivieren

Abbildung 1. Screenshot der Beispiel-App

Geräteverwaltungs-App 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.
• 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.xml befinden. 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 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 eine DeviceAdminReceiver-Unterklasse 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_ENABLED ist die primäre Aktion, die eine DeviceAdminReceiver-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 in onEnabled() verarbeitet. Außerdem muss der Empfänger die Berechtigung BIND_DEVICE_ADMIN haben, damit andere Apps sie nicht missbrauchen können.
• 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 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 liefern zusätzliche Informationen speziell für den Geräteadministrator, wie von der DeviceAdminInfo-Klasse geparst. Hier ist der Inhalt von device_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 Ihrer 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 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. Die Geräteverwaltungsanwendung muss eine abgeleitete DeviceAdminReceiver-Klasse enthalten.

DevicePolicyManager

Eine Klasse zum Verwalten von Richtlinien, die auf einem Gerät erzwungen werden. Die meisten Clients dieser Klasse müssen eine DeviceAdminReceiver veröffentlicht haben, die der Nutzer derzeit aktiviert hat. Der DevicePolicyManager verwaltet Richtlinien für eine oder mehrere DeviceAdminReceiver-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 Rest 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 als Reaktion auf bestimmte Ereignisse einfach eine Toast-Benachrichtigung 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, ihre Richtlinien werden jedoch nicht erzwungen und der Nutzer kann keine Vorteile der App 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 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 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 Benutzeroberfläche in Abbildung 2 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 Verwaltungsaufgaben ausführen:

• Passwortrichtlinien festlegen
• Gerätesperre einrichten
• Daten löschen

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 Ziffern als auch Buchstaben (oder andere Symbole) 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. Im Folgenden sind die Methoden zur Anpassung des Inhalts eines Passworts aufgeführt:

• 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 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() dafür sorgen, dass Nutzer keine alten Passwörter wiederverwenden können. 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. Dadurch 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, es 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. Dies 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 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() 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. Es muss sich dabei nicht um eine dauerhafte Deaktivierung handeln. 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. 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 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

In den Beispielen Android AppRestrictionEnforcer und DeviceOwner wird die Verwendung der auf dieser Seite behandelten APIs näher erläutert.