Resumo
Crie uma verificação Gradle que use o applicationId final e a assinatura do artefato, sem pacote de debug fixo.
Para quem: Engenheiros Android que mantêm vários product flavors ou muitas variantes.
Etapas do lançamento
- Resolva applicationId da variante de release selecionada.
- Execute a consulta somente depois de assinar o artefato de produção.
- Extraia o SHA-256 do certificado com as ferramentas Android.
- Emita um resultado pequeno para CI sem expor credenciais.
Informações-chave
Use a variante final como fonte. Um package de debug fixo pode produzir uma resposta válida para a identidade errada.
Orientação detalhada
Resolva os valores da variante selecionada
Builds Android modernos podem ter vários applicationIds e configurações de assinatura. Vincule uma tarefa exclusiva de release à variante selecionada e ao artefato assinado, sem manter outra lista fixa de identidades.
Mantenha a chamada de rede fora das tarefas normais de compilação e teste. Exporte pacote e impressão como um artefato pequeno e deixe o CI chamar a API de forma protegida.
- Não executar em todo build de debug.
- Não presumir que namespace é igual a applicationId.
- Não usar a configuração de assinatura de debug no release.
./gradlew assembleRelease
apksigner verify --print-certs app/build/outputs/apk/release/app-release.apkInforme o nome de produção e, para conferir a assinatura, o SHA-256 do certificado do APK entregue aos usuários. A consulta não substitui a análise da loja.
Verificar status →Perguntas frequentes
Por que não consultar em todo build Gradle?
Builds locais de debug não precisam da chamada, podem representar a variante errada e consomem quota. Use uma etapa controlada antes do release.
Como representar os flavors?
Use o applicationId final e o certificado do artefato assinado daquela variante específica.
Fontes e revisão
Última revisão: