Identify the exact API you need
Start with the method your feature calls and read its current permission and role requirements. The permission reference is the authority for the declaration; individual telephony APIs may impose additional restrictions that vary by Android version and app role.
Do not request phone state merely because an old analytics SDK tutorial recommends it. Modern identification, advertising and account flows should use the appropriate dedicated APIs and privacy controls.
Keep these capabilities separate
| Desired information or action | What to investigate |
|---|---|
| Telephony state | Relevant state API and current permission rules |
| User's phone number | Number-specific APIs, roles and availability |
| Call history | Restricted call-log access and distribution policy |
| Start a phone call | Dial intent versus direct-call permission |
| Advertising identifier | Advertising-ID API and consent requirements |
A device may have no SIM, multiple subscriptions or unavailable information. Even with a grant, the result may not be a useful stable identifier.
Request in context and handle refusal
For an ordinary runtime grant, follow the permission request flow. Explain the feature requiring telephony information and keep unrelated functions available when access is declined.
Do not persist the fact that the user once granted access as a permanent authorization. Recheck before the operation and handle missing or changed subscription state.
Do not substitute identifiers
Using a hardware identifier to replace a resettable advertising identifier can conflict with privacy expectations and platform restrictions. An unavailable advertising ID is not a reason to request broader phone permissions. Review the advertising-ID guidance for the actual advertising use case.
Audit SDK contributions
Inspect the merged release manifest to see whether a dependency introduced READ_PHONE_STATE. If it is unnecessary, update or configure the dependency and verify that removing the declaration does not break a legitimate feature.
APKLint can identify the permission in a manifest and help flag its sensitivity. It cannot determine whether the device will return a specific telephony value or whether your use meets Google Play's separate policy requirements.
Find why the declaration entered the release
Suppose a release manifest contains READ_PHONE_STATE even though the app has no visible telephony feature. Compare the merged manifest with the source manifests and identify the dependency that contributed it. Review that dependency's current configuration and the API it actually calls. An old manifest line is not sufficient evidence that the permission remains necessary.
The TelephonyManager reference documents method-specific access and result conditions. Read the exact method contract rather than assuming phone-state access supplies a phone number, unrestricted hardware identifier or call history. Those are different data and access questions.
Remove an unnecessary request with feature evidence
Update or configure the owning SDK through its supported settings, rebuild and inspect the final manifest again. Exercise the SDK feature that the application actually uses with the permission absent. If it fails, capture the protected API call and determine whether the feature needs a narrower implementation, a supported replacement or a truthful capability limitation.
Do not solve an unavailable advertising identifier by introducing phone-state access and substituting a device identifier. A resettable advertising signal and a telephony value have different purposes and privacy properties. Keep account identity, device diagnostics and advertising measurement separated in the application's design.
For a legitimate state-related feature, test a device without a SIM, a device with multiple subscriptions and a denied grant. A successful call can still return information unsuitable for the product's assumption. Show an unavailable state rather than converting missing data into a common fake identifier that merges unrelated users or sessions.
Recheck access when the operation starts and handle changes after returning from settings. If the feature listens for telephony changes, align listener registration and cleanup with its actual lifecycle. Avoid retaining a listener indefinitely after the user disables the associated feature.
Record the API, device version, app role where relevant and observed failure category without exposing private telephony values. Then compare clean installation with an update from the previous version. The repaired release should either justify the exact access through a working feature or remove the unnecessary declaration and request. A manifest scanner can locate the permission, but runtime evidence establishes what the application does with it.
Sources and further reading
- Android Developers: Manifest.permission reference
- Android Developers: Request runtime permissions
- Android Developers: Best practices for unique identifiers
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
