Ejecución de dispositivos de la plataforma de dispositivos para desarrolladores para Android

Vista previa

Este producto o función está sujeto a las "Condiciones de la Oferta de la Fase Previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles “tal como están” y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En esta guía, se describe cómo ejecutar una prueba de instrumentación de Android con la CLI de gcloud beta device-run y encontrar los resultados en la consola de Google Cloud . Se supone que tienes una cuenta y un proyecto de Google Cloud .

Para usar esta Google Cloud CLI, deberás proporcionar el ID de tu proyecto Google Cloud . Consulta gcloud beta device-run para obtener un resumen de los comandos.

Antes de comenzar

En estos pasos, se supone que ya hiciste lo siguiente:

1. Creaste un proyecto de Google Cloud .
2. Configura la Plataforma de dispositivos para desarrolladores siguiendo la guía de inicio rápido.
3. Te autenticaste con gcloud en la terminal.
4. Revisé la descripción general de Device Run para obtener información general.
5. Compiló una prueba instrumentada para Android.

Paso 1: Elige dispositivos

Con la CLI de device-run, se pueden ejecutar pruebas de Android en los dispositivos físicos y virtuales disponibles. Para ver la lista completa de dispositivos disponibles, visita el Catálogo de dispositivos interactivo o ejecuta el siguiente comando:

gcloud beta device-run devices list

Resultado de ejemplo:

ID        MAKE    NAME     MODEL FORM      OS_VERSION CAPACITY  AVAILABILITY  PRODUCTS
tegu-35   Google  Pixel 9a tegu  PHYSICAL  35         MEDIUM    LOW           Automation, Streaming
tokay-34  Google  Pixel 9  tokay PHYSICAL  34         HIGH      HIGH          Automation, Streaming

Consulta el Catálogo de dispositivos para obtener información sobre cómo filtrar esta lista. Para segmentar un dispositivo específico para la ejecución de la prueba, usa su ID correspondiente (p. ej., tegu-35) en el comando de envío.

Paso 2: Ejecuta tu prueba de instrumentación

Ten en cuenta que estas marcas son obligatorias para las pruebas de Android:

• Dispositivo: Especifica un dispositivo con --device: --device shiba-35
• Prueba: Especifica el APK de prueba con --test: --test /path/to/test.apk

Para ejecutar la prueba, emite un comando similar al siguiente, pero con tus propios IDs de dispositivo y ruta de prueba:

gcloud beta device-run sessions submit instrumentation \
--device shiba-34 \
--apps /path/to/app.apk \
--test /path/to/test.apk

La carpeta del informe de resultados del trabajo se puede encontrar en una ruta de Cloud Storage, como gs://BUCKET_NAME/automation/sessions/SESSION_ID/. Consulta el resultado de la prueba para el vínculo, que se parecerá a lo siguiente: https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/.

Paso 3: Cómo configurar la ejecución de la prueba

Nota: Para ver todas las opciones disponibles del comando submit instrumentation, ejecuta gcloud beta device-run sessions submit instrumentation --help.

Ahora que ejecutaste una prueba, explora algunas opciones de configuración:

• Varios dispositivos: Para ejecutar las mismas pruebas en varios dispositivos, proporciona el indicador --device con varios IDs de dispositivos separados por comas, como --device shiba-34,tokay-36, o con varios indicadores --device, cada uno de los cuales especifica un ID de dispositivo distinto (p.ej., --device shiba-34 --device tokay-36).
• Apps adicionales: De manera opcional, puedes especificar uno o más APKs para instalar antes de ejecutar las pruebas con la marca --apps=path1,path2,...,path_n. El orden que especifiques será el orden en el que se instalarán estas apps.
• Tiempo de espera de la prueba: Limita la duración de la ejecución: --instrumentation-timeout=10m (el intervalo válido es de 1m a 1h y el valor predeterminado es 5m).
• Bucket personalizado de Cloud Storage: Si no especificas un bucket de Cloud Storage con la marca --bucket-name=, Google Cloud CLI usará un bucket predeterminado llamado PROJECT_ID-devicerun.
• Reintentos de pruebas inestables: Establece la cantidad máxima de intentos para volver a ejecutar pruebas inestables: --flaky-test-attempts=3 (el valor predeterminado es 1 intento).

Paso 4: Usa el sharding

Para incluir la plataforma de dispositivos para desarrolladores en un flujo de trabajo de integración continua y entrega continua (CI/CD), debes considerar la fragmentación de tus pruebas. Con la fragmentación de pruebas, se divide un conjunto de pruebas en subgrupos (fragmentos) que se ejecutan por separado de forma aislada. Developer Device Platform ejecuta automáticamente cada fragmento en paralelo con varios dispositivos y completa todo el conjunto de pruebas en menos tiempo.

Precaución: La fragmentación de pruebas puede tener un costo superior. Aunque la fragmentación de pruebas reduce el tiempo que lleva ejecutar todas las pruebas, la sobrecarga de iniciar tu app en cada fragmento puede aumentar los tiempos de cada dispositivo.

Paso 4.1 Cómo elegir la opción de fragmentación

Si tus trabajos tienen solo una pequeña cantidad de casos de prueba o el tiempo total de ejecución de todos los casos de prueba no es largo, no es necesario que uses la fragmentación. Si tienes una gran cantidad de casos de prueba o el tiempo total de ejecución de todos ellos es largo, considera usar la fragmentación.

La Plataforma de dispositivos para desarrolladores admite el sharding inteligente y uniforme. Cuando decidas cómo fragmentar tus pruebas, considera las siguientes opciones:

• Si todos los casos de prueba tardarán una cantidad de tiempo similar, usa el fragmentado uniforme dividiendo todos los casos de prueba en n fragmentos.

• Cuando el tiempo de ejecución de diferentes casos de prueba varía mucho, usa la división inteligente. La Plataforma de dispositivos para desarrolladores usa el tiempo histórico de ejecución de pruebas para crear diferentes fragmentos y completar todos los fragmentos en un período similar.

Nota: La cantidad de fragmentos es configurable, por lo que, cuando la Plataforma para dispositivos de desarrolladores ejecuta muchos fragmentos en paralelo, las ejecuciones de prueba podrían verse limitadas por la disponibilidad de dispositivos. Por este motivo, recomendamos que la cantidad de dispositivos especificada en la marca --device sea menor o igual a la cantidad de fragmentos.

Fragmentación uniforme

Para fragmentar tus pruebas con un fragmentado uniforme, incluye las marcas --sharding-option=uniform y --uniform-sharding-count= en el comando sessions submit instrumentation de la siguiente manera:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
 --device shiba-34,tokay-36 \
    --sharding-option=uniform \
    --uniform-sharding-count=2

Deberías ver un resultado que indique Job status: 2 running. El servicio crea dos trabajos, uno para cada dispositivo. Debido a que las entradas para ambos trabajos son idénticas, el servicio centraliza la validación y la realiza solo una vez.

Verás los dos trabajos enumerados por separado en el resultado final del comando cuando se complete:

JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED

Fragmentación inteligente

Para fragmentar tus pruebas con la fragmentación inteligente, incluye las marcas --sharding-option=smart, --smart-sharding-max-shard-count=, --smart-sharding-target-duration= (en minutos o 1 h) y --smart-sharding-record-name= en el comando sessions submit instrumentation de la siguiente manera:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
    --device shiba-34,shiba-35,tokay-36 \
    --sharding-option=smart \
    --smart-sharding-max-shard-count=3 \
    --smart-sharding-target-duration=5m \
    --smart-sharding-record-name=test.yaml

Deberías ver el resultado final que indica que se ejecutaron tres trabajos:

Session [session-3cd0564a] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED
job-002   execution-000   PASSED

A continuación, se incluye un resumen de las marcas de fragmentación inteligente que se usan aquí:

• --smart-sharding-max-shard-count=SMART_SHARDING_MAX_SHARD_COUNT: Especifica la cantidad máxima de fragmentos que se crearán para el fragmentado inteligente. Si no se establece o se configura en 0, se usan los límites máximos definidos por el sistema. El rango válido es de 0 a 20 para los dispositivos físicos y de 0 a 200 para los dispositivos virtuales.

• --smart-sharding-target-duration=SMART_SHARDING_TARGET_DURATION: Especifica el tiempo de ejecución objetivo (p.ej., 2 min, 10 min, 1 h) por fragmento para el fragmentado inteligente. El rango válido es de 2 min a 1 h. Obligatorio cuando --sharding-option=smart.

• --smart-sharding-record-name=SMART_SHARDING_RECORD_NAME: Especifica el nombre del archivo de registro de la fragmentación inteligente, sin incluir la extensión. Se requiere cuando --sharding-option=smart. Este archivo YAML se encuentra en el bucket de Storage Google Cloudespecificado por --bucket-name en el directoriosmart-sharding/. Si el archivo no existe, se creará automáticamente. De lo contrario, su contenido se actualizará cuando se complete la sesión.

Paso 5: Explora y administra la ejecución de la prueba

Para el modo síncrono y asíncrono del comando sessions submit instrumentation, puedes usar el comando sessions describe para consultar el estado del trabajo durante la ejecución o obtener el resultado después de que se complete:

gcloud beta device-run sessions describe SESSION_ID

El resultado resume los resultados de las pruebas y vincula a ellos en Google Cloud console. Por ejemplo:

Session SESSION_ID finished with result [FAILED].
Result files are stored at [https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   all             FAILED: 2 test cases failed, 5 passed

Usa el siguiente comando para enumerar todas tus sesiones en ejecución y completadas:

gcloud beta device-run sessions list

Recibirás un resultado que contiene la lista de sesiones de tu proyecto, similar al siguiente:

SESSION_ID                                    START_TIME                STATE
session-4825e153                              2026-07-28T16:38:43.155Z  DONE
session-813ca602                              2026-07-28T22:40:32.415Z  DONE
session-67cd0570                              2026-07-16T08:25:55.474Z  DONE
session-17cc299c                              2026-07-14T14:31:33.649Z  DONE
session-911d0763                              2026-07-09T00:39:02.051Z  DONE
session-4e943fea                              2026-07-15T23:08:32.252Z  DONE
session-0132e458                              2026-08-20T18:33:19.751Z  DONE
session-1077f07b                              2026-07-28T22:35:43.848Z  DONE
session-71b054c6                              2026-07-15T01:15:41.643Z  DONE
session-4f8b2e45                              2026-08-06T23:11:56.161Z  DONE

El comando sessions list admite todas las opciones de marcas estándar de Google Cloud CLI. Por ejemplo:

gcloud beta device-run sessions list --limit 5

Esto genera resultados similares a los siguientes:

SESSION_ID                            START_TIME                STATE
session-4825e153                      2026-07-28T16:38:43.155Z  DONE
session-813ca602                      2026-07-28T22:40:32.415Z  DONE
93ec2df2-d5bf-4c36-b7f7-c2a4fb0dc3ce  2026-07-03T05:10:58.015Z  DONE
session-67cd0570                      2026-07-16T08:25:55.474Z  DONE
session-17cc299c                      2026-07-14T14:31:33.649Z  DONE

O bien, para encontrar todas las sesiones en ejecución, ejecuta lo siguiente:

gcloud beta device-run sessions list --filter RUNNING

Si tienes sesiones en ejecución, verás resultados similares a los siguientes:

SESSION_ID        START_TIME  STATE
session-d7ff8b81              RUNNING

De lo contrario, recibirás Listed 0 items..

Para cancelar una sesión en ejecución, ejecuta este comando con tu ID de sesión:

gcloud beta device-run sessions cancel SESSION_ID

El comando se muestra de inmediato, ya que la sesión solo se marca para cancelarse. La cancelación se realiza de forma asíncrona en el backend.

Si la sesión ya finalizó, solo se imprimirá el estado actual. Solicitar la cancelación de una sesión finalizada no es un error.

¿Qué sigue?

A continuación, busca y analiza los registros.