Como pré-instalar aplicativos em dispositivos Android em escala
Um passo a passo prático de como um aplicativo chega à frota antes do primeiro uso — da pré-instalação em fábrica à implantação gerenciada — para que você escolha a via adequada ao seu software e ao tamanho do lote.
- Publicado
- Atualizado
Quatro maneiras de entregar um aplicativo antes do primeiro uso
Existem algumas vias distintas para colocar seu software em um dispositivo, e elas não são equivalentes. A pré-instalação em fábrica grava o aplicativo na compilação antes do envio da unidade; um aplicativo de sistema fica em uma partição protegida com privilégios elevados; o Managed Google Play envia o aplicativo durante a inscrição; e a preparação de APK deixa os pacotes prontos para instalação durante o provisionamento. A opção adequada depende de o dispositivo executar GMS, do nível de controle necessário e de como a frota é inscrita.
- Pré-instalação em fábrica — o aplicativo é incorporado à imagem do firmware no momento da compilação
- Aplicativo de sistema — instalado em uma partição protegida com privilégios elevados
- Managed Google Play — o aplicativo é entregue durante a inscrição por meio de um EMM
- Preparação de APKs — os pacotes APK são preparados e instalados no provisionamento da primeira inicialização
Pré-instalação em fábrica versus implantação gerenciada
A maneira mais clara de comparar as vias é observar onde o aplicativo fica e quem pode alterá-lo. A pré-instalação em fábrica coloca o aplicativo na imagem do firmware, para que esteja presente na primeira inicialização, mas a via de atualização passa então pelo firmware, e não por uma loja. Uma implantação gerenciada instala o aplicativo após a inscrição por meio de um DPC e um EMM, o que mantém a via de atualização independente da compilação e transforma a remoção em uma decisão de política. Cada via depende do OEM e da plataforma e está sujeita à validação técnica no dispositivo escolhido.
- Pré-instalação em fábrica: presente na primeira inicialização; via de atualização vinculada à imagem do firmware
- Implantação gerenciada: instalado pelo DPC após a inscrição, com atualizações no modelo de loja
- Sob gerenciamento, a remoção é uma decisão de política; na pré-instalação, é uma decisão da compilação
- A combinação adequada depende do dispositivo, do EMM e da cadência de atualizações necessária
Assinatura, permissões e dependências do APK
Antes de planejar qualquer pré-instalação, é preciso compreender o próprio pacote. O nome do pacote e a chave de assinatura devem ser estáveis, pois vinculam as atualizações ao mesmo aplicativo e determinam se ele pode ocupar uma posição privilegiada ou de sistema. As permissões em tempo de execução, qualquer dependência do Play Services, as bibliotecas nativas e a arquitetura de CPU de destino influenciam onde e como o aplicativo pode ser instalado. Tratamos esses itens como pré-requisitos técnicos a confirmar desde o início, e não como premissas, pois cada um precisa ser validado no hardware real.
- Nome do pacote e chave de assinatura estáveis e vinculados entre versões
- Permissões em tempo de execução analisadas segundo o princípio do menor privilégio
- Dependências do Play Services verificadas em relação a um destino GMS ou AOSP
- Bibliotecas nativas compatíveis com a arquitetura de CPU do dispositivo
Distribuição e atualizações de aplicativos privados
Um aplicativo pré-instalado raramente permanece inalterado; por isso, a via de manutenção é tão importante quanto a primeira instalação. Um aplicativo privado pode ser distribuído sem uma listagem pública, com o código da versão orientando a lógica de atualização, uma implantação em etapas limitando a exposição e uma via de reversão pronta caso uma compilação apresente falhas. O canal de atualização e a titularidade do aplicativo são acordados antes da produção, deixando claro quem fornece novas compilações e como elas chegam à frota. Esses mecanismos podem ser configurados para MDM/EMM e são confirmados na implantação durante a validação.
- Distribuição de aplicativo privado sem listagem em uma loja pública
- O código da versão orienta a detecção e a ordem das atualizações
- Implantação em etapas e via de reversão testada para novas compilações
- Canal de atualização e titularidade do aplicativo acordados antes da produção do lote
Testes antes da produção do lote
Nenhuma via de pré-instalação deve chegar a uma rodada de produção sem testes. Um teste de compatibilidade na versão do sistema operacional (OS) e no firmware escolhidos verifica se o aplicativo é instalado, iniciado e se comporta como esperado, enquanto condições de rede, fluxos de login e eventuais periféricos são exercitados no dispositivo real. O resultado é um registro de aceitação que documenta o que foi verificado e todas as limitações conhecidas. É nessa etapa de teste conforme a especificação que as premissas são detectadas antes de se multiplicarem pelo lote.
- Teste de compatibilidade com a versão do sistema operacional (OS) e a compilação do firmware de destino
- Comportamento de rede, login e periféricos exercitado no dispositivo real
- Limitações conhecidas documentadas, em vez de descobertas em campo
- Registro de aceitação assinado antes de o lote seguir para a produção
Segurança e tratamento de dados
Gerenciar um aplicativo para uma frota exige cuidado com o código e as credenciais. A transferência do APK é controlada, e o pacote passa por uma verificação antimalware antes de entrar no fluxo de compilação ou preparação; todas as contas de teste usam credenciais com o menor privilégio, e nunca segredos de produção. A proteção de dados é tratada como prática de trabalho, não como consideração tardia, para que o acesso do aplicativo no dispositivo seja definido deliberadamente. Essas medidas descrevem as práticas que aplicamos e validamos, e não garantias absolutas.
- Transferência controlada do APK, com verificação antimalware antes do uso
- Contas de teste com credenciais de menor privilégio, nunca segredos de produção
- Acesso do aplicativo aos dados definido deliberadamente no dispositivo
- Práticas de tratamento de dados validadas como parte da compilação, e não presumidas
Perguntas frequentes
Os usuários podem desinstalar um aplicativo pré-instalado?
Depende de como o aplicativo foi entregue. Um aplicativo de sistema pré-instalado em fábrica pode ser difícil de remover, e uma implantação gerenciada pode bloquear a desinstalação por meio de uma política de device owner em hardware compatível; as duas opções dependem do OEM e da plataforma e são confirmadas durante a validação.
Um aplicativo pré-instalado pode iniciar automaticamente após a primeira inicialização?
O comportamento de inicialização automática pode ser configurado para MDM/EMM e, no caso de um aplicativo de sistema, definido na compilação; porém, as restrições do Android a atividades em segundo plano e ao uso da bateria variam conforme a versão do sistema operacional (OS) e o OEM. O comportamento exato está sujeito à validação técnica no dispositivo-alvo.
O que acontece com o aplicativo após uma restauração de fábrica?
Um aplicativo incorporado à imagem do firmware normalmente retorna após uma restauração de fábrica porque faz parte da compilação, enquanto um aplicativo implantado por gerenciamento é reinstalado durante a inscrição quando o dispositivo é provisionado novamente; a via aplicável depende do OEM e da plataforma.
Os aplicativos podem ser atualizados offline?
É possível organizar vias de atualização compatíveis com uso offline — por exemplo, APKs preparados e aplicados durante o provisionamento ou um canal de atualização local —, mas uma atualização gerenciada por uma loja geralmente exige conectividade; a abordagem viável para sua implantação é confirmada durante a validação.
Conte seu fluxo de trabalho e suas regras.
Transformamos requisitos em dispositivos prontos para implantação.