Android Phone Permissions: Separate Calls, State and Call Logs

Begin with the user action

If the app only needs to let a person call a displayed number, a dial intent that hands control to a phone app may be more appropriate than directly initiating the call. If the feature needs call history, that is a much more sensitive and policy-restricted data flow.

Consult the current permission reference for the exact API and Android version. Names that look related do not necessarily grant overlapping access.

Separate common requirements

Do not use permission groups as a promise that granting one permission grants every other permission in that group.

Check distribution policy independently

Google Play's sensitive-permission policy can limit eligible uses even when an Android API technically allows a request. A successful permission dialog on a test device does not establish Play approval.

Document the core feature, why a less sensitive alternative is insufficient, and how the data is handled. Keep declarations, in-app explanations and privacy disclosures consistent.

Test difficult device states

Use devices or emulators representing no telephony capability, no SIM, multiple SIMs and denied access. Handle missing values without converting them into a shared fake identifier or crashing the screen.

For runtime permissions, follow the current request pattern and recheck at the point of use. A user can change access after the app has started.

Inspect what shipped

APKLint's permission checker helps review the final manifest and identify unexpected phone-related declarations. It cannot confirm carrier data availability, role eligibility or policy acceptance. Those require device tests and a review of the actual feature and distribution requirements.