Diese Seite bietet einen Überblick über die neuen APIs, Funktionen und Verhaltensänderungen in Android 8.0 (API-Level 26), die Android im Unternehmen betreffen.
Neue APIs und Funktionen
Die Modi „Profilinhaber“ und „Geräteinhaber verwalten“ sind jetzt leistungsstärker, produktiver und einfacher als je zuvor bereitzustellen. Außerdem haben wir ein ganz neues Bereitstellungsszenario ermöglicht: Arbeitsprofile auf vollständig verwalteten Geräten. Diese und andere Funktionen werden in den folgenden Abschnitten beschrieben.
Arbeitsprofile auf vollständig verwalteten Geräten
Ab Android 8.0 können vollständig verwaltete Geräte auch Arbeitsprofile haben. Auf diese Weise können Unternehmen Anwendungen und Richtlinien trennen und gleichzeitig die Kontrolle und Sichtbarkeit über beide Profile hinweg beibehalten. Der vorhandene Geräteinhaber oder ein anderer Device Policy Controller (DPC) kann das verwaltete Profil erstellen.
Mit Arbeitsprofilen auf vollständig verwalteten Geräten haben Geräteeigentümer folgende Möglichkeiten:
- Erstellen Sie durch Aufrufen von
EXTRA_PROVISIONING_SKIP_USER_CONSENT
ein verwaltetes Profil ohne Nutzerinteraktion. - Sie erhalten Benachrichtigungen, wenn sekundäre Nutzer oder verwaltete Profile erstellt oder entfernt werden. Die Callbacks sind
onUserAdded()
undonUserRemoved()
. - Verhindern Sie, dass andere DPCs mit
DISALLOW_ADD_MANAGED_PROFILE
verwaltete Profile erstellen. Diese Einstellung ist in Android 8.0 die Standardeinstellung für Geräteeigentümer mit neu bereitgestellten Geräten oder Geräten, die auf Android 8.0 aktualisiert werden. - Geräteinhaber können außerdem verhindern, dass Nutzer vorhandene verwaltete Profile mit
DISALLOW_REMOVE_MANAGED_PROFILE
entfernen.
Geräteinhaber und Profilinhaber können miteinander kommunizieren, wenn sie vom selben APK stammen und verknüpft sind (siehe Nutzerzugehörigkeit unten).
Ausführliche Informationen zur Unterstützung dieses neuen Bereitstellungsszenarios finden Sie auf der entsprechenden Seite für Arbeitsprofile auf vollständig verwalteten Geräten.
Nutzerzugehörigkeit
Wenn ein Geräteinhaber und ein Profilinhaber dieselbe Organisation repräsentieren, gilt Folgendes:
Die Geräte- und Profilinhaber können innerhalb desselben APKs miteinander kommunizieren. Möglicherweise möchten sie Richtlinien oder den Status teilen (siehe Arbeitsprofile auf vollständig verwalteten Geräten oben).
Geräteübergreifende Funktionen wie das Logging oder das Sperren von Aufgaben auf der Zulassungsliste können für verknüpfte Nutzer gelten.
Zugehörigkeits-IDs, die einem Profil oder Nutzer zugeordnet sind, dienen zur Identifizierung von Organisationen. Stimmen die Partner-IDs überein, werden die Nutzer verknüpft. Geräte- und Profilinhaber verwenden setAffiliationIds(), um ihre Zugehörigkeits-IDs festzulegen. Sie stellen Organisationen mit langen, schwer zu erratenden Zeichenfolgen-IDs dar.
Neuer Zugriff für verknüpfte Nutzer
Wenn alle sekundären Nutzer und Profile auf einem Gerät mit dem Geräteinhaber verknüpft sind, sind die folgenden Funktionen verfügbar:
- Sicherheits-Logging mit
setSecurityLoggingEnabled()
. - Logging von Netzwerkaktivitäten mit
setNetworkLoggingEnabled()
. - Fehlerbericht mit
requestBugreport()
wird gemeldet.
Sicherheits-Logging und Fehlerberichte waren bisher nur für Geräte mit einem Nutzer oder mit nur einem Profil und einem Nutzer verfügbar.
Der Modus „Sperraufgabe“ ist für sekundäre Nutzer und verwaltete Profile verfügbar, wenn sie über setLockTaskPackages()
mit dem Geräteinhaber verbunden sind.
Weitere Informationen zur Nutzerzugehörigkeit finden Sie unter Verbundene Nutzer.
Haftungsausschlüsse für benutzerdefinierte Bereitstellung
DPCs können Nutzern jetzt während der Bereitstellung eigene Haftungsausschlüsse anzeigen. Verwenden Sie EXTRA_PROVISIONING_DISCLAIMERS
, EXTRA_PROVISIONING_DISCLAIMER_HEADER
und EXTRA_PROVISIONING_DISCLAIMER_CONTENT
, um Haftungsausschlüsse mit benutzerdefiniertem Text anzugeben. Die benutzerdefinierten Haftungsausschlüsse eines DPC werden in der minimierbaren Liste der Nutzungsbedingungen angezeigt.
Sicherheit
Profilinhaber und Geräteinhaber können mit setRequiredStrongAuthTimeout()
ein Zeitlimit zum Entsperren eines Geräts oder eines Profils mit einer sekundären Authentifizierungsmethode wie Fingerabdrücken oder Trust Agents konfigurieren. Nach Ablauf des Zeitlimits muss der Nutzer das Gerät oder Profil mit einer starken Authentifizierungsmethode wie einem Passwort, einer PIN oder einem Muster entsperren.
Geräteinhaber und Profilinhaber können die Passwörter für Geräte und Arbeitsprofile mit resetPasswordWithToken()
sicher zurücksetzen.
Bei Geräten, die die dateibasierte Verschlüsselung unterstützen, ist diese API verfügbar, bevor ein Nutzer sein Gerät oder Profil entsperrt, sofern der DPC die Verschlüsselung unterstützt.
Wenn Sie ein Arbeitsprofil auf einem Gerät sperren, das die dateibasierte Verschlüsselung unterstützt, kann lockNow(int)
optional die primären Verschlüsselungsschlüssel des Arbeitsprofils mit FLAG_EVICT_CREDENTIAL_ENCRYPTION_KEY
entfernen.
Die Verschlüsselungsschlüssel werden auch entfernt, wenn der Nutzer sein Arbeitsprofil deaktiviert.
Außerdem können Geräteeigentümer mit setNetworkLoggingEnabled()
das Netzwerk-Logging von DNS-Abfragen und TCP-Verbindungen aktivieren, die von unternehmenseigenen Geräten initiiert werden. Weitere Informationen finden Sie unter Logging von Netzwerkaktivitäten.
Profilinhaber können einschränken, welche Pakete des Hauptnutzers Arbeitsprofilbenachrichtigungen abrufen können. Rufen Sie setPermittedCrossProfileNotificationListeners()
auf, um die Pakete auf der Zulassungsliste festzulegen, die Ereignisse über eine NotificationListenerService
empfangen. Wenn Sie die zulässigen Listener auf null
(Standardeinstellung) setzen, wird die Zulassungsliste deaktiviert und alle Pakete können Benachrichtigungen abhören. Übergeben Sie ein leeres Set, um Ereignisse auf Systempakete zu beschränken. Wenn Nutzer Apps aufrufen möchten, die nicht auf Benachrichtigungen des Arbeitsprofils zugreifen können, tippen sie auf Einstellungen > Apps & Benachrichtigungen > Spezieller App-Zugriff > Benachrichtigungszugriff.
Schließlich können Profil- und Geräteinhaber mit getPendingSystemUpdate()
Informationen zu den ausstehenden Systemupdates abrufen, die auf einem Gerät verfügbar sind.
API-Delegierung für die App-Verwaltung
Mithilfe der API-Delegierung können Geräte- und Profilinhaber die App-Verwaltung vollständig auf andere Anwendungen auslagern. Die Klasse DevicePolicyManager
bietet Methoden zum Verwalten der Delegierungsbereiche, die Geräte- und Profilinhaber einem Paket zuweisen können:
- Mit der Methode
setDelegatedScopes()
können Geräte- und Profilinhaber anderen Apps Zugriff auf privilegierte APIs gewähren. - Die Methode
getDelegatedScopes()
gibt die Bereiche zurück, die einem Paket gewährt wurden. getDelegatePackages()
gibt die Pakete mit einem Bereich zurück.
Die folgende Tabelle zeigt, wie verschiedene Methoden in DevicePolicyManager
in die verschiedenen Bereiche organisiert sind:
Lang andauernde Hintergrunddienste
Geräte- und Profilinhaber können abgeleitete Klassen von DeviceAdminService
erstellen, um Hintergrunddienste zu erstellen. Das Android-System versucht, den Dienst während der Ausführung des Nutzers aufrechtzuerhalten.
Wenn Sie regelmäßige Aufgaben ausführen möchten, sollten Sie JobScheduler
verwenden, bevor Sie einen Hintergrunddienst erstellen.
Sicherungsdienst steuern
Geräteeigentümer können den Android Backup Service mit neuen Methoden in DevicePolicyManager
aktivieren oder deaktivieren. Aktivieren und deaktivieren Sie den Sicherungsdienst mit setBackupServiceEnabled()
.
Prüfen Sie den Status des Sicherungsdienstes mit isBackupServiceEnabled()
.
WLAN-Proxy-Konfiguration
Geräteinhaber und Profilinhaber können HTTP-Proxyserver für WLANs konfigurieren. Verwenden Sie eine PAC-Datei oder manuelle Einstellungen, um einen Proxyserver für jedes WLAN zu konfigurieren. Wenn Sie den Proxy für WifiConfiguration
festlegen oder entfernen möchten, rufen Sie die zugehörige Methode setHttpProxy()
auf. Rufen Sie getHttpProxy()
auf, um die Proxyeinstellungen abzurufen.
Erläuterungsdialogfelder für vom Administrator deaktivierte Funktionen
Ihre Anwendung sollte Nutzern, die ein vom Administrator deaktiviertes Feature verwenden, eine nützliche Erklärung anzeigen. Alle Apps können jetzt mit createAdminSupportIntent()
einen Intent erstellen, der bei Übergabe an startActivity(Intent)
ein Erklärungsdialogfeld anzeigt.
Intents umfassen angepasste, lokalisierte Erläuterungen zu deaktivierten Kameras, deaktivierte Bildschirmaufnahmen und alle UserManager
-Einschränkungen.
Bluetooth wird eingeschränkt
Geräteinhaber können Bluetooth deaktivieren. Dies wirkt sich auf alle Nutzer und Profile auf dem Gerät aus. Fügen Sie zum Deaktivieren von Bluetooth die Nutzereinschränkung DISALLOW_BLUETOOTH
hinzu.
Geräte- und Profilinhaber können verhindern, dass Nutzer mit DISALLOW_BLUETOOTH_SHARING
Dateien über Bluetooth senden. Der Empfang von Dateien ist davon nicht betroffen. Wenn die Richtlinie von einem Geräteinhaber festgelegt wurde, gilt DISALLOW_BLUETOOTH_SHARING
für alle Nutzer auf dem Gerät. Diese Einstellung ist in Android 8.0 die Standardeinstellung für neue Profile und bestehende Profile auf Geräten, die auf Android 8.0 aktualisiert werden.
Änderungen des Verhaltens
Wenn Sie Apps für Unternehmen erstellen, einschließlich DPCs, sollten Sie sich die folgenden Änderungen am Verhalten in Android 8.0 ansehen und Ihre App entsprechend anpassen.
Nutzer entfernen
Geräteinhaber können sekundäre Nutzer und verwaltete Profile mit removeUser()
entfernen, auch wenn DISALLOW_REMOVE_USER
aktiviert ist.
Sicherheit
Authentifizierung
Die folgenden Änderungen wurden in der Klasse DevicePolicyManager
wirksam:
- Die Methode
lockNow()
sperrt das Arbeitsprofil nur, wenn eine separate Identitätsbestätigung aktiv ist. - Die Methode
resetPassword()
ist nicht mehr für DPCs verfügbar, die als Geräteinhaber oder Profilinhaber agieren und auf Android 8.0 ausgerichtet sind. Wenn sie aufgerufen wird, wird eine Sicherheitsausnahme ausgelöst. Stattdessen sollten DPCsresetPasswordWithToken()
verwenden.Hinweis : DPCs, die auf Android 7.1.1 (API-Level 25) oder niedriger ausgerichtet sind, sowie DPCs, die nur Geräteadministratorberechtigungen haben, sind von dieser Änderung nicht betroffen.
- Bei Geräten, die die dateibasierte Verschlüsselung unterstützen, ist
isActivePasswordSufficient()
erst verfügbar, wenn der Nutzer das Gerät nach einem Neustart zum ersten Mal entsperrt. Wenn der Aufruf aufgerufen wird, bevor der Nutzer das Gerät entsperrt, wird eine Ausnahme ausgelöst.
Daten aus gesperrten Arbeitsprofilen
Unter Android 8.0 wurden Änderungen an der Benutzeroberfläche vorgenommen, um Daten von gesperrten Arbeitsprofilen zu trennen.
- In Benachrichtigungen für Apps im Arbeitsprofil wird jetzt möglicherweise der Inhalt ausgeblendet. Bisher war auf der Benachrichtigungsleiste der Inhalt von geschäftlichen Apps aus einem gesperrten Arbeitsprofil zu sehen.
- Auf dem Bildschirm Zuletzt verwendet wird jetzt ein einfacher Bereich zum Ausführen von Apps über ein gesperrtes Arbeitsprofil angezeigt. Das einfache, farbcodierte Steuerfeld enthält das Symbol und den Namen einer App. Bisher wurde bei Aktivitäten oder Aufgaben aus einem gesperrten Arbeitsprofil auf dem Bildschirm „Letzte“ eine Vorschau angezeigt.
Geräteintegrität
- Das Flag
ENSURE_VERIFY_APPS
ist jetzt eine globale Nutzereinschränkung. Wenn ein Nutzer auf dem Gerät diese Einschränkung hat, wird die App-Überprüfung für alle Nutzer auf dem Gerät erzwungen. Wenn beispielsweise ein Profilinhaber die Einschränkung für das Arbeitsprofil festlegt, wird die App-Überprüfung im privaten Profil des Nutzers erzwungen. - Die Methode
onSystemUpdatePending()
wird jetzt nicht nur für Geräteinhaber, sondern auch für Profilinhaber aufgerufen. - Wenn Sie die Klasse
SystemUpdatePolicy
verwenden, gilt die Richtlinie zum Verschieben nicht mehr für Sicherheitspatches, sodass Sicherheitspatches nicht mehr verschoben werden können. Das Verhalten anderer Richtlinientypen, z. B. automatisch oder mit Fenster, ist jedoch nicht betroffen. - Geräteeigentümer können das Zurücksetzen auf die Werkseinstellungen mit
wipeData()
auslösen, auch wennDISALLOW_FACTORY_RESET
aktiviert ist.
Durchgehend aktives VPN
Unter Android 8.0 wurden Änderungen an der Benutzeroberfläche vorgenommen, damit Nutzer den Status von durchgehend aktiven VPN-Verbindungen besser nachvollziehen können:
- Wenn durchgehend aktive VPN-Verbindungen getrennt werden oder keine Verbindung hergestellt werden kann, sehen Nutzer eine Benachrichtigung, die sich nicht schließen lässt. Wenn Sie auf die Benachrichtigung tippen, werden die VPN-Konfigurationseinstellungen angezeigt. Die Benachrichtigung verschwindet, wenn die VPN-Verbindung wiederhergestellt wird oder der Nutzer die Option „Durchgehend aktives VPN“ deaktiviert.
- Durch ein durchgehend aktives VPN kann die Person, die ein Gerät verwendet, alle Netzwerkverbindungen blockieren, die das VPN nicht verwenden. Wenn Sie diese Option aktivieren, warnt die App „Einstellungen“ den Nutzer, dass er keine Internetverbindung herstellen kann, bis eine Verbindung zum VPN hergestellt wird. Der Nutzer wird in den Einstellungen aufgefordert, fortzufahren oder den Vorgang abzubrechen.
Der VpnService
von VPN-Apps muss jetzt nach dem Start die Methode startForeground()
aufrufen. Da das Android-System den Dienst einer VPN-Anwendung direkt startet, liegt der Übergang in den Vordergrund der App in der Verantwortung. Unter Android 8.0 werden VPN-Apps heruntergefahren, die den VPN-Dienst nicht in den Vordergrund übertragen.
Passwort-Callbacks
Die Callbacks zur Passwortänderung von DeviceAdminReceiver
enthalten jetzt den Parameter user
, um den Nutzer oder das Profil zu identifizieren, zu dem das Passwort gehört. Die neuen Methodensignaturen sind:
onPasswordChanged(Context, Intent, UserHandle)
onPasswordExpiring(Context, Intent, UserHandle)
onPasswordFailed(Context, Intent, UserHandle)
onPasswordSucceeded(Context, Intent, UserHandle)
Bei der Standardimplementierung jeder neuen Methode wird die vorherige Version aufgerufen und das Nutzerargument wird verworfen. In Android 8.0 werden die vorherigen Methoden eingestellt.
API-Delegierung für die App-Verwaltung
Die folgenden Methoden in der Klasse DevicePolicyManager
wurden eingestellt:
setCertInstallerPackage()
getCertInstallerPackage()
setApplicationRestrictionsManagingPackage()
getApplicationRestrictionsManagingPackage()
Außerdem ist es jetzt möglich, einen einzelnen Bereich an mehrere Pakete zu delegieren. Geräte- und Profilinhaber können also zwei verschiedenen Paketen gleichzeitig Zugriff auf dieselben APIs gewähren.