Geräte, die bereits über Ihren benutzerdefinierten DPC verwaltet werden, können zu Android Device Policy (ADP) migriert werden und die Android Management API nutzen.
Voraussetzungen
- 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 Android 11 oder höher ausgeführt werden.
Integration mit dem AMAPI SDK in Ihren benutzerdefinierten DPC
Für den Migrationsprozess muss die benutzerdefinierte DPC-Anwendung das AMAPI SDK integrieren. Weitere Informationen zu dieser Bibliothek und dazu, wie Sie sie zu Ihrer Anwendung hinzufügen können, finden Sie im Integrationsleitfaden für das AMAPI SDK.
Schritte zur Migration eines Geräts
- Richten Sie eine Richtlinie ein, die vom Gerät nach der Migration zu AMAPI verwendet werden soll. Für eine optimale Nutzererfahrung sollte dies der Richtlinie entsprechen, die bereits von Ihrem DPC auf dem Gerät erzwungen wird.
- Erstelle ein Migrationstoken für das Gerät. Rufe dazu
enterprises.migrationTokens.create
auf. - Senden Sie die
value
dieses Migrationstokens an Ihren benutzerdefinierten DPC. - Prüfen Sie mithilfe der Play EMM API, ob Android Device Policy auf dem Gerät installiert ist.
- Verwenden Sie
DpcMigrationClientFactory
, um einenDpcMigrationClient
zu erstellen. - Rufen Sie in
DpcMigrationClient
die MethodemigrateDeviceManagementToAndroidManagementApi
auf. Damit ist die Migration abgeschlossen. deviceState
ändert sich inACTIVE
und Sie erhalten eineSTATUS_REPORT
-Nachricht über den Pub/Sub-Kanal.
Nach Abschluss der Migration verliert die aufrufende App die Berechtigungen „Geräteinhaber“ oder „Profilinhaber“, da diese an 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 während der Migration Netzwerkverbindungen unterbrochen werden. Die wichtigsten Vorgänge, die eine Netzwerkverbindung erfordern, werden ausgeführt, bevor die Rechte des Geräteinhabers oder des Profilinhabers von Ihrem DPC an die Android Device Policy übertragen werden.
Migrationstoken
Ein Migrationstoken wird vom EMM-Server angefordert, um die Absicht zu signalisieren, ein bestimmtes Gerät zu migrieren, das von einem benutzerdefinierten DPC verwaltet wird. Ein Migrationstoken kann so lange verwendet werden, bis die Migration erfolgreich abgeschlossen ist oder bis sie abläuft.
Benutzerdefinierte DPC-Integration
Erstellen Sie zuerst ein DpcMigrationRequest
und übergeben Sie das Token und gegebenenfalls die Liste der konfigurierten WLANs an den Builder:
// Create a DpcMigrationRequest
DpcMigrationRequest request =
DpcMigrationRequest.builder()
.setMigrationToken(token)
.build();
Sie können dann ein DpcMigrationClient
abrufen und den Migrationsprozess mit migrateDeviceManagementToAndroidManagementApi
starten:
// 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
verfolgt.
Sie können direkt die von migrateDeviceManagementToAndroidManagementApi
zurückgegebene ID oder die Methoden getMigrationAttempt
und listMigrationAttempts
verwenden, um Migrationsversuche abzurufen und aufzulisten.
// Passing an empty name, we retrieve the last attempt
var request = GetDpcMigrationAttemptRequest.builder().build();
var attempt = client.getMigrationAttempt(request);
Optional kannst du mit deinem NotificationReceiverService
eine DpcMigrationListener
einrichten, um Statusupdates für DpcMigrationAttempt
zu überwachen.
// 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
}
}
Umgang mit WLANs
Wenn es WLANs gibt, die vom benutzerdefinierten DPC verwaltet werden, sollte die AMAPI ONC-Richtlinie die Konfigurationen dieser Netzwerke abgleichen, damit die AMAPI sie problemlos verwalten kann. 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, dass jedes in der Richtlinie konfigurierte WLAN, das dieselbe SSID und denselben Sicherheitstyp wie ein konfiguriertes WLAN auf dem Gerät hat, mit dem übereinstimmenden konfigurierten WLAN identisch ist. Daher bleiben WLAN-Netzwerke, die von benutzerdefinierten DPC konfiguriert wurden, nach der Migration unberührt, bis eine Änderung in der ONC-Richtlinie für das Netzwerk erfolgt. Wenn der benutzerdefinierte DPC jedoch nach der Migration deinstalliert wird, werden die vom benutzerdefinierten DPC konfigurierten WLAN-Netzwerke automatisch entfernt. Android Device Policy erzwingt weiterhin Richtlinien. Wenn eines dieser Netzwerke in einer Richtlinie konfiguriert ist, werden die in der Richtlinie konfigurierten Netzwerke wie gewohnt hinzugefügt.
Arbeitsprofil auf einem privaten Gerät
Aus technischen Gründen müssen vom benutzerdefinierten DPC konfigurierte WLANs durch den benutzerdefinierten DPC für Android Device Policy entfernt werden, um diese WLANs verwalten zu können. Das AMAPI SDK erledigt das und entfernt solche WLANs, bevor die Inhaberschaft vom benutzerdefinierten DPC an die Android Device Policy übertragen wird. Der benutzerdefinierte DPC muss jedoch Informationen zu diesen Netzwerken in DpcMigrationRequest
übergeben. Nach der Migration werden in der Richtlinie konfigurierte Netzwerke normal hinzugefügt. Daher wird empfohlen, die vom benutzerdefinierten DPC hinzugefügten Netzwerke auch in der Richtlinie zu konfigurieren.
Beachten Sie dabei Folgendes:
- Wenn das aktive Netzwerk ein von einem benutzerdefinierten DPC konfiguriertes WLAN ist, kann das Gerät während der Migration kurz offline sein.
- In
DpcMigrationRequest
sollten nur die vom benutzerdefinierten DPC konfigurierten WLAN-Netzwerke übergeben werden. Andernfalls schlägt die Migration fehl, wenn ein Netzwerk nicht vom AMAPI SDK entfernt werden kann (z. B. ein vom Nutzer hinzugefügtes WLAN). - WLANs sollten nur dann in
DpcMigrationRequest
übergeben werden, wenn der benutzerdefinierte DPC ein Profilinhaber auf einem privaten Gerät ist. Andernfalls schlägt die Migration fehl. - Aus technischen Gründen ist Android 12 ein Ausnahmefall, bei dem die in
DpcMigrationRequest
übergebenen Netzwerke ignoriert und alle vom benutzerdefinierten DPC konfigurierten WLAN-Netzwerke automatisch entfernt werden. Außerdem muss der benutzerdefinierte DPC die BerechtigungACCESS_WIFI_STATE
unter Android 12 für Arbeitsprofile auf privaten Geräten haben. Andernfalls schlägt die Migration fehl.
Wichtige Hinweise
Im Folgenden sind einige Einschränkungen im Zusammenhang mit dieser Funktion aufgeführt.
Unternehmensspezifische ID
Bei Arbeitsprofilen unter Android 12 und höher ändert sich die unternehmensspezifische ID, auf die über DevicePolicyManager.getEnrollmentSpecificId
zugegriffen werden kann, zum Zeitpunkt der Migration nicht. Wenn jedoch ein von der Android Device Policy verwaltetes Arbeitsprofil auf dem Gerät neu erstellt wird, z. B. nach dem Löschen des vorherigen Profils oder nach dem Zurücksetzen auf die Werkseinstellungen, ändert sich die unternehmensspezifische ID zu diesem Zeitpunkt.
Arbeitsprofile auf vollständig verwalteten Geräten
Diese Funktion wird auf vollständig verwalteten Geräten mit einem Arbeitsprofil mit Android 9 oder 10 nicht unterstützt. Es darf nicht versucht werden, diese Geräte zu migrieren. Unabhängig davon, ob ein Fehler gemeldet wird, werden diese Geräte nicht für die DPC-Migration unterstützt.