This guide is for founders and small businesses with Android apps that verify users by phone number. Google Play’s July 2026 policy announcement says account verification via phone call is no longer an approved use case for the READ_CALL_LOG permission, with at least 30 days from July 15, 2026 to comply.
The practical impact is simple: if your app depends on reading call logs to confirm a user’s number, you should plan a migration before your next Google Play update. The safest alternatives are usually the Digital Credentials API, the SMS Retriever API, or a verification provider built around approved Android flows.
Founder takeaway: check this before a rushed store submission. Removing a sensitive permission often touches app code, backend verification, privacy copy, QA, and support scripts.
What changed in Google Play phone verification?
Google’s July 15, 2026 policy announcement states that the SMS and Call Log Permissions policy will no longer permit account verification via phone call as a use case for READ_CALL_LOG. Google recommends the Digital Credentials API or the SMS Retriever API as alternatives.
This matters most for apps that used call-based verification to reduce SMS cost or improve conversion in markets where one-time password delivery is unreliable. Those goals are understandable, but for a Play-listed app the permission model now needs to change.
Which apps should review this now?
You should review your Android verification flow if the app includes sign-up, login, marketplace onboarding, driver or worker verification, booking accounts, fintech-style identity steps, or customer support account recovery. Even if your app is built with Flutter, React Native, Expo, or Kotlin Multiplatform, the Android permission and Play Console disclosure still apply.
Look for these warning signs in your backlog or codebase:
- The app requests
READ_CALL_LOGor related call permissions. - The verification provider uses flash calls, missed calls, or automatic call detection.
- The privacy policy mentions call logs or phone state access.
- Google Play Console has sensitive permission declarations tied to verification.
- Your team cannot explain the fallback if call verification is rejected.
Migration options: SMS Retriever, Digital Credentials, or provider change
| Option | Best for | Trade-off |
|---|---|---|
| SMS Retriever API | Apps that can keep SMS OTP but want automatic code capture without SMS permissions. | Still depends on SMS delivery and SMS provider cost. |
| Digital Credentials API | Apps that want a modern phone verification path without sensitive call-log permissions. | May require provider support and extra implementation planning. |
| Verification provider migration | Teams using a third-party service that currently relies on flash-call verification. | Requires contract, pricing, SDK, and QA review. |
| Manual fallback | Low-volume B2B apps where support-assisted verification is acceptable. | Does not scale well and must be secure enough for real users. |
For many MVPs, SMS Retriever is the fastest path because it keeps the familiar OTP model while avoiding extra app permissions. Google’s documentation explains that SMS Retriever can verify a user automatically without manual code entry and without requiring additional app permissions. For higher-risk account flows, Digital Credentials may be worth evaluating earlier.
Cost and timeline for a small app
A realistic migration for a small Android app is usually measured in days, not months, if the verification flow is isolated. Budget roughly 2-4 hours for discovery, 4-12 hours for app changes, 4-10 hours for backend or provider work, 3-6 hours for privacy and Play Console updates, and 6-12 hours for QA across devices and failure states.
The expensive cases are older apps where phone verification is tangled into onboarding, referral rewards, fraud checks, analytics, or customer support tooling. If the app also needs the August 31, 2026 Android target API 36 or Play Billing Library 8 work, combine the release planning so QA happens once. Related guides: Google Play target API deadline, Billing Library 8 upgrade cost, and mobile app compliance cost.
Founder checklist before the next Android release
- Search the app code and dependency list for
READ_CALL_LOG. - Ask your verification provider whether flash-call or call-log verification is used.
- Pick the replacement flow: SMS Retriever, Digital Credentials, or a new provider.
- Update privacy policy, Data safety answers, and sensitive permission declarations.
- Test sign-up, login, retry, timeout, SIM changes, dual-SIM devices, and poor network cases.
- Prepare a fallback for users who cannot receive SMS or complete automatic verification.
- Submit the update early enough to avoid a deadline-driven rejection.
FAQ
Can Android apps still verify users by phone number?
Yes. The issue is not phone verification itself; it is using READ_CALL_LOG for account verification via phone call. Apps can still use approved alternatives such as SMS Retriever, Digital Credentials, or compliant verification providers.
Does SMS Retriever remove SMS costs?
No. SMS Retriever improves the user experience and avoids extra SMS permissions, but your server or provider still sends an SMS message. If SMS delivery cost is the main issue, review provider pricing and regional routing separately.
Should this be fixed before other Android 2026 updates?
If the app currently requests READ_CALL_LOG for verification, treat it as a release blocker. It can be planned alongside API 36, Billing Library 8, and Data safety updates, but it should not be left until submission week.
Final takeaway
The Google Play READ_CALL_LOG verification change is a good example of mobile maintenance becoming product risk. A small permission decision can affect sign-up conversion, store approval, support, and launch timing.
Need to update an Android verification flow?
Newlin can review your current sign-up flow, choose a compliant replacement, update the app, and prepare the Google Play release without unnecessary rebuilds.
Request a free app consult →