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
.
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:
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
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.
- Die Berechtigung
- 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 abgeleiteteDeviceAdminReceiver
-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 abgeleiteteDeviceAdminReceiver
-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 inonEnabled()
Damit dies unterstützt wird, muss der Empfänger auch benötigen die BerechtigungBIND_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 KlasseDeviceAdminInfo
geparst. 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>
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 dieDevicePolicyManager
werden 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 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.
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
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.