A Unity project can contain several Android manifest inputs: a custom manifest, text files supplied by plugins, and manifests inside Android libraries. A file under Assets/Plugins/Android is useful evidence, but it is not automatically the manifest that ships in your App Bundle. The Android build merges manifest inputs and build configuration into a final result. Android's manifest merger guide explains why a library declaration can appear, change, or conflict during that step.
A release review therefore has two questions: What do the visible source files request? What does the built artifact actually contain?
Start by inventorying text *Manifest.xml files and readable manifest metadata inside AARs under Assets/Plugins/Android, along with source dependency declarations. This source inventory does not inspect the final merged or binary manifest.
Start with a source inventory
Before changing a permission, note which file declared it and which plugin owns that file. A permission may be intentional for an SDK feature, or it may be an old declaration that the project no longer needs. Removing it without checking the plugin can break a real feature.
For each source manifest, review permission declarations, duplicate permissions, selected sensitive permissions, explicit debugging, cleartext and backup flags. If the project targets API 31 or higher, check for a missing android:exported attribute on components with intent filters. Record the source path and the reason for each observation. These are prompts for inspection, not a verdict on the shipped app.
| Question | Evidence to keep |
|---|---|
| Which source requested it? | Relative manifest or AAR path and plugin owner |
| Why is it present? | Feature or SDK documentation |
| Is it intended for this build variant? | Build profile and variant notes |
| What happened after merging? | Final merged manifest or artifact inspection |
| Who approved the decision? | Reviewer and date |
A duplicate declaration in source is worth explaining, but the final merge may resolve it. A missing declaration in the source scan is also not proof of absence: packages, generated Gradle files and external dependencies can contribute later.
Check exported components in context
An activity, service or receiver with an intent filter needs special attention. Android's activity manifest reference documents android:exported and its behavior. When the attribute is missing from a source component, inspect its intended accessibility before choosing a value. Do not set every component to true just to silence a warning.
After the build, inspect the merged manifest and the merger log. If you export the Unity Android project to Gradle and open it in Android Studio, the Merged Manifest view shows which source contributed each element and flags conflicts. Follow the chain from source finding to final declaration. If the result differs from what the team expected, fix the owning source or merger rule, rebuild, and inspect again.
Treat dependency warnings as leads
Also note dynamic versions and differing requested versions of the same Maven coordinate in source declarations. That does not tell you which version Gradle ultimately resolved, nor does it cover dependencies delivered outside the inspected source paths. Record the resolved dependency graph from the actual build when a conflict matters. Review bundled native libraries and binary manifests separately; a text scan cannot validate them.
A repeatable release check
- Run the local scan and assign every source-manifest finding to an owner.
- Explain each permission and exported component against the feature that uses it.
- Build the release variant and inspect its merged manifest and merge log. Record the build variant and Gradle task so the evidence can be reproduced.
- Inspect the final signed AAB, including its identity and version, with your normal Android release tooling. Android's App Bundle guide describes the artifact and its inspection tools.
- Test the behaviors that depend on those declarations on real devices.
- Attach the scan, merged-manifest evidence, build identifier and remaining manual decisions to the release review.
This workflow catches questionable source inputs early and still gives the final artifact the last word. A local settings or manifest scan cannot certify Play acceptance, privacy declarations, signing or device behavior.
The practical boundary is simple: keep a source finding, the merged result and the built artifact together. If they disagree, investigate before release rather than treating a local scan as final proof.
Editorial disclosure: This article was drafted primarily by Codex, an AI agent, using the linked Unity and Android documentation. The publisher is responsible for the final review.
Top comments (0)