Um cliente instala a sua aplicação, inicia sessão e encontra uma mensagem a dizer que o telemóvel não é suportado. O aparelho funciona. O cliente é real. Algures entre a instalação e o servidor, uma regra de segurança tomou uma decisão que o suporte terá agora 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 numa 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 destes controlos 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 aplicações a aceitem. Visão geral do AOSP.
A verificação de programadores associa uma identidade a aplicações registadas. O Play Integrity fornece sinais sobre uma aplicação e o ambiente em que funciona. Depois, o responsável pela aplicação decide o que o utilizador pode fazer. Identificar quem desenvolve, reconhecer o pacote e aceitar o dispositivo são perguntas diferentes.
Pense num evento: identificar a organização, conferir o bilhete e decidir quem entra numa sala reservada são controlos separados. Passar num não resolve automaticamente os restantes. 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, Singapura 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 aplicação. Anúncios antigos e formulações mais amplas noutras páginas podem tornar esta distinção menos evidente. Lojas participantes; Perguntas frequentes sobre a implementação.
A Google também documenta um percurso avançado para instalar aplicações não verificadas, a manutenção da instalação por ADB e contas de distribuição limitada. Estas permitem partilhar aplicações com até 20 dispositivos autorizados, sem documento de identificação oficial nem taxa de registo. 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 a aplicação com outra chave. A Google documenta o registo dessa assinatura e uma opção de percurso avançado para aplicações não registadas. Cada projeto deve verificar o seu canal real, em vez de presumir que o registo numa loja abrange todos os binários. Guia para aplicações de código aberto.
O que o Play Integrity permite saber
O Play Integrity pode devolver informação sobre reconhecimento da aplicação, 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 telemóvel. A 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. A 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 enganadora e uma má política de suporte. Risco de acesso e acessibilidade.
O argumento de segurança e o custo de governação
A Google apresenta a verificação de identidade como uma forma de dificultar abusos repetidos: retirar uma aplicação maliciosa não deveria permitir ao mesmo operador regressar imediatamente com uma identidade anónima nova. Esta é a justificação 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 da Google.
Em setembro de 2025, o F-Droid argumentou que o registo central colocaria em risco a distribuição independente e a privacidade dos programadores. É 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 controlo 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 numa indisponibilidade e que utilizadores legítimos ficam excluídos faz parte de avaliar a segurança.
Seis perguntas antes de bloquear utilizadores
1. Que ação está a proteger? 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 recolha e retenção proporcionais. Separe falta de informação, erros temporários e resultados explicitamente adversos. Caso contrário, uma indisponibilidade pode parecer uma vaga 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 desenho, 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 da aplicação 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. Registe 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 deteção, uma integração avariada ou uma regra demasiado abrangente. O número, sozinho, não demonstra sucesso.
Um exemplo pequeno, sem regra universal
Imagine uma aplicação de retalho fictícia. Consultar o catálogo tem pouco risco; reclamar repetidamente um desconto de novo cliente tem outro. A equipa 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 mau. É 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 a precisar de alguém que atenda o intercomunicador.
Está a planear uma aplicação Android? Inclua canais de distribuição, dispositivos suportados e tratamento de falhas no âmbito inicial. Conheça o desenvolvimento mobile da Zephyrus.