On July 15, 2026, Google Play announced an update to the SMS and Call Log Permissions policy. The Policy Deadlines table lists it under Use of SMS or call log permission groups, with deadline 2027-01-27. The published change is specific: Play will no longer permit account verification via phone call as a use case for the READ_CALL_LOG permission. If your app still confirms a missed call or flash-call OTP by reading the call log, that exception is scheduled to disappear. KappS is writing this as a policy walkthrough, not as a substitute for the live Help pages.

What you are solving today: detect whether any binary or SDK still uses READ_CALL_LOG to verify that a phone call arrived; pick a permission-light alternative from the preview Help article; remove the permission if that was the only reason you held it; and resubmit the Permissions Declaration Form in Play Console so the declared use matches the shipping build. Recheck current Play Console Help for the exact form labels — this tutorial only restates what those three Help pages publish.

What Play published (deadline, current page, preview)

Three official pages describe the same deadline in different lengths:

Read the two policy articles side by side before you change the manifest. Default SMS / Phone / Assistant handler rules stay. Other exception rows stay, including Call-based authentication and authorization in banking or brokerage apps. The row that goes away is specifically account verification via phone call that confirms receipt by reading the call log — not every call-related exception in the table.

Both the current page and the preview still list this as an invalid use: account or device authentication via broad access to SMS or Call Log permissions. After the deadline, missed-call / flash-call OTP that depends on READ_CALL_LOG sits in that invalid bucket unless you have migrated to a published alternative.

Step 1 — Detect if you use READ_CALL_LOG for missed-call / flash-call OTP

Do not start in Console. Start with the binary and every merged library. The exception Play is removing is written as: the device may be verified by transmitting a phone call; receipt is confirmed by verifying the number in a call log. Eligible permission on the current page: READ_CALL_LOG.

That is the missed-call / flash-call pattern: your backend places (or asks the user to wait for) a short incoming call, then the app reads the call log to prove the device received that number. If any feature, SDK, or “verification provider” still does that, you are on the exception that ends 2027-01-27.

Walk the real artifacts, not the store listing copy:

  1. Search the merged manifest and dependency manifests for READ_CALL_LOG (and, if present, other Call Log group permissions you only added for this flow).
  2. Search code and SDK docs for call-log queries tied to account signup, login, device binding, or OTP — not for a default dialer or a remaining exception.
  3. Ask whether the product confirms “the call arrived” by reading the log, or whether it is a banking/brokerage call-based authentication and authorization flow that the preview still lists as its own exception row.
  4. If the user refuses READ_CALL_LOG, does signup still work? If the only path is the call log, you do not have a permission-light fallback yet.
  5. Is the feature promoted on the Play listing? Restricted-permission Help (both current and preview) says you may only access Call Log or SMS permissions for permitted uses that enable critical core functionality, and the listing should prominently document that core feature.

Do not confuse this check with default-handler status. Apps that are actively registered as the default SMS, Phone, or Assistant handler still follow the handler table — they must be the registered handler before prompting for these permissions, and they must stop using the permission when they are no longer the default. That path is unchanged. This tutorial is for apps that held READ_CALL_LOG under the account verification via phone call exception.

Also do not treat the remaining banking/brokerage row as a rename of flash-call OTP. The preview keeps “Call-based authentication and authorization in banking or brokerage apps” for banking or brokerage apps that facilitate secure device-based financial transactions for their service. If you are not that product, do not declare that row to keep reading the call log for signup OTP.

Step 2 — Pick a permission-light alternative

Policy Deadlines and the preview Alternatives section name the same family of tools. Play’s stated goal is to verify accounts without requiring sensitive app permissions. Published options — do not invent extra APIs:

  1. Digital Credentials API — the preview’s recommended option for verifying phone numbers securely without sensitive app permissions, used directly or through a verification provider built upon it. Policy Deadlines uses the same wording for account verification.
  2. SMS Retriever API — perform SMS-based user verification automatically, without requiring the user to type a code and without extra app permissions. If SMS Retriever is not an option, both the current page and the preview say users can manually enter a verification code.
  3. Incoming Call Retriever API — preview only (the post-deadline article). Play says you can perform phone number verification through an incoming phone call. Access is restricted to the specific incoming number needed for verification, within a designated phone number range provided by the app. That scoped path is how Play describes dropping broad call-log permission while still using an incoming call.

Choose from what those pages publish. A flash-call SDK that still reads the entire call log is not an “Incoming Call Retriever” migration. The preview’s point is scoped access to a designated number range — no broad call-log permission.

Other alternatives on the same table are not substitutes for this OTP job: SMS Intent (initiate a text), Share Intent (share or invite), Dial Intent (open the phone app to place a call, without CALL_PHONE). Use those for the uses Play assigned them; they do not replace account verification.

If a vendor still tells you to keep READ_CALL_LOG for “account verification via phone call,” that sentence matches the exception Play is deleting. Replace the vendor flow or replace the vendor.

Step 3 — Remove the permission and update the Permissions Declaration Form

Both the current policy and the preview say: if the app does not qualify for Call Log or SMS permissions, you must remove these permissions from your app’s manifest. After you migrate the verification feature, drop READ_CALL_LOG from the app manifest and from any leftover library merge that only existed for flash-call OTP.

Then update Console. Official points, without extra buttons:

  1. If you still meet a permitted use or a remaining exception, you must declare any Call Log or SMS permissions directly through Google Play Console.
  2. Apps that fail to meet policy requirements or lack a Permissions Declaration Form may be removed from Google Play.
  3. If you change the way the app uses these restricted permissions, you must submit the Permissions Declaration Form again with updated and accurate information. Deceptive and non-declared uses may result in suspension of the app and/or termination of the developer account.

A migration off flash-call OTP is a change in how you use the permission. Even if the new build no longer requests READ_CALL_LOG, resubmit so Play is not reviewing a form that still claims “account verification via phone call.” If another remaining exception (backup, caller ID, companion device, and the other rows that still appear in the preview table) is the real reason you keep Call Log or SMS permissions, the new form must describe that use — not the deleted OTP exception.

This page does not invent a Console menu path or a questionnaire label beyond the name Play publishes: Permissions Declaration Form. Use the labels that appear in your account, and re-read the live Help article linked from that form.

Old APKs: both articles still describe a narrow policy exception for APKs published before January 1, 2019 that you can no longer change. You declare those version codes in the APK Exceptions field of the same form, serve alternative compliant APKs to Android Oreo (API 26) or higher, and keep the excepted APKs to a very small percentage of installs. That path is not a way to keep shipping flash-call OTP on current users.

Step 4 — What fails after 2027-01-27

Play publishes outcomes. Do not substitute folklore:

If Console shows a new questionnaire after you read this, follow the live Help article linked from that form. This page does not invent extra buttons, extra API class names, or extra dates beyond 2026-07-15 (announced) and 2027-01-27 (Policy Deadlines / effective date on the current-page banner and the preview).

A 10-minute checklist

  1. Search every active bundle (including test tracks you still serve) for READ_CALL_LOG.
  2. Mark each use: missed-call / flash-call account verification (the row being removed), a remaining exception in the preview table, or a default SMS / Phone / Assistant handler.
  3. If the only reason you hold the permission is phone-call account verification, pick Digital Credentials API (directly or via a provider built on it), SMS Retriever API or manual OTP, or Incoming Call Retriever API scoped to a designated number range.
  4. Remove READ_CALL_LOG from the manifest and from any library that existed only for that OTP path.
  5. Open Play Console and submit an updated Permissions Declaration Form that matches the new permission set and remaining uses.
  6. Confirm the store listing still describes core functionality that matches any Call Log or SMS access you still request.
  7. Re-read current Policy Deadlines, the current SMS/Call Log article, and the preview before you ship the next bundle.

The one-line version

As of the 2027-01-27 deadline announced July 15, 2026, Play’s SMS and Call Log policy no longer allows READ_CALL_LOG for account verification via phone call; migrate that missed-call / flash-call OTP to Digital Credentials API, SMS Retriever (or manual OTP), or Incoming Call Retriever, then drop the permission and resubmit the Permissions Declaration Form.

Sources