Registrar e provisionar um dispositivo

Provisionamento é o processo de configurar um dispositivo para ser gerenciado usando policies por um enterprise. Durante o processo, um dispositivo instala o Android Device Policy, que é usado para receber e aplicar policies. Se o provisionamento for bem-sucedido, a API vai criar um objeto devices, vinculando o dispositivo a uma empresa.

A API Android Management usa tokens de inscrição para acionar o processo de provisionamento. O token de inscrição e o método de provisionamento usados estabelecem a propriedade de um dispositivo (pessoal ou da empresa) e o modo de gerenciamento (perfil de trabalho ou dispositivo totalmente gerenciado).

Um sistema de cotas controla quantos dispositivos cada projeto pode gerenciar. Você precisa solicitar a cota inicial de dispositivos antes de provisionar o primeiro.

Dispositivos pessoais

Android 5.1 ou mais recente

Os dispositivos dos funcionários podem ser configurados com um perfil de trabalho. Um perfil de trabalho oferece um espaço independente para apps e dados de trabalho, separado dos apps e dados pessoais. A maioria dos apps, dados e outros controles de gerenciamento policies se aplica apenas ao perfil de trabalho, enquanto os apps e dados pessoais do funcionário permanecem privados.

Para configurar um perfil de trabalho em um dispositivo pessoal, crie um token de registro (verifique se allowPersonalUsage está definido como PERSONAL_USAGE_ALLOWED) e use um dos seguintes métodos de provisionamento:

Dispositivos da empresa para uso profissional e pessoal

Android 8 ou mais recente

Configurar um dispositivo da empresa com um perfil de trabalho permite que ele seja usado para fins profissionais e pessoais. Em dispositivos corporativos com perfis de trabalho:

Para configurar um dispositivo da empresa com um perfil de trabalho, crie um token de registro (verifique se allowPersonalUsage está definido como PERSONAL_USAGE_ALLOWED) e use um dos seguintes métodos de provisionamento:

Dispositivos da empresa para uso exclusivo no trabalho

Android 5.1 ou mais recente

O gerenciamento total de dispositivos é adequado para aparelhos da empresa destinados exclusivamente a fins profissionais. As empresas podem gerenciar todos os apps no dispositivo e aplicar todo o espectro de políticas e comandos da API Android Management.

Também é possível bloquear um dispositivo por política para usar um único app ou um pequeno conjunto de apps para uma finalidade ou caso de uso específico. Esse subconjunto de dispositivos totalmente gerenciados é chamado de dispositivos dedicados. Os tokens de inscrição para esses dispositivos precisam ter allowPersonalUsage definido como PERSONAL_USAGE_DISALLOWED_USERLESS.

Para configurar o gerenciamento completo em um dispositivo da empresa, crie um token de registro, garantindo que allowPersonalUsage esteja definido como PERSONAL_USAGE_DISALLOWED ou PERSONAL_USAGE_DISALLOWED_USERLESS, e use um dos seguintes métodos de provisionamento.

As políticas podem afetar a geração da interface durante o provisionamento do dispositivo. Essas políticas são:

Se você quiser que as etapas de senha sejam mostradas junto com a instalação de apps de trabalho e os cards de registro do dispositivo durante o provisionamento, sugerimos atualizar suas políticas para atrasar o início da geração da interface mantendo o dispositivo em um estado de quarentena, que ocorre se o dispositivo for registrado sem uma política associada, até que a política final selecionada para a configuração do dispositivo seja especificada com itens relevantes para suas necessidades de configuração. Depois que o provisionamento do dispositivo for concluído, você poderá mudar a política conforme necessário.

Criar um token de inscrição

Visão geral do Gerenciamento do Android.
Figura 1. Crie um token que registre e aplique "policy1" aos dispositivos. Após 1.800 segundos (30 minutos), o token expira.

É preciso ter um token de inscrição para cada dispositivo que você quer registrar. É possível usar o mesmo token para vários dispositivos. Para solicitar um token de inscrição, chame enterprises.enrollmentTokens.create. Por padrão, os tokens de inscrição expiram após uma hora,mas é possível especificar um tempo de expiração personalizado (duration) de até aproximadamente 10.000 anos.

Uma solicitação bem-sucedida retorna um objeto enrollmentToken que contém um enrollmentTokenId e um qrcode que os administradores de TI e os usuários finais podem usar para provisionar dispositivos.

Especificar uma política

Você também pode especificar um policyName na solicitação para aplicar uma política ao mesmo tempo em que um dispositivo é registrado. Se você não especificar um policyName, consulte Registrar um dispositivo sem uma política.

Especificar uso pessoal

allowPersonalUsage determina se um perfil de trabalho pode ser adicionado ao dispositivo durante o provisionamento. Defina como PERSONAL_USAGE_ALLOWED para permitir que um usuário crie um perfil de trabalho (necessário para dispositivos pessoais, opcional para dispositivos corporativos).

Aplicar a autenticação do Google no registro

Os EMMs podem exigir o login na Conta do Google durante o registro do dispositivo definindo os valores apropriados no token de registro ou de login. Essa configuração determina se o botão "Pular" fica oculto na tela de login do Google. Quando definidas, essas opções substituem a política googleAuthenticationSettings de toda a empresa.

Opções de configuração

É possível controlar o comportamento de autenticação usando o objeto googleAuthenticationOptions em um EnrollmentToken ou um SigninDetail.

Campo Descrição Valores
authenticationRequirement Especifica se o usuário precisa se autenticar com o Google durante a inscrição. AUTHENTICATION_REQUIREMENT_UNSPECIFIED::volta para as configurações padrão da empresa.
OPCIONAL:o usuário vê a tela de login do Google, mas pode pular essa etapa.
OBRIGATÓRIO:o usuário não pode pular o login. O botão "Pular" fica oculto.
requiredAccountEmail O e-mail específico da Conta do Google gerenciada que o usuário precisa usar.
Observação:authenticationRequirement precisa ser definido como REQUIRED se este campo for usado.		 String (por exemplo, "user@enterprise.com")

Exemplos de payload JSON

Desativar o botão "Pular"

Para ocultar o botão "Pular" e forçar o usuário a fazer login com uma conta corporativa válida, defina o requisito de autenticação como REQUIRED.

{
  ...
  "googleAuthenticationOptions": {
    "authenticationRequirement": "REQUIRED"
  }
}

Exigir um e-mail de conta específico

Para forçar o usuário a fazer login com uma conta designada, defina a string requiredAccountEmail. A solicitação de criação de token vai falhar com um erro INVALID_ARGUMENT se o campo de requisito não estiver definido como REQUIRED.

{
...
  "googleAuthenticationOptions": {
    "authenticationRequirement": "REQUIRED",
    "requiredAccountEmail": "user@enterprise.com"
  }
}

Sobre os QR codes

Os QR codes funcionam como um método eficiente de provisionamento de dispositivos para empresas que mantêm muitas políticas diferentes. O QR code retornado de enterprises.enrollmentTokens.create é composto por uma carga útil de pares de chave-valor que contém um token de inscrição e todas as informações necessárias para que a Política de dispositivo Android provisione um dispositivo.

Exemplo de pacote de QR code

O pacote inclui o local de download do Android Device Policy e um token de registro.

{
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
    "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup",
    "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
        "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "{enrollment-token}"
    }
}

Você pode usar o QR code retornado de enterprises.enrollmentTokens.create diretamente ou personalizá-lo. Para uma lista completa de propriedades que podem ser incluídas em um pacote de QR code, consulte Criar um QR code.

Para converter a string qrcode em um QR code legível, use um gerador de QR code, como o ZXing.

Métodos de provisionamento

Nesta seção, descrevemos diferentes métodos para provisionar um dispositivo.

Adicionar perfil de trabalho em "Configurações"

Android 5.1 ou mais recente

Para configurar um perfil de trabalho no dispositivo, o usuário pode:

  1. Acesse Configurações > Google > Configurar e restaurar.
  2. Toque em Configurar seu perfil de trabalho.

Essas etapas iniciam um assistente de configuração que faz o download do Android Device Policy no dispositivo. Em seguida, o usuário vai precisar ler um QR code ou inserir manualmente um token de registro para concluir a configuração do perfil de trabalho.

Baixar o Android Device Policy

Android 5.1 ou mais recente

Para configurar um perfil de trabalho no dispositivo, o usuário pode baixar a Política de dispositivos Android na Google Play Store. Depois que o app for instalado, o usuário vai precisar ler um QR code ou inserir manualmente um token de inscrição para concluir a configuração do perfil de trabalho.

Android 5.1 ou mais recente

Usando o token de inscrição retornado de enrollmentTokens.create ou o signinEnrollmentToken da empresa, gere um URL com o seguinte formato:

https://enterprise.google.com/android/enroll?et=<enrollmentToken>

Você pode fornecer esse URL aos administradores de TI, que podem disponibilizá-lo aos usuários finais. Quando um usuário final abre o link no dispositivo, ele é guiado pela configuração do perfil de trabalho.

URL de login

Com esse método, os usuários são direcionados a uma página para inserir as informações adicionais necessárias para concluir o provisionamento. Com base nas informações inseridas pelo usuário, você pode calcular a política adequada antes de prosseguir com o provisionamento do dispositivo. Exemplo:

  1. Especifique o URL de login em enterprises.signInDetails[]. Defina allowPersonalUsage como PERSONAL_USAGE_ALLOWED se quiser permitir que um usuário crie um perfil de trabalho (necessário para dispositivos pessoais, opcional para dispositivos corporativos).

    Adicione o signinEnrollmentToken resultante como um extra de provisionamento a um QR code, um payload NFC ou uma configuração sem toque. Outra opção é fornecer o signinEnrollmentToken diretamente aos usuários.

  2. Escolha uma opção:

    1. Dispositivos da empresa:depois de ligar um dispositivo novo ou redefinido para a configuração de fábrica, passe o signinEnrollmentToken para o dispositivo (por QR code, toque NFC etc.) ou peça para os usuários inserirem o token manualmente. O dispositivo vai abrir o URL de login especificado na etapa 1.
    2. Dispositivos pessoais:peça aos usuários para adicionar um perfil de trabalho em "Configurações". Quando solicitado, o usuário lê um QR code com o signinEnrollmentToken ou insere o token manualmente. O dispositivo vai abrir o URL de login especificado na etapa 1.
    3. Dispositivos pessoais:forneça aos usuários um link de token de registro, em que o token de registro é o signinEnrollmentToken. O dispositivo vai abrir o URL de login especificado na etapa 1.

  3. Verifique se o Google já autenticou o usuário. Receba as informações de provisionamento do dispositivo (durante o registro) usando o parâmetro GET provisioningInfo e verifique se há um valor para o campo authenticatedUserEmail. Se houver um valor nesse campo, o usuário já foi autenticado pelo Google, e você pode usar essa identidade sem mais autenticação.

  4. Se o Google ainda não tiver autenticado o usuário, o URL de login vai pedir que ele insira as credenciais. Com base na identidade, você pode determinar a política adequada e receber as informações de provisionamento do dispositivo (durante o registro) usando o parâmetro GET provisioningInfo.

  5. Chame enrollmentTokens.create, especificando o policyId adequado com base nas credenciais do usuário.

  6. Retorne o token de inscrição gerado na etapa 5 usando o redirecionamento de URL, no formato https://enterprise.google.com/android/enroll?et=<token>.

Aplicar a autenticação do Google com o fluxo de URL de login

Ao usar SigninDetail para fluxos de login de terceiros (via enterprises.create ou enterprises.patch), é possível transmitir googleAuthenticationOptions. Isso impõe regras antes que o usuário seja redirecionado para o URL de login de terceiros.

Quando um EnrollmentToken é criado no final de um fluxo de URL de login, os requisitos de autenticação interagem com o SigninDetail inicial:

  • Se o usuário ignorou o login do Google porque ele não era exigido por SigninDetail, mas o EnrollmentToken resultante tem o requisito definido como REQUIRED, o usuário vai receber um erro e precisará fazer login.
  • Se requiredAccountEmail estiver definido no token e o usuário tiver feito login com um endereço diferente pertencente à empresa, ele vai receber um erro de "Conta errada" e precisará fazer login novamente com o e-mail correto.

Método de QR code

Android 7.0 ou mais recente

Para provisionar um dispositivo da empresa, gere um QR code e mostre-o no console do EMM:

  1. Em um dispositivo novo ou redefinido para a configuração original, o usuário (normalmente um administrador de TI) toca na tela seis vezes no mesmo lugar. Dessa forma, o dispositivo vai acionar a leitura de QR code.
  2. O usuário lê o QR code exibido no console de gerenciamento (ou aplicativo semelhante) para registrar e provisionar o dispositivo.

Método NFC

Android 6.0 ou mais recente

Esse método exige que você crie um app programador de NFC que contenha o token de inscrição, as políticas iniciais e a configuração, as configurações e todos os outros detalhes de provisionamento necessários para que o cliente provisione um dispositivo totalmente gerenciado ou dedicado. Quando você ou seu cliente instala o app programador de NFC em um dispositivo Android, ele se torna o dispositivo programador.

As orientações detalhadas sobre como oferecer suporte ao método NFC estão disponíveis na documentação para desenvolvedores da API EMM do Play. O site também inclui código de amostra dos parâmetros padrão enviados a um dispositivo em uma conexão NFC ao encostá-los. Para instalar o Android Device Policy, defina o local de download do pacote de administrador do dispositivo como:

https://play.google.com/managed/downloadManagingApp?identifier=setup

Método de identificador de DPC

Se não for possível adicionar a Política de dispositivos Android usando QR code ou NFC, um usuário ou administrador de TI pode seguir estas etapas para provisionar um dispositivo da empresa:

  1. Siga o assistente de configuração em um dispositivo novo ou redefinido para a configuração original.
  2. Digite os detalhes de login do Wi-Fi para conectar o dispositivo à Internet.
  3. Quando for solicitado que você faça login, digite afw#setup, que baixa o Android Device Policy.
  4. Leia um QR code ou insira manualmente um token de registro para provisionar o dispositivo.

Registro sem toque

Android 8.0 ou mais recente (Pixel 7.1 ou mais recente)

Os dispositivos comprados de um revendedor autorizado de registro sem toque são qualificados para o registro sem toque, um método simplificado para pré-configurar dispositivos e provisioná-los automaticamente na primeira inicialização.

As organizações podem criar configurações com detalhes de provisionamento para dispositivos de registro sem toque pelo portal de registro sem toque ou usando o console de EMM (consulte a API de registro sem toque para clientes). Na primeira inicialização, um dispositivo sem toque verifica se uma configuração foi atribuída a ele. Nesse caso, o dispositivo faz o download do Android Device Policy, que conclui a configuração do dispositivo usando os extras de provisionamento especificados na configuração atribuída.

Se os clientes usarem o portal de registro sem toque, eles precisarão selecionar a Política de dispositivos Android como o DPC de EMM para cada configuração criada. Instruções detalhadas sobre como usar o portal, incluindo como criar e atribuir configurações a dispositivos, estão disponíveis na Central de Ajuda do Android Enterprise.

Se você preferir que seus clientes definam e atribuam configurações diretamente no console de EMM, faça a integração com a API de registro sem toque para clientes. Ao criar uma configuração, especifique os extras de provisionamento no campo dpcExtras. O snippet JSON a seguir mostra um exemplo básico do que incluir em dpcExtras, com um token de login adicionado.

{
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME":"com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
   "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM":"I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
   "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{
      "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN":"{Sign In URL token}"
   }
}

Abrir um app durante a configuração

setupaction
Figura 2. Use setupActions para iniciar um app durante a configuração.

Em policies, você pode especificar um app para o Android Device Policy iniciar durante a configuração do dispositivo ou do perfil de trabalho. Por exemplo, você pode iniciar um app de VPN para que os usuários configurem as definições de VPN como parte do processo de configuração. O app precisa retornar RESULT_OK para sinalizar a conclusão e permitir que o Android Device Policy conclua o provisionamento do dispositivo ou do perfil de trabalho. Para abrir um app durante a configuração:

Verifique se o installType do app é REQUIRED_FOR_SETUP. Se o app não puder ser instalado ou iniciado no dispositivo, o provisionamento vai falhar.

{
   "applications":[
      {
         "packageName":"com.my.vpnapp.",
         "installType":"REQUIRED_FOR_SETUP"
      }
   ]
}

Adicione o nome do pacote do app a setupActions. Use title e description para especificar instruções voltadas ao usuário.

{
   "setupActions":[
      {
         "title":{
            "defaultMessage":"Configure VPN"
         },
         "description":{
            "defaultMessage":"Enable your VPN client to access corporate resources."
         },
         "launchApp":{
            "packageName":"com.my.vpnapp."
         }
      }
   ]
}

Para distinguir que um app foi iniciado em launchApp, a atividade que é iniciada primeiro como parte do app contém o extra de intent booleano com.google.android.apps.work.clouddpc.EXTRA_LAUNCHED_AS_SETUP_ACTION (definido como true). Esse extra permite personalizar o app com base em se ele foi iniciado em setupActions ou por um usuário.

Depois que o app retornar RESULT_OK, o Android Device Policy vai concluir as etapas restantes necessárias para provisionar o dispositivo ou o perfil de trabalho.

Cancelar a inscrição durante a configuração

O app iniciado como SetupAction pode cancelar a inscrição retornando RESULT_FIRST_USER.

O cancelamento do registro redefine um dispositivo da empresa ou exclui o perfil de trabalho em um dispositivo pessoal.

Observação: o cancelamento da inscrição aciona a ação sem uma caixa de diálogo de confirmação do usuário. É responsabilidade do app mostrar uma caixa de diálogo de erro adequada ao usuário antes de retornar RESULT_FIRST_USER.

Aplicar uma política a dispositivos recém-inscritos

O método usado para aplicar políticas a dispositivos recém-inscritos depende de você e dos requisitos dos seus clientes. Confira as diferentes abordagens que você pode usar:

  • (Recomendado) Ao criar um token de inscrição, você pode especificar o nome da política (policyName) que será vinculada inicialmente ao dispositivo. Quando você registra um dispositivo com o token, a política é aplicada automaticamente.

  • Definir uma política como padrão para uma empresa. Se nenhum nome de política for especificado no token de inscrição e houver uma política com o nome enterprises/<enterprise_id>/policies/default, cada novo dispositivo será vinculado automaticamente à política padrão no momento da inscrição.

  • Inscreva-se em um tópico do Cloud Pub/Sub para receber notificações sobre dispositivos recém-inscritos. Em resposta a uma notificação de ENROLLMENT, chame enterprises.devices.patch para vincular o dispositivo a uma política.

Registrar um dispositivo sem uma política

Se um dispositivo for registrado sem uma política válida, ele será colocado em quarentena. Os dispositivos em quarentena são bloqueados de todas as funções até serem vinculados a uma política.

Se um dispositivo não for vinculado a uma política em cinco minutos, a inscrição dele vai falhar, e ele será redefinido para a configuração original. O estado de quarentena do dispositivo oferece a oportunidade de implementar verificações de licenciamento ou outros processos de validação de registro como parte da sua solução.

Exemplo de fluxo de trabalho de verificação de licenciamento

  1. Um dispositivo é registrado sem uma política padrão ou específica.
  2. Verifique quantas licenças a empresa ainda tem.
  3. Se houver licenças disponíveis, use devices.patch para anexar uma política ao dispositivo e diminua a contagem de licenças. Se não houver licenças disponíveis, use devices.patch para desativar o dispositivo. Como alternativa, a API faz uma redefinição de fábrica em qualquer dispositivo que não esteja anexado a uma política em até cinco minutos após o registro.