Neue Funktionen von Android 9 für Unternehmens-Apps

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.

Abbildung 1: Privater und geschäftlicher Tab des Standard-Launchers mit einem Schieberegler für das Arbeitsprofil

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:

  1. 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.
  2. Rufen Sie getProfileSwitchingIconDrawable() auf, um ein Symbol zu erhalten, das Sie für ein anderes Profil verwenden können.
  3. Rufe getProfileSwitchingLabel() auf, um lokalisierten Text zu erhalten, der den Nutzer zum Wechseln des Profils auffordert.
  4. 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:

  1. Rufen Sie DevicePolicyManager.setLockTaskPackages() auf, um Apps für den Sperrmodusmodus auf die Zulassungsliste zu setzen.
  2. 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:

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:

  1. Legen Sie das Flag MAKE_USER_EPHEMERAL fest, wenn Sie DevicePolicyManager.createAndManageUser() aufrufen.
  2. 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:

Ereignisnachrichten für Nutzer anzeigen

Geräteinhaber können die Mitteilungen konfigurieren, die Nutzern beim Starten und Beenden ihrer Sitzungen angezeigt werden:

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:

  1. Rufen Sie DevicePolicyManager.setKeepUninstalledPackages() auf, um die Liste der Pakete anzugeben, die als APKs beibehalten werden sollen. Rufen Sie DevicePolicyManager.getKeepUninstalledPackages() auf, um eine Liste dieser Pakete abzurufen.

  2. Rufen Sie DevicePolicyManager.installExistingPackage() auf, um ein Paket zu installieren, das nach dem Entfernen über setKeepUninstalledPackages() 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:

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:

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:

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:

  1. 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.
  2. Der Quell-DPC ruft transferOwnership() auf, um die Übertragung zu starten.
  3. Das System macht den Ziel-DPC zum aktiven Administrator und legt ihn als Inhaber des verwalteten Geräts oder Arbeitsprofils fest.
  4. Der Ziel-DPC empfängt den Callback onTransferOwnershipComplete() und kann ihn mit Werten aus dem Argument bundle selbst konfigurieren.
  5. 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:

  1. Übertragen Sie zuerst die Eigentümerschaft des Arbeitsprofils.
  2. Warten Sie auf den DeviceAdminReceiver-Callback onTransferAffiliatedProfileOwnershipComplete(), um zu bestätigen, dass das Arbeitsprofil auf den Ziel-DPC übertragen wurde.
  3. Ü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 (siehe KeyPairGenerator) 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 oder ID_TYPE_MEID im Argument idAttestationFlags. Das zurückgegebene Zertifikat enthält die Hardware-IDs im Attestierungsdatensatz. Wenn Sie die Hardware-IDs nicht angeben möchten, übergeben Sie 0. Profilinhaber können nur Herstellerinformationen erhalten, indem sie ID_TYPE_BASE_INFO übergeben. Rufe isDeviceIdAttestationSupported() 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 folgenden DevicePolicyManager-Methoden auf:

Durch die Kombination dieser APIs können Unternehmen Geräte sicher identifizieren und deren Integrität bestätigen, bevor sie Zugriff gewähren:

  1. 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.
  2. 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.
  3. Der Server validiert die Zertifikatskette (gerootet mit einem Google-Zertifikat) und extrahiert die Gerätemetadaten aus dem Attestierungsdatensatz.
  4. 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.
  5. Der Server generiert ein Zertifikat von der CSR und sendet es an das Gerät.
  6. 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.

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:

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: