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 die Migrationsoptionen finden Sie unter Einstellung des Geräteadministrators.

Android unterstützt Unternehmens-Apps über die Android Device Administration API. 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 eine umfassende Kontrolle über die Geräte der Mitarbeiter benötigen. Die integrierte Android-E-Mail-App nutzt diese APIs beispielsweise, 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, auf allen Geräten erzwingen. Administratoren können auch verlorene oder gestohlene Mobilgeräte aus der Ferne löschen (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. Es werden die verschiedenen Funktionen der Device Administration API erläutert, die für eine höhere Sicherheit von Android-Geräten von Mitarbeitern sorgen.

Hinweis: Informationen zum Erstellen eines Work Policy Controllers für Android for Work-Bereitstellungen findest du unter Device Policy Controller erstellen.

Modus „Geräteeigentümer“ ohne Display

Mit Android 14 (API-Level 34) wird der Modus „Monitorloser Systemnutzer“ eingeführt (Geräte, auf denen UserManager.isHeadlessSystemUserMode den Wert true zurückgibt). Im Modus „Monitorloser Systemnutzer“ ist der Systemnutzer ein Hintergrundnutzer und benötigt zusätzliche Vordergrundnutzer für die Interaktion mit dem Endnutzer. Mit Android 14 wird auch ein Modus für zugehörige Headless-Geräteeigentümer eingeführt, der allen zugehörigen Nutzern außer dem Systemnutzer, für den der Geräteeigentümer festgelegt ist, einen Profilinhaber hinzufügt.

Auf Geräten, die mit einem Headless-Systemnutzer konfiguriert sind (bei dem der Systemnutzer im Hintergrund ausgeführt wird), 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: In Android 14 (API-Level 34) kann eine DPC-Anwendung nur dann als Geräteeigentümer auf einem Gerät festgelegt werden, das als Gerät im Headless System User Mode konfiguriert ist, wenn sie den Affiliated Mode unterstützt. Weitere Informationen finden Sie unter HEADLESS_DEVICE_OWNER_MODE_AFFILIATED.

Android-Gerätehersteller können sich an den Leitfaden 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önnten:

• E-Mail-Clients
• Sicherheits-Apps, die Daten aus der Ferne löschen.
• Dienste und Apps zur Geräteverwaltung.

Wie funktioniert das?

Mit der Device Administration API können Sie Admin-Apps für Geräte schreiben, die Nutzer auf ihren Geräten installieren. Die Geräteadministrator-App erzwingt die gewünschten Richtlinien. Funktionsweise:

• Ein Systemadministrator schreibt eine Geräteadministrator-App, die Sicherheitsrichtlinien für Remote- und lokale Geräte erzwingt. Diese Richtlinien können in der App hartcodiert sein oder die App kann Richtlinien dynamisch von einem Drittanbieterserver abrufen.
• Die App wird auf den Geräten der Nutzer installiert. Android bietet derzeit keine automatisierte Bereitstellungslösung. Hier sind einige Möglichkeiten, wie ein Systemadministrator die App an Nutzer verteilen kann:
  • Mit Google Play.
  • Installation aus einem anderen Store aktivieren.
  • Verbreitung der App über andere Kanäle, z. B. per E-Mail oder über Websites.
• Das System fordert den Nutzer auf, die Admin-App zu aktivieren. Wie und wann dies geschieht, hängt davon ab, wie die App implementiert ist.
• Sobald Nutzer die Geräteadministrator-App aktivieren, unterliegen sie deren Richtlinien. Die Einhaltung dieser Richtlinien bietet in der Regel Vorteile, z. B. den Zugriff auf sensible Systeme und Daten.

Wenn Nutzer die Geräteadministrator-App nicht aktivieren, bleibt sie auf dem Gerät, ist aber inaktiv. Die Richtlinien der App gelten nicht für diese Nutzer, sie können aber auch keine der 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), entscheidet die App, wie damit umzugehen ist. In der Regel führt dies jedoch dazu, dass der Nutzer keine Daten synchronisieren kann.

Wenn ein Gerät versucht, eine Verbindung zu einem Server herzustellen, der Richtlinien erfordert, die in der Device Administration API nicht unterstützt werden, wird die Verbindung nicht zugelassen. Die Device Administration API lässt derzeit keine teilweise Bereitstellung zu. Mit anderen Worten: Wenn ein Gerät (z. B. ein älteres Gerät) nicht alle angegebenen Richtlinien unterstützt, kann es keine Verbindung herstellen.

Wenn auf einem Gerät mehrere Admin-Apps aktiviert sind, wird die strengste Richtlinie erzwungen. Es ist nicht möglich, eine bestimmte Admin-App anzusprechen.

Wenn Nutzer eine vorhandene Geräteadministrator-App deinstallieren möchten, müssen sie die App zuerst als Administrator abmelden.

Richtlinien

In Unternehmen müssen die Geräte von Mitarbeitern häufig strenge Richtlinien einhalten, die die Nutzung des Geräts regeln. 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
Passwortgeschützt	Geräte müssen eine PIN oder ein Passwort anfordern.
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	Erfordert, dass Passwörter eine Kombination aus Buchstaben und Ziffern enthalten. Sie können symbolische Zeichen enthalten.
Komplexes Passwort erforderlich	Passwörter müssen mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen enthalten. Eingeführt in Android 3.0.
Mindestanzahl der im Passwort erforderlichen Buchstaben	Die Mindestanzahl der Buchstaben, die im Passwort für alle Administratoren oder einen bestimmten Administrator erforderlich sind. Eingeführt in Android 3.0.
Mindestanzahl von Kleinbuchstaben im Passwort	Die Mindestanzahl der im Passwort erforderlichen Kleinbuchstaben für alle Administratoren oder einen bestimmten Administrator. Eingeführt in Android 3.0.
Mindestanzahl von Zeichen, die keine Buchstaben sind, im Passwort erforderlich	Die Mindestanzahl der im Passwort erforderlichen Zeichen, die keine Buchstaben sind, für alle Administratoren oder einen bestimmten Administrator. Eingeführt in Android 3.0.
Mindestanzahl der im Passwort erforderlichen Ziffern	Die Mindestanzahl der im Passwort erforderlichen Ziffern für alle Administratoren oder einen bestimmten Administrator. Eingeführt in Android 3.0.
Mindestanzahl der im Passwort erforderlichen Symbole	Die Mindestanzahl von Symbolen, die im Passwort für alle Administratoren oder einen bestimmten Administrator erforderlich sind. Eingeführt in Android 3.0.
Mindestanzahl von Großbuchstaben im Passwort	Die Mindestanzahl der im Passwort erforderlichen Großbuchstaben für alle Administratoren oder einen bestimmten Administrator. Eingeführt 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 ein Geräteadministrator das Ablaufzeitlimit festlegt. Eingeführt 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 einer bestimmten Zeit zu aktualisieren. Eingeführt in Android 3.0.
Maximale Anzahl falscher Passworteingaben	Gibt an, wie oft ein Nutzer das falsche 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 per Fernzugriff auf die Werkseinstellungen zurücksetzen. So sind die Daten geschützt, falls das Gerät verloren geht oder gestohlen wird.
Sperre nach maximaler Inaktivitätszeit	Legt die Zeitspanne fest, die seit der letzten Berührung des Bildschirms oder dem letzten Drücken einer Taste durch den Nutzer vergeht, bevor das Gerät den Bildschirm sperrt. In diesem Fall müssen Nutzer ihre PIN oder ihr Passwort 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. Eingeführt in Android 3.0.
Kamera deaktivieren	Gibt an, dass die Kamera deaktiviert werden soll. Dies muss keine dauerhafte Deaktivierung sein. Die Kamera kann je nach Kontext, Zeit usw. dynamisch aktiviert oder deaktiviert werden. Eingeführt in Android 4.0.

Weitere Funktionen

Zusätzlich zu den in der obigen Tabelle aufgeführten Richtlinien unterstützt die Device Administration API Folgendes:

• Nutzer auffordern, ein neues Passwort festzulegen.
• Gerät sofort sperren.
• Gerätedaten löschen (Gerät auf die Werkseinstellungen zurücksetzen)

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 (verfügbar über den Android SDK-Manager) und sich auf Ihrem System unter <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 Geräteadministratoren. Sie bietet Nutzern eine Benutzeroberfläche, über die sie die Geräteadministrator-App aktivieren können. Sobald sie die App aktiviert haben, können sie die Schaltflächen in der Benutzeroberfläche für Folgendes verwenden:

• Passwortqualität festlegen
• Geben Sie Anforderungen für das Passwort des Nutzers an, z. B. die Mindestlänge, die Mindestanzahl an numerischen Zeichen, die es enthalten muss, usw.
• 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 die Gerätedaten gelöscht werden, d. h. das Gerät auf die Werkseinstellungen zurückgesetzt wird.
• Legen Sie fest, wie lange das Passwort ab jetzt gültig ist.
• Legen Sie die Anzahl der gemerkten Passwörter fest. Anzahl bezieht sich auf die Anzahl der alten Passwörter, die im Verlauf gespeichert werden. Dadurch wird verhindert, dass Nutzer eines der letzten n Passwörter wiederverwenden, die sie zuvor verwendet haben.
• Geben Sie an, dass der Speicherbereich verschlüsselt werden soll, wenn das Gerät dies unterstützt.
• Legen Sie die maximale Inaktivitätszeit fest, die verstreichen darf, bevor das Gerät gesperrt wird.
• Das Gerät wird sofort gesperrt.
• Gerätedaten löschen (d. h. Werkseinstellungen wiederherstellen)
• Deaktiviere die Kamera.

Abbildung 1. Screenshot der Beispiel-App

App zur Geräteverwaltung entwickeln

Systemadministratoren können die Device Administration API verwenden, um eine App zu schreiben, die die Durchsetzung von Sicherheitsrichtlinien für Remote- und lokale Geräte erzwingt. In diesem Abschnitt werden die Schritte zum Erstellen einer App zur Geräteverwaltung zusammengefasst.

Manifest erstellen

Wenn Sie die Device Administration API verwenden möchten, 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_ENABLED zu reagieren, der im Manifest als Intent-Filter angegeben ist.
• Eine Erklärung der in den Metadaten verwendeten Sicherheitsrichtlinien.

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>

Hinweis:

• Die folgenden Attribute beziehen sich auf String-Ressourcen, die sich für die 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 für Nutzer lesbare Label für die Aktivität.
  • android:label="@string/sample_device_admin" bezieht sich auf das für 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 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 Ihre Geräteadministrator-App missbrauchen.
• android.app.action.DEVICE_ADMIN_ENABLED ist die primäre Aktion, die eine DeviceAdminReceiver-Unterklasse verarbeiten muss, um ein Gerät verwalten zu dürfen. Dies wird für den Empfänger festgelegt, wenn der Nutzer die Geräte-Admin-App aktiviert. Ihr Code verarbeitet dies normalerweise in onEnabled(). Damit der Empfänger unterstützt wird, muss er auch die Berechtigung BIND_DEVICE_ADMIN erfordern, damit andere Apps sie nicht missbrauchen können.
• Wenn ein Nutzer die Geräteadministrator-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 den Nutzer auffordern, ein anderes Passwort auszuwählen, das den Anforderungen entspricht.
• Ändere den Namen des Empfängers nach der Veröffentlichung deiner App nicht. Wenn sich der Name im Manifest ändert, wird die Geräteverwaltung deaktiviert, wenn Nutzer die App aktualisieren. Weitere Informationen findest du unter <receiver>.
• android:resource="@xml/device_admin_sample" deklariert die in den Metadaten verwendeten Sicherheitsrichtlinien. Die Metadaten enthalten zusätzliche Informationen, die für den Geräteadministrator spezifisch sind und von der Klasse DeviceAdminInfo geparst werden. 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 deiner App zur Geräteverwaltung musst du nicht alle Richtlinien einbeziehen, sondern nur die, die für deine App relevant sind.

Weitere Informationen zur Manifestdatei finden Sie im Android-Entwicklerleitfaden.

Code implementieren

Die Device Administration API enthält die folgenden Klassen:

DeviceAdminReceiver

Basisklasse für die Implementierung einer Geräteverwaltungskomponente. Diese Klasse bietet eine einfache Möglichkeit, die vom System gesendeten Intent-Aktionen zu interpretieren. Ihre Geräteverwaltungs-App 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 DeviceAdminReceiver veröffentlicht haben, die der Nutzer derzeit aktiviert hat. Der DevicePolicyManager verwaltet Richtlinien für eine oder mehrere DeviceAdminReceiver-Instanzen

DeviceAdminInfo

Diese Klasse wird verwendet, um Metadaten für eine Geräteadministratorkomponente anzugeben.

Diese Klassen bilden die Grundlage für eine voll funktionsfähige Geräteverwaltungs-App. Im Rest dieses Abschnitts wird beschrieben, wie du die APIs DeviceAdminReceiver und DevicePolicyManager verwendest, um eine Geräteverwaltungs-App zu schreiben.

DeviceAdminReceiver ableiten

Wenn Sie eine Geräteadministrator-App erstellen möchten, 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 auftreten.

In der Unterklasse DeviceAdminReceiver 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 Geräteadministrator-App verarbeiten 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, bleibt sie zwar auf dem Gerät, aber die Richtlinien werden nicht erzwungen und der Nutzer kann die App nicht verwenden.

Der Prozess zum Aktivieren der App beginnt, wenn der Nutzer eine Aktion ausführt, die den Intent ACTION_ADD_DEVICE_ADMIN auslöst. In der Beispiel-App geschieht dies, wenn der Nutzer das Kästchen Enable Admin (Administrator aktivieren) anklickt.

Wenn der Nutzer das Kästchen Enable Admin (Administrator aktivieren) anklickt, wird er aufgefordert, die Admin-App des Geräts zu aktivieren (siehe Abbildung 2).

Abbildung 2: Beispiel-App: App aktivieren

Unten sehen Sie den Code, der ausgeführt wird, wenn der Nutzer das Kästchen Enable Admin (Administrator aktivieren) anklickt. Dadurch wird der Callback onPreferenceChange() ausgelöst. Dieser Callback wird aufgerufen, wenn der Wert dieses Preference vom Nutzer geändert wurde und festgelegt und/oder beibehalten werden soll. Wenn der Nutzer die App aktiviert, ändert sich die Anzeige und der Nutzer wird aufgefordert, die Geräteadministrator-App zu aktivieren (siehe Abbildung 2). Andernfalls ist die Geräteadministrator-App 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) gibt an, dass mDeviceAdminSample (eine DeviceAdminReceiver-Komponente) die Zielrichtlinie ist. Diese Zeile ruft die in Abbildung 2 gezeigte Benutzeroberfläche auf, die Nutzer durch das Hinzufügen des Geräteadministrators zum System führt (oder ihnen ermöglicht, dies abzulehnen).

Wenn die App einen Vorgang ausführen muss, der von der Aktivierung der Geräteadministrator-App abhängt, wird geprüft, ob die App aktiv ist. Dazu wird die Methode DevicePolicyManager isAdminActive() verwendet. Beachten Sie, dass die Methode isAdminActive() von DevicePolicyManager 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 ein Handle für 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
• Gerätesperre einrichten
• Daten löschen

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 Aufgaben im Zusammenhang mit Passwörtern 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 alphabetische (oder andere) Zeichen enthält.

PASSWORD_QUALITY_ALPHANUMERIC

Der Nutzer muss ein Passwort eingeben, das sowohl numerische als auch alphabetische Zeichen (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 ein Passwort, aber es ist egal, welches.

PASSWORD_QUALITY_UNSPECIFIED

Die Richtlinie enthält keine Anforderungen für das Passwort.

So legen Sie beispielsweise die Passwortrichtlinie fest, um ein alphanumerisches Passwort zu erzwingen:

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 die Inhalte des Passworts optimieren können. Sie können beispielsweise eine Richtlinie festlegen, die besagt, dass Passwörter mindestens n Großbuchstaben enthalten müssen. Hier sind die Methoden zur Feinabstimmung des Passwortinhalts:

• setPasswordMinimumLetters()
• setPasswordMinimumLowerCase()
• setPasswordMinimumUpperCase()
• setPasswordMinimumNonLetter()
• setPasswordMinimumNumeric()
• setPasswordMinimumSymbols()

In diesem Snippet wird beispielsweise angegeben, 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 falscher Passworteingaben festlegen

Sie können die maximal zulässige Anzahl fehlgeschlagener Passwortversuche festlegen, bevor das Gerät gelöscht wird (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);

Zeitlimit für den Ablauf des Passworts festlegen

Ab Android 3.0 kannst du mit der Methode setPasswordExpirationTimeout() festlegen, wann ein Passwort abläuft. Dies wird als Delta in Millisekunden ab dem Zeitpunkt angegeben, an dem ein Geräteadministrator das Ablaufzeitlimit festlegt. 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 Verlauf einschränken

Ab Android 3.0 können Sie mit der Methode setPasswordHistoryLength() die Möglichkeit der Nutzer einschränken, alte Passwörter wiederzuverwenden. Diese Methode verwendet den Parameter length, 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 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 einrichten

Sie können die maximale Zeit der Nutzerinaktivität festlegen, 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

Mit der Methode DevicePolicyManagerwipeData() können Sie das Gerät auf die Werkseinstellungen zurücksetzen. Das ist nützlich, wenn das Gerät verloren geht oder gestohlen wird. Oft ist die Entscheidung, das Gerät zu löschen, das Ergebnis bestimmter Bedingungen, die erfüllt sind. Mit setMaximumFailedPasswordsForWipe() können Sie beispielsweise festlegen, dass ein Gerät nach einer bestimmten Anzahl von falschen 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. Das muss nicht dauerhaft sein. Die Kamera kann je nach Kontext, Uhrzeit usw. dynamisch aktiviert oder deaktiviert werden.

Mit der Methode setCameraDisabled() können Sie festlegen, ob die Kamera deaktiviert ist. Mit 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());

Storage-Verschlüsselung

Ab Android 3.0 können Sie mit der Methode setStorageEncryption() eine Richtlinie festlegen, die die Verschlüsselung des Speicherbereichs erfordert, sofern dies 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 Beispiel für die Device Administration API.

Zusätzliche Codebeispiele

Die Beispiele Android AppRestrictionEnforcer und DeviceOwner veranschaulichen die Verwendung der auf dieser Seite behandelten APIs.