Manifesto Estrutura

Como montar um manifesto estrutura que não te cause dor de cabeça

A primeira coisa que você precisa entender é que a estrutura do manifesto não é sobre seguir um template bonitinho. É sobre declarar permissões, atividades, serviços e receivers de forma que o sistema operacional consiga resolver dependências sem falhar silenciosamente. Eu passei horas debugando um app que só quebrava em dispositivos Samsung com One UI 5. A causa? Um conflicts entre intent-filters declarados em bibliotecas diferentes dentro do manifesto estruturado. O erro nem aparecia no build. Apenas travava na inicialização. O manifesto estrutura é basicamente o arquivo XML que define a espinha dorsal do seu aplicativo. No ecossistema Android, esse arquivo se chama AndroidManifest.xml e fica na raiz do módulo. Ele contém o pacote, versão, permissões, componentes e intenções. Mas "estrutura" aqui se refere à forma como esses elementos se organizam hierarquicamente e como as ferramentas de build os interpretam. Uma estrutura bem montada segue uma ordem lógica: primeiro as declarações globais no tag manifest, depois permissões de instalação, depois os componentes (activities, services, receivers, providers), e por fim as declarações de aplicação e testes. A ordem não é cosmética. O aapt2 processa o arquivo em sequência e algumas resoluções de recurso dependem disso.

Passo a passo prático

Vamos começar com o esqueleto básico. Você precisa de pelo menos isto: namespace definido corretamente no tag root. Isso é o atributo xmlns que aponta para o namespace do Android. Se faltar ou estiver errado, o build quebra com erro de namespace. Não é opcional. O package deve ser único e consistente com o nome do seu módulo. Eu vi muita gente deixar o package diferente do applicationId no build.gradle. Funciona, mas gera problemas com deep links e compartilhamento de pacotes.

As permissões devem ser divididas em dois grupos: as que você pede ao usuário na instalação (permissions no root) e as que você define internamente (permissions com proteção). Permissões perigosas como câmera e localização precisam de solicitação runtime. O manifesto só declara. A lógica de pedir fica no código. Os componentes são o coração. Cada activity precisa ter seu intent-filter definido se for entrada da aplicação. Serviços precisam do nome da classe completa. Receivers podem ser estáticos ou dinâmicos. Providers exigem authorities únicas por pacote.

O problema que ninguém conta

Quando você integra múltiplas bibliotecas, cada uma pode tentar declarar a mesma activity ou o mesmo receiver. O merge do manifesto acontece automaticamente, mas conflitos silenciosos surgem quando duas bibliotecas declaram o mesmo intent-filter com diferentes categorias. Eu perdi um dia inteiro porque a biblioteca de analytics sobrescrevia o launch category de uma library de login. A activity de login simplesmente não abria. A solução foi adicionar um tools:replace no merging rules e forçar a prioridade. Outro problema comum: ferramentas de minificação como ProGuard podem remover componentes declarados no manifesto se você não configurar as regras de preservação. O manifesto estrutura permanece intacto, mas o app perde funcionalidades. Sempre adicione regras de keep para activities, services e receivers que você declarar.

Limitações e quando não usar

O manifesto estrutura tradicional tem um limite claro: ele não escala bem para apps modulares grandes. Quando você tem mais de dez módulos, o merge manual dos manifestos se torna um pesadelo de manutenção. Recomendo migrar para o sistema de módulos separados com manifestos individuais que são fundidos automaticamente pelo Gradle. Aí sim a estrutura faz sentido. Também não funciona bem para apps que precisam de componentes dinâmicos criados em runtime. Se seu app carrega plugins ou features sob demanda, o manifesto estático vai limitar sua arquitetura. Nesse caso, considere usar reflection ou componentes AIDL.

O que observar na prática

Um checklist rápido que uso antes de qualquer release: verifique se todas as activities têm intent-filter de launcher quando necessário. Confirme se as permissões não excedem o necessário para o core feature. Teste o merge do manifesto usando o comando gradlew processDebugManifest que gera o arquivo fundido em app/build/outputs/merged_manifests. Esse arquivo é onde você vê o resultado real do que o sistema vai executar, não o seu manifesto original. A estrutura do manifesto é simples na teoria mas traiçoeira na prática. Cada linha adicional adiciona uma nova camada de complexidade que só aparece quando o app está rodando em um dispositivo específico com uma versão específica do Android. Manter o arquivo limpo e documentado é o que separa quem resolve problemas rápido de quem passa dias procurando a causa raiz.