Neue Funktionen von Android 9 für Unternehmens-Apps

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">
</ph>
Abbildung 1: Persönlicher und geschäftlicher Tab im Standard-Launcher mit dem Wechsel des Arbeitsprofils

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:

  1. 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.
  2. getProfileSwitchingIconDrawable() anrufen um ein Symbol zu erhalten, das Sie zur Darstellung eines anderen Profils verwenden können.
  3. Rufen Sie getProfileSwitchingLabel() an, um lokalisierter Text, der den Nutzer zum Wechseln des Profils auffordert
  4. 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:

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

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:

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

Ereignisnachrichten für Nutzer anzeigen

Geräteeigentümer können die Mitteilungen konfigurieren, die Nutzern angezeigt werden, wenn sie ihre Sitzungen beginnen und beenden:

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:

  1. Anruf DevicePolicyManager.setKeepUninstalledPackages() , um die Liste der Pakete anzugeben, die als APKs beibehalten werden sollen. So rufen Sie eine Liste dieser pakete, anrufen DevicePolicyManager.getKeepUninstalledPackages()

  2. DevicePolicyManager.installExistingPackage() anrufen ein Paket zu installieren, das nach dem Entfernen über setKeepUninstalledPackages()

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:

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:

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:

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:

  1. 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.
  2. Der Quell-DPC ruft transferOwnership() auf, um den übertragen werden.
  3. Das System legt den Ziel-DPC als aktiven Administrator fest und legt fest, als Eigentümer des verwalteten Geräts oder Arbeitsprofils.
  4. Der Ziel-DPC empfängt den Callback. onTransferOwnershipComplete() und kann konfigurieren mithilfe von Werten aus dem Argument bundle.
  5. 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:

  1. Übertragen Sie zuerst die Eigentümerschaft des Arbeitsprofils.
  2. Auf DeviceAdminReceiver-Callback warten onTransferAffiliatedProfileOwnershipComplete() um zu bestätigen, dass das Arbeitsprofil an den Ziel-DPC übertragen wurde.
  3. 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 (siehe KeyPairGenerator) 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 von ID_TYPE_BASE_INFO, ID_TYPE_SERIAL, ID_TYPE_IMEI oder ID_TYPE_MEID im idAttestationFlags Argument. Das zurückgegebene Zertifikat enthält die Hardware IDs im Attestierungseintrag. Wenn du die Hardware-IDs nicht verwenden möchtest, übergib 0 Profilinhaber können nur Herstellerinformationen erhalten, indem sie ID_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 folgenden DevicePolicyManager-Methoden auf: <ph type="x-smartling-placeholder">

Durch die Kombination dieser APIs können Unternehmen Geräte sicher identifizieren und ihre Integrität überprüfen, bevor Sie ihnen Zugriff gewähren:

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

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:

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: