Diese Seite bietet einen Überblick über die APIs, Funktionen und Verhaltensweisen von Unternehmen die in Android 9 verfügbar sind.
Benutzeroberfläche des Arbeitsprofils
Android 9 (API-Level 28) enthält in der Standardeinstellung Änderungen an der Benutzeroberfläche Launcher, mit dem Nutzer private und geschäftliche Apps voneinander trennen können. Gerätehersteller kann dies den Nutzenden Apps in separaten Tabs für geschäftliche und private Zwecke. Außerdem können Gerätenutzer Arbeitsprofile jetzt noch einfacher aktivieren und deaktivieren: einschließlich eines Schalters auf dem Tab „Arbeit“ des Launchers.
<ph type="x-smartling-placeholder">![](https://developer.android.com/static/images/about/versions/pie/p-work-profile.jpg?authuser=19&hl=de)
Bei der Bereitstellung von Arbeitsprofilen und verwalteten Geräten umfasst Android 9 animierte Illustrationen, damit Gerätenutzer diese Funktionen besser verstehen.
Apps zwischen Profilen wechseln
Android 9 enthält APIs, mit denen eine weitere App-Instanz in einer anderen App gestartet werden kann.
Profil, um Nutzern den Wechsel zwischen Konten zu erleichtern. Eine E-Mail-App kann beispielsweise
Eine Benutzeroberfläche, über die Nutzer zwischen dem privaten Profil und dem Arbeitsprofil wechseln können
Profil auf zwei E-Mail-Konten zugreifen. Alle Apps können diese APIs aufrufen, um die
Hauptaktivität derselben App, wenn diese bereits im anderen Profil installiert ist. Bis
um einen profilübergreifenden Kontowechsel zu Ihrer App hinzuzufügen, führen Sie die folgenden Schritte aus:
Methoden der
Klasse CrossProfileApps
:
- Rufen Sie
getTargetUserProfiles()
auf, um eine Liste der Profilen, in denen Sie eine weitere Instanz der App starten können. Mit dieser Methode wird geprüft, die Anwendung in den Profilen installiert ist. getProfileSwitchingIconDrawable()
anrufen um ein Symbol zu erhalten, das Sie zur Darstellung eines anderen Profils verwenden können.- Rufen Sie
getProfileSwitchingLabel()
an, um lokalisierter Text, der den Nutzer zum Wechseln des Profils auffordert - Rufen Sie
startMainActivity()
auf, um eine Instanz von Ihre Anwendung in einem anderen Profil.
Prüfen Sie, ob die Hauptaktivität, die Sie starten möchten, in der
Manifestdatei mit einer ACTION_MAIN
-Intent-Aktion und enthält
eine CATEGORY_LAUNCHER
-Intent-Kategorie.
Arbeitsprofile programmatisch aktivieren oder deaktivieren
Der Standard-Launcher (oder Apps mit der Berechtigung MANAGE_USERS
oder
MODIFY_QUIET_MODE
) kann das Arbeitsprofil durch folgenden Anruf aktivieren oder deaktivieren:
UserManager.requestQuietModeEnabled()
Sie können
den Rückgabewert prüfen, um zu erfahren, ob Nutzende ihre
Anmeldedaten vor, bevor sich der Status ändert. Weil die Änderung vielleicht nicht
hören Sie auf das Ereignis
ACTION_MANAGED_PROFILE_AVAILABLE
oder
ACTION_MANAGED_PROFILE_UNAVAILABLE
um zu erfahren, wann die Benutzeroberfläche aktualisiert werden muss.
Deine App kann den Status des Arbeitsprofils prüfen, indem sie Folgendes aufruft:
UserManager.isQuietModeEnabled()
Apps auf einem Gerät sperren
Ab Android 9: Geräteinhaber und Profilinhaber (von sekundären Nutzern) können jede App auf dem Bildschirm eines Geräts sperren, indem Sie die App in den Modus „Aufgaben sperren“ versetzen. Bisher mussten App-Entwickler Unterstützung für die Aufgabe „Sperren“ hinzufügen, Modus in ihren Apps aktivieren. Android 9 erweitert außerdem die APIs für Profilinhaber von nicht verbundenen sekundären Nutzern Gehen Sie dazu so vor: um eine App auf dem Bildschirm zu sperren:
DevicePolicyManager.setLockTaskPackages()
anrufen für Apps für den Sperrmodusmodus auf die Zulassungsliste setzen.- Zum Starten
ActivityOptions.setLockTaskEnabled()
anrufen einer App auf der Zulassungsliste in den Sperrmodusmodus versetzt werden.
Wenn Sie eine App im Modus „Aufgaben sperren“ beenden möchten, entfernen Sie die App aus dem Modus „Aufgaben sperren“
Zulassungsliste mit
DevicePolicyManager.setLockTaskPackages()
Funktionen der System-Benutzeroberfläche aktivieren
Wenn der Modus „Aufgaben sperren“ aktiviert ist, können Geräteinhaber und Profilinhaber Folgendes aktivieren:
bestimmte Funktionen der Benutzeroberfläche auf dem Gerät
DevicePolicyManager.setLockTaskFeatures()
und übergeben einen
der folgenden Funktions-Flags:
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
Du kannst DevicePolicyManager.getLockTaskFeatures()
anrufen
, um eine Liste der Funktionen abzurufen, die auf einem Gerät verfügbar sind, wenn der Modus „Aufgaben sperren“ aktiviert ist
aktiviert. Wenn ein Gerät den Modus „Gesperrte Aufgabe“ beendet, kehrt es in den vom
andere Geräterichtlinien.
Fehlerdialogfelder unterdrücken
In einigen Umgebungen, z. B. bei Demonstrationen im Einzelhandel oder bei öffentlichen Informationen
sollten Sie Nutzern keine Fehlerdialogfelder anzeigen. Eine Geräterichtlinie
Der Controller (DPC) kann Systemfehlerdialoge bei Absturz oder Nichtreaktion unterdrücken
hinzufügen, indem Sie die
DISALLOW_SYSTEM_ERROR_DIALOGS
-Nutzer
Einschränkung. Diese Einschränkung wirkt sich auf alle Dialogfelder aus, wenn sie von einem Geräteeigentümer angewendet wird
aber nur die Fehlerdialogfelder des primären oder sekundären Nutzers werden unterdrückt.
, wenn die Einschränkung von Profilinhabern angewendet wird. Diese Einschränkung gilt nicht
Arbeitsprofile auswirken.
Unter Android 9 werden Apps, die im immersiven Vollbildmodus ausgeführt werden, angezeigt wird, wird das Infofeld nicht angezeigt, wenn Modus „Gesperrt“. Das Infofeld für die Erinnerung ist ein Bereich, der Nutzern beim ersten Start angezeigt wird wie der immersive Modus beendet wird.
Unterstützung mehrerer Nutzer auf zweckbestimmten Geräten
Mit Android 9 wird das Konzept des flüchtigen Nutzers für dedizierte Geräte (früher als COSU-Geräte bezeichnet). Sitzungsspezifische Nutzer Langzeitnutzer in Fällen, in denen mehrere Nutzer ein gemeinsames zweckbestimmtes Gerät. Dazu gehören auch öffentliche Nutzersitzungen auf Geräten wie z. B. in der Bibliothek oder Check-in-Kioske in Gastgewerben sowie dauerhafte Sitzungen zwischen festen Gruppe von Nutzern mit Geräten, z. B. Schichtarbeiter.
Sitzungsspezifische Nutzer sollten im Hintergrund erstellt werden. Sie werden erstellt als sekundäre Nutzer auf einem Gerät und werden entfernt (einschließlich zugehöriger Apps und Daten), wenn sie gestoppt, gewechselt oder das Gerät neu gestartet werden. So erstellen Sie ein flüchtigen Nutzern, können Geräteeigentümer Folgendes tun:
- Legen Sie beim Aufruf das Flag
MAKE_USER_EPHEMERAL
fest.DevicePolicyManager.createAndManageUser()
DevicePolicyManager.startUserInBackground()
anrufen um den flüchtigen Nutzer im Hintergrund zu starten.
Hinweis: Apps, die auf Android 9 ausgerichtet sind, sollten
UserManager.UserOperationException
beim Anruf
createAndManageUser()
. Rufen Sie die Methode
getUserOperationResult()
-Methode, um herauszufinden,
Nutzer wurde nicht erstellt.
Terminbenachrichtigungen erhalten
Das DeviceAdminReceiver
erhält Benachrichtigungen für
folgende Ereignisse:
onUserStarted()
: Wird beim Start eines Nutzers aufgerufen.onUserSwitched()
: Wird bei einem Nutzerwechsel aufgerufen abgeschlossen ist.onUserStopped()
: Wird zusammen mitonUserRemoved()
, wenn ein Nutzer stoppt oder das Protokoll durchführt raus.
Ereignisnachrichten für Nutzer anzeigen
Geräteeigentümer können die Mitteilungen konfigurieren, die Nutzern angezeigt werden, wenn sie ihre Sitzungen beginnen und beenden:
- Verwenden Sie
DevicePolicyManager.setStartUserSessionMessage()
, um die Nachricht festzulegen, die einem Nutzer zu Beginn seiner Sitzung angezeigt wird. Bis die Nachricht abrufen, dieDevicePolicyManager.getStartUserSessionMessage()
- Verwenden Sie
DevicePolicyManager.setEndUserSessionMessage()
, um festzulegen, welche Nachricht dem Nutzer am Ende seiner Sitzung angezeigt wird. Bis die Nachricht abrufen, dieDevicePolicyManager.getEndUserSessionMessage()
Abmelden und Nutzer stoppen
Geräteeigentümer können
DevicePolicyManager.setLogoutEnabled()
, um anzugeben, ob
Abmeldung ist für sekundäre Nutzer aktiviert. Um zu überprüfen, ob die Abmeldung aktiviert ist, rufen Sie
DevicePolicyManager.isLogoutEnabled()
Profilinhaber sekundärer Nutzer können Anrufe tätigen.
DevicePolicyManager.logoutUser()
, um den sekundären Nutzer zu stoppen und
wieder zum primären Nutzer wechseln.
Geräteeigentümer können mit DevicePolicyManager.stopUser()
Folgendes beenden:
der angegebene sekundäre Nutzer ist.
Paket-Caching
Um die Nutzerverwaltung auf gemeinsam verwendeten Geräten mit einer festen Nutzergruppe zu optimieren, z. B. Geräte für Schichtarbeiter, können Pakete im Cache gespeichert werden, erforderlich für Sitzungen mit mehreren Nutzern:
Anruf
DevicePolicyManager.setKeepUninstalledPackages()
, um die Liste der Pakete anzugeben, die als APKs beibehalten werden sollen. So rufen Sie eine Liste dieser pakete, anrufenDevicePolicyManager.getKeepUninstalledPackages()
DevicePolicyManager.installExistingPackage()
anrufen ein Paket zu installieren, das nach dem Entfernen übersetKeepUninstalledPackages()
Zusätzliche Methoden und Konstanten
Android 9 enthält außerdem die folgenden Methoden und Konstanten zur weiteren Unterstützung. Nutzersitzungen auf gemeinsam verwendeten Geräten:
DevicePolicyManager.getSecondaryUsers()
ruft eine Liste mit für alle sekundären Nutzer auf einem Gerät.DISALLOW_USER_SWITCH
ist eine Nutzereinschränkung, die Sie durch Aufrufen vonDevicePolicyManager.addUserRestriction()
, um den Nutzerwechsel zu blockieren.LEAVE_ALL_SYSTEM_APPS_ENABLED
ist ein Flag. verfügbar fürDevicePolicyManager.createAndManageUser()
Wenn festgelegt, System-Apps werden während der Nutzerverwaltung nicht deaktiviert.UserManager.UserOperationException
wird ausgelöst vonDevicePolicyManager.createAndManageUser()
, wenn ein Nutzer nicht erstellt werden kann, also den Ausnahme enthält den Grund für den Fehler.
Paketdaten löschen und Konten entfernen
Geräteinhaber und Profilinhaber können Anrufe
clearApplicationUserData()
, um die Nutzerdaten zu löschen
für ein bestimmtes Paket. So entfernen Sie ein Konto aus der
AccountManager
, Geräte- und Profilinhaber können anrufen
removeAccount()
Nutzereinschränkungen und mehr Kontrolle über Einstellungen
Mit Android 9 werden eine Reihe von Nutzerbeschränkungen für DPCs eingeführt. Konfiguration von APNs, Uhrzeit und Zeitzone sowie Systemeinstellungen auf einem Gerät
APNs konfigurieren
Geräteeigentümer können die folgenden Methoden in der
DevicePolicyManager
-Klasse zum Konfigurieren von APNs für eine
Gerät:
addOverrideApn()
updateOverrideApn()
removeOverrideApn()
getOverrideApns()
setOverrideApnEnabled()
isOverrideApnEnabled()
Uhrzeit und Zeitzone konfigurieren
Geräteeigentümer können die folgenden Methoden in der
DevicePolicyManager
-Klasse zum Festlegen der Uhrzeit und Zeitzone
auf einem Gerät:
Nutzerbeschränkungen für wichtige Einstellungen erzwingen
Android 9 fügt Nutzerbeschränkungen hinzu, um Systemfunktionen und -einstellungen zu deaktivieren. Bis
Einschränkung hinzufügen,
DevicePolicyManager.addUserRestriction()
durch einen der
folgende UserManager
-Konstanten:
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
erzwungen
können Geräteeigentümer immer noch das Display
Helligkeit, Displayhelligkeit
Einstellungen für den Modus und das Display automatisch ausschalten
auf dem Gerät mithilfe der API
DevicePolicyManager.setSystemSetting()
.
Kostenpflichtige Daten
Geräte- und Profilinhaber können verhindern, dass Apps die
Datennetzwerken. Ein Netzwerk gilt als kostenpflichtig, wenn der Nutzer
aufgrund von Kosten, Datenlimits oder Akku- und
Probleme mit der Leistung. Um zu verhindern, dass Apps kostenpflichtige Netzwerke nutzen, rufe
DevicePolicyManager.setMeteredDataDisabledPackages()
und übergibt eine Liste von Paketnamen. Rufen Sie zum Abrufen der derzeit eingeschränkten Apps Folgendes auf:
DevicePolicyManager.getMeteredDataDisabledPackages()
Weitere Informationen zu kostenpflichtigen Daten in Android finden Sie unter Netzwerkdaten optimieren Nutzung.
DPCs migrieren
Device Policy Controller (DPCs) können die Eigentümerschaft eines Geräts oder Arbeitsprofil zu einem anderen DPC zu übertragen. Sie können die Eigentümerschaft übertragen, um einige Funktionen zu verschieben die Seite Android Management API, um Geräte von Ihren alten DPC oder um IT-Administratoren bei der Migration zu Ihrem EMM zu unterstützen. Weil Sie nur wenn Sie die DPC-Inhaberschaft ändern, können Sie mit dieser Funktion nicht den Typ z. B. bei der Migration von einem verwalteten Gerät zu einem Arbeitsprofil oder und umgekehrt.
Mit der XML-Ressource Richtlinien für die Geräteverwaltung können Sie
geben an, dass diese Version Ihres DPC die Migration unterstützt. Ziel-DPC
gibt an, dass er die Eigentümerschaft annehmen kann, indem er ein Element namens
<support-transfer-ownership>
Das folgende Beispiel zeigt, wie Sie dies in
der Device Admin-XML-Datei Ihres DPCs:
<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 zu einer neuen DPC-App übertragen möchten, können prüfen, ob ein Ziel-DPC
Version unterstützt die Migration durch Aufrufen der Methode DeviceAdminInfo
supportsTransferOwnership()
Vor der Übertragung
liegt es in der Verantwortung des Quell-DPCs, den Ziel-DPC zu verifizieren,
App-Signaturen vergleichen. Die Klasse PackageManager
umfasst Folgendes:
für Codesignaturen.
Android verwaltet die System- und Nutzerrichtlinien des Quell-DPC über eine Inhaberschaft
Übertragung: DPCs müssen diese nicht migrieren. Ein Quell-DPC kann benutzerdefinierte Daten an
den Ziel-DPC mithilfe von Schlüssel/Wert-Paaren in einem PersistableBundle
. Nach einem
erfolgreich übertragen wurde, kann der Ziel-DPC diese Daten abrufen, indem er Folgendes aufruft:
DevicePolicyManager.getTransferOwnershipBundle()
Die Schritte zum Übertragen der Eigentümerschaft eines verwalteten Geräts oder eines Arbeitsprofils sind gleich:
- Der Quell-DPC prüft, ob die Version des Ziel-DPC Migration unterstützt und bestätigt, dass die App-Signatur des Ziel-DPCs mit einem erwarteten Wert übereinstimmt.
- Der Quell-DPC ruft
transferOwnership()
auf, um den übertragen werden. - Das System legt den Ziel-DPC als aktiven Administrator fest und legt fest, als Eigentümer des verwalteten Geräts oder Arbeitsprofils.
- Der Ziel-DPC empfängt den Callback.
onTransferOwnershipComplete()
und kann konfigurieren mithilfe von Werten aus dem Argumentbundle
. - Wenn bei der Übertragung ein Fehler auftritt, geht die Inhaberschaft wieder auf
Quell-DPC. Wenn Ihr Quell-DPC bestätigen muss, dass die Übertragung der Inhaberschaft
erfolgreich war, rufen Sie
isAdminActive()
auf, um zu prüfen, ob der Quell-DPC ist nicht mehr der aktive Administrator.
Alle im Arbeitsprofil ausgeführten Apps erhalten den
ACTION_PROFILE_OWNER_CHANGED
wird übertragen, wenn
ändert sich der Profilinhaber. Apps, die auf einem verwalteten Gerät ausgeführt werden, erhalten den
ACTION_DEVICE_OWNER_CHANGED
wird übertragen, wenn der
Änderungen des Geräteeigentümers an.
Arbeitsprofile auf vollständig verwalteten Geräten
Übertragung von zwei Instanzen eines DPC, die als Geräteinhaber und Profilinhaber ausgeführt werden erfolgt in zwei Phasen. Wenn das private Profil und das Arbeitsprofil verknüpft sind, schließen Sie die Übertragung in der folgenden Reihenfolge ab:
- Übertragen Sie zuerst die Eigentümerschaft des Arbeitsprofils.
- Auf
DeviceAdminReceiver
-Callback wartenonTransferAffiliatedProfileOwnershipComplete()
um zu bestätigen, dass das Arbeitsprofil an den Ziel-DPC übertragen wurde. - Abschließend übertragen Sie die Inhaberschaft des verwalteten Geräts auf den Ziel-DPC.
Over-the-Air-Updates (OTA) 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 (z. B. Feiertage). Das System erzwingt einen obligatorischen 60-Tage-Puffer nach einem definierten um zu verhindern, dass das Gerät auf unbestimmte Zeit eingefroren wird.
Während der Sperrzeit gilt Folgendes:
- Geräte erhalten keine Benachrichtigungen über ausstehende 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.
Um eine Sperrzeit festzulegen, rufen Sie
SystemUpdatePolicy.setFreezePeriods()
Weil die Zeit gekommen ist,
die Periode jährlich wiederholt wird, werden das Start- und Enddatum des Zeitraums dargestellt.
durch Ganzzahlen, die die Anzahl der Tage seit Jahresbeginn zählen. Der Starttag muss
mindestens 60 Tage nach dem Ende eines vorherigen Sperrzeitraums beginnen. Gerät
Inhaber können SystemUpdatePolicy.getFreezePeriods()
anrufen, um
Eine Liste der zuvor für das Richtlinienobjekt für Systemupdates festgelegten Sperrzeiten abrufen
DevicePolicyManager.getSystemUpdatePolicy()
wurde
aktualisiert, um alle vom Geräteeigentümer festgelegten Sperrzeiträume zurückzugeben.
Freigabe in einem Arbeitsprofil einschränken
Profilinhaber können verhindern, dass Nutzer personenbezogene Daten in einem Arbeitsprofil teilen
auf dem Gerät, indem Sie die Nutzerbeschränkung
DISALLOW_SHARE_INTO_MANAGED_PROFILE
Durch diese Einschränkung wird die folgende Verarbeitung und Freigabe von Intents verhindert:
- Apps im privaten Profil, die Daten und Dateien mit Apps im Arbeitsprofil teilen
- Apps im Arbeitsprofil, die Elemente aus dem privaten Profil auswählen, z. B. Bilder oder Dateien.
Nachdem du diese Einschränkung festgelegt hast, kann dein DPC weiterhin profilübergreifende Aktivitäten zulassen
durch Aufrufen von
addCrossProfileIntentFilter()
Hardware-gesicherte Schlüssel und Computerzertifikate
Unter Android 9 werden APIs hinzugefügt, die Sie bei der Arbeit mit Schlüsseln und Zertifikaten unterstützen, die Sie um Geräte sicher zu identifizieren. Ein DPC, der im Profilinhaber oder auf dem Gerät ausgeführt wird oder ein Installationsprogramm für delegierte Zertifikate die folgenden Aufgaben ausführen:
- Generieren Sie Schlüssel und Zertifikate auf der sicheren Hardware (z. B. einer vertrauenswürdigen
Ausführungsumgebung (TEE) oder Secure Element (SE) des Android-Geräts. Die
generierte Schlüssel verlassen niemals die sichere Hardware und können vom Android-System
KeyChain aus. Anruf
DevicePolicyManager.generateKeyPair()
mit dem Parameter (sieheKeyPairGenerator
) und die Hardware-IDs, die Sie z. B. die Seriennummer oder IMEI. Weitere Informationen zur Sicherheit Hardware-Änderungen, siehe Android 9 Security Verbesserungen. - Verknüpfen Sie ein Zertifikat mit einem vorhandenen vom Gerät generierten Schlüssel. Anruf
Von
DevicePolicyManager.setKeyPairCertificate()
bereitgestellt Alias des vorhandenen Schlüssels und der Zertifikatskette – beginnend mit dem Blatt und die Vertrauenskette der Reihe nach einbezogen. - Prüfen Sie, ob die sichere Hardware den Schlüssel schützt, bevor Sie ihn verwenden. Zur Überprüfung welche Mechanismen den Schlüssel schützen, befolgen Sie die Schritte unter Schlüssel Bestätigung.
- Geräteinhaber und delegierte Zertifikatinstallationen können ein signiertes
die Beschreibung der Geräte, Hardware-IDs mit Android-Systemversionen. Anruf
DevicePolicyManager.generateKeyPair()
übergeben mindestens eine vonID_TYPE_BASE_INFO
,ID_TYPE_SERIAL
,ID_TYPE_IMEI
oderID_TYPE_MEID
imidAttestationFlags
Argument. Das zurückgegebene Zertifikat enthält die Hardware IDs im Attestierungseintrag. Wenn du die Hardware-IDs nicht verwenden möchtest, übergib0
Profilinhaber können nur Herstellerinformationen erhalten, indem sieID_TYPE_BASE_INFO
. Rufen Sie auf, um zu prüfen, ob das Gerät IDs attestieren kann.isDeviceIdAttestationSupported()
- Verhindern, dass Gerätenutzer Unternehmensschlüssel missbrauchen (bei Aufgaben außerhalb des Unternehmens)
indem Sie die Schlüsselzertifikate nicht auswählen. Das System enthält keine
nicht auswählbare Zertifikate. In der
DeviceAdminReceiver.onChoosePrivateKeyAlias()
Callback-Methode verwenden, geben Sie den Alias an Ihren Unternehmensschlüssel zurück, damit das System das Zertifikat automatisch im Namen des Nutzers auswählt. Schlüssel erstellen nicht auswählbar sind, rufen Sie die folgendenDevicePolicyManager
-Methoden auf: <ph type="x-smartling-placeholder">- </ph>
setKeyPairCertificate()
und Übergeben Siefalse
für dasisUserSelectable
-Argument.installKeyPair (ComponentName, PrivateKey, Certificate[], String, int)
und lassen SieINSTALLKEY_SET_USER_SELECTABLE
aus Das Argumentflags
Durch die Kombination dieser APIs können Unternehmen Geräte sicher identifizieren und ihre Integrität überprüfen, bevor Sie ihnen Zugriff gewähren:
- Das Android-Gerät generiert auf der sicheren Hardware einen neuen privaten Schlüssel. 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 Zertifikatssignierung zu erstellen und zu senden (CSR) an den Server zu senden. Die CSR enthält den Attestierungseintrag mit dem Geräte-IDs.
- Der Server validiert die Zertifikatskette (gerootet mit einem Google-Zertifikat). und extrahiert die Gerätemetadaten aus dem Attestierungseintrag.
- Der Server bestätigt, dass die sichere Hardware den privaten Schlüssel schützt und ob die Geräte-IDs mit den Daten des Unternehmens übereinstimmen. Der Server kann auch prüfen, ob das Android-System und die Patchversionen alle Anforderungen erfüllen.
- Der Server generiert ein Zertifikat aus der CSR und sendet das Zertifikat an auf dem Gerät.
- Das Gerät koppelt das Zertifikat mit dem privaten Schlüssel (der im sichere Hardware), mit der Apps eine Verbindung zu Unternehmensdiensten herstellen können.
Weitere Sicherheits-APIs, -Funktionen und -Änderungen
IDs für Sicherheits- und Netzwerkprotokolle
Android 9 enthält IDs in Sicherheits- und Netzwerkaktivitätsprotokollen. Die numerische ID monoton für jedes Ereignis ansteigt, wodurch es für IT-Administratoren einfacher ist, Lücken in ihren Logs hat. Da Sicherheitsprotokolle und Netzwerkprotokolle getrennt sind verwaltet das System separate ID-Werte.
Rufen Sie uns unter SecurityEvent.getId()
an.
DnsEvent.getId()
oder
ConnectEvent.getId()
, um den ID-Wert abzurufen. Das System
Die ID wird zurückgesetzt, wenn ein DPC die Protokollierung aktiviert oder das Gerät neu startet.
Sicherheitsprotokolle, die durch den Aufruf abgerufen wurden
DevicePolicyManager.retrievePreRebootSecurityLogs()
enthalten sind.
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 Log-Ebene zurück,
entweder LEVEL_INFO
, LEVEL_WARNING
oder
LEVEL_ERROR
Android 9 protokolliert die in der folgenden Tabelle aufgeführten Ereignisse unter
Logs Rufen Sie getTag()
auf, um das Tag eines Ereignisses zu prüfen. Bis
Rufen Sie getData()
auf.
Taggen | Ereignisbeschreibung |
---|---|
TAG_CERT_AUTHORITY_INSTALLED |
Versuch, ein neues Root-Zertifikat im Anmeldeinformationsspeicher des Systems zu installieren. |
TAG_CERT_AUTHORITY_REMOVED |
Versuch, ein Root-Zertifikat aus dem Anmeldeinformationsspeicher des Systems zu entfernen. |
TAG_CERT_VALIDATION_FAILURE |
Die Validierung eines WLAN-Zertifikats während der Verbindung ist fehlgeschlagen. |
TAG_CRYPTO_SELF_TEST_COMPLETED |
Das System hat den kryptografischen Selbsttest abgeschlossen. |
TAG_KEYGUARD_DISABLED_FEATURES_SET |
Durch eine Admin-App wurden Funktionen auf dem Sperrbildschirm eines Geräts oder eines 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 durch Sicherheitsprotokollierung gestartet. |
TAG_LOGGING_STOPPED |
Aufzeichnung durch Sicherheitsprotokollierung beendet. |
TAG_LOG_BUFFER_SIZE_CRITICAL |
Der Zwischenspeicher des Sicherheitsprotokolls hat 90% seiner Kapazität erreicht. |
TAG_MAX_PASSWORD_ATTEMPTS_SET |
Eine Admin-App hat die Anzahl der zulässigen Versuche mit einem falschen Passwort festgelegt. |
TAG_MAX_SCREEN_LOCK_TIMEOUT_SET |
Eine Admin-App hat ein maximales Zeitlimit für die Displaysperre festgelegt. |
TAG_MEDIA_MOUNT |
Das auf dem Gerät bereitgestellte Wechselspeichermedium. |
TAG_MEDIA_UNMOUNT |
Das Gerät hat die Bereitstellung des Wechseldatenträgers aufgehoben. |
TAG_OS_SHUTDOWN |
Das Android-System wurde heruntergefahren. |
TAG_OS_STARTUP |
Das Android-System wurde gestartet. |
TAG_PASSWORD_COMPLEXITY_SET |
Eine Admin-App legt Anforderungen an die Passwortkomplexität fest. |
TAG_PASSWORD_EXPIRATION_SET |
Eine Admin-App hat eine Gültigkeitsdauer für das Passwort festgelegt. |
TAG_PASSWORD_HISTORY_LENGTH_SET |
Eine Admin-App legt eine Länge des Passwortverlaufs fest, sodass Nutzer alte Passwörter nicht wiederverwenden können. |
TAG_REMOTE_LOCK |
Das Gerät oder das Arbeitsprofil wurde von einer Administrator-App gesperrt. |
TAG_USER_RESTRICTION_ADDED |
Eine Admin-App hat eine Nutzereinschränkung festgelegt. |
TAG_USER_RESTRICTION_REMOVED |
Eine Administrator-App hat eine Nutzereinschränkung aufgehoben. |
TAG_WIPE_FAILURE |
Ein Versuch, ein Gerät oder Arbeitsprofil zu löschen, ist fehlgeschlagen. |
Herausforderung auf dem Sperrbildschirm des Arbeitsprofils
Ab Android 9 können Profilinhaber von Nutzern verlangen, eine separate Sperre einzurichten
Bildschirm-Herausforderung für ihr Arbeitsprofil mit der
DISALLOW_UNIFIED_PASSWORD
-Nutzereinschränkung. Bis
Prüfen, ob ein Nutzer dieselbe Identitätsbestätigung auf dem Sperrbildschirm für sein Gerät eingerichtet hat und
arbeitsprofil, anruf
DevicePolicyManager.isUsingUnifiedPassword()
Wenn ein Gerät einen separaten Sperrbildschirm für das Arbeitsprofil hat,
Mit DevicePolicyManager.setMaximumTimeToLock()
wird nur ein
Zeitlimit für die Displaysperre gilt nicht für das gesamte Gerät, sondern für das Arbeitsprofil.
Zugriff auf Entwicklertools
Damit Arbeitsdaten im Arbeitsprofil verbleiben, hat das ADB-Tool (Android Debug Bridge) kann nicht auf Verzeichnisse und Dateien im Arbeitsprofil zugreifen.
Unterstützung weiterer biometrischer Optionen
Android 9 bietet eine präzise Steuerung der biometrischen Hardware-Authentifizierung in einem
auf dem Sperrbildschirm des Arbeitsprofils. Vorhandenen
DevicePolicyManager.setKeyguardDisabledFeatures()
mit KEYGUARD_DISABLE_FACE
und
KEYGUARD_DISABLE_IRIS
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 device Administrator. Die Richtlinien funktionieren weiterhin. wie bisher in Android 9. Ab Android 10 eine SecurityException auslösen, wenn sie von einem Geräteadministrator aufgerufen wird.
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 Geräteverwaltung für Verbraucher. Für z. B. das Sperren und Löschen eines verlorenen Geräts. Die folgenden Richtlinien werden weiterhin verfügbar sein, um dies zu ermöglichen:
Weitere Informationen zu diesen Änderungen finden Sie unter Geräteadministrator Einstellung.
Optimierte QR-Code-Registrierung
Integrierte QR-Bibliothek
Android 9 wird mit einer QR-Bibliothek geliefert, um das QR-Code-Gerät zu optimieren Nutzerverwaltung. IT-Administratoren müssen bei der Einrichtung nicht mehr manuell WLAN-Daten eingeben auf einem Gerät. Mit Android 9 ist es jedoch möglich, diese WLAN-Details anzugeben. in einem QR-Code. Wenn ein IT-Administrator den QR-Code mit einer unternehmenseigenen App scannt stellt das Gerät automatisch eine WLAN-Verbindung her und führt die ohne zusätzliche manuelle Eingaben verarbeiten.
Die QR-Code-Bereitstellungsmethode unterstützt die folgenden WLAN-Details angeben:
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 erweiterten Funktionen festlegen
Die QR-Code-Bereitstellungsmethode unterstützt die Bereitstellung von Extras, um die Uhrzeit und Zeitzone auf einem Gerät:
Optionen zum Löschen von Daten
Geräteadministratoren können Nutzern beim Entfernen einer Arbeit eine personalisierte Nachricht anzeigen
Profil oder sekundärer Nutzer. Die Mitteilung hilft Gerätenutzern zu verstehen,
Der IT-Administrator hat das Arbeitsprofil oder den sekundären Nutzer entfernt. Anruf
wipeData(int, CharSequence)
und geben Sie ein Kurzvideo ein.
erklärende Nachricht. Bei einem Aufruf durch den Hauptnutzer oder Geräteeigentümer
erscheint keine Meldung und das Gerät wird auf die Werkseinstellungen zurückgesetzt.
Um Abodaten von einer eingebetteten eUICC-SIM zu entfernen, rufen Sie
wipeData()
und WIPE_EUICC
in flags
aufnehmen
.
Methoden für verknüpfte Profilinhaber
Die folgenden Methoden sind für verknüpfte Profile verfügbar. Inhaber:
DevicePolicyManager.setKeyguardDisabled()
DevicePolicyManager.setStatusBarDisabled()
PackageInstaller.createSession()