Explicá el proceso de release en Play Store — tracks, staged rollout, App signing

Llevar un build de Android hasta los usuarios pasa por un pipeline con cuatro tracks, un modelo de firma que se malentiende fácil, y un mecanismo de rollout dentro del último track. Explicarlo con claridad — en el orden correcto, con los nombres correctos — es en sí mismo una señal de que publicaste apps de verdad en Google Play, no que armaste una de forma aislada.

#Los cuatro tracks

Internal testing es el carril más rápido: hasta 100 testers, agregados por email, sin ninguna revisión de Google, así que un build puede estar disponible minutos después de subirlo. Existe para hacer smoke-testing vos mismo y con tu equipo inmediato antes de que nadie afuera de la empresa lo vea.

Closed testing — lo que la mayoría de los equipos todavía llama "alpha" — es opt-in mediante una lista de emails o un Google Group, sí recibe una revisión (generalmente liviana), y es donde corrés un pase de QA real con un grupo más amplio: soporte, stakeholders, un cohorte de acceso anticipado. Desde fines de 2023, Google exige que las cuentas de desarrollador personales nuevas corran un closed test con al menos 12 testers opt-in de forma continua durante 14 días antes de poder siquiera solicitar acceso a producción, así que este track no es opcional para una cuenta nueva, sin importar cuánta confianza tengas en el build.

Open testing ("beta") es público: cualquiera con el link de opt-in puede sumarse sin que vos administres una lista, y escala a miles de testers. Es el track para un programa de beta genuino, donde querés diversidad real de dispositivos y de red antes de producción.

Production es el listado que ve todo el mundo, y es el único track donde aplica un porcentaje de staged rollout.

#App signing: upload key vs. app signing key

Play App Signing divide la única clave de firma que antes administrabas vos en dos: una upload key, que vos guardás y usás para firmar el AAB que le mandás a Google, y una app signing key, que Google guarda y usa para firmar de verdad los APKs que se instalan en los dispositivos. Esa separación es lo que le permite a Google recuperar tu cuenta si perdés la upload key — pedís un reset, probás la titularidad, y te dan una upload key nueva sin tocar la app signing key ni romper las actualizaciones de los usuarios existentes — y es lo que le permite a Google re-optimizar el formato de la clave de firma con el tiempo sin pedirte que refirmes nada. También es obligatorio en la práctica: los Android App Bundles son el formato de publicación requerido desde agosto de 2021, y un AAB solo se puede publicar a través de Play App Signing.

#El staged rollout, y qué hace realmente frenarlo

Dentro del track de producción, un staged rollout libera la versión nueva a un porcentaje de usuarios que buscan actualización, y después te deja subirlo — 5, 10, 20, 50, 100 — mientras mirás los Android vitals: tasa de crashes, tasa de ANR, y el pre-launch report que Google corre automáticamente contra una matriz de dispositivos reales antes de que tu build llegue siquiera a los testers.

El detalle que hace tropezar a la gente en entrevistas: frenar un staged rollout detiene que el porcentaje siga subiendo y detiene que usuarios nuevos reciban la actualización, pero no revierte la actualización en los dispositivos que ya la instalaron. Si necesitás que esos dispositivos vuelvan a la versión anterior, publicás un release nuevo con un version code más alto que el del build malo, pero que contiene el código de la versión anterior — un rollback real, no una pausa.