Neuerungen für Unternehmen in Android 10

Auf dieser Seite finden Sie einen Überblick über die neuen Enterprise-APIs, Funktionen und Verhaltensänderungen, die in Android 10 eingeführt wurden.

Arbeitsprofile für unternehmenseigene Geräte

In Android 10 werden neue Funktionen für die Bereitstellung und Attestierung für unternehmenseigene Geräte eingeführt, für die nur ein Arbeitsprofil erforderlich ist.

Verbesserte Tools für die Nutzerverwaltung im Arbeitsprofil

Sie können Arbeitsprofile auf Geräten mit Android 10 und höher bereitstellen, die über einen QR-Code oder Zero-Touch registriert wurden. Beim Bereitstellen eines unternehmenseigenen Geräts kann mit einem neuen Intent-Extra die Einrichtung eines Arbeitsprofils oder eines vollständig verwalteten Geräts durch Device Policy Controller-Apps (DPCs) initiiert werden. Nachdem ein Arbeitsprofil erstellt oder die vollständige Verwaltung eingerichtet wurde, müssen DPCs Bildschirme zur Richtlinienkonformität starten, um alle anfänglichen Richtlinien zu erzwingen.

Deklarieren Sie in der Manifestdatei des 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. Beispiel:

<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. Mit dieser Aktivität wird ein Verwaltungsmodus (Arbeitsprofil oder vollständig verwaltet) festgelegt.

Es kann hilfreich sein, die zusätzlichen Bereitstellungsinformationen abzurufen, bevor der geeignete Verwaltungsmodus für das Gerät festgelegt wird. Die Aktivität kann getIntent() aufrufen, um Folgendes abzurufen:

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

Rufen Sie putExtra(DevicePolicyManager.EXTRA_PROVISIONING_MODE,desiredProvisioningMode) auf, um den Verwaltungsmodus auf dem Gerät festzulegen. Dabei gilt Folgendes:desiredProvisioningMode

  • Arbeitsprofil: PROVISIONING_MODE_MANAGED_PROFILE
  • Vollständig verwaltet: PROVISIONING_MODE_FULLY_MANAGED_DEVICE

Schließen Sie die Bereitstellung des Arbeitsprofils oder die Bereitstellung als vollständig verwaltetes Gerät ab, indem Sie die Bereitstellungsdetails über setResult(RESULT_OK, Intent) an die Einrichtung zurücksenden und alle aktiven Bildschirme mit finish() schließen.

Nach Abschluss der Bereitstellung ist eine neue Intent für DPCs verfügbar, mit der sie ihre Compliance-Bildschirme starten und die anfänglichen Richtlinieneinstellungen erzwingen können. Auf Geräten mit Arbeitsprofil werden Compliance-Bildschirme im Arbeitsprofil angezeigt. Ihr DPC muss dafür sorgen, dass die Compliance-Bildschirme Nutzern angezeigt werden, auch wenn ein Nutzer den Einrichtungsvorgang abbricht.

Deklarieren Sie in der Manifestdatei des 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. Beispiel:

<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>

Ihr DPC muss diesen neuen Intent verwenden, anstatt auf den Broadcast ACTION_PROFILE_PROVISIONING_COMPLETE zu warten.

Die mit dem Intent-Filter verknüpfte Aktivität kann getIntent() aufrufen, um die EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE abzurufen. Nach der Durchführung der Richtlinienkonformität muss ADMIN_POLICY_COMPLIANCE setResult(RESULT_OK, Intent) zurückgeben und alle aktiven Bildschirme mit finish() schließen.

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

Attestierung der Geräte-ID für Arbeitsprofile

DPCs, die als Administrator eines Arbeitsprofils festgelegt sind, das mit der Zero-Touch-Registrierung bereitgestellt wurde, können Geräte-IDs mit sicherer Hardware-Bestätigung wie eine IMEI oder die Seriennummer des Herstellers abrufen. Das Gerät muss sichere Hardware (z. B. eine Trusted Execution Environment (TEE) oder ein Secure Element (SE)) enthalten und die Attestierung der Geräte-ID sowie die Zero-Touch-Registrierung unterstützen.

Die Administratorkomponente eines Arbeitsprofils kann DevicePolicyManager.generateKeyPair() aufrufen und dabei einen oder mehrere der Werte 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 überprüfen.

Verbesserungen bei Arbeitsprofilen

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

Arbeitsprofil, geräteübergreifende unbekannte Quellen

Apps, die nicht aus dem Google Play Store oder anderen vertrauenswürdigen App-Stores 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 müssen sie die neue Nutzerbeschränkung DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY hinzufügen. Nachdem Sie diese Einschränkung hinzugefügt haben, kann eine Person, die das Gerät verwendet, jedoch weiterhin Apps über adb installieren.

Damit Nutzer nicht versehentlich Apps aus unbekannten Quellen installieren, empfehlen wir, diese Nutzerbeschränkung hinzuzufügen, da dafür keine Google Play-Dienste installiert sein müssen. Wenn Sie ältere Android-Versionen unterstützen möchten, können Sie einen Wert für die verwaltete Konfiguration für Google Play festlegen.

Zulässige Eingabegeräte auf Arbeitsprofile beschränken

Wenn Administratoren von Arbeitsprofilen DevicePolicyManager.setPermittedInputMethods() aufrufen, sind Nutzer nur auf die zulässigen Eingabemethoden in ihrem Arbeitsprofil beschränkt und nicht auf dem gesamten Gerät. So haben Nutzer die volle Kontrolle über die Eingabemethoden auf der privaten Seite ihres Geräts.

Arbeitsprofile im Hintergrund löschen

Das Flag WIPE_SILENTLY wurde zu DevicePolicyManager.wipeData() hinzugefügt. Wenn das Flag gesetzt 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, darunter manuelle Systemupdates, die Erweiterung der QR-Code- und NFC-Bereitstellung um die Anmeldedaten für ein EAP-WLAN und die Unterstützung von DNS over TLS.

Manuelle Installation von Systemupdates

In Android 10 können Administratoren vollständig verwalteter Geräte Systemupdates über eine Systemupdate-Datei installieren. Manuelle Systemupdates bieten IT-Administratoren folgende Möglichkeiten:

  • Testen Sie ein Update auf einer kleinen Anzahl von Geräten, bevor Sie es auf allen Geräten installieren.
  • Doppelte Downloads in Netzwerken mit begrenzter Bandbreite vermeiden
  • Installationen sollten zeitlich versetzt erfolgen oder Geräte sollten nur aktualisiert werden, wenn sie nicht verwendet werden.

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

Nach dem Neustart des Geräts muss der DPC die erfolgreiche Installation mit einer Versions-API wie Build.FINGERPRINT bestätigen. Wenn das Update fehlschlägt, informieren Sie einen IT-Administrator.

WLAN-Bereitstellung für das EAP

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

Wenn Sie WLAN mit EAP authentifizieren möchten, fügen Sie ein EXTRA_PROVISIONING_WIFI_SECURITY_TYPE-Extra mit dem Wert "EAP" hinzu. Wenn Sie die EAP-Authentifizierung angeben möchten, können Sie Ihrem Intent die folgenden Provisioning-Extras hinzufügen:

Unterstützung für privates DNS

Organisationen können DNS-over-TLS (auf Android-Geräten als Privates DNS bezeichnet) verwenden, um DNS-Leaks zu vermeiden, einschließlich derer interner Hostnamen. Administratorkomponenten vollständig verwalteter Geräte können die Einstellungen für privates DNS des Geräts steuern. So legen Sie den Modus für privates DNS fest:

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

Rufen Sie getGlobalPrivateDnsMode() und getGlobalPrivateDnsHost() auf, um den auf einem Gerät festgelegten privaten DNS-Modus und Host abzurufen. Sie können verhindern, dass Nutzer private DNS-Einstellungen ändern, indem Sie die Nutzerbeschränkung DISALLOW_CONFIG_PRIVATE_DNS hinzufügen.

Ausnahme vom VPN-Sperrmodus

Im VPN-Sperrmodus kann ein Geräteinhaberprofil (Device Owner Profile, DPC) jeden Netzwerkverkehr blockieren, der nicht das VPN verwendet. Administratoren von vollständig verwalteten Geräten und Arbeitsprofilen können Apps vom Sperrmodus ausnehmen. Ausgenommene Apps verwenden standardmäßig ein VPN, stellen aber automatisch eine Verbindung zu anderen Netzwerken her, wenn das VPN nicht verfügbar ist. Ausgenommene Apps, denen der Zugriff auf das VPN explizit verweigert wurde, verwenden nur andere Netzwerke.

Wenn Sie eine App vom Sperrmodus ausnehmen möchten, rufen Sie die neue Methode DevicePolicyManager setAlwaysOnVpnPackage() auf, die eine Liste der ausgenommenen App-Pakete akzeptiert. Alle App-Pakete, die der DPC hinzufügt, müssen auf dem Gerät installiert sein, wenn die Methode aufgerufen wird. Wenn eine App deinstalliert und neu installiert wird, muss sie noch einmal ausgenommen werden. Rufen Sie getAlwaysOnVpnLockdownWhitelist() auf, um die Apps abzurufen, die zuvor vom Sperrmodus ausgenommen waren.

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 Delegationsbereiche

In Android 10 wird die Liste der Funktionen erweitert, die ein DPC an andere, spezialisiertere Apps delegieren kann. Android gruppiert die für eine Aufgabe erforderlichen API-Methoden in Bereichen. Wenn Sie einen Bereich delegieren möchten, rufen Sie setDelegatedScopes() auf und übergeben Sie einen oder mehrere der folgenden Bereiche:

In Android 10 wird die neue Klasse DelegatedAdminReceiver für Delegierungs-Apps eingeführt. Das System verwendet diesen Übertragungsempfänger, um DPC-ähnliche Callbacks an delegierte Apps zu senden. Apps, denen die Protokollierung von Netzwerkaktivitäten und die Auswahl von Zertifikaten übertragen wurden, sollten diese Klasse implementieren. So fügen Sie diese Komponente einer delegierten App hinzu:

  1. Fügen Sie der Delegaten-App eine Unterklasse von DelegatedAdminReceiver hinzu.
  2. Deklarieren Sie <receiver> im App-Manifest und fügen Sie für jeden Callback eine Intent-Filter-Aktion 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-App, die sowohl die Netzwerkprotokollierung als auch die Zertifikatauswahl übernimmt:

<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 erkennen und nachverfolgen 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 die Netzwerkprotokollierung an eine spezielle App delegieren.

Damit Delegate-Apps Netzwerkprotokolle abrufen können, nachdem das System einen Batch zur Verfügung gestellt hat, müssen sie zuerst die Klasse DelegatedAdminReceiver (siehe oben) unterklassen. Implementieren Sie in Ihrer Unterklasse den Callback onNetworkLogsAvailable() gemäß der Anleitung unter Logs abrufen.

Delegierte Apps können die folgenden DevicePolicyManager-Methoden aufrufen (wobei null für das admin-Argument übergeben wird):

Damit keine Logs verloren gehen, sollten DPCs kein Netzwerk-Logging aktivieren, wenn sie die Aufgabe an eine andere App delegieren möchten. Die delegierte App sollte Netzwerk-Logs aktivieren und erfassen. Nachdem ein Geräteinhaber-Controller die Netzwerkprotokollierung delegiert hat, werden keine weiteren onNetworkLogsAvailable()-Callbacks empfangen.

Informationen zum Melden der Protokollierung von Netzwerkaktivitäten über eine delegierte App finden Sie im Entwicklerleitfaden Protokollierung von Netzwerkaktivitäten.

Zertifikatsauswahl

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

Um einen Zertifikatsalias auszuwählen, müssen delegierte Apps zuerst die Klasse DelegatedAdminReceiver (siehe oben) unterklassen. Implementieren Sie in Ihrer Unterklasse den onChoosePrivateKeyAlias()-Callback und geben Sie einen Alias für ein bevorzugtes Zertifikat zurück. Wenn Sie den Nutzer auffordern möchten, ein Zertifikat auszuwählen, geben Sie null zurück.

Einstellung von Device Admin-Richtlinien

Unter Android 10 können Apps und DPCs keine alten Geräteadministrator-Richtlinien mehr anwenden. Wir empfehlen Kunden und Partnern, auf vollständig verwaltete Geräte oder Arbeitsprofile umzustellen. Die folgenden Richtlinien lösen einen SecurityException aus, wenn sie von einem Geräteadministrator aufgerufen werden, der auf Android 10 ausgerichtet ist:

Einige Anwendungen verwenden den Geräteadministrator für die Verwaltung von Verbrauchergeräten. Zum Beispiel das Sperren und Löschen eines verlorenen Geräts. Dazu sind weiterhin die folgenden Richtlinien verfügbar:

Weitere Informationen zu diesen Änderungen finden Sie unter Einstellung der Geräteadministrator-API.

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 gestartet werden. Apps, die die KeyChain API aufrufen, profitieren von Verhaltensverbesserungen. Außerdem sind neue Funktionen für VPN-Apps verfügbar.

Qualitätsprüfung der Displaysperre

Ab Android 10 können Apps mit wichtigen Funktionen, für die eine Displaysperre erforderlich ist, 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 Systemeinstellungen für die Displaysperre weiterleiten, damit er seine Sicherheitseinstellungen aktualisieren kann.

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

Verwenden Sie ACTION_SET_NEW_PASSWORD, um die Einstellungen für die Displaysperre des Systems zu starten. Zusätzliche EXTRA_PASSWORD_COMPLEXITY-Optionen, die nicht der im Intent-Extra angegebenen Komplexität entsprechen, werden ausgegraut. Nutzer können zwischen den verfügbaren Optionen für die Displaysperre wählen oder den Bildschirm schließen.

Best Practice:Zeigen Sie in Ihrer App eine Meldung an, bevor Sie die Seite für die Systembildschirmsperre aufrufen. Wenn Ihre App fortgesetzt wird, rufen Sie DevicePolicyManager.getPasswordComplexity() noch einmal auf. Wenn eine stärkere Displaysperre weiterhin erforderlich ist, sollten Sie den Zugriff einschränken, anstatt Nutzer wiederholt aufzufordern, ihre Sicherheitseinstellungen zu aktualisieren.

HTTP-Proxy-Unterstützung in VPN-Apps

In Android 10 können VPN-Apps einen HTTP-Proxy für ihre VPN-Verbindung festlegen. Wenn Sie einen HTTP-Proxy hinzufügen möchten, muss eine VPN-App eine ProxyInfo-Instanz mit einem Host und Port konfigurieren, bevor VpnService.Builder.setHttpProxy() aufgerufen wird. Das System und viele Netzwerkbibliotheken verwenden diese Proxyeinstellung, aber das System zwingt Apps nicht, HTTP-Anfragen über einen Proxy zu senden.

Beispielcode zum Festlegen eines HTTP-Proxys finden Sie in der Beispiel-App ToyVPN.

VPN-Dienstmodi

VPN-Apps können erkennen, ob der Dienst aufgrund von Durchgehend aktives VPN ausgeführt wird und ob der Sperrmodus aktiv ist. Mit den neuen Methoden, die in Android 10 hinzugefügt wurden, können Sie die Benutzeroberfläche anpassen. Sie können beispielsweise die Schaltfläche zum Trennen der Verbindung deaktivieren, wenn der Lebenszyklus Ihres Dienstes durch das dauerhaft aktive VPN gesteuert wird.

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

  • isAlwaysOn(), um herauszufinden, ob der Dienst vom System aufgrund von durchgehend aktivem VPN gestartet wurde
  • isLockdownEnabled() um herauszufinden, ob das System Verbindungen blockiert, die das VPN nicht verwenden.

Der Status „Immer aktiv“ bleibt während der Ausführung Ihres Dienstes unverändert, der Status des Sperrmodus kann sich jedoch ändern.

Verbesserungen bei der Schlüsselbundverwaltung

In Android 10 gibt es 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 im Aufruf angegebenen Ausstellern und Schlüsselalgorithmen.

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

Außerdem ist für KeyChain nicht mehr erforderlich, dass auf einem Gerät eine Displaysperre eingerichtet ist, bevor Schlüssel oder CA-Zertifikate importiert werden können.