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
| Feature | Review focus |
|---|---|
| Display a number and open the dialer | Correct intent handling and user control |
| Place a call directly | Direct-call permission and appropriate runtime behavior |
| Observe telephony state | State-specific APIs and current access restrictions |
| Read call history | Restricted permission eligibility and role requirements |
| Obtain a phone number | API availability, roles and a fallback when unavailable |
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.
Choose who actually places the call
Suppose a shop listing has a Call button. If the intended experience is to open a dialer with the shop's number and let the user decide whether to call, design that handoff explicitly. It differs from an app directly initiating a call. The permission reference helps distinguish the relevant capabilities, but the API used by the feature determines what must be requested.
Keep the displayed number and the destination passed to the platform consistent. Test formatting and invalid input with synthetic numbers, and handle a device without a compatible dialer. Do not substitute an unrelated number or initiate a different action merely because the intended handler is unavailable.
Test telephony assumptions outside a single personal phone
A tablet may have no telephony feature, while a dual-SIM phone can have multiple subscriptions. A number may be unavailable even when an API call is permitted. Review the exact TelephonyManager method contract and any role or version conditions before interpreting its result.
Test missing information as a normal outcome. If an account form needs a contact number, let the person provide and verify it through the product's intended flow rather than treating a device value as guaranteed identity. A shared, transferred or multi-subscription device is not proof that a particular number belongs to the signed-in account holder.
Keep call-history access separate from dialing and state observation. Its sensitivity and distribution restrictions cannot be inferred from the fact that another phone-related permission was granted. Audit SDK additions so a dependency does not introduce call-log or phone-state declarations unrelated to the app's actual feature.
For a direct-call feature that legitimately requires a runtime grant, test denial and revocation at the operation boundary. Do not preserve an old granted flag as permanent authority. Confirm the intended user action still exists when a delayed permission response arrives, especially if the person navigated away from the contact screen.
Retain only the technical context needed to diagnose failures, such as the API path and non-sensitive error category. Avoid uploading phone numbers or call records merely to understand a permission problem. A useful release check establishes the exact capability used, its fallback and its device limitations without treating the phone permission group as a single unrestricted grant.
Sources and further reading
- Android Developers: Manifest.permission reference
- Google Play: Permissions and APIs that access sensitive information
- Android Developers: Request runtime permissions
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
