Resumen
Crea un control Gradle del paquete Android que use el applicationId final y la identidad del artefacto firmado, no valores codificados a mano.
Para quién: Ingenieros Android que mantienen muchas variantes o varios product flavors.
Secuencia de lanzamiento
- Resuelve applicationId desde la variante de release elegida.
- Ejecuta el control solo después de firmar el artefacto de producción.
- Extrae el SHA-256 con las herramientas de build Android.
- Genera para CI un resultado pequeño y legible por máquina sin exponer credenciales.
Datos clave
Los product flavors y applicationIdSuffix originan muchos falsos NOT_REGISTERED.
Guía detallada
Obtén los valores de la variante elegida
Un proyecto Android moderno puede tener varios applicationId y configuraciones de firma. Conecta una tarea exclusiva de release a la variante seleccionada y su salida firmada, en lugar de mantener otra lista de identidades.
Mantén la red fuera de las tareas normales de compilación y test. Exporta paquete y huella en un artefacto legible por máquina y deja que CI haga la llamada protegida.
- No ejecutar en cada build de depuración.
- No suponer que namespace equivale a applicationId.
- No usar la firma de depuración para revisar una release.
./gradlew assembleRelease
apksigner verify --print-certs app/build/outputs/apk/release/app-release.apkIntroduce 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
¿Por qué no llamar a la API en cada build Gradle?
Consume cuota, ralentiza los builds y extiende las credenciales a más entornos. Úsala como comprobación de release controlada.
¿Cómo se representan los flavors?
Usa el applicationId final de la variante y el certificado de su artefacto firmado.
Fuentes y revisión
Última revisión: