Neuerungen für Unternehmen in Android 10

Diese Seite bietet einen Überblick über die neuen APIs, Funktionen und Verhaltensänderungen für Unternehmen, die in Android 10 eingeführt wurden.

Arbeitsprofile für unternehmenseigene Geräte

Mit Android 10 werden neue Bereitstellungs- und Attestierungsfunktionen für unternehmenseigene Geräte eingeführt, für die nur ein Arbeitsprofil erforderlich ist.

Verbesserte Bereitstellungstools für Arbeitsprofile

Sie können Arbeitsprofile auf Geräten mit Android 10 und höher bereitstellen, die mit QR-Code oder Zero-Touch registriert wurden. Während der Bereitstellung eines unternehmenseigenen Geräts kann ein neuer Intent-Zusatz dazu führen, dass Device Policy Controller-Apps (DPCs) ein Arbeitsprofil oder eine vollständig verwaltete Einrichtung initiieren. Nachdem ein Arbeitsprofil erstellt oder die vollständige Verwaltung eingerichtet wurde, müssen DPCs Bildschirme für die Richtliniencompliance aufrufen, um anfängliche Richtlinien zu erzwingen.

Deklarieren Sie in der Manifestdatei Ihres DPC einen neuen Intent-Filter für GET_PROVISIONING_MODE in einer Aktivität und fügen Sie die Berechtigung BIND_DEVICE_ADMIN hinzu, um zu verhindern, dass beliebige Apps die Aktivität starten. Beispiele:

<activity
    android:name=".GetProvisioningModeActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action
            android:name="android.app.action.GET_PROVISIONING_MODE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Während der Bereitstellung startet das System die Aktivität, die mit dem Intent-Filter verknüpft ist. Der Zweck dieser Aktivität besteht darin, einen Verwaltungsmodus (Arbeitsprofil oder vollständig verwaltet) anzugeben.

Es kann nützlich sein, Extras für die Bereitstellung abzurufen, bevor der geeignete Verwaltungsmodus für das Gerät bestimmt wird. Die Aktivität kann getIntent() aufrufen, um Folgendes abzurufen:

DPCs können auch einen neuen Ergebnis-Intent erstellen und ihm die folgenden Extras hinzufügen:

Rufen Sie zum Festlegen des Verwaltungsmodus auf dem Gerät putExtra(DevicePolicyManager.EXTRA_PROVISIONING_MODE,desiredProvisioningMode) auf, wobei desiredProvisioningMode für Folgendes steht:

  • Arbeitsprofil: PROVISIONING_MODE_MANAGED_PROFILE
  • Vollständig verwaltet: PROVISIONING_MODE_FULLY_MANAGED_DEVICE

Schließen Sie die Bereitstellung des Arbeitsprofils oder der vollständig verwalteten Bereitstellung ab, indem Sie die Bereitstellungsdetails über setResult(RESULT_OK, Intent) zurück an die Einrichtung senden und alle aktiven Bildschirme mit finish() schließen.

Wenn die Bereitstellung abgeschlossen ist, steht den DPCs ein neuer Intent zur Verfügung, damit sie ihre Compliancebildschirme starten und anfängliche Richtlinieneinstellungen erzwingen können. Auf Geräten mit Arbeitsprofilen werden Compliancebildschirme im Arbeitsprofil angezeigt. Der DPC muss dafür sorgen, dass seine Compliancebildschirme den Nutzern auch dann angezeigt werden, wenn ein Nutzer den Einrichtungsvorgang verlässt.

Deklarieren Sie in der Manifestdatei Ihres DPC einen neuen Intent-Filter für ADMIN_POLICY_COMPLIANCE in einer Aktivität und fügen Sie die Berechtigung BIND_DEVICE_ADMIN hinzu, um zu verhindern, dass beliebige Apps die Aktivität starten. Beispiele:

<activity
    android:name=".PolicyComplianceActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action android:name="android.app.action.ADMIN_POLICY_COMPLIANCE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Der DPC muss diesen neuen Intent verwenden, anstatt die ACTION_PROFILE_PROVISIONING_COMPLETE-Übertragung zu überwachen.

Die mit dem Intent-Filter verknüpfte Aktivität kann getIntent() aufrufen, um den EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE abzurufen. Nachdem die Richtlinien eingehalten wurden, muss ADMIN_POLICY_COMPLIANCE setResult(RESULT_OK, Intent) zurückgeben und alle aktiven Bildschirme mit finish() schließen.

Auf vollständig verwalteten Geräten kehren die Nutzer zum Startbildschirm zurück. Geräte mit Arbeitsprofil werden Nutzer aufgefordert, ihr privates Konto hinzuzufügen, bevor sie zum Startbildschirm zurückkehren.

Geräte-ID-Nachweis des Arbeitsprofils

DPCs, die als Administrator eines mit Zero-Touch-Registrierung bereitgestellten Arbeitsprofils festgelegt sind, können Geräte-IDs mit sicherer Hardwareattestierung wie eine IMEI oder die Seriennummer des Herstellers erhalten. Das Gerät muss sichere Hardware (z. B. eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) oder Secure Element (SE)) enthalten und Geräte-ID-Attestierung und Zero-Touch-Registrierung unterstützen.

Die Administratorkomponente eines Arbeitsprofils kann DevicePolicyManager.generateKeyPair() aufrufen und dabei ID_TYPE_SERIAL, ID_TYPE_IMEI oder ID_TYPE_MEID für das Argument idAttestationFlags übergeben.

Weitere Informationen zum Extrahieren und Validieren von Geräte-IDs finden Sie unter Hardwaregestützte Schlüsselpaare mit Schlüsselattestierung verifizieren.

Verbesserungen am Arbeitsprofil

Es sind neue APIs verfügbar, die die profilübergreifende Kalendersichtbarkeit und die geräteübergreifende Blockierung von App-Installationen aus unbekannten Quellen unterstützen.

Arbeitsprofil, unbekannte Quellen für das gesamte Gerät

Apps, die von anderen Quellen als Google Play oder anderen vertrauenswürdigen App-Shops heruntergeladen wurden, werden als Apps aus unbekannten Quellen bezeichnet. In Android 10 können Administratoren von Arbeitsprofilen verhindern, dass Nutzer oder Profile Apps aus unbekannten Quellen auf dem Gerät installieren. Dazu fügen sie die neue Nutzereinschränkung DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY hinzu. Nachdem diese Einschränkung hinzugefügt wurde, kann ein Nutzer des Geräts jedoch weiterhin Apps mit ADB installieren.

Um zu verhindern, dass Nutzer versehentlich Apps aus unbekannten Quellen installieren, empfehlen wir, diese Nutzereinschränkung hinzuzufügen, da die Installation von Google Play-Diensten nicht erforderlich ist. Wenn Sie ältere Android-Versionen unterstützen möchten, können Sie einen Wert für eine verwaltete Konfiguration für Google Play festlegen.

Zulässige Eingabegeräte auf Arbeitsprofile beschränken

Wenn Administratoren von Arbeitsprofilen DevicePolicyManager.setPermittedInputMethods() aufrufen, können Nutzer nur die zulässigen Eingabemethoden in ihrem Arbeitsprofil verwenden und nicht das gesamte Gerät. So haben sie die volle Kontrolle über die Eingabemethoden auf der privaten Seite ihres Geräts.

Arbeitsprofile ohne Internetverbindung löschen

Das Flag WIPE_SILENTLY wurde DevicePolicyManager.wipeData() hinzugefügt. Wenn das Flag festgelegt ist, werden Nutzer nicht benachrichtigt, nachdem ihr Arbeitsprofil mit wipeData() gelöscht wurde.

Neue Funktionen für vollständig verwaltete Geräte

Mit Android 10 werden neue Funktionen und APIs für vollständig verwaltete Geräte eingeführt. Dazu gehören manuelle Systemupdates und die Erweiterung der QR-Code- und NFC-Bereitstellung mit den Anmeldedaten für ein EAP-WLAN-Netzwerk sowie Unterstützung von DNS über TLS.

Manuelle Installation von Systemupdates

In Android 10 können Administratoren von vollständig verwalteten Geräten Systemupdates über eine Systemupdatedatei installieren. Mit manuellen Systemupdates können IT-Administratoren Folgendes tun:

  • Teste ein Update auf einer kleinen Anzahl von Geräten, bevor du sie ausgiebig installierst.
  • Doppelte Downloads in Netzwerken mit begrenzter Bandbreite vermeiden
  • Sie können Installationen aufteilen oder Geräte nur aktualisieren, wenn sie nicht verwendet werden.

Zuerst legt ein IT-Administrator eine Richtlinie für verzögerte Systemupdates fest, um die automatische Installation zu verzögern (falls erforderlich). Als Nächstes ruft der DPC eines Geräts installSystemUpdate() mit dem Pfad zur Systemupdatedatei eines Geräteherstellers auf. Übergeben Sie ein InstallSystemUpdateCallback-Objekt, mit dem das System Fehler melden kann, die vor dem Neustart des Geräts auftreten. Wenn ein Fehler auftritt, ruft das System onInstallUpdateError() mit dem Fehlercode auf.

Nachdem das Gerät neu gestartet wurde, muss der DPC eine erfolgreiche Installation mit einer Versions-API wie Build.FINGERPRINT bestätigen. Wenn das Update fehlschlägt, melden Sie es einem IT-Administrator.

EAP-WLAN-Bereitstellung

In Android 10 können QR-Codes und NFC-Daten, die für die Gerätebereitstellung verwendet werden, EAP-Konfiguration und Anmeldedaten enthalten, einschließlich Zertifikaten. Wenn eine Person einen QR-Code scannt oder auf ein NFC-Tag tippt, authentifiziert sich das Gerät automatisch mithilfe von EAP bei einem lokalen WLAN und startet den Bereitstellungsprozess ohne zusätzliche manuelle Eingabe.

Fügen Sie zur Authentifizierung von WLAN mit EAP ein zusätzliches EXTRA_PROVISIONING_WIFI_SECURITY_TYPE mit dem Wert "EAP" hinzu. Um die EAP-Authentifizierung anzugeben, können Sie Ihrem Intent die folgenden Extras für die Bereitstellung hinzufügen:

Unterstützung für privates DNS

Organisationen können DNS über TLS (privates DNS auf Android-Geräten) verwenden, um DNS-Abfragen, einschließlich interner Hostnamen, zu vermeiden. Administratorkomponenten von vollständig verwalteten Geräten können die Einstellungen für das private DNS des Geräts steuern. Rufen Sie folgenden Befehl auf, um den privaten DNS-Modus festzulegen:

Wenn Ihr DPC eine dieser Methoden aufruft und der Aufruf erfolgreich war, gibt das System PRIVATE_DNS_SET_NO_ERROR zurück. Andernfalls wird ein Fehler zurückgegeben.

Rufen Sie getGlobalPrivateDnsMode() und getGlobalPrivateDnsHost() auf, um den privaten DNS-Modus und die Hostgruppe auf einem Gerät abzurufen. Wenn Sie verhindern möchten, dass Nutzer private DNS-Einstellungen ändern, fügen Sie die Nutzereinschränkung DISALLOW_CONFIG_PRIVATE_DNS hinzu.

Ausnahme für den VPN-Sperrmodus

Mit dem VPN-Sperrmodus kann ein DPC jeglichen Netzwerkverkehr blockieren, der das VPN nicht verwendet. Administratoren von vollständig verwalteten Geräten und Arbeitsprofilen können Apps vom Sperrmodus ausnehmen. Ausgenommene Anwendungen verwenden standardmäßig ein VPN, stellen jedoch automatisch eine Verbindung zu anderen Netzwerken her, wenn das VPN nicht verfügbar ist. Ausgenommene Anwendungen, denen auch der Zugriff auf das VPN explizit verweigert wird, verwenden nur andere Netzwerke.

Wenn Sie eine App vom Sperrmodus ausnehmen möchten, rufen Sie die neue DevicePolicyManager-Methode setAlwaysOnVpnPackage() auf, die eine Liste von ausgenommenen App-Paketen akzeptiert. Alle vom DPC hinzugefügten App-Pakete müssen beim Aufruf der Methode auf dem Gerät installiert werden. Wenn eine App deinstalliert und neu installiert wird, muss sie noch einmal ausgenommen werden. Damit die Apps zuvor vom Sperrmodus ausgenommen werden, rufen Sie getAlwaysOnVpnLockdownWhitelist() auf.

Damit Administratoren von vollständig verwalteten Geräten und Arbeitsprofilen den Status des Sperrmodus abrufen können, wird in Android 10 die Methode isAlwaysOnVpnLockdownEnabled() hinzugefügt.

Neue Delegierungsbereiche

Mit Android 10 wird die Liste der Funktionen erweitert, die ein DPC an andere spezifischere Apps delegieren kann. Android gruppiert die für eine Aufgabe erforderlichen API-Methoden in Bereiche. Zum Delegieren eines Bereichs rufen Sie setDelegatedScopes() auf und übergeben einen oder mehrere der folgenden Bereiche:

In Android 10 wird die neue Klasse DelegatedAdminReceiver für delegierte Apps eingeführt. Das System verwendet diesen Broadcast-Empfänger, um DPC-ähnliche Callbacks zum Delegieren von Apps zu senden. Apps, denen das Netzwerkaktivitäts-Logging und die Zertifikatsauswahl delegiert wurden, sollten diese Klasse implementieren. So fügen Sie diese Komponente einer delegierten App hinzu:

  1. Fügen Sie der delegierten Anwendung eine abgeleitete Klasse von DelegatedAdminReceiver hinzu.
  2. Deklarieren Sie <receiver> im App-Manifest und fügen Sie für jeden Callback eine Intent-Filteraktion hinzu. Beispiel: ACTION_NETWORK_LOGS_AVAILABLE oder ACTION_CHOOSE_PRIVATE_KEY_ALIAS.
  3. Schützen Sie den Übertragungsempfänger mit der Berechtigung BIND_DEVICE_ADMIN.

Das folgende Snippet zeigt das App-Manifest einer einzelnen delegierten Anwendung, die sowohl das Netzwerk-Logging als auch die Zertifikatsauswahl verarbeitet:

<receiver android:name=".app.DelegatedAdminReceiver"
        android:permission="android.permission.BIND_DELEGATED_ADMIN">
    <intent-filter>
        <action android:name="android.app.admin.action.NETWORK_LOGS_AVAILABLE">
        <action android:name="android.app.action.CHOOSE_PRIVATE_KEY_ALIAS">
    </intent-filter>
    </receiver>

Protokollierung der Netzwerkaktivität

Damit Organisationen Malware besser erkennen und verfolgen können, können DPCs TCP-Verbindungen und DNS-Lookups durch das System protokollieren. In Android 10 können Administratoren von vollständig verwalteten Geräten das Netzwerk-Logging an eine spezialisierte Anwendung delegieren.

Zum Abrufen von Netzwerklogs, nachdem das System einen Batch verfügbar gemacht hat, sollten delegierte Anwendungen zuerst eine abgeleitete Klasse von DelegatedAdminReceiver erstellen (siehe oben). Implementieren Sie in Ihrer Unterklasse den onNetworkLogsAvailable()-Callback. Folgen Sie dazu der Anleitung unter Logs abrufen.

Delegierte Anwendungen können die folgenden DevicePolicyManager-Methoden aufrufen und dabei null für das Argument admin übergeben:

Um den Verlust von Logs zu vermeiden, sollten DPCs kein Netzwerk-Logging aktivieren, wenn sie an eine andere Anwendung delegieren möchten. Die delegierte Anwendung sollte Netzwerkprotokolle aktivieren und erfassen. Nachdem ein DPC das Netzwerk-Logging delegiert hat, erhält er keine weiteren onNetworkLogsAvailable()-Callbacks.

Wie Sie das Logging von Netzwerkaktivitäten über eine bevollmächtigte App melden, erfahren Sie im Entwicklerhandbuch unter Logging von Netzwerkaktivitäten.

Zertifikatsauswahl

In Android 10 können Administratoren von vollständig verwalteten Geräten, Arbeitsprofilen und sekundären Nutzern die Zertifikatsauswahl an eine spezialisierte App delegieren.

Zur Auswahl eines Zertifikatsalias sollten delegierte Anwendungen die erste abgeleitete Klasse von DelegatedAdminReceiver sein (siehe oben). Implementieren Sie in Ihrer Unterklasse den onChoosePrivateKeyAlias()-Callback und geben Sie einen Alias für ein bevorzugtes Zertifikat zurück. Wenn Sie den Nutzer zur Auswahl eines Zertifikats auffordern möchten, geben Sie null zurück.

Einstellung von Richtlinien zur Geräteverwaltung

Android 10 verhindert, dass Apps und DPCs alte Richtlinien zur Geräteverwaltung anwenden. Wir empfehlen Kunden und Partnern, auf vollständig verwaltete Geräte oder Arbeitsprofile umzusteigen. Die folgenden Richtlinien geben ein SecurityException aus, wenn sie von einem Geräteadministrator aufgerufen werden, der auf Android 10 ausgerichtet ist:

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 weiterhin verfügbar:

Weitere Informationen zu diesen Änderungen finden Sie unter Einstellung der Geräteverwaltung.

Neue Funktionen für Apps

Apps, die auf Android 10 ausgerichtet sind, können die auf einem Gerät festgelegte Komplexität der Displaysperre abfragen, bevor vertrauliche Daten angezeigt oder wichtige Funktionen eingeführt werden. Apps, in denen die KeyChain API aufgerufen wird, profitieren von Verhaltensverbesserungen. Für VPN-Apps sind außerdem neue Funktionen verfügbar.

Qualitätsprüfung für Displaysperre

Ab Android 10 können Apps mit wichtigen Funktionen, die eine Displaysperre erfordern, die Komplexität der Displaysperre eines Geräts oder Arbeitsprofils abfragen. Apps, die eine stärkere Displaysperre benötigen, können den Nutzer zu den Einstellungen für die Displaysperre des Systems weiterleiten und dort seine Sicherheitseinstellungen aktualisieren.

So prüfen Sie die Qualität der Displaysperre:

Verwenden Sie ACTION_SET_NEW_PASSWORD mit zusätzlichen EXTRA_PASSWORD_COMPLEXITY, um die Einstellungen für die Displaysperre des Systems zu starten. Optionen, die nicht der im Intent-Zusätzlichen angegebenen Komplexität entsprechen, sind ausgegraut. Nutzer können eine der verfügbaren Optionen für die Displaysperre auswählen oder den Bildschirm verlassen.

Best Practice:Zeigen Sie in Ihrer App eine Nachricht an, bevor Sie die Systemsperre für den Bildschirm starten. Wenn die App fortgesetzt wird, rufen Sie noch einmal DevicePolicyManager.getPasswordComplexity() auf. Wenn weiterhin eine stärkere Displaysperre erforderlich ist, schränken Sie den Zugriff ein, anstatt Nutzer wiederholt zur Aktualisierung ihrer Sicherheitseinstellungen aufzufordern.

HTTP-Proxy-Unterstützung in VPN-Apps

In Android 10 können VPN-Apps einen HTTP-Proxy für ihre VPN-Verbindung festlegen. Zum Hinzufügen eines HTTP-Proxys muss eine VPN-Anwendung eine ProxyInfo-Instanz mit einem Host und einem Port konfigurieren, bevor VpnService.Builder.setHttpProxy() aufgerufen wird. Das System und viele Netzwerkbibliotheken verwenden diese Proxyeinstellung, aber das System erzwingt keine Anwendungen, die HTTP-Anfragen weiterleiten.

Einen Beispielcode, der zeigt, wie ein HTTP-Proxy eingerichtet wird, finden Sie in der Beispiel-App ToyVPN.

VPN-Dienstmodi

VPN-Anwendungen können feststellen, ob der Dienst aufgrund von Always-On-VPN ausgeführt wird und ob der Sperrmodus aktiv ist. Mit den neuen Methoden in Android 10 kannst du deine Benutzeroberfläche anpassen. Sie können beispielsweise die Schaltfläche zum Trennen der Verbindung deaktivieren, wenn das durchgehend aktive VPN den Lebenszyklus Ihres Dienstes steuert.

VPN-Apps können die folgenden VpnService-Methoden aufrufen, nachdem eine Verbindung zum Dienst hergestellt und die lokale Schnittstelle eingerichtet wurde:

  • isAlwaysOn(), um herauszufinden, ob das System den Dienst aufgrund eines durchgehend aktiven VPN gestartet hat
  • isLockdownEnabled(), um herauszufinden, ob das System Verbindungen blockiert, die nicht das VPN verwenden

Der Status „Always-On“ bleibt unverändert, während der Dienst ausgeführt wird, der Status des Sperrmodus kann sich jedoch ändern.

Verbesserungen am Schlüsselbund

Android 10 enthält mehrere Verbesserungen im Zusammenhang mit der KeyChain API.

Wenn eine App KeyChain.choosePrivateKeyAlias() aufruft, filtern Geräte mit Android 10 und höher die Liste der Zertifikate, aus denen ein Nutzer auswählen kann, basierend auf den Ausstellern und Schlüsselalgorithmen, die im Aufruf angegeben sind.

Wenn ein TLS-Server beispielsweise im Rahmen eines TLS-Handshakes eine Nachricht für eine Zertifikatsanfrage sendet und der Browser KeyChain.choosePrivateKeyAlias() aufruft, enthält die Aufforderung zur Zertifikatsauswahl nur Optionen, die mit dem Parameter Aussteller übereinstimmen. Wenn keine passenden Optionen verfügbar sind oder keine Zertifikate auf dem Gerät installiert sind, wird dem Nutzer die Auswahlaufforderung nicht angezeigt.

Außerdem muss auf einem Gerät für KeyChain keine Displaysperre mehr aktiviert sein, damit Schlüssel oder CA-Zertifikate importiert werden können.