Geräte, die bereits über Ihren benutzerdefinierten DPC verwaltet werden, können zum Android-Gerät migriert werden. Policy (ADP) und nutze die Android Management API.
Vorbereitung
- Das Gerät wird bereits von Ihrem EMM mit einem benutzerdefinierten DPC verwaltet.
- Ihr benutzerdefinierter DPC ist in das AMAPI SDK integriert.
- Das Gerät ist bei der Google Play EMM API registriert.
- Das Gerät gehört zu einer Kontogruppe für Managed Google Play.
- Auf dem Gerät ist Android 9 oder höher installiert.
- Bei Arbeitsprofilen auf unternehmenseigenen Geräten muss das Gerät Android 11 oder höher.
Integration mit dem AMAPI SDK in Ihren benutzerdefinierten DPC
Für den Migrationsprozess muss die benutzerdefinierte DPC-Anwendung das AMAPI-SDK. Weitere Informationen zu dieser Bibliothek und dazu, wie du sie hinzufügen kannst für Ihre Anwendung finden Sie im Integrationsleitfaden für das AMAPI SDK.
Schritte zur Migration eines Geräts
- Richten Sie eine Richtlinie ein, die nach der Migration auf dem Gerät verwendet werden soll. zu AMAPI. Für eine optimale Nutzererfahrung sollte dies der Richtlinie entsprechen bereits durch Ihren DPC auf dem Gerät erzwungen.
- Erstellen Sie ein Migrationstoken für das Gerät, indem Sie folgenden Befehl aufrufen:
enterprises.migrationTokens.create
- Senden Sie die
value
dieses Migrationstokens an Ihren benutzerdefinierten DPC. - Stellen Sie sicher, dass Android Device Policy auf dem Gerät installiert ist, indem Sie EMM API von Google Play
- Mit
DpcMigrationClientFactory
erstellen:DpcMigrationClient
- Rufen Sie im
DpcMigrationClient
die MethodemigrateDeviceManagementToAndroidManagementApi
-Methode. Damit ist die Migration abgeschlossen. - Das
deviceState
ändert sich zuACTIVE
. Du erhältst einSTATUS_REPORT
-Nachricht über den Pub/Sub-Kanal.
Nach Abschluss der Migration verliert die aufrufende App den Geräteinhaber oder das Profil. Eigentümerberechtigungen, da diese auf die Android Device Policy übertragen werden.
Hinweis:Das Gerät muss mit dem Internet verbunden sein, um die Migration zu starten. Der Prozess ist so konzipiert, dass es während der damit die Schlüsselvorgänge, die eine Netzwerkverbindung erfordern, werden vor der Übertragung der Rechte des Geräteinhabers oder Profilinhabers durchgeführt. von Ihrem DPC an Android Device Policy.
Migrationstoken
Ein Migrationstoken wird vom EMM-Server angefordert, um zu signalisieren, Sie migrieren ein bestimmtes Gerät, das von einem benutzerdefinierten DPC verwaltet wird. Sie können ein Migrationstoken verwenden, bis die Migration erfolgreich abgeschlossen ist, oder bis sie abläuft.
Benutzerdefinierte DPC-Integration
Zuerst müssen Sie ein DpcMigrationRequest
erstellen. Dabei übergeben Sie
das Token und, falls erforderlich, die Liste der konfigurierten WLAN-Netzwerke
Builder:
// Create a DpcMigrationRequest
DpcMigrationRequest request =
DpcMigrationRequest.builder()
.setMigrationToken(token)
.build();
Sie können dann mit „get“ DpcMigrationClient
den
Migrationsprozess mit
migrateDeviceManagementToAndroidManagementApi
:
// Create a DpcMigrationClient
DpcMigrationClient dpcMigrationClient = DpcMigrationClientFactory.create(context);
try {
// Use helper function to retrieve Admin component name
var adminComponentName = getAdminComponent(context);
ListenableFuture<DpcMigrationAttempt> futureAttempt =
dpcMigrationClient.migrateDeviceManagementToAndroidManagementApi(
new ComponentName(context, DpcMigrationNotificationReceiver.class),
adminComponentName,
request);
// handle futureAttempt
} catch (RuntimeException e) {
// send failure feedback: "Error: " + e
}
Migrationsfortschritt verfolgen
Der Migrationsprozess wird auf dem Gerät über eine
DpcMigrationAttempt
Sie können die vom
migrateDeviceManagementToAndroidManagementApi
oder verwenden
getMigrationAttempt
und listMigrationAttempts
-Methoden, um
und eine Liste der Migrationsversuche erstellen.
// Passing an empty name, we retrieve the last attempt
var request = GetDpcMigrationAttemptRequest.builder().build();
var attempt = client.getMigrationAttempt(request);
Optional können Sie ein DpcMigrationListener
einrichten mit
Ihr NotificationReceiverService
, um auf
Statusupdates für DpcMigrationAttempt
.
// DpcMigrationNotificationReceiver for callback handling
public class DpcMigrationNotificationReceiver extends NotificationReceiverService
implements DpcMigrationListener {
@Override
protected DpcMigrationListener getDpcMigrationListener() {
// getDpcMigrationListener"
return this;
}
@Override
public void onMigrationStateChanged(DpcMigrationAttempt migrationAttempt) {
// send success feedback
}
}
WLANs verwalten
Wenn es WLANs gibt, die vom benutzerdefinierten DPC verwaltet werden, AMAPI ONC-Richtlinie müssen mit den Konfigurationen dieser Netzwerke übereinstimmen, damit sie von AMAPI verwaltet werden können reibungslos zu gestalten. Die Interaktion der DPC-Migration mit der WLAN-Verwaltung variiert je nach Verwaltungsmodus.
Vollständig verwaltete Geräte und Arbeitsprofile auf unternehmenseigenen Geräten
Während der Migration geht Android Device Policy davon aus, in der Richtlinie konfiguriert, die SSID und den Sicherheitstyp Das konfigurierte WLAN auf dem Gerät ist mit dem konfigurierten WLAN identisch. WLAN. Daher bleiben WLAN-Netzwerke, die von einem benutzerdefinierten DPC konfiguriert wurden, unverändert. nach der Migration, bis sich die ONC-Richtlinie entsprechend der Netzwerk. Wenn der benutzerdefinierte DPC jedoch nach der Migration deinstalliert wird, Über einen benutzerdefinierten DPC konfigurierte WLANs werden automatisch entfernt. Android Device Policy erzwingt weiterhin Richtlinien. Wenn eines dieser Netzwerke in der Richtlinie konfiguriert sind, werden die in der Richtlinie konfigurierten Netzwerke hinzugefügt als Üblicherweise.
Arbeitsprofil auf einem privaten Gerät
Aus technischen Gründen müssen WLANs, die vom benutzerdefinierten DPC konfiguriert wurden,
vom benutzerdefinierten DPC für Android Device Policy entfernt, um sie verwalten zu können
WLANs. Das AMAPI SDK erledigt das und entfernt solche WLANs
bevor die Inhaberschaft vom benutzerdefinierten DPC an Android Device Policy übertragen wird
Der benutzerdefinierte DPC muss jedoch Informationen zu diesen Netzwerken
DpcMigrationRequest
Nach der Migration werden Netzwerke
in Richtlinie konfiguriert, werden normal hinzugefügt. Es wird daher empfohlen,
Die vom benutzerdefinierten DPC hinzugefügten Netzwerke müssen auch in der Richtlinie konfiguriert werden.
Beachten Sie dabei Folgendes:
- Wenn das aktive Netzwerk ein WLAN ist, das von einem benutzerdefinierten DPC konfiguriert wurde, während der Migration kurz offline sein.
- Es sollten nur die WLAN-Netzwerke übergeben werden, die vom benutzerdefinierten DPC konfiguriert wurden
DpcMigrationRequest
. Andernfalls schlägt die Migration fehl, wenn Netzwerk kann nicht vom AMAPI SDK entfernt werden (z.B. vom Nutzer hinzugefügte WLAN-Netzwerke). - WLAN-Netzwerke müssen übergeben werden.
DpcMigrationRequest
nur, wenn der benutzerdefinierte DPC ein auf einem privaten Gerät verwenden, da andernfalls die Migration fehlschlägt. - Aus technischen Gründen ist Android 12 ein Ausnahmefall, in dem die Netzwerke
übergebene
DpcMigrationRequest
ignoriert und alle WLANs Vom benutzerdefinierten DPC konfigurierte Netzwerke werden automatisch entfernt. Außerdem ist es ist eine Voraussetzung für den benutzerdefinierten DPC, umACCESS_WIFI_STATE
zu haben unter Android 12 für Arbeitsprofile auf privaten Geräten Andernfalls schlägt die Migration fehl.
Vorsichtsmaßnahmen
Im Folgenden sind einige Einschränkungen im Zusammenhang mit dieser Funktion aufgeführt.
Unternehmensspezifische ID
Bei Arbeitsprofilen unter Android 12 und höher die unternehmensspezifische ID,
Sie können über DevicePolicyManager.getEnrollmentSpecificId
darauf zugreifen.
zum Zeitpunkt der Migration nicht geändert. Wenn jedoch ein Arbeitsprofil
über die Android Device Policy verwaltet wird, auf dem Gerät neu erstellt wird (z. B.
nachdem Sie das vorherige gelöscht oder
das Gerät auf die Werkseinstellungen zurückgesetzt haben),
ändert sich die unternehmensspezifische ID.
Arbeitsprofile auf vollständig verwalteten Geräten
Diese Funktion wird auf vollständig verwalteten Geräten mit einer mit Android 9 oder 10. Es darf nicht versucht werden, diese Geräte zu migrieren. Geräte werden nicht unterstützt, unabhängig davon, ob ein Fehler gemeldet wird oder nicht. für die DPC-Migration.