Diese Seite bietet einen Überblick über die APIs, Funktionen und Verhaltensänderungen für Unternehmen, die in Android 9 verfügbar sind.
Benutzeroberfläche des Arbeitsprofils
Unter Android 9 (API-Level 28) wurden Änderungen an der Benutzeroberfläche im Standard-Launcher vorgenommen, damit Nutzer private und geschäftliche Apps besser voneinander unterscheiden können. Gerätehersteller, die dies unterstützen, können die Apps der Nutzer auf separaten Tabs für Arbeit und Privates präsentieren. Außerdem ist es für Gerätenutzer nun einfacher, das Arbeitsprofil zu aktivieren und zu deaktivieren. Dafür gibt es jetzt einen Schalter auf dem Tab „Arbeit“ des Launchers.
![](https://developer.android.google.cn/static/images/about/versions/pie/p-work-profile.jpg?authuser=6&hl=de)
Bei der Bereitstellung von Arbeitsprofilen und verwalteten Geräten enthält Android 9 animierte Illustrationen, damit Gerätenutzer diese Funktionen verständlich machen.
Zwischen Apps wechseln
Android 9 enthält APIs zum Starten einer weiteren Instanz einer App in einem anderen Profil, damit Nutzer leichter zwischen Konten wechseln können. Eine E-Mail-Anwendung kann beispielsweise eine UI bereitstellen, mit der der Nutzer zwischen dem privaten und dem Arbeitsprofil wechseln kann, um auf zwei E-Mail-Konten zuzugreifen. Alle Anwendungen können diese APIs aufrufen, um die Hauptaktivität derselben Anwendung zu starten, wenn sie bereits im anderen Profil installiert ist. Wenn Sie in Ihrer App den profilübergreifenden Kontowechsel hinzufügen möchten, führen Sie die folgenden Schritte zum Aufrufen der Aufrufmethoden der Klasse CrossProfileApps
aus:
- Rufen Sie
getTargetUserProfiles()
auf, um eine Liste der Profile abzurufen, in denen Sie eine weitere Instanz der App starten können. Mit dieser Methode wird geprüft, ob die Anwendung in den Profilen installiert ist. - Rufen Sie
getProfileSwitchingIconDrawable()
auf, um ein Symbol zu erhalten, das Sie für ein anderes Profil verwenden können. - Rufe
getProfileSwitchingLabel()
auf, um lokalisierten Text zu erhalten, der den Nutzer zum Wechseln des Profils auffordert. - Rufen Sie
startMainActivity()
auf, um eine Instanz der Anwendung in einem anderen Profil zu starten.
Prüfen Sie, ob die Hauptaktivität, die Sie starten möchten, in der Manifestdatei Ihrer App mit einer Intent-Aktion ACTION_MAIN
deklariert ist und die Intent-Kategorie CATEGORY_LAUNCHER
enthält.
Arbeitsprofile programmatisch aktivieren oder deaktivieren
Der Standard-Launcher (oder Apps mit der Berechtigung MANAGE_USERS
oder MODIFY_QUIET_MODE
) kann das Arbeitsprofil durch Aufrufen von UserManager.requestQuietModeEnabled()
aktivieren oder deaktivieren. Anhand des Rückgabewerts lässt sich feststellen, ob der Nutzer seine Anmeldedaten bestätigen muss, bevor sich der Status ändert. Da die Änderung möglicherweise nicht sofort erfolgt, warten Sie auf die Broadcasts ACTION_MANAGED_PROFILE_AVAILABLE
oder ACTION_MANAGED_PROFILE_UNAVAILABLE
, um zu erfahren, wann die Benutzeroberfläche aktualisiert werden muss.
Ihre App kann den Status des Arbeitsprofils durch Aufrufen von UserManager.isQuietModeEnabled()
prüfen.
Jede App auf einem Gerät sperren
Ab Android 9 können Geräteinhaber und Profilinhaber (von sekundären Nutzern) jede App auf dem Bildschirm eines Geräts sperren, indem sie die App in den Modus „Gesperrte Aufgabe“ versetzen. Bisher mussten App-Entwickler in ihren Apps Unterstützung für den Modus „Sperren“ hinzufügen. Android 9 erweitert die APIs für Sperraufgaben außerdem auf Profilinhaber von nicht verbundenen sekundären Nutzern. So sperrst du eine App auf dem Bildschirm:
- Rufen Sie
DevicePolicyManager.setLockTaskPackages()
auf, um Apps für den Sperrmodusmodus auf die Zulassungsliste zu setzen. - Rufen Sie
ActivityOptions.setLockTaskEnabled()
auf, um eine App auf der Zulassungsliste im Modus „Sperraufgabe“ zu starten.
Wenn Sie eine App im Modus zum Sperren von Aufgaben beenden möchten, entfernen Sie sie mithilfe von DevicePolicyManager.setLockTaskPackages()
aus der Zulassungsliste.
System-UI-Funktionen aktivieren
Wenn der Modus zum Sperren von Aufgaben aktiviert ist, können Geräteinhaber und Profilinhaber bestimmte System-UI-Funktionen auf dem Gerät aktivieren, indem sie DevicePolicyManager.setLockTaskFeatures()
aufrufen und ein Bitfeld mit den folgenden Funktions-Flags übergeben:
LOCK_TASK_FEATURE_NONE
LOCK_TASK_FEATURE_SYSTEM_INFO
LOCK_TASK_FEATURE_HOME
LOCK_TASK_FEATURE_NOTIFICATIONS
kann nur in Kombination mitLOCK_TASK_FEATURE_HOME
verwendet werden.LOCK_TASK_FEATURE_KEYGUARD
LOCK_TASK_FEATURE_OVERVIEW
kann nur in Kombination mitLOCK_TASK_FEATURE_HOME
verwendet werden.LOCK_TASK_FEATURE_GLOBAL_ACTIONS
Sie können DevicePolicyManager.getLockTaskFeatures()
aufrufen, um eine Liste der Funktionen abzurufen, die auf einem Gerät verfügbar sind, wenn der Modus zum Sperren von Aufgaben aktiviert ist. Wenn ein Gerät den Aufgabenmodus zum Sperren beendet, kehrt es zu dem von anderen Geräterichtlinien festgelegten Status zurück.
Fehlerdialoge unterdrücken
In einigen Umgebungen, z. B. bei Demos für den Einzelhandel oder zur Anzeige öffentlicher Informationen, möchten Sie Nutzern möglicherweise keine Fehlerdialogfelder anzeigen lassen. Ein Device Policy Controller (DPC) kann Dialogfelder zu Systemfehlern für abgestürzte oder nicht reagierende Apps durch Hinzufügen der Nutzereinschränkung DISALLOW_SYSTEM_ERROR_DIALOGS
unterdrücken. Diese Einschränkung gilt für alle Dialogfelder, wenn sie von einem Geräteinhaber angewendet wird. Wenn die Einschränkung von Profilinhabern angewendet wird, werden jedoch nur die Fehlerdialogfelder unterdrückt, die dem primären oder sekundären Nutzer angezeigt werden. Diese Einschränkung hat keine Auswirkungen auf Arbeitsprofile.
Unter Android 9 wird bei Apps, die im immersiven Vollbildmodus ausgeführt werden, das Erinnerungs-Infofeld im Modus zum Sperren der Aufgabe nicht angezeigt. Das Erinnerungs-Infofeld ist ein Bereich, der Nutzern beim ersten Start angezeigt wird und erklärt, wie der immersive Modus beendet wird.
Mehrere Nutzer auf zweckbestimmten Geräten unterstützen
Mit Android 9 wird das Konzept eines sitzungsspezifischen Nutzers für dedizierte Geräte (früher COSU-Geräte genannt) eingeführt. Sitzungsspezifische Nutzer sind kurzfristige Nutzer, wenn mehrere Nutzer ein einzelnes dediziertes Gerät verwenden. Dazu gehören öffentliche Nutzersitzungen auf Geräten wie Bibliotheken oder Check-in-Kiosken für Gastgewerbe sowie dauerhafte Sitzungen zwischen einer bestimmten Gruppe von Nutzern auf Geräten, z. B. Schichtarbeitern.
Sitzungsspezifische Nutzer sollten im Hintergrund erstellt werden. Sie werden als sekundäre Nutzer auf einem Gerät erstellt und zusammen mit den zugehörigen Apps und Daten entfernt, wenn sie beendet, gewechselt oder das Gerät neu gestartet wird. Zum Erstellen eines sitzungsspezifischen Nutzers haben Geräteinhaber folgende Möglichkeiten:
- Legen Sie das Flag
MAKE_USER_EPHEMERAL
fest, wenn SieDevicePolicyManager.createAndManageUser()
aufrufen. - Rufen Sie
DevicePolicyManager.startUserInBackground()
auf, um den flüchtigen Nutzer im Hintergrund zu starten.
Hinweis: Apps, die auf Android 9 ausgerichtet sind, sollten beim Aufrufen von createAndManageUser()
UserManager.UserOperationException
erfassen. Rufen Sie die Methode getUserOperationResult()
der Ausnahme auf, um herauszufinden, warum der Nutzer nicht erstellt wurde.
Terminbenachrichtigungen erhalten
Das DeviceAdminReceiver
erhält Benachrichtigungen für die folgenden Ereignisse:
onUserStarted()
: Wird beim Starten eines Nutzers aufgerufen.onUserSwitched()
: Wird aufgerufen, wenn ein Nutzerwechsel abgeschlossen ist.onUserStopped()
: Wird zusammen mitonUserRemoved()
aufgerufen, wenn ein Nutzer die Ausführung beendet oder sich abmeldet.
Ereignisnachrichten für Nutzer anzeigen
Geräteinhaber können die Mitteilungen konfigurieren, die Nutzern beim Starten und Beenden ihrer Sitzungen angezeigt werden:
- Mit
DevicePolicyManager.setStartUserSessionMessage()
können Sie die Mitteilung festlegen, die einem Nutzer zu Beginn seiner Sitzung angezeigt wird. Rufen Sie zum Abrufen der NachrichtDevicePolicyManager.getStartUserSessionMessage()
auf. - Mit
DevicePolicyManager.setEndUserSessionMessage()
können Sie die Mitteilung festlegen, die dem Nutzer am Ende seiner Sitzung angezeigt wird. Rufen Sie zum Abrufen der NachrichtDevicePolicyManager.getEndUserSessionMessage()
auf.
Abmelden und Nutzer stoppen
Geräteinhaber können mit DevicePolicyManager.setLogoutEnabled()
angeben, ob die Abmeldung für sekundäre Nutzer aktiviert ist. Rufen Sie DevicePolicyManager.isLogoutEnabled()
auf, um zu prüfen, ob die Abmeldung aktiviert ist.
Profilinhaber sekundärer Nutzer können DevicePolicyManager.logoutUser()
aufrufen, um den sekundären Nutzer zu stoppen und zum primären Nutzer zurückzukehren.
Geräteeigentümer können DevicePolicyManager.stopUser()
verwenden, um einen angegebenen sekundären Nutzer zu stoppen.
Paket-Caching
Um die Nutzerverwaltung auf gemeinsam verwendeten Geräten mit einer festen Gruppe von Nutzern zu optimieren, z. B. Geräte für Schichtarbeiter, ist es möglich, Pakete im Cache zu speichern, die für Sitzungen mit mehreren Nutzern erforderlich sind:
Rufen Sie
DevicePolicyManager.setKeepUninstalledPackages()
auf, um die Liste der Pakete anzugeben, die als APKs beibehalten werden sollen. Rufen SieDevicePolicyManager.getKeepUninstalledPackages()
auf, um eine Liste dieser Pakete abzurufen.Rufen Sie
DevicePolicyManager.installExistingPackage()
auf, um ein Paket zu installieren, das nach dem Entfernen übersetKeepUninstalledPackages()
beibehalten wurde.
Zusätzliche Methoden und Konstanten
Android 9 umfasst außerdem die folgenden Methoden und Konstanten, um Nutzersitzungen auf gemeinsam verwendeten Geräten weiter zu unterstützen:
- Mit
DevicePolicyManager.getSecondaryUsers()
wird eine Liste aller sekundären Nutzer auf einem Gerät abgerufen. DISALLOW_USER_SWITCH
ist eine Nutzereinschränkung, die Sie durch Aufrufen vonDevicePolicyManager.addUserRestriction()
aktivieren können, um den Nutzerwechsel zu blockieren.LEAVE_ALL_SYSTEM_APPS_ENABLED
ist ein Flag, das fürDevicePolicyManager.createAndManageUser()
verfügbar ist. Wenn dies festgelegt ist, werden Systemanwendungen während der Nutzerverwaltung nicht deaktiviert.UserManager.UserOperationException
wird vonDevicePolicyManager.createAndManageUser()
ausgelöst, wenn ein Nutzer nicht erstellt werden kann. Die Ausnahme enthält den Grund für den Fehler.
Paketdaten löschen und Konten entfernen
Geräte- und Profilinhaber können clearApplicationUserData()
aufrufen, um die Nutzerdaten für ein bestimmtes Paket zu löschen. Zum Entfernen eines Kontos aus dem AccountManager
können Geräte- und Profilinhaber removeAccount()
aufrufen.
Nutzereinschränkungen und mehr Kontrolle über Einstellungen
Android 9 bietet eine Reihe von Nutzereinschränkungen für DPCs sowie die Möglichkeit, APNs, Zeit und Zeitzone sowie Systemeinstellungen auf einem Gerät zu konfigurieren.
APNs konfigurieren
Geräteinhaber können die folgenden Methoden in der Klasse DevicePolicyManager
verwenden, um APNs auf einem Gerät zu konfigurieren:
addOverrideApn()
updateOverrideApn()
removeOverrideApn()
getOverrideApns()
setOverrideApnEnabled()
isOverrideApnEnabled()
Uhrzeit und Zeitzone konfigurieren
Geräteinhaber können die folgenden Methoden in der Klasse DevicePolicyManager
verwenden, um die Uhrzeit und Zeitzone auf einem Gerät festzulegen:
Nutzereinschränkungen für wichtige Einstellungen erzwingen
Unter Android 9 werden Nutzereinschränkungen hinzugefügt, um Systemfunktionen und -einstellungen zu deaktivieren. Wenn Sie eine Einschränkung hinzufügen möchten, rufen Sie DevicePolicyManager.addUserRestriction()
mit einer der folgenden UserManager
-Konstanten auf:
DISALLOW_AIRPLANE_MODE
DISALLOW_AMBIENT_DISPLAY
DISALLOW_CONFIG_BRIGHTNESS
DISALLOW_CONFIG_DATE_TIME
DISALLOW_CONFIG_LOCATION
DISALLOW_CONFIG_SCREEN_TIMEOUT
DISALLOW_PRINTING
Wenn DISALLOW_CONFIG_BRIGHTNESS
und DISALLOW_CONFIG_SCREEN_TIMEOUT
auf einem Gerät erzwungen werden, können Geräteeigentümer weiterhin die Bildschirmhelligkeit, den Bildschirmhelligkeitsmodus und das Zeitlimit für die Bildschirmzeit über die API DevicePolicyManager.setSystemSetting()
auf dem Gerät festlegen.
Kostenpflichtige Daten
Geräte- und Profilinhaber können verhindern, dass Apps die kostenpflichtigen Datennetzwerke eines Geräts nutzen. Ein Netzwerk gilt als kostenpflichtig, wenn der Nutzer aufgrund von Kosten, Datenlimits oder Akku- und Leistungsproblemen auf eine hohe Datennutzung reagiert. Wenn Sie verhindern möchten, dass Apps gebührenpflichtige Netzwerke verwenden, rufen Sie DevicePolicyManager.setMeteredDataDisabledPackages()
auf und übergeben Sie eine Liste von Paketnamen. Rufen Sie DevicePolicyManager.getMeteredDataDisabledPackages()
auf, um die derzeit eingeschränkten Apps abzurufen.
Weitere Informationen zu kostenpflichtigen Daten in Android finden Sie unter Netzwerkdatennutzung optimieren.
DPCs migrieren
Device Policy Controller (DPCs) können die Inhaberschaft eines Geräts oder Arbeitsprofils auf einen anderen DPC übertragen. Sie können die Inhaberschaft übertragen, um einige Funktionen zur Android Management API zu verschieben, Geräte von Ihrem alten DPC zu migrieren oder IT-Administratoren bei der Migration zu Ihrem EMM zu unterstützen. Da Sie nur die DPC-Inhaberschaft ändern, können Sie diese Funktion nicht verwenden, um die Art der Verwaltung zu ändern, z. B. die Migration von einem verwalteten Gerät zu einem Arbeitsprofil oder umgekehrt.
Mit der XML-Ressource Geräteadministratorrichtlinien können Sie angeben, dass diese Version Ihres DPC die Migration unterstützt. Ein Ziel-DPC gibt an, dass er Eigentumsrechte erhalten kann, indem er ein Element namens <support-transfer-ownership>
enthält. Das folgende Beispiel zeigt, wie Sie dies in der XML-Datei für die Geräteverwaltung Ihres DPCs tun können:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
<support-transfer-ownership />
<uses-policies>
<limit-password />
<watch-login />
<reset-password />
</uses-policies>
</device-admin>
DPCs, die die Inhaberschaft zur neuen DPC-Anwendung migrieren möchten, können durch Aufrufen der DeviceAdminInfo
-Methode supportsTransferOwnership()
prüfen, ob die Version eines Ziel-DPC die Migration unterstützt. Vor der Übertragung der Inhaberschaft liegt es in der Verantwortung des Quell-DPC, den Ziel-DPC durch den Vergleich der Anwendungssignaturen zu prüfen. Die Klasse PackageManager
enthält Methoden für die Arbeit mit Codesignaturen.
Android verwaltet die System- und Nutzerrichtlinien des Quell-DPC durch eine Übertragung der Inhaberschaft – DPCs müssen diese nicht migrieren. Ein Quell-DPC kann mithilfe von Schlüssel/Wert-Paaren in einem PersistableBundle
benutzerdefinierte Daten an den Ziel-DPC übergeben. Nach einer erfolgreichen Übertragung kann der Ziel-DPC diese Daten durch Aufrufen von DevicePolicyManager.getTransferOwnershipBundle()
abrufen.
Die Schritte zum Übertragen der Eigentümerschaft eines verwalteten Geräts oder Arbeitsprofils sind identisch:
- Der Quell-DPC prüft, ob die Version des Ziel-DPC die Migration unterstützt, und bestätigt, dass die Anwendungssignatur des Ziel-DPC mit einem erwarteten Wert übereinstimmt.
- Der Quell-DPC ruft
transferOwnership()
auf, um die Übertragung zu starten. - Das System macht den Ziel-DPC zum aktiven Administrator und legt ihn als Inhaber des verwalteten Geräts oder Arbeitsprofils fest.
- Der Ziel-DPC empfängt den Callback
onTransferOwnershipComplete()
und kann ihn mit Werten aus dem Argumentbundle
selbst konfigurieren. - Wenn bei der Übertragung ein Fehler auftritt, setzt das System die Inhaberschaft auf den Quell-DPC zurück. Wenn der Quell-DPC bestätigen muss, dass die Übertragung der Inhaberschaft erfolgreich war, rufen Sie
isAdminActive()
auf, um zu prüfen, ob der Quell-DPC nicht mehr der aktive Administrator ist.
Alle Apps, die im Arbeitsprofil ausgeführt werden, erhalten die ACTION_PROFILE_OWNER_CHANGED
-Nachricht, wenn sich der Profilinhaber ändert. Apps, die auf einem verwalteten Gerät ausgeführt werden, erhalten die ACTION_DEVICE_OWNER_CHANGED
-Nachricht, wenn sich der Eigentümer des Geräts ändert.
Arbeitsprofile auf vollständig verwalteten Geräten
Die Übertragung von zwei Instanzen eines DPC, der als Geräteinhaber und Profilinhaber ausgeführt wird, erfolgt in zwei Phasen. Wenn das private Profil und das Arbeitsprofil verbunden sind, schließen Sie die Übertragung in der folgenden Reihenfolge ab:
- Übertragen Sie zuerst die Eigentümerschaft des Arbeitsprofils.
- Warten Sie auf den
DeviceAdminReceiver
-CallbackonTransferAffiliatedProfileOwnershipComplete()
, um zu bestätigen, dass das Arbeitsprofil auf den Ziel-DPC übertragen wurde. - Übertragen Sie abschließend die Eigentümerschaft des verwalteten Geräts auf den Ziel-DPC.
OTA-Updates (Over The Air) verschieben
Geräteeigentümer können OTA-Systemupdates für Geräte um bis zu 90 Tage verschieben, um die auf diesen Geräten ausgeführte Betriebssystemversion über kritische Zeiträume wie z. B. Feiertage einzufrieren. Das System erzwingt nach einem festgelegten Sperrzeitraum einen obligatorischen 60-tägigen Puffer, um zu verhindern, dass das Gerät auf unbestimmte Zeit einfriert.
Während der Sperrzeit gilt Folgendes:
- Geräte erhalten keine Benachrichtigungen zu ausstehenden OTA-Updates.
- Auf den Geräten werden keine OTA-Updates für das Betriebssystem installiert.
- Gerätenutzer können in den Einstellungen nicht manuell nach OTA-Updates suchen.
Rufen Sie SystemUpdatePolicy.setFreezePeriods()
auf, um eine Sperrzeit festzulegen. Da sich die Sperrzeit jährlich wiederholt, werden Start- und Enddatum des Zeitraums durch Ganzzahlen dargestellt, die die Anzahl der Tage seit Jahresbeginn zählen. Der Starttag muss mindestens 60 Tage nach dem Ende des vorherigen Sperrzeitraums beginnen. Geräteinhaber können SystemUpdatePolicy.getFreezePeriods()
aufrufen, um eine Liste der Sperrzeiträume abzurufen, die zuvor für das Richtlinienobjekt für Systemupdates festgelegt wurden.
DevicePolicyManager.getSystemUpdatePolicy()
wurde aktualisiert, um alle Sperrzeiträume zurückzugeben, die vom Geräteeigentümer festgelegt wurden.
Freigabe in einem Arbeitsprofil einschränken
Profilinhaber können die Nutzereinschränkung DISALLOW_SHARE_INTO_MANAGED_PROFILE
hinzufügen, um zu verhindern, dass Nutzer personenbezogene Daten für ein Arbeitsprofil auf dem Gerät freigeben.
Diese Einschränkung verhindert die folgende Verarbeitung und Freigabe von Intents:
- Apps mit privatem Profil, die Daten und Dateien an Apps mit Arbeitsprofil weitergeben.
- Apps mit Arbeitsprofil, in denen Elemente aus dem privaten Profil ausgewählt werden, z. B. Bilder oder Dateien
Nachdem Sie diese Einschränkung festgelegt haben, kann Ihr DPC weiterhin profilübergreifende Aktivitäts-Intents durch Aufrufen von addCrossProfileIntentFilter()
zulassen.
Hardwaregesicherte Schlüssel und Gerätezertifikate
Unter Android 9 werden APIs hinzugefügt, die Ihnen die Arbeit mit Schlüsseln und Zertifikaten erleichtern, die Sie kombinieren können, um Geräte sicher zu identifizieren. Ein DPC, der im Profilinhaber- oder Geräteinhabermodus ausgeführt wird, oder ein Installationsprogramm für delegierte Zertifikate können die folgenden Aufgaben ausführen:
- Generieren Sie Schlüssel und Zertifikate auf der sicheren Hardware (z. B. eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) oder ein Secure Element (SE)) des Android-Geräts. Die generierten Schlüssel verlassen die sichere Hardware nie und können über die Android-KeyChain verwendet werden. Rufen Sie
DevicePolicyManager.generateKeyPair()
auf und geben Sie den Algorithmus (sieheKeyPairGenerator
) und alle Hardware-IDs an, die attestiert werden sollen, z. B. die Seriennummer oder IMEI. Weitere Informationen zu sicheren Hardwareänderungen findest du in den Verbesserungen der Android 9-Sicherheit. - Verknüpfen Sie ein Zertifikat mit einem vorhandenen, vom Gerät generierten Schlüssel. Rufen Sie
DevicePolicyManager.setKeyPairCertificate()
auf und geben Sie den Alias des vorhandenen Schlüssels und der Zertifikatskette an – beginnend mit dem untergeordneten Zertifikat und einschließlich der Vertrauenskette. - Prüfen Sie, ob der Schlüssel durch die sichere Hardware geschützt ist, bevor Sie ihn verwenden. Führen Sie die Schritte unter Schlüsselattestierung aus, um zu prüfen, welche Mechanismen den Schlüssel schützen.
- Geräteinhaber und delegierte Zertifikatinstallationsprogramme können eine signierte Erklärung der Hardware-IDs der Geräte mit Android-Systemversionen erhalten. Rufen Sie
DevicePolicyManager.generateKeyPair()
auf und übergeben Sie dabei mindestens einen der folgenden Werte:ID_TYPE_BASE_INFO
,ID_TYPE_SERIAL
,ID_TYPE_IMEI
oderID_TYPE_MEID
im ArgumentidAttestationFlags
. Das zurückgegebene Zertifikat enthält die Hardware-IDs im Attestierungsdatensatz. Wenn Sie die Hardware-IDs nicht angeben möchten, übergeben Sie0
. Profilinhaber können nur Herstellerinformationen erhalten, indem sieID_TYPE_BASE_INFO
übergeben. RufeisDeviceIdAttestationSupported()
auf, um zu prüfen, ob das Gerät IDs attestieren kann. - Sie können verhindern, dass Gerätenutzer Unternehmensschlüssel (bei Aufgaben für andere Zwecke) missbrauchen, indem Sie die Auswahl der Schlüsselzertifikate deaktivieren. In der Auswahl werden keine nicht auswählbaren Zertifikate angezeigt. Geben Sie in der Callback-Methode
DeviceAdminReceiver.onChoosePrivateKeyAlias()
den Alias an Ihren Unternehmensschlüssel zurück, sodass das System das Zertifikat automatisch für den Nutzer auswählt. Wenn Sie die Auswahl eines Schlüssels aufheben möchten, rufen Sie die folgendenDevicePolicyManager
-Methoden auf:setKeyPairCertificate()
und übergebenfalse
für das ArgumentisUserSelectable
.installKeyPair (ComponentName, PrivateKey, Certificate[], String, int)
und lassen SieINSTALLKEY_SET_USER_SELECTABLE
im Argumentflags
weg.
Durch die Kombination dieser APIs können Unternehmen Geräte sicher identifizieren und deren Integrität bestätigen, bevor sie Zugriff gewähren:
- Das Android-Gerät generiert einen neuen privaten Schlüssel auf der sicheren Hardware. Da der private Schlüssel niemals die sichere Hardware verlässt, bleibt er geheim.
- Das Gerät verwendet den Schlüssel, um eine Anfrage zur Zertifikatsignierung (Certificate Signing Request, CSR) zu erstellen und an den Server zu senden. Die CSR enthält den Attestierungsdatensatz mit den Geräte-IDs.
- Der Server validiert die Zertifikatskette (gerootet mit einem Google-Zertifikat) und extrahiert die Gerätemetadaten aus dem Attestierungsdatensatz.
- Der Server bestätigt, dass die sichere Hardware den privaten Schlüssel schützt und die Geräte-IDs mit den Einträgen des Unternehmens übereinstimmen. Der Server kann auch prüfen, ob die Android-System- und Patchversionen alle Anforderungen erfüllen.
- Der Server generiert ein Zertifikat von der CSR und sendet es an das Gerät.
- Das Gerät koppelt das Zertifikat mit dem privaten Schlüssel (der auf der sicheren Hardware verbleibt), sodass Anwendungen eine Verbindung zu Unternehmensdiensten herstellen können.
Weitere Sicherheits-APIs, Funktionen und Änderungen
IDs für Sicherheits- und Netzwerkprotokolle
Unter Android 9 sind IDs in den Protokollen zur Sicherheit und Netzwerkaktivität enthalten. Die numerische ID erhöht sich monoton für jedes Ereignis, sodass IT-Administratoren Lücken in ihren Logs leichter erkennen können. Da Sicherheits- und Netzwerkprotokolle separate Sammlungen sind, behält das System separate ID-Werte bei.
Rufen Sie SecurityEvent.getId()
, DnsEvent.getId()
oder ConnectEvent.getId()
auf, um den ID-Wert zu erhalten. Das System setzt die ID zurück, wenn ein DPC die Protokollierung aktiviert oder das Gerät neu gestartet wird.
Sicherheitslogs, die durch den Aufruf von DevicePolicyManager.retrievePreRebootSecurityLogs()
abgerufen werden, enthalten diese IDs nicht.
Sicherheits-Logging
Das Sicherheits-Logging weist jedem SecurityEvent
eine Logebene zu. Um die Logebene zu erhalten, rufen Sie getLogLevel()
auf. Diese Methode gibt einen Wert auf Logebene zurück, der entweder LEVEL_INFO
, LEVEL_WARNING
oder LEVEL_ERROR
sein kann.
Android 9 protokolliert die in der folgenden Tabelle aufgeführten Ereignisse in Sicherheitslogs. Rufen Sie getTag()
auf, um das Tag eines Ereignisses zu prüfen. Rufen Sie zum Abrufen der Ereignisdaten getData()
auf.
Taggen | Terminbeschreibung |
---|---|
TAG_CERT_AUTHORITY_INSTALLED |
Versuch, ein neues Root-Zertifikat im Anmeldedatenspeicher des Systems zu installieren. |
TAG_CERT_AUTHORITY_REMOVED |
Versuch, ein Root-Zertifikat aus dem Anmeldedatenspeicher des Systems zu entfernen. |
TAG_CERT_VALIDATION_FAILURE |
Ein WLAN-Zertifikat hat die Validierungsprüfung während der Verbindung nicht bestanden. |
TAG_CRYPTO_SELF_TEST_COMPLETED |
Das System hat den kryptografischen Selbsttest abgeschlossen. |
TAG_KEYGUARD_DISABLED_FEATURES_SET |
Eine Administrator-App hat Funktionen des Sperrbildschirms eines Geräts oder Arbeitsprofils deaktiviert. |
TAG_KEY_DESTRUCTION |
Ein Versuch, einen kryptografischen Schlüssel zu löschen. |
TAG_KEY_GENERATED |
Ein Versuch, einen neuen kryptografischen Schlüssel zu generieren. |
TAG_KEY_IMPORT |
Ein Versuch, einen neuen kryptografischen Schlüssel zu importieren. |
TAG_KEY_INTEGRITY_VIOLATION |
Android hat einen beschädigten Verschlüsselungs- oder Authentifizierungsschlüssel erkannt. |
TAG_LOGGING_STARTED |
Aufzeichnung des Sicherheits-Loggings gestartet. |
TAG_LOGGING_STOPPED |
Aufzeichnung des Sicherheits-Loggings beendet. |
TAG_LOG_BUFFER_SIZE_CRITICAL |
Der Zwischenspeicher des Sicherheitsprotokolls hat 90% seiner Kapazität erreicht. |
TAG_MAX_PASSWORD_ATTEMPTS_SET |
Eine Administrator-App hat die Anzahl der zulässigen falschen Passworteingaben festgelegt. |
TAG_MAX_SCREEN_LOCK_TIMEOUT_SET |
Eine Administrator-App hat ein maximales Zeitlimit für die Displaysperre festgelegt. |
TAG_MEDIA_MOUNT |
Auf dem Gerät bereitgestellte Wechseldatenträger |
TAG_MEDIA_UNMOUNT |
Das Gerät hat ein Wechseldatenträgermedium getrennt. |
TAG_OS_SHUTDOWN |
Das Android-System wurde heruntergefahren. |
TAG_OS_STARTUP |
Das Android-System wurde gestartet. |
TAG_PASSWORD_COMPLEXITY_SET |
Eine Administrator-App legt die Komplexitätsanforderungen für Passwörter fest. |
TAG_PASSWORD_EXPIRATION_SET |
Eine Administrator-App hat eine Ablaufdauer für das Passwort festgelegt. |
TAG_PASSWORD_HISTORY_LENGTH_SET |
Eine Administrator-App legt die Länge des Passwortverlaufs fest und verhindert, dass Nutzer alte Passwörter wiederverwenden. |
TAG_REMOTE_LOCK |
Eine Administrator-App hat das Gerät oder das Arbeitsprofil gesperrt. |
TAG_USER_RESTRICTION_ADDED |
Eine Administrator-App hat eine Nutzereinschränkung festgelegt. |
TAG_USER_RESTRICTION_REMOVED |
Eine Administrator-App hat eine Nutzereinschränkung entfernt. |
TAG_WIPE_FAILURE |
Der Versuch, die Daten auf einem Gerät oder Arbeitsprofil zu löschen, ist fehlgeschlagen. |
Identitätsbestätigung per Arbeitsprofil
Ab Android 9 können Profilinhaber festlegen, dass Nutzer mit der Nutzereinschränkung DISALLOW_UNIFIED_PASSWORD
eine separate Identitätsbestätigung für ihr Arbeitsprofil einrichten müssen. Wenn Sie prüfen möchten, ob für ein Nutzer und sein Arbeitsprofil dieselbe Identitätsbestätigung auf dem Sperrbildschirm festgelegt ist, rufen Sie DevicePolicyManager.isUsingUnifiedPassword()
auf.
Wenn ein Gerät einen separaten Sperrbildschirm mit Arbeitsprofil hat, legt DevicePolicyManager.setMaximumTimeToLock()
nur ein Zeitlimit für den Sperrbildschirm für das Arbeitsprofil und nicht für das gesamte Gerät fest.
Zugriff auf Entwicklertools
Damit die Arbeitsdaten im Arbeitsprofil bleiben, kann das ADB-Tool (Android Debug Bridge) nicht auf Verzeichnisse und Dateien im Arbeitsprofil zugreifen.
Unterstützung weiterer biometrischer Optionen
Mit Android 9 können Sie die Authentifizierung biometrischer Hardware auf dem Sperrbildschirm eines Arbeitsprofils genau steuern. Rufen Sie die vorhandene Methode DevicePolicyManager.setKeyguardDisabledFeatures()
mit KEYGUARD_DISABLE_FACE
und KEYGUARD_DISABLE_IRIS
auf.
Wenn Sie alle vom Gerät bereitgestellten biometrischen Authentifizierungsmethoden deaktivieren möchten, fügen Sie KEYGUARD_DISABLE_BIOMETRICS
hinzu.
Einstellung von Richtlinien zur Geräteverwaltung
Unter Android 9 werden die unten aufgeführten Richtlinien für DPCs, die die Geräteverwaltung verwenden, als eingestellt gekennzeichnet. Die Richtlinien funktionieren in Android 9 weiterhin wie zuvor. Ab Android 10 geben dieselben Richtlinien eine SecurityException aus, wenn sie von einem Geräteadministrator aufgerufen werden.
USES_POLICY_DISABLE_CAMERA
USES_POLICY_DISABLE_KEYGUARD_FEATURES
USES_POLICY_EXPIRE_PASSWORD
USES_POLICY_LIMIT_PASSWORD
Einige Anwendungen verwenden die Geräteverwaltung für die Verwaltung von Verbrauchergeräten. Beispiel: Sperren und Löschen eines verlorenen Geräts. Die folgenden Richtlinien sind dafür weiterhin verfügbar:
Weitere Informationen zu diesen Änderungen finden Sie unter Einstellung der Geräteverwaltung.
Optimierte QR-Code-Registrierung
Integrierte QR-Bibliothek
Android 9 wird mit einer QR-Bibliothek geliefert, um die Bereitstellung von QR-Code-Geräten zu optimieren. IT-Administratoren müssen WLAN-Details nicht mehr manuell eingeben, um ein Gerät einzurichten. Bei Android 9 ist es stattdessen möglich, diese WLAN-Details in einen QR-Code aufzunehmen. Wenn ein IT-Administrator den QR-Code mit einem unternehmenseigenen Gerät scannt, stellt das Gerät automatisch eine WLAN-Verbindung her und beginnt ohne zusätzliche manuelle Eingaben im Bereitstellungsprozess.
Die Bereitstellungsmethode für QR-Code unterstützt die folgenden Bereitstellungsfunktionen zur Angabe von WLAN-Details:
EXTRA_PROVISIONING_WIFI_HIDDEN
EXTRA_PROVISIONING_WIFI_PAC_URL
EXTRA_PROVISIONING_WIFI_PASSWORD
EXTRA_PROVISIONING_WIFI_PROXY_BYPASS
EXTRA_PROVISIONING_WIFI_PROXY_HOST
EXTRA_PROVISIONING_WIFI_PROXY_PORT
EXTRA_PROVISIONING_WIFI_SECURITY_TYPE
EXTRA_PROVISIONING_WIFI_SSID
Datum und Zeitzone mithilfe von Extras festlegen
Die Bereitstellungsmethode für QR-Code unterstützt die Bereitstellung von Extras zum Festlegen der Uhrzeit und Zeitzone auf einem Gerät:
Optionen zum Löschen von Daten
Geräteadministratoren können Nutzern beim Entfernen eines Arbeitsprofils oder sekundären Nutzers eine personalisierte Nachricht anzeigen. Die Nachricht informiert Gerätenutzer darüber, dass ihr IT-Administrator das Arbeitsprofil oder den sekundären Nutzer entfernt hat. Rufen Sie wipeData(int, CharSequence)
auf und geben Sie eine kurze erklärende Nachricht ein. Wenn das System vom primären Nutzer oder Geräteeigentümer aufgerufen wird, zeigt das System keine Nachricht an und beginnt mit dem Zurücksetzen des Geräts auf die Werkseinstellungen.
Wenn du Abodaten von einer eingebetteten eUICC-SIM-Karte entfernen möchtest, rufe wipeData()
auf und füge WIPE_EUICC
in das flags
-Argument ein.
Methoden für Inhaber von verknüpften Profilen
Inhaber von verknüpften Profilen können die folgenden Methoden nutzen:
DevicePolicyManager.setKeyguardDisabled()
DevicePolicyManager.setStatusBarDisabled()
PackageInstaller.createSession()