O que é o manifest.xml e por que ele te dá dor de cabeça
O arquivo AndroidManifest.xml é o coração de qualquer app Android. Ele descreve para o sistema operacional tudo o que seu aplicativo precisa: permissões, componentes, intenções, versões mínimas do sistema. Sem ele, nada funciona. Mas muita gente tratava como algo decorativo até o dia em que o build falhava sem motivo claro. Um exemplo de manifesto pequeno é basicamente isso: uma versão enxuta do arquivo, com apenas o essencial, sem bagunça de permissões ou atividades que você nunca vai usar. O problema é que "pequeno" não significa "simples". Todo campo ali tem peso real.
exemplo de manifesto pequeno: estrutura base
Aqui está um exemplo que eu uso como ponto de partida há anos. É um projeto limpo, sem permissões extras, sem bibliotecas desnecessárias, só o que é estritamente necessário para o app rodar: <manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.seu.projeto"
android:versionCode="1"
android:versionName="1.0">
<uses-sdk android:minSdkVersion="21" android:targetSdkVersion="34" />
<application
android:allowBackup="true"
android:label="@string/app_name"
android:icon="@mipmap/ic_launcher"
android:theme="@style/AppTheme">
<activity android:name=".MainActivity"
android:exported="true">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Isso já compila. Já roda. Se você tá começando um projeto novo ou precisando de um template rápido para testar alguma configuração, esse é o ponto de partida.
Permissões: onde a maioria erra
Eu passei meses refatorando um app que tinha mais de 40 linhas de permissões no manifest. A maior parte era legado — bibliotecas antigas que puxavam permissões que nunca eram usadas. O tamanho do manifest crescia, as revisões da Play Store atrasavam, e o debug ficava mais lento a cada build. O workaround foi simples mas demorado: descomentei linha por linha, rodei o app em um dispositivo real, e verifiquei com o comando adb shell dumpsys package <package-name> cada permissão que o app realmente solicitava em runtime. As que sobravam foram removidas. Em dois builds, eu tinha um manifesto com menos da metade do tamanho original.
Uma coisa que poucos ensinam: permissões declaradas no manifest não exigem aprovação do usuário no Android 6.0+ apenas se forem permissões normais (normals). Para dangerous permissions, o usuário precisa aceitar via runtime request, mas a declaração no manifest continua obrigatória. Se você declarar uma permissão dangerous e não pedir no runtime, o app trava silenciosamente sem crash visível. Isso me custou três horas de debug uma vez.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Versioning e o problema do versionCode
O versionName é o que o usuário vê. O versionCode é o que importa para o Google Play. Se você já tentou atualizar um app e recebeu o erro "downgrade not allowed", sabe do que estou falando. O versionCode precisa ser um inteiro crescente a cada release. Cada build que você subir precisa ter um versionCode maior que o anterior. Sem exceção. Eu já vi devs esquecerem de atualizar o versionCode e perderem semanas porque o Play Store não aceitava o upload. A solução prática é configurar o versionCode automaticamente no build.gradle usando uma expressão como o timestamp da build ou um contador incremental. Assim você não depende de memória ou planilha manual.
Quando o manifesto pequeno não serve
O exemplo que mostrei funciona bem para protótipos, projetos educacionais e apps simples. Mas ele não cobre casos reais. Se seu app precisa de notificações, acesso à câmera, localização, ou serviços em background, o manifesto precisa crescer. E crescer corretamente. Algumas armadilhas comuns:
Activities não declaradas — Se você cria uma Activity e não a declara no manifest, o app fecha com ActivityNotFoundException. Isso parece óbvio mas acontece todo dia em código legado onde atividades são movidas entre módulos. Exported mal configurado — Desde o Android 12, toda activity, service ou receiver que recebe intents de fora do app precisa ter android:exported explicitamente definido. Se você deixar como false por padrão e tentar receber intents de outra app, o sistema ignora sua resposta. Eu configurei exportado como true em um receiver que deveria ser privado e levou horas para descobrir o problema.
Meta-dados duplicados — Bibliotecas diferentes podem declarar o mesmo meta-data com valores diferentes. O último a ser mesclado vence, mas o build não avisa. Se seu Firebase config ou seu chave de API sumiram do runtime, essa é a causa provável.
Alternativa para quem quer controle total
Se você tá cansado de lidar com merges automáticos do Gradle e quer ter controle total sobre o manifesto final, pode usar o recurso de manifest merger rule. Ele permite que você defina regras explícitas de merge no seu arquivo AndroidManifest.xml do módulo, sobreescrevendo valores vindos de dependências. Não é para iniciantes, mas resolve 80% dos problemas de conflito que aparecem em projetos grandes. Depois de mexer com manifestos por anos, eu cheguei à conclusão de que o arquivo mais importante do seu projeto Android é o que você nunca olha. Ele é pequeno, quase invisível, mas qualquer erro nele para tudo. Manter um exemplo de manifesto pequeno como template de referência e ir adicionando apenas o necessário é a abordagem que me poupou mais tempo.
