Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Geräteverwaltung implementieren

Auf dieser Seite finden Sie Richtlinien für Gerätehersteller zum Aktivieren der Geräteverwaltung auf Android. Damit die Geräteverwaltung unterstützt werden kann, müssen Geräte alle Softwarekompatibilitätsanforderungen erfüllen, die im Abschnitt 3.9. Geräteverwaltung in dem Android Compatibility Definition Document (CDD) definiert sind. Die hier bereitgestellten Implementierungsrichtlinien sind nicht vollständig und dienen nur als Ausgangspunkt für die Implementierung der Android-Geräteverwaltung.

Geräteverwaltung aktivieren

Wenn Sie die Geräteverwaltung auf Android aktivieren möchten, aktivieren Sie diese Funktionen:

android.software.device_admin
android.software.managed_users

Führen Sie den folgenden ADB Befehl auf einem Gerät aus, um zu prüfen, ob ein Gerät die Geräteverwaltung unterstützt, und prüfen Sie, ob diese Funktionen vorhanden sind: adb shell pm list features.

Voraussetzungen für die Einrichtung

Auf Geräten, auf denen die Bereitstellung für Geräteeigentümer oder Profilinhaber implementiert ist, müssen Endnutzer während der Einrichtung (Out-of-Box-Erlebnis oder Einrichtung des Arbeitsprofils) entsprechende Offenlegungen erhalten. AOSP bietet eine Referenzimplementierung. Die verwaltete Bereitstellung ist der UI-Ablauf des Android-Frameworks, der während der Einrichtung eines vollständig verwalteten Geräts oder Arbeitsprofils aufgerufen wird, um sicherzustellen, dass Gerätebenutzer ausreichend über die Auswirkungen der Festlegung eines Geräteeigentümers oder verwalteten Profils auf dem Gerät informiert werden. Bei der verwalteten Bereitstellung werden die folgenden Aktivitäten ausgeführt oder an einen Inhaber der Rolle „Geräterichtlinienverwaltung“ delegiert:

Gerät verschlüsseln (wenn die Verschlüsselung aktiviert ist)
Verwalteten Nutzer einrichten
Optionale Apps deaktivieren
Die EMM-App (Enterprise Mobility Management) des Device Policy Controller (DPC) als Geräteeigentümer oder Profilinhaber festlegen.

Die DPC-App führt wiederum die folgenden Aktivitäten aus:

Nutzerkonten hinzufügen
Einhaltung der Geräterichtlinien erzwingen
Zusätzliche System-Apps aktivieren

Nach Abschluss der Bereitstellung wird der Intent Handler der DPC-App im vollständig verwalteten Gerätbenutzer (für die Bereitstellung des Geräteeigentümers) oder im Arbeitsprofilbenutzer (für die Bereitstellung des Profilinhabers) ausgeführt.ADMIN_POLICY_COMPLIANCE Anschließend fügt die DPC-App Konten hinzu und erzwingt Richtlinien.

Launcher-Anforderungen

Damit die Geräteverwaltung unterstützt werden kann, muss der Launcher das Kennzeichnen von Apps mit Arbeitssymbolen unterstützen (in AOSP bereitgestellt, um verwaltete Anwendungen darzustellen). Andere UI-Elemente auf verwalteten Geräten oder Profilen, z. B. Benachrichtigungen, müssen Assets mit Arbeitssymbolen verwenden. Launcher3 in AOSP unterstützt diese Kennzeichnungsfunktionen bereits.

Standard-Arbeits-Apps

Standardmäßig werden im Rahmen der Android Enterprise-Bereitstellung nur Anwendungen aktiviert, die für den korrekten Betrieb eines verwalteten Geräts oder Arbeitsprofils erforderlich sind. Gerätehersteller können eine Liste von Standard-Apps mithilfe der folgenden XML-Dateien angeben:

vendor_required_apps_managed_profile.xml
vendor_required_apps_managed_device.xml
vendor_required_apps_managed_user.xml

Nach der Gerätebereitstellung können IT-Administratoren über die EMM-Konsole oder Managed Google Play zusätzliche Apps bereitstellen, die von einem Unternehmen als erforderlich erachtet werden.

In beiden Modi (Geräteeigentümer – vollständig verwaltetes Gerät – und Profilinhaber – Arbeitsprofil):

Apps ohne Launcher-Symbole gelten als wichtige Systemkomponenten und werden automatisch von Android aktiviert.
Apps mit Launcher-Symbolen können während der Geräte bereitstellung standardmäßig aktiviert werden, indem Sie ihre Paketnamen in die Zulassungsliste in den Dateien vendor_required_apps_managed_[device|profile|user].xml files aufnehmen.
Alle anderen Apps werden während der Gerätebereitstellung automatisch deaktiviert.

Implementierung des Geräteeigentümers auf Geräten, die mit einem monitorlosen Systemnutzer konfiguriert sind

In Android 14 (API-Level 34) wird die Konfiguration des monitorlosen Systemnutzermodus eingeführt, bei der der Systemnutzer ein Hintergrundnutzer und die Vordergrund nutzer sekundäre Nutzer sind. Da die Funktion des Geräteeigentümers traditionell darauf basiert, dass sich der Systemnutzer auch im Vordergrund befindet, stellt die Konfiguration des monitorlosen Systemnutzers vollständig verwaltete Geräte (Bereitstellung des Geräteeigentümers)vor bestimmte einzigartige Herausforderungen.

Monitorloser Systemnutzermodus

Abbildung 1 : Monitorloser Systemnutzermodus

Auf einem Gerät im monitorlosen Systemnutzermodus kann eine DPC-Anwendung (Device Policy Controller) nur dann als Geräteeigentümer festgelegt werden, wenn sie den verknüpften Modus (HEADLESS_DEVICE_OWNER_MODE_AFFILIATED) unterstützt. Das System prüft, ob der verknüpfte Modus unterstützt wird, indem es getHeadlessDeviceOwnerMode() aufruft. Die Gerätebereitstellung wird entsprechend verarbeitet, je nachdem, ob die DPC-Anwendung die Bereitstellung im verknüpften Modus unterstützt.