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

Urządzenia zarządzane już przez niestandardowy kontroler zasad dotyczących urządzeń (DPC) można przenieść do aplikacji Android Device Policy (ADP) i korzystać z interfejsu Android Management API.

Wymagania wstępne

• Urządzenie jest już zarządzane przez platformę EMM za pomocą niestandardowego kontrolera zasad dotyczących urządzeń.
• Twój niestandardowy DPC jest zintegrowany z pakietem SDK AMAPI.
• Urządzenie jest zarejestrowane w interfejsie Google Play EMM API.
• Urządzenie należy do grupy kont zarządzanego Sklepu Google Play.
• Urządzenie działa na Androidzie 9 lub nowszym.
• W przypadku profili służbowych na urządzeniach należących do firmy urządzenie musi mieć Androida 11 lub nowszego.

Integracja z pakietem AMAPI SDK w niestandardowym kontrolerze zasad dotyczących urządzeń

Proces migracji wymaga zintegrowania niestandardowej aplikacji DPC z pakietem SDK AMAPI. Więcej informacji o tej bibliotece i o tym, jak dodać ją do aplikacji, znajdziesz w przewodniku po integracji pakietu SDK AMAPI.

Kroki migracji urządzenia

1. Skonfiguruj zasady, które mają być używane przez urządzenie po migracji do AMAPI. Aby zapewnić użytkownikom jak najlepsze wrażenia, wartość ta powinna być zgodna z zasadami już egzekwowanymi na urządzeniu przez DPC. Zasady w AMAPI muszą należeć do tego samego przedsiębiorstwa, do którego urządzenie należy już w interfejsie Play EMM API. Pamiętaj, że dana firma ma taką samą nazwę w AMAPI i w interfejsie Google Play EMM API.
2. Utwórz token migracji dla urządzenia, wywołując funkcję enterprises.migrationTokens.create.
3. Wyślij value tego tokena migracji do niestandardowego dostawcy DPC.
4. Sprawdź, czy na urządzeniu jest zainstalowana aplikacja Android Device Policy, korzystając z interfejsu Play EMM API.
5. Użyj DpcMigrationClientFactory, aby utworzyć DpcMigrationClient
6. W DpcMigrationClient wywołaj metodę migrateDeviceManagementToAndroidManagementApi. To ostatni element procesu migracji.
7. Symbol deviceState zmieni się na ACTIVE, a Ty otrzymasz wiadomość STATUS_REPORT przez kanał Pub/Sub.

Po zakończeniu migracji aplikacja do połączeń utraci uprawnienia właściciela urządzenia lub profilu, ponieważ zostaną one przeniesione 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 ten jest odporny na rozłączenia sieci podczas migracji, dzięki czemu kluczowe operacje wymagające połączenia sieciowego są wykonywane przed faktycznym przeniesieniem praw właściciela urządzenia lub właściciela profilu z DPC na aplikację Android Device Policy.

Token migracji

Serwer EMM wysyła żądanie tokena migracji, aby zasygnalizować zamiar migracji konkretnego urządzenia zarządzanego przez niestandardowy kontroler zasad dotyczących urządzeń. Token migracji można używać do momentu pomyślnego zakończenia migracji lub do momentu jego wygaśnięcia.

Integracja niestandardowego DPC

Najpierw musisz utworzyć 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 uzyskać 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
}

Konfigurowanie NotificationReceiverService i śledzenie migracji

Wdróż NotificationReceiverService w niestandardowym kontrolerze zasad urządzenia.

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

Możesz bezpośrednio użyć wartości zwróconej przez funkcję migrateDeviceManagementToAndroidManagementApi lub użyć metod getMigrationAttempt i listMigrationAttempts, aby uzyskać i wyświetlić listę prób 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 nasłuchiwać aktualizacji stanu DpcMigrationAttempt.

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

Obsługa sieci Wi-Fi

Jeśli istnieją sieci Wi-Fi zarządzane przez niestandardowy kontroler zasad urządzeń, zasady ONC AMAPI powinny być zgodne z konfiguracjami tych sieci, aby AMAPI mogło nimi sprawnie zarządzać. Współdziałanie 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 profile służbowe na urządzeniach należących do firmy

Podczas migracji usługa Android Device Policy zakłada, ż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 odpowiednią skonfigurowaną siecią Wi-Fi. Dlatego sieci Wi-Fi skonfigurowane przez niestandardowy kontroler zasad urządzenia pozostają po migracji bez zmian, dopóki nie nastąpi zmiana w zasadach ONC odpowiadających sieci. Jeśli jednak niestandardowy DPC zostanie odinstalowany po migracji, sieci Wi-Fi skonfigurowane przez niestandardowy DPC zostaną automatycznie usunięte. Zasady dotyczące urządzeń z Androidem nadal będą egzekwowane, a jeśli w zasadach skonfigurowano którąś z tych sieci, zostaną one dodane w zwykły sposób.

Profil służbowy na urządzeniu osobistym

Ze względów technicznych sieci Wi-Fi skonfigurowane przez niestandardowy kontroler zasad urządzeń muszą zostać usunięte przez ten kontroler, aby usługa Android Device Policy mogła zarządzać tymi sieciami Wi-Fi. Pakiet AMAPI SDK zajmuje się tym i usuwa takie sieci Wi-Fi przed przeniesieniem własności z niestandardowego DPC na Android Device Policy, ale wymaga, aby niestandardowy DPC przekazywał informacje o tych sieciach w DpcMigrationRequest. Po migracji sieci skonfigurowane w zasadach będą dodawane normalnie, dlatego zalecamy, aby sieci dodane przez niestandardowy kontroler zasad urządzenia były również skonfigurowane w zasadach.

Pamiętaj o tych kwestiach:

• Jeśli aktywna sieć to sieć Wi-Fi skonfigurowana przez niestandardowy DPC, urządzenie może być przez krótki czas offline podczas migracji.
• Przekazywane powinny być tylko sieci Wi-Fi skonfigurowane przez niestandardowy DPC DpcMigrationRequest.W przeciwnym razie migracja nie powiedzie się, jeśli nie będzie można usunąć sieci za pomocą pakietu SDK AMAPI (np. sieci Wi-Fi dodanej przez użytkownika).
• Sieci Wi-Fi należy przekazywać w parametrze DpcMigrationRequest tylko wtedy, gdy niestandardowy DPC jest właścicielem profilu na urządzeniu należącym do użytkownika. W przeciwnym razie migracja się nie powiedzie.
• Ze względów technicznych Android 12 jest wyjątkiem, w którym sieci przekazane w DpcMigrationRequest są ignorowane, a wszystkie sieci Wi-Fi skonfigurowane przez niestandardowy DPC są automatycznie usuwane. Ponadto w przypadku profili służbowych na urządzeniach należących do użytkowników niestandardowy kontroler zasad urządzenia musi mieć uprawnienie ACCESS_WIFI_STATE na Androidzie 12. 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 i nowszym identyfikator specyficzny dla przedsiębiorstwa, 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 ponownie utworzony profil służbowy zarządzany przez Android Device Policy (np. po usunięciu poprzedniego profilu lub po przywróceniu ustawień fabrycznych), identyfikator specyficzny dla firmy ulegnie zmianie.

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, na których działa Android 9 lub 10. Nie należy próbować przenosić tych urządzeń. Niezależnie od tego, czy wystąpi błąd, takie urządzenia nie są obsługiwane w przypadku migracji DPC.

Polecenie RESET_PASSWORD

Jeśli urządzenie ma hasło blokady ekranu, polecenie RESET_PASSWORD zostanie wykonane dopiero po potwierdzeniu przez użytkownika swoich danych logowania (np. ponownym wpisaniu kodu PIN) po migracji. Jeśli urządzenie nie ma hasła blokady ekranu, polecenie RESET_PASSWORD można użyć od razu po migracji.