Android 17 SMS OTP delay: why auto-read breaks in 2027 and the India fix

Summary. Android 17 (API level 37), released on 16 June 2026, holds back standard SMS messages containing a one-time password from most apps that target API 37: for three hours the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider queries are filtered. Exempt apps include the default SMS app, the assistant app and connected-device companion apps. A second change already hits every app on an Android 17 device: WebOTP-format messages are hidden for three hours from apps that are not the domain-verified recipient. Google's fixes are the SMS Retriever API (an 11-character app hash in a message of at most 140 bytes) and the SMS User Consent API (one tap to share one message). Google's blog said Play will require API 37 in August 2027, while Play Console Help still lists only the API 36 rule. In India the slow step is the DLT template change under TRAI's TCCCPR 2018, amended again on 18 September and 4 November 2026. WhatsApp templates and passkeys cut OTP volume, carrier verification lists no Indian carrier yet, and RBI's 2025 directions keep SMS OTP lawful.

About this article. For Android engineers and product owners at Indian banks, fintechs, ecommerce and delivery companies whose apps read OTP SMS. On 7 November 2026 we checked platform claims against Google's Android, Chrome, Firebase and Play documentation, WhatsApp claims against Meta's developer pages, and regulatory claims against TRAI's gazette texts (TCCCPR 2018 as amended to 4 November 2026) and RBI's Directions of 25 September 2025. This is general information, not legal advice; Google can revise these pages at any time, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What Android 17 changed

Two Google pages describe the change. The one for apps targeting Android 17 covers standard SMS; the one for all apps covers the two special OTP formats on any Android 17 device, whatever your targetSdkVersion. Google's launch post lists the exempt apps.

Nothing is blocked for the user, who still sees the message and can type the code; your app sees it three hours later, after the code has expired. Google does not say how the system detects an OTP, so rewording templates to dodge it is a poor bet. Google tells apps that extract OTPs from SMS to move to SMS Retriever or SMS User Consent. Our Android 17 API 37 breaking-changes guide covers the other targeted changes.

Why auto-fill breaks, and why it looks like a UX bug

Many Indian apps auto-fill OTPs the same way: hold RECEIVE_SMS or READ_SMS, catch the SMS broadcast or query the inbox, and pull a 6-digit code out with a regular expression. Once the app targets API 37, both routes return nothing for that message for three hours.

On Google Play these permissions are open only to default SMS, phone or assistant handlers and to approved exceptions such as SMS-based financial transactions (Google's example is UPI) and SMS-based money management. So the change lands hardest on Indian payments, lending and budgeting apps.

Nothing crashes: the OTP screen waits while the user copies the code or gives up, so the failure shows in conversion, not crash rates. Log whether each code was auto-filled, typed or timed out before you change anything.

Three places hide SMS reading:

• Third-party SDKs. Check the merged manifest, not only your own.

• Cross-platform plugins. React Native and Flutter plugins that read SMS directly hit the same wall; those that wrap SMS Retriever or User Consent do not.

• Web and app sharing one template. If your website sends WebOTP-format messages and your app reads SMS directly, the app counts as the recipient only if Android's domain verification links it to that domain. That applies on Android 17 devices today, whatever you target.

When it hits you: the dates

The standard-SMS delay depends on your target API level, so what matters is when you must target 37. Sources: Google's Beta 1, resizability and launch posts, and Play Console Help.

Updates targeting API 36 stay acceptable until August 2027. The last two rules took effect on 31 August (2025 for API 35, 2026 for API 36), so plan for 31 August 2027 and finish the OTP migration by June 2027 to leave room for a staged rollout. Our Google Play API 37 deadline checklist covers the wider Android 17 work.

The India fix: choose a path for each flow

There is no single replacement. Pick per flow, by who writes the message and whether you need SMS at all. Sources: Google's Retriever, User Consent, WebOTP and phone-verification guides and Meta's template documentation.

The first two are Google's named fixes. Play's policy page lists the Digital Credentials API first among its recommended options for phone verification, then SMS Retriever and User Consent. The rest cut how often you need one.

SMS Retriever: the default when you own the template

SMS Retriever, part of Google Play services, hands your app one message carrying its hash, without any SMS permission. It needs a minSdkVersion of 19 and a compileSdkVersion of 28 or higher.

1. Compute the hash from the right certificate. It is the first 11 characters of a base64-encoded SHA-256 of your package name and signing certificate. With Play App Signing, download deployment_cert.der from the App signing section of Play Console; debug and upload keys give different hashes. Google says not to put a hash computed on the device into your messages.

1. Rewrite the message. At most 140 bytes, containing the one-time code and the 11-character hash.

1. Listen before you request the SMS. startSmsRetriever() waits up to five minutes for one matching message.

1. Receive it safely. Protect the receiver with com.google.android.gms.auth.api.phone.permission.SEND (Play services 19.8.31 or higher) so only Play services can deliver the broadcast, and do not declare that permission for the app itself. The sender address extra arrives from Play services 24.20.

1. Verify on the server. Check the code is valid and unexpired, mark the number verified, then delete the code. Google says codes are generated and checked only on the server.

            val client = SmsRetriever.getClient(context)
client.startSmsRetriever()
    .addOnSuccessListener { requestOtpFromServer(phoneNumber) } // send SMS only after listening starts
    .addOnFailureListener { showManualEntry() }                 // manual entry stays available
          

If the same OTP serves your website, one template can carry both formats. WebOTP needs @host #code as the last line, and Chrome lists a message ending in an app hash as malformed, so the hash goes in the body:

            482913 is your ExampleApp login code. Do not share it with anyone. FA+9qCX9VSu
@example.com #482913
          

That is Google's sample hash; yours will differ. The message is 99 characters of plain Latin text. Hindi or another Indian script goes out as Unicode (UCS-2) at two bytes per character, so 140 bytes holds only 70 characters; test regional-language templates before you file them.

SMS User Consent: when someone else writes the SMS

Some OTPs are not yours to change: a card issuer's code, a bank's account-linking code, a partner's message. User Consent is Google's answer for that case. Your app calls startSmsUserConsent(); when a matching message arrives, the device asks the user whether to share that one message, and if they agree you get the full text.

For five minutes, a message triggers the prompt only if it contains a 4 to 10 character alphanumeric string with at least one digit and, if you passed a sender number, came from that number. Messages that arrived earlier are not forwarded. Chrome's WebOTP FAQ adds that the prompt does not appear when the sender is in the user's contacts.

Two India cautions. The sender filter takes a phone number while Indian OTPs come from alphanumeric DLT headers, so test with your real header or pass null. And each message costs a tap, so this is the fallback, not the primary flow.

DLT and TRAI: the part that is not code

India's commercial SMS, OTPs included, runs on the distributed ledger (DLT) system under TRAI's Telecom Commercial Communications Customer Preference Regulations, 2018 (TCCCPR). Senders register headers and content templates, and messages are scrubbed against them, so adding a hash or a WebOTP line is a template change. Three amendments matter:

• February 2025. Operators may allow more than three variables only with recorded justification, and then only if each variable is pre-tagged and at least 30% of the template is fixed text. Each template may link to one header, and templates unused for 90 days are deactivated until the sender asks for reactivation.

• September 2026. The Third Amendment moved OTPs for app login, password reset and two-factor authentication into the definition of service messages. A template found on complaint to be in the wrong category is blacklisted, and five such blacklistings in 90 days suspend the sender for a month or until all its templates are re-verified, whichever is later. That provision starts 90 days after gazette publication: 17 December 2026 if counted from the 18 September notification date.

• November 2026. The Fourth Amendment of 4 November postpones regulation 35A, a charge of up to 5 paise a minute on A2P voice calls, to a date TRAI will notify. SMS template rules are unchanged.

For an OTP template, that means:

• Fix the hash and domain. Both are constant for a given app, signing key and website.

• Count variables. A combined Retriever and WebOTP template uses the code twice.

• Plan one template per app and header. Different package names give different hashes.

• Treat debug builds separately. Use User Consent there, or register a test template.

• Check category and timing. File OTPs as service messages, and do not register so early that templates sit unused for 90 days.

Approval runs on the operator's calendar, so start early.

Beyond SMS: WhatsApp, RCS, carrier checks and passkeys

WhatsApp authentication templates. Meta requires one for any OTP sent over WhatsApp. One-tap autofill opens your app with the code; it is Android only, needs app changes and shows a copy-code button on other devices, though iOS 26 and later offers keyboard autofill. Zero-tap delivers the code to your app without the user leaving it, also on Android only, and Meta advises against making WhatsApp your default channel. Both carry your package name and the same hash you compute for SMS Retriever, and Meta deprecated the older PendingIntent handshake on 15 October 2026 in favour of its OTP Android SDK. For pricing, ask Meta or your provider; since 1 July 2024 India has carried Meta's authentication-international rate for eligible senders based abroad.

RCS. Google's Android 17 notes and its Retriever and User Consent guides cover SMS only, and we found no public Android API that lets a third-party app read RCS business messages. Treat RCS as a tap-or-copy channel with SMS fallback.

Carrier-based number verification. Android's Phone Number Verification API gets a verified number from the carrier without an SMS: the user confirms on a Credential Manager sheet, Android fetches an encrypted GSMA TS.43 token by authenticating the SIM, and your server exchanges it with an aggregator or carrier, which is when charges apply. It needs Android 10 or later, and Google says to check carrier support first and fall back to SMS. Google's Firebase version lists 14 regions and 20 carriers, none in India, on a page last updated 6 November 2026, so pilot it first. It sits alongside the SIM checks in our India SIM binding guide.

Missed-call verification. Play stops accepting account verification by phone call as a use of READ_CALL_LOG from 27 January 2027.

Passkeys. Credential Manager is Google's recommended Jetpack API for passkeys, passwords and Sign in with Google, and a passkey removes the OTP from routine sign-in. Chrome's documentation warns that SMS can be spoofed and numbers hijacked or recycled. Our passkeys versus SMS OTP guide covers the server side. For payments, RBI's Authentication Mechanisms for Digital Payment Transactions Directions, 2025 (issued 25 September 2025, compliance by 1 April 2026 unless stated otherwise) keep the two-factor norm, and RBI says they encourage new factors and risk-based checks without discontinuing SMS OTP. SMS OTP stays lawful; it just stops being the only sensible option.

A fallback ladder for one login screen

The timers are design choices, not study figures.

Keep step 6 visible throughout: Google's User Consent guidance asks you to offer keyboard entry first, because the SMS may arrive on a different device from the one running your app.

Migration checklist

1. List every flow that reads SMS (login, sign-up, number change, payment confirmation) and search the merged manifest for RECEIVE_SMS and READ_SMS.

1. Add funnel events for auto-filled, typed and timed-out codes, and collect a baseline.

1. Decide per flow: SMS Retriever, SMS User Consent, or a non-SMS method.

1. Download the Play App Signing certificate and compute the production hash.

1. Draft templates with the hash and, for WebOTP, the @domain #code last line; check the 140-byte limit, including Unicode versions.

1. File the templates with your gateway as service messages and confirm the current TCCCPR rules.

1. Build the Retriever and User Consent paths, keeping manual entry visible.

1. Remove both SMS permissions once no flow needs them, and update your Play permissions declaration.

1. Test on an Android 17 device with a build targeting API 37; compatibility toggles also let a debuggable app switch on targeted changes without changing its target.

1. Test WebOTP-format messages on Android 17 devices now, then ship through a staged rollout against your baseline.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our Android app development team can take an app through the Android 17 OTP change, from SMS-reading inventory and DLT template drafting to Retriever, User Consent and passkey builds and a measured staged rollout. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Behavior changes: apps targeting Android 17 or higher, last updated 31 October 2026 — Android Developers

1. Android 17 is here, 16 June 2026 — Android Developers Blog

1. Behavior changes: all apps (Android 17), last updated 28 October 2026 — Android Developers

1. Perform SMS verification on a server — Google for Developers

1. Request one-time consent to read an SMS verification code — Google for Developers

1. Prepare your app for the resizability and orientation changes in Android 17, 13 February 2026 — Android Developers Blog

1. Target API level requirements for Google Play apps — Play Console Help

1. Telecom Commercial Communications Customer Preference (Third Amendment) Regulations, 2026, 18 September 2026 — Telecom Regulatory Authority of India

1. Telecom Commercial Communications Customer Preference (Fourth Amendment) Regulations, 2026, 4 November 2026 — Telecom Regulatory Authority of India

1. RBI issues Directions on Framework on Authentication Mechanisms for Digital Payment Transactions, 25 September 2025 — Reserve Bank of India

1. Use of SMS or Call Log permission groups — Play Console Help

1. The First Beta of Android 17, 13 February 2026 — Android Developers Blog

1. Verify phone numbers on the web with the WebOTP API — Chrome for Developers

1. About verifying phone numbers, last updated 26 October 2026 — Android Developers

1. Authentication templates — Meta for Developers

1. Request SMS verification in an Android app, last updated 3 November 2026 — Android Developers

1. What is UCS-2 character encoding? — Twilio

1. One-tap SMS verification with the SMS User Consent API — Google for Developers

1. Telecom Commercial Communications Customer Preference (Second Amendment) Regulations, 2025, 12 February 2025 — Telecom Regulatory Authority of India

1. One-tap autofill authentication templates — Meta for Developers

1. Zero-tap authentication templates — Meta for Developers

1. Authentication-international rates — Meta for Developers

1. Implement phone number verification — Android Developers

1. Firebase Phone Number Verification supported carriers and pricing, last updated 6 November 2026 — Firebase

1. About Credential Manager — Android Developers

1. Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025 — Reserve Bank of India

1. Migrate apps to Android 17 — Android Developers