Vorhandene Geräte zu AMAPI migrieren

Geräte, die bereits von deinem benutzerdefinierten DPC verwaltet werden, können zu Android Device Policy migriert werden und die Android Management API nutzen.

Hinweis:Dieser Vorgang ist für Endnutzer transparent. Dieser Vorgang kann nur in eine Richtung vorgenommen werden und kann nach Abschluss nicht rückgängig gemacht werden. Außerdem kann er nicht für die Migration eines Geräts von einem EMM zu einem anderen verwendet werden.

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 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.
  • Wenn Arbeitsprofile auf unternehmenseigenen Geräten verwendet werden, muss auf dem Gerät Android 11 oder höher ausgeführt werden.

AMAPI SDK in Ihren benutzerdefinierten DPC einbinden

Für den Migrationsprozess muss die benutzerdefinierte DPC-Anwendung das AMAPI SDK einbinden. 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.

Hinweis: Für diesen Vorgang ist Version 1.1.4 oder höher der AMAPI SDK-Bibliothek erforderlich.

Schritte zum Migrieren eines Geräts

  1. 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.
  2. Erstellen Sie durch Aufrufen von enterprises.migrationTokens.create ein Migrationstoken für das Gerät.
  3. Senden Sie das value dieses Migrationstokens an Ihren benutzerdefinierten DPC.
  4. Sorgen Sie mithilfe der Play EMM API dafür, dass Android Device Policy auf dem Gerät installiert ist.
  5. Verwenden Sie DpcMigrationClientFactory, um eine DpcMigrationClient zu erstellen.
  6. Rufen Sie für DpcMigrationClient die Methode migrateDeviceManagementToAndroidManagementApi auf. Damit ist die Migration abgeschlossen.
  7. Das deviceState wird zu ACTIVE geändert und Sie erhalten eine STATUS_REPORT-Nachricht über den Pub/Sub-Kanal.

Nach Abschluss der Migration verliert die aufrufende App die Berechtigungen „Geräteinhaber“ oder „Profilinhaber“, da diese in die Android Device Policy übertragen werden.

Hinweis:Das Gerät muss mit dem Internet verbunden sein, damit die Migration gestartet werden kann. Der Prozess ist so konzipiert, dass Netzwerkunterbrechungen während der Migration nicht beeinträchtigt werden. So werden die wichtigsten Vorgänge, die eine Netzwerkverbindung erfordern, durchgeführt, bevor die Rechte des Geräteinhabers oder Profilinhabers von Ihrem DPC an 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 bis zum Abschluss der Migration oder bis zum Ablauf der Migration verwendet werden.

Benutzerdefinierte DPC-Integration

Zuerst müssen Sie ein DpcMigrationRequest erstellen. Dazu übergeben Sie das Token und gegebenenfalls die Liste der konfigurierten WLAN-Netzwerke an den Builder:

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

Sie können dann einen DpcMigrationClient verwenden und den Migrationsprozess mit migrateDeviceManagementToAndroidManagementApi starten:

// Create a DpcMigrationClient
DpcMigrationClient dpcMigrationClient = DpcMigrationClientFactory.create(context);
try {
  // Use helper functiong 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

Die Migration wird auf dem Gerät über eine DpcMigrationAttempt verfolgt.

Sie können die von migrateDeviceManagementToAndroidManagementApi zurückgegebene 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);

Du kannst optional mit deinem NotificationReceiverService einen DpcMigrationListener einrichten, um Statusaktualisierungen für die DpcMigrationAttempt zu erhalten.

// 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 vom benutzerdefinierten DPC verwaltete WLAN-Netzwerke verwaltet werden, sollte die AMAPI ONC-Richtlinie den Konfigurationen dieser Netzwerke entsprechen, damit AMAPI sie reibungslos 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 mit derselben SSID und demselben Sicherheitstyp wie ein konfiguriertes WLAN auf dem Gerät mit dem entsprechenden konfigurierten WLAN identisch ist. Daher bleiben von benutzerdefinierten DPC konfigurierte WLANs nach der Migration unberührt, bis es eine Änderung in der ONC-Richtlinie für das Netzwerk gibt. Wenn der benutzerdefinierte DPC jedoch nach der Migration deinstalliert wird, werden die vom benutzerdefinierten DPC konfigurierten WLAN-Netzwerke automatisch entfernt. Die Android Device Policy erzwingt weiterhin die Richtlinie. Wenn eines dieser Netzwerke in der 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 vom benutzerdefinierten DPC für Android Device Policy entfernt werden, um mit der Verwaltung dieser WLANs beginnen zu können. Das AMAPI SDK kümmert sich darum und entfernt solche WLANs, bevor die Inhaberschaft vom benutzerdefinierten DPC an die Android Device Policy übertragen wird. Der benutzerdefinierte DPC setzt jedoch voraus, dass Informationen zu diesen Netzwerken in DpcMigrationRequest übergeben werden. Nach der Migration werden in der Richtlinie konfigurierte Netzwerke normal hinzugefügt. Daher wird empfohlen, die vom benutzerdefinierten DPC hinzugefügten Netzwerke ebenfalls in der Richtlinie zu konfigurieren.

Beachten Sie die folgenden Punkte:

  • Wenn das aktive Netzwerk ein von benutzerdefiniertem DPC konfiguriertes WLAN ist, kann das Gerät während der Migration kurz offline sein.
  • In DpcMigrationRequest sollten nur die vom benutzerdefinierten DPC konfigurierten WLANs ü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 WLANs automatisch entfernt werden. Außerdem muss der benutzerdefinierte DPC unter Android 12 die Berechtigung ACCESS_WIFI_STATE für Arbeitsprofile auf privaten Geräten haben. Andernfalls schlägt die Migration fehl.

Wichtige Hinweise

Im Folgenden finden Sie 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 über die Android Device Policy verwaltetes Arbeitsprofil auf dem Gerät neu erstellt wird, z. B. nachdem das vorherige Profil gelöscht oder das Gerät auf die Werkseinstellungen zurückgesetzt wurde, ä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 auftritt, werden solche Geräte für die DPC-Migration nicht unterstützt.