Vorhandene Geräte zu AMAPI migrieren

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

Vorbereitung

  • Das Gerät wird bereits von Ihrem EMM mit einem benutzerdefinierten DPC verwaltet.
  • Ihr benutzerdefinierter DPC ist in das AMAPI SDK eingebunden.
  • 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 muss Android 9 oder höher installiert sein.
  • Bei Arbeitsprofilen auf unternehmenseigenen Geräten muss auf dem Gerät Android 11 oder höher ausgeführt werden.

AMAPI SDK in deine benutzerdefinierte DPC einbinden

Für die Migration muss das AMAPI SDK in die benutzerdefinierte DPC-Anwendung eingebunden werden. Weitere Informationen zu dieser Bibliothek und dazu, wie du sie deiner Anwendung hinzufügen kannst, findest du im Leitfaden zur AMAPI SDK-Integration.

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.
  2. Erstelle ein Migrationstoken für das Gerät, indem du enterprises.migrationTokens.create aufrufst.
  3. Senden Sie die value dieses Migrationstokens an Ihren benutzerdefinierten DPC.
  4. Prüfen Sie mithilfe der Play EMM API, ob Android Device Policy auf dem Gerät installiert ist.
  5. Verwenden Sie DpcMigrationClientFactory, um eine DpcMigrationClient zu erstellen.
  6. Rufen Sie auf der DpcMigrationClient die Methode migrateDeviceManagementToAndroidManagementApi auf. Damit ist die Migration abgeschlossen.
  7. deviceState ändert sich in ACTIVE und Sie erhalten eine STATUS_REPORT-Nachricht über den Pub/Sub-Kanal.

Nach Abschluss der Migration verliert die anrufende App die Berechtigungen des Geräteeigentümers oder Profilinhabers, da diese an Android Device Policy übertragen werden. Dieser Prozess 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 Vorgang ist so konzipiert, dass er bei Netzwerkunterbrechungen während der Migration möglichst reibungslos abläuft. Die wichtigsten Vorgänge, für die eine Netzwerkverbindung erforderlich ist, werden daher ausgeführt, bevor die Rechte des Geräte- oder Profilinhabers von Ihrer DPC auf die Android Device Policy übertragen werden.

Migrationstoken

Der EMM-Server fordert ein Migrationstoken an, um die Absicht zu signalisieren, ein bestimmtes Gerät zu migrieren, das von einem benutzerdefinierten DPC verwaltet wird. Ein Migrationstoken kann bis zum erfolgreichen Abschluss der Migration oder bis zum Ablauf verwendet werden.

Benutzerdefinierte DPC-Integration

Erstelle zuerst eine DpcMigrationRequest und übergebe das Token und bei Bedarf die Liste der konfigurierten WLANs an den Builder:

// Create a DpcMigrationRequest
DpcMigrationRequest request =
        DpcMigrationRequest.builder()
            .setMigrationToken(token)
            .build();

Sie können dann eine DpcMigrationClient abrufen und die Migration 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 überwacht.

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 kannst du einen DpcMigrationListener mit deinem NotificationReceiverService einrichten, um auf Statusaktualisierungen für den DpcMigrationAttempt zu warten.

// 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, muss die AMAPI ONC-Richtlinie mit den Konfigurationen dieser Netzwerke übereinstimmen, damit AMAPI sie reibungslos 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-Geräterichtlinie davon aus, dass jedes in der Richtlinie konfigurierte WLAN mit derselben SSID und demselben Sicherheitstyp wie ein konfiguriertes WLAN auf dem Gerät mit dem entsprechenden konfigurierten WLAN identisch ist. Daher bleiben WLANs, die über eine benutzerdefinierte DPC konfiguriert wurden, nach der Migration unverändert, bis sich die ONC-Richtlinie für das Netzwerk ändert. Wenn die benutzerdefinierte DPC jedoch nach der Migration deinstalliert wird, werden die damit konfigurierten WLANs automatisch entfernt. Die Android Device Policy wird weiterhin erzwungen. Wenn eines dieser Netzwerke in der Richtlinie konfiguriert ist, werden die Netzwerke wie gewohnt hinzugefügt.

Arbeitsprofil auf einem privaten Gerät

Aus technischen Gründen müssen WLANs, die vom benutzerdefinierten DPC konfiguriert wurden, vom benutzerdefinierten DPC für die Android-Geräterichtlinie entfernt werden, damit diese WLANs verwaltet werden können. Das AMAPI SDK übernimmt diese Aufgabe und entfernt solche WLANs, bevor die Inhaberschaft vom benutzerdefinierten Datenschutz- und Richtlinienkontroll-Objekt an die Android-Geräterichtlinie übertragen wird. Das benutzerdefinierte Datenschutz- und Richtlinienkontroll-Objekt muss jedoch Informationen zu diesen Netzwerken in DpcMigrationRequest übergeben. Nach der Migration werden Netzwerke, die in der Richtlinie konfiguriert sind, normal hinzugefügt. Daher wird empfohlen, dass auch die Netzwerke, die über die benutzerdefinierte DPC hinzugefügt wurden, in der Richtlinie konfiguriert werden.

Beachten Sie dabei Folgendes:

  • Wenn das aktive Netzwerk ein WLAN ist, das mit einem benutzerdefinierten DPC konfiguriert wurde, kann das Gerät während der Migration kurz offline sein.
  • Es sollten nur die WLANs übergeben werden, die über benutzerdefinierte DPCs konfiguriert wurden. Andernfalls schlägt die Migration fehl, wenn ein Netzwerk nicht über das AMAPI SDK entfernt werden kann (z. B. vom Nutzer hinzugefügtes WLAN).DpcMigrationRequest
  • WLANs sollten nur in DpcMigrationRequest übergeben werden, wenn der benutzerdefinierte DPC Inhaber eines Profils 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 über die benutzerdefinierte DPC konfigurierten WLANs automatisch entfernt werden. Außerdem muss der benutzerdefinierte DPC die Berechtigung ACCESS_WIFI_STATE für Arbeitsprofile auf privaten Geräten unter Android 12 haben. Andernfalls schlägt die Migration fehl.

Vorsichtsmaßnahmen

Beachten Sie bei der Verwendung dieser Funktion Folgendes:

Unternehmensspezifische ID

Bei Arbeitsprofilen unter Android 12 und höher ändert sich die unternehmensspezifische ID, auf die unter DevicePolicyManager.getEnrollmentSpecificId zugegriffen werden kann, während der Migration nicht. Wenn jedoch ein von Android Device Policy verwaltetes Arbeitsprofil auf dem Gerät noch einmal erstellt wird (z. B. nachdem das vorherige gelöscht oder das Gerät auf die Werkseinstellungen zurückgesetzt wurde), ä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. Die Migration dieser Geräte darf nicht versucht werden. Unabhängig davon, ob ein Fehler auftritt, werden solche Geräte nicht für die DPC-Migration unterstützt.