La API de Google Play Developer te permite subir APKs nuevos para tus apps y publicarlos en diferentes segmentos. Esto te permite implementar versiones alfa y beta de tu app que estarán disponibles para usuarios aprobados. Esto también te permite implementar una versión de lanzamiento en etapas, que estará disponible automáticamente para una pequeña cantidad de usuarios de la app. Una vez que hayas publicado la versión de lanzamiento en etapas, puedes aumentar gradualmente la cantidad de usuarios que obtienen esa versión de la app hasta finalmente implementarla como la versión de "producción".
Cómo agregar y modificar APKs
Para subir uno o más APKs, llama al método Edits.apks: upload.
Este método sube el APK a un "bucket" de almacenamiento, en el cual el APK se puede asignar a un "segmento" para implementarlo para los usuarios. (Si se borra o descarta la edición, también se pierden los APKs subidos a ella).
Para lanzar los APKs en "segmentos", llama a Edits.tracks: update. Las opciones son las siguientes:
Segmentos de pruebas, como
"alpha"
y"beta"
Las versiones alfa y beta de la app se implementan para los usuarios que asignas a los grupos de prueba alfa y beta. Puedes asignar usuarios a estos grupos a través de Google Play Console.
Segmento de pruebas internas:
"qa"
Las versiones internas de tu app se implementan en el segmento de pruebas internas de acuerdo con la configuración establecida en Google Play Console.
Segmento de producción:
"production"
Las versiones del segmento de "producción" se implementan para todos los usuarios. Puedes usar lanzamientos en etapas en el segmento de producción a fin de implementar la versión de manera segura en un porcentaje pequeño de usuarios de producción primero y, luego, aumentar gradualmente este porcentaje a medida que aumenta tu seguridad con respecto a la versión.
Los usuarios de modo simple no deben colocar más de un APK en ningún segmento. Los usuarios de modo avanzado que usan la compatibilidad con múltiples APKs pueden subir cero, uno o más APKs a cada segmento.
Nombres de segmentos de factores de forma
Los nombres de segmentos de factores de forma incluyen un prefijo con un identificador específico.
Factor de forma | Prefijo |
---|---|
SO Android Automotive | industria automotriz |
Wear OS | wear |
Android TV | tv |
Cómo se computa el nombre de un segmento de factor de forma determinado
Los tipos de segmento comunes, como los de producción, pruebas abiertas y pruebas internas, tienen nombres conocidos.
Tipo de segmento | Nombre de segmento predeterminado |
---|---|
Producción | production |
Prueba abierta | beta |
Prueba interna | qa |
El nombre de segmento de un factor de forma determinado se puede computar de la siguiente manera:
"[prefix]:defaultTrackName"
.
Por ejemplo, el factor de forma de Wear OS tendrá segmentos llamados "wear:production"
, "wear:beta"
y "wear:qa"
.
Los segmentos de pruebas cerradas se crean de forma manual y tienen nombres personalizados. Por lo tanto, un segmento de pruebas cerradas para un factor de forma llamado $name
tendrá el nombre "[prefix]:$name"
.
Ejemplo de flujo de trabajo de APK
En esta sección, se describe una forma típica de usar la API de Tracks. En este caso, suponemos que quieres subir versiones nuevas del APK para cada segmento y asignar una cantidad de usuarios para que reciban una versión de lanzamiento en etapas. (En la práctica, es poco probable que un desarrollador realice todas estas acciones en la misma operación; en cambio, se puede actualizar la versión beta un día, crear un lanzamiento en etapas en "producción" otro día, y así sucesivamente).
- Abre una edición nueva, como se describe en el Flujo de trabajo de Edits.
- Llama al método Edits.apks: upload para cada APK que quieras subir. Pasa el APK en el cuerpo de la solicitud del método. (De esa manera, se colocará el APK en un área de almacenamiento, pero no se lanzará en un segmento ni se implementará). El método mostrará un código de versión para cada APK que subas. Ese código se usará para hacer referencia al APK cuando lo lances en un segmento.
Llama al método Edits.tracks: update para cada segmento en el que quieras lanzar los APKs. En el cuerpo de la solicitud, pasa un recurso Edits.tracks que contenga la versión que quieras lanzar. Por ejemplo, para lanzar un APK con el código de versión 88, pasa lo siguiente:
{ "releases": [{ "versionCodes": ["88"], "status": "completed" }] }
En este punto, los APK aún no están disponibles para los usuarios. Al igual que con otras ediciones, los cambios no se publican hasta que los confirmas.
Llama al método Edits: commit para confirmar los cambios. Después de este proceso, los usuarios de cada segmento obtendrán la versión actualizada del APK. (Al igual que con todas las ediciones, los cambios pueden demorar varias horas en aplicarse).
Lanzamientos en etapas
Si tienes una versión nueva del APK que quieres implementar de manera gradual, puedes optar por un "lanzamiento en etapas". Si lanzas la versión de esta manera, Google Play la implementará automáticamente en la fracción deseada que especifiques de usuarios de la app. Si el APK de "lanzamiento" no tiene problemas (como fallas, etc.), puedes aumentar la fracción de usuarios que reciben esa versión. Cuando esté todo listo, puedes implementar ese APK como la nueva versión de producción.
En esta sección, se describen los pasos que seguirías para realizar un lanzamiento en etapas de un APK y, luego, implementarlo como la versión de producción:
Crea una edición, como se describe en el Flujo de trabajo de Edits.
Sube un APK nuevo a la edición con el método Edits.apks: upload.
Inicia un lanzamiento en etapas
"inProgress"
en el segmento de producción con el método Edits.tracks: update. Elige la fracción de usuarios que deben recibir el nuevo APK. En este punto, el APK aún no está disponible para ningún usuario final.{ "releases": [{ "versionCodes": ["99"], "userFraction": 0.05, "status": "inProgress" }] }
Llama a Edits: commit para confirmar los cambios en la edición activa. En las próximas horas, se lanzará el APK nuevo para los usuarios. La fracción de los usuarios que selecciones recibirán el nuevo APK.
Según tu nivel de satisfacción con el lanzamiento en etapas, es posible que desees aumentar el porcentaje de usuarios aptos o detener la versión.
Cómo aumentar la fracción de usuarios para un lanzamiento en etapas
Suponiendo que tienes un lanzamiento en etapas vigente en un 5%, como se mostró en la sección anterior, en esta parte se describe cómo aumentar el porcentaje en caso de que la versión tenga un rendimiento satisfactorio:
Crea una edición, como se describe en el Flujo de trabajo de Edits.
Cambia el lanzamiento en etapas
"inProgress"
del segmento de producción con el método Edits.tracks: update. Aumenta la fracción de usuarios que deben recibir el APK nuevo:{ "releases": [{ "versionCodes": ["99"], "userFraction": 0.1, "status": "inProgress" }] }
Llama a Edits: commit para confirmar los cambios en la edición activa. En las próximas horas, se lanzará el APK nuevo para los usuarios. La fracción de los usuarios que selecciones recibirán el nuevo APK.
Cómo detener un lanzamiento en etapas
Suponiendo que tienes un lanzamiento en etapas vigente en un 5%, como se mostró en el ejemplo de código más arriba, en esta sección se describe cómo detener ese lanzamiento en caso de que hayas detectado un problema:
Crea una edición, como se describe en el Flujo de trabajo de Edits.
Cambia el lanzamiento en etapas
"inProgress"
del segmento de producción con el método Edits.tracks: update. Establece el estado como"halted"
.{ "releases": [{ "versionCodes": ["99"], "status": "halted" }] }
Llama a Edits: commit para confirmar los cambios en la edición activa. La versión ya no estará disponible para usuarios nuevos.
Si luego decides reanudar una versión detenida, puedes volver a establecer su estado como "inProgress"
.
Cómo completar un lanzamiento en etapas
Una vez que estés conforme con tu lanzamiento en etapas y desees lanzar la versión al 100% de los usuarios, puedes establecer el estado de la versión como "completed"
:
Crea una edición, como se describe en el Flujo de trabajo de Edits.
Cambia el lanzamiento en etapas
"inProgress"
del segmento de producción con el método Edits.tracks: update. Establece el estado como"completed"
.{ "releases": [{ "versionCodes": ["99"], "status": "completed" }] }
Llama a Edits: commit para confirmar los cambios en la edición activa. En las próximas horas, se lanzará el APK nuevo para los usuarios. La fracción de los usuarios que selecciones recibirán el nuevo APK.
Versiones en borrador
Las versiones en borrador te permiten subir APKs automáticamente y crear una versión a través de la API, que más adelante se puede implementar a través de Google Play Console. Para crear una versión en borrador de un segmento, sigue estos pasos:
- Abre una edición nueva, como se describe en el Flujo de trabajo de Edits.
- Llama al método Edits.apks: upload para cada APK que quieras subir. Pasa el APK en el cuerpo de la solicitud del método. El método devolverá un código de versión para cada APK que subas. Ese código se usará para hacer referencia al APK cuando lo asignes a una versión.
Llama al método Edits.tracks: update para cada segmento en el que quieras lanzar la versión. En el cuerpo de la solicitud, pasa un recurso Edits.tracks que contenga la versión en borrador que desees crear. Por ejemplo:
{ "releases": [{ "name": "My draft release", "versionCodes": ["88"], "status": "draft" }] }
Llama al método Edits: commit para confirmar los cambios. Ahora podrás inspeccionar y lanzar tu versión en borrador a través de desde Google Play Console o la API.
Cómo especificar las notas de la versión
Cuando lanzas una versión nueva de la app, puedes especificar las notas de la versión para destacar qué novedades hay para los usuarios.
Para ello, usa el campo "releaseNotes"
cuando proporciones un recurso Edits.tracks al método Edits.tracks: update.
{ "releases": [{ "name": "Release with notes", "versionCodes": ["88"], "status": "completed", "releaseNotes": [ {"language": "en-US", "text": "Describe what's new in this release."} ] }] }