Unity Android manifest checks: what source files can tell you

A Unity project may include multiple Android manifest inputs, such as custom manifests, plugin-supplied text files, and manifests within Android libraries. However, the manifest present in the final App Bundle is not directly derived from these source files. The Android build system merges all manifest inputs and build configurations into a single final manifest. The Android manifest merger guide explains how library declarations and conflicts can arise during this merging process.

When reviewing an Android project, it is crucial to understand what each source file requests and what the built artifact contains. Start by cataloging all manifest XML files and readable manifest metadata within the Assets/Plugins/Android directory, along with source dependency declarations. This initial inventory does not examine the merged or binary manifest.

Before removing any permission, investigate the source file that declared it and identify the plugin that owns it. Permissions may be intentional for specific SDK features or outdated declarations no longer in use. Removing a permission without checking the plugin could inadvertently break a real feature. For every source manifest, review permission declarations, duplicate permissions, selected sensitive permissions, explicit debugging, cleartext, and backup flags.

Additionally, for projects targeting API 31 or higher, verify that components with intent filters have an android:exported attribute present.

During the review, record the source path and the reason for each observation. These notes serve as prompts for further investigation, not as final verdicts on the shipped app. Consider the following questions when analyzing source files: Which source requested each manifest file? What is the relative manifest or AAR path and plugin owner? What is the purpose of the manifest (feature or SDK documentation)? Is it intended for this particular build variant? How does it affect the build profile and variant?

After merging, inspect the final merged manifest or artifact to determine any discrepancies. A missing declaration in the source scan may not indicate its absence in the final build, as packages, generated Gradle files, and external dependencies can contribute later. When checking exported components with intent filters, pay special attention to components lacking the android:exported attribute in the source.

Avoid setting every component to true merely to address warnings; instead, assess their intended accessibility before assigning a value.

After the build, inspect the merged manifest and the merger log to identify the source that contributed each element and any conflicts. If the merged manifest differs from expectations, adjust the owning source or merger rule, rebuild, and reinspect. Treat dependency warnings as potential leads when multiple requests for the same Maven coordinate exist. Record the resolved dependency graph from the actual build, especially when conflicts arise.

In addition to text scans, review bundled native libraries and binary manifests separately, as a text scan cannot validate them. If dependency warnings prompt further investigation, record the resolved dependency graph from the actual build.

To ensure a thorough release check, run the local scan and assign every source-manifest finding to an owner. Clearly explain each permission and exported component's relevance to the feature utilizing it. After building the release variant, inspect its merged manifest and merger log, while recording the build variant, Gradle task, and signed AAB details.

Refer to the Android App Bundle guide for inspection tools. Test the behaviors dependent on those declarations on real devices before attaching the scan, merged-manifest evidence, build identifier, and any remaining manual decisions to the release review.

While a local settings or manifest scan cannot certify Play Store acceptance, privacy declarations, signing, or device behavior, maintaining a source finding, merged result, and built artifact together is essential. If these elements disagree, investigate before release rather than treating a local scan as definitive proof. This workflow helps catch questionable source inputs early, allowing teams to address issues before the final release.