READ_PHONE_STATE: What It Allows and What It Does Not

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

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.