O que uma especificação de configuração de dispositivo Android deve incluir?

Resposta curta

Uma especificação de configuração de dispositivo Android é um registro de projeto com controle de versão que declara o estado exato do dispositivo que um lote deve reproduzir: qual dispositivo físico, qual compilação de firmware, quais versões do aplicativo, qual política, qual via de provisionamento, quais premissas de mercado, quais acessórios e qual embalagem — e quem responde por cada uma dessas decisões quando alguma delas muda. Ela é escrita como rascunho durante a viabilidade, refinada em uma revisão de candidata a amostra antes de uma unidade ser configurada e congelada em uma referência de produção aceita depois que a amostra é analisada e aprovada. Duas coisas a tornam útil, e não decorativa. A primeira é que cada campo material carrega um valor aprovado, uma referência de evidência, um responsável nomeado e uma regra de mudança, de modo que ninguém precisa adivinhar se um valor foi decidido ou apenas digitado. A segunda é que ela vem emparelhada com uma amostra com controle de versão: a especificação diz qual deveria ser o estado, o registro da amostra diz o que uma unidade real foi observada como sendo, e a aceitação é o momento em que os dois são declarados equivalentes dentro de um escopo definido. Os programas que a Vantora cota a partir de cerca de 500 unidades dependem desse emparelhamento, porque a consistência de produção só faz sentido quando existe uma referência com a qual ser consistente.

A especificação de configuração é um registro de projeto controlado

Uma especificação de configuração de dispositivo Android não é uma ficha técnica de consumo, um arquivo de build de aplicativo Android nem uma prova de que o dispositivo passou na aceitação. É um registro de projeto com controle de versão que define o estado de entrega pretendido. “Especificação de configuração de dispositivo Android” é uma expressão de projeto da Vantora, e não um tipo de documento oficial do Android; por isso, cada campo material deve identificar um estado, remeter a uma evidência, nomear um responsável e definir o que acontece quando esse estado muda. A disciplina é imposta pela plataforma, não inventada para ela: quase todo valor que o comprador trata como uma coisa só é, na verdade, vários. O Android expõe identificadores de modelo, produto, hardware, SKU e build como campos distintos; o rótulo da versão, o nível de API, o identificador da build e o nível do patch de segurança avançam de forma independente entre si; um aplicativo carrega um nome de pacote, um version code, um version name e uma identidade de assinatura que não são intercambiáveis. Uma especificação que reduz qualquer um desses elementos a uma única expressão simpática já perdeu a capacidade de dizer se duas unidades são iguais — que é a única pergunta que uma verificação de lote consegue responder de fato. O corolário importa na mesma medida: resultados de compatibilidade, licenciamento, aprovação de mercado e evidências de aceitação permanecem como registros separados, com seus próprios detentores, porque uma especificação que os absorve vira o documento que todos citam e ninguém consegue verificar.

O que é uma amostra de dispositivo Android com controle de versão

Uma especificação de configuração descreve uma intenção. Uma amostra com controle de versão é a contraparte física: uma unidade configurada cuja identidade completa foi capturada, registrada por escrito e colocada sob controle de mudanças, para que qualquer afirmação posterior sobre a frota possa ser rastreada até algo que realmente existiu em uma bancada, em uma data conhecida. A expressão importa porque “a amostra que enviamos” não é um registro. Ela nomeia um objeto, não um estado. Três meses depois, ninguém consegue dizer com segurança qual compilação de firmware aquela unidade tinha, qual version code do aplicativo estava instalado, se o launcher havia sido atualizado entre a demonstração e a aprovação, ou qual revisão de política estava aplicada quando o testador executou os cenários de quiosque. Uma amostra com controle de versão responde a tudo isso a partir de um registro escrito, e não da memória, porque a identidade foi capturada no momento da configuração, e não reconstruída depois. A identidade que uma amostra carrega tem três camadas, e cada uma existe por um motivo diferente. A identidade de compra — fabricante, modelo exato, SKU regional, variante de memória e armazenamento, via de fornecimento — responde a “esta unidade pode ser comprada de novo no mercado-alvo?”, que é a pergunta na qual uma amostra promissora costuma falhar meses depois. A identidade de runtime — número de série, IMEI, versão do Android e nível de API, nível do patch de segurança, build ID ou impressão digital do firmware, estado GMS ou AOSP — responde a “uma unidade de produção é mesmo a mesma plataforma de software?”, e é capturada do dispositivo, e não da ficha técnica, porque as duas divergem com mais frequência do que os compradores esperam. A identidade de configuração — nomes de pacote dos aplicativos com version code e version name, assinatura e via de distribuição, pacote e versão do launcher, versão do DPC ou do agente de gerenciamento, revisão do perfil de política, modo de propriedade e via de provisionamento — responde a “o que foi de fato aplicado a esta unidade?”. Acima dessas camadas ficam os campos de processo que tornam o registro defensável, e não apenas detalhado: a data da configuração, o testador nomeado, a revisão da matriz de aceitação contra a qual a unidade foi testada, as limitações conhecidas aceitas junto com ela e a data de aprovação do cliente, com o nome de quem aprovou. Sem esse último grupo, o registro é um instantâneo técnico; com ele, o registro é uma decisão. O controle de versão acrescenta três propriedades que um instantâneo não tem. Os estados anteriores são preservados em vez de sobrescritos, então uma dúvida sobre uma unidade entregue em março pode ser respondida conforme a revisão que regia março. Cada revisão tem um escopo, que indica quais lotes ou remessas ela rege, e é isso que permite que uma remessa piloto de vinte a cem unidades rode sob uma revisão enquanto as demais unidades do programa aguardam a próxima. E toda mudança é atribuível — alguém a propôs, alguém a aprovou, e ambos ficam registrados —, o que é a diferença entre um adendo e uma discussão. A mecânica de reproduzir um estado aprovado em unidades de produção pertence à preparação em lote; o que importa aqui é que a preparação tem uma referência fixa a reproduzir e uma regra de parada que dispara quando uma unidade se desvia dela.

Como o registro da amostra e a especificação de configuração se referenciam

Os dois registros respondem a perguntas diferentes e não devem repetir um ao outro. A especificação de configuração é prescritiva: declara o valor pretendido de cada campo material, a tolerância ou variação permitida em torno dele, o responsável e a regra de mudança. O registro da amostra é descritivo: declara o que uma unidade real foi observada como sendo, em uma data, testada por uma pessoa nomeada. A aceitação é o momento em que os dois são comparados e declarados equivalentes dentro de um escopo definido, e essa comparação só é possível porque os dois registros usam os mesmos nomes de campo, na mesma ordem. A ligação deve ser explícita e enxuta. A especificação carrega o ID da amostra e a revisão da amostra contra a qual foi aceita; o registro da amostra carrega a revisão da especificação a partir da qual a unidade foi configurada e a revisão da matriz de aceitação contra a qual foi testada. Nada além disso é copiado de um para o outro. Quando um valor é duplicado nos dois documentos, uma hora ele será atualizado em um e não no outro, e o projeto passa a ter duas verdades e nenhuma forma de saber qual delas regeu um lote embarcado. Quando um valor realmente precisa aparecer nos dois — o build ID do firmware é o caso mais comum —, um documento é o dono dele e o outro apenas o referencia, e a referência indica qual documento tem autoridade. Lacunas residuais vão para outro lugar ainda: uma limitação que foi aceita em vez de corrigida pertence à biblioteca de limitações conhecidas, com um responsável e um gatilho de revalidação, e não enterrada como ressalva dentro de um campo da especificação, porque um campo que parece aprovado é tratado como aprovado por todo mundo a jusante.

Use sete seções e quatro controles de campo

Para cada campo material, registre um valor aprovado ou uma faixa delimitada, uma referência de evidência, o responsável que confirma e a regra de variação ou de mudança. Um campo não resolvido permanece em aberto, com um responsável e um ponto de decisão; ele não deve ser preenchido com um palpite plausível. Esses quatro controles são o que separa uma especificação de uma lista de desejos, e aplicá-los costuma revelar mais do que os próprios valores — um campo que ninguém quer assumir é um campo que ninguém decidiu. Estruture o registro de modo que um avaliador consiga estabelecer em uma única passagem se o dispositivo físico, a plataforma de software, o estado dos aplicativos, o desenho de gerenciamento, o mercado e o kit, e a trilha de evidências foram todos definidos por alguém com autoridade para defini-los. O que a maioria das especificações pula é o limite — declarar o que cada seção deliberadamente não cobre —, e pular isso é como conclusões de certificação e condições comerciais acabam se infiltrando em uma linha de base de entrega. Mantenha os segredos completamente fora dela: tokens de inscrição, credenciais de administrador e material de assinatura são referenciados por localização e custodiante, nunca colados em um registro que vai circular como anexo.

Substitua rótulos vagos por cláusulas controladas

O objetivo não é mais palavras; é menos interpretações. Use marcadores de posição enquanto a especificação for um rascunho, mas não deixe que uma referência de produção aceita esconda uma incógnita material atrás de um “a definir”, de uma captura de tela sem legenda ou de um link inacessível. O padrão que separa um rótulo vago de uma cláusula digna de especificação é sempre o mesmo: o rótulo nomeia um resultado, a cláusula nomeia o valor, o mecanismo, o responsável e a variação permitida. “Firmware mais recente” é o exemplo mais claro, porque nem chega a ser um estado — é um alvo móvel que se resolve de forma diferente no dia em que cada unidade é preparada, que é exatamente como duas remessas do mesmo pedido acabam em builds diferentes. “Igual à amostra aceita” é o mais perigoso, porque soa como o compromisso mais forte possível enquanto delega toda a definição a um registro que talvez não esteja sob controle de versão. Para cada um desses casos há também evidências que pertencem a outro lugar, e trazê-las para dentro da especificação é como uma linha de base de entrega vira um documento não auditável em que ninguém confia o bastante para atualizar.

Mantenha os registros da implantação separados

A especificação de configuração define o estado-alvo. Os registros adjacentes definem a necessidade, a comprovação e a execução unidade a unidade. Mantê-los separados preserva a rastreabilidade e impede que um único documento finja responder a todas as perguntas da implantação. O teste prático é perguntar contra qual registro uma divergência deve ser resolvida. Se a discussão é sobre se um requisito chegou a ser acordado, o registro é o briefing de requisitos. Se é sobre qual deveria ser o estado entregue, é a especificação de configuração. Se é sobre se o estado foi comprovado como funcional, é a matriz de aceitação, que reúne cenário, comportamento esperado, comportamento observado, veredito e responsável. Se é sobre quais unidades receberam qual estado, é o registro de preparação ou do lote. Fundir quaisquer dois desses registros produz um documento que não consegue responder bem a nenhuma das perguntas: uma especificação que carrega resultados de teste fica desatualizada assim que um cenário é reexecutado, e uma matriz de aceitação que carrega definições de campo vira o lugar onde as pessoas vão consultar valores de produção que nunca foram mantidos ali. A separação também define quem pode alterar o quê — e a única regra que vale enunciar explicitamente é que um registro de preparação nunca autoriza uma mudança no estado aprovado. Ele registra que o estado foi aplicado, ou que uma unidade se desviou e foi retida.

Congele a referência e depois controle as mudanças

Um SKU de dispositivo, uma revisão de hardware, uma impressão digital de firmware, uma linha de base de patch, um artefato de aplicativo, uma via de assinatura, uma política, uma via de provisionamento, uma premissa de mercado, um acessório, um ativo de marca ou uma embalagem podem, todos, alterar a configuração. Abra uma revisão controlada, compare-a com a referência atual, identifique as evidências e as linhas da matriz de aceitação afetadas, atribua responsáveis e obtenha a decisão exigida antes que o novo estado seja usado. Vale nomear explicitamente os quatro estados abaixo no próprio documento, porque boa parte da confusão em um projeto de dispositivos vem de pessoas lendo um rascunho como se fosse uma aprovação. Um rascunho convida ao questionamento; uma revisão de candidata a amostra é um compromisso de configurar uma unidade de determinada maneira; uma referência de produção aceita é uma autorização com escopo e data; uma revisão substituída é evidência retida, não um erro a ser apagado. Onde esses pontos de controle se encaixam na sequência mais ampla — viabilidade, amostra, aceitação, preparação e transferência — está descrito em como funciona uma implantação validada de dispositivos Android.

1. 1Rascunho de viabilidade: requisitos confirmados, candidatos, incógnitas e responsáveis, sem implicar aceitação.
2. 2Revisão de candidata a amostra: a configuração exata que a amostra pretende representar.
3. 3Referência de produção aceita: decisão autorizada sobre a amostra, limitações e evidências para um escopo definido.
4. 4Revisão substituída: mantida em arquivo depois que uma revisão aprovada mais recente entra em vigor.

Revisão ou adendo: o que cada mudança dispara

Depois que uma referência é aceita, toda mudança proposta precisa de uma via, e existem apenas três. Um adendo corrige o documento sem alterar o estado do dispositivo — o nome corrigido de um responsável, uma tolerância esclarecida, um link que ficou obsoleto. Ele é registrado, datado e atribuído, mas não toca na aceitação e não exige que quem aprovou volte a olhar o dispositivo. Uma revisão muda o estado pretendido, o que significa um novo número de revisão, um diff em relação à referência anterior, uma avaliação de quais linhas da matriz de aceitação são afetadas e uma decisão de quem aprova, nomeado no documento, antes que qualquer unidade seja preparada conforme ela. Uma substituição ou uma mudança de modo de propriedade é um terceiro caso: produz uma nova amostra em vez de uma revisão, porque aquilo que está sendo validado deixou de ser aquilo que foi validado. A linha divisória não é o tamanho da mudança, e sim se as evidências continuam valendo. Um encarte de embalagem meramente cosmético pode ser um adendo; a troca de um carregador não pode, porque as evidências elétricas e de mercado se prendem a um número de peça. Uma mudança de política de totalmente gerenciado para uma configuração dedicada é uma revisão, já que o uso dedicado é um subconjunto do modelo totalmente gerenciado e a mudança é aplicada como política em um dispositivo já provisionado. Uma mudança de perfil de trabalho para gerenciamento como device owner não é uma revisão de forma alguma, porque a propriedade é fixada no provisionamento e não pode ser trocada pelo console; o dispositivo é reprovisionado a partir de um estado limpo, e uma nova amostra é configurada e aceita. Essa assimetria é a coisa mais útil a saber antes de escrever um modo em uma especificação de compra, e os próprios modos são comparados em dispositivos Android dedicados versus totalmente gerenciados. A autoridade de aprovação deve ser escrita na especificação, não presumida. Na maioria dos programas, o responsável técnico avalia o impacto, o aprovador do cliente autoriza qualquer coisa que mude comportamento aceito ou custo, e a preparação fica retida até que a autorização exista. O sentido de nomeá-los é que a falha cara não é uma decisão ruim — é uma mudança que chegou à produção porque ninguém era claramente responsável por dizer não.

Quando o OEM lança uma nova build de firmware após a aceitação

Esta é a forma mais comum de uma amostra aprovada deixar silenciosamente de representar a frota, e ela merece uma regra declarada, não uma resposta improvisada. Uma especificação de configuração pode congelar o valor que registra; ela não pode congelar o que um fabricante ou uma operadora publica. Dispositivos comprados semanas depois da aceitação podem sair da fábrica com uma build mais recente, e um dispositivo que chega ao campo pode se atualizar sozinho, a menos que a via de atualização seja controlada. O Android expõe uma política de atualização do sistema que um controlador de políticas do dispositivo atuando como device owner pode usar para adiar a instalação ou restringi-la a uma janela, onde o OEM oferece suporte, e vale aplicá-la — mas ela rege o momento da instalação em um dispositivo gerenciado, não o que chega pré-instalado em um lote recebido, e seu comportamento depende do OEM e da plataforma. A resposta viável tem quatro partes. Detectar: as unidades recebidas são conferidas contra o build ID ou a impressão digital registrados durante a preparação, de modo que uma divergência apareça na bancada, e não no site do cliente. Classificar: um avanço de nível de patch dentro do mesmo ramo de firmware costuma ser mais estreito do que um novo build ID, e uma especificação que declara explicitamente uma faixa de patch evita reabrir a referência a cada boletim mensal. Delimitar o reteste: em vez de reexecutar a matriz inteira, reexecute as linhas de aceitação que plausivelmente dependem da plataforma — inscrição a partir de um estado limpo, aplicação de políticas, comportamento do lock task, drivers de periféricos e a via de primeira execução e de permissões do aplicativo. Decidir e registrar: ou a nova build vira uma revisão da referência aceita, ou as unidades afetadas ficam retidas e a diferença é escalonada. Seja qual for o desfecho, o resultado é escrito na especificação e, quando uma diferença é aceita em vez de corrigida, também no registro de limitações conhecidas, com um responsável. O modo de falha contra o qual se deve projetar é o silencioso — unidades embarcadas com uma build que ninguém comparou, descoberta apenas quando parte da frota se comporta de forma diferente e não há registro do que mudou. A regra acima é a resposta do lado da especificação: o que a referência diz e qual autoridade a move. A resposta do lado da bancada — como um lote recebido é de fato conferido, como é uma reverificação em minipiloto em um pedido repetido e como as unidades divergentes são mantidas fora do fluxo de liberação — pertence à preparação em lote de dispositivos Android.

Como um pedido de substituição é avaliado

Pedidos de substituição chegam por motivos ordinários: uma variante sai de linha, um nível de memória fica escasso, um acessório é descontinuado, um prazo de fornecimento estoura a janela de entrega. Eles são legítimos, e recusá-los de imediato não é uma política — mas aceitar um deles com base em uma ficha técnica parecida é como um programa adquire um defeito que não consegue explicar. Uma avaliação útil segue uma ordem fixa. Primeiro, identifique o que de fato difere: não o nome comercial do modelo, e sim os campos que a especificação controla — SKU, rádios e bandas suportadas, memória e armazenamento, ramo de firmware, estado GMS ou AOSP, número de peça do periférico ou acessório, aprovações de mercado. Segundo, mapeie cada diferença na matriz de aceitação e marque as linhas que ela pode afetar; se uma diferença não toca nenhuma linha, provavelmente a especificação não está controlando algo que deveria. Terceiro, decida a via pela regra acima: um SKU regional ou uma revisão de hardware diferente é uma nova amostra; a troca de um acessório normalmente é uma revisão, com peça nomeada e regra de substituição. Quarto, orce a avaliação com honestidade, em tempo e em dinheiro, porque uma substituição que chega tarde em um programa concorre diretamente com a data de entrega que ela deveria proteger. Quinto, registre a decisão — inclusive uma recusa —, para que o mesmo pedido não volte sem informação nova. Duas salvaguardas valem ser escritas na especificação com antecedência. Nomeie quais campos são substituíveis, para que a área de compras saiba disso antes de perguntar; e declare que qualquer variante substituída entra no programa pela mesma via de amostra e aceitação da original, normalmente confirmada em uma remessa pequena antes de as demais unidades do programa serem preparadas. Esse acordo prévio é o que mantém uma substituição como um problema de cronograma, e não como uma renegociação.

Baixe o modelo de especificação de configuração de dispositivo

Use o modelo para registrar a plataforma pretendida do dispositivo, o estado do software e dos aplicativos, a política, a embalagem, os acessórios, as evidências e as referências de preparação. Mantenha segredos e condições comerciais em seus sistemas controlados e conecte a revisão final à amostra e às evidências de aceitação que a sustentam. Se um projeto já tem uma especificação em outro formato, o exercício útil não é reescrevê-la, e sim testá-la contra os quatro controles de campo: cada campo material carrega um valor aprovado, uma referência de evidência, um responsável nomeado e uma regra de mudança? Os campos que não passam nesse teste são justamente onde uma implantação costuma dar errado, e são baratos de corrigir enquanto a especificação ainda é um rascunho. Quando a questão mais ampla de prontidão ainda está em aberto — se um dispositivo que se inscreve com sucesso está de fato pronto para um lote —, comece por dispositivos Android prontos para MDM versus prontos para implantação e depois traga o modelo-alvo, o aplicativo, a plataforma de gerenciamento, os mercados e a faixa de quantidade, para que a especificação seja construída sobre restrições reais.