Como pré-instalar aplicativos em dispositivos Android em escala

Resposta curta

Colocar um aplicativo em uma frota são duas decisões, não uma, e os projetos que tratam disso como uma decisão só costumam pagar pela segunda mais tarde. A primeira decisão é a via de entrega: como o pacote chega fisicamente ao dispositivo — instalado por uma plataforma de gerenciamento depois da inscrição, preparado durante o provisionamento na bancada, gravado na imagem expedida para estar presente na primeira inicialização ou integrado a uma partição de sistema com posição privilegiada. A segunda decisão é a responsabilidade pelas atualizações: quem guarda a chave de assinatura, quem decide que uma nova versão será lançada, como uma versão é fixada no registro da configuração e o que precisa acontecer, física e comercialmente, para que uma build defeituosa seja recolhida. As duas se condicionam mutuamente. Quanto mais fundo o aplicativo se aloja na build, mais ele consegue fazer e mais caro fica alterá-lo, porque a alteração deixa de ser uma publicação em loja e passa a ser um evento de firmware com um OEM no circuito. Esse compromisso é todo o assunto desta página. Vale delimitar um ponto logo de início: este guia trata das vias de chegada ao dispositivo, não da pergunta sobre qual canal de distribuição transporta o pacote — Google Play público, Managed Google Play ou um APK hospedado de forma privada é uma decisão correlata, com restrições próprias, e é resolvida separadamente das decisões de posicionamento tratadas a seguir.

Como um aplicativo chega ao dispositivo: quatro famílias de vias

As vias parecem intercambiáveis em um documento de requisitos e se comportam de maneira muito diferente em campo. Uma instalação gerenciada acontece depois que o dispositivo se inscreve: o controlador de políticas do dispositivo (DPC), definido como device owner no provisionamento, instala o aplicativo por instrução da plataforma de gerenciamento, que também é o caminho pelo qual o aplicativo é depois atualizado, substituído ou removido. A preparação no momento do provisionamento instala o pacote durante a própria execução da preparação, antes de a unidade ser encaixotada, de modo que o dispositivo sai com o aplicativo presente, mantenha ele ou não uma relação de gerenciamento contínua. Uma pré-instalação de fábrica grava o pacote na imagem expedida, e é a via a escolher quando o aplicativo precisa estar presente na primeira inicialização em um dispositivo que talvez nunca se inscreva e talvez nunca veja uma rede. A integração ao sistema vai um nível além e coloca o aplicativo em uma partição de sistema, o que é coisa diferente de uma pré-instalação e é tratado em seção própria mais adiante. As vias gerenciadas são as mais baratas de alterar e as mais fáceis de comprovar, então a disciplina útil é justificar qualquer coisa mais pesada em vez de adotá-la por padrão; os comportamentos padrão de distribuição gerenciada, incluindo os tipos de instalação que bloqueiam o caminho de desinstalação visível ao usuário, estão documentados nas orientações da Android Management API sobre aplicativos. Todas as vias abaixo dependem do OEM e da plataforma e são confirmadas por modelo, e não presumidas a partir do nome de uma família.

Pré-instalação de aplicativo versus integração como aplicativo de sistema

Essa é a distinção que mais costuma passar sem exame, porque as duas são descritas em reuniões como “o aplicativo vem pré-instalado”. São compromissos de engenharia diferentes, com responsáveis diferentes. Uma pré-instalação é o posicionamento de um aplicativo comum de modo que ele esteja presente quando o usuário liga o dispositivo pela primeira vez. Uma integração como aplicativo de sistema muda o que o aplicativo é: sua partição, sua posição em termos de permissões, seu comportamento de desinstalação e sua relação com toda build de firmware futura. Vale separar cinco posicionamentos, e eles escalam. Um aplicativo instalado normalmente vive na área de dados, é assinado pela equipe do aplicativo, pode ser desinstalado a menos que a política bloqueie e desaparece em uma restauração de fábrica — a equipe do aplicativo responde por ele de ponta a ponta. Uma pré-instalação copiada para a área de dados na primeira inicialização, vinda de uma região de pré-instalação ou de personalização do OEM, parece idêntica para o usuário, mas é recuperada por uma restauração; a equipe do aplicativo continua respondendo pelo pacote e o OEM responde pelo posicionamento. Um aplicativo de sistema pré-instalado fica em uma partição somente leitura, como a imagem do sistema ou a imagem de produto: ao usuário não é oferecida a desinstalação, apenas a remoção de qualquer atualização posterior, e a versão de fábrica volta após uma restauração porque a partição nunca é apagada. Um aplicativo privilegiado vai ainda mais longe — colocado no diretório de aplicativos privilegiados, ele pode ter permissões que o framework não concede a um aplicativo comum, e essas permissões precisam constar na lista de permissões privilegiadas da build, um mecanismo documentado na referência da lista de permissões privilegiadas do AOSP. Quando a verificação está ativada, uma build cujo aplicativo privilegiado solicita uma permissão ausente dessa lista pode se recusar a inicializar, o que é uma falha em nível de firmware descoberta na bancada, e não um relato de problema vindo do campo. Um aplicativo assinado com a chave da plataforma é o último degrau: ele é assinado com a chave de plataforma do OEM, que o OEM controla e raramente compartilha, e que o vincula a permissões de nível de assinatura e às builds daquele fornecedor. Três consequências merecem ser ditas com todas as letras antes de alguém se comprometer. Primeira: tudo além de uma instalação comum exige participação do OEM na build — a equipe do aplicativo deixa de conseguir expedir o artefato por conta própria, e o posicionamento só está disponível na medida da disposição e do cronograma do OEM. Segunda: cada nível é revalidado a cada mudança de firmware — um patch de segurança, uma atualização de versão do Android ou uma variante regional da build reabre a pergunta sobre se o posicionamento, as permissões e a lista de permissões sobreviveram, e é por isso que a integração ao sistema é registrada como uma obrigação de manutenção, e não como uma tarefa concluída. Terceira: cada nível fecha alguma porta. Uma build assinada com a chave da plataforma amarra o aplicativo a um único fornecedor e complica qualquer migração para hardware de segunda fonte. Um posicionamento privilegiado estreita a lista de dispositivos candidatos aos fornecedores dispostos a realizar a integração e pode afetar a submissão de compatibilidade da build. E um posicionamento no sistema muda a história do rollback: um aplicativo comum é revertido publicando-se uma versão corrigida, ao passo que um posicionamento no sistema que esteja errado na imagem é corrigido por uma liberação de firmware, por um retorno à bancada ou, no pior caso, por um lote que é expedido com uma limitação conhecida anexada. A regra honesta de planejamento é manter o aplicativo no nível mais leve que atenda ao requisito, escalar apenas diante de um requisito escrito que o nível anterior comprovadamente não consiga sustentar e tratar essa escalada como uma decisão de seleção de dispositivo, e não de software — a versão mais ampla desse argumento está exposta em MDM versus ROM Android personalizada.

Pré-requisitos do pacote que decidem quais vias permanecem abertas

Antes de escolher uma via, é preciso entender o pacote, porque várias propriedades dele fecham vias silenciosamente. O nome do pacote e a identidade de assinatura precisam ser estáveis entre versões: são eles que vinculam uma atualização a uma instalação existente, e a divergência não degrada com elegância — uma atualização assinada por uma chave diferente da cópia já presente no dispositivo é recusada, de modo que uma pré-instalação assinada com uma chave de desenvolvimento pode ficar permanentemente inalcançável pelo canal de atualização de produção. As permissões de execução importam duas vezes: uma pelo que o aplicativo precisa para funcionar e outra porque uma política de device owner pode concedê-las ou negá-las silenciosamente, o que muda o que um teste de primeira execução realmente comprova. A dependência do Google Play services é uma decisão de via, e não um detalhe, já que um pacote que o pressupõe se comportará de outro modo em uma build sem ele; a comparação entre GMS e AOSP trata do que essa escolha retira. As bibliotecas nativas precisam corresponder à arquitetura de CPU do dispositivo, e um pacote compilado para apenas uma arquitetura exclui silenciosamente parte de uma lista de dispositivos candidatos. O API level de destino, as premissas de execução em segundo plano, os tipos de serviço em primeiro plano e qualquer dependência de ser o handler padrão de uma intent precisam ser verificados contra a versão exata do Android da build de destino, e não contra a versão em que o aplicativo foi desenvolvido. Nada disso é exótico; são simplesmente as propriedades que decidem se a via mais leve funciona, e cada uma custa menos para confirmar na primeira semana do que para descobrir durante uma preparação de lote. A lista completa de verificação prévia que uma equipe de aplicativo deve percorrer está no checklist de dispositivos Android prontos para aplicativos.

• Nome de pacote e identidade de assinatura estáveis entre versões e alinhados ao canal de atualização
• Permissões de execução revisadas segundo o princípio do menor privilégio e diante do que a política concede silenciosamente
• Dependência do Play services resolvida diante de um alvo GMS ou AOSP antes de fechar a lista de dispositivos candidatos
• Bibliotecas nativas compatíveis com a arquitetura de CPU do dispositivo em todos os modelos no escopo
• API level de destino, execução em segundo plano e premissas de handler padrão verificados na build exata

Quem responde pela atualização depois da entrega

A entrega é a metade fácil. A metade que decide se uma frota se mantém saudável é quem responde pela versão depois que as unidades estão em campo, e ela se desdobra em quatro perguntas concretas que pertencem a um contrato, e não a uma conversa. A primeira é a custódia da chave. Quem detém a chave de assinatura detém a capacidade de expedir qualquer atualização, porque a plataforma só aceita uma nova versão assinada pela mesma identidade da que está instalada. Se o aplicativo é distribuído por uma loja que administra a chave de assinatura em nome do publicador, o artefato entregue à fábrica para pré-instalação precisa ser aquele que a loja vai distribuir, e não uma build assinada localmente a partir do mesmo código-fonte — caso contrário, a cópia pré-instalada e a cópia da loja são dois aplicativos diferentes do ponto de vista do dispositivo, e a atualização da loja não se instalará por cima da pré-instalação. A mecânica, incluindo a diferença entre a chave de upload e a chave de assinatura e as circunstâncias estreitas em que uma chave pode ser rotacionada, está documentada no guia de assinatura de aplicativos Android. A custódia da chave também traz uma pergunta de saída anexada: se a relação com a integradora, com o OEM ou com o distribuidor terminar, quem ainda pode assinar uma versão. A segunda pergunta é a fixação da versão. Uma implantação só é reproduzível se a versão aprovada estiver registrada como version code exato e identidade de build na especificação de configuração do dispositivo, ao lado da build de firmware em que ela foi aceita. Uma especificação de configuração que nomeia um aplicativo sem fixar sua versão não fixou nada, porque o artefato vai se mover. A fixação também dá ao lote uma verificação que pode ser executada em vez de presumida: cada unidade preparada informa uma versão, e ou essa versão corresponde ao registro, ou a unidade para. A terceira pergunta é o rollback, e é a que mais costuma ser presumida em vez de projetada. No Android, um aplicativo instalado normalmente não aceita um pacote com version code menor, e o suporte a rollback existente no nível da plataforma é estreito e dependente do instalador. Na prática, fazer rollback significa publicar um version code maior que contenha o código anterior — o que só é possível se esse código anterior ainda for compilável, ainda for assinável e ainda for compatível com o estado de backend que a versão defeituosa criou. Para um aplicativo pré-instalado a situação é ainda mais difícil, porque a cópia que está na imagem não se move: reverter uma atualização devolve o dispositivo à versão de fábrica, que pode ser mais antiga do que a frota espera, e corrigir a própria imagem é um evento de firmware sujeito ao prazo do OEM. Um plano de rollback que sobrevive ao contato com a realidade nomeia o artefato, a pessoa que pode assiná-lo, o canal que o transporta, o tempo previsto para chegar a um dispositivo e o que a frota faz nesse intervalo. A quarta pergunta é aquela que se deve testar em vez de acreditar: “o aplicativo se atualiza sozinho”. Essa frase pode significar uma atualização gerenciada pela loja, uma atualização conduzida pela plataforma de gerenciamento, um atualizador dentro do próprio aplicativo que baixa o próprio pacote, ou nada em uma build sem o componente do qual esse atualizador depende. Vias de autoatualização frequentemente precisam de uma permissão de instalação que a política de device owner restringiu, de acesso de rede que uma configuração bloqueada não permite, ou de um componente de loja ausente da build de destino. Trate a frase como uma alegação com um teste anexado: na amostra aceita, na build aceita, publique uma nova versão e observe se ela chega, quanto tempo leva, se o dispositivo precisa estar desbloqueado ou acompanhado e o que acontece quando a atualização cai no meio do turno, com um usuário no meio de uma tarefa. A responsabilidade pelas atualizações também é um item de transferência, porque a frota sobrevive ao projeto: nomeie quem publica, quem aprova e quem é acionado quando uma versão dá errado.

• Custódia da chave nomeada, incluindo quem ainda pode assinar uma versão se a relação comercial terminar
• Version code exato e identidade de build fixados na especificação de configuração diante de uma build de firmware nomeada
• Rollback projetado como uma versão para a frente que contém o código anterior, com assinante, canal e tempo previsto de chegada nomeados
• Comportamento de autoatualização testado na build aceita, e não aceito como declaração de produto
• Publicador, aprovador e contato de escalonamento nomeados antes da transferência, e não depois da primeira versão ruim

Comprovar entrega e atualização na amostra com controle de versão

Uma via de entrega é uma hipótese até que uma unidade a demonstre. A amostra com controle de versão fixa o modelo e o SKU regional exatos, a versão do Android e a build de firmware, o nome de pacote, o version code e o assinante do aplicativo, a via de provisionamento e a versão da política, de modo que cada afirmação desta página fique presa a algo reproduzível, e não a uma família de dispositivos. A evidência de entrega é comportamental e parte de um dispositivo limpo: faça a restauração de fábrica da unidade, execute a via de provisionamento pretendida e cronometre quanto tempo leva até o aplicativo estar presente e utilizável sem que ninguém toque no aparelho. Depois teste os estados que realmente acontecem — um dispositivo que inicializa sem rede, um dispositivo ligado pela primeira vez semanas após a preparação, uma configuração inicial interrompida, uma unidade com pouco armazenamento e um dispositivo em que o usuário tenta remover o aplicativo. A evidência de atualização exige um segundo ato na mesma unidade: publique uma nova versão, observe-a chegando, confirme que a versão informada no dispositivo corresponde ao que foi publicado, depois volte à versão anterior pela via que o plano de rollback indica e confirme que o dispositivo continua utilizável. A evidência de remoção fecha o ciclo: bloqueie a desinstalação e então tente desinstalar pelo launcher, pelas configurações, pelas informações do aplicativo e por qualquer gerenciador de arquivos ou handler que a configuração permita, registrando o que é oferecido. Os resultados pertencem a um registro estruturado, e não a uma conversa de chat, que é a finalidade da matriz de aceitação de amostras — cenário, comportamento esperado, comportamento observado, veredito, responsável —, com tudo o que não puder ser encerrado registrado na biblioteca de limitações conhecidas, para que o aprovador veja antes de assinar. A preparação do lote então reproduz o estado aceito em vez de reinventá-lo: a mesma imagem, o mesmo pacote e version code, a mesma via de provisionamento, verificados unidade a unidade contra a amostra de referência, com uma regra de interrupção quando uma unidade destoa, conforme descrito em dispositivos Android preparados em lote antes da entrega. É por isso que os programas são cotados a partir de cerca de 500 unidades, com uma remessa piloto de vinte a cem dispositivos dentro do programa: o piloto é onde as vias de entrega e de atualização são confirmadas em condições reais, e as unidades restantes só são preparadas depois que essa evidência existe.

• Uma amostra com controle de versão fixa modelo, SKU, build de firmware, pacote, version code, assinante, via de provisionamento e versão da política
• A entrega é cronometrada a partir de um dispositivo restaurado de fábrica, pela via de provisionamento real, sem operador
• Atualização e rollback são exercitados na mesma unidade, e não apenas a primeira instalação
• A desinstalação é tentada em todas as superfícies que a configuração deixa alcançáveis, e o resultado é registrado
• A preparação do lote reproduz o estado aceito e para quando uma unidade destoa da referência

Tratamento de código e credenciais na cadeia de entrega

Preparar uma frota significa lidar com o código de outra pessoa e, muitas vezes, com as credenciais dela. Os controles são banais e mesmo assim são justamente os que costumam ser pulados. A transferência do pacote é controlada e o artefato é verificado antes de entrar em uma build ou em um fluxo de preparação, com o arquivo recebido conferido contra um checksum publicado pela equipe do aplicativo, e não contra um nome de arquivo. As contas de teste usam credenciais de menor privilégio emitidas para o projeto e revogadas na transferência, nunca segredos de produção, porque uma bancada de preparação é um ambiente compartilhado e um APK com um token de produção embutido é um problema de vida bem mais longa do que um teste que falhou. O que o aplicativo consegue alcançar no dispositivo é delimitado deliberadamente pelas permissões que ele solicita e pela política aplicada ao seu redor, e qualquer posicionamento privilegiado é justificado por escrito, e não concedido por conveniência. Essas são práticas de trabalho aplicadas e validadas durante a configuração, com os resultados registrados junto com o restante da evidência de aceitação — elas são descritas aqui como controles, não como garantia de que qualquer implantação esteja livre de risco.

• Transferência controlada do pacote, com checksum conferido contra o que a equipe do aplicativo publicou
• Credenciais de projeto de menor privilégio para contas de teste, revogadas na transferência
• Acesso do aplicativo aos dados delimitado pelas permissões solicitadas e pela política aplicada
• Posicionamento privilegiado justificado por escrito, e não concedido por conveniência

Limitações conhecidas das vias de pré-instalação

O quadro acima é uma ferramenta de planejamento, e vale dizer onde ele deixa de ser arrumado. A disponibilidade de cada via depende do OEM, da versão do Android, do EMM e do hardware o tempo todo, de modo que uma via confirmada em um modelo não está confirmada no sucessor dele nem em uma build regional diferente do mesmo modelo.

• Qualquer coisa além de uma instalação comum exige participação do OEM na build e só está disponível na medida do cronograma e da disposição desse OEM.
• Posicionamentos no sistema e privilegiados são revalidados a cada mudança de firmware, incluindo patches de segurança e variantes regionais da build.
• Uma divergência de chave de assinatura entre a cópia pré-instalada e o canal de atualização não é recuperável no lugar — o aplicativo precisa ser substituído.
• Uma restauração de fábrica apaga a área de dados: instalações gerenciadas e preparadas na bancada não sobrevivem a ela, enquanto posicionamentos em partição de sistema sobrevivem.
• As políticas de lojas e de plataformas de gerenciamento para aplicativos pré-instalados mudam com o tempo e são reverificadas a cada build, e não presumidas a partir de um programa anterior.
• Um dispositivo que nunca faz check-in mantém a versão com que foi expedido; novas versões ficam na fila e nunca chegam, e um registro antigo de último contato pode parecer um dispositivo saudável.

Decida a via antes de congelar a imagem

O momento mais barato para corrigir uma decisão de entrega é antes de a build ser congelada, porque depois disso a mesma correção passa a ser uma liberação de firmware em vez de uma publicação. Traga o requisito, e não o mecanismo preferido: se o aplicativo precisa estar presente sem rede na primeira vez em que o aparelho é ligado, se o usuário pode removê-lo, se ele precisa voltar após uma restauração de fábrica, o que ele precisa fazer que um aplicativo comum não consegue, com que frequência vai mudar, quem vai guardar a chave de assinatura e a faixa de quantidade em discussão. A Vantora traduz essas linhas em uma via de entrega e um nível de posicionamento, informa quais partes são impostas e quais apenas estão presentes, confirma a via em uma amostra com controle de versão e registra as limitações remanescentes antes de qualquer compromisso — as vias de provisionamento que levam o aplicativo até o dispositivo são comparadas em métodos de provisionamento de dispositivos Android, e o trabalho de integração em si está em Integração de aplicativo, MDM e quiosque.