Implementowanie kont użytkowników

W przypadku rejestracji w Androidzie Enterprise istnieją 2 główne typy tożsamości użytkownika: konta zarządzanego Sklepu Google Play i zarządzane konta Google. Konta zarządzane w zarządzanym Sklepie Google Play są powiązane z urządzeniem, co oznacza, że nie są one powiązane z tożsamością Google konkretnego użytkownika. Zarządzane konta Google są natomiast powiązane z firmową tożsamością Google użytkownika, co poprawia komfort korzystania z usługi, ponieważ użytkownik jest stale zalogowany na swoich urządzeniach.

Konta zarządzanego Sklepu Google Play były kiedyś standardem. Google zachęca jednak obecnie wszystkich nowych deweloperów do korzystania z ulepszonego procesu rejestracji, który domyślnie tworzy zarządzane konta Google.

Na końcu tego dokumentu znajdziesz wskazówki dotyczące starszej implementacji, ale wszystkie nowe projekty powinny być zgodne z opisanym tutaj nowym procesem rejestracji.

Przegląd

Ulepszony proces rejestracji urządzeń upraszcza konfigurację urządzeń dzięki wykorzystaniu kilku nowych komponentów i zmianie sposobu wdrażania niestandardowych kontrolerów zasad dotyczących urządzeń (DPC). To nowe podejście wymaga, aby niestandardowe rozwiązania DPC były zintegrowane z pakietem SDK Android Management API (AMAPI) i aplikacją Android Device Policy w celu wykonywania funkcji przygotowywania urządzeń i rejestracji użytkowników.

Pakiet AMAPI SDK udostępnia interfejsy API niezbędne do interakcji z aplikacją Android Device Policy na urządzeniu. Po stronie serwera rozwiązania do zarządzania mobilnością w przedsiębiorstwie (EMM) będą używać interfejsu Play EMM API do generowania tokenów rejestracji wymaganych do rozpoczęcia procesu rejestracji urządzenia.

Aplikacja Android Device Policy odgrywa teraz kluczową rolę w obsłudze operacji na urządzeniu. Pakiet SDK AMAPI służy do zarządzania instalacją i niezbędnymi aktualizacjami na urządzeniu. Aplikacja Android Device Policy przejmuje też proces uwierzytelniania użytkownika, obsługując go bezpośrednio i przekazując tożsamość użytkownika do usługi EMM. Jeśli z jakiegokolwiek powodu nie uda się uwierzytelnić użytkownika, na urządzeniu zostanie utworzone i dodane nowe konto w zarządzanym Sklepie Google Play jako rozwiązanie awaryjne.

Kluczowym elementem tego nowego procesu rejestracji jest zarządzanie dostępem urządzenia do usług Google. Domyślnie urządzenia są uruchamiane w stanie ograniczonym, a usługa EMM odgrywa kluczową rolę w umożliwianiu dostępu po spełnieniu wymagań przez urządzenie.

Integracja interfejsu API

Zanim zaczniesz, sprawdź, czy używasz najnowszej wersji klienta interfejsu Play EMM API i pakietu SDK AMAPI.

Przewodnik po implementacji rejestracji

W tym przewodniku znajdziesz instrukcje wdrażania rejestracji. Obejmuje przygotowanie środowiska, obsługę różnych metod rejestracji i zarządzanie cyklem życia urządzenia.

Przygotowywanie środowiska

Przed rozpoczęciem konfiguracji konta należy przygotować środowisko urządzenia. Przygotowanie polega na zaktualizowaniu Sklepu Play do najnowszej wersji i cichej instalacji na urządzeniu aplikacji Android Device Policy (com.google.android.apps.work.clouddpc). Zainstalowanie aplikacji Android Device Policy jest niezbędne, ponieważ zawiera ona kluczowe komponenty procesu konfiguracji konta. Dostawcy usług EMM nie muszą ręcznie przygotowywać środowiska. Zamiast tego powinni używać EnvironmentClient, zgodnie z dokumentacją dostępną pod adresem i zgodnie z podanymi przykładami kodu.

Przykładowy kod

Zanim będzie można użyć interfejsu AccountSetup do dodania konta służbowego na urządzeniu, DPC musi najpierw sprawdzić, czy środowisko urządzenia jest gotowe.

  • Użyj EnvironmentClientFactory do utworzenia instancji EnvironmentClient i wywołania prepareEnvironment lub prepareEnvironmentAsync.

    val notificationReceiverServiceName = ComponentName(context,
NotificationReceiver::class.java)

// An EMM should implement android.app.admin.DeviceAdminReceiver and use that
// class to instantiate a ComponentName

val admin = ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java)

EnvironmentClientFactory.create(context)
    .prepareEnvironment(
        PrepareEnvironmentRequest.builder()
            .setRoles(
                listOf(
                    Role.builder().setRoleType(
                        Role.RoleType.DEVICE_POLICY_CONTROLLER
                    ).build()
                )
            )
    .setAdmin(admin)
            .build(),
          notificationReceiverServiceName,
        )

[Proceed with AccountSetup]

Ta operacja może potrwać kilka sekund lub minut, ponieważ aplikacje mogą być instalowane lub aktualizowane w celu weryfikacji prawidłowego środowiska pracy. Google zaleca rozpoczęcie tego procesu jak najwcześniej w tle i wyświetlanie odpowiedniego interfejsu, gdy użytkownik czeka. Po zakończeniu operacji urządzenie jest gotowe do użycia interfejsu AccountSetup API przez dostawcę zasad dotyczących urządzeń.

Proces rejestracji

Dostawcy EMM muszą zaprzestać używania users.generateAuthenticationToken() i users.insert() na wszystkich urządzeniach. Zamiast tego platformy EMM muszą wywoływać interfejs API na urządzeniu, aby przeprowadzić uwierzytelnianie użytkownika. Nowy interfejs API zwróci do DPC wartości userId i email. Jeśli Google nie może uwierzytelnić użytkownika, zostanie utworzone konto zarządzanego Sklepu Google Play i dodane do urządzenia. W takim przypadku Google zwróci userId tego konta.

Google wprowadza teraz tokeny rejestracji, które muszą być przekazywane do interfejsu API uwierzytelniania. Systemy EMM określają, kiedy i jak utworzyć token.Może on być częścią istniejącego ładunku rejestracji (np. kodu QR lub konfiguracji Zero-touch).

Google zaleca jednak tworzenie tokena na żądanie i zastąpienie dotychczasowego interfejsu API do zarządzania kontami w zarządzanym Sklepie Google Play nowym interfejsem API, aby zminimalizować zmiany.

Typowa integracja DPC z poprzednimi interfejsami API
Rysunek 1. Typowa integracja DPC z poprzednimi interfejsami API
Przykładowa integracja DPC z nowymi interfejsami API dla urządzeń bez użytkownika
Rysunek 2. Przykładowa integracja DPC z nowymi interfejsami API dla urządzeń bez użytkownika
Przykładowa integracja DPC z nowymi interfejsami API na urządzeniach użytkowników
Rysunek 3. Przykładowa integracja DPC z nowymi interfejsami API na urządzeniach użytkowników

Ulepszony proces rejestracji niestandardowego dostawcy DPC obejmuje te kroki:

Ważny stan początkowy urządzenia: podczas rejestrowania urządzenia za pomocą niestandardowego DPC konto Google dodane do urządzenia jest początkowo wyłączone. Oznacza to, że dostęp do usług Google, w tym Google Play, jest początkowo ograniczony.

Ten domyślny stan „wyłączony” i wymóg, aby system EMM oznaczył urządzenie jako zgodne (np. przez wywołanie Devices.SetState), obowiązują w tych warunkach:

  1. Organizacja potwierdziła w Google własność domeny.
  2. Administrator IT wyraźnie włączył zarządzanie urządzeniami mobilnymi z Androidem przez firmy zewnętrzne w przypadku konkretnej jednostki organizacyjnej użytkownika w konsoli administracyjnej Google.
  1. Utwórz token rejestracji: dostawca usług EMM tworzy token rejestracji za pomocą interfejsu Play EMM API.
  2. Przygotowywanie środowiska: niestandardowy DPC używa procesu przygotowywania środowiska, aby sprawdzić, czy urządzenie jest gotowe do wdrożenia.
  3. Rozpocznij rejestrację: niestandardowy DPC wywołuje interfejs startAccountSetup API w pakiecie AMAPI SDK, przekazując token rejestracji. Uwaga: przed wywołaniem tego interfejsu API DPC musi być właścicielem urządzenia lub właścicielem profilu.
  4. Uruchom działanie uwierzytelniania Google: w razie potrzeby niestandardowy DPC wywołuje interfejs API launchAuthenticationActivity w pakiecie AMAPI SDK, przekazując AccountSetupAttempt. Rozpoczyna to proces uwierzytelniania w Google, a po pomyślnym uwierzytelnieniu użytkownik wraca do niestandardowego DPC. Użytkownik może też pominąć ten proces. W takim przypadku na urządzeniu zostanie dodane konto zarządzanego Sklepu Google Play. Tę opcję można skonfigurować za pomocą googleAuthenticationOptions.
  5. Kończenie rejestracji: pakiet SDK AMAPI powiadamia niestandardowy kontroler zasad urządzenia o wyniku rejestracji.

  6. Włącz usługi Google: gdy niestandardowy kontroler zasad dotyczących urządzeń w pełni skonfiguruje urządzenie i potwierdzi, że jest ono zgodne ze wszystkimi zasadami firmy, serwer EMM musi wywołać Devices.setState() z parametrem accountState ustawionym na "enabled".

    • Dlaczego jest to ważne: to wywołanie interfejsu API oznacza, że urządzenie jest zgodne.
    • Konsekwencje braku połączenia: bez tego Devices.setState(setStateRequest) połączenia konto pozostanie w stanie „wyłączone”. Użytkownik nie będzie mieć dostępu do Google Play (aby instalować i aktualizować aplikacje) ani do innych usług Google, które wymagają uwierzytelnienia konta.

Zarządzanie stanem urządzenia i dostępem do usług

Po wstępnej rejestracji usługa EMM odpowiada za utrzymanie dostępu urządzenia do usług Google na podstawie jego stanu zgodności.

Obsługa przerw w działaniu usługi: BAD_DEVICE_MANAGEMENT

Jeśli dostęp urządzenia do usług Google jest zablokowany, usługi Google Play (GMSCore) wyślą komunikat z działaniem com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT. Dzieje się tak z kilku powodów:

  • Po wstępnej rejestracji urządzenia system EMM nigdy nie wywołał funkcji Devices.setState("enabled").
  • Urządzenie nie jest już zgodne z zasadami EMM, a EMM nie włączył go jeszcze ponownie.
  • Dostawca usług EMM wyraźnie ustawił stan urządzenia na „wyłączony”, wywołując funkcję Devices.setState() z parametrem accountState ustawionym na „wyłączony”. Może to być spowodowane względami bezpieczeństwa, działaniami administracyjnymi lub innymi przyczynami.

Ten zamiar zawiera kod stanu, np. "ThirdPartyDeviceManagementRequired".

Niestandardowe DPC MUSZĄ implementować BroadcastReceiver, aby nasłuchiwać tego zamiaru BAD_DEVICE_MANAGEMENT.

Po otrzymaniu tej transmisji DPC powinien:

  1. Ponowna ocena zgodności: sprawdź, czy urządzenie spełnia obecnie wszystkie zasady ustawione przez EMM.
  2. Podejmij działanie:
    • Jeśli urządzenie jest zgodne: DPC powinien powiadomić serwer EMM. Serwer EMM powinien następnie wywołać funkcję Devices.setState() z parametrem accountState ustawionym na "enabled" dla konkretnego identyfikatora użytkownika i identyfikatora urządzenia, aby spróbować przywrócić dostęp do usługi.
    • Jeśli urządzenie jest niezgodne: po rozwiązaniu problemów i uzyskaniu zgodności urządzenia system EMM powinien wywołać funkcję Devices.setState().

Ten mechanizm zapewnia możliwość wykrywania sytuacji, w których urządzenie traci dostęp do usług Google, i przywracania go.

Kwestie związane z przejęciem firmy

Może dojść do zmiany rodzaju konta organizacji (np. z ManagedGoogleDomainType.TYPE_TEAM na ManagedGoogleDomainType.TYPE_DOMAIN). Chociaż ten proces zwykle nie przerywa powiązania z EMM, czasami może zakłócić dostęp do usług Google na urządzeniach.

Dostawcy usług EMM powinni pamiętać, że jeśli użytkownicy zgłoszą problemy z dostępem do usług po znanym przejęciu, nawet jeśli urządzenie wydaje się zgodne z zasadami EMM, może być konieczne wykonanie połączenia z Devices.setState(), aby ponownie zsynchronizować stan urządzenia z backendami Google w ramach nowej struktury klienta. W przypadku wszystkich urządzeń po przejęciu nie są zwykle wymagane proaktywne połączenia, ale jest to kluczowe narzędzie do rozwiązywania problemów z dostępem.

Konfigurowanie konta – przykładowy kod

  1. Aby zainicjować próbę skonfigurowania konta, aplikacja do połączeń może użyć AccountSetupClient i wywołać metodę startAccountSetup() lub startAccountSetupFuture(). Przykładową implementację znajdziesz w tym przykładowym kodzie:

    // Create AccountSetupClient
val client = AccountSetupClientFactory.create(
    this,
    activityResultRegistry
)
lifecycle.addObserver(client.lifecycleObserver)

// Create adminComponent
val notificationReceiver = ComponentName(this, AccountSetupNotificationReceiver::class.java)
// Helper method to get enrollment token created with Play EMM API
val enrollmentToken = getEnrollmentToken()
val request =
    StartAccountSetupRequest.builder()
        .setEnrollmentToken(enteredText)
        .setNotificationReceiverServiceComponentName(notificationReceiver)
        .setAdminComponentName(
            ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java))
        .build()
try {
    val accountSetupAttempt = client.startAccountSetup(request)
    // handle attempt
} catch (e: Exception) {
    // handle exception
}

  2. Zaimplementuj interfejs AccountSetupListener i podaj implementację sposobu obsługi otrzymanych aktualizacji stanu.

  3. Rozszerz klasę NotificationReceiverService i podaj instancję AccountSetupListener utworzoną w kroku 2, zastępując getAccountSetupListener().

    // Handles account setup changes
class AccountSetupNotificationReceiver :
      NotificationReceiverService(),
      AccountSetupListener {

    override fun getAccountSetupListener(): AccountSetupListener = this

    override fun onAccountSetupChanged(accountSetupAttempt:
  AccountSetupAttempt) {

        when (accountSetupAttempt.state.kind) {
            StateCase.ADDED_ACCOUNT -> {
                val enterpriseAccount = state.addedAccount()
                val userId = enterpriseAccount.userId
                val deviceId = enterpriseAccount.deviceId
                // Handle account added state.

                // IMPORTANT: The device/account is now added but *DISABLED*
                // for Google services. Your EMM backend MUST be notified to
                // perform policy compliance checks and then call Devices.setState()
                // to activate Google Play and other services.

            }
            StateCase.AUTHENTICATION_ACTIVITY_LAUNCH_REQUIRED -> {
                val request = LaunchAuthenticationActivityRequest.builder()
            .setAccountSetupAttempt(accountSetupAttempt)
            .build();
                // Send the attempt to the foreground activity to call:
                accountSetupClient.launchAuthenticationActivity(request)
            }
            StateCase.ACCOUNT_SETUP_ERROR -> {
                // Handle error state.
                val failureReason = state.accountSetupError().failureReason
            }
            else -> {
                // Handle unknown account setup attempt state.
            }
        }
    }
}

  4. Dodaj rozszerzone zajęciaNotificationReceiverService do AndroidManifest.xml i sprawdź, czy zostały wyeksportowane.

      <application>
    <service
        android:name = ".accountsetup.AccountSetupNotificationReceiver"
        android:exported = "true" />
  </application>

    Jeśli Twoja aplikacja jest kierowana na SDK w wersji 30 lub nowszej, w AndroidManifest.xml musi się znajdować element queries, który określa, że aplikacja będzie wchodzić w interakcję z ADP.

      <queries>
    <package android:name="com.google.android.apps.work.clouddpc" />
  </queries>

Wskazówki dotyczące testowania

W tej sekcji znajdziesz zestaw wskazówek i sprawdzonych metod dotyczących testowania implementacji.

Testuj „PrepareEnvironment”

  1. Pobieranie bieżącego stanu urządzenia: system EMM uruchamia

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    aby uzyskać wersję aplikacji Android Device Policy na urządzeniu. Jeśli aplikacja Android Device Policy nie jest zainstalowana, oczekiwane jest puste wyjście.

  2. Zintegruj PrepareEnvironment: niestandardowy DPC wywołuje interfejs prepareEnvironment API w pakiecie AMAPI SDK, przekazując prawidłowe żądanie.

  3. Oczekiwanie na wynik PrepareEnvironment: niestandardowy DPC czeka na zakończenie działania prepareEnvironment.

  4. Potwierdzenie powodzenia działania funkcji PrepareEnvironment: po zakończeniu EMM uruchamia się ponownie.

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    Tym razem wersja aplikacji Zasady dotyczące urządzeń z Androidem powinna być nowsza niż w kroku 1.

Testowanie uwierzytelniania konta Google

  1. Utwórz testową firmę: usługa EMM tworzy testową firmę w Google Workspace powiązaną z testową usługą EMM, z enterprises.generateSignupUrl.
  2. Włącz uwierzytelnianie Google: dostawca usług EMM włącza uwierzytelnianie Google w testowym przedsiębiorstwie, postępując zgodnie z tymi instrukcjami w konsoli administracyjnej Google.
  3. Utwórz token rejestracji: dostawca usług EMM tworzy token rejestracji za pomocą interfejsu Play EMM API z typem userDevice.
  4. Rozpocznij rejestrację: niestandardowy DPC wywołuje interfejs startAccountSetup API w pakiecie AMAPI SDK, przekazując token rejestracji.
  5. Wymagana aktywność uruchamiania: pakiet SDK AMAPI powiadamia niestandardowy kontroler zasad urządzenia, że w celu uwierzytelnienia użytkownika należy uruchomić aktywność.
  6. Uwierzytelnij użytkownika: niestandardowy DPC wywołuje launchAuthenticationActivity, aby rozpocząć działanie. Użytkownik uwierzytelnia się za pomocą zarządzanego konta Google (należącego do grupy utworzonej w kroku 1).
  7. Kończenie rejestracji: pakiet AMAPI SDK powiadamia niestandardowy kontroler zasad urządzenia o wyniku rejestracji.

Testowanie pomijania uwierzytelniania Google

Zastosujemy opisaną wcześniej konfigurację.

Tym razem w kroku 7 użytkownik klika Pomiń zamiast uwierzytelniać się za pomocą konta Google. Rejestracja zostanie zakończona, a na urządzeniu pojawi się konto usługi (tzn. AuthenticationType jest anonimowe).

Testowanie urządzeń bez użytkowników

Ulepszony proces rejestracji niestandardowego DPC, gdy uwierzytelnianie Google jest wyłączone, obejmuje te kroki:

  1. Utwórz testową firmę: może to być ta sama firma, która została utworzona wcześniej.
  2. Utwórz token rejestracji: dostawca usług EMM tworzy token rejestracji za pomocą interfejsu Play EMM API z typem userlessDevice.
  3. Rozpocznij rejestrację: niestandardowy DPC wywołuje interfejs startAccountSetup API w pakiecie AMAPI SDK, przekazując token rejestracji.
  4. Kończenie rejestracji: pakiet SDK AMAPI powiadamia niestandardowy kontroler zasad urządzenia o wyniku rejestracji.