Przeprowadź migrację istniejących urządzeń do AMAPI

Urządzenia, którymi zarządza niestandardowy kontroler zasad dotyczących urządzeń, można przenieść do aplikacji Android Device Policy (ADP) i korzystać z interfejsu API zarządzania Androidem.

Uwaga: ten proces jest przejrzysty dla użytkowników. Jest to proces jednokierunkowy (nie można go cofnąć po jego zakończeniu) i nie można go wykorzystać do przeniesienia urządzenia z jednego systemu zarządzania urządzeniami mobilnymi na inny.

Wymagania wstępne

• Urządzeniem zarządza już usługa EMM za pomocą niestandardowego adresu DPC.
• Niestandardowy DPC jest zintegrowany z pakietem AMAPI SDK.
• Urządzenie jest zarejestrowane w interfejsie Google Play EMM API.
• Urządzenie należy do grupy kont zarządzanego Sklepu Google Play.
• Urządzenie musi działać na Androidzie 9 lub nowszym.
• W przypadku profili służbowych na urządzeniach należących do firmy urządzenie musi mieć zainstalowanego Androida 11 lub nowszego.

Integracja z pakietem AMAPI SDK w niestandardowym DPC

Proces migracji wymaga, aby niestandardowa aplikacja DPC zintegrowała pakiet AMAPI SDK. Więcej informacji o tej bibliotece i sposobie dodania jej do aplikacji znajdziesz w przewodniku po integracji pakietu AMAPI SDK.

Ważne: ten proces wymaga biblioteki AMAPI SDK w wersji 1.1.4 lub nowszej. Najnowszą wersję znajdziesz w informacjach o wersji biblioteki AMAPI SDK.
Zalecamy, aby zawsze korzystać z najnowszej wersji biblioteki, aby korzystać z dostępnych poprawek i ulepszeń.

Jak przenieść dane z urządzenia

1. Skonfiguruj zasady, które mają być używane przez urządzenie po migracji do AMAPI. Aby zapewnić użytkownikom jak najlepszy komfort, należy zastosować zasady, które są już egzekwowane na urządzeniu przez administratora.
2. Utwórz token migracji dla urządzenia, wywołując funkcję enterprises.migrationTokens.create.
3. Prześlij value tego tokena migracji do niestandardowego DPC.
4. Upewnij się, że na urządzeniu jest zainstalowana aplikacja Android Device Policy. Aby to sprawdzić, użyj interfejsu Play EMM API.
5. Użyj aplikacji DpcMigrationClientFactory, aby utworzyć plik DpcMigrationClient.
6. Na stronie DpcMigrationClient wywołaj metodę migrateDeviceManagementToAndroidManagementApi. To kończy migrację.
7. Wartość deviceState zmieni się na ACTIVE, a Ty otrzymasz wiadomość STATUS_REPORT przez kanał Pub/Sub.

Po zakończeniu migracji aplikacja do połączeń traci uprawnienia właściciela urządzenia lub właściciela profilu, ponieważ są one przenoszone do aplikacji Android Device Policy. Ten proces można przedstawić za pomocą tego diagramu sekwencji:

Uwaga: aby rozpocząć migrację, urządzenie musi być połączone z internetem. Proces jest odporny na rozłączenia sieci podczas migracji, dzięki czemu kluczowe operacje wymagające połączenia z siecią są wykonywane przed rzeczywistym przeniesieniem praw właściciela urządzenia lub właściciela profilu z DPC do Android Device Policy.

Token migracji

Serwer EMM prosi o token migracji, aby zasygnalizować zamiar przeniesienia konkretnego urządzenia zarządzanego przez niestandardowy DPC. Token migracji może być używany do czasu ukończenia migracji lub do czasu jego wygaśnięcia.

Niestandardowa integracja z DPC

Najpierw musisz utworzyć element DpcMigrationRequest, przekazując token i w razie potrzeby listę skonfigurowanych sieci Wi-Fi do jego konstruktora:

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

Następnie możesz pobrać DpcMigrationClient i rozpocząć proces migracji za pomocą 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
}

Śledzenie postępów migracji

Proces migracji jest śledzony na urządzeniu za pomocą DpcMigrationAttempt.

Możesz użyć bezpośrednio wartości zwracanej przez funkcję migrateDeviceManagementToAndroidManagementApi lub użyć metod getMigrationAttempt i listMigrationAttempts, aby uzyskać i wypisać próby migracji.

// Passing an empty name, we retrieve the last attempt 
var request = GetDpcMigrationAttemptRequest.builder().build();

var attempt = client.getMigrationAttempt(request);

Opcjonalnie możesz skonfigurować DpcMigrationListener za pomocą NotificationReceiverService, aby odbierać aktualizacje stanu 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
  }
}

Obsługa sieci Wi-Fi

Jeśli są sieci Wi-Fi zarządzane przez niestandardowy DPC, zasady AMAPI ONC powinny odpowiadać konfiguracjom tych sieci, aby AMAPI mogło nimi płynnie zarządzać. Interakcja migracji DPC z zarządzaniem Wi-Fi różni się w zależności od trybu zarządzania.

W pełni zarządzane urządzenia i profily służbowe na urządzeniach należących do firmy

Podczas migracji Zasady dotyczące urządzeń z Androidem przyjmują, że każda sieć Wi-Fi skonfigurowana w zasadach, która ma ten sam identyfikator SSID i typ zabezpieczeń co skonfigurowana sieć Wi-Fi na urządzeniu, jest identyczna z odpowiadającą skonfigurowaną siecią Wi-Fi. Dlatego sieci Wi-Fi skonfigurowane przez niestandardowy DPC pozostają bez zmian po migracji, dopóki nie nastąpi zmiana zasad ONC odpowiadających danej sieci. Jeśli jednak po migracji niestandardowy DPC zostanie odinstalowany, sieci Wi-Fi skonfigurowane przez niestandardowy DPC zostaną automatycznie usunięte. Usługa Android Device Policy nadal będzie egzekwować zasady, a jeśli któraś z tych sieci jest skonfigurowana w zasadzie, sieci te zostaną dodane zgodnie ze zwykłą procedurą.

Profil służbowy na urządzeniu osobistym

Z powodów technicznych sieci Wi-Fi skonfigurowane przez niestandardową usługę DPC muszą zostać usunięte przez tę usługę, aby można było nimi zarządzać za pomocą Android Device Policy. Pakiet AMAPI SDK zajmuje się tym i usuwa takie sieci Wi-Fi przed przeniesieniem własności z niestandardowej aplikacji DPC do aplikacji Android Device Policy, ale wymaga, aby niestandardowa aplikacja DPC przekazała informacje o tych sieciach w DpcMigrationRequest. Po migracji sieci skonfigurowane w zasadzie zostaną dodane w zwykły sposób, dlatego zalecamy skonfigurowanie w zasadzie również sieci dodanych przez niestandardową usługę DPC.

Oto kilka kwestii, o których warto pamiętać:

• Jeśli aktywna sieć to sieć Wi-Fi skonfigurowana przez niestandardowy DPC, urządzenie może na krótko przejść w tryb offline podczas migracji.
• Tylko sieci Wi-Fi skonfigurowane przez niestandardowy pakiet DPC powinny być przekazywane w DpcMigrationRequest.W przeciwnym razie migracja zakończy się niepowodzeniem, jeśli sieć nie będzie można usunąć za pomocą pakietu SDK AMAPI (np. sieć Wi-Fi dodana przez użytkownika).
• Sieci Wi-Fi powinny być przekazywaneDpcMigrationRequest tylko wtedy, gdy niestandardowy DPC jest właścicielem profilu na urządzeniu osobistym. W przeciwnym razie migracja się nie powiedzie.
• Z powodów technicznych Android 12 jest wyjątkowym przypadkiem, w którym sieci przekazane w DpcMigrationRequest są ignorowane, a wszystkie sieci Wi-Fi skonfigurowane przez niestandardowy DPC są automatycznie usuwane. Ponadto niestandardowy DPC musi mieć uprawnienie ACCESS_WIFI_STATE w Androidzie 12 dla profili służbowych na urządzeniach należących do użytkowników. W przeciwnym razie migracja się nie powiedzie.

Zastrzeżenia

Oto kilka zastrzeżeń dotyczących tej funkcji.

Identyfikator firmy

W przypadku profili służbowych na Androidzie 12 lub nowszym identyfikator organizacji, do którego można uzyskać dostęp z poziomu DevicePolicyManager.getEnrollmentSpecificId, nie zmienia się w momencie migracji. Jeśli jednak na urządzeniu zostanie utworzony profil służbowy zarządzany przez Android Device Policy (np. po usunięciu poprzedniego lub przywróceniu urządzenia do ustawień fabrycznych), identyfikator firmy zostanie zmieniony.

Profile służbowe na w pełni zarządzanych urządzeniach

Ta funkcja nie jest obsługiwana na w pełni zarządzanych urządzeniach z profilem służbowym i Androidem 9 lub 10. Nie należy próbować migrować tych urządzeń. Niezależnie od tego, czy wystąpił błąd, takie urządzenia nie są obsługiwane w przypadku migracji DPC.