Geräteverwaltung – Übersicht

Einstellung der Geräteverwaltung. Ab Android 9 (API-Level 28) werden einige Administratorrichtlinien als verworfen markiert, wenn sie von einem Geräteadministrator aufgerufen werden. Wir empfehlen Ihnen, sich schon jetzt auf diese Änderung vorzubereiten. Weitere Informationen und Informationen zu den Migrationsoptionen finden Sie unter Einstellung von Geräteverwaltung.

Android unterstützt über die Android Device Administration API auch Unternehmens-Apps. Die Device Administration API bietet Geräteverwaltungsfunktionen auf Systemebene. Mit diesen APIs können Sie sicherheitsbewusste Anwendungen erstellen, die für 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 hat diese APIs beispielsweise genutzt, um die Exchange-Unterstützung zu verbessern. Über die E-Mail-App können Exchange-Administratoren Passwortrichtlinien – einschließlich alphanumerischer Passwörter oder numerischer PINs – auf allen Geräten erzwingen. Administratoren können bei verlorenen oder gestohlenen Mobilgeräten auch die Daten auf verloren gegangenen oder gestohlenen Geräten 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, um die Sicherheit für Mitarbeitergeräte mit Android zu erhöhen.

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

Monitorloser Geräteeigentümermodus

Mit Android 14 (API-Level 34) wird der monitorlose Systemnutzermodus für Geräte eingeführt, bei denen UserManager.isHeadlessSystemUserMode true zurückgibt. Im monitorlosen Systemnutzermodus ist der Systemnutzer ein Nutzer im Hintergrund und benötigt zusätzliche Nutzer im Vordergrund für die Endnutzerinteraktion. In Android 14 wird auch ein monitorloser Modus für die Zuordnung von Geräteinhabern eingeführt, bei dem allen verknüpften Nutzern mit Ausnahme des Systemnutzers, für den der Geräteinhaber festgelegt ist, ein Profilinhaber hinzugefügt wird.

Auf Geräten, die mit einem monitorlosen Systemnutzer konfiguriert sind (wo der Systemnutzer im Hintergrund ausgeführt wird), werden nur globale Geräterichtlinien (Richtlinien, die für alle Nutzer gelten) auf den Nutzer oder die Nutzer im Vordergrund angewendet. Weitere Informationen finden Sie unter addUserRestriction.

Hersteller von Android-Geräten können die Anleitung auf source.android.com lesen.

Device Administration API – Übersicht

Im Folgenden finden Sie Beispiele für App-Typen, die die Device Administration API verwenden können:

• E-Mail-Clients
• Sicherheits-Apps, die Daten aus der Ferne löschen können
• Geräteverwaltungsdienste und Apps

Wie funktioniert das?

Mit der Device Administration API können Sie Apps zur Geräteverwaltung schreiben, die Nutzer auf ihren Geräten installieren. Die gewünschten Richtlinien werden von der App zur Geräteverwaltung erzwungen. Dies funktioniert folgendermaßen:

• Ein Systemadministrator schreibt eine Geräteverwaltungs-App, die Sicherheitsrichtlinien für Remote- oder lokale Geräte erzwingt. Diese Richtlinien können in der Anwendung hartcodiert sein oder sie könnten dynamisch Richtlinien von einem Drittanbieterserver abrufen.
• Die App ist auf den Geräten der Nutzer installiert. Android hat derzeit keine Lösung für automatisierte Bereitstellungen. Ein Systemadministrator kann die Anwendung beispielsweise so an Nutzer verteilen:
  • Mit Google Play.
  • Aktivieren der Installation aus einem anderen Speicher
  • Bereitstellung der App über andere Mittel, z. B. per E-Mail oder über Websites.
• Der Nutzer wird vom System aufgefordert, die App zur Geräteverwaltung zu aktivieren. Wie und wann dies geschieht, hängt davon ab, wie die App implementiert ist.
• Sobald Nutzer die App zur Geräteverwaltung aktivieren, unterliegen sie den Richtlinien. Die Einhaltung dieser Richtlinien bietet in der Regel Vorteile, z. B. den Zugriff auf sensible Systeme und Daten.

Wenn Nutzer die App zur Geräteverwaltung nicht aktivieren, bleibt sie auf dem Gerät, jedoch inaktiv. Nutzer unterliegen weder diesen Richtlinien, noch profitieren sie von den Vorteilen der App, z. B. wenn sie keine Daten synchronisieren können.

Wenn ein Nutzer die Richtlinien nicht einhält, z. B. weil er ein gegen die Richtlinien verstoßendes Passwort festlegt, muss die App entscheiden, wie damit umgegangen wird. 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, 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 lässt derzeit keine teilweise Bereitstellung zu. Wenn also ein Gerät (z. B. ein altes Gerät) nicht alle genannten Richtlinien unterstützt, kann das Gerät keine Verbindung herstellen.

Wenn ein Gerät mehrere aktivierte Administrator-Apps enthält, wird die strengste Richtlinie erzwungen. Es gibt keine Möglichkeit, ein Targeting auf eine bestimmte Admin-App festzulegen.

Um eine vorhandene Geräteverwaltungs-App zu deinstallieren, müssen Nutzer zuerst die Registrierung der App als Administrator aufheben.

Richtlinien

In einem Unternehmen müssen die Geräte von Mitarbeitern häufig strengen Richtlinien entsprechen, die die Nutzung des Geräts regeln. Die Device Administration API unterstützt die Richtlinien, die in Tabelle 1 aufgeführt sind. 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

Neben der Unterstützung der in der obigen Tabelle aufgeführten Richtlinien bietet die Device Administration API folgende Möglichkeiten:

• Nutzer auffordern, ein neues Passwort festzulegen.
• Sperre das Gerät sofort.
• Löschen Sie die Gerätedaten, d. h., das Gerät wird auf die Werkseinstellungen zurückgesetzt.

Beispiel-App

Die auf dieser Seite verwendeten Beispiele basieren auf dem Device Administration API-Beispiel, das in den SDK-Beispielen enthalten ist (über den Android SDK Manager erhältlich) und sich auf deinem System als <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java befindet.

Die Beispiel-App enthält eine Demo der Funktionen zur Geräteverwaltung. Nutzer sehen eine Benutzeroberfläche, über die sie die App zur Geräteverwaltung aktivieren können. Nach dem Aktivieren der App können sie über die Schaltflächen auf der Benutzeroberfläche Folgendes tun:

• Passwortqualität festlegen
• Legen Sie Anforderungen für das Nutzerpasswort fest, z. B. die Mindestlänge oder die Mindestanzahl von 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 möglich sind, bevor das Gerät auf die Werkseinstellungen zurückgesetzt wird.
• Legen Sie fest, wie lange das Passwort gültig sein soll.
• Legen Sie die Länge des Passwortverlaufs fest. Die Länge bezieht sich auf die Anzahl der im Verlauf gespeicherten alten Passwörter. Dadurch wird verhindert, dass Nutzer eines der letzten n Passwörter, die sie zuvor verwendet haben, noch einmal verwenden.
• Legen Sie fest, dass der Speicherbereich verschlüsselt werden soll, sofern das Gerät dies unterstützt.
• Legen Sie die maximale Inaktivitätszeit fest, die verstreichen darf, bevor das Gerät gesperrt wird.
• Sperren Sie das Gerät sofort.
• Löschen Sie die Gerätedaten, d. h., stellen Sie die Werkseinstellungen wieder her.
• Deaktivieren Sie die Kamera.

Abbildung 1: Screenshot der Beispiel-App

App zur Geräteverwaltung entwickeln

Systemadministratoren können mit der Device Administration API eine App schreiben, die die Erzwingung von Remote- oder lokalen Gerätesicherheitsrichtlinien erzwingt. In diesem Abschnitt werden die Schritte zum Erstellen einer Anwendung zur Geräteverwaltung zusammengefasst.

Manifest wird erstellt

Damit Sie die Device Administration API verwenden können, muss das Manifest der App Folgendes enthalten:

• Eine abgeleitete Klasse von DeviceAdminReceiver, die Folgendes enthält:
  • Die Berechtigung BIND_DEVICE_ADMIN.
  • Die Möglichkeit, auf den Intent ACTION_DEVICE_ADMIN_ENABLED zu reagieren, der im Manifest als Intent-Filter ausgedrückt wird.
• Eine Deklaration von Sicherheitsrichtlinien, die in Metadaten verwendet werden.

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

<activity android:name=".app.DeviceAdminSample"
            android:label="@string/activity_sample_device_admin">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.SAMPLE_CODE" />
    </intent-filter>
</activity>
<receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver"
        android:label="@string/sample_device_admin"
        android:description="@string/sample_device_admin_description"
        android:permission="android.permission.BIND_DEVICE_ADMIN">
    <meta-data android:name="android.app.device_admin"
            android:resource="@xml/device_admin_sample" />
    <intent-filter>
        <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
    </intent-filter>
</receiver>

Hinweise:

• Die folgenden Attribute beziehen sich auf Stringressourcen, die sich für die Beispielanwendung in ApiDemos/res/values/strings.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 der 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 abgeleitete DeviceAdminReceiver-Klasse haben muss, damit nur das System mit dem Empfänger interagieren kann. Diese Berechtigung kann keiner App gewährt werden. Dadurch wird verhindert, dass andere Apps Ihre Geräteverwaltungs-App missbrauchen.
• android.app.action.DEVICE_ADMIN_ENABLED ist die primäre Aktion, die eine abgeleitete DeviceAdminReceiver-Klasse ausführen muss, um ein Gerät verwalten zu können. Wird auf den Empfänger festgelegt, wenn der Nutzer die Geräteverwaltungs-App aktiviert. Normalerweise übernimmt dein Code dies in onEnabled(). Dazu muss der Empfänger auch die Berechtigung BIND_DEVICE_ADMIN haben, damit andere Apps sie nicht missbrauchen können.
• Wenn ein Nutzer die App zur Geräteverwaltung aktiviert, die dem Empfänger die Berechtigung erteilt, Aktionen als Reaktion auf die Übertragung bestimmter Systemereignisse auszuführen. Wenn ein geeignetes Ereignis eintritt, kann die App eine Richtlinie auferlegen. Wenn der Nutzer beispielsweise versucht, ein neues Passwort festzulegen, das nicht den Richtlinienanforderungen entspricht, kann die Anwendung ihn auffordern, ein anderes Passwort auszuwählen, das den Anforderungen entspricht.
• Ändern Sie den Namen des Empfängers nach dem Veröffentlichen der App nicht. Wenn sich der Name im Manifest ändert, wird der Geräteadministrator deaktiviert, wenn Nutzer die App aktualisieren. Weitere Informationen finden Sie unter <receiver>.
• android:resource="@xml/device_admin_sample" deklariert die in Metadaten verwendeten Sicherheitsrichtlinien. Die Metadaten liefern zusätzliche Informationen, die von der Klasse DeviceAdminInfo geparst werden und für den Geräteadministrator spezifisch sind. 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, nur die, die für Ihre Anwendung relevant sind.

Code implementieren

Die Device Administration API umfasst die folgenden Klassen:

DeviceAdminReceiver

Basisklasse für die Implementierung einer Komponente zur Geräteverwaltung Diese Klasse bietet eine komfortable Möglichkeit zur Interpretation der vom System gesendeten Rohdaten der Intents. Die Geräteverwaltungs-App muss die 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 weiteren Verlauf dieses Abschnitts wird beschrieben, wie Sie die APIs DeviceAdminReceiver und DevicePolicyManager verwenden, um eine App zur Geräteverwaltung zu schreiben.

Abgeleitete Klasse zu DeviceAdminReceiver

Zum Erstellen einer App zur Geräteverwaltung müssen Sie eine abgeleitete Klasse von DeviceAdminReceiver erstellen. Die Klasse DeviceAdminReceiver besteht aus einer Reihe von Callbacks, die ausgelöst werden, wenn bestimmte Ereignisse eintreten.

In ihrer DeviceAdminReceiver-Unterklasse zeigt die Beispiel-App einfach eine Toast-Benachrichtigung als Antwort auf bestimmte Ereignisse an. Beispiele:

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 wird aktiviert

Eines der wichtigsten Ereignisse, die eine Geräteverwaltungs-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, ist sie weiterhin auf dem Gerät vorhanden, aber die Richtlinien werden nicht erzwungen und der Nutzer kann nicht von den Vorteilen der App profitieren.

Die Aktivierung der Anwendung beginnt, wenn der Nutzer eine Aktion ausführt, die den Intent ACTION_ADD_DEVICE_ADMIN auslöst. In der Beispielanwendung geschieht dies, wenn der Nutzer auf das Kästchen Administrator aktivieren klickt.

Wenn der Nutzer auf das Kästchen Administrator aktivieren klickt, ändert sich die Anzeige und er wird aufgefordert, die App zur Geräteverwaltung zu aktivieren (siehe Abbildung 2).

Abbildung 2: Beispiel-App: App aktivieren

Der folgende Code wird ausgeführt, wenn der Nutzer auf das Kästchen Admin aktivieren klickt. Dadurch wird der onPreferenceChange()-Callback ausgelöst. Dieser Callback wird aufgerufen, wenn der Wert für Preference vom Nutzer geändert wurde und jetzt festgelegt und/oder beibehalten wird. Wenn der Nutzer die App aktiviert, ändert sich die Anzeige und er wird aufgefordert, die App zur Geräteverwaltung zu aktivieren (siehe Abbildung 2). Andernfalls ist 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;
}

Die Zeile intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) gibt an, dass mDeviceAdminSample (eine DeviceAdminReceiver-Komponente) die Zielrichtlinie ist. Mit dieser Zeile wird die in Abbildung 2 gezeigte Benutzeroberfläche aufgerufen, über die Nutzer den Geräteadministrator zum System hinzufügen oder ablehnen können.

Wenn die Anwendung einen Vorgang ausführen muss, bei dem die Geräteverwaltungsanwendung aktiviert sein muss, bestätigt sie, dass die Anwendung aktiv ist. Dazu wird die DevicePolicyManager-Methode isAdminActive() verwendet. Die DevicePolicyManager-Methode isAdminActive() verwendet eine DeviceAdminReceiver-Komponente als Argument:

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 einen 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 Verwaltungsaufgaben ausführen:

• Passwortrichtlinien festlegen
• Gerätesperre einrichten
• Daten auf Werkseinstellungen zurücksetzen

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

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);

Qualität von Passwörtern 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 Sonderzeichen) enthält.

PASSWORD_QUALITY_ALPHANUMERIC

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

PASSWORD_QUALITY_NUMERIC

Der Nutzer muss ein Passwort mit mindestens numerischen Zeichen 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

Für die Richtlinie ist ein Passwort erforderlich, aber es ist egal.

PASSWORD_QUALITY_UNSPECIFIED

Die Richtlinie enthält keine Anforderungen an das Passwort.

So würden Sie beispielsweise die Passwortrichtlinie so konfigurieren, dass ein alphanumerisches Passwort erforderlich ist:

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 Passwortinhalte festlegen

Ab Android 3.0 enthält die Klasse DevicePolicyManager Methoden, mit denen Sie den Inhalt des Passworts anpassen können. Beispielsweise können Sie eine Richtlinie festlegen, die besagt, dass Passwörter mindestens n Großbuchstaben enthalten müssen. Hier sind die Methoden, um den Inhalt eines Passworts zu optimieren:

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

Dieses Snippet gibt beispielsweise an, 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);

Minimale Passwortlänge festlegen

Sie können angeben, dass ein Passwort mindestens der angegebenen Mindestlänge entsprechen muss. Beispiele:

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 zulässiger fehlgeschlagener Passworteingaben festlegen, bevor das Gerät gelöscht (d. h. auf die Werkseinstellungen zurückgesetzt wird). Beispiele:

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);

Zeitlimit für Ablauf des Passworts festlegen

Ab Android 3.0 können Sie mit der Methode setPasswordExpirationTimeout() festlegen, wann ein Passwort abläuft, ausgedrückt als Delta in Millisekunden nach dem Festlegen des Ablaufzeitlimits durch den Geräteadministrator. Beispiele:

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 auf Grundlage des Verlaufs einschränken

Ab Android 3.0 können Sie mit der Methode setPasswordHistoryLength() die Möglichkeit der Nutzer einschränken, alte Passwörter wiederzuverwenden. Bei dieser Methode wird ein length-Parameter verwendet, der angibt, wie viele alte Passwörter gespeichert werden. Wenn diese Richtlinie aktiviert ist, können Nutzer kein neues Passwort eingeben, das mit den letzten n Passwörtern übereinstimmt. Dadurch wird verhindert, dass Nutzer immer wieder dasselbe Passwort verwenden. Diese Richtlinie wird normalerweise in Verbindung mit setPasswordExpirationTimeout() verwendet, das Nutzer zwingt, ihre Passwörter nach einer bestimmten Zeit zu aktualisieren.

Dieses Snippet verbietet beispielsweise Nutzern, dass ihre letzten fünf Passwörter noch einmal verwendet werden:

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 Nutzerinaktivität festlegen, der auftreten darf, bevor das Gerät gesperrt wird. Beispiele:

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 anweisen, es sofort zu sperren:

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

DevicePolicyManager dpm;
dpm.lockNow();

Daten auf Werkseinstellungen zurücksetzen

Mit der DevicePolicyManager-Methode wipeData() können Sie das Gerät auf die Werkseinstellungen zurücksetzen. Dies ist nützlich, wenn das Gerät verloren geht oder gestohlen wird. Oftmals werden bestimmte Bedingungen erfüllt, um Gerätedaten zu löschen. Sie können mit setMaximumFailedPasswordsForWipe() beispielsweise festlegen, dass ein Gerät nach einer bestimmten Anzahl fehlgeschlagener Passworteingaben 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. Derzeit muss der Wert 0 sein.

Kamera deaktivieren

Ab Android 4.0 können Sie die Kamera deaktivieren. Dabei muss es sich nicht um eine dauerhafte Deaktivierung handeln. Die Kamera kann je nach Kontext, Zeit usw. dynamisch aktiviert oder deaktiviert werden.

Mit der Methode setCameraDisabled() legen Sie fest, ob die Kamera deaktiviert werden soll. Dieses Snippet legt beispielsweise fest, dass die Kamera basierend auf einer Kästcheneinstellung aktiviert oder deaktiviert wird:

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 diese unterstützt wird.

Beispiele:

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

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setStorageEncryption(deviceAdminSample, true);

Im Beispiel für die Device Administration API finden Sie ein vollständiges Beispiel für die Aktivierung der Speicherverschlüsselung.

Zusätzliche Codebeispiele

In den Beispielen Android AppRestrictionEnforcer und DeviceOwner wird die Verwendung der auf dieser Seite behandelten APIs weiter veranschaulicht.