Implementa cuentas de usuario

Existen dos tipos principales de identidades de usuario para las inscripciones de Android Enterprise: cuentas de Google Play administrado y Cuentas de Google administradas. Las cuentas de Google Play administrado se centran en el dispositivo, lo que significa que no están vinculadas a la identidad de Google de un usuario específico. En cambio, las Cuentas de Google administradas están vinculadas a la identidad corporativa de Google de un usuario, lo que mejora la experiencia del usuario, ya que lo mantiene conectado en sus dispositivos.

Las cuentas de Google Play administrado solían ser el estándar. Sin embargo, ahora Google recomienda que todos los desarrollos nuevos utilicen el flujo de inscripción mejorado, que, de forma predeterminada, crea Cuentas de Google administradas.

Si bien al final de este documento se proporciona orientación sobre la implementación anterior para brindar contexto, todo desarrollo nuevo debe seguir el nuevo flujo de inscripción que se detalla aquí.

Descripción general

El flujo de inscripción de dispositivos mejorado optimiza la configuración de dispositivos aprovechando varios componentes nuevos y cambiando la forma en que se implementan los controladores de política de dispositivos (DPC) personalizados. Este nuevo enfoque requiere que las soluciones de DPC personalizadas se integren con el SDK de la API de Android Management (AMAPI) y la Política de dispositivos Android para realizar funciones de preparación de dispositivos y de inscripción de usuarios.

El SDK de AMAPI proporciona las APIs necesarias para interactuar con la Política de dispositivos Android en el dispositivo. En el servidor, las soluciones de administración de movilidad empresarial (EMM) usarán la API de Play EMM para generar los tokens de inscripción necesarios para iniciar el proceso de inscripción del dispositivo.

La aplicación Device Policy de Android ahora desempeña un papel central en el control de las operaciones del dispositivo. El SDK de la AMAPI se usa para administrar su instalación y las actualizaciones necesarias en el dispositivo. Android Device Policy también se encarga del flujo de autenticación del usuario, ya que controla la autenticación del usuario directamente y proporciona la identidad del usuario al EMM. Si Google no puede autenticar al usuario por algún motivo, se crea una nueva cuenta de Google Play administrado y se agrega al dispositivo como alternativa.

Integración de APIs

Antes de comenzar, verifica que estés usando la versión más reciente del cliente de la API de Play EMM y del SDK de la AMAPI.

Guía de implementación de la inscripción

En esta guía, se proporcionan los pasos necesarios para implementar la inscripción. Abarca la preparación del entorno, el manejo de diferentes métodos de inscripción y la administración del ciclo de vida del dispositivo.

Prepara el entorno

Antes de iniciar la configuración de la cuenta, es necesario preparar el entorno del dispositivo. Esta preparación implica actualizar Play Store a su iteración más reciente e instalar de forma silenciosa la Política de dispositivos Android (com.google.android.apps.work.clouddpc) en el dispositivo. La instalación de Android Device Policy es fundamental, ya que contiene componentes críticos del proceso de configuración de la cuenta. Los EMM no necesitan preparar el entorno de forma manual. En su lugar, deben usar EnvironmentClient, tal como se documenta en y cumplir con los ejemplos de código proporcionados.

Código de muestra

Antes de poder usar la API de AccountSetup para agregar la cuenta de trabajo en el dispositivo, el DPC primero debe verificar que el entorno del dispositivo esté listo.

  • Usa EnvironmentClientFactory para crear una instancia de EnvironmentClient y llamar a prepareEnvironment o 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]

Esta operación puede tardar varios segundos o minutos, ya que es posible que se instalen o actualicen aplicaciones para verificar un entorno de trabajo adecuado. Google recomienda iniciar este proceso lo antes posible en segundo plano y mostrar la IU adecuada mientras el usuario espera. Cuando se completa la operación, el dispositivo está listo para que el DPC use la API de AccountSetup.

Flujo de inscripción

Los EMM deben dejar de usar users.generateAuthenticationToken() y users.insert() para todos los dispositivos. En cambio, los EMM deben llamar a la API en el dispositivo para realizar la autenticación del usuario final. La nueva API devolverá userId y email al DPC. Si Google no puede autenticar al usuario, se creará una Cuenta de Google administrada y se agregará al dispositivo. En este caso, Google devolverá el userId de esa cuenta.

Ahora Google introduce el uso de tokens de inscripción, que se deben pasar a la API de autenticación. Los EMM determinan cuándo y cómo crear el token, y este puede formar parte de una carga útil de inscripción existente (p.ej., un código QR o la Configuración sin intervención).

Sin embargo, Google recomienda crear el token a pedido y reemplazar la API existente para las cuentas de Google Play administrado por la nueva API para minimizar el cambio.

Integración típica del DPC con las APIs anteriores
Figura 1. Integración típica del DPC con APIs anteriores
Ejemplo de integración del DPC con las nuevas APIs para dispositivos sin usuarios
Figura 2: Ejemplo de integración del DPC con las nuevas APIs para dispositivos sin usuario
Ejemplo de integración del DPC con las nuevas APIs para dispositivos del usuario
Figura 3: Ejemplo de integración del DPC con las nuevas APIs para dispositivos del usuario

El flujo de inscripción personalizado mejorado del DPC incluye los siguientes pasos:

  1. Crea un token de inscripción: La EMM crea un token de inscripción con la API de Play EMM.
  2. Preparar el entorno: El DPC personalizado usa el flujo de trabajo Preparar el entorno para verificar que el dispositivo esté listo para la inscripción.
  3. Inicia la inscripción: El DPC personalizado invoca la API de startAccountSetup en el SDK de AMAPI y pasa el token de inscripción. Nota: El DPC debe ser el propietario del dispositivo o del perfil antes de llamar a esta API.
  4. Inicia la actividad de autenticación de Google: Si es necesario, el DPC personalizado invoca la API de launchAuthenticationActivity en el SDK de AMAPI y pasa AccountSetupAttempt. Esto inicia una actividad de autenticación de Google y devuelve al usuario al DPC personalizado tras una autenticación exitosa. El usuario también puede omitir este proceso. En este caso, se agregará una cuenta de Google Play administrado al dispositivo. Esta opción se puede configurar con googleAuthenticationOptions.
  5. Finalize Enrollment: El SDK de AMAPI notifica al DPC personalizado el resultado de la inscripción.
  6. Habilita los servicios de Google: Una vez que el dispositivo de un usuario con la Cuenta de Google administrada cumpla con las políticas empresariales, el EMM debe llamar a Devices.setState(). Esta acción habilita el acceso a los servicios de Google para la cuenta en el dispositivo. Sin esta llamada, Play Store y otros servicios de Google no funcionarán.

Configuración de la cuenta: código de muestra

  1. Para iniciar un intento de configuración de la cuenta, la app que realiza la llamada puede usar AccountSetupClient y llamar al método startAccountSetup() o startAccountSetupFuture(). Para ver un ejemplo de implementación, consulta el siguiente código de muestra:

    // 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. Implementa la interfaz AccountSetupListener y proporciona una implementación para controlar las actualizaciones de estado recibidas.

  3. Extiende NotificationReceiverService y proporciona la instancia AccountSetupListener creada en el paso 2 anulando 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. Agrega la clase NotificationReceiverService extendida a tu AndroidManifest.xml y verifica que se haya exportado.

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

    Si tu app se segmenta para el SDK 30 o versiones posteriores, se necesita un elemento queries en AndroidManifest.xml para especificar que interactuará con ADP.

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

Orientación para las pruebas

En esta sección, se proporciona un conjunto de lineamientos y prácticas recomendadas para probar tu implementación.

Prueba PrepareEnvironment

  1. Obtén el estado actual del dispositivo: El EMM ejecuta

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

    para obtener la versión de Android Device Policy presente en el dispositivo Si no se instala la Política de dispositivos Android, se espera un resultado vacío.

  2. Integra PrepareEnvironment: El DPC personalizado invoca la API de prepareEnvironment en el SDK de AMAPI y pasa la solicitud correcta.

  3. Espera el resultado de PrepareEnvironment: El DPC personalizado espera a que se complete prepareEnvironment.

  4. Confirma que PrepareEnvironment se ejecutó correctamente: Cuando se complete, el EMM se volverá a ejecutar.

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

    En esta ocasión, la versión de Android Device Policy debe ser superior a la del paso 1.

Cómo probar la autenticación de la Cuenta de Google

  1. Crea una empresa de prueba: El EMM crea una empresa de Google con un dominio de prueba vinculada a un EMM de prueba, con enterprises.generateSignupUrl.
  2. Habilita la autenticación de Google: El EMM habilita la autenticación de Google para la empresa de prueba siguiendo estas instrucciones en la Consola del administrador de Google.
  3. Crea un token de inscripción: La EMM crea un token de inscripción con la API de Play EMM con el tipo userDevice.
  4. Inicia la inscripción: El DPC personalizado invoca la API de startAccountSetup en el SDK de AMAPI y pasa el token de inscripción.
  5. Se requiere iniciar la actividad: El SDK de AMAPI notifica al DPC personalizado que se debe iniciar una actividad para autenticar al usuario.
  6. Autentica al usuario: El DPC personalizado invoca launchAuthenticationActivity para iniciar la actividad. El usuario se autentica con una Cuenta de Google administrada (parte de la empresa creada en el paso 1).
  7. Finalize Enrollment: El SDK de AMAPI notifica al DPC personalizado el resultado de la inscripción.

Prueba la omisión de la autenticación de Google

Usaremos la configuración descrita anteriormente.

Esta vez, en el paso 7, el usuario presiona Omitir en lugar de autenticarse con su Cuenta de Google. La inscripción se completa correctamente, con una cuenta de servicio en el dispositivo (es decir, AuthenticationType es anónimo).

Cómo probar dispositivos sin usuarios

El flujo de inscripción de DPC personalizado mejorado utiliza los siguientes pasos cuando la autenticación de Google está inhabilitada:

  1. Crea una empresa de prueba: Puede ser la misma empresa que creaste anteriormente.
  2. Crea un token de inscripción: La EMM crea un token de inscripción con la API de Play EMM con el tipo userlessDevice.
  3. Inicia la inscripción: El DPC personalizado invoca la API de startAccountSetup en el SDK de AMAPI y pasa el token de inscripción.
  4. Finalize Enrollment: El SDK de AMAPI notifica al DPC personalizado el resultado de la inscripción.