Geräteverwaltung – Übersicht

Einstellung des Geräteadministrators Ab Android 9 (API-Ebene 28) werden einige Administratorrichtlinien als veraltet markiert, von einem Geräteadministrator aufgerufen wurde. Wir empfehlen Ihnen, sich schon jetzt auf diese Änderung vorzubereiten. Weitere Informationen mehr und mehr über die Migrationsoptionen erfahren Sie unter <ph type="x-smartling-placeholder"></ph> Einstellung des Geräteadministrators

Android unterstützt Unternehmens-Apps, indem es Android Device Administration API Die Device Administration API stellt das Gerät bereit auf Systemebene. Mit diesen APIs können Sie sicherheitsbewusste Apps, die nützlich für Unternehmen sind, in denen die IT Beschäftigte benötigen umfassende Kontrolle über die Geräte ihrer Mitarbeiter. Beispiel: Der Parameter hat die integrierte Android-E-Mail-App diese APIs genutzt, Exchange-Support. Über die E-Mail-App können Exchange-Administratoren Passwortrichtlinien erzwingen, einschließlich alphanumerischer und numerischer Passwörter PINs – geräteübergreifend Administratoren können Daten auch per Remote-Zugriff löschen, verloren gegangenen oder gestohlenen Handys. Exchange-Nutzer können synchronisieren ihre E-Mail- und Kalenderdaten.

Dieses Dokument richtet sich an Entwickler, die für Android-Geräte. Es werden die verschiedenen Funktionen die von der Device Administration API bereitgestellt werden, um Mitarbeitergeräte mit Android-Betriebssystem.

Hinweis: Informationen zum Erstellen von Arbeitsrichtlinien Controller für Android for Work-Bereitstellungen, siehe Device Policy Controller erstellen

Monitorloser Modus für Geräteeigentümer

Mit Android 14 (API-Level 34) wird der monitorlose Systemnutzermodus (Geräte in welche UserManager.isHeadlessSystemUserMode gibt true zurück. Im monitorlosen Systemnutzermodus Hintergrundnutzern und sind auf zusätzliche Nutzer im Vordergrund angewiesen, Interaktion. Mit Android 14 wird außerdem eine Verknüpfungsmodus des monitorlosen Geräteeigentümers Dadurch wird allen Nutzern ein Profilinhaber verknüpfte Nutzer als der Systemnutzer, für den der Geräteeigentümer festgelegt ist.

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

<ph type="x-smartling-placeholder">

</ph> Hinweis: In Android 14 (API-Level 34) kann eine DPC-App so festgelegt werden: Geräteeigentümer auf einem Gerät, das als Geräte mit monitorlosem Systemnutzermodus wenn der Verknüpfungsmodus unterstützt wird. Weitere Informationen finden Sie unter HEADLESS_DEVICE_OWNER_MODE_AFFILIATED .

Hersteller von Android-Geräten verweisen möglicherweise Anleitung die auf source.android.com veröffentlicht wurden.

Übersicht zur Device Administration API

Hier sind Beispiele für die Arten von Apps, die die Device Administration API verwenden können:

• E-Mail-Clients
• Sicherheits-Apps zur Remote-Löschung
• Geräteverwaltungsdienste und -Apps

Wie funktioniert das?

Sie verwenden die Device Administration API, um Geräteverwaltungs-Apps zu schreiben, die Nutzer auf ihren Geräten installieren. Die Geräteverwaltungs-App erzwingt die gewünschte Richtlinien. Dies funktioniert folgendermaßen:

• Ein Systemadministrator schreibt eine App zur Geräteverwaltung, Sicherheitsrichtlinien für Remote-/Lokale Geräte. Diese Richtlinien könnten in Die App kann auch dynamisch Richtlinien von einem Drittanbieter abrufen, Server.
• Die App ist auf dem Geräte. Android kann verfügt derzeit nicht über eine Lösung für die automatische Bereitstellung. Ein Systemadministrator kann die App an Nutzer zu vertreiben: <ph type="x-smartling-placeholder">
  </ph>
  • Mit Google Play.
  • Installation aus einem anderen Speicher wird aktiviert.
  • Die Bereitstellung der App über andere Mittel, z. B. per E-Mail oder über Websites.
• Der Nutzer wird aufgefordert, die App zur Geräteverwaltung zu aktivieren. Wie Wann dies geschieht, hängt davon ab, wie die App implementiert wird.
• Sobald Nutzer die App zur Geräteverwaltung aktiviert haben, seine Richtlinien. Die Einhaltung dieser Richtlinien bringt in der Regel Vorteile mit sich: Zugang zu sensiblen Systemen und Daten.

Wenn Nutzer die App zur Geräteverwaltung nicht aktivieren, bleibt sie auf dem Gerät, jedoch im Status „Inaktiv“. Nutzer unterliegen nicht den Richtlinien und können umgekehrt keine Vorteile der App nutzen, z. B. können sie möglicherweise keine Daten synchronisieren.

Wenn ein Nutzer die Richtlinien nicht einhält, z. B. wenn ein Nutzer eine das gegen die Richtlinien verstößt, liegt die Entscheidung bei der App. wie Sie damit umgehen. In der Regel führt dies jedoch dazu, dass die Nutzenden Daten synchronisieren können.

Wenn ein Gerät versucht, eine Verbindung zu einem Server herzustellen, für den Richtlinien erforderlich sind, in der Device Administration API unterstützt wird, funktioniert die Verbindung nicht zulässig sein. Die Device Administration API ermöglicht derzeit keine teilweisen Nutzerverwaltung. Mit anderen Worten, wenn ein Gerät (z. B. ein älteres Gerät) nicht alle genannten Richtlinien unterstützt, ist es nicht möglich, zu verbindendes Gerät.

Wenn ein Gerät mehrere aktivierte Admin-Apps enthält, ist die strengste Richtlinie durchgesetzt wird. Es gibt keine Möglichkeit, ein Targeting auf einen bestimmten Administrator vorzunehmen

Wenn Nutzer eine bestehende App zur Geräteverwaltung deinstallieren möchten, müssen sie Folgendes tun: die App als Administrator abmelden.

Richtlinien

In Unternehmen müssen die Geräte der Mitarbeiter oft Sie müssen strenge Richtlinien für die Nutzung des Geräts einhalten. Die Die Device Administration API unterstützt die in Tabelle 1 aufgeführten Richtlinien. Beachten Sie, dass die Device Administration API derzeit nur Passwörter für Bildschirm- Schloss:

Tabelle 1 Von der Device Administration API unterstützte Richtlinien.

Richtlinie	Beschreibung
Passwort aktiviert	Bei dieser Einstellung müssen Geräte nach einer PIN oder Passwörtern fragen.
Mindestlänge des Passworts	Legen Sie die erforderliche Anzahl von Zeichen für das Passwort fest. Zum Beispiel haben Sie festlegen, dass PIN oder Passwörter mindestens sechs Zeichen umfassen müssen.
Alphanumerisches Passwort erforderlich	Erfordert, dass Passwörter eine Kombination aus Buchstaben und Zahlen. Sie können symbolische Zeichen enthalten.
Komplexes Passwort erforderlich	Passwörter müssen mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen enthalten. In Android 3.0 eingeführt.
Mindestanzahl der Buchstaben im Passwort erforderlich	Die Mindestanzahl von Buchstaben, die im Passwort für alle Administratoren oder für einen bestimmten Administrator erforderlich sind. In Android 3.0 eingeführt.
Passwort muss mindestens Kleinbuchstaben enthalten	Die Mindestanzahl von Kleinbuchstaben Buchstaben, die im Passwort für alle Administratoren oder für einen bestimmten Administrator erforderlich sind. In Android 3.0 eingeführt.
Passwort muss mindestens Zeichen enthalten, die keine Buchstaben sind	Die Mindestanzahl von Passwörter, die keine Buchstaben sind, sind für alle Administratoren oder für ein bestimmtes Passwort erforderlich. In Android 3.0 eingeführt.
Mindestanzahl der Ziffern im Passwort erforderlich	Die Mindestanzahl an Ziffern, die im Passwort für alle Administratoren oder für einen bestimmten Wert erforderlich sind. In Android 3.0 eingeführt.
Mindestanzahl von Symbolen im Passwort erforderlich	Die Mindestanzahl von Symbolen, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich sind. In Android 3.0 eingeführt.
Passwort muss mindestens Großbuchstaben enthalten	Die Mindestanzahl an Großbuchstaben, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich ist. In Android 3.0 eingeführt.
Zeitlimit für Ablauf des Passworts	Der Zeitpunkt, zu dem das Passwort abläuft, ausgedrückt als Delta in Millisekunden ab dem Zeitpunkt, zu dem der Geräteverwaltungszeitpunkt das Zeitlimit festlegt. In Android 3.0 eingeführt.
Beschränkung des Passwortverlaufs	Diese Richtlinie verhindert, dass Nutzer die letzten n eindeutigen Passwörter wiederverwenden. Diese Richtlinie wird normalerweise in Verbindung mit setPasswordExpirationTimeout(), wodurch die die Nutzer ihre Passwörter nach einer gewissen Zeit aktualisieren können. In Android 3.0 eingeführt.
Maximale Anzahl fehlgeschlagener Passworteingaben	Gibt an, wie oft ein Nutzer ein falsches Passwort eingeben kann, werden die Daten auf dem Gerät gelöscht. Mit der Device Administration API können Administratoren Gerät per Fernzugriff auf die Werkseinstellungen zurücksetzen. So werden Daten geschützt, falls Gerät verloren gegangen ist oder gestohlen wurde.
Maximale Inaktivitätszeitsperre	Legt fest, wie viel Zeit seit dem letzten Berühren des Bildschirms vergangen ist. eine Taste gedrückt haben, bevor das Gerät den Bildschirm sperrt. In diesem Fall können Nutzer müssen ihre PIN oder Passwörter erneut eingeben, bevor sie ihre Geräte verwenden können. auf Daten zugreifen können. Der Wert kann zwischen 1 und 60 Minuten liegen.
Speicherverschlüsselung erforderlich	Gibt an, dass der Speicherbereich verschlüsselt werden soll, wenn das Gerät dies unterstützt. In Android 3.0 eingeführt.
Kamera deaktivieren	Gibt an, dass die Kamera deaktiviert werden soll. Beachten Sie, dass hier keine als dauerhafte Deaktivierung. Die Kamera kann dynamisch aktiviert/deaktiviert werden. je nach Kontext, Zeit usw. In Android 4.0 eingeführt.

Weitere Funktionen

Das Gerät unterstützt nicht nur die in der obigen Tabelle aufgeführten Richtlinien, Mit der Administration API haben Sie folgende Möglichkeiten:

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

Beispiel-App

Die auf dieser Seite verwendeten Beispiele basieren auf der Device Administration API. der in den SDK-Beispielen (verfügbar über die Android SDK Manager) und befinden sich auf Ihrem System als <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java

Die Beispiel-App bietet eine Demo der Funktionen zur Geräteverwaltung. Sie zeigt Nutzenden, über eine Benutzeroberfläche, über die sie die App zur Geräteverwaltung aktivieren können. Einmal aktiviert haben, können sie die Schaltflächen auf der Benutzeroberfläche um Folgendes zu tun:

• Legen Sie die Passwortqualität fest.
• Anforderungen an das Passwort des Nutzers festlegen, z. B. Mindestlänge, numerische Zeichen, die er enthalten muss, usw.
• Legen Sie das Passwort fest. Wenn das Passwort nicht dem angegebenen gibt das System einen Fehler zurück.
• Legen Sie fest, wie viele fehlgeschlagene Passworteingaben passieren können, bevor das Gerät gelöscht wird (d. h. auf die Werkseinstellungen zurückgesetzt).
• Legen Sie fest, wie lange das Passwort ab jetzt abläuft.
• Legen Sie die Länge des Passwortverlaufs fest. Die Länge bezieht sich auf die Anzahl der im Verlauf gespeicherten alten Passwörter. So wird verhindert, dass Nutzer eines der letzten n Passwörter, die sie zuvor verwendet haben.
• Legen Sie fest, dass der Speicherbereich verschlüsselt werden soll, wenn das Gerät dies unterstützt.
• Hier können Sie die maximale Zeit der Inaktivität festlegen, die verstreichen darf, bevor das Gerät beginnt. Schlösser.
• Sperren Sie das Gerät sofort.
• Löschen Sie die Daten des Geräts, d. h., stellen Sie die Werkseinstellungen wieder her.
• Kamera deaktivieren

Abbildung 1: Screenshot der Beispiel-App

Geräteverwaltungs-App entwickeln

Systemadministratoren können die Device Administration API verwenden, um eine App zu schreiben. , die die Erzwingung von Sicherheitsrichtlinien für Remote- oder lokale Geräte erzwingt. Dieser Abschnitt fasst die Schritte zum Erstellen einer Geräteverwaltung zusammen

Manifest erstellen

Damit du die Device Administration API verwenden kannst, muss die Einstellung muss das Manifest Folgendes enthalten:

• Eine abgeleitete Klasse von DeviceAdminReceiver, die Folgendes enthält: <ph type="x-smartling-placeholder">
  </ph>
  • Die Berechtigung BIND_DEVICE_ADMIN.
  • Die Möglichkeit, auf ACTION_DEVICE_ADMIN_ENABLED zu reagieren Intent, ausgedrückt im Manifest als Intent-Filter.
• Eine Deklaration der 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 befinden. ApiDemos/res/values/strings.xml Weitere Informationen zu Ressourcen finden Sie unter Anwendungsressourcen.
  • android:label="@string/activity_sample_device_admin" bezieht sich auf den für Nutzer lesbares Label für die Aktivität.
  • android:label="@string/sample_device_admin" bezieht sich auf den für Nutzer lesbares 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 länger informativ als ein Label.
• android:permission="android.permission.BIND_DEVICE_ADMIN" ist eine Berechtigung, die eine abgeleitete DeviceAdminReceiver-Klasse haben muss Dadurch wird sichergestellt, dass nur das System mit dem Empfänger interagieren kann (keine App kann diese Berechtigung erteilen). Dieses verhindert, dass andere Apps Ihre App zur Geräteverwaltung missbrauchen.
• android.app.action.DEVICE_ADMIN_ENABLED ist die primäre Aktion, die eine abgeleitete DeviceAdminReceiver-Klasse verarbeiten muss, um ein Gerät verwalten darf. Wird auf den Empfänger festgelegt, wenn der Nutzer App zur Geräteverwaltung Ihr Code übernimmt dies normalerweise in onEnabled() Damit dies unterstützt wird, muss der Empfänger auch benötigen die Berechtigung BIND_DEVICE_ADMIN, damit andere Apps darf sie nicht missbrauchen.
• Wenn ein Nutzer die App zur Geräteverwaltung aktiviert, erhält der Empfänger Berechtigung, Aktionen als Reaktion auf die Übertragung eines bestimmten Systems auszuführen Ereignisse. Wenn ein geeignetes Ereignis eintritt, kann die App eine Richtlinie festlegen. Für Beispiel: Der Nutzer versucht, ein neues Passwort festzulegen, das nicht der Richtlinie entspricht. Anforderungen erfüllt, kann die App den Nutzer auffordern, ein anderes Passwort das die Anforderungen erfüllt.
• Ändern Sie den Namen des Empfängers nach der Veröffentlichung Ihrer App nicht. Wenn der Name im Feld Manifeständerungen 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 bieten zusätzliche Informationen, die für den Geräteadministrator spezifisch sind, wie von der Klasse DeviceAdminInfo geparst. Hier sind die Inhalte der 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äteverwaltungs-App müssen Sie alle Richtlinien enthalten, nur die, die für Ihre App relevant sind.

Weitere Informationen zur Manifestdatei finden Sie im Leitfaden für Android-Entwickler.

Code implementieren

Die Device Administration API umfasst die folgenden Klassen:

DeviceAdminReceiver

Basisklasse für die Implementierung einer Komponente zur Geräteverwaltung. Dieser Kurs bietet eine vereinfachte Interpretation der unbearbeiteten Intent-Aktionen, die vom System. Deine Geräteverwaltungs-App muss Folgendes enthalten: DeviceAdminReceiver abgeleitete Klasse.

DevicePolicyManager

Kurs zum Verwalten von Richtlinien, die auf einem Gerät erzwungen werden. Die meisten Kunden von Diese Klasse muss eine DeviceAdminReceiver veröffentlicht haben, die vom Nutzer derzeit aktiviert ist. Über die DevicePolicyManager werden Richtlinien verwaltet für eine oder mehrere DeviceAdminReceiver-Instanzen

DeviceAdminInfo

Mit dieser Klasse werden Metadaten angegeben für eine Geräteadministratorkomponente.

Diese Klassen bilden die Grundlage für eine voll funktionsfähige Geräteverwaltungs-App. Im weiteren Verlauf dieses Abschnitts wird beschrieben, wie Sie DeviceAdminReceiver und DevicePolicyManager APIs zum Schreiben einer Geräteverwaltungs-App.

Abgeleitete Klassen von DeviceAdminReceiver

Um eine Geräteverwaltungs-App zu erstellen, müssen Sie abgeleitete Klassen erstellen DeviceAdminReceiver Klasse DeviceAdminReceiver besteht aus einer Reihe von Callbacks, die ausgelöst werden, wenn bestimmte Ereignisse auftreten.

Die Beispielanwendung in ihrer abgeleiteten DeviceAdminReceiver-Klasse lediglich eine Toast-Benachrichtigung als Antwort auf eine bestimmte Ereignisse. Beispiel:

Kotlin

class DeviceAdminSample : DeviceAdminReceiver() {

    private fun showToast(context: Context, msg: String) {
        context.getString(R.string.admin_receiver_status, msg).let { status ->
            Toast.makeText(context, status, Toast.LENGTH_SHORT).show()
        }
    }

    override fun onEnabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_enabled))

    override fun onDisableRequested(context: Context, intent: Intent): CharSequence =
            context.getString(R.string.admin_receiver_status_disable_warning)

    override fun onDisabled(context: Context, intent: Intent) =
            showToast(context, context.getString(R.string.admin_receiver_status_disabled))

    override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) =
            showToast(context, context.getString(R.string.admin_receiver_status_pw_changed))
...
}

Java

public class DeviceAdminSample extends DeviceAdminReceiver {

    void showToast(Context context, String msg) {
        String status = context.getString(R.string.admin_receiver_status, msg);
        Toast.makeText(context, status, Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onEnabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_enabled));
    }

    @Override
    public CharSequence onDisableRequested(Context context, Intent intent) {
        return context.getString(R.string.admin_receiver_status_disable_warning);
    }

    @Override
    public void onDisabled(Context context, Intent intent) {
        showToast(context, context.getString(R.string.admin_receiver_status_disabled));
    }

    @Override
    public void onPasswordChanged(Context context, Intent intent, UserHandle userHandle) {
        showToast(context, context.getString(R.string.admin_receiver_status_pw_changed));
    }
...
}

Anwendung aktivieren

Eines der wichtigsten Ereignisse, die eine Geräteverwaltungs-App bewältigen muss, die App zu aktivieren. Der Nutzer muss die App explizit für die durchgesetzt werden sollen. Wenn der Nutzer die App nicht aktiviert Es ist weiterhin auf dem Gerät vorhanden, aber die Richtlinien werden nicht erzwungen und der Nutzer die Vorteile der App nutzen können.

Die Aktivierung der Anwendung beginnt, wenn der Nutzer eine Aktion, die den ACTION_ADD_DEVICE_ADMIN auslöst die Nutzerabsicht verstehen. Im Beispiel-App verwendet, geschieht dies, wenn der Nutzer auf die Schaltfläche Aktivieren Admin klicken.

Wenn der Nutzer auf das Kontrollkästchen Admin aktivieren klickt, wird das Display Änderungen an, um den Nutzer aufzufordern, 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 Administrator aktivieren klickt. Dadurch wird das Ereignis onPreferenceChange() Callback des Nutzers an. Dieser Callback wird aufgerufen, wenn der Wert von Preference vom Nutzer geändert wurde und nun festgelegt und/oder beibehalten wird. Wenn der Nutzer die App aktiviert, wird auf dem Display Änderungen an, um den Nutzer aufzufordern, die App zur Geräteverwaltung zu aktivieren (siehe Abbildung). 2. Andernfalls ist die App zur Geräteverwaltung deaktiviert.

Kotlin

override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean {
    if (super.onPreferenceChange(preference, newValue)) return true
    val value = newValue as Boolean
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply {
                    putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample)
                    putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                            activity.getString(R.string.add_admin_extra_app_text))
                }
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN)
                // return false - don't update checkbox until we're really active
                return false
            } else {
                dpm.removeActiveAdmin(deviceAdminSample)
                enableDeviceCapabilitiesArea(false)
                adminActive = false
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value)
    }
    return true
}

Java

@Override
public boolean onPreferenceChange(Preference preference, Object newValue) {
    if (super.onPreferenceChange(preference, newValue)) {
        return true;
    }
    boolean value = (Boolean) newValue;
    if (preference == enableCheckbox) {
        if (value != adminActive) {
            if (value) {
                // Launch the activity to have the user enable our admin.
                Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
                intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample);
                intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,
                        activity.getString(R.string.add_admin_extra_app_text));
                startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN);
                // return false - don't update checkbox until we're really active
                return false;
            } else {
                dpm.removeActiveAdmin(deviceAdminSample);
                enableDeviceCapabilitiesArea(false);
                adminActive = false;
            }
        }
    } else if (preference == disableCameraCheckbox) {
        dpm.setCameraDisabled(deviceAdminSample, value);
    }
    return true;
}

Die Linie intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample) gibt an, dass mDeviceAdminSample (also DeviceAdminReceiver-Komponente) ist die Zielrichtlinie. Mit dieser Zeile wird die in Abbildung 2 gezeigte Benutzeroberfläche aufgerufen. Hinzufügen des Geräteadministrators zum System oder Ablehnen des Geräteadministrators

Wenn die App einen Vorgang ausführen muss, der von der App zur Geräteverwaltung aktiviert, wird bestätigt, dass die App aktiv ist. Dazu wird die Methode DevicePolicyManager verwendet. isAdminActive(). Beachten Sie, dass die DevicePolicyManager isAdminActive()-Methode einen DeviceAdminReceiver-Wert -Komponente als Argument an:

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 Person oder mehr DeviceAdminReceiver-Instanzen.

So erhalten Sie einen Handle für DevicePolicyManager:

Kotlin

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

Java

DevicePolicyManager dpm =
    (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);

In diesem Abschnitt wird beschrieben, wie Sie mit DevicePolicyManager Verwaltungsaufgaben:

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

Passwortrichtlinien festlegen

DevicePolicyManager enthält APIs zum Festlegen und Erzwingen der Gerätepasswort-Richtlinie. In der Device Administration API gilt das Passwort nur für Displaysperre. In diesem Abschnitt werden häufige passwortbezogene Aufgaben beschrieben.

Passwort für das Gerät festlegen

Mit diesem Code wird eine Benutzeroberfläche angezeigt, auf der der Nutzer aufgefordert wird, ein Passwort festzulegen:

Kotlin

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

Java

Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD);
startActivity(intent);

Passwortqualität festlegen

Die Passwortqualität kann eine der folgenden DevicePolicyManager-Konstanten sein:

PASSWORD_QUALITY_ALPHABETIC

Der Nutzer muss eine Das Passwort, das mindestens Buchstaben (oder ein anderes Symbol) enthält.

PASSWORD_QUALITY_ALPHANUMERIC

Der Nutzer muss eine das Passwort mindestens sowohl numerische als auch Buchstaben (oder andere Symbole).

PASSWORD_QUALITY_NUMERIC

Der Nutzer muss ein Passwort eingeben mit mindestens numerischen Zeichen.

PASSWORD_QUALITY_COMPLEX

Der Nutzer muss ein Passwort eingegeben haben, das mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen.

PASSWORD_QUALITY_SOMETHING

Die irgendeine Art von eines Passworts, aber es spielt keine Rolle, was es ist.

PASSWORD_QUALITY_UNSPECIFIED

Die Richtlinie enthält keine Anforderungen an das Passwort.

So können Sie beispielsweise die Passwortrichtlinie so einstellen, dass ein alphanumerisches Passwort erforderlich ist:

Kotlin

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

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);

Anforderungen an den Inhalt von Passwörtern festlegen

Ab Android 3.0 wird die DevicePolicyManager-Klasse verwendet. enthält Methoden, mit denen Sie den Inhalt des Passworts optimieren können. Für Sie können beispielsweise eine Richtlinie festlegen, die besagt, dass Passwörter mindestens n Großbuchstaben. Mit den folgenden Methoden können Sie Inhalt:

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

Dieses Snippet besagt beispielsweise, dass das Passwort mindestens zwei Großbuchstaben enthalten muss:

Kotlin

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

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwMinUppercase = 2;
...
dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);

Mindestlänge des Passworts festlegen

Sie können festlegen, dass ein Passwort mindestens dem angegebenen Minimum entsprechen muss. Länge. Beispiel:

Kotlin

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

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
int pwLength;
...
dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);

Maximale Anzahl fehlgeschlagener Passworteingaben festlegen

Sie können die maximal zulässige Anzahl fehlgeschlagener Passworteingaben festlegen, werden alle Daten auf dem Gerät gelöscht, d. h. auf die Werkseinstellungen zurückgesetzt. Beispiel:

Kotlin

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

Java

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

Zeitlimit für Ablauf des Passworts festlegen

Ab Android 3.0 können Sie die setPasswordExpirationTimeout() Methode zum Festlegen, wann ein Passwort abläuft, ausgedrückt als Delta in Millisekunden ab dem Zeitpunkt, an dem ein Geräteadministrator das Ablaufdatum 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 dem Verlauf einschränken

Ab Android 3.0 können Sie die setPasswordHistoryLength() Methode zum Einschränken der die Möglichkeit, alte Passwörter wiederzuverwenden. Diese Methode verwendet eine length der angibt, wie viele alte Passwörter gespeichert werden. Wenn diese Richtlinie aktiv ist, können Nutzer keine neue Passwort, das mit den letzten n Passwörtern übereinstimmt. Dadurch wird verhindert, dass Nutzer immer wieder dasselbe Passwort verwenden. Diese Richtlinie wird in der Regel in Verbindung mit setPasswordExpirationTimeout(), die Nutzende zwingt, um ihre Passwörter nach einer gewissen Zeit zu aktualisieren.

Das Snippet verhindert beispielsweise, dass Nutzer ihre letzten fünf Passwörter wiederverwenden:

Kotlin

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

Java

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

Gerätesperre einrichten

Sie können festlegen, wie lange ein Nutzer maximal inaktiv sein darf, bevor Gerätesperren. Beispiel:

Kotlin

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

Java

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

Sie können das Gerät auch programmatisch anweisen, es sofort zu sperren:

Kotlin

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

Java

DevicePolicyManager dpm;
dpm.lockNow();

Daten löschen

Sie können die Methode DevicePolicyManager verwenden wipeData(), um das Gerät auf die Werkseinstellungen zurückzusetzen. Hilfreich wenn das Gerät verloren geht oder gestohlen wird. Häufig liegt die Entscheidung zum Löschen der Gerätedaten wenn bestimmte Bedingungen erfüllt sind. So können Sie beispielsweise setMaximumFailedPasswordsForWipe(), um anzugeben, dass ein Gerät die nach einer bestimmten Anzahl fehlgeschlagener Passworteingaben gelöscht wurden.

So löschen Sie Daten:

Kotlin

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

Java

DevicePolicyManager dpm;
dpm.wipeData(0);

Die Methode wipeData() übernimmt eine Bitmaske mit zusätzlichen Optionen. Derzeit muss der Wert 0 sein.

Kamera deaktivieren

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

Sie können festlegen, ob die Kamera deaktiviert werden soll, indem Sie die setCameraDisabled()-Methode. Mit diesem Snippet wird die Kamera beispielsweise anhand eines Kästchens aktiviert oder deaktiviert:

Kotlin

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

Java

private CheckBoxPreference disableCameraCheckbox;
DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());

Speicherverschlüsselung

Ab Android 3.0 können Sie die setStorageEncryption() Methode zum Festlegen einer Richtlinie, die die Verschlüsselung des Speicherbereichs erfordert, sofern diese unterstützt wird.

Beispiel:

Kotlin

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

Java

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

Ein vollständiges Beispiel für die Aktivierung der Speicherverschlüsselung finden Sie im Device Administration API-Beispiel.

Zusätzliche Codebeispiele

Android AppRestrictionEnforcer und DeviceOwner in den Beispielen mehr über die Verwendung der auf dieser Seite behandelten APIs.