Vorhandene Geräte zu AMAPI migrieren

Geräte, die bereits von Ihrem benutzerdefinierten DPC verwaltet werden, können zu Android Device Policy (ADP) migriert werden, um die Android Management API zu nutzen.

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 mit 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 auf dem Gerät Android 11 oder höher ausgeführt werden.

Integration in das AMAPI SDK in Ihrem benutzerdefinierten DPC

Für den Migrationsprozess muss in die benutzerdefinierte DPC-Anwendung das AMAPI-SDK eingebunden werden. Weitere Informationen zu dieser Bibliothek und dazu, wie Sie sie Ihrer Anwendung hinzufügen, finden Sie im AMAPI SDK-Integrationsleitfaden.

Schritte zum Migrieren eines Geräts

  1. Richten Sie eine Richtlinie ein, die vom Gerät verwendet werden soll, nachdem es zu AMAPI migriert wurde. Für eine optimale Nutzererfahrung sollte dies der Richtlinie entsprechen, die bereits von Ihrem DPC auf dem Gerät erzwungen wird. Die Richtlinie in der AMAPI muss zu demselben Unternehmen gehören, zu dem das Gerät bereits in der Play EMM API gehört. Der Name eines Unternehmens ist in der AMAPI und der Play EMM API identisch.
  2. Erstellen Sie ein Migrationstoken für das Gerät, indem Sie enterprises.migrationTokens.create aufrufen.
  3. Senden Sie die value dieses Migrationstokens an Ihren benutzerdefinierten DPC.
  4. Prüfen Sie mit der Play EMM API, ob Android Device Policy auf dem Gerät installiert ist.
  5. DpcMigrationClientFactory verwenden, um ein DpcMigrationClient zu erstellen
  6. Rufen Sie für DpcMigrationClient die Methode migrateDeviceManagementToAndroidManagementApi auf. Damit ist die Migration abgeschlossen.
  7. Die deviceState ändert sich zu ACTIVE und Sie erhalten eine STATUS_REPORT-Nachricht über den Pub/Sub-Kanal.

Nach Abschluss der Migration verliert die Anruf-App ihre Berechtigungen als Geräteinhaber oder Profilinhaber, da diese auf Android Device Policy übertragen werden. Dieser Vorgang kann durch das folgende Sequenzdiagramm dargestellt werden:

Sequenzdiagramm für die DPC-Migration

Hinweis:Das Gerät muss mit dem Internet verbunden sein, damit die Migration gestartet werden kann. Der Prozess ist so konzipiert, dass er auch bei Netzwerkunterbrechungen während der Migration stabil bleibt. Die wichtigsten Vorgänge, für die eine Netzwerkverbindung erforderlich ist, werden vor der eigentlichen Übertragung der Rechte des Geräteinhabers oder Profilinhabers von Ihrem DPC auf die Android Device Policy-App ausgeführt.

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 verwendet werden, bis die Migration erfolgreich abgeschlossen ist oder bis es abläuft.

Benutzerdefinierte DPC-Integration

Zuerst müssen Sie ein DpcMigrationRequest erstellen und das Token und gegebenenfalls die Liste der konfigurierten WLANs an den Builder übergeben:

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

NotificationReceiverService einrichten und Migration verfolgen

Implementieren Sie ein NotificationReceiverService in Ihrem benutzerdefinierten DPC.

Der Migrationsprozess wird auf dem Gerät über eine DpcMigrationAttempt verfolgt.

Sie können die von migrateDeviceManagementToAndroidManagementApi zurückgegebene ID direkt verwenden 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 können Sie mit Ihrem NotificationReceiverService ein DpcMigrationListener einrichten, um Statusaktualisierungen für das DpcMigrationAttempt zu erfassen.

// DpcMigrationNotificationReceiver for callback handling
public class DpcMigrationNotificationReceiver extends NotificationReceiverService
    implements DpcMigrationListener {

  @Override
  protected DpcMigrationListener getDpcMigrationListener() {
    return this;
  }

  @Override
  public void onMigrationStateChanged(DpcMigrationAttempt migrationAttempt) {
    // send success feedback
  }
}

WLANs verarbeiten

Wenn es WLAN-Netzwerke gibt, die vom benutzerdefinierten DPC verwaltet werden, sollte die AMAPI-ONC-Richtlinie mit den Konfigurationen dieser Netzwerke übereinstimmen, damit AMAPI sie problemlos verwalten kann. Die Interaktion der DPC-Migration mit der WLAN-Verwaltung hängt vom Verwaltungsmodus ab.

Vollständig verwaltete Geräte und Arbeitsprofile auf unternehmenseigenen Geräten

Während der Migration geht die Android Device Policy davon aus, dass jedes in der Richtlinie konfigurierte WLAN mit derselben SSID und demselben Sicherheitstyp wie ein auf dem Gerät konfiguriertes WLAN mit dem entsprechenden konfigurierten WLAN identisch ist. Daher bleiben WLANs, die durch einen benutzerdefinierten DPC konfiguriert wurden, nach der Migration unverändert, bis sich die ONC-Richtlinie für das Netzwerk ändert. Wenn der benutzerdefinierte DPC nach der Migration deinstalliert wird, werden die vom benutzerdefinierten DPC konfigurierten WLANs jedoch automatisch entfernt. Die Android Device Policy erzwingt weiterhin Richtlinien. Wenn eines dieser Netzwerke in der Richtlinie konfiguriert ist, werden die Netzwerke wie in der Richtlinie konfiguriert wie gewohnt hinzugefügt.

Arbeitsprofil auf einem privaten Gerät

Aus technischen Gründen müssen vom benutzerdefinierten DPC konfigurierte WLANs vom benutzerdefinierten DPC entfernt werden, damit Android Device Policy diese WLANs verwalten kann. Das AMAPI SDK übernimmt diese Aufgabe und entfernt solche WLANs, bevor die Inhaberschaft vom benutzerdefinierten DPC auf Android Device Policy übertragen wird. Dazu muss der benutzerdefinierte DPC jedoch Informationen zu diesen Netzwerken in DpcMigrationRequest übergeben. Nach der Migration werden Netzwerke, die in der Richtlinie konfiguriert sind, normal hinzugefügt. Es wird daher empfohlen, dass die vom benutzerdefinierten DPC hinzugefügten Netzwerke ebenfalls in der Richtlinie konfiguriert werden.

Beachten Sie Folgendes:

  • Wenn das aktive Netzwerk ein WLAN ist, das von einem benutzerdefinierten DPC konfiguriert wurde, kann das Gerät während der Migration kurz offline sein.
  • Nur die von benutzerdefinierten Geräteinhabern konfigurierten WLANs sollten in DpcMigrationRequest übergeben werden. Andernfalls schlägt die Migration fehl, wenn ein Netzwerk nicht mit dem 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 der Profilinhaber auf einem privaten Gerät ist. Andernfalls schlägt die Migration fehl.
  • Aus technischen Gründen ist Android 12 ein Sonderfall, in dem die in DpcMigrationRequest übergebenen Netzwerke ignoriert werden und alle vom benutzerdefinierten DPC konfigurierten WLANs automatisch entfernt werden. Außerdem muss der benutzerdefinierte DPC unter Android 12 für Arbeitsprofile auf privaten Geräten die Berechtigung ACCESS_WIFI_STATE haben, da die Migration sonst fehlschlägt.

Vorsichtsmaßnahmen

Hier sind einige Einschränkungen im Zusammenhang mit dieser Funktion.

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 des Geräts auf die Werkseinstellungen), ändert sich die unternehmensspezifische ID.

Arbeitsprofile auf vollständig verwalteten Geräten

Diese Funktion wird auf vollständig verwalteten Geräten mit einem Arbeitsprofil unter Android 9 oder 10 nicht unterstützt. Diese Geräte dürfen nicht migriert werden. Unabhängig davon, ob ein Fehler auftritt, werden solche Geräte für die DPC-Migration nicht unterstützt.

Befehl RESET_PASSWORD

Wenn das Gerät ein Sperrbildschirm-Passwort hat, kann der RESET_PASSWORD-Befehl erst ausgeführt werden, nachdem der Nutzer seine Anmeldedaten bestätigt hat (z.B. durch erneute Eingabe seiner PIN). Wenn das Gerät kein Passwort für den Sperrbildschirm hat, kann der Befehl RESET_PASSWORD direkt nach der Migration verwendet werden.