O que é um dispositivo Android personalizado?

Uma definição prática

Um dispositivo Android personalizado é um smartphone ou tablet cuja configuração foi fixada em torno de um requisito de negócio específico, em vez de ficar aberta para que cada proprietário a personalize. O hardware de base costuma ser um celular ou tablet Android comprovado e já em produção em volume; o que muda é a camada acima dele — identidade visual, software pré-instalado, experiência padrão, políticas de gerenciamento e, em uma minoria dos programas, firmware ou componentes. O dispositivo chega dedicado a um propósito: ele abre na ferramenta para a qual a organização o distribuiu, impõe as restrições que a organização acordou e faz isso do mesmo modo em cada unidade do lote. Propósito acima de personalização é o que a maioria das pessoas quer dizer ao perguntar o que é um dispositivo Android personalizado.

Por que a reprodutibilidade faz parte da definição

A propriedade que as definições curtas costumam descartar — do mesmo modo em cada unidade — é justamente a que decide se um projeto dá certo. Uma configuração que um técnico consegue produzir uma vez na bancada é uma demonstração. Uma configuração que pode ser registrada em uma especificação da configuração, comprovada em uma amostra com controle de versão, aprovada conforme uma matriz de aceitação e reproduzida sob um registro do lote é um programa de dispositivos. O conteúdo de engenharia dos dois pode ser idêntico; a diferença está em o estado ser reprodutível e documentado. Por isso a definição de trabalho usada em todo este site é deliberadamente estreita: um dispositivo Android personalizado é uma configuração de dispositivo acordada — modelo e variante regional, versão do Android, linha de base do firmware, conjunto de aplicativos, conjunto de políticas, embalagem e premissas de mercado — que foi validada em uma amostra e reproduzida sob um registro do lote. Tudo o que vem a seguir descreve o que pode estar dentro dessa configuração, de quem cada parte depende e qual guia é dono da decisão. A visão capacidade por capacidade está em personalização de dispositivos Android.

Os quatro níveis de personalização

Ajuda pensar na personalização como camadas que se empilham, e não como um cardápio do qual se escolhem itens. Cada nível acrescenta capacidade, custo e esforço de validação, e cada um muda quem precisa ser envolvido: uma pré-instalação é uma tarefa de software, uma política é uma tarefa de EMM e uma alteração de firmware é uma tarefa de engenharia do OEM, com o prazo do OEM embutido. A maioria dos programas se resolve nos dois ou três primeiros níveis, e o quarto é o mais restrito, validado caso a caso no hardware escolhido. A tabela abaixo deve ser lida em uma única direção: a pergunta útil não é qual é o nível mais profundo disponível, mas qual é o nível mais leve que atende ao requisito. Um programa entregável por identidade visual, pré-instalação do aplicativo e uma política do Android Enterprise é mais rápido de construir, mais barato de sustentar e mais fácil de atualizar do que outro que exija um fork de firmware, e continua herdando o fluxo de patches de segurança do OEM em vez de assumir essa responsabilidade. Profundidade é um custo, não um recurso. Quando um requisito realmente não pode ser atendido por política — remapear um botão físico, remover um rádio, impor uma restrição em nível de sistema fora da superfície de políticas padrão —, é aí que os níveis mais profundos se justificam, e o trade-off está descrito em MDM versus ROM Android personalizada.

O que uma amostra aprovada precisa comprovar: cinco resultados

Os níveis descrevem o que pode ser alterado. Os resultados descrevem o que a organização de fato possui quando o programa termina e, para quem está especificando um dispositivo personalizado pela primeira vez, o enquadramento por resultados é o mais útil. Todo programa aceito se traduz em cinco resultados — Lista reduzida de dispositivos, Configuração pronta para aplicativos, Configuração controlada por políticas, Amostra aprovada em testes de aceitação e Entrega em lote preparado — e cada um é comprovado em um ponto específico da cadeia, em vez de afirmado em uma proposta. Isso torna os cinco resultados o teste honesto a aplicar a qualquer fornecedor, inclusive a este: se um fornecedor não sabe dizer onde cada resultado é confirmado e quem o assina, o resultado é uma intenção, e não uma entrega. A tabela relaciona cada resultado ao ponto da implantação em que ele deixa de ser uma alegação e ao guia que é dono da decisão por trás dele.

O que significa cada um dos cinco resultados

A Lista reduzida de dispositivos responde qual modelo, em qual variante regional, em qual versão do Android e com qual horizonte de suporte. Ela é comprovada quando uma especificação da configuração identifica um hardware que passa em conjunto pelos filtros de aplicativo, região, periféricos e ciclo de vida — não quando um item de catálogo parece adequado isoladamente. A Configuração pronta para aplicativos responde se o software que justifica todo o programa realmente funciona: instalação, primeira execução, login, permissões, comportamento offline, trabalho em segundo plano e via de atualização, testados em uma versão congelada do aplicativo sobre uma linha de base de firmware congelada. A Configuração controlada por políticas responde qual camada de controle entrega cada restrição — um launcher muda o que o usuário vê, o bloqueio de dispositivo dedicado muda o que o sistema permite, a política de EMM muda o que a frota impõe e o firmware é o último recurso. A Amostra aprovada em testes de aceitação responde o que foi aprovado e, com a mesma importância, o que foi registrado como limitação conhecida em vez de silenciosamente deixado de lado na esperança de que não apareça. A Entrega em lote preparado responde se o estado aceito pode ser reproduzido e rastreado nas unidades de produção, em vez de reconstruído de memória dezoito meses depois.

Três programas, três profundidades diferentes

Níveis e resultados ficam mais fáceis de reter como formas concretas, então seguem três — composições ilustrativas de padrões comuns, não clientes identificados. Uma implantação de serviço de campo com cerca de mil aparelhos costuma parar no nível três: um celular OEM intermediário atual, o aplicativo de ordens de serviço pré-instalado, uma política de dispositivo dedicado que trava o aparelho nesse aplicativo mais câmera e chamadas, e identidade visual limitada ao logotipo de inicialização e à embalagem. Nada de firmware é tocado, então o fluxo de patches do OEM continua valendo, e a maior parte do cronograma vai para a amostra e não para a construção — provar que o aplicativo mantém as permissões após uma reinicialização e que o técnico não consegue sair do aplicativo para um navegador. Uma implantação do setor público de porte parecido parece idêntica no slide e não é: a configuração precisa ficar documentada e reproduzível para compras e auditoria, de modo que o trabalho migra para a evidência — resultados assinados por uma autoridade de aceitação nomeada, um registro de lote que amarra faixas de número de série ou IMEI à amostra aprovada, e limitações escritas em vez de ignoradas. Essa é a forma de uma implantação controlada de cerca de 1,000 unidades e a de um programa organizacional construído na camada de experiência, em que identidade, aplicativos pré-instalados e uma tela inicial voltada ao foco viraram uma especificação de dispositivo construível sem mexer no firmware. A terceira forma é o caso minoritário: um programa de uso restrito que precisa remover ou desativar um recurso em um nível que a política não alcança. Esse chega ao nível quatro e traz junto engenharia do OEM, um ciclo de amostra mais longo e questões de documentação do mercado de destino — é aí que a distinção entre ODM e OEM deixa de ser acadêmica. Os cinco resultados são os mesmos nos três casos. Mudam a profundidade, os responsáveis e a quantidade de prova.

O que cada nível custa

A profundidade é paga em três moedas e só uma aparece na cotação. A primeira é o cronograma: cada nível acrescentado é mais uma coisa que a amostra precisa demonstrar antes de um lote poder ser preparado. A segunda é a evidência — construções mais profundas não exigem apenas mais testes, exigem mais registro: uma linha de base de firmware, um resultado de regressão, um plano de patches. A terceira é a responsabilidade, e é a que sobrevive ao projeto: até o nível três o OEM continua publicando patches de segurança e a frota os herda, enquanto no nível quatro essa herança deixa de ser automática e alguém precisa assumi-la por toda a vida da implantação. É por isso que ficar no nível mais leve que atenda ao requisito é uma decisão de manutenção, não uma concessão orçamentária. Faixa de volume, profundidade da personalização, escopo de documentação e número de ciclos de amostra mexem muito mais na cotação do que a lista de materiais — os números estão em MOQ, custo e prazo, e os limites em que outros programas já esbarraram estão reunidos na biblioteca de limitações conhecidas.

Dispositivo Android personalizado versus celular de consumo personalizado pelo usuário

Personalizar um celular de consumo significa que uma pessoa altera configurações de nível de usuário — papel de parede, aplicativos, contas, preferências de notificação — para si mesma. É reversível, não documentado e impossível de reproduzir no próximo aparelho sem repetir cada passo manualmente. Um dispositivo Android personalizado é construído para implantação, onde a reprodutibilidade e o controle central importam mais do que a preferência de qualquer usuário isolado. Essa consistência, e não o logotipo na tela de inicialização, é a diferença prática, e é o que permite que uma frota de vários milhares de unidades seja atendida por uma equipe pequena: quando todos os dispositivos vieram da mesma configuração aceita, um chamado de suporte trata de um dispositivo, e não de descobrir qual das onze configurações possíveis esta unidade específica está rodando.

De onde um dispositivo implantado tira o seu estado

A diferença mecânica entre os dois está na origem da configuração. A personalização de consumo vive em configurações de usuário que o próprio usuário pode desfazer. Um dispositivo personalizado implantado tira o seu estado de um provisionamento e de uma política de gerenciamento aplicada no registro — normalmente com um controlador de políticas do dispositivo estabelecido como device owner —, de modo que a configuração é reafirmada pela plataforma em vez de lembrada pela pessoa que segura o dispositivo. Onde a via de provisionamento permite, uma restauração pode devolver a unidade à linha de base acordada em vez de a um estado de consumo em branco, embora esse comportamento dependa da via de provisionamento e do OEM e seja uma das coisas que uma amostra deve demonstrar, e não presumir. É também por isso que o modo de propriedade escolhido no registro importa mais do que a maioria das listas de recursos sugere: um perfil de trabalho, um perfil de trabalho em dispositivo corporativo e um dispositivo totalmente gerenciado não expõem o mesmo escopo de controle, e um dispositivo dedicado é um dispositivo totalmente gerenciado restringido ainda mais a um aplicativo ou a um pequeno conjunto de aplicativos.

Onde cada decisão é realmente tomada

Uma página de definição não deve tentar resolver todas as decisões que menciona, e esta deliberadamente não resolve. Cada pergunta abaixo tem um guia que é dono dela, com os trade-offs, as dependências de plataforma e as evidências que uma amostra precisa produzir escritos de forma adequada; as respostas de uma linha aqui servem de orientação para quem acabou de chegar ao tema, não como substituto da decisão. Lidas em ordem, as cinco perguntas também formam uma sequência aproximada. Saber se um dispositivo personalizado é mesmo necessário vem antes de escolher a camada de controle; a camada de controle vem antes da via de plataforma; e o formato comercial — faixa de volume, ciclos de amostra, escopo de documentação — é o que transforma tudo isso em uma cotação e uma data.

• Precisamos mesmo de um dispositivo personalizado? Um dispositivo de prateleira com um EMM, um dispositivo levemente configurado e uma configuração completa são três compromissos diferentes — veja dispositivos Android personalizados versus de prateleira.
• Política ou firmware? A política padrão do Android Enterprise cobre a maioria das restrições; uma ROM personalizada traz o próprio ônus de patches e manutenção — veja MDM versus ROM Android personalizada.
• GMS ou AOSP? Os serviços do Google e o Managed Google Play diante de uma configuração sem serviços, com premissas diferentes de registro, distribuição de aplicativos e atualização — veja GMS versus AOSP para dispositivos empresariais.
• Qual camada de bloqueio? Um launcher muda o que o usuário vê, o bloqueio de dispositivo dedicado muda o que o sistema permite e a política de EMM muda o que a frota impõe — veja launcher personalizado versus modo quiosque versus MDM.
• Quanto vai custar e quando? Faixa de volume, profundidade da personalização, escopo de documentação e ciclos de amostra alteram a cotação mais do que a lista de materiais — veja MOQ, custo e prazo.

Casos de uso corporativos comuns

Dispositivos Android personalizados aparecem sempre que uma organização entrega hardware para executar um trabalho definido, em vez de distribuir celulares genéricos. O padrão é consistente entre setores: alguém responde pelo que o dispositivo faz, a pessoa que o segura não o escolheu e o custo de uma unidade inconsistente é medido em chamados de suporte, auditorias reprovadas ou turnos perdidos, e não em leve inconveniência. Equipes de serviço em campo e operações de logística os utilizam para que o pessoal abra direto na ferramenta certa e permaneça nela durante todo o turno. Programas do setor público os utilizam porque a configuração precisa ser documentada e reproduzível para fins de compras públicas e auditoria, e não apenas funcional no dia da demonstração. Programas educacionais e comunitários os utilizam para colocar uma única experiência de aprendizagem ou de associação diante do usuário e mantê-la ali. Plataformas de varejo e de conteúdo os utilizam para tornar um único aplicativo praticamente todo o dispositivo. O que esses casos têm em comum não é uma lista de recursos — é que a pergunta de aceitação é idêntica em todos eles: esta configuração exata, neste modelo exato, executa o trabalho acordado do mesmo modo na unidade um e na unidade dois mil?

• Serviço em campo e logística — fluxos de inspeção, vistoria e entrega sobre um conjunto de ferramentas bloqueado.
• Setor público — dispositivos com a marca do órgão e controlados por políticas para uso oficial e em campo.
• Programas educacionais e comunitários — uma experiência focada de aprendizagem ou de associação como padrão.
• Plataformas de varejo e de conteúdo — dispositivos que abrem direto em um único aplicativo ou ponto de entrada de conteúdo.

Quando você não precisa de um dispositivo Android personalizado

Uma página de definição honesta precisa incluir os casos em que a resposta é não. Programas de dispositivos personalizados são cotados a partir de cerca de 500 unidades porque o trabalho fixo — especificação, amostra, aceitação, registro de lote — não encolhe junto com a quantidade do pedido; abaixo desse piso o mesmo resultado costuma sair mais barato em um dispositivo de prateleira com uma assinatura de MDM, e dizer isso antes de um ciclo de amostra custa menos do que descobrir depois. Os outros três casos de não são mais silenciosos, porque chegam parecendo problemas de dispositivo e não são. Vale descartar cada um deliberadamente: um requisito que na verdade é do aplicativo acompanhará o programa até o nível quatro e continuará sem solução lá.

• Abaixo de cerca de 500 unidades — configure um dispositivo de prateleira com um EMM; remessas piloto de 20-100 unidades dentro de um programa maior são outro caso.
• Identidade visual sem aplicativo, sem política e sem plano de implantação por trás — isso é um exercício de compras, não uma construção de dispositivo.
• Uma restrição que a frota já implantada conseguiria aplicar hoje — teste a política no hardware que você tem antes de trocar de hardware; veja celulares Android de consumo como dispositivos de projeto controlados.
• Uma lacuna que na verdade mora no aplicativo — comportamento offline, permissões e trabalho em segundo plano são decisões do aplicativo antes de serem do dispositivo; veja a checklist de dispositivo pronto para o aplicativo.

O que não se pode presumir

Não há duas configurações de dispositivo iguais, por isso é arriscado presumir que uma capacidade observada em um modelo se transfere para o seguinte. A versão do Android disponível, o horizonte de patches de segurança, a presença dos Google Mobile Services ou de uma configuração AOSP sem serviços, a profundidade do acesso ao código-fonte do OEM e a vida útil de produção do modelo carregam todos uma dependência do OEM que precisa ser verificada no hardware específico, e não pelo nome da família. Uma premissa merece ser dita com todas as letras: GMS não é uma propriedade do Android em si. Os serviços do Google e o Managed Google Play chegam por meio de uma configuração licenciada e testada quanto à compatibilidade, e os requisitos subjacentes estão publicados no Android Compatibility Definition Document. Uma configuração AOSP sem serviços precisa de uma via diferente de gerenciamento e de distribuição de aplicativos, que é onde GMS versus AOSP para dispositivos empresariais retoma o assunto. Por sua vez, os controles mais fortes dependem de um controlador de políticas do dispositivo estabelecido como device owner, o que normalmente exige um dispositivo em estado limpo, recém-saído da caixa ou restaurado de fábrica, e não um já configurado com uma conta pessoal — aplicar device owner retroativamente a um celular de consumo já configurado geralmente não está disponível.

O vocabulário, em uma tabela

A maior parte da confusão em uma conversa inicial sobre dispositivos personalizados é de vocabulário, não de engenharia: duas pessoas usam a mesma palavra para escopos de controle diferentes e só descobrem na amostra. A tabela fixa os termos usados neste site e, mais útil ainda, aponta o momento em que cada um deixa de ser definição e passa a ser um resultado que alguém precisa demonstrar.

Termos que carregam premissas ocultas

Vários termos cotidianos desta área importam silenciosamente premissas que só uma amostra pode resolver. Um dispositivo dedicado não é um modo de gerenciamento separado: é um dispositivo totalmente gerenciado bloqueado em um aplicativo ou em um pequeno conjunto de aplicativos, portanto herda a capacidade de device owner, e o Google documenta esse padrão em dispositivos dedicados. A forma como o lock task mode trata a barra de status, as notificações, as caixas de diálogo do sistema e as rotas de recuperação varia conforme a versão do Android e a implementação do OEM, e é precisamente por isso que isso pertence a uma matriz de aceitação, e não a uma frase de especificação. Do mesmo modo, um EMM só consegue definir os campos de configuração que o desenvolvedor do aplicativo efetivamente publicou por meio de configurações gerenciadas; nenhuma plataforma de gerenciamento consegue inventá-los, e um aplicativo de terceiros que não exponha nenhum exigirá uma abordagem diferente. Documentação do mercado-alvo, bandas de rádio e responsabilidades do importador são avaliadas país a país, e tudo o que vá além do comportamento padrão documentado está sujeito a validação técnica antes de ser assumido em um programa.

Como funciona normalmente um projeto de dispositivo personalizado

Um programa de dispositivo personalizado não é um pedido seguido de uma surpresa. Ele percorre seis pontos de controle visíveis — Briefing do projeto, Especificação da configuração do dispositivo, Amostra validada, Matriz de aceitação, Lote preparado e Implantação gerenciada — e cada ponto de controle tem uma entrada definida, um material de saída definido e um aceitante nomeado. São essas três propriedades que tornam a cadeia auditável; quando um programa atrasa, é quase sempre porque uma delas ficou implícita, de modo que ninguém combinou o que significava “amostra aprovada” ou ninguém foi nomeado para dizê-lo. Os pontos de controle também são a resposta à pergunta escondida dentro de “o que é um dispositivo Android personalizado”: o dispositivo é o que a especificação da configuração diz, comprovado pelo que a amostra demonstrou e reproduzido pelo que o registro do lote rastreia. O passo a passo completo — entradas, materiais de saída e responsáveis pela aceitação em cada ponto de controle, além dos materiais que se acumulam em um dossiê da configuração — está em como funciona uma implantação validada de dispositivos Android, e a visão do lado da entrega da mesma cadeia está em desenvolvimento de dispositivos Android personalizados.

1. 1Briefing do projeto — usuários, aplicativo, mercados-alvo, restrições, faixa de quantidade e prazo, anonimizado quando é preciso proteger uma relação com um parceiro.
2. 2Especificação da configuração do dispositivo — lista reduzida de modelos, escolha entre GMS e AOSP, versão do Android, lista de aplicativos pré-instalados, desenho do launcher e das políticas, embalagem, etiquetas e limites conhecidos.
3. 3Amostra validada — a configuração em hardware real sobre uma versão congelada do aplicativo e das políticas, com uma nota de versão registrando exatamente o que foi construído.
4. 4Matriz de aceitação — resultados de aprovação, reprovação e condicionais para o comportamento do aplicativo, das políticas, da rede, da restauração e da embalagem, assinados por uma autoridade de aceitação nomeada.
5. 5Lote preparado — unidades de produção preparadas conforme as versões aceitas e vinculadas à amostra por número de série ou IMEI em um registro do lote.
6. 6Implantação gerenciada — transferência dos limites de suporte, da responsabilidade pelas atualizações, do caminho de garantia, da política de unidades sobressalentes e dos gatilhos de revalidação.

O que é flexível em um programa de dispositivo personalizado e o que não é

A profundidade é livremente flexível. Um pedido de identidade visual e aplicativo sobre um modelo comprovado pode atravessar rapidamente a especificação e a amostra, enquanto uma configuração em nível de firmware ou pesada em documentação passará semanas em validação — e deve mesmo passar; as janelas de planejamento são faixas típicas confirmadas por projeto, e não prometidas de forma genérica. O que não é flexível é a ordem. Nenhum lote é preparado antes de uma amostra ser aceita, nenhuma amostra é construída antes de uma especificação ser assinada e nenhuma especificação é escrita contra um briefing que ninguém revisou. Pular um ponto de controle não elimina o risco dele; apenas transfere a descoberta desse risco para o campo, onde é mais caro corrigir. Uma brecha de saída do modo quiosque encontrada em uma unidade de avaliação é uma nota de engenharia. A mesma brecha encontrada em dois mil dispositivos preparados é um incidente e, nesse ponto, a linha de base aceita, o registro do lote e o limite de suporte precisam ser reabertos todos de uma vez.

Comece pelo requisito, não pela lista de recursos

A forma mais comum de um projeto de dispositivo personalizado dar errado é começar como uma lista de compras — um logotipo, um modo quiosque, um aplicativo pré-instalado — em vez de um requisito. Uma lista de recursos não pode ser testada; um requisito pode. Descrever quem usa o dispositivo, o que essas pessoas precisam poder fazer, o que não podem fazer, onde ele é usado, para quais mercados é enviado e quantas unidades são esperadas transforma a conversa em algo que uma análise de viabilidade consegue de fato responder e, na prática, encurta os programas ao eliminar personalizações que ninguém precisava depois que o requisito subjacente foi escrito. Sobre volume: os programas são cotados a partir de cerca de 500 unidades, e um programa normalmente começa com 1-3 amostras de avaliação e uma remessa piloto de aproximadamente 20-100 unidades antes de o lote de produção ser comprometido. Abaixo desse piso, configurar um dispositivo de prateleira com uma assinatura de MDM costuma ser a via mais econômica, e dizer isso cedo custa menos do que descobri-lo depois de um ciclo de amostra. A descoberta de soluções é onde um requisito é transformado em uma lista reduzida de dispositivos e em uma lista de questões em aberto com responsáveis, e o modelo de especificação de configuração do dispositivo é o formato em que essas respostas se materializam.