Build a Mobile App Permissions Audit That Includes SDK Additions

Start from the merged release manifest

Use the build's manifest merger information to identify declarations added by the app, product flavors and libraries. Save the final APK or bundle identity with the audit. Reviewing only src/main/AndroidManifest.xml can miss SDK additions.

Create a row for each permission with feature, source dependency, supported API range, grant mechanism, denial behavior and disclosure implications.

Ask whether a narrower API works

Alternatives depend on the feature. Do not remove a necessary permission without replacing the actual user workflow.

Test negative paths deliberately

For runtime permissions, test denial and revocation. For special access, test returning from settings without enabling it. For selected media, test a URI that is no longer available. Each path should produce a useful message and preserve unrelated functionality.

The Android permission model should drive the test plan, not an assumption that every permission uses the same dialog.

Reconcile with data practices

A permission does not automatically prove data is collected or shared, and the absence of a permission does not prove that no personal data leaves the app. Google Play Data safety requires a broader understanding of collection and SDK behavior.

Map each relevant permission to the associated data flow, then verify that the privacy policy and declarations describe the implemented behavior.

Close findings in a new release

Record whether a permission was removed, narrowed, justified or still requires work. Reinspect the built artifact and test the relevant feature. APKLint can support the static inventory and highlight sensitive declarations; the final audit needs runtime evidence and an accountable decision for each remaining permission.