Checklist de dispositivos Android prontos para aplicativos para equipes de SaaS e software

Resposta curta

Este checklist ajuda equipes de SaaS e software a decidir se as evidências de um dispositivo pronto para aplicativos realmente existem antes de comprometer um lote. Neste guia, “pronto para aplicativos” é um termo de projeto da Vantora, não uma certificação do Google ou do Android. A equipe do projeto precisa conectar os mecanismos separados de compatibilidade, permissões, distribuição, gerenciamento e atualização do Android a um fluxo real em uma compilação exata. Entregue como um programa e não como uma checklist, é isso que dispositivos Android com marca própria e prontos para aplicativos cobre.

Instalado não é o mesmo que pronto para o aplicativo

Um teste de instalação comprova que um pacote pode chegar ao dispositivo testado pela via testada. Não comprova a jornada operacional. O Android define a compatibilidade do aplicativo em relação a uma versão específica da plataforma e observa que alterações na plataforma podem afetar os aplicativos; portanto, valide as compilações de destino do Android e do firmware — consulte as orientações sobre compatibilidade de aplicativos do Android.

Registre a base antes dos testes

Não aprove “a versão do Android” nem “o APK” de forma abstrata. Crie um registro da compilação para a amostra de referência. No mínimo, registre o modelo exato e o SKU regional do dispositivo, as compilações do Android e do firmware, o pacote e a versão do aplicativo, a origem da assinatura, a via de distribuição, o modo de gerenciamento, a versão da política, os periféricos, as premissas de rede, os mercados-alvo e a data dos testes. Quando o aplicativo incluir voz ou vídeo em tempo real, amplie essa linha de base com o perfil de chamada e as evidências da amostra no guia de hardware Android para videochamadas WebRTC.

Como testar a compilação em um dispositivo candidato

A maioria dos checklists diz o que verificar e deixa o método implícito, e é aí que a avaliação erra silenciosamente: os testes são executados, são aprovados e comprovam menos do que a equipe acredita. Comece pela via de instalação, porque ela muda o significado de todos os resultados seguintes. Durante a avaliação, um engenheiro normalmente envia a compilação por adb a partir de uma estação de trabalho com a depuração USB ativada, e essa é uma forma razoável de iterar rapidamente sobre um defeito funcional. Não é a via que a frota vai usar. Uma instalação gerenciada conduzida por um controlador de políticas do dispositivo acontece sem nenhum usuário presente, possivelmente antes de alguém fazer login, sob as restrições que a política já aplica, e com a instalação atribuída ao canal gerenciado, e não a uma sessão local. O conjunto de restrições de produção é a parte que pega as equipes de surpresa: uma política que proíbe a instalação a partir de fontes desconhecidas, ou que bloqueia a depuração USB ou a instalação de aplicativos por completo, fecha a via da qual a avaliação dependia — de modo que o pacote que instalou sem problemas em uma unidade de bancada não tem caminho algum até um dispositivo de produção. Teste a via gerenciada no candidato antes de considerar o aplicativo instalável e reserve o sideload para iterações de depuração que sejam testadas novamente depois. O modelo das vias de entrega está exposto em pré-instalar aplicativos em dispositivos Android em escala; o ponto aqui é mais restrito — a via usada para executar um teste faz parte do resultado desse teste. Em seguida, confirme a arquitetura que está realmente sendo entregue. Os dispositivos informam uma ABI primária e uma secundária, comumente arm64-v8a com suporte a 32 bits onde a plataforma ainda o oferece, e a documentação de ABI do Android descreve como as bibliotecas nativas de um pacote são associadas ao dispositivo. Falhas de ABI errada raramente parecem falhas de ABI: ou a instalação é recusada porque nenhum código nativo corresponde, ou a instalação é bem-sucedida porque o pacote por acaso traz uma pasta de bibliotecas utilizável e o aplicativo morre mais tarde, com um erro de carregamento de biblioteca nativa, na primeira vez em que o scanner, o pipeline da câmera ou o módulo de criptografia é acionado. Se o aplicativo é distribuído como Android App Bundle, o APK universal que um testador instala por sideload e o split que um canal gerenciado gera para aquele dispositivo específico não são o mesmo artefato; portanto, registre qual deles foi testado e concilie isso com o que a frota vai receber. Os limites de versão merecem o mesmo literalismo. Os níveis mínimo e de destino da API declarados no manifesto decidem tanto a elegibilidade quanto o comportamento: um candidato que executa uma versão do Android abaixo do mínimo declarado é filtrado para fora de um canal gerenciado em vez de receber uma mensagem de erro, e o sintoma é um dispositivo que simplesmente nunca recebe a atribuição, enquanto o nível de destino seleciona quais comportamentos de compatibilidade da plataforma se aplicam. O Google também impõe um requisito contínuo de nível de API de destino para novos envios, de modo que uma compilação interna mais antiga pode ser perfeitamente testável e ainda assim não ser publicável pelo canal que o programa pretende usar. Depois, teste a compilação que a frota vai receber, não a que o desenvolvedor tem aberta. Uma compilação de depuração difere da candidata a versão de maneiras que escondem falhas reais: uma chave de assinatura diferente, o sinalizador debuggable ativado, redução e ofuscação de código reduzidas ou ignoradas, registro detalhado mantido e — uma surpresa tardia frequente — as substituições de depuração da configuração de segurança de rede ativas, de modo que um certificado interno ou autoassinado que funcionou durante toda a avaliação para de funcionar na versão assinada. A redução de código traz sua própria classe de defeito, já que reflexão, serialização e injeção de dependências costumam quebrar apenas depois que a ofuscação é aplicada. A identidade de assinatura importa então para além da primeira instalação, porque a aceitação das atualizações depende dela; defina a custódia da assinatura, descrita em assinatura de aplicativos, antes de a amostra ser aceita, e não depois. Execute tudo isso no SKU regional exato que será encomendado. Uma mesma família de modelos pode compartilhar um nome comercial entre números de modelo que diferem em bandas de rádio, faixa de memória, software pré-instalado, canal de firmware, conjunto de idiomas padrão e, em alguns mercados, na presença ou não dos serviços do Google — uma unidade parecida emprestada de um colega é um bom dispositivo para encontrar defeitos e um péssimo dispositivo de aceitação. Por fim, registre os mesmos campos em todas as execuções, ou os resultados não poderão ser comparados depois: modelo e número do modelo do dispositivo, impressão digital da compilação e nível de patch de segurança, nome do pacote com nome e código da versão, resumo do certificado de assinatura, via de instalação, versão da política em vigor, testador e data, além dos artefatos brutos — um extrato de log em torno de cada falha, uma gravação do fluxo de trabalho e qualquer registro de falha grave ou de ANR. É esse conjunto que permite que um resultado de teste se torne uma linha da matriz de aceitação e que a preparação em lote reproduza as condições testadas, em vez de aproximá-las.

O que um teste de mesa esconde: execução em segundo plano e política de energia

Um teste de dez minutos em um dispositivo ligado à tomada e com a tela acesa exercita quase nada do comportamento da plataforma que decide se o aplicativo ainda funciona ao final de um turno. O Android restringe ativamente o que um dispositivo ocioso permite: o Doze e o app standby adiam o trabalho em segundo plano, os alarmes e o acesso à rede quando o dispositivo está fora da tomada, parado e no escuro, liberando-os em janelas de manutenção, e os grupos de standby de aplicativos reduzem a frequência com que um aplicativo pouco usado pode ser executado. Um dispositivo no carregador nunca entra nesse estado, que é exatamente por isso que o teste de mesa passa. O protocolo de avaliação, portanto, precisa forçá-lo: desconecte a unidade da tomada, bloqueie-a, deixe-a por um turno realista e, durante as iterações de engenharia, coloque o dispositivo deliberadamente no estado ocioso e em um grupo de standby restritivo, em vez de esperar que a plataforma chegue lá sozinha. O trabalho de longa duração também precisa de um mecanismo que a plataforma respeite. Um serviço em primeiro plano é visível ao usuário e, nas versões recentes do Android, precisa declarar um tipo de serviço com a permissão correspondente e ser iniciado em condições que a plataforma permita; o trabalho adiável pertence a tarefas agendadas; e os alarmes exatos ficam restritos às categorias de aplicativo que se qualificam para eles. Um aplicativo construído em torno de uma thread comum em segundo plano e de um alarme exato pode se comportar bem por uma semana na bancada e depois perder a sincronização noturna em toda a frota. As isenções de otimização de bateria são a parte que mais se presume em vez de verificar. Uma isenção muda o modo como a plataforma trata o aplicativo, mas obtê-la é uma questão de política, e não uma configuração do aplicativo: em um dispositivo não gerenciado, ela passa por uma solicitação visível ao usuário, enquanto em um dispositivo totalmente gerenciado ou dedicado um EMM pode conseguir aplicá-la — e camadas separadas de gerenciamento de energia do OEM podem se sobrepor ao comportamento da plataforma e encerrar aplicativos segundo regras que a documentação do Android não descreve. Essas camadas dependem do OEM, do modelo e do firmware, e precisam ser confirmadas no candidato, não deduzidas da documentação da plataforma. Duas consequências decorrem disso para a implantação. Primeira: a isenção de que o aplicativo depender precisa fazer parte da versão da política que a preparação em lote aplica; caso contrário, a amostra é aprovada com uma isenção que um testador configurou manualmente e o lote é enviado sem ela, que é a diferença habitual entre um dispositivo que funciona e uma frota. Segunda: essa dependência pertence à biblioteca de limitações conhecidas, com um gatilho de revalidação, porque uma atualização de firmware pode alterar o comportamento do gerenciamento de energia sem que nada mude no aplicativo. O mesmo raciocínio vale para tudo o mais que um testador configurou manualmente na amostra: se não está na base registrada, não existe no lote.

• Carregado e ligado à tomada — o dispositivo nunca entra no estado ocioso em que o trabalho em segundo plano é adiado.
• Tela acesa e desbloqueada — sem bloqueio de tela, sem rebaixamento de standby, sem a temporização das janelas de manutenção.
• Opções do desenvolvedor e depuração USB ativadas — um estado que a política de produção normalmente não permite.
• Wi-Fi forte, tokens recentes e um banco de dados local vazio — nada disso descreve a oitava hora de um turno.
• Isenções e configurações aplicadas manualmente em uma unidade — ausentes do lote, a menos que a política as aplique.

1. Verifique o fluxo real do aplicativo

Um benchmark genérico de dispositivo não responde a essas perguntas. O hardware deve ser escolhido em torno da tarefa que o aplicativo executa, e não de um número de destaque de processador ou de memória.

• O usuário principal, a tarefa, o ambiente e o resultado de sucesso estão definidos.
• Há caminhos representativos de login, tenant, função e recuperação de conta disponíveis para teste.
• Os comportamentos online, com rede fraca, offline, de sincronização e de sessão interrompida estão cobertos quando relevantes.
• As interações necessárias com câmera, NFC, código de barras, impressora, scanner, dock, Bluetooth ou USB estão listadas.
• As premissas de backend, certificado, VPN, domínio, horário, localização ou API estão registradas.

2. Verifique o hardware exato e a variante de mercado

Estes são insumos de viabilidade, não afirmações universais de produto. Compare as vias de mercado convencional, robusta ou de OEM mais aprofundada com os requisitos antes de comprometer uma quantidade.

• Tela, memória, armazenamento, arquitetura de CPU, câmera, sensores e portas atendem ao fluxo de trabalho.
• Bateria, carregamento, acessórios, montagem e necessidades ambientais são realistas para o turno de operação.
• O SKU regional exato — não apenas a família de modelos — está registrado.
• Bandas celulares, compatibilidade com a operadora, certificações, obrigações do importador e premissas sobre os países-alvo têm responsáveis nomeados.
• A disponibilidade do modelo, a via de substituição e o ciclo de vida provável são adequados ao programa.

3. Verifique a entrega do aplicativo e a identidade da versão

Escolha a via de entrega deliberadamente: Google Play gerenciado, uma pré-instalação acordada ou a preparação controlada de APK. Elas não são intercambiáveis. O Google documenta que o Google Play gerenciado pode instalar aplicativos por meio de política de dispositivo e restringir um aplicativo privado a uma única empresa — consulte a documentação de distribuição gerenciada de aplicativos. Isso é útil em implantações gerenciadas com suporte, mas não torna a mesma via disponível em toda compilação AOSP, sem GMS, de OEM ou não gerenciada.

• O nome do pacote, o código da versão, o canal de lançamento e o responsável pela assinatura estão registrados.
• A via selecionada funciona a partir do estado de dispositivo limpo previsto.
• A visibilidade do aplicativo privado e a atribuição de tenant estão corretas quando se usa o Google Play gerenciado.
• Falha de instalação, download interrompido e reinstalação têm um caminho de suporte definido.
• O lote de produção receberá o mesmo pacote e a mesma via aprovados.

4. Verifique a primeira execução, as permissões e a configuração

Um aplicativo pode instalar sem problemas e falhar na primeira solicitação de permissão. Nas versões modernas compatíveis, o Android exige que as permissões perigosas sejam solicitadas em tempo de execução, e o aplicativo precisa tratar uma negação em vez de presumir o acesso — teste a sequência real de solicitações, a justificativa, a concessão, a negação e o comportamento de recuperação descritos no fluxo de permissões em tempo de execução do Android. Para a configuração remota, confirme que o aplicativo expõe e consome os campos necessários: as orientações sobre configurações gerenciadas do Android atribuem ao aplicativo a responsabilidade de definir o próprio esquema, e um EMM não pode inventar campos não suportados.

• A primeira inicialização chega à tela prevista sem etapas manuais não documentadas.
• As permissões necessárias são solicitadas em contexto e as permissões negadas falham de forma segura.
• As configurações de conta, tenant, idioma, região, certificado e endpoint estão corretas.
• Os cenários de reinicialização, reabertura, logout, expiração de token e redefinição acordada são testados.
• Nenhuma credencial de produção, chave de assinatura ou dado desnecessário de cliente está embutido na compilação.

5. Verifique o gerenciamento, o quiosque e os limites do usuário

Primeiro decida se o dispositivo é de propriedade pessoal, corporativo com uso misto, totalmente gerenciado ou dedicado. Na Android Management API, o token de inscrição e o método de provisionamento estabelecem a propriedade e o modo de gerenciamento — consulte a documentação de provisionamento do Google. Outras arquiteturas de EMM podem diferir; portanto, verifique a plataforma selecionada em vez de copiar uma política de exemplo. O exemplo de política para dispositivo dedicado do Google pode iniciar automaticamente um aplicativo de quiosque designado na inicialização; é um exemplo de implementação, não uma promessa universal de controle.

• A inscrição se repete a partir do estado previsto de restauração de fábrica ou de dispositivo limpo.
• A atribuição de aplicativos, a política, as restrições, as configurações de rede e os relatórios chegam ao tenant e ao grupo corretos.
• Os requisitos de aplicativo único, múltiplos aplicativos, launcher personalizado, lista de permissão e acesso do suporte são explícitos.
• Reinicialização, bloqueio, desbloqueio, redefinição, atualização de política e rotas de saída inaceitáveis são testados.
• A equipe de suporte tem um caminho de recuperação que não depende de uma senha desconhecida nem de uma etapa oculta de configuração.

6. Verifique atualizações, recuperação e controle de mudanças

A primeira versão é apenas o começo do programa de dispositivos. O Android aceita a atualização de um aplicativo somente quando as condições de identidade e de assinatura são satisfeitas: o ID do aplicativo precisa coincidir, o certificado de assinatura precisa coincidir ou usar uma prova de rotação válida, e a condição de versão precisa ser atendida — revise as regras de atualização de aplicativos do Android antes de mudar de canal de distribuição ou de custódia da assinatura. As orientações de atualização da Android Management API do Google descrevem os modos padrão condicional, de alta prioridade e de adiamento para aplicativos gerenciados; eles não controlam as versões de firmware do OEM.

• A responsabilidade pelo lançamento do aplicativo, a custódia da assinatura, a aprovação e o momento da implantação estão documentados.
• O comportamento de lançamento normal, urgente e escalonado do canal escolhido é compreendido.
• Os cenários de atualização com falha, atualização interrompida, migração de dados e recuperação são testados quando relevantes.
• Mudanças de firmware, aplicativo, backend, política e periféricos têm gatilhos de revalidação.
• “Rollback” não é prometido a menos que o canal exato e o modelo de dados do aplicativo sustentem uma via de recuperação testada.

7. Verifique a aceitação da amostra

Converta cada expectativa crítica em um critério de aprovação, método de teste, resultado observado, referência da evidência, responsável e decisão. Use Aprovado, Condicional, Reprovado ou Não aplicável apenas quando o significado estiver definido. A Matriz de aceitação da amostra é uma estrutura útil, mas quem decide o que é suficiente para a liberação é a autoridade nomeada do projeto, não o modelo.

• A amostra aceita está fisicamente identificada e vinculada ao seu registro de compilação.
• Os fluxos de trabalho críticos do usuário são aprovados na configuração exata da amostra.
• Os itens condicionais indicam dependência, impacto, responsável, condição de encerramento e se o trabalho de lote pode prosseguir.
• Os itens críticos reprovados bloqueiam a liberação até que uma autoridade nomeada aprove um novo caminho.
• Capturas de tela, logs, gravações, registros do console ou notas de inspeção sustentam os resultados relevantes quando apropriado.

8. Verifique a preparação do lote e a transferência

A preparação transforma a amostra aceita em um lote controlado — e a transferência decide se a equipe receptora consegue de fato operá-lo.

• As unidades de produção são preparadas a partir da base aceita de aplicativo, firmware, política e configuração.
• Os registros de número de série, IMEI, patrimônio, local, tenant, SIM/APN, acessórios, etiqueta, caixa e exceções são capturados conforme aplicável.
• O QA compara o lote com a amostra de referência e inclui uma regra de interrupção para desvios relevantes.
• As instruções de ativação, substituição, garantia, suporte, escalonamento e novo pedido estão prontas.
• A equipe receptora sabe quais ações permanecem no local e qual estado já deve existir na chegada.

Atribua responsabilidades antes do piloto

O que segue é um modelo de planejamento, não um contrato universal. Confirme cada linha na matriz de responsabilidades do projeto real. A página de parceria para empresas de aplicativos e SaaS da Vantora descreve o escopo de entrega relacionado.

Libere o lote apenas quando as evidências se conectarem

O dispositivo está pronto para o lote acordado quando a base exata está registrada, os cenários críticos foram aprovados, os itens condicionais têm responsáveis, o processo de preparação reproduz a amostra e as regras de suporte e de controle de mudanças são utilizáveis. A prontidão expira quando uma mudança relevante invalida essas evidências. É esse limite mais amplo de evidências que faz com que pronto para MDM não seja o mesmo que pronto para implantação — a inscrição pode ser necessária sem ser suficiente. Conectar as camadas de hardware, aplicativo, política, validação e entrega é o trabalho de coordenação de uma integradora de implantação de dispositivos Android. A pergunta prática é: este aplicativo, dispositivo, caminho de gerenciamento e fluxo operacional exatos podem ser aceitos e repetidos nas condições-alvo?