Como corrigir o erro 10 do Google Sign-In no teste fechado

O escopo aqui é uma única falha: o login nativo com o Google que quebra na cópia que o Google Play entrega. O guia separa essa falha de outros erros parecidos e depois trata de frameworks, outros provedores de login e do que os testadores devem relatar. Todas as páginas do Google citadas aqui foram verificadas em 16 de outubro de 2026, e os relatos da comunidade estão identificados como tal. As fontes estão listadas no final.

Corrija o Google Sign-In no build do Play

Faça o app que seus testadores instalaram corresponder ao nome de pacote e ao SHA-1 de assinatura registrados para ele. Siga estas etapas na ordem; os caminhos do Firebase e do Google Cloud vêm em seguida.

Adicione o certificado do Play no Firebase

Selecione o app Android correspondente antes de adicionar a impressão digital de assinatura do Play. As etapas seguem a ajuda de impressões digitais do Firebase e o guia de login com o Google dele.

1. No console do Firebase, abra o projeto que o seu app usa e, depois, Project settings > General.
2. Em Your apps, selecione o app Android cujo nome de pacote corresponde ao build que está falhando.
3. Clique em Add fingerprint, cole o SHA-1 da assinatura de apps do Play e salve. Adicione-o ao lado das impressões digitais existentes, em vez de substituí-las.
4. Em Authentication > Sign-in method, confirme que o Google está ativado.
5. Se o Firebase pedir para você baixar um google-services.json atualizado, substitua o arquivo no seu projeto. O Firebase diz que o arquivo “contém as informações do cliente OAuth necessárias para o login com o Google”, então um arquivo alterado significa um novo build. Confira se o projeto e o pacote dele correspondem ao app que está falhando.

Adicione um SHA-256 apenas quando um serviço específico do Firebase pedir. A autenticação por telefone, por exemplo, usa o SHA-256 no caminho do Play Integrity; o Google Sign-In em si depende do SHA-1.

Configure o Google Cloud sem o Firebase

Dois clientes OAuth fazem dois trabalhos diferentes. O cliente Android registra o seu app; o ID do cliente Web é o que a sua solicitação de token usa.

1. Selecione o projeto que emitiu os seus IDs de cliente e abra Google Auth platform > Clients (ajuda do Google Cloud).
2. Procure um cliente Android existente com este nome de pacote e este SHA-1 antes de criar outro.
3. Se ele não existir, escolha Create Client, defina Application type como Android, informe um nome, o nome do pacote e o SHA-1 da assinatura de apps do Play e clique em Create. O formulário Android tem um campo de SHA-1; um SHA-256 não vai ali.
4. Registre cada par de pacote e certificado de que você precisa, por exemplo debug, release local e Play.
5. Deixe o cliente Web no lugar para a solicitação de token e nunca coloque uma chave secreta do cliente dentro do app.

Comprove a correção

Um único login bem-sucedido não prova que a versão está corrigida. Esta lista é o teste de aceitação que nós recomendamos, não uma regra do Google; a última linha importa porque o login de um desenvolvedor passou uma vez e ainda falhou no login seguinte, um problema de sessão que uma verificação única não pegaria.

Por que o login funciona no debug, mas falha no teste fechado?

O app instalado pelo Google Play pode ter um assinante diferente do APK que você instala localmente. O guia de autenticação do cliente do Google observa que “o Android Studio assina automaticamente o seu app com um certificado de debug”. Uma versão de release que você mesmo gera usa a chave que estiver configurada para essa variante. Com a assinatura de apps do Google Play, a sua chave de upload assina o pacote que você envia, e o Google assina com a chave de assinatura de apps os APKs que os seus testadores recebem.

Essas chaves têm funções diferentes, mas nem sempre têm valores diferentes: você pode fornecer a sua própria chave de assinatura, e algumas configurações usam uma chave para duas funções. Compare as impressões digitais reais, e não os nomes das chaves.

Leia as impressões digitais você mesmo

Para builds gerados na sua máquina, o relatório de assinatura do Gradle mostra o SHA-1 e o SHA-256 de cada variante, e o keytool lê o keystore de debug diretamente (digite a senha do keystore quando ela for pedida):

./gradlew signingReport

keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystore

Um relatório de assinatura local não diz o que assinou a cópia do Play. Para conferir o próprio build que está falhando, instale-o pelo teste fechado em um dispositivo, extraia-o com o adb e mostre os certificados dele com o apksigner, que o Google documenta como uma forma de exibir “informações sobre os certificados de assinatura do APK”. Troque o nome do pacote e use o caminho que o primeiro comando mostrar:

adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apk

Adicionei o SHA-1 e ainda falha

Compare o certificado do APK que está falhando, o ID do aplicativo final dele e os IDs de cliente antes de mudar mais configurações. Desça por esta escada; cada linha descarta uma camada.

A linha 4 não é teórica. Em um caso com Expo relatado em setembro de 2026, adicionar impressões digitais não mudou nada; a correção foi um erro de digitação no ID de cliente que o back-end aceitava.

Vários certificados de assinatura ou chaves atualizadas

Um único app pode precisar de mais de uma identidade de assinatura registrada. A ajuda atual da assinatura de apps do Google Play descreve a assinatura híbrida com três chaves de assinatura de apps e pede que você registre as impressões digitais de cada uma, e um app que fez upgrade da chave de assinatura ainda pode ter instalações assinadas por uma chave mais antiga. Registre as identidades que as suas instalações realmente têm e não apague entradas antigas que ainda funcionam. A rotação de chaves está fora do escopo deste guia e não é uma correção de login.

Outro projeto já é dono deste pacote e deste SHA-1

A ajuda sobre conflitos do Firebase diz que um par de nome de pacote e SHA-1 “precisa ser único em todos os projetos do Firebase e do Google Cloud”. Se o console recusar a sua impressão digital porque outro projeto já a tem, descubra qual projeto é dono desse cliente OAuth antes de apagar qualquer coisa. O suporte do Google pode ajudar a localizar o conflito; não remova clientes ou projetos ativos tentando adivinhar a solução.

O erro 10 é o mesmo que 12500, 12501 ou canceled?

Não. Leia o erro exato e a biblioteca que o gerou antes de tratar todo login que falha como um único problema. A referência de códigos de status comuns do Google define DEVELOPER_ERROR = 10 como “O aplicativo está configurado incorretamente.” Os outros códigos abaixo vêm do SDK histórico play-services-auth 21.6.0 do Google.

Google Sign-In legado e Credential Manager

As notas da versão do Google Play Services registram a descontinuação das APIs do Google Sign-In no play-services-base em 16 de abril de 2024, e o Google anunciou a migração para o Credential Manager em 11 de setembro de 2024. As APIs foram então removidas do play-services-auth 22.0.0 em 26 de agosto de 2026 e do play-services-base 18.11.0 em 17 de setembro de 2026, com a nota “Removed the APIs related to Google Sign-in” (as APIs relacionadas ao Google Sign-In foram removidas). Essa é uma mudança no SDK; ela não estabelece uma data de desligamento para apps já instalados. Código novo e upgrades devem seguir o guia de migração do Google.

As duas APIs falham de formas diferentes. O Credential Manager não tem erro 10; o guia de solução de problemas dele avisa que “um volume alto de "cancelamentos" pode, na verdade, indicar uma configuração incorreta”. Então um cancelamento pode ser uma falha de configuração ou um cancelamento real, e NoCredentialException é mais um sinal diferente.

Verificações para Flutter, React Native, Expo e Unity

As verificações de identidade nativa acima valem para todos os frameworks, mas a configuração, a inicialização e a configuração de build mudam. Use o caminho do seu framework e a versão da biblioteca que o seu app realmente resolve.

Para React Native, os mantenedores da biblioteca oferecem uma verificação de configuração que você pode rodar na raiz do projeto:

npx @react-native-google-signin/config-doctor

O que muda para Supabase, Facebook, Apple ou Auth0?

O provedor e o fluxo de login decidem qual certificado, ID de cliente ou callback precisa corresponder. Um SHA-1 do Google é a resposta para o login nativo com o Google; para outros provedores, ele pode ser o hash errado, o formato errado ou irrelevante.

O que os testadores devem enviar ao desenvolvedor?

Um relatório útil identifica o build do Play que está falhando e o ponto exato em que o login para. Um testador não consegue consertar um registro OAuth tentando de novo, então o trabalho dele é reunir evidências, e não insistir. Copie este modelo e envie aos seus testadores:

App e link de teste do Play:
Versão ou build do app instalado:
Instalado por: teste fechado do Play / outro caminho
Dispositivo e versão do Android:
Data, hora e fuso horário:
Texto exato do erro ou uma captura de tela com dados ocultos:
Onde parou: antes do seletor de contas / depois de escolher uma conta / depois de voltar ao app
Outro método de login conseguiu abrir o app?
Resultado e versão do novo teste:

Peça aos testadores que continuem participando do teste enquanto você corrige o problema. Nunca peça senhas, tokens OAuth, chaves privadas ou acesso ao Play Console. Depois da sua mudança, peça ao mesmo testador que abra um recurso que exige login, saia e entre de novo, e anote a versão e o resultado.

O erro 10 afeta o meu teste fechado ou o acesso de produção?

Um erro de configuração de login é separado da participação no teste. O erro 10 não é um código de recusa por política do Play, e nenhuma regra do Google que encontramos diz que ele reinicia o período de participação dos seus testadores. A página de requisitos de teste do Google incentiva você a melhorar o app durante o teste fechado, então mantenha os testadores participando e envie a correção para a mesma faixa fechada. Essa é uma leitura das regras publicadas, e não uma promessa que cubra todos os casos.

Um login quebrado ainda importa. A política de funcionalidade do Google Play diz que “não permitimos apps que travam, forçam o fechamento, congelam ou funcionam de forma anormal”, e uma barreira de login impede que os testadores cheguem aos recursos que deveriam testar. Corrija isso antes de solicitar o acesso de produção e forneça aos revisores dados de login que funcionem. Se uma análise já voltou, veja a recusa por funcionalidade quebrada (Broken Functionality).

Para contexto: contas pessoais de desenvolvedor criadas após 13 de novembro de 2023 precisam de no mínimo 12 testadores participando continuamente há 14 dias antes de solicitar o acesso de produção para aquele app. Depois que você solicita, o Google diz: “Esse processo geralmente leva até sete dias, mas pode demorar um pouco mais.” Se faltam testadores na contagem, confira como eles foram convidados antes de mexer no login.

Perguntas frequentes

Resumo final

Os rótulos de menu do Play Console e do Firebase são os fatos que mudam mais rápido nesta página. Se um caminho acima não corresponder mais ao seu console, procure a assinatura de apps do Play em Protected with Play e as impressões digitais no seu app Android, nas configurações do projeto do Firebase.