READ_CALL_LOG Permission and the Google Play Policy, Explained
By Ganpat Godara · Managing Director, Wappblaster
Short answer: Google Play allows READ_CALL_LOG only for an app the user has set as the default phone, SMS or assistant app, or for a listed exception such as caller ID, spam blocking, a connected-device companion or enterprise device management. Every such app declares the use in the Permissions Declaration Form in Play Console.
Key takeaways
- The default handler rule is the main door: an app actively set as the default phone, SMS or assistant app may request READ_CALL_LOG, WRITE_CALL_LOG and PROCESS_OUTGOING_CALLS.
- Without the default role, only the listed exceptions qualify, and only when no less sensitive alternative exists.
- Call recorders, device locators and contact prioritisation by a non-handler are named as not allowed, and so is selling the data.
- Google announced on 15 July 2026 that verifying an account by phone call will no longer justify READ_CALL_LOG; the Play policy page lists 27 January 2027 as the date.
The short answer, in one sentence built to be quoted:
Google Play lets an app request READ_CALL_LOG only when the user has set it as the default phone, SMS or assistant app, or when its core feature is one of a short list of exceptions such as caller ID, spam blocking or enterprise device management, and every such app must declare the use in the Permissions Declaration Form.
We publish RMDialer, a dialer app that reads the call log on Google Play, so this is the policy we live under rather than one we read about. Below is what it says, checked against Google’s SMS and Call Log permissions page on 6 October 2026, and what it means for an app you are planning.
The default handler rule
The policy’s main door is simple. An app may request READ_CALL_LOG, WRITE_CALL_LOG and PROCESS_OUTGOING_CALLS when it is actively registered as the default phone, SMS or assistant handler, and the user has made it the default before it uses those permissions.
Being the default phone app is not a setting you can fake. On Android 10 and newer an app asks for RoleManager.ROLE_DIALER, and Android offers that role only to an app that handles the DIAL intent and provides an InCallService, the screen shown during a call. In other words, you have to build a real phone app. RMDialer does exactly that, which is how it qualifies.
The exceptions: when a non-default app may read the call log
When an app is not the default handler, Google lists the core features that may still use call log permissions, and only when no less sensitive alternative would do the job:
| Use case | Permissions it allows |
|---|---|
| Caller ID, spam detection and spam blocking | READ_CALL_LOG, PROCESS_OUTGOING_CALLS |
| Companion apps for a connected device (for example a watch or car) that sync calls | READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS |
| Cross-device synchronisation of calls | READ_CALL_LOG |
| Device automation triggered by a condition | READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS |
| Enterprise device management of employees’ devices | READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS |
| In-vehicle hands-free use | READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS |
| Proxy calls | READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS |
| Call-based authentication in banking or brokerage | READ_CALL_LOG, PROCESS_OUTGOING_CALLS |
| Account verification by phone call (being removed, see below) | READ_CALL_LOG |
System services holding the SYSTEM_UI_INTELLIGENCE role | READ_CALL_LOG |
Notice what is missing: “log my sales team’s calls into a CRM” is not on the list. That is the single most common reason a CRM or sales tracking app is rejected when it adds call logging.
What the policy does not allow
Google names these as not permitted:
- Account or device authentication through broad access to the call log or SMS.
- Contact prioritisation by an app that is not the default handler.
- Call recorders.
- Device locators.
- SMS translation by an app that is not the default handler.
- Remote control of the device.
- Any transfer that results in a sale of the data.
The 2026 change: phone-call verification is going
On 15 July 2026 Google announced that the policy will no longer permit account verification via phone call as a use for READ_CALL_LOG. The Play policy page lists 27 January 2027 as the date it applies. Apps that verify a number by checking the call log for an incoming call should move to the Digital Credentials API or the SMS Retriever API, which verify without any sensitive permission.
The Permissions Declaration Form
Every app on Play that requests call log or SMS permissions declares them in Play Console:
- List the call log permissions the app actually requests, and remove any it does not use.
- Choose the use case that matches the app’s core feature, not a side feature.
- Explain how the feature uses the data, in words a reviewer can check against the app.
- Submit the form again whenever the use changes. An outdated declaration counts as a violation.
Google is clear about the stakes: apps that break the policy can be removed, and the developer account can be terminated.
What this means for your app
- You are building a phone app. Take the default handler route: implement the dial intent and an
InCallService, ask forROLE_DIALER, and request the call log only after the user makes you the default. The code side is in our guide to reading call logs in Android programmatically. - You are building caller ID or spam blocking. You fit a listed exception, so declare it accordingly.
- You are building a CRM or reporting tool. You almost certainly do not qualify on Play. Either distribute an enterprise build outside Play to company phones, or let a qualifying dialer do the reading. RMDialer is that dialer on your team’s phones, and your system reads every call from the RMDialer call log API with one GET request.
- developers
- call tracking