Um cliente instala seu aplicativo, entra na conta e encontra uma mensagem dizendo que o celular não é suportado. O aparelho funciona. O cliente é real. Em algum ponto entre a instalação e o servidor, uma regra de segurança tomou uma decisão que o suporte agora terá de explicar.
É um bom ponto de partida para discutir o Android. Prevenir fraude é importante. Poder instalar software e utilizar um dispositivo que nos pertence também. Compreender os mecanismos permite discutir as duas coisas sem transformar cada decisão técnica em uma discussão aos gritos.
Este artigo reflete a documentação consultada em 8 de outubro de 2026. Os detalhes da implementação podem mudar. Distinguimos o comportamento documentado, as posições das partes interessadas e a nossa análise de engenharia. Não afirmamos ter medido a eficácia real desses controles na Zephyrus.
Três camadas que convém distinguir
O AOSP disponibiliza o código-fonte do Android. O Google Play e os Google Mobile Services pertencem a um ecossistema mais amplo, com condições próprias de participação e licenciamento. Poder criar uma variante do Android não garante que todos os serviços ou aplicativos a aceitem. Visão geral do AOSP.
A verificação de desenvolvedores associa uma identidade a aplicativos registrados. O Play Integrity fornece sinais sobre um aplicativo e o ambiente em que funciona. Depois, o responsável pelo aplicativo decide o que o usuário pode fazer. Identificar quem desenvolve, reconhecer o pacote e aceitar o dispositivo são perguntas diferentes.
Pense em um evento: identificar a organização, conferir o ingresso e decidir quem entra em uma sala reservada são controles separados. Passar em um não resolve automaticamente os demais. A analogia é nossa; explica a diferença, não o protocolo do Android.
O que mudou em setembro de 2026
O calendário atual começa em 30 de setembro de 2026, em lojas participantes no Brasil, Indonésia, Cingapura e Tailândia, em dispositivos certificados com Android 7 ou posterior. A expansão mais ampla está prevista para 2027. É uma implementação regional e por canal, não uma proibição mundial de instalação direta. Calendário atual.
A lista inclui Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore e GetApps. As perguntas frequentes atuais esclarecem que outras lojas e a instalação direta estão fora desta fase inicial de fiscalização. Anúncios antigos e formulações mais amplas em outras páginas podem tornar esta distinção menos evidente. Lojas participantes; Perguntas frequentes sobre a implementação.
O Google também documenta um percurso avançado para instalar aplicativos não verificados, a manutenção da instalação por ADB e contas de distribuição limitada. Estas permitem compartilhar aplicativos com até 20 dispositivos autorizados, sem documento de identificação oficial nem taxa de registro. Continuam a exigir dados de conta: dispensar o documento não significa distribuição anônima. Requisitos da distribuição limitada.
A distribuição de código aberto tem uma questão prática própria: a plataforma pode recompilar e assinar o aplicativo com outra chave. O Google documenta o registro dessa assinatura e uma opção de percurso avançado para aplicativos não registrados. Cada projeto deve verificar o seu canal real, em vez de presumir que o registro em uma loja abrange todos os binários. Guia para aplicativos de código aberto.
O que o Play Integrity permite saber
O Play Integrity pode retornar informações sobre reconhecimento do aplicativo, licença no Play e integridade do dispositivo, além de sinais opcionais de outros riscos. Os resultados têm critérios definidos. A ausência de um resultado não é uma biografia de quem segura o celular. O Google recomenda combinar sinais e compreender o público antes de impor restrições. Orientações do Play Integrity.
A distinção importa em dispositivos modificados ou antigos. A integridade básica é diferente das verificações mais exigentes. A partir do Android 13, a integridade forte também considera atualizações de segurança recentes. Um cliente pode ficar fora de uma política exigente devido às atualizações do aparelho, sem ter tentado cometer fraude. Esta é uma interpretação dos critérios, não uma garantia de segurança desse dispositivo. Definições dos resultados.
A acessibilidade merece atenção particular. O Google documenta uma exclusão de determinados sinais de risco para serviços de acessibilidade verificados. Isso é mais específico do que dizer que qualquer ferramenta de acessibilidade está automaticamente excluída. Mandar remover indiscriminadamente software de apoio seria uma mensagem enganosa e uma má política de suporte. Risco de acesso e acessibilidade.
O argumento de segurança e o custo de governança
O Google apresenta a verificação de identidade como uma forma de dificultar abusos repetidos: retirar um aplicativo malicioso não deveria permitir ao mesmo operador voltar imediatamente com uma identidade anônima nova. Esta é a justificativa do fornecedor. Verificar a identidade não é auditar o código, e a documentação não mede, por si só, quanta fraude o programa evita. Explicação do Google.
Em setembro de 2025, o F-Droid argumentou que o registro central colocaria em risco a distribuição independente e a privacidade dos desenvolvedores. É a posição de um projeto afetado, escrita sobre uma proposta anterior. Documenta as suas preocupações; não prova que o F-Droid tenha deixado de funcionar com a implementação atual. Posição datada do F-Droid.
A nossa avaliação é que ambas as questões operacionais merecem escrutínio. Um controle pode encarecer o abuso e, ao mesmo tempo, acrescentar burocracia, custos de suporte e dependência de uma entidade central. Perguntar quem pode recorrer, o que acontece em uma indisponibilidade e que usuários legítimos ficam excluídos faz parte de avaliar a segurança.
Seis perguntas antes de bloquear usuários
1. Que ação está protegendo? Consultar uma página de ajuda, usar uma promoção e alterar dados sensíveis de uma conta têm riscos diferentes. Escreva a política para a ação antes de escolher um nível de integridade.
2. O que acontece antes de impor a regra? Observe os sinais do público atual, com coleta e retenção proporcionais. Separe falta de informação, erros temporários e resultados explicitamente adversos. Caso contrário, uma indisponibilidade pode parecer uma onda de fraude.
3. Que respostas graduais fazem sentido? Conforme a ameaça, poderá avaliar uma nova tentativa, uma confirmação adicional, uma operação limitada ou uma recusa. São opções de projeto, não uma instrução universal para permitir acesso quando a verificação falha.
4. A mensagem ajuda a resolver o problema? “Não conseguimos verificar este pedido; tente novamente” e “Esta versão do aplicativo não é suportada” descrevem situações diferentes. Dê ao suporte uma referência útil, sem expor tokens ou dados pessoais desnecessários.
5. Foram previstos os casos incômodos? Inclua um dispositivo suportado, uma atualização de segurança antiga, um canal alternativo legítimo, ferramentas de acessibilidade e uma falha da API. Registre o resultado esperado antes de testar. É uma proposta de teste, não um relatório de testes realizados por nós.
6. Como vai rever o compromisso? Acompanhe separadamente abuso confirmado, reclamações legítimas e recuperação do acesso. Mais bloqueios podem significar melhor detecção, uma integração com defeito ou uma regra abrangente demais. O número, sozinho, não demonstra sucesso.
Um exemplo pequeno, sem regra universal
Imagine um aplicativo fictício de varejo. Consultar o catálogo tem pouco risco; solicitar repetidamente um desconto de novo cliente tem outro. A equipe poderia estudar verificações mais exigentes nessa operação, mantendo acessível a informação pública dos produtos. Pagamentos e recuperação de conta exigiriam avaliações próprias. Um único interruptor de “permitir ou recusar tudo” esconderia estas diferenças.
A pergunta útil não é apenas se o Play Integrity é bom ou ruim. É se um sinal sustenta uma decisão concreta, se o cliente consegue recuperar de um erro e se a política continua proporcional enquanto o ecossistema muda. Uma porta de segurança continua precisando de alguém que atenda o interfone.
Está planejando um aplicativo Android? Inclua canais de distribuição, dispositivos suportados e tratamento de falhas no escopo inicial. Conheça o desenvolvimento mobile da Zephyrus.