Respuesta rápida
El error 10 de Google Sign-In, DEVELOPER_ERROR, significa que la app de Android está mal configurada. Si el inicio de sesión funciona en local pero falla en una prueba cerrada de Play, comprueba que el SHA-1 de firma de la app instalada desde Play y su nombre de paquete final estén registrados en el proyecto correcto de Firebase o Google Cloud, y que cualquier serverClientId o webClientId sea el ID de cliente de la aplicación web, no el de Android. Después vuelve a probar con la versión instalada desde Google Play.
Elige tu configuración
¿Ya agregaste el SHA-1? Ve a qué revisar después.
Esta guía cubre una sola falla: el inicio de sesión nativo con Google que se rompe en la copia que entrega Google Play. La separa de otros errores que se parecen y luego repasa frameworks, otros proveedores de inicio de sesión y lo que deben reportar los testers. Cada página de Google citada aquí se verificó el 16 de octubre de 2026, y los reportes de la comunidad están marcados como tales. Las fuentes aparecen al final.
En esta página
Corrige Google Sign-In en la versión de Play
Haz que la app que instalaron tus testers coincida con el nombre de paquete y el SHA-1 de firma registrados para ella. Sigue estos pasos en orden; las rutas de Firebase y de Google Cloud vienen después.
Confirma qué copia está fallando
Comprueba que el tester instaló la app desde tu prueba cerrada en Google Play y anota la versión que tiene. Después anota el ID de aplicación final de esa compilación. La guía de compilación de Android dice que el ID de aplicación lo define la propiedad applicationId, que puede ser distinta del namespace de tu código fuente o recibir un sufijo en una variante de producto (flavor). Si el tester no puede instalar la app en absoluto, el problema es otro: consulta por qué una app no está disponible para los testers.
Abre la firma de apps de Play
En Play Console, abre la app y ve a Protected with Play. Google trasladó la firma de apps ahí en mayo de 2026, y su propia ayuda nombra el siguiente paso de dos maneras (tabla de abajo). Cualquiera de las dos rutas termina en la misma página.
| Ruta tal como la escribe Google | Dónde la usa Google | Qué abrir ahí |
|---|---|---|
| Protected with Play > Play Store distribution > Go to Play app signing | Dónde la usa GoogleAyuda de Play Console, Usar la firma de apps de Play, sección de registro de API | Qué abrir ahíApp signing key certificate y luego el valor SHA-1 |
| Protected with Play > Play Store protection > Manage Play app signing | Dónde la usa GoogleLas notas de la actualización de mayo de 2026 de Google Play y otra sección de la misma página de ayuda | Qué abrir ahíLa misma página; las etiquetas del menú pueden variar entre cuentas |
Copia el SHA-1 de la clave de firma de apps
Abre la sección App signing key certificate (certificado de la clave de firma de apps), no la del certificado de la clave de subida, y copia su SHA-1. Si Play muestra más de una clave de firma para tu app, registra cada huella digital que corresponda (consulta varios certificados de firma). Conserva tus huellas de debug y locales y agrega las de Play junto a ellas. No rotes tu clave de firma para corregir el inicio de sesión.
Regístralo donde tu app inicia sesión
Usa la ruta de Firebase o la ruta de Google Cloud, según la que use tu app, y usa el mismo proyecto que emitió los ID de cliente que lleva tu app.
Vuelve a probar la versión instalada desde Play
Si solo cambiaste un registro en Firebase o Google Cloud, vuelve a intentarlo con la copia ya instalada desde Play antes de compilar nada; algunos desarrolladores han reportado que una corrección solo de registro funcionó sin subir una versión nueva. Si cambiaste la configuración incluida en la app, un ID de cliente, código o una dependencia, sube una compilación nueva al mismo canal de pruebas cerrado (en la consola en español de Latinoamérica, “segmento de pruebas”) y prueba esa. Google no publica un plazo fijo para que una huella nueva surta efecto, así que vuelve a probar en lugar de esperar una cantidad fija de horas.
Agrega el certificado de Play en Firebase
Selecciona la app de Android correspondiente antes de agregar su huella de firma de Play. Los pasos siguen la ayuda de Firebase sobre huellas digitales y su guía de inicio de sesión con Google.
- En Firebase console, abre el proyecto que usa tu app y luego Project settings > General (Configuración del proyecto).
- En Your apps (Tus apps), selecciona la app de Android cuyo nombre de paquete coincide con la compilación que falla.
- Haz clic en Add fingerprint (Agregar huella digital), pega el SHA-1 de la firma de apps de Play y guarda. Agrégalo junto a las huellas existentes en lugar de reemplazarlas.
- En Authentication > Sign-in method, confirma que Google está habilitado.
- Si Firebase te pide descargar un
google-services.jsonactualizado, reemplaza el archivo en tu proyecto. Firebase dice que el archivo “contiene la información del cliente OAuth necesaria para el inicio de sesión con Google”, así que un archivo cambiado implica una compilación nueva. Comprueba que su proyecto y su paquete coincidan con la app que falla.
Agrega un SHA-256 solo cuando un servicio concreto de Firebase lo pida. La autenticación por teléfono, por ejemplo, usa SHA-256 para su ruta de Play Integrity; Google Sign-In en sí depende del SHA-1.
Configura Google Cloud sin Firebase
Dos clientes OAuth hacen dos trabajos distintos. El cliente de Android registra tu app; el ID de cliente web es el que usa tu solicitud de token.
| Tipo de cliente | Qué contiene | Dónde lo usas |
|---|---|---|
| Android | Qué contieneTu nombre de paquete y el SHA-1 del certificado de firma | Dónde lo usasRegistra la identidad de la app nativa. Este ID de cliente no se pega en serverClientId. |
| Aplicación web | Qué contieneEl ID de cliente web | Dónde lo usasEl serverClientId o webClientId de tu solicitud de token, y la audiencia que acepta tu backend. El codelab de Acceder con Google lo describe como el que actúa “como cliente de backend para el servicio de Google Sign-In.” |
- Selecciona el proyecto que emitió tus ID de cliente y abre Google Auth platform > Clients (ayuda de Google Cloud).
- Busca un cliente de Android existente con este nombre de paquete y este SHA-1 antes de crear otro.
- Si no existe, elige Create Client, configura Application type como Android, escribe un nombre, el nombre de paquete y el SHA-1 de la firma de apps de Play, y luego Create. El formulario de Android tiene un campo SHA-1; un SHA-256 no va ahí.
- Registra cada par de paquete y certificado que necesites, por ejemplo debug, release local y Play.
- Deja el cliente web en su lugar para la solicitud de token, y nunca pongas un secreto de cliente dentro de la app.
Comprueba que la reparación funciona
Un inicio de sesión exitoso no prueba que la versión esté corregida. Esta lista es la prueba de aceptación que recomendamos, no una regla de Google; la última fila importa porque el inicio de sesión de un desarrollador funcionó una vez y aun así falló en el siguiente intento, un problema de sesión que una sola comprobación no habría detectado.
| Comprobación | Evidencia de que pasa | Si falla |
|---|---|---|
| App y versión correctas | Evidencia de que pasaEl tester confirma la instalación de Play y la compilación previstas | Si fallaResuelve primero la entrega de la versión o del canal |
| Primer inicio de sesión | Evidencia de que pasaAl elegir una cuenta, la app vuelve con la sesión iniciada | Si fallaCaptura la excepción exacta y usa la tabla de errores de abajo |
| Función protegida | Evidencia de que pasaEl tester puede usar una función que requiere iniciar sesión | Si fallaRevisa cómo manejan el token la app y el backend |
| Cerrar sesión y volver a entrar | Evidencia de que pasaUn segundo inicio de sesión funciona sin reinstalar | Si fallaInvestiga el manejo de la sesión y del cierre de sesión del proveedor |
| Dispositivo afectado antes | Evidencia de que pasaEl mismo tester y el mismo dispositivo ahora funcionan | Si fallaCompara el certificado, el sistema operativo, la cuenta y la compilación real |
| Continuidad de la prueba | Evidencia de que pasaEl tester sigue habiendo aceptado participar y registraste la corrección | Si fallaCorrige la inscripción por separado del inicio de sesión |
¿Por qué el inicio de sesión funciona en debug pero falla en la prueba cerrada?
La app instalada a través de Google Play puede tener un firmante distinto del APK que instalas en local. La guía de autenticación del cliente de Google señala que “Android Studio firma automáticamente tu app con un certificado de debug.” Una versión release que compilas tú usa la clave con la que esté configurada esa variante. Con Play App Signing, tu clave de subida firma el paquete que subes, y Google firma con la clave de firma de apps los APK que reciben tus testers.
Esas claves cumplen funciones distintas, pero no siempre tienen valores distintos: puedes aportar tu propia clave de firma, y algunas configuraciones usan una sola clave para dos funciones. Compara las huellas reales en lugar de los nombres de las claves.
| Copia instalada | Certificado que hay que revisar | Primera acción |
|---|---|---|
| Instalación de Play desde pruebas internas, cerradas, abiertas o producción con Play App Signing | Certificado que hay que revisarEl certificado o los certificados de firma de apps de Play, en Protected with Play | Primera acciónRegistra cada SHA-1 de Play que corresponda |
| Ejecución de debug desde Android Studio | Certificado que hay que revisarEl certificado de debug de esa computadora | Primera acciónRegistra ese SHA-1 para el ID de aplicación correspondiente |
| APK release compilado en tu equipo | Certificado que hay que revisarEl certificado configurado para esa variante release | Primera acciónNo supongas que “release” significa el firmante de Google |
| Enlace de compartición interna de apps | Certificado que hay que revisarEl certificado de prueba propio de la compartición interna de apps | Primera acciónRegístralo por separado si los testers usan esa vía |
La compartición interna de apps no son las pruebas internas
La ayuda de compartición interna de apps de Google dice: “Cada APK se vuelve a firmar con este certificado de prueba.” Lo encuentras en Test and release > Internal testing > Internal app sharing > Uploaders and testers > Internal test certificate. Los canales de pruebas internas y de pruebas cerradas usan en cambio tu clave de firma de apps de Play.
Lee las huellas digitales tú mismo
Para las compilaciones de tu equipo, el informe de firma de Gradle muestra el SHA-1 y el SHA-256 de cada variante, y keytool lee directamente el keystore de debug (escribe la contraseña del keystore cuando te la pida):
./gradlew signingReport
keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystoreUn informe de firma local no te dice qué firmó la copia de Play. Para revisar la propia compilación que falla, instálala desde la prueba cerrada en un dispositivo, extráela con adb e imprime sus certificados con apksigner, que según la documentación de Google muestra “información sobre los certificados de firma del APK.” Reemplaza el nombre de paquete y usa la ruta que imprime el primer comando:
adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apkAgregué el SHA-1 y sigue fallando
Compara el certificado del APK que falla, su ID de aplicación final y los ID de cliente antes de cambiar más ajustes. Recorre esta escalera de arriba abajo; cada fila descarta una capa.
| Comprobación | Qué comparar | Decisión |
|---|---|---|
| 1. Copia instalada y canal | Qué compararLa instalación real de Play del tester frente a la versión que querías probar | DecisiónUn informe de firma local no prueba cuál es el firmante de Play |
| 2. Certificado | Qué compararLa salida de apksigner verify --print-certs sobre el APK de Play que falla frente a lo que registraste |
DecisiónRegistra cada firmante necesario; conserva las entradas antiguas que todavía sirven a usuarios con la app instalada |
| 3. ID de aplicación final | Qué compararEl applicationId de la variante compilada, incluidos los sufijos de flavor, frente al paquete registrado | DecisiónEl namespace del código fuente no cuenta |
| 4. Proyecto y cliente web | Qué compararEl proyecto y el ID de cliente web que usan de verdad tu versión release y tu backend | DecisiónUn error de tipeo aquí rompe el inicio de sesión aunque las huellas sean correctas |
| 5. El proveedor y los clientes existen | Qué compararGoogle habilitado como proveedor, más los clientes de Android y web que lo respaldan | DecisiónSi otro proyecto reclama el par, consulta la nota sobre conflictos de abajo |
| 6. Familia de error | Qué compararCódigo nativo 10, una cancelación de Credential Manager, un rechazo del token en el backend o una discrepancia de redirección en el navegador | DecisiónCada una es una rama distinta; consulta la tabla de errores |
| 7. Problema del framework en release | Qué compararLa reducción de recursos, la versión de la biblioteca que se resuelve y la inicialización | DecisiónGuíate por changelogs y correcciones confirmadas, no por actualizaciones o regresiones de versión al azar |
La fila 4 no es teórica. En un caso de Expo reportado en septiembre de 2026, agregar huellas no cambió nada; la solución fue corregir un error de tipeo en el ID de cliente que aceptaba el backend.
Varios certificados de firma o claves actualizadas
Una misma app puede necesitar más de una identidad de firma registrada. La ayuda actual de Play App Signing de Google describe la firma híbrida con tres claves de firma de apps y te pide registrar las huellas de cada una, y una app que actualizó su clave de firma todavía puede tener instalaciones firmadas con una anterior. Registra las identidades que llevan de verdad tus instalaciones y no borres entradas antiguas que siguen funcionando. La rotación de claves queda fuera del alcance de esta guía, y no es una solución para el inicio de sesión.
Otro proyecto ya tiene este paquete y este SHA-1
La ayuda sobre conflictos de Firebase dice que un par de nombre de paquete y SHA-1 “debe ser único en todos los proyectos de Firebase y Google Cloud.” Si la consola rechaza tu huella porque otro proyecto la tiene, averigua qué proyecto es dueño de ese cliente OAuth antes de borrar nada. El soporte de Google puede ayudarte a localizar el conflicto; no elimines clientes ni proyectos activos para resolverlo a ciegas.
¿El error 10 es lo mismo que 12500, 12501 o canceled?
No. Lee el error exacto y la biblioteca que lo produjo antes de tratar cada inicio de sesión fallido como un mismo problema. La referencia de códigos de estado comunes de Google define DEVELOPER_ERROR = 10 como “La aplicación está mal configurada.” Los demás códigos de abajo vienen del SDK histórico play-services-auth 21.6.0 de Google.
| Lo que ves | Qué significa | Siguiente paso |
|---|---|---|
ApiException: 10 o DEVELOPER_ERROR |
Qué significaError de configuración de la app | Siguiente pasoCompara el firmante, el paquete, el proyecto y los ID de cliente |
12500 |
Qué significaSIGN_IN_FAILED: “Se produjo un error de inicio de sesión no recuperable” |
Siguiente pasoLee los registros de alrededor; no lo trates como el error 10 |
12501 |
Qué significaSIGN_IN_CANCELLED: “Acción de inicio de sesión cancelada” |
Siguiente pasoAverigua si el usuario canceló y qué API lo produjo |
canceled de Credential Manager o de Flutter |
Qué significaUna cancelación real o un problema de configuración | Siguiente pasoRevisa los detalles de la excepción y la configuración; deja que el usuario haga un nuevo intento después de diagnosticar |
NoCredentialException |
Qué significaNo se devolvió ninguna credencial; no es un diagnóstico de certificado | Siguiente pasoRevisa la disponibilidad de cuentas y la configuración de la solicitud, además del registro |
| El token de Google funciona, el backend lo rechaza | Qué significaUna etapa posterior a la obtención de la credencial de Google | Siguiente pasoRevisa la audiencia y los ID de cliente que acepta tu backend |
redirect_uri_mismatch |
Qué significaUna redirección OAuth en el navegador no coincide con un URI autorizado | Siguiente pasoCorrige la configuración de callback de ese flujo |
| “Item not found” (artículo no encontrado) en el enlace de Play | Qué significaUn problema de instalación o de elegibilidad, no de inicio de sesión | Siguiente pasoSigue las comprobaciones para una app no disponible |
Google Sign-In heredado y Credential Manager
Las notas de la versión de Play services de Google registran la baja de las API de Google Sign-In en play-services-base el 16 de abril de 2024, y Google anunció el paso a Credential Manager el 11 de septiembre de 2024. Después, las API se eliminaron de play-services-auth 22.0.0 el 26 de agosto de 2026 y de play-services-base 18.11.0 el 17 de septiembre de 2026, con la nota “Se eliminaron las API relacionadas con Google Sign-in.” Es un cambio del SDK; no fija una fecha de cierre para las apps ya instaladas. El código nuevo y las actualizaciones deben seguir la guía de migración de Google.
Las dos API fallan de forma distinta. Credential Manager no tiene error 10; su guía de solución de problemas advierte que “un volumen alto de "cancelaciones" puede indicar en realidad un error de configuración.” Así que una cancelación puede ser un fallo de configuración o una cancelación real, y NoCredentialException es otra señal distinta.
Comprobaciones para Flutter, React Native, Expo y Unity
Las comprobaciones de identidad nativa de arriba aplican a cualquier framework, pero la configuración, la inicialización y la configuración de compilación cambian. Usa la ruta de tu framework y la versión de la biblioteca que tu app resuelve de verdad.
| Framework | Comprobaciones específicas | No supongas |
|---|---|---|
| Flutter | Comprobaciones específicasLa implementación de Android, google_sign_in_android, pasó a Credential Manager en la 7.0.0. Pasa el ID de cliente web como serverClientId. Su changelog de la 7.2.16 “evita que los reductores de recursos eliminen el recurso default_web_client_id”, algo que importa en las fallas que solo ocurren en release. |
No supongasQue cada resultado canceled sea un problema de SHA, o que bajar de versión sea una solución universal. |
| React Native | Comprobaciones específicasIdentifica qué API de la biblioteca usas, pasa el ID de cliente web como webClientId y revisa el applicationId real y el APK que falla. La guía de solución de problemas incluye “El inicio de sesión no funciona al descargar desde Play Store” y ofrece un comando para revisar la configuración (abajo). |
No supongasQue un issue cerrado en el tracker demuestre una reparación. |
| Expo | Comprobaciones específicasEl inicio de sesión nativo con Google necesita una compilación de desarrollo o personalizada; la guía de Expo dice: “Estas bibliotecas no se pueden usar en Expo Go porque requieren código nativo personalizado.” Mantén separado el certificado de firma de EAS o local del certificado de firma de apps de Play. | No supongasQue Expo Go reproduzca el flujo de release, o que recompilar corrija un ID de cliente de backend equivocado. |
| Unity | Comprobaciones específicasDecide si usas Firebase Authentication o Unity Authentication, obtén el token de ID de Google mediante la integración de plataforma compatible y luego intercámbialo con ese backend (guía de Unity de Firebase). El antiguo ejemplo de inicio de sesión para Unity de Google se archivó el 19 de abril de 2026. | No supongasQue el inicio de sesión de Play Games y el inicio de sesión con cuenta de Google sean la misma integración. |
Para React Native, los mantenedores de la biblioteca ofrecen una revisión de configuración que puedes ejecutar desde la raíz del proyecto:
npx @react-native-google-signin/config-doctor¿Qué cambia con Supabase, Facebook, Apple o Auth0?
El proveedor y el flujo de inicio de sesión deciden qué certificado, ID de cliente o callback tiene que coincidir. Un SHA-1 de Google es la respuesta para el inicio de sesión nativo con Google; para otros proveedores puede ser el hash equivocado, el formato equivocado o no importar en absoluto.
| Proveedor o flujo | Qué debe coincidir | Dónde configurarlo |
|---|---|---|
| Google nativo con Firebase | Qué debe coincidirEl paquete instalado y su SHA-1, el cliente web y Google habilitado como proveedor | Dónde configurarloLas huellas de Project settings en Firebase, más Authentication |
| Google nativo con Supabase | Qué debe coincidirLa identidad nativa de Android y el ID de cliente web; la guía de Supabase dice: “El ID de cliente web es el que se usa en tu app de Android.” | Dónde configurarloLos clientes de Android y web de Google y luego los ajustes del proveedor Google en Supabase |
| OAuth de Supabase en el navegador | Qué debe coincidirEl cliente web, el callback de Supabase y el enlace de retorno de tu app | Dónde configurarloLos URI de redirección autorizados en Google y los ajustes de redirección de Supabase; una corrección de SHA no aplica |
| Facebook en Android | Qué debe coincidirUn hash de clave en Base64 generado a partir de los bytes del SHA-1 del certificado de firma, no el hexadecimal separado por dos puntos | Dónde configurarloAjustes de la app en Facebook, hashes de clave de Android (ruta según la guía de Facebook de Expo) |
| Inicio de sesión web de Apple en Android | Qué debe coincidirEl Services ID, el dominio y la URL de retorno | Dónde configurarloLa configuración web de Sign in with Apple de Apple; no es el mecanismo DEVELOPER_ERROR de Google |
| Apple a través de Firebase en Android | Qué debe coincidirLa configuración de Apple más el SHA-1 de la app | Dónde configurarloLa guía de Apple de Firebase: “Especifica la huella digital SHA-1 de tu app si aún no lo has hecho.” |
| Auth0 en Android | Qué debe coincidirLas URL de callback permitidas y el esquema de la app; la identidad de App Links donde se use | Dónde configurarloLos ajustes de la aplicación en Auth0; su readme del SDK de Android usa hashes de clave SHA-256 para configurar App Links |
| Autenticación por teléfono de Firebase | Qué debe coincidirSHA-256 para Play Integrity, SHA-1 para la alternativa con reCAPTCHA | Dónde configurarloAutenticación por teléfono de Firebase: un flujo distinto del inicio de sesión con Google |
No muevas el inicio de sesión a un WebView
Pasar el inicio de sesión con Google por un WebView incrustado no es una solución alternativa. Las políticas de OAuth 2.0 de Google dicen que los desarrolladores “no deben dirigir una solicitud de autorización de Google OAuth 2.0 a un agente de usuario incrustado.”
¿Qué deben enviarle los testers al desarrollador?
Un informe útil identifica la versión de Play que falla y el punto exacto en el que se detiene el inicio de sesión. Un tester no puede reparar un registro de OAuth reintentando, así que su trabajo es aportar evidencia, no insistir. Copia esta plantilla y envíasela a tus testers:
App y enlace de la prueba en Play:
Versión o compilación instalada:
Instalada desde: prueba cerrada de Play / otra vía
Dispositivo y versión de Android:
Fecha, hora y zona horaria:
Texto exacto del error o captura de pantalla con datos ocultos:
Dónde se detuvo: antes del selector de cuentas / después de elegir una cuenta / después de volver a la app
¿Otro método de inicio de sesión pudo abrir la app?
Resultado y versión de la nueva prueba:Pide a los testers que sigan participando en la prueba mientras lo corriges. Nunca pidas contraseñas, tokens de OAuth, claves privadas ni acceso a Play Console. Después de tu cambio, pide al mismo tester que abra una función que requiera iniciar sesión, que cierre sesión y vuelva a entrar, y que anote la versión y el resultado.
¿El error 10 afecta a tus pruebas cerradas o al acceso a producción?
Un error de configuración del inicio de sesión es algo aparte de la inscripción. El error 10 no es un código de rechazo por políticas de Play, y ninguna regla de Google que hayamos encontrado dice que reinicie el periodo en el que tus testers aceptaron participar. La página de requisitos de prueba de Google te anima a mejorar la app durante la prueba cerrada, así que mantén a los testers dentro y publica la corrección en el mismo canal de pruebas cerrado. Esa es una lectura de las reglas publicadas, no una promesa que cubra todos los casos.
Un inicio de sesión roto sigue importando. La política de funcionalidad de Google Play dice: “No permitimos apps que fallen, se cierren de forma forzada, se congelen o funcionen de manera anormal”, y un muro de inicio de sesión impide que los testers lleguen a las funciones que deben probar. Corrígelo antes de solicitar acceso a producción y dale a los revisores datos de inicio de sesión que funcionen. Si ya recibiste el resultado de una revisión, consulta el rechazo por funcionalidad defectuosa (Broken Functionality).
Como contexto: las cuentas personales de desarrollador creadas después del 13 de noviembre de 2023 necesitan un mínimo de 12 testers (verificadores, en la documentación oficial de Google en español) que hayan aceptado participar durante al menos 14 días de forma continua antes de solicitar acceso a producción para esa app. Después de solicitarlo, Google dice: “La revisión suele tardar siete días o menos, pero en ocasiones puede tardar más.” Si faltan testers en el recuento, revisa cómo los invitaste antes de tocar el inicio de sesión.
¿Necesitas testers reales para los 14 días?
Los testers no pueden corregir un registro de OAuth, así que primero haz que el inicio de sesión funcione. Cuando funcione, PrimeTestLab te da 12+ testers reales que instalan tu versión de Play en teléfonos Android reales y siguen participando durante los 14 días completos, desde $19.99 (más 5% de tarifa de servicio). Si Google no concede el acceso a producción después de la prueba completa, eliges entre una repetición gratis o un reembolso completo. Mira cómo funciona la prueba cerrada con 12 testers.
Preguntas frecuentes
¿Por qué Google Sign-In funciona en debug pero no en la prueba cerrada?
Tu APK de debug y la app descargada desde Google Play pueden estar firmados con certificados distintos, así que registrar la huella de debug no configura la versión de Play. Empieza por el SHA-1 de la firma de apps de Play y después revisa el nombre de paquete final de la versión release y los ID de cliente que la app usa de verdad.
¿Dónde encuentro ahora el SHA-1 de Play App Signing?
Abre la página Protected with Play de tu app en Play Console. La ayuda de Google describe Play Store distribution y luego Go to Play app signing; otros textos actuales de Google los llaman Play Store protection y Manage Play app signing. Abre la sección App signing key certificate y copia el SHA-1, revisando también cualquier clave adicional que aparezca para tu app.
¿Necesito SHA-1 o SHA-256 para Google Sign-In?
El cliente OAuth de Android de Google identifica tu app por su nombre de paquete y la huella SHA-1 de su certificado de firma, y un SHA-256 no reemplaza ese campo. Otros servicios tienen sus propias necesidades: la autenticación por teléfono de Firebase usa SHA-256 para Play Integrity y SHA-1 para su alternativa con reCAPTCHA. Configura cada servicio para el flujo que usa tu app.
Ya agregué el SHA-1. ¿Qué debo revisar después?
Confirma que pertenece a la app instalada desde Play, no a tu clave de subida ni a la de debug. Después compara el ID de aplicación final, el proyecto de Firebase o de Cloud y el ID de cliente web. Si tu app tiene varios certificados de firma, revísalos también. Un error de tipeo en el ID de cliente que acepta el backend puede romper el inicio de sesión aunque las huellas sean correctas.
¿Tengo que subir otro AAB después de agregar una huella?
No necesariamente. Algunos desarrolladores reportan que una corrección solo de registro en Firebase o Google Cloud funcionó con la app ya instalada. Un ID de cliente, un archivo de configuración, código o una dependencia que cambien deben llegar a los testers en una compilación nueva. Revisa qué cambiaste y luego verifica la instalación real de Play en lugar de recompilar una y otra vez sin diagnóstico.
¿Cuánto tarda en funcionar una huella nueva?
Google no publica un tiempo de propagación específico para las huellas, y los hilos de desarrolladores que revisamos no midieron ninguno. Guarda la configuración correcta y vuelve a intentarlo. Si sigue fallando, verifica el certificado instalado y los ajustes del cliente en lugar de esperar una cantidad fija de horas, porque esperar no repara una discrepancia.
¿Por qué dice canceled si yo no cancelé?
Algunas integraciones de Credential Manager y de frameworks reportan un problema de configuración o de autorización como una cancelación, aunque una cancelación también puede ser real. Anota el tipo y el mensaje de la excepción, revisa la guía de solución de problemas de tu framework y no confundas la API actual con el estado heredado 12501 SIGN_IN_CANCELLED antes de cambiar ajustes.
¿El ID de cliente de Android es el que pongo en serverClientId?
No. En las integraciones nativas de Google documentadas, serverClientId o webClientId es el cliente OAuth de la aplicación web que se usa para la solicitud de token. El cliente de Android, en cambio, registra tu paquete y tu certificado de firma. Configura los dos y confirma que tu backend acepta la audiencia de token prevista, en lugar de intercambiar ID de cliente al azar.
¿El error 10 reinicia mi prueba cerrada de 14 días?
Ninguna regla de Google que hayamos encontrado dice que este error reinicie el periodo de participación, y Google anima a hacer mejoras durante la prueba cerrada, así que mantén a los testers inscritos y corrige el canal existente. Eso no indica que la app esté lista: un muro de inicio de sesión puede impedir pruebas útiles y dejar un problema de funcionalidad que debes corregir antes de solicitar acceso.
¿Qué debo pedirle a un tester que me envíe?
Pide la versión instalada, el enlace de la prueba en Play, el dispositivo y la versión de Android, el error exacto y el paso en el que se detiene el inicio de sesión. Una captura de pantalla con datos ocultos o una grabación corta ayuda. Después de tu corrección, pide al mismo tester que use una función que requiera iniciar sesión, que cierre sesión y vuelva a entrar, sin compartir ninguna credencial.
En resumen
En resumen
El error 10 de Google Sign-In significa que la app está mal configurada, y cuando solo falla la copia de Play, el certificado de firma es lo primero que hay que revisar. Copia el SHA-1 de la clave de firma de apps desde Protected with Play, regístralo con el nombre de paquete final de la compilación en el mismo proyecto de Firebase o Google Cloud que usa tu app, mantén el ID de cliente web en serverClientId y vuelve a probar la versión que instalaron tus testers, incluido un segundo inicio de sesión. Si sigue fallando, compara el certificado del APK instalado, el ID de aplicación y los ID de cliente antes de cambiar cualquier otra cosa.
Fuentes verificadas el 16 de octubre de 2026
Las etiquetas de los menús de Play Console y Firebase son los datos que más rápido cambian en esta página. Si una ruta de arriba ya no coincide con tu consola, busca la firma de apps de Play en Protected with Play, y las huellas digitales en tu app de Android dentro de Project settings en Firebase.