Geräteverwaltung – Übersicht

Einstellung von Device Admin Ab Android 9 (API-Level 28) werden einige Administratorrichtlinien als eingestellt 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 der Geräteadministrator-API.

Android bietet Unterstützung für 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 umfassende Kontrolle über Mitarbeitergeräte 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 auf allen Geräten erzwingen, z. B. alphanumerische Passwörter oder numerische PINs. Administratoren können verlorene oder gestohlene Smartphones auch per Remotezugriff auf die Werkseinstellungen zurücksetzen. Exchange-Nutzer können ihre E‑Mail- und Kalenderdaten synchronisieren.

Dieses Dokument richtet sich an Entwickler, die Unternehmenslösungen für Android-Geräte entwickeln möchten. Darin werden die verschiedenen Funktionen der Geräteadministrator-API beschrieben, die für eine höhere Sicherheit von Mitarbeitergeräten mit Android 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“ für Geräte ohne Bildschirm

Mit Android 14 (API-Level 34) wird der Headless System User-Modus eingeführt (Geräte, auf denen UserManager.isHeadlessSystemUserMode true zurückgibt). Im Headless System User-Modus ist der Systemnutzer ein Hintergrundnutzer und für die Endnutzerinteraktion auf zusätzliche Vordergrundnutzer angewiesen. Mit Android 14 wird auch ein Modus für verbundene Geräte ohne Display eingeführt, in dem allen verbundenen Nutzern außer dem Systemnutzer, für den der Geräteeigentümer festgelegt ist, ein Profilinhaber hinzugefügt wird.

Auf Geräten, die mit einem Headless-Systemnutzer konfiguriert sind (auf denen der Systemnutzer im Hintergrund ausgeführt wird), werden nur Geräte-Richtlinien, die global gelten (Richtlinien, die für alle Nutzer gelten), auf den Vordergrundnutzer oder die Vordergrundnutzer angewendet. Weitere Informationen finden Sie unter addUserRestriction.

Hersteller von Android-Geräten können sich an die auf source.android.com veröffentlichten Richtlinien halten.

Geräteverwaltungs-API – Übersicht

Hier sind Beispiele für App-Typen, die die Device Administration API verwenden könnten:

• E-Mail-Clients
• Sicherheits-Apps, die das Löschen von Daten aus der Ferne ermöglichen
• Dienste und Apps zur Geräteverwaltung.

Wie funktioniert das?

Mit der Device Administration API können Sie Geräteadministrator-Apps schreiben, die Nutzer auf ihren Geräten installieren. Die Geräteadministrator-App erzwingt die gewünschten Richtlinien. Das funktioniert so:

• Ein Systemadministrator schreibt eine Geräteadministrator-App, die Sicherheitsrichtlinien für Geräte (remote/lokal) 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. Derzeit gibt es für Android keine automatisierte Bereitstellungslösung. Einige Möglichkeiten, wie ein Systemadministrator die App an Nutzer verteilen kann, sind folgende:
  • Mit Google Play.
  • Installation aus einem anderen Shop aktivieren
  • Die App wird auf andere Weise vertrieben, z. B. per E-Mail oder über Websites.
• 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äteadministrator-App aktivieren, unterliegen sie den zugehörigen 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. Nutzer unterliegen nicht den Richtlinien der App und profitieren umgekehrt auch nicht von den Vorteilen der App, z. B. der Möglichkeit, Daten zu synchronisieren.

Wenn ein Nutzer die Richtlinien nicht einhält (z. B. wenn er ein Passwort festlegt, das gegen die Richtlinien verstößt), liegt es an der App, wie damit umgegangen wird. In der Regel kann der Nutzer dann jedoch keine Daten 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 unterstützt derzeit keine teilweise Bereitstellung. Wenn ein Gerät (z. B. ein altes Gerät) nicht alle angegebenen Richtlinien unterstützt, kann es keine Verbindung herstellen.

Wenn auf einem Gerät mehrere Administrator-Apps aktiviert sind, wird die strengste Richtlinie erzwungen. Es ist nicht möglich, eine bestimmte Administrator-App als Ziel zu verwenden.

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

Richtlinien

In einem Unternehmensumfeld müssen Mitarbeitergeräte häufig strengen Richtlinien entsprechen, die die Verwendung 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.

Weitere Funktionen

Zusätzlich zu den in der obigen Tabelle aufgeführten Richtlinien können Sie mit der Device Administration API Folgendes tun:

• Nutzer auffordern, ein neues Passwort festzulegen.
• Gerät sofort sperren
• Löschen Sie die Daten des Geräts (d. h. setzen Sie das Gerät auf die Werkseinstellungen zurück).

Beispiel-App

Die auf dieser Seite verwendeten Beispiele basieren auf dem Beispiel für die Geräteadministrations-API, das in den SDK-Beispielen (verfügbar über den Android SDK Manager) enthalten ist 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 Geräteadministratorfunktionen. Nutzer sehen eine Benutzeroberfläche, über die sie die Geräteadministrator-App aktivieren können. Nachdem sie die App aktiviert haben, können sie über die Schaltflächen in der Benutzeroberfläche Folgendes tun:

• Passwortqualität festlegen
• Geben Sie Anforderungen für das Passwort des Nutzers an, z. B. die Mindestlänge und die Mindestanzahl der numerischen Zeichen, die es 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 falsche Passworteingaben erfolgen dürfen, bevor das Gerät gelöscht (d. h. auf die Werkseinstellungen zurückgesetzt) wird.
• Legen Sie fest, wie lange das Passwort noch gültig sein soll.
• Legen Sie die Länge des Passwortverlaufs fest (length 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, sofern das Gerät dies unterstützt.
• Legen Sie fest, wie lange das Gerät inaktiv sein kann, bevor es gesperrt wird.
• Das Gerät wird sofort gesperrt.
• Löschen Sie die Daten des Geräts (d. h. stellen Sie die Werkseinstellungen wieder her).
• Deaktiviere die Kamera.

Abbildung 1: Screenshot der Beispiel-App

App zur Geräteverwaltung entwickeln

Systemadministratoren können mit der Device Administration API eine App schreiben, die die Durchsetzung von Sicherheitsrichtlinien für Geräte (remote/lokal) erzwingt. In diesem Abschnitt werden die Schritte zum Erstellen einer App zur Geräteadministration zusammengefasst.

Manifest erstellen

Wenn Sie die Device Administration API verwenden möchten, muss das Manifest der App Folgendes enthalten:

• Eine Unterklasse 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 Metadaten verwendeten Sicherheitsrichtlinien.

Hier ist ein Auszug aus dem Beispielmanifest für die Geräteadministration:

<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 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 Receiver interagieren kann. Keine App kann diese Berechtigung erhalten. Dadurch wird verhindert, dass andere Apps Ihre App zur Geräteverwaltung 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. Diese wird auf den Empfänger festgelegt, wenn der Nutzer die Geräteadministrator-App aktiviert. In der Regel wird dies in Ihrem Code in onEnabled() behandelt. Damit die Berechtigung unterstützt wird, muss der Empfänger auch die Berechtigung BIND_DEVICE_ADMIN benötigen, damit sie nicht von anderen Apps missbraucht werden kann.
• Wenn ein Nutzer die Geräteadministrator-App aktiviert, erhält der Receiver die Berechtigung, Aktionen als Reaktion auf die Übertragung bestimmter Systemereignisse auszuführen. Wenn ein geeignetes Ereignis eintritt, kann die App eine Richtlinie durchsetzen. 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 den Anforderungen entspricht.
• Ändern Sie den Empfängernamen nach der Veröffentlichung Ihrer App nicht. Wenn sich der Name im Manifest ändert, wird die Geräteadministration deaktiviert, wenn Nutzer die App aktualisieren. Weitere Informationen finden Sie 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 Ihrer Geräteadministrator-App müssen Sie nicht alle Richtlinien einbeziehen, sondern nur die, die für Ihre App relevant sind.

Code implementieren

Die Device Administration API umfasst die folgenden Klassen:

DeviceAdminReceiver

Basisklasse zum Implementieren einer Geräteverwaltungskomponente. Diese Klasse bietet eine praktische Möglichkeit, die vom System gesendeten Roh-Intent-Aktionen zu interpretieren. Ihre Geräteadministrator-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äteadministrator-Komponente anzugeben.

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

DeviceAdminReceiver ableiten

Wenn Sie eine Geräteadministrator-App erstellen möchten, müssen Sie eine Unterklasse von DeviceAdminReceiver erstellen. Die Klasse DeviceAdminReceiver besteht aus einer Reihe von Rückrufen, die ausgelöst werden, wenn bestimmte Ereignisse eintreten.

In der DeviceAdminReceiver-Unterklasse der Beispiel-App wird als Reaktion auf bestimmte Ereignisse einfach eine Toast-Benachrichtigung angezeigt. Beispiel:

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))
...
}

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 durchgesetzt werden können. 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 die Vorteile der App nicht nutzen.

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 Administrator aktivieren anklickt, wird die Anzeige geändert und der Nutzer wird aufgefordert, die Geräteadministrator-App zu aktivieren (Abbildung 2).

Abbildung 2: Beispiel-App: 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 festgelegt und/oder gespeichert werden soll. Wenn der Nutzer die App aktiviert, ändert sich die Anzeige und der Nutzer wird aufgefordert, die App zur Geräteverwaltung zu aktivieren (siehe Abbildung 2). Andernfalls wird die App zur Geräteverwaltung deaktiviert.

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
}

@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. Mit dieser Zeile wird die Benutzeroberfläche aufgerufen, die in Abbildung 2 dargestellt ist. Sie führt Nutzer durch das Hinzufügen des Geräteadministrators zum System (oder ermöglicht es ihnen, das Hinzufügen abzulehnen).

Wenn die App einen Vorgang ausführen muss, der davon abhängt, dass die Geräteadministrator-App aktiviert ist, wird bestätigt, dass die App aktiv ist. Dazu wird die Methode DevicePolicyManager isAdminActive() verwendet. Beachten Sie, dass die Methode DevicePolicyManager isAdminActive() eine DeviceAdminReceiver-Komponente als Argument verwendet:

private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)

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 ein Handle für DevicePolicyManager:

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

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 Gerätepasswortrichtlinie. 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

Dieser Code zeigt eine Benutzeroberfläche an, in der der Nutzer aufgefordert wird, ein Passwort festzulegen:

Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}

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 Zeichen (oder andere Symbole) enthält.

PASSWORD_QUALITY_ALPHANUMERIC

Der Nutzer muss ein Passwort eingeben, das mindestens sowohl numerische als auch alphabetische (oder andere Symbol-)Zeichen enthält.

PASSWORD_QUALITY_NUMERIC

Der Nutzer muss ein Passwort mit mindestens Ziffern eingeben.

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 an das Passwort.

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

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)

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. Sie können beispielsweise eine Richtlinie festlegen, die besagt, dass Passwörter mindestens n Großbuchstaben enthalten müssen. So können Sie den Inhalt eines Passworts optimieren:

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

In diesem Snippet wird beispielsweise festgelegt, dass das Passwort mindestens zwei Großbuchstaben enthalten muss:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwMinUppercase = 2
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)

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:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwLength: Int = ...
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)

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 wird (d. h. auf die Werkseinstellungen zurückgesetzt wird). Beispiel:

val dPM:DevicePolicyManager
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val maxFailedPw: Int = ...
...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int maxFailedPw;
 ...
dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);

Zeitüberschreitung für den Ablauf des Passworts festlegen

Ab Android 3.0 können Sie mit der Methode setPasswordExpirationTimeout() festlegen, wann ein Passwort abläuft. Die Angabe erfolgt als Delta in Millisekunden ab dem Zeitpunkt, zu dem ein Geräteadministrator das Ablauf-Timeout festlegt. Beispiel:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwExpiration: Long = ...
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)

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, ob 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 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:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwHistoryLength = 5
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwHistoryLength = 5;
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);

Gerätesperre einrichten

Sie können den maximalen Zeitraum der Inaktivität festlegen, der auftreten kann, bevor das Gerät gesperrt wird. Beispiel:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val timeMs: Long = 1000L * timeout.text.toString().toLong()
...
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
long timeMs = 1000L*Long.parseLong(timeout.getText().toString());
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);

Sie können das Gerät auch programmatisch sofort sperren lassen:

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

DevicePolicyManager dpm;
dpm.lockNow();

Daten löschen

Sie können das Gerät mit der DevicePolicyManager-MethodewipeData() auf die Werkseinstellungen zurücksetzen. Das ist nützlich, wenn das Gerät verloren gegangen oder gestohlen worden ist. Die Entscheidung, das Gerät zu löschen, ist oft das Ergebnis bestimmter Bedingungen. Sie können beispielsweise setMaximumFailedPasswordsForWipe() verwenden, um anzugeben, dass ein Gerät nach einer bestimmten Anzahl fehlgeschlagener Passwortversuche gelöscht werden soll.

So löschen Sie Daten:

private lateinit var dpm: DevicePolicyManager
dpm.wipeData(0)

DevicePolicyManager dpm;
dpm.wipeData(0);

Die Methode wipeData() verwendet als Parameter eine Bitmaske mit zusätzlichen Optionen. Der Wert muss derzeit 0 sein.

Kamera deaktivieren

Ab Android 4.0 können Sie die Kamera deaktivieren. Das muss nicht unbedingt eine dauerhafte Deaktivierung sein. Die Kamera kann je nach Kontext, Uhrzeit usw. dynamisch aktiviert oder deaktiviert werden.

Sie können mit der Methode setCameraDisabled() festlegen, ob die Kamera deaktiviert ist. In diesem Snippet wird die Kamera beispielsweise basierend auf einer Checkbox-Einstellung aktiviert oder deaktiviert:

private lateinit var disableCameraCheckbox: CheckBoxPreference
private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)

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 eine Verschlüsselung des Speicherbereichs erfordert, sofern dies unterstützt wird.

Beispiel:

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
...
dpm.setStorageEncryption(deviceAdminSample, true)

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.