Einstellung von Device Admin Ab Android 9 (API-Ebene 28) werden einige Administratorrichtlinien als eingestellt gekennzeichnet, wenn sie von einem Geräteadministrator aufgerufen werden. Wir empfehlen Ihnen, sich jetzt auf diese Änderung vorzubereiten. Weitere Informationen und Migrationsoptionen finden Sie unter Einstellung der Geräteverwaltung.
Android unterstützt Unternehmens-Apps, indem es Android Device Administration API Die Device Administration API bietet Funktionen zur Geräteverwaltung 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 – einschließlich alphanumerischer Passwörter oder numerischer PINs – geräteübergreifend erzwingen. 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. Darin werden die verschiedenen Funktionen der Device Administration API beschrieben, die für eine bessere Sicherheit von Android-Geräten von Mitarbeitern sorgen.
Hinweis: Informationen zum Erstellen 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
.
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, die Daten aus der Ferne löschen
- Dienste und Apps zur Geräteverwaltung
Wie funktioniert das?
Sie verwenden die Device Administration API, um Geräteverwaltungs-Apps zu schreiben, die Nutzer auf ihren Geräten installieren. Die Device Policy App erzwingt die gewünschten Richtlinien. Das funktioniert so:
- Ein Systemadministrator schreibt eine App für Geräteadministratoren, die Sicherheitsrichtlinien für Remote-/lokale Geräte erzwingt. Diese Richtlinien könnten in Die App kann auch dynamisch Richtlinien von einem Drittanbieter abrufen, Server.
- Die App ist auf dem Geräte. Android bietet derzeit keine automatisierte Bereitstellungslösung. Ein Systemadministrator kann
die App an Nutzer zu vertreiben:
- Mit Google Play.
- Installation aus einem anderen Speicher wird aktiviert.
- Die App über andere Kanäle wie E-Mails oder Websites vertreiben.
- Das System fordert den Nutzer auf, die App zur Geräteverwaltung zu aktivieren. Wie und wann dies geschieht, hängt davon ab, wie die App implementiert ist.
- Sobald Nutzer die App zur Geräteverwaltung aktiviert haben, seine Richtlinien. Die Einhaltung dieser Richtlinien bietet in der Regel Vorteile, z. B. Zugriff auf sensible Systeme und Daten.
Wenn Nutzer die App für die Geräteverwaltung nicht aktivieren, bleibt sie auf dem Gerät, ist aber inaktiv. Für Nutzer gelten dann nicht die Richtlinien von Google und sie können auch keine Vorteile der App nutzen. So können sie beispielsweise keine Daten synchronisieren.
Wenn ein Nutzer die Richtlinien nicht einhält (z. B. ein Passwort festlegt, das gegen die Richtlinien verstößt), liegt es in der Entscheidung der App, wie damit umgegangen wird. In der Regel 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, die in der Device Administration API nicht unterstützt werden, wird die Verbindung nicht zugelassen. Die Device Administration API ermöglicht derzeit keine teilweise Bereitstellung. Wenn ein Gerät (z. B. ein älteres Gerät) also nicht alle angegebenen Richtlinien unterstützt, kann es keine Verbindung herstellen.
Wenn ein Gerät mehrere aktivierte Administrator-Apps enthält, wird die strengste Richtlinie erzwungen. Es gibt keine Möglichkeit, 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 Mitarbeitergeräte häufig strengen Richtlinien zur Nutzung des Geräts entsprechen. Die Die Device Administration API unterstützt die in Tabelle 1 aufgeführten Richtlinien. Die Device Administration API unterstützt derzeit nur Passwörter für die Displaysperre:
Tabelle 1 Von der Device Administration API unterstützte Richtlinien.
| Richtlinie | Beschreibung |
|---|---|
| Passwort aktiviert | 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. Sie können beispielsweise festlegen, dass PINs oder Passwörter mindestens sechs Zeichen lang sein müssen. |
| Alphanumerisches Passwort erforderlich | Erfordert, dass Passwörter ein eine Kombination aus Buchstaben und Zahlen. Sie können auch Symbole 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. |
| Mindestanzahl der Kleinbuchstaben im Passwort | Die Mindestanzahl an Kleinbuchstaben, die für alle Administratoren oder einen bestimmten Administrator im Passwort erforderlich sind. Einführung in Android 3.0. |
| Mindestanzahl der Zeichen im Passwort, die keine Buchstaben sind | Die Mindestanzahl 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 | 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 an Symbolen im Passwort | Die Mindestanzahl von Symbolen, die das Passwort für alle Administratoren oder einen bestimmten Administrator enthalten muss. Einführung in Android 3.0. |
| Passwort muss mindestens einen Großbuchstaben enthalten | Die Mindestanzahl an Großbuchstaben, die im Passwort für alle Administratoren oder für ein bestimmtes Passwort erforderlich ist. Einführung in Android 3.0. |
| Zeitlimit für Ablauf des Passworts | Der Zeitpunkt, zu dem das Passwort abläuft, ausgedrückt als Delta in Millisekunden ab dem Zeitpunkt, zu dem der Geräteverwaltungszeitpunkt das Zeitlimit festlegt. 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 das Gerät auch 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 erzwingen | 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 oder deaktiviert werden, je nach Kontext, Uhrzeit usw. In Android 4.0 eingeführt. |
Weitere Funktionen
Zusätzlich zu den in der Tabelle oben aufgeführten Richtlinien können Sie mit der Device Administration API Folgendes tun:
- 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 für die Geräteverwaltung. Sie bietet Nutzern eine Benutzeroberfläche, über die sie die Geräteverwaltungs-App aktivieren können. Nachdem sie die App aktiviert haben, können sie über die Schaltflächen auf der Benutzeroberfläche Folgendes tun:
- Legen Sie die Passwortqualität fest.
- Geben Sie Anforderungen für das Passwort des Nutzers an, z. B. die Mindestlänge und die Mindestanzahl an Ziffern.
- Legen Sie das Passwort fest. Wenn das Passwort nicht dem angegebenen gibt das System einen Fehler zurück.
- Legen Sie fest, wie viele falsche Passworteingaben zulässig sind, bevor das Gerät gelöscht (d. h. auf die Werkseinstellungen zurückgesetzt) wird.
- Legen Sie fest, 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.
- Legen Sie fest, wie lange das Gerät maximal inaktiv sein darf, bevor es gesperrt wird.
- Sperren Sie das Gerät sofort.
- Löschen Sie die Daten auf dem Gerät, d. h. setzen Sie es auf die Werkseinstellungen zurück.
- Deaktivieren Sie die Kamera.
Abbildung 1: Screenshot der Beispiel-App
App zur Geräteverwaltung entwickeln
Systemadministratoren können die Device Administration API verwenden, um eine App zu schreiben. , die die Erzwingung von Sicherheitsrichtlinien für Remote- oder lokale Geräte erzwingt. In diesem Abschnitt werden die Schritte zum Erstellen einer App zur Geräteverwaltung zusammengefasst.
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:- Die Berechtigung
BIND_DEVICE_ADMIN. - Die Möglichkeit, auf
ACTION_DEVICE_ADMIN_ENABLEDzu reagieren Intent, ausgedrückt im Manifest als Intent-Filter.
- Die Berechtigung
- Eine Deklaration von Sicherheitsrichtlinien, die in Metadaten verwendet werden.
Hier ein Auszug aus dem Beispielmanifest für die Geräteverwaltung:
<activity android:name=".app.DeviceAdminSample" android:label="@string/activity_sample_device_admin"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.SAMPLE_CODE" /> </intent-filter> </activity> <receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver" android:label="@string/sample_device_admin" android:description="@string/sample_device_admin_description" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin_sample" /> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver>
Hinweise:
- Die folgenden Attribute beziehen sich auf Stringressourcen, die sich in der Beispiel-App in
ApiDemos/res/values/strings.xmlbefinden. 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 das nutzerlesbare Label für die Berechtigung.android:description="@string/sample_device_admin_description"bezieht sich auf die für Nutzer lesbare Beschreibung der Berechtigung. Eine Beschreibung ist in der Regel länger und informativer als ein Label.
android:permission="android.permission.BIND_DEVICE_ADMIN"ist eine Berechtigung, die eineDeviceAdminReceiver-Unterklasse haben muss, damit nur das System mit dem Empfänger interagieren kann. Diese Berechtigung kann keiner App gewährt werden. So wird verhindert, dass andere Apps Ihre App zur Geräteverwaltung missbrauchen.android.app.action.DEVICE_ADMIN_ENABLEDist die primäre Aktion, die eineDeviceAdminReceiver-Unterklasse verarbeiten muss, um Geräte verwalten zu dürfen. Dieser wird auf den Empfänger festgelegt, wenn der Nutzer die Geräteverwaltungs-App aktiviert. In Ihrem Code wird dies normalerweise inonEnabled()verarbeitet. Damit die Funktion unterstützt wird, muss der Empfänger auch die BerechtigungBIND_DEVICE_ADMINbenötigen, damit andere Apps sie nicht missbrauchen können.- Wenn ein Nutzer die App „Geräteverwaltung“ aktiviert, erhält der Empfänger die Berechtigung, Aktionen als Reaktion auf die Übertragung bestimmter Systemereignisse auszuführen. Wenn ein geeignetes Ereignis eintritt, kann die App eine Richtlinie erzwingen. 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 enthalten zusätzliche Informationen, die sich speziell auf den Geräteadministrator beziehen und von der KlasseDeviceAdminInfogeparst werden. Hier sind die Inhalte derdevice_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>
Bei der Entwicklung Ihrer App zur Geräteverwaltung müssen Sie nicht alle Richtlinien einbeziehen, sondern nur die, die für Ihre App relevant sind.
Weitere Informationen zur Manifestdatei finden Sie im Android-Entwicklerleitfaden.Code implementieren
Die Device Administration API umfasst die folgenden Klassen:
DeviceAdminReceiver- Basisklasse für die Implementierung einer Geräteverwaltungskomponente. Dieser Kurs bietet
eine vereinfachte Interpretation der unbearbeiteten Intent-Aktionen, die vom
System. Deine Geräteverwaltungs-App muss Folgendes enthalten:
DeviceAdminReceiverabgeleitete Klasse. DevicePolicyManager- Kurs zum Verwalten von Richtlinien, die auf einem Gerät erzwungen werden. Die meisten Kunden von
Diese Klasse muss eine
DeviceAdminReceiververöffentlicht haben, die vom Nutzer derzeit aktiviert ist. Über dieDevicePolicyManagerwerden Richtlinien verwaltet für eine oder mehrereDeviceAdminReceiver-Instanzen DeviceAdminInfo- Mit dieser Klasse werden Metadaten angegeben für eine Geräteadministratorkomponente.
Diese Klassen bilden die Grundlage für eine voll funktionsfähige App zur Geräteverwaltung. Im restlichen Teil dieses Abschnitts wird beschrieben, wie Sie mit den APIs DeviceAdminReceiver und DevicePolicyManager eine App zur Geräteverwaltung erstellen.
Abgeleitete Klassen von DeviceAdminReceiver
Um eine Geräteverwaltungs-App zu erstellen, müssen Sie abgeleitete Klassen erstellen
DeviceAdminReceiver Die DeviceAdminReceiver-Klasse besteht aus einer Reihe von Rückrufen, die bei bestimmten Ereignissen ausgelöst werden.
Die Beispielanwendung in ihrer abgeleiteten DeviceAdminReceiver-Klasse
lediglich eine Toast-Benachrichtigung als Antwort auf eine bestimmte
Ereignisse. 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ä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.
Der Prozess der Aktivierung der Anwendung beginnt, wenn der Benutzer 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: Beispielanwendung: App aktivieren
Unten sehen Sie den Code, der ausgeführt wird, wenn der Nutzer das Kästchen Administrator aktivieren anklickt. Dadurch wird das Ereignis
onPreferenceChange()
Callback des Nutzers an. Dieser Callback wird aufgerufen, wenn der Wert dieser Preference vom Nutzer geändert wurde und kurz davor steht, festgelegt und/oder gespeichert zu werden. Wenn der Nutzer die App aktiviert, ändert sich das Display 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; }
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-Methode isAdminActive() eine DeviceAdminReceiver-Komponente als Argument nimmt:
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:
Passwortrichtlinien festlegen
DevicePolicyManager enthält APIs zum Festlegen und Durchsetzen der Richtlinie für Gerätepasswörter. In der Device Administration API gilt das Passwort nur für
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:
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 Buchstaben (oder andere Symbole) enthält.
PASSWORD_QUALITY_ALPHANUMERIC- Der Nutzer muss ein Passwort eingeben, das mindestens sowohl Ziffern als auch Buchstaben (oder andere Symbole) enthält.
PASSWORD_QUALITY_NUMERIC- Der Nutzer muss ein Passwort eingeben, das mindestens Ziffern enthält.
PASSWORD_QUALITY_COMPLEX- Der Nutzer muss ein Passwort eingegeben haben, das mindestens einen Buchstaben, eine Ziffer und ein Sonderzeichen.
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:
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 Passwortinhalt 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:
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 angeben, 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 maximal zulässige Anzahl fehlgeschlagener Passworteingaben festlegen, werden alle Daten auf dem Gerät gelöscht, d. h. auf die Werkseinstellungen zurückgesetzt. 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);
Zeitlimit für das Ablaufdatum 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:
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() die Möglichkeit für Nutzer einschränken, alte Passwörter wiederzuverwenden. Diese Methode nimmt den Parameter length an, 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. So 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.
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 festlegen, wie lange ein Nutzer maximal inaktiv sein darf, bevor Gerätesperren. 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 anweisen, es sofort zu sperren:
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
DevicePolicyManager dpm; dpm.lockNow();
Daten löschen
Sie können das Gerät mit der Methode DevicePolicyManager
wipeData() auf die Werkseinstellungen zurücksetzen. Das ist nützlich, wenn das Gerät verloren geht oder gestohlen wird. Häufig wird die Entscheidung zum Löschen des Geräts getroffen, wenn bestimmte Bedingungen erfüllt sind. Mit setMaximumFailedPasswordsForWipe() können Sie beispielsweise angeben, dass ein Gerät nach einer bestimmten Anzahl von fehlgeschlagenen Passwortversuchen gelöscht werden soll.
So löschen Sie die Daten:
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
DevicePolicyManager dpm; dpm.wipeData(0);
Die Methode wipeData() nimmt als Parameter eine Bitmaske mit zusätzlichen Optionen an. Derzeit muss der Wert 0 sein.
Kamera deaktivieren
Ab Android 4.0 können Sie die Kamera deaktivieren. Es muss sich dabei nicht um eine dauerhafte Deaktivierung handeln. Die Kamera kann dynamisch basierend auf Kontext, Uhrzeit usw. aktiviert oder deaktiviert werden.
Mit der Methode setCameraDisabled() kannst du festlegen, ob die Kamera deaktiviert ist. Mit diesem Snippet wird die Kamera beispielsweise anhand eines Kästchens aktiviert oder deaktiviert:
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 die
setStorageEncryption()
Methode zum Festlegen einer Richtlinie, die die Verschlüsselung des Speicherbereichs erfordert, sofern diese 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);
Im Beispiel für die Device Administration API finden Sie ein vollständiges Beispiel dazu, wie die Speicherverschlüsselung aktiviert wird.
Zusätzliche Codebeispiele
Die Beispiele Android AppRestrictionEnforcer und DeviceOwner veranschaulichen die Verwendung der auf dieser Seite beschriebenen APIs.