Реализовать учетные записи пользователей

Для регистрации корпоративных устройств Android существует два основных типа учётных записей пользователей: управляемые учётные записи Google Play и управляемые учётные записи Google. Управляемые учётные записи Google Play привязаны к устройству, то есть не привязаны к учётной записи Google конкретного пользователя. В отличие от них, управляемые учётные записи Google привязаны к корпоративной учётной записи Google пользователя, что улучшает пользовательский опыт, позволяя пользователю оставаться в системе на своих устройствах.

Раньше стандартом были управляемые аккаунты Google Play. Однако теперь Google рекомендует всем новым разработчикам использовать улучшенный процесс регистрации, который по умолчанию предполагает создание управляемых аккаунтов Google.

Хотя в конце документа для контекста приведены рекомендации по старой реализации, все новые разработки должны следовать новому процессу регистрации, подробно описанному здесь.

Обзор

Улучшенный процесс регистрации устройств упрощает настройку устройств за счёт использования нескольких новых компонентов и изменения способа реализации настраиваемых контроллеров политики устройств (DPC). Этот новый подход требует интеграции настраиваемых решений DPC с SDK Android Management API (AMAPI) и Android Device Policy для выполнения функций подготовки устройств и регистрации пользователей.

AMAPI SDK предоставляет необходимые API для взаимодействия с политикой Android Device Policy на самом устройстве. На стороне сервера решения для управления мобильными устройствами предприятия (EMM) будут использовать API Play EMM для генерации токенов регистрации, необходимых для инициирования процесса регистрации устройства.

Приложение Android Device Policy теперь играет центральную роль в обработке операций на стороне устройства. AMAPI SDK используется для управления его установкой и необходимыми обновлениями на устройстве. Android Device Policy также берет на себя процесс аутентификации пользователя, выполняя её напрямую и предоставляя его идентификационные данные в EMM. Если Google по какой-либо причине не может аутентифицировать пользователя, создаётся новая управляемая учётная запись Google Play, которая добавляется на устройство в качестве резервной.

API-интеграция

Перед началом работы убедитесь, что вы используете последнюю версию клиента Play EMM API и AMAPI SDK.

Руководство по внедрению регистрации

В этом руководстве представлены необходимые шаги для реализации регистрации. Оно охватывает подготовку среды, использование различных методов регистрации и управление жизненным циклом устройства.

Подготовить среду

Перед настройкой учётной записи необходимо подготовить среду устройства. Эта подготовка включает в себя обновление Play Store до последней версии и автоматическую установку Android Device Policy ( com.google.android.apps.work.clouddpc ) на устройство. Установка Android Device Policy крайне важна, поскольку она содержит критически важные компоненты процесса настройки учётной записи. EMM-специалистам не нужно вручную подготавливать среду. Вместо этого следует использовать EnvironmentClient , как описано по адресу [ссылка отсутствует], и следовать предоставленным примерам кода.

Пример кода

Прежде чем использовать API AccountSetup для добавления рабочей учетной записи на устройство, DPC должен сначала убедиться, что среда устройства готова.

  • Используйте EnvironmentClientFactory для создания экземпляра EnvironmentClient и вызова prepareEnvironment или 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]

Эта операция может занять несколько секунд или минут, поскольку приложения могут быть установлены или обновлены для проверки корректности работы. Google рекомендует запускать этот процесс как можно раньше в фоновом режиме и отображать соответствующий пользовательский интерфейс, пока пользователь ждёт. После завершения операции устройство будет готово к использованию API AccountSetup DPC.

Поток регистрации

EMM-системам необходимо прекратить использование users.generateAuthenticationToken() и users.insert() для всех устройств. Вместо этого EMM-системам необходимо вызывать API на устройстве для аутентификации конечного пользователя. Новый API будет возвращать userId и email в DPC. Если Google не сможет аутентифицировать пользователя, будет создан и добавлен на устройство управляемый аккаунт Google Play. В этом случае Google вернет userId этого аккаунта.

Google теперь использует токены регистрации, которые необходимо передать в API аутентификации. EMM определяют, когда и как создавать токен, и он может быть частью существующей полезной нагрузки регистрации (например, QR-кода или конфигурации Zero-touch).

Однако Google рекомендует создавать токен по требованию и заменять существующий API для управляемых аккаунтов Google Play новым API, чтобы минимизировать изменения.

Типичная интеграция DPC с предыдущими API
Рисунок 1. Типичная интеграция DPC с предыдущими API
Пример интеграции DPC с новыми API для беспользовательских устройств
Рисунок 2. Пример интеграции DPC с новыми API для беспользовательских устройств
Пример интеграции DPC с новыми API для пользовательских устройств
Рисунок 3. Пример интеграции DPC с новыми API для пользовательских устройств

Улучшенный процесс регистрации в индивидуальном DPC включает следующие этапы:

  1. Создание токена регистрации: EMM создает токен регистрации с помощью API Play EMM.
  2. Подготовка среды: пользовательский DPC использует поток подготовки среды для проверки готовности устройства к регистрации.
  3. Инициирование регистрации: пользовательский DPC вызывает API startAccountSetup в AMAPI SDK, передавая токен регистрации. Примечание: DPC должен быть владельцем устройства или профиля перед вызовом этого API.
  4. Запуск активности аутентификации Google: при необходимости пользовательский DPC вызывает API launchAuthenticationActivity в AMAPI SDK, передавая AccountSetupAttempt . Это запускает активность аутентификации Google, возвращая пользователя в пользовательский DPC после успешной аутентификации. Пользователь также может пропустить этот процесс. В этом случае на устройство будет добавлен управляемый аккаунт Google Play. Эту опцию можно настроить с помощью googleAuthenticationOptions .
  5. Завершение регистрации: AMAPI SDK уведомляет пользовательский DPC о результате регистрации.
  6. Включение сервисов Google: после того, как устройство пользователя с управляемым аккаунтом Google будет соответствовать корпоративным политикам, EMM должен вызвать метод Devices.setState() . Это действие включает доступ к сервисам Google для аккаунта на устройстве. Без этого вызова Play Маркет и другие сервисы Google не будут работать.

Настройка учетной записи — пример кода

  1. Чтобы инициировать попытку настройки учётной записи, вызывающее приложение может использовать AccountSetupClient и вызвать метод startAccountSetup() или startAccountSetupFuture() . Пример реализации см. в следующем коде:

    // 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. Реализуйте интерфейс AccountSetupListener и предоставьте реализацию обработки полученных обновлений статуса.

  3. Расширьте NotificationReceiverService и предоставьте экземпляр AccountSetupListener , созданный на шаге 2, путем переопределения 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.

            }
            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. Добавьте расширенный класс NotificationReceiverService в ваш AndroidManifest.xml и убедитесь, что он экспортирован.

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

    Если ваше приложение ориентировано на SDK 30 или более позднюю версию, то в AndroidManifest.xml необходим элемент requests, чтобы указать, что приложение будет взаимодействовать с ADP.

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

Руководство по тестированию

В этом разделе представлен набор рекомендаций и передовых методов тестирования вашей реализации.

PrepareEnvironment

  1. Получить текущее состояние устройства: EMM работает

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

    Чтобы получить версию политики Android Device Policy, установленную на устройстве. Если политика Android Device Policy не установлена, ожидается пустой вывод.

  2. Интеграция PrepareEnvironment: пользовательский DPC вызывает prepareEnvironment API в AMAPI SDK, передавая правильный запрос.

  3. Ожидание результата PrepareEnvironment: пользовательский DPC ожидает завершения prepareEnvironment .

  4. Подтверждение успешного выполнения PrepareEnvironment: по завершении EMM запускается снова.

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

    На этот раз версия Android Device Policy должна быть выше, чем на шаге 1.

Тестовая аутентификация аккаунта Google

  1. Создание тестового предприятия: EMM создает тестовый домен Google Enterprise, связанный с тестовым EMM, с помощью enterprises.generateSignupUrl .
  2. Включить аутентификацию Google: EMM включает аутентификацию Google для тестового предприятия, следуя этим инструкциям в консоли администратора Google.
  3. Создание токена регистрации: EMM создает токен регистрации с помощью API Play EMM с типом userDevice .
  4. Инициирование регистрации: пользовательский DPC вызывает API startAccountSetup в AMAPI SDK, передавая токен регистрации.
  5. Требуется запустить действие: AMAPI SDK уведомляет пользовательский DPC о том, что необходимо запустить действие для аутентификации пользователя.
  6. Аутентификация пользователя: пользовательский DPC вызывает launchAuthenticationActivity для запуска активности. Пользователь аутентифицируется с помощью управляемой учётной записи Google (часть предприятия, созданная на шаге 1).
  7. Завершение регистрации: AMAPI SDK уведомляет пользовательский DPC о результате регистрации.

Тест пропуска аутентификации Google

Мы будем использовать ранее описанную установку.

На этот раз на шаге 7 пользователь нажимает «Пропустить» вместо аутентификации с помощью учётной записи Google. Регистрация завершается успешно, на устройстве появляется учётная запись сервиса (т.е. AuthenticationType — «Анонимный»).

Тестирование беспользовательских устройств

Улучшенный процесс регистрации настраиваемого DPC использует следующие шаги при отключенной аутентификации Google:

  1. Создайте тестовое предприятие: это может быть то же предприятие, которое было создано ранее.
  2. Создание токена регистрации: EMM создает токен регистрации с помощью API Play EMM с типом userlessDevice .
  3. Инициирование регистрации: пользовательский DPC вызывает API startAccountSetup в AMAPI SDK, передавая токен регистрации.
  4. Завершение регистрации: AMAPI SDK уведомляет пользовательский DPC о результате регистрации.