Android 17 ganha verificação de build e ledger de apps Google
A checagem começa em Pixels e informa se o sistema é uma build oficial e amplamente distribuída. Um ledger separado cobre software Google de produção.
O Google anunciou em 12 de maio uma checagem do Android 17 capaz de informar se o aparelho executa uma build oficial e amplamente distribuída do sistema. Chamada Android OS verification, a função começa em dispositivos Pixel. O anúncio também apresentou um ledger público para confirmar a procedência de aplicativos Google de produção.¹
As duas ferramentas respondem a perguntas diferentes. A primeira oferece ao dono do aparelho uma informação sobre a build do sistema. O ledger registra hashes criptográficos de binários que o Google declara ter publicado. Android Verified Boot já verifica a cadeia de software durante a inicialização, enquanto attestation pode comunicar parte desse estado a um serviço externo.
O Android 17 chegou à maioria dos Pixels compatíveis em 16 de junho.⁹ O Google ainda não publicou uma lista específica de modelos com OS verification, o caminho completo da interface ou um calendário para outras fabricantes. A disponibilidade documentada permanece “inicialmente em Pixels”.¹
O aviso novo classifica a procedência da build
O anúncio descreve o resultado da checagem em duas condições: a build precisa ser oficial e ter distribuição ampla. A captura de tela publicada pelo Google mostra um aviso de build oficial, mas a empresa não detalha quais sinais alimentam a decisão nem como uma pessoa inicia a consulta.¹
Esse limite importa para sistemas alternativos. Uma ROM construída a partir do AOSP, assinada por outro projeto e instalada deliberadamente pode ficar fora da classificação usada pelo Google. O resultado informa procedência dentro dos critérios anunciados; não determina sozinho se uma ROM é maliciosa, segura ou adequada ao usuário.
Também não há documentação que transforme OS verification numa auditoria de todo o código da imagem. Uma build reconhecida continua sujeita a bugs e vulnerabilidades. A checagem ajuda a encontrar versões modificadas que se apresentam como uma distribuição oficial, sem substituir atualizações de segurança ou análise técnica do software.
Nos Pixels, o recurso se junta a uma infraestrutura anterior. Pixel Binary Transparency mantém um registro criptográfico público de metadados das factory images lançadas pelo Google. Uma prova de inclusão permite verificar que a imagem corresponde a uma versão publicada; a prova de consistência mostra que entradas antigas não foram alteradas quando o registro cresceu.⁸ O próprio material técnico ressalva que os metadados não atestam a integridade do processo de build e release.
O ledger de apps registra versões destinadas ao público
O segundo anúncio cobre aplicativos Google de produção em Android, incluindo Google Play services e APIs fundamentais do GMS. Para versões lançadas depois de 1º de maio de 2026, o Google publica uma entrada criptográfica correspondente. Um aplicativo cuja última atualização ocorreu antes dessa data pode não aparecer.²
Na documentação do Google Product Application Transparency, cada entrada contém o hash SHA-256 do APK completo, o tipo do hash, o nome do pacote e o versionCode. O hash funciona como uma impressão digital do arquivo: qualquer mudança no APK produz outro valor. Uma prova de inclusão permite comparar a cópia instalada ou recebida com a versão que o Google marcou como destinada ao público.³
A assinatura digital e o ledger cobrem etapas relacionadas. Uma assinatura válida associa o binário à chave usada pelo desenvolvedor. O registro acrescenta uma declaração verificável de intenção de publicação para aquela versão específica. Isso pode revelar um APK assinado com uma chave comprometida que nunca entrou no fluxo oficial de produção.² ³
O log usa uma árvore de Merkle, estrutura que resume todas as entradas num hash raiz. Novos itens podem ser acrescentados sem que alterações ou remoções anteriores passem despercebidas. Os dados são públicos e consultáveis. A documentação informa que uma rede padronizada de testemunhas independentes ainda está planejada e incentiva terceiros a monitorar a consistência do registro.³ ⁴
“Binary Transparency” é o nome do conjunto de projetos do Google, não de um catálogo universal. A página geral separa registros para firmware Pixel, alguns APKs de sistema Google, aplicativos Google e módulos Android Mainline.⁴ O ledger anunciado não cobre aplicativos de outros desenvolvedores, todos os apps instalados nem todo o código de uma build Android.
A correspondência entre o hash do arquivo e a entrada no ledger confirma que o binário é o que o Google declarou como versão de produção. Ela não garante ausência de vulnerabilidades, não avalia as decisões do aplicativo e não prova que o código-fonte publicado gerou exatamente aquele arquivo. O sistema torna versões inesperadas detectáveis dentro do escopo coberto.
Verified Boot protege outra parte do caminho
Android Verified Boot opera durante a inicialização. A cadeia começa numa raiz de confiança protegida por hardware e verifica o bootloader, a partição de boot e outras partições, como system e vendor, antes de entregar a execução à etapa seguinte. O mecanismo também aplica rollback protection para impedir o retorno silencioso a versões antigas em condições protegidas.⁵
Essa verificação é local e depende da raiz de confiança aceita pelo aparelho. O AOSP prevê um estado para dispositivos bloqueados que usam uma chave configurada pelo usuário e outro para bootloader desbloqueado. Portanto, Verified Boot consegue validar uma cadeia assinada com uma raiz alternativa sem afirmar que ela pertence a uma distribuição oficial do Google.⁶
Key attestation pode expor a uma parte externa informações verificáveis sobre esse estado. Os campos documentados incluem a chave de Verified Boot, o estado do bloqueio, o resultado da verificação e o digest protegido.⁷ Serviços usam declarações desse tipo para decidir quanta confiança concedem a uma solicitação.
O Google não publicou uma arquitetura que identifique OS verification como uma camada construída apenas sobre Verified Boot ou attestation. A distinção segura vem do que cada documentação promete: integridade da cadeia local no boot, comunicação criptográfica do estado e reconhecimento de uma build amplamente distribuída são afirmações separadas.
Fontes
- What’s New in Android Security and Privacy in 2026 · Google Security Blog · https://blog.google/security/whats-new-in-android-security-privacy-2026/ · 12 maio 2026
- Evolving Verifiable Trust: Bringing Binary Transparency to the Android Ecosystem · Google Security Blog · https://blog.google/security/bringing-binary-transparency-to-the-android-ecosystem/ · 4 maio 2026
Mostrar mais 7 fontesOcultar fontes
- Google Product Application Transparency · Google for Developers · https://developers.google.com/android/binary_transparency/google_apk/overview · atualização 1º maio 2026
- Binary Transparency · Google for Developers · https://developers.google.com/android/binary_transparency/overview · atualização 1º maio 2026
- Verified Boot · Android Open Source Project · https://source.android.com/docs/security/features/verifiedboot · acesso em 26 ago. 2026
- Boot flow · Android Open Source Project · https://source.android.com/docs/security/features/verifiedboot/boot-flow · atualização 17 jun. 2026
- Key and ID attestation — schema · Android Open Source Project · https://source.android.com/docs/security/features/keystore/attestation#schema · acesso em 26 ago. 2026
- Pixel Binary Transparency: verifiable security for Pixel devices · Google Security Blog · https://security.googleblog.com/2023/08/pixel-binary-transparency-verifiable.html · 4 ago. 2023
- Android 17 is here · Android Developers Blog · https://android-developers.googleblog.com/2026/06/Android-17.html · 16 jun. 2026