Como corrigimos a baixa otimização DEX no Google Play

Contexto: aplicativo React Native com Expo (managed ou prebuild), builds Android via EAS. O Google Play Console exibe alerta ou classificação baixa de otimização DEX / ofuscação na versão que está na loja ou em teste fechado.

Modo: INVESTIGAÇÃO SOMENTE LEITURA. Não editar arquivos, não instalar pacotes, não executar eas build, não commitar, não publicar.

Tarefas:
1. Explicar em linguagem clara o que o Play Console costuma medir neste contexto: bytecode DEX, percentual de ofuscação reportado, download estimado por aparelho — e por que essas métricas não são intercambiáveis.
2. Listar arquivos e configs que devo inspecionar neste projeto Expo, na ordem mais útil: package.json (expo, react-native, plugins), app.json ou app.config, eas.json (perfis de build), pasta android/ se existir (build.gradle release, proguard/r8), artefatos locais AAB/APK se eu indicar que tenho cópias.
3. Verificar se há expo-build-properties (ou equivalente) e se enableMinifyInReleaseBuilds (ou flags Gradle minifyEnabled / shrinkResources no variant release) estão declarados para o build que alimenta a Play Store — distinguir configuração declarada de efeito no artefato.
4. Identificar qual perfil EAS (production, preview, etc.) provavelmente gera o pacote da loja versus builds internos de teste (APK). Se não houver evidência no repositório, declarar lacuna e pedir confirmação minha — sem solicitar URLs de dashboard, IDs de build ou credenciais.
5. Produzir diagnóstico em três blocos: FATOS (métricas e versões que eu informei + trechos de config encontrados), HIPÓTESES (release sem minify, permissões herdadas, profile errado), RECOMENDAÇÕES ordenadas por impacto e risco.
6. Não inventar números de ofuscação ou MB; não prometer que habilitar a minificação e a ofuscação com R8, respeitando as regras de preservação de código aplicáveis, resolve sozinho sem testes funcionais.

Entrega: checklist numerado para eu validar antes de qualquer implementação.

Contexto: pós-diagnóstico de otimização DEX no Google Play. Suspeita de permissões declaradas sem uso no app e/ou release Android sem minificação R8 efetiva no variant publicado.

Modo: AUDITORIA. Pode sugerir edits, mas NÃO aplicar alterações até eu aprovar explicitamente.

Tarefas — permissões:
1. Mapear todas as permissões no AndroidManifest efetivo (app + bibliotecas). Para cada permissão sensível ou incomum, indicar provável origem (app.json permissions/blockedPermissions, plugin Expo, dependência nativa).
2. Cruzar com as funcionalidades que descrevo abaixo. Marcar como REMOVÍVEL/BLOQUEÁVEL somente com justificativa; se houver dúvida, manter e explicar o risco de remover.
3. Para apps sem overlay flutuante, explicar quando faz sentido usar android.blockedPermissions com SYSTEM_ALERT_WINDOW no Expo — e quando NÃO fazer (biblioteca que exige overlay, debug tools, etc.).

Tarefas — release / R8:
4. Inspecionar expo-build-properties (versão no package.json) e plugins em app.json/app.config. Confirmar se enableMinifyInReleaseBuilds está true para release. Verificar se enableShrinkResourcesInReleaseBuilds existe; se ausente, dizer o que isso implica (não assumir que está ativo).
5. Revisar eas.json: perfis preview vs production, buildType (apk vs app-bundle), autoIncrement, appVersionSource remote/local. Avaliar se o build que vai à loja usa o mesmo variant otimizado que testamos internamente.
6. Listar riscos de compatibilidade: notificações locais, alarmes exatos (SCHEDULE_EXACT_ALARM), reflexão/React Native, bibliotecas que quebram com minify — citar necessidade de regras ProGuard keep quando aplicável.

Entrega:
- Tabela: permissão | origem | usada? | ação recomendada (manter / blockedPermissions / investigar lib).
- Diff mínimo proposto (app.json, package.json se faltar dependência, eas.json se precisar perfil de teste).
- Não recomendar bump de Expo SDK ou AGP sem justificar impacto e escopo de reteste.

Contexto: auditoria concluída; vou autorizar implementação mínima para melhorar otimização DEX/R8 no release Android (Expo + EAS).

Regras de governança (obrigatórias):
- Antes de editar: mostrar plano e diff esperado; aguardar minha aprovação.
- Antes de eas build, push, submit ou upload Play: pedir aprovação separada.
- PROIBIDO: git push --force, alterar versionCode/versionName sem minha confirmação, remover permissões ainda necessárias, bump de Expo/RN sem plano de reteste.
- Minificação NÃO substitui testes funcionais manuais.

Implementação desejada (ajuste ao meu SDK — consulte documentação oficial da minha versão):
1. Se ausente, adicionar expo-build-properties compatível com meu expo no package.json (não inventar versão; usar mesma linha major do SDK).
2. Em app.json ou app.config, registrar plugin expo-build-properties com android.enableMinifyInReleaseBuilds: true. Não habilitar shrinkResources salvo documentação oficial e minha aprovação.
3. Para permissões confirmadas como desnecessárias, preferir android.blockedPermissions no Expo em vez de editar XML manual, salvo exceção justificada.
4. eas.json: se útil, criar ou ajustar perfil preview-optimized (extends preview, APK internal, autoIncrement coerente) para validar release otimizado antes do production AAB. Manter production como trilha do app bundle da loja (autoIncrement conforme projeto).
5. Mostrar diff arquivo a arquivo com uma linha de explicação cada. Sugerir mensagem de commit convencional (ex.: fix(android): …).
6. Listar comandos que EU executarei depois (npm install se necessário, eas build --profile …) — você NÃO executa build nem submit.

Após implementação no código (somente após minha OK em cada passo):
- Indicar testes estáticos disponíveis (npm run lint, npm test, tsc) se existirem no projeto.
- Listar fluxos manuais críticos para validar (notificações, telas principais, instalação limpa).

Entrega: diff proposto + sequência de validação; nenhum build automático.

Contexto: implementação de minificação release e ajustes de manifesto concluídos; preciso validar o release antes de confiar no Play Console.

Modo: VERIFICAÇÃO. Pode orientar comandos read-only; não publicar na Play nem executar submit sem minha aprovação.

1. Testes estáticos: rodar ou indicar npm run lint, npm test, typecheck se existirem; interpretar falhas relacionadas a minify/reflexão.

2. Comparação de artefatos (read-only):
   - Tamanho do arquivo .aab ou .apk (não confundir com download estimado na loja).
   - Quantidade e soma dos arquivos .dex dentro do AAB (zip/base/dex) — métrica técnica do bundle, não igual ao que cada usuário baixa.
   - Manifesto: permissões antes/depois (ex.: SYSTEM_ALERT_WINDOW presente ou ausente). Preferir bundletool/aapt2 se disponível; se não, declarar limitação da análise.
   - Deixar claro: % de ofuscação do Play ≠ % de redução de tamanho ≠ soma DEX.

3. Testes manuais no dispositivo (checklist): instalação limpa, fluxos que listo, notificações/alarmes se o app usa, regressões visuais. Minificação exige reteste — listar sinais de crash por ClassNotFound ou reflexão.

4. Google Play Console (orientação, sem pedir credenciais):
   - Onde encontrar relatório de otimização DEX / ofuscação e download estimado para a faixa publicada.
   - Tempo de processamento após upload; diferença entre versão em rascunho, teste fechado e produção.
   - Como comparar release anterior vs nova sem expor IDs de conta em material público.

5. Registro de resultados: tabela FATO (medidas locais que eu autorizar compartilhar) vs OBSERVAÇÃO PLAY (métricas do console em capturas sem dados sensíveis) vs EM ABERTO (itens só para documentação interna da equipe).

6. Limitações explícitas: validar com APK em perfil preview não prova sozinho o AAB production; versionCode pode diferir entre trilhas se autoIncrement/remote divergirem.

Entrega: relatório markdown curto para documentação interna + lista do que ainda falta evidenciar antes de artigo ou release notes públicas.