Métodos de provisionamento de dispositivos Android: guia para escolher a opção de implantação

Escolha o estado de gerenciamento antes do método de entrada

Duas decisões costumam ser tratadas como uma só. O estado de propriedade e gerenciamento define o limite de controle após a configuração; o método de entrada no provisionamento é apenas a via para chegar a esse estado compatível. Um código QR não significa, por si só, “dedicado”, e zero-touch não define a política que o dispositivo receberá. Consulte primeiro dispositivos dedicados versus totalmente gerenciados; as orientações do Android Enterprise para configuração de dispositivos, do Google, também observam que a compatibilidade dos métodos varia conforme o fornecedor de EMM.

Provisionamento, inscrição e preparação do lote são relacionados — mas não idênticos

A inscrição é a relação gerenciada entre um dispositivo e seu ambiente de gerenciamento. O provisionamento leva o dispositivo de uma condição inicial acordada ao estado inicial exigido. A preparação do lote aplica uma via aceita às unidades de produção, verifica os resultados, registra exceções e prepara a transferência. Portanto, um token de inscrição é uma entrada de alguns fluxos, e não automaticamente um método de provisionamento separado.

• Um perfil de trabalho em dispositivo pessoal normalmente é adicionado a um dispositivo já configurado, sem restauração de fábrica.
• Implantações com perfil de trabalho em dispositivo corporativo, totalmente gerenciadas e dedicadas normalmente são estabelecidas durante o assistente de configuração em um dispositivo novo ou restaurado de fábrica.
• O identificador afw#setup baixa o Android Device Policy durante um fluxo compatível do assistente de configuração; os dados efetivos de inscrição constituem um artefato separado.
• Valores de tokens de produção, cargas de QR, identificadores de tenant, credenciais e listas de dispositivos nunca devem aparecer em conteúdo público nem em evidências comuns de aceitação.

Compare os principais métodos de entrada no provisionamento

Esta matriz auxilia na seleção; ela não é uma promessa universal de compatibilidade. Antes de aprovar uma via, confirme o modelo exato, o SKU regional, a compilação do Android e do firmware, a opção GMS ou AOSP, o EMM ou DPC selecionado, a licença, o estado de gerenciamento e a rede. O guia atual de provisionamento da Android Management API documenta as vias e os pré-requisitos compatíveis com o Google.

Elimine as vias incompatíveis antes do trabalho piloto

Não classifique os métodos antes de conhecer as dependências do projeto. Use os filtros a seguir para eliminar vias incapazes de alcançar o estado gerenciado pretendido no dispositivo e na compilação exatos.

• Estado-alvo — perfil de trabalho em dispositivo pessoal, perfil de trabalho em dispositivo corporativo, totalmente gerenciado ou dedicado.
• Base do dispositivo — modelo exato, SKU regional, versão do Android, compilação do firmware e estado de segurança relevante.
• Opção de serviços do Google — GMS, Google Play Services e compatibilidade com Android Enterprise quando exigidos pela via selecionada.
• Arquitetura de EMM — método de entrada e estado de gerenciamento compatíveis nessa compilação exata.
• Cadeia de suprimentos — responsáveis pelo registro dos dispositivos, atribuição da configuração, programa do OEM e exceções de contas.
• Rede — Wi-Fi, portal cativo, proxy, firewall, DNS, horário e acesso aos serviços efetivamente utilizados.
• Recuperação — condição inicial acordada e resposta a interrupção, redefinição, substituição ou falha na inscrição.

Valide a via a partir da condição inicial pretendida

A documentação comprova que um método existe; a aceitação do projeto exige que a implementação exata seja exercitada. Execute a via em uma amostra com controle de versão e registre evidências não sigilosas para cada ponto de verificação. O provisionamento bem-sucedido comprova apenas o método testado e o estado gerenciado nas condições registradas — não o fluxo completo do aplicativo, o comportamento do quiosque, os periféricos, a adequação regional, as atualizações nem a consistência do lote. Essa distinção é o cerne de pronto para MDM versus pronto para implantação.

• Registre a condição inicial e a identidade exata do dispositivo e da compilação.
• Execute a via aprovada usando dados de provisionamento controlados e não públicos.
• Confirme a empresa, o grupo, o estado de propriedade e o modo de gerenciamento pretendidos.
• Verifique a chegada da política esperada e do aplicativo aprovado sem tratar essa chegada como prova do comportamento completo.
• Teste reinicialização, perda temporária da rede, interrupção da configuração, atualização da política e a via acordada de acesso ao suporte.
• Teste a redefinição e a nova inscrição quando necessário, usando um cenário adequado ao estado de propriedade.
• Registre exceções, ações de recuperação, responsáveis, resultados e todas as condições que exijam revalidação.

Transforme a via aceita em uma instrução controlada para o lote

Depois que a via da amostra for aceita, transforme-a em uma instrução com controle de versão. A preparação do lote não é outro método de entrada do Android Enterprise; é o processo operacional que aplica a via aceita de forma consistente, rastreia dispositivos e exceções, executa as verificações acordadas e prepara as evidências para a transferência. Consulte Provisionamento e Preparação em Lote de Dispositivos Android para conhecer o contexto mais amplo da entrega.

• Registre o dispositivo e a compilação do firmware, o estado-alvo, o método, a política EMM e as referências aprovadas dos aplicativos.
• Use uma referência não sigilosa ao perfil de inscrição, em vez de incorporar um token de produção ou uma carga de QR.
• Documente a condição inicial, os pré-requisitos de rede, os pontos de verificação do operador, a via de exceção, a regra de interrupção e o responsável.
• Vincule as faixas de números de série ou IMEI à compilação aceita, à política, ao aplicativo, às etiquetas, aos acessórios e ao estado das caixas.
• Faça nova validação após mudanças na compilação, na opção GMS/AOSP, no EMM ou DPC, na política, no aplicativo, no processo do revendedor, na rede ou nas premissas de recuperação.

Trate programas AOSP e sem GMS como uma via de viabilidade separada

Não presuma que o provisionamento por QR ou zero-touch, por identificador de DPC ou por uma via gerenciada pelo Google seja transferido sem alterações para uma compilação AOSP ou sem GMS. A via de produção depende da compilação do OEM, dos componentes de gerenciamento incluídos, do modelo de assinatura e privilégios, da experiência de configuração, da responsabilidade pelas atualizações e do processo de preparação. Comece pelo guia de decisão GMS versus AOSP. O AOSP documenta a arquitetura de gerenciamento de dispositivos da plataforma e os mecanismos de provisionamento de device owner, mas o projeto exato ainda precisa de evidências próprias sobre segurança, recuperação, ciclo de vida e aceitação.

• Um projeto AOSP pode exigir um fluxo específico do OEM, firmware, USB, APK, agente ou preparação.
• O Device Admin legado não deve ser apresentado como um atalho moderno; novas soluções EMM devem seguir a Android Management API, em vez de novos registros na Play EMM API ou de registros personalizados de DPC.
• Implementações de DPC personalizado precisam seguir os manipuladores de provisionamento das versões atuais do Android e passar por nova validação após alterações no sistema operacional (OS) ou no firmware.

Atribua as contas e as responsabilidades

O modelo de responsabilidades abaixo é uma base de planejamento, e não um contrato universal. A Vantora pode coordenar o programa de dispositivos, mas não se torna a fornecedora de EMM, titular do tenant nem operadora do Android Enterprise do cliente, tampouco a responsável universal por todos os programas de inscrição do OEM.

Casos comuns de falha e recuperação

A maioria das falhas de provisionamento decorre de um pequeno conjunto de dependências do projeto. Detecte-as em uma amostra controlada e ensaie a via de recuperação antes que o método selecionado se transforme em uma instrução de produção.

• Portal cativo, proxy, DNS, firewall ou rede instável bloqueia o download do DPC ou da política.
• Tenant incorreto, incompatibilidade de contas, configuração zero-touch não atribuída ou falha no registro pelo revendedor.
• Modelo, SKU regional, compilação do firmware ou estado de gerenciamento incompatível.
• Token expirado, carga malformada, erro do DPC ou identificador de dispositivo duplicado.
• Redefinição inesperada, proteção contra restauração de fábrica ou via incompleta de nova inscrição.
• A política ou o aplicativo chega, mas o fluxo representativo ainda falha após reinicialização, atualização ou perda temporária da rede.