Resumen
Añade a GitHub Actions una comprobación previa del registro Android sin exponer la clave API de Google.
Para quién: Equipos que usan GitHub Actions para compilar, firmar y publicar aplicaciones Android.
Secuencia de lanzamiento
- Resuelve el applicationId de la variante de producción.
- Extrae el SHA-256 público del certificado del artefacto firmado.
- Llama a la API oficial desde un job protegido o un endpoint interno.
- Bloquea la promoción si el estado está pendiente o la huella no coincide, con una política manual de excepción.
Datos clave
Nunca muestres la clave API, la contraseña del almacén ni la clave privada en los logs de Actions. Una huella pública del certificado no es la clave privada.
Guía detallada
Job de control antes del lanzamiento
Ejecuta la comprobación después de firmar el APK y antes de promoverlo. Guarda la clave de Google en GitHub Actions secrets, restríngela a Android Developer ID Status API y evita contextos de pull request donde código no confiable pueda acceder a credenciales de release.
El ejemplo mínimo solo consulta el nombre de paquete. Para validar también la firma, añade a la URL certificateFingerprint con el SHA-256 del certificado de producción. Analiza state con jq; falla de inmediato para estados estables y usa backoff limitado solo para RESOURCE_EXHAUSTED, INTERNAL y UNAVAILABLE.
- No mostrar nunca la clave API.
- Añadir certificateFingerprint para comprobar el certificado de producción.
- Guardar el artefacto de estado sin secretos de firma.
- name: Check Android registration
env:
API_KEY: ${{ secrets.ANDROID_DEVELOPER_ID_API_KEY }}
PACKAGE_NAME: com.example.app
run: |
curl --fail --silent --show-error \
-H "X-Goog-Api-Key: $API_KEY" \
"https://androiddeveloperidstatus.googleapis.com/v1/packages/$PACKAGE_NAME/packageRegistrationStatus:check" \
| tee status.json
test "$(jq -r .state status.json)" = "REGISTERED"Introduce el nombre de producción. Para comprobar la firma, añade la huella SHA-256 del certificado del APK que reciben los usuarios. El resultado no sustituye la revisión de la tienda.
Comprobar el estado →Preguntas frecuentes
¿La CI debe llamar al endpoint web de PkgReady?
No. Debe llamar a la API oficial servidor a servidor con una clave protegida que pertenezca a tu organización.
¿Qué estados deben detener la release?
Detén NOT_REGISTERED y las huellas distintas. Trata los errores de cuota o servicio como fallos de infraestructura con reintentos limitados.
Fuentes y revisión
Última revisión: