Android APK Security Review: From Build Flags to Runtime Evidence

Freeze the release identity

Record the APK hash, package identifier, version code, signing certificate and distribution channel. For split delivery, keep the base and relevant configuration or feature splits together. An isolated base APK may omit code and resources used on the tested device.

The review should be reproducible against that exact artifact, not an unspecified file called app-final.apk that gets overwritten later.

Review the release boundary

Inspect debug flags, exported components, permissions, cleartext rules and included SDKs. Compare each observation with an expected configuration approved by the feature owner.

A risk is contextual. A launcher activity needs an external entry point, while an internal account-management activity may not.

Trace one sensitive user flow

Choose a high-value flow such as login, purchase confirmation or exporting private data. Follow its local storage, network client, error handling and authorization boundaries. The Android security guidance and MASTG provide reference points, but the evidence must come from your implementation.

Do not assume a client-side check protects the backend. Server authorization must remain correct when client requests are unexpected or stale.

Verify remediation in a new artifact

After a fix, rebuild the intended variant and repeat the relevant checks. Confirm that the updated package is the one promoted to the correct track. A fixed source branch does not protect users still receiving the previous artifact.

Make the report actionable

Attach evidence, affected version, owner and retest condition to each issue. APKLint's Android security scanner can speed up initial package review, but it does not certify the app, verify every code path or guarantee Google Play acceptance. Preserve a separate list of untested areas rather than presenting them as passed.