Prueba cerrada de Google Play para apps con Kotlin y Jetpack Compose

Las apps nuevas deben usar la firma de aplicaciones de Play: Google guarda la clave de firma de la app y tú firmas cada subida con una clave de subida. El asistente de Android Studio puede crear el keystore; recomienda una validez de al menos 25 años.

Para firmar desde la línea de comandos o en CI, guarda las credenciales en un archivo keystore.properties fuera del control de versiones y léelo en app/build.gradle.kts:

storePassword=myStorePassword
keyPassword=myKeyPassword
keyAlias=upload
storeFile=/path/to/upload-keystore.jks

import java.io.FileInputStream
import java.util.Properties

val keystoreProperties = Properties().apply {
    load(FileInputStream(rootProject.file("keystore.properties")))
}

android {
    signingConfigs {
        create("release") {
            keyAlias = keystoreProperties["keyAlias"] as String
            keyPassword = keystoreProperties["keyPassword"] as String
            storeFile = file(keystoreProperties["storeFile"] as String)
            storePassword = keystoreProperties["storePassword"] as String
        }
    }
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

Haz copia del keystore y de las dos contraseñas. Si la clave de subida se pierde o se filtra, crea una nueva y pide un restablecimiento en Play Console; la clave de firma de la app sigue siendo la misma.

versionCode tiene que ser mayor que el de cualquier bundle que hayas subido, en cualquier canal; versionName es lo que ven los usuarios. Ambos están en defaultConfig, junto a los niveles de SDK:

android {
    compileSdk = 36
    defaultConfig {
        applicationId = "com.yourcompany.app"
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

Desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones deben apuntar a Android 16 (nivel de API 36). Subir targetSdk activa comportamientos nuevos de la plataforma. Las apps que apuntan a Android 15 o superior se dibujan de borde a borde y en Android 16 ya no se puede desactivar, así que comprueba antes de la prueba que tus pantallas de Compose gestionan bien los window insets.

• R8 elimina lo que necesita la reflexión. Con isMinifyEnabled = true, los modelos de serialización, las clases de Retrofit o Gson y algunas configuraciones de inyección de dependencias pueden romperse solo en release. Añade reglas en proguard-rules.pro y prueba la variante release.
• Sorpresas del borde a borde. El contenido dibujado bajo la barra de estado y la de navegación tapa botones. Usa el padding de Scaffold o los modificadores WindowInsets en cada pantalla que vayan a ver los testers.
• Release depurable. Con isDebuggable = true en el tipo de build release, Play Console rechaza el bundle.
• Secretos de firma en git. Las contraseñas escritas directamente en build.gradle.kts acaban en tu repositorio. Guárdalas en keystore.properties o en los secretos de la CI.
• Bibliotecas nativas y páginas de 16 KB. Las apps solo en Kotlin ya admiten páginas de memoria de 16 KB, pero el código NDK y las bibliotecas con archivos .so deben recompilarse o actualizarse. Play Console avisa de ello y, a partir del 1 de febrero de 2027, no se podrán publicar actualizaciones sin esa compatibilidad.
• Probar solo debug. Los testers reciben la variante release. Ejecútala en al menos una versión reciente de Android antes de cada subida.

Los testers solo ejecutan la variante de release, así que sus fallos vienen de código optimizado por R8, con clases y métodos renombrados. El build escribe el mapeo que lo deshace en app/build/outputs/mapping/release/mapping.txt, lo sobrescribe en cada build y además lo mete en el .aab.

1. 1

   Deja que Play Console desofusque

   Con el plugin de Android para Gradle 4.1 o posterior, Play Console toma el archivo de mapeo del bundle subido. Los fallos de Supervisar y mejorar → Android vitals → Fallos y ANR muestran entonces tus nombres reales de clases y métodos.

2. 2

   Guarda una copia por versión

   Archiva mapping.txt con cada código de versión que subas. Lo necesitas para los stack traces que los testers pegan en sus informes y para cualquier herramienta de fallos fuera de Google Play.

3. 3

   Haz retrace a mano

   Ejecuta retrace de las herramientas de línea de comandos con el mapeo y un archivo que contenga el stack trace. Las versiones recientes de Android Studio también hacen retrace automático en Logcat.

$ANDROID_HOME/cmdline-tools/latest/bin/retrace \
  app/build/outputs/mapping/release/mapping.txt trace.txt

¿Usas el NDK? Define debugSymbolLevel en el tipo de build de release. SYMBOL_TABLE da nombres de función en Play Console y FULL añade archivos y números de línea. En los app bundles, los símbolos nativos se incluyen y se suben automáticamente.

android {
    buildTypes {
        release {
            ndk {
                debugSymbolLevel = "FULL" // or "SYMBOL_TABLE"
            }
        }
    }
}

Cuando R8 conserva código que no esperabas, o elimina código que la reflexión necesita, -whyareyoukeeping muestra el camino de una clase conservada a un punto de entrada, y configuration.txt junto al mapeo enumera todas las reglas combinadas.

En cuanto tu bundle de Kotlin / Jetpack Compose esté compilado y firmado, el resto ocurre en Play Console y funciona igual con cualquier framework. Esta es la lista de comprobación; cada menú y cada pantalla están en la guía completa de Play Console.

• Termina la configuración de la app en el Panel: política de privacidad, acceso a la app, anuncios, clasificación de contenido, público objetivo, seguridad de los datos y ficha de Play Store.
• Crea una versión de prueba cerrada en Probar y publicar → Pruebas → Prueba cerrada: elige los países de tus testers, sube el .aab y envíalo a revisión.
• Añade testers con un Google Group en la pestaña Testers y comparte el enlace de opt-in. Funciona en cuanto el canal muestra Publicado.
• Mantén al menos 12 testers con opt-in durante 14 días seguidos. Las pruebas internas no cuentan, y quien sale y vuelve empieza sus 14 días de nuevo.
• Publica al menos una actualización durante la prueba y apunta qué encontraron los testers y qué cambiaste.
• Solicita acceso a producción desde el Panel y responde las tres secciones sobre tu prueba, tu app y tu preparación. La decisión es de Google; nadie puede garantizar la aprobación.

Cuenta con bajas: recluta más de 12 testers para que una baja no retrase tu calendario. Ver todos los pasos de Play Console.

Sube versionCode, vuelve a compilar el bundle (Gradle o el asistente de Android Studio) y súbelo al mismo canal cerrado.

./gradlew bundleRelease

Para instalar el bundle que vas a subir, genera a partir de él APK específicos del dispositivo con bundletool, firmados con tu clave de subida. Es lo más parecido a lo que entrega Google Play, incluidas las divisiones por densidad de pantalla, idioma y ABI:

bundletool build-apks --connected-device \
  --bundle=app/build/outputs/bundle/release/app-release.aab --output=app.apks \
  --ks=/path/to/upload-keystore.jks --ks-key-alias=upload
bundletool install-apks --apks=app.apks

Para pruebas rápidas de tu propio equipo, el uso compartido interno de apps de Play Console acepta cualquier código de versión y te da un enlace de descarga para hasta 100 personas. Esas subidas no pueden formar parte de un canal de prueba y no sustituyen la prueba cerrada: tus 12 testers siempre instalan desde el canal cerrado.