En esta página, se proporciona ayuda para solucionar problemas y respuestas a preguntas frecuentes sobre la ejecución de pruebas con la plataforma de dispositivos para desarrolladores. Si no encuentras lo que buscas o necesitas más ayuda, comunícate con nosotros.
Soluciona problemas
¿Por qué mi prueba tarda tanto en ejecutarse?
Cuando seleccionas un dispositivo con un nivel de capacidad alto en el catálogo de la Plataforma de dispositivos para desarrolladores, las pruebas pueden comenzar más rápido. Cuando un dispositivo tiene capacidad baja, las pruebas pueden tardar más en ejecutarse. Si la cantidad de pruebas invocadas es mucho mayor que la capacidad de los dispositivos seleccionados, las pruebas pueden tardar más en completarse.
Las pruebas que se ejecutan en cualquier nivel de capacidad del dispositivo pueden tardar más debido a los siguientes factores:
- Tráfico, que afecta la disponibilidad del dispositivo y la velocidad de prueba.
- Fallas en el dispositivo o la infraestructura, que pueden ocurrir en cualquier momento. Para verificar si hay fallas de infraestructura informadas para Developer Device Platform, consulta el panel de Google Cloud Personalized Service Health.
Para obtener más información sobre la capacidad del dispositivo en Developer Device Platform, consulta el Catálogo de dispositivos.
¿Por qué los resultados de la prueba no son concluyentes?
Por lo general, los resultados de la prueba no son concluyentes debido a ejecuciones de pruebas canceladas
o errores de infraestructura. Además de PASSED y FAILED, la Plataforma de dispositivos para desarrolladores puede devolver ERROR, TIMED_OUT y CANCELLED.
Los errores de infraestructura se deben a problemas internos de la Plataforma de dispositivos para desarrolladores, como errores de red o comportamientos inesperados del dispositivo. Internamente, la plataforma de dispositivos para desarrolladores reintenta varias veces las ejecuciones de pruebas que producen errores de infraestructura antes de informar un resultado no concluyente.
Para determinar la causa del error, sigue estos pasos:
- Consulta si hay interrupciones conocidas en el panel de Service Health de Google Cloud.
Vuelve a ejecutar la prueba en la plataforma del dispositivo para desarrolladores y verifica que se pueda reproducir.
Intenta ejecutar la prueba en otro dispositivo o tipo de dispositivo, si corresponde. Consulta el Catálogo de dispositivos para obtener más información.
¿Por qué la fragmentación hizo que mis pruebas se ejecutaran por más tiempo?
La fragmentación puede provocar que las pruebas se ejecuten durante más tiempo cuando la cantidad de fragmentos que especificaste supera la cantidad de dispositivos disponibles para usar en la plataforma de dispositivos para desarrolladores. Para evitar esta situación, limita la cantidad de dispositivos a la cantidad de fragmentos. Para obtener más información sobre cómo elegir otro dispositivo, consulta el Catálogo de dispositivos.
¿Por qué mi prueba tarda tanto en iniciarse?
Cuando envías una solicitud de prueba, tu app se valida, se vuelve a firmar, etc., a modo de preparación para ejecutar pruebas en un dispositivo. Por lo general, este proceso se completa en unos pocos segundos, pero puede verse afectado por factores como el tamaño de la app.
Una vez que tu app esté lista, las ejecuciones de prueba se programan y permanecen en una cola hasta que un dispositivo esté listo para ejecutarla.
¿Por qué mi prueba tarda tanto en terminar?
Una vez que finaliza la ejecución de prueba, los artefactos de prueba se descargan del dispositivo, se procesan y se suben a Cloud Storage. La duración de este paso puede verse afectada por la cantidad y el tamaño de los artefactos.
Solución de problemas específicos de Android
La app no muestra los datos y no puede ubicar las capturas de pantalla
Los artefactos de ejecución de prueba (como capturas de pantalla y archivos de registro) se almacenan en Cloud Storage y se procesan directamente en la consola de Google Cloud . Verifica que hayas asignado roles a nivel del proyecto.
También ten en cuenta que Developer Device Platform tiene un agente de servicio dedicado que usa sus propias credenciales en lugar de las tuyas para realizar las siguientes acciones:
- Leer y escribir en buckets y objetos de Cloud Storage
- Descarga archivos de entrada de Cloud Storage en el sistema interno
- Sube archivos del sistema interno al bucket de salida de Cloud Storage
Es posible que tengas acceso a un bucket de Cloud Storage y a un archivo, pero que ese bucket sea propiedad de un proyecto Google Cloud diferente del que se usa en DDP. Por lo tanto, la cuenta de servicio de la plataforma de dispositivos para desarrolladores no tiene acceso a él.
También puedes tener controles de acceso adicionales en buckets individuales. Consulta Device Run para saber cómo incluir archivos en tus pruebas.
¿Por qué recibo resultados parciales o faltantes en los casos de prueba de instrumentación?
Cuando ejecutas pruebas de instrumentación, es posible que veas que la cantidad total de casos de prueba es menor de lo esperado. Esto suele deberse a que la plataforma del dispositivo para desarrolladores no puede analizar el Logcat para los marcadores de inicio o fin de casos de prueba que suele generar AndroidJUnitRunner.
Las siguientes son causas comunes de este problema:
| Descripción del problema | Solución posible |
|---|---|
| No se ejecutó el caso de prueba porque se agotó el tiempo de espera. Si la duración total de las pruebas supera el tiempo de espera especificado o un tiempo de espera máximo, Developer Device Platform cancela el resto de los casos de prueba. |
|
| No se pudo completar el caso de prueba porque se cerró de forma prematura o se detuvo. Es posible que el caso de prueba se cierre antes de tiempo debido a una excepción no detectada o un error de aserción. Es posible que los casos de prueba se detengan en un bucle infinito o que no puedan continuar, por ejemplo, si la app no muestra la vista correcta y el caso de prueba no puede realizar la acción en la IU. |
Revisa el video y el logcat para investigar dónde se detuvo la
prueba.
|
Un ejecutor de pruebas personalizado (incluida la extensión de AndroidJUnitRunner) falló
de forma inesperada o escribió marcadores de inicio o fin de casos de prueba inesperados en
logcat.
|
Verifica el código del ejecutor de pruebas. |
Los registros excesivos se escribieron en logcat y sobrecargaron el búfer o
hicieron fallar el proceso logcat.
|
Reduce las operaciones de escritura a logcat.
|
| La app sometida a prueba falló. | Depura tu app. |
Preguntas frecuentes
¿Dónde puedo encontrar información sobre los precios de la Plataforma de dispositivos para desarrolladores?
Consulta Preguntas sobre precios y facturación para obtener más detalles.
¿Dónde puedo encontrar los detalles del dispositivo, como la resolución, etcétera?
La información detallada del dispositivo está disponible a través de la API y se puede acceder a ella desde la CLI de Developer Device Platform con el comando device-run devices describe <device-id>:
gcloud beta device-run devices describe DEVICE_ID
¿Cómo puedo averiguar si el tráfico que llega a mi backend proviene de la Plataforma para dispositivos de desarrolladores?
Desde tu backend, puedes determinar si el tráfico proviene de dispositivos de prueba alojados en la Plataforma para dispositivos de desarrolladores. Para ello, revisa si la dirección IP de origen pertenece a nuestros rangos de IP.
¿La Plataforma de dispositivos para desarrolladores funciona con VPC-SC?
Developer Device Platform no funciona con VPC-SC, que bloquea la copia de apps y otros artefactos de prueba entre el almacenamiento interno de Developer Device Platform y los buckets de resultados de los usuarios.
¿Cómo puedo reducir las pruebas inestables en la plataforma de dispositivos para desarrolladores?
Para detectar un comportamiento inestable en tus pruebas, te recomendamos usar la opción --flaky-test-attempts. Las ejecuciones de reintento que corrigieron las inestabilidades se facturan o se consideran en tu cuota diaria de la misma manera que las ejecuciones de prueba normales.
Ten en cuenta lo siguiente:
- De forma predeterminada, DDP ejecutará el reintento en secuencia para ahorrar costos. Los usuarios deben configurar
--flaky-test-parallel-retrypara que se ejecute en paralelo. - La marca
--flaky-test-retry-leveldefine si se debe volver a intentar la solicitud en el nivelshardo en el niveltestindividual, y el valor predeterminado esshard. Establécelo entestpara reducir el tamaño y la duración de la prueba de reintentos.
Preguntas frecuentes específicas para iOS
¿La Plataforma de dispositivos para desarrolladores admite Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?
Si bien algunas de estas plataformas de pruebas y desarrollo de apps están en nuestra hoja de ruta, no podemos garantizar la compatibilidad con ellas.
¿Por qué faltan videos en los resultados de mi prueba para iOS?
Se planea admitir videos en los resultados en iOS 18 o versiones posteriores.
Preguntas frecuentes específicas de Android
¿La Plataforma de dispositivos para desarrolladores admite dispositivos wearable?
Sí. La Plataforma de dispositivos para desarrolladores es compatible con el Google Pixel Watch. Ahora puedes ejecutar pruebas en tu app para Wear OS independiente en el Google Pixel Watch. Para obtener más información sobre los dispositivos de Developer Device Platform, consulta el Catálogo de dispositivos.
¿La Plataforma de dispositivos para desarrolladores es compatible con los dispositivos de Google más recientes?
Sí. La plataforma Developer Device admite la Google Pixel Tablet y el Google Pixel Fold. Puedes ejecutar las pruebas en tus dispositivos físicos independientes. Para obtener más información sobre los dispositivos disponibles en Developer Device Platform, consulta el Catálogo de dispositivos.
¿La Plataforma para dispositivos del desarrollador admite Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?
Si bien algunas de estas plataformas de pruebas y desarrollo de apps están en nuestra hoja de ruta, no podemos garantizar la compatibilidad con ellas. Sin embargo, si creaste la app con un framework que admite Espresso (como Flutter), puedes escribir una prueba de instrumentación con Espresso y, luego, ejecutarla en Developer Device Platform.
¿La Plataforma de dispositivos para desarrolladores admite pruebas de apps ofuscadas, por ejemplo, con ProGuard o R8?
La Plataforma para dispositivos de desarrolladores no admite explícitamente la ofuscación o desofuscación. Si bien es probable que la app se ejecute, cualquier dato ofuscado, como los seguimientos de pila, aparecerá como ofuscado en los registros.
¿Puedo usar mi dispositivo plegable en diferentes estados y posiciones plegables mientras hago pruebas en la Plataforma de dispositivos para desarrolladores?
Sí. Puedes probar tu dispositivo plegable en estados y posiciones plegables.
Estos dispositivos pueden estar en varios estados de plegado, como FLAT (completamente abierto) o HALF_OPENED (entre completamente abierto y completamente cerrado).
Por otro lado, las posiciones constan de la orientación específica y el estado plegable del dispositivo. Por ejemplo, la posición de mesa, que es un estado HALF_OPENED en orientación horizontal, o la posición de libro, que es un estado HALF_OPENED en orientación vertical.
Si ejecutas pruebas de instrumentación, puedes usar la biblioteca WindowManager de Jetpack y seguir la documentación de pruebas de tu app en dispositivos plegables para hacer pruebas en diferentes estados y posiciones.
Como alternativa, los estados disponibles son específicos del dispositivo y se puede interactuar con ellos mediante adb
shell command cmd device_state.
- Para mostrar el estado actual, ejecuta
adb shell cmd device_state state. - Para establecer o anular el estado actual, ejecuta
adb shell cmd device_state state <IDENTIFIER>. - Para restablecer el estado, ejecuta
adb shell cmd device_state state reset. - Para verificar los estados disponibles, ejecuta el comando
adb shell cmd device_state print-statesen el dispositivo plegable.
Google Pixel Fold (ID de modelo felix)
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSED', app_accessible=true},
DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
DeviceState{identifier=2, name='OPENED', app_accessible=true},
DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]
Samsung Galaxy Z Fold4 (ID de modelo q4q)
$ adb shell cmd device_state print-states
Supported states: [
DeviceState{identifier=0, name='CLOSE', app_accessible=true},
DeviceState{identifier=1, name='TENT', app_accessible=true},
DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
DeviceState{identifier=3, name='OPEN', app_accessible=true},
]
¿Puedo probar la Plataforma para dispositivos de desarrollador si no tengo una app?
A diferencia de otros productos de la Plataforma para dispositivos de desarrollador, no necesitas agregar un SDK de la Plataforma para dispositivos de desarrollador para usarla. Si aún no tienes una app, puedes descargar un APK en línea o compilar una app y un APK de prueba de una de las muestras del repositorio de AndroidX en GitHub. Ten en cuenta que una prueba de instrumentación requiere una app y un APK de prueba que se compilan a partir del código fuente. Para obtener más información, consulta el artículo sobre las pruebas instrumentadas.
Para obtener más información sobre las funciones de la Plataforma de dispositivos para desarrolladores, consulta la descripción general del producto de la DDP.
¿Qué dispositivos son mejores para las pruebas de captura de pantalla con diferencias?
En las pruebas de captura de pantalla con diferencias, las aserciones de prueba se basan en comparar
imágenes de pantalla obtenidas durante la ejecución de una prueba con imágenes doradas que representan el comportamiento
esperado. Estas pruebas pueden ser más frágiles en algunos tipos de dispositivos que en otras. Recomendamos segmentar
los dispositivos emuladores de ARM (*.arm) para este tipo de pruebas. Los dispositivos emuladores de ARM usan
imágenes muy similares o idénticas a los emuladores genéricos de Android Studio.
También te recomendamos que investigues las bibliotecas de prueba, ya que pueden ayudar a que las pruebas de captura de pantalla sean más sólidas ante la presencia de cambios esperados.
¿Actualiza la Plataforma de dispositivos para desarrolladores los dispositivos virtuales?
Sí. Los dispositivos virtuales se actualizan cuando se realizan los siguientes cambios:
- Actualizaciones en las imágenes existentes
- Baja de los niveles de API anteriores
- Se agregaron nuevos niveles de API de Android
¿Cómo habilito los informes de cobertura?
Para habilitar los informes de cobertura, agrega coverage=true al campo additional-test-options.
Si usas Android Test Orchestrator, debes proporcionar una ruta de acceso al directorio para almacenar los resultados de la cobertura:
--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/
Si no usas Orchestrator, puedes especificar una ruta de acceso al archivo:
--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec
¿Cómo accedo a una app para Wear sin un teléfono?
Si tu app normalmente requiere un teléfono para acceder, puedes crear una variante de compilación que omita el acceso y use un token incorporado en tu compilación de prueba, o bien leer desde archivos en el disco que suelen enviarse con la marca --other-files-to-push.