Implementowanie kont użytkowników

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

Konta zarządzanego Sklepu Google Play były standardem. Google zachęca jednak teraz 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 implementacje powinny korzystać z nowego procesu rejestracji opisanego w tym dokumencie.

Przegląd

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

Pakiet AMAPI SDK udostępnia interfejsy API niezbędne do interakcji z aplikacją Android Device Policy na samym urządzeniu. Po stronie serwera rozwiązania Enterprise Mobility Management (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 po stronie urządzenia. Pakiet AMAPI SDK służy do zarządzania instalacją i niezbędnymi aktualizacjami na urządzeniu. Aplikacja Android Device Policy przejmuje też proces uwierzytelniania użytkownika, bezpośrednio obsługując uwierzytelnianie użytkownika i przekazując jego tożsamość do EMM. Jeśli z jakiegoś powodu Google nie może uwierzytelnić użytkownika, tworzone jest nowe konto zarządzanego Sklepu Google Play, które jest dodawane do urządzenia jako opcja rezerwowa.

Kluczowym elementem tego nowego procesu rejestracji jest zarządzanie dostępem urządzenia do usług Google. Domyślnie urządzenia zaczynają działać w stanie ograniczonym, a EMM odgrywa a kluczową rolę w umożliwianiu dostępu, gdy urządzenie jest zgodne z zasadami.

Integracja interfejsu API

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

Przewodnik po implementacji rejestracji

W tym przewodniku znajdziesz niezbędne kroki implementacji rejestracji. Obejmuje on przygotowanie środowiska, obsługę różnych metod rejestracji i zarządzanie cyklem życia urządzenia.

Przygotuj środowisko

Przed rozpoczęciem konfiguracji konta należy przygotować środowisko urządzenia. Przygotowanie to obejmuje zaktualizowanie Sklepu Play do najnowszej wersji i ciche zainstalowanie aplikacji Android Device Policy (com.google.android.apps.work.clouddpc) na urządzeniu. Instalacja aplikacji Android Device Policy jest niezbędna, ponieważ zawiera ona kluczowe komponenty procesu konfiguracji konta. EMM nie muszą ręcznie przygotowywać środowiska. Zamiast tego powinny używać EnvironmentClient, zgodnie z opisem w dokumentacji, i stosować się do podanych przykładów kodu.

Przykładowy kod

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

  • Użyj EnvironmentClientFactory , aby utworzyć instancję EnvironmentClient , i wywołaj 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 sprawdzenia prawidłowego działania środowiska. 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 przez DPC interfejsu AccountSetup API.

Proces rejestracji

EMM muszą zaprzestać używania users.generateAuthenticationToken() i users.insert() na wszystkich urządzeniach. Zamiast tego EMM muszą wywoływać interfejs API na urządzeniu, aby przeprowadzić uwierzytelnianie użytkownika. Nowy interfejs API zwróci do DPC 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 użycie tokenów rejestracji, które muszą być przekazywane do interfejsu Authentication API. EMM określają, kiedy i jak utworzyć token, który może być częścią istniejącego ładunku rejestracji (np. kodu QR lub konfiguracji Zero-touch).

Wyjątek dotyczący istniejących tokenów rejestracji

Niektórzy klienci używają tokenów rejestracji z długimi datami ważności do przeprowadzania powtarzających się rejestracji. Aby nie przerywać tych istniejących procesów, wszystkie tokeny utworzone PRZED włączeniem wymagania „Uwierzytelnij się za pomocą Google” są zwolnione z nowych monitów logowania. Te starsze tokeny będą nadal działać tak jak wcześniej, umożliwiając użytkownikom rejestrowanie urządzeń bez przechodzenia przez proces uwierzytelniania Google. Jednak wszystkie tokeny utworzone PO włączeniu wymagania uwierzytelniania Google będą podlegać nowym regułom uwierzytelniania. Oznacza to, że urządzenia korzystające z tych nowszych tokenów będą wymagać od użytkowników uwierzytelnienia zgodnie z ustawieniami wybranymi przez administratora IT.

Google zaleca tworzenie tokena na żądanie i zastąpienie istniejącego interfejsu API dla kont zarządzanego Sklepu 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ład integracji 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ład integracji DPC z nowymi interfejsami API dla urządzeń użytkownika

Ulepszony proces rejestracji niestandardowego 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 do Google Play, jest początkowo ograniczony.

Ten domyślny stan „wyłączony” i późniejsze wymaganie, aby EMM oznaczył urządzenie jako zgodne z zasadami (np. przez wywołanie Devices.SetState), mają zastosowanie w tych warunkach:

  1. Organizacja potwierdziła w Google własność domeny.
  2. Administrator IT włączył w konsoli administracyjnej Google zarządzanie urządzeniami mobilnymi z Androidem przez firmy zewnętrzne w przypadku konkretnej jednostki organizacyjnej użytkownika.
  1. Utwórz token rejestracji: EMM tworzy token rejestracji za pomocą interfejsu Play EMM API.
  2. Przygotuj środowisko: niestandardowy DPC używa procesu przygotowania środowiska aby sprawdzić, czy urządzenie jest gotowe do rejestracji.
  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 aktywność uwierzytelniania Google: w razie potrzeby niestandardowy DPC wywołuje interfejs launchAuthenticationActivity API w pakiecie AMAPI SDK, przekazując AccountSetupAttempt. Spowoduje to uruchomienie aktywności uwierzytelniania Google, która po pomyślnym uwierzytelnieniu przekieruje użytkownika do niestandardowego DPC. Użytkownik może też pominąć ten proces. W takim przypadku do urządzenia zostanie dodane konto zarządzanego Sklepu Google Play. Tę opcję można skonfigurować za pomocą googleAuthenticationOptions.
  5. Zakończ rejestrację: pakiet AMAPI SDK powiadamia niestandardowy DPC o wyniku rejestracji.
  6. Włącz usługi Google: gdy niestandardowy DPC 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 niezbędne: to wywołanie interfejsu API oznacza, że urządzenie jest zgodne z zasadami.
  • Konsekwencje niewywołania: bez tego wywołania Devices.setState(setStateRequest) konto pozostanie w stanie „wyłączone”. Użytkownik nie będzie mógł uzyskać dostępu do Google Play (aby instalować lub 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 EMM odpowiada za utrzymywanie dostępu urządzenia do usług Google na podstawie jego stanu zgodności z zasadami.

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

Jeśli dostęp urządzenia do usług Google zostanie zablokowany, Usługi Google Play (GMSCore) wyślą intencję z działaniem: com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT. Może się tak zdarzyć z kilku powodów:

  • Po wstępnej rejestracji urządzenia EMM nigdy nie wywołał `Devices.setState("enabled")`.
  • Urządzenie nie jest już zgodne z zasadami EMM, a EMM nie włączył go ponownie.
  • EMM wyraźnie ustawił stan urządzenia na „wyłączony”, wywołując `Devices.setState()` z parametrem `accountState` ustawionym na „disabled”. Może to wynikać z obaw o bezpieczeństwo, działań administracyjnych lub innych przyczyn.

Ta intencja zawiera kod stanu, np. "ThirdPartyDeviceManagementRequired".

Niestandardowe DPC MUSZĄ zaimplementować BroadcastReceiver, aby nasłuchiwać tej intencji BAD_DEVICE_MANAGEMENT.

Po otrzymaniu tego rozgłoszenia DPC powinien:

  1. Ponownie ocenić zgodność: sprawdź, czy urządzenie spełnia wszystkie zasady ustawione przez EMM.
  2. Podjąć działanie:
    • Jeśli urządzenie jest zgodne z zasadami: DPC powinien powiadomić serwer EMM. Serwer EMM powinien następnie wywołać 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 nie jest zgodne z zasadami: gdy problemy zostaną rozwiązane, a urządzenie będzie zgodne z zasadami, EMM powinien wywołać Devices.setState().

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

Ważne informacje dotyczące przejęcia firmy

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

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

Konfiguracja konta – przykładowy kod

  1. Aby rozpocząć próbę konfiguracji konta, wywołująca aplikacja może użyć AccountSetupClient i wywołać metodę startAccountSetup() lub startAccountSetupFuture(). Przykład implementacji znajdziesz w tym przykładzie kodu:

    // 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 AccountSetupListener interfejs i podaj implementację sposobu obsługi otrzymywanych aktualizacji stanu.

  3. Rozszerz 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 rozszerzoną NotificationReceiverService klasę do pliku AndroidManifest.xml i sprawdź, czy jest eksportowana.

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

    Jeśli Twoja aplikacja jest przeznaczona na pakiet SDK w wersji 30 lub nowszej, w pliku AndroidManifest.xml potrzebny jest element queries, aby określić, że będzie ona wchodzić w interakcje z ADP.

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

Wskazówki dotyczące testowania

W tej sekcji znajdziesz zestaw wytycznych i sprawdzonych metod testowania implementacji.

Testowanie PrepareEnvironment

  1. Pobierz bieżący stan urządzenia: 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 prepareEnvironment API w pakiecie AMAPI SDK, przekazując prawidłowe żądanie.

  3. Poczekaj na wynik PrepareEnvironment: niestandardowy DPC czeka na zakończenie prepareEnvironment.

  4. Potwierdź, że PrepareEnvironment zakończyło się pomyślnie: po zakończeniu EMM ponownie uruchamia

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

    Tym razem wersja aplikacji Android Device Policy powinna być wyższa niż w kroku 1.

Testowanie uwierzytelniania konta Google

  1. Utwórz testową firmę: EMM tworzy testową domenę Google powiązaną z testowym EMM za pomocą enterprises.generateSignupUrl.
  2. Włącz uwierzytelnianie Google: EMM włącza uwierzytelnianie Google w przypadku testowej firmy, postępując zgodnie z tymi instrukcjami w konsoli administracyjnej Google.
  3. Utwórz token rejestracji: 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ść: pakiet AMAPI SDK powiadamia niestandardowy DPC, że należy uruchomić aktywność, aby uwierzytelnić użytkownika.
  6. Uwierzytelnij użytkownika: niestandardowy DPC wywołuje launchAuthenticationActivity aby rozpocząć aktywność. Użytkownik uwierzytelnia się za pomocą zarządzanego konta Google (części firmy utworzonej w kroku 1).
  7. Zakończ rejestrację: pakiet AMAPI SDK powiadamia niestandardowy DPC o wyniku rejestracji.

Testowanie pomijania uwierzytelniania Google

Użyjemy opisanej wcześniej konfiguracji.

Tym razem w kroku 7 użytkownik naciśnie Pomiń zamiast uwierzytelniać się za pomocą konta Google. Rejestracja zakończy się pomyślnie, a na urządzeniu będzie konto usługi (czyli AuthenticationType będzie mieć wartość Anonymous).

Testowanie urządzeń bez użytkownika

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

  1. Utwórz testową firmę: może to być ta sama firma, która została utworzona wcześniej.
  2. Utwórz token rejestracji: 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. Zakończ rejestrację: pakiet AMAPI SDK powiadamia niestandardowy DPC o wyniku rejestracji.