What would you inspect in an Android app’s merged release manifest?
Instruction: Explain the manifest’s purpose, then describe a release review after adding a library. Cover components, export/access rules, permissions, features, build identity and merged declarations.
Updated
Official answer
AndroidManifest.xml describes app entry points and configuration to build tools, the system and distribution tooling. A release is governed by the merged manifest, which can combine app, variant and library declarations; reviewing only the main source file can miss an added component or permission.
I would inspect the intended release variant for declared activities, services, providers and manifest receivers; explicit export/access rules; intent filters; requested permissions; required or optional device features; and application metadata such as the network-security configuration. Dynamically registered receivers are a separate registration path. An intent filter describes routing, not caller authorization.
In an Android Gradle build, applicationId determines installed app identity and the packaged manifest's package value; namespace controls generated-code naming. They can differ. SDK and variant settings can also come from the build configuration, so I would compare the effective artifact rather than infer everything from a source package attribute.
For a newly added SDK, inspect the merger report to find the origin of unexpected entries. Remove or override only declarations whose need and effect are understood, then test the dependent feature. Do not blindly delete a required provider just to make the manifest shorter.
Finally, verify that runtime permissions are requested and handled where required; manifest declaration is not user consent or a runtime grant. Test external entry points with unauthorized and malformed input, and check that debug-only configuration did not enter the release.
Manifest declarations, Manifest merger behavior, Application ID and namespace