Android 17 y el OTP por SMS: el formato del mensaje ahora importa

Android 17 retiene tres horas los SMS con código para las apps que no son las destinatarias. Qué formatos reconoce el sistema (SMS Retriever, User Consent y WebOTP) y qué deben ajustar quienes envían OTP.

Lectura de 8 minActualizado: 18 de octubre de 2026

Desde Android 17, el sistema operativo trata de forma distinta los SMS que traen un código de verificación. Si el mensaje está marcado para una app o un sitio concreto, solo ese destinatario puede leerlo de inmediato; el resto de las apps con permiso de lectura de SMS lo ve tres horas después. Para quienes enviamos OTP todos los días, la consecuencia es concreta: el formato del mensaje dejó de ser un detalle de redacción y pasó a ser parte del diseño de la autenticación.

Qué cambió en Android 17

Android 17 se liberó en versión estable el 16 de junio de 2026 y, entre sus cambios de comportamiento, amplía la protección de los SMS que contienen contraseñas de un solo uso. Hay dos capas, y conviene separarlas porque no aplican igual.

1. Para todas las apps: los mensajes con formato de destinatario

Android ya protegía los mensajes con formato SMS Retriever: los que incluyen un hash que identifica a la app. Esos mensajes se retenían tres horas para la mayoría de las apps, con excepción de la app de mensajes predeterminada y de la app dueña del hash. Android 17 extiende la misma lógica al formato WebOTP, el que vincula el código a un dominio. Si una app tiene permiso para leer SMS pero no es la destinataria del mensaje (lo que se determina por verificación de dominio), no accede al contenido hasta tres horas después de recibido. Esta capa aplica a todas las apps, sin importar la versión de Android a la que estén orientadas.

2. Para apps orientadas a Android 17: los OTP sin formato

La segunda capa es la más amplia. En las apps que declaran como objetivo Android 17 (nivel de API 37), el sistema también retiene los SMS con OTP que no usan ningún formato estándar: durante tres horas no se entrega el aviso de mensaje recibido y las consultas a la base de SMS vienen filtradas. Quedan exentas la app de mensajes predeterminada, las apps compañeras de dispositivos conectados y algunos casos puntuales.

Traducido a la operación: una app que hoy lee el SMS completo para extraer el código por su cuenta va a dejar de encontrarlo en el momento en que lo necesita, en cuanto se actualice para apuntar a la nueva versión. La recomendación de Google es explícita: migrar a las API de SMS Retriever o de SMS User Consent.

Los tres formatos que Android reconoce

Ninguno de estos formatos es nuevo. Lo nuevo es que pasan de ser una comodidad a ser la vía que el sistema operativo privilegia. Cada uno sirve para un flujo distinto.

SMS Retriever: el código va directo a la app

Es la opción para una app nativa que quiere completar la verificación sin intervención del usuario. Según la documentación de Android, el mensaje debe cumplir tres condiciones: no superar 140 bytes, contener el código y llevar una cadena de 11 caracteres que identifica a la app. Esa cadena se calcula a partir del nombre del paquete y del certificado con el que se firma la app.

Tu clave de acceso es 482913.
No la compartas con nadie.
FA+9qCX9VSu

SMS User Consent: la app lo pide y el usuario lo aprueba

Es la alternativa cuando no se puede incluir el hash, por ejemplo porque el texto lo define un tercero. La app escucha el siguiente SMS y el sistema le muestra al usuario un aviso para que autorice compartir ese mensaje. De acuerdo con la guía de Google, el mensaje tiene que traer un código alfanumérico de 4 a 10 caracteres con al menos un número, y no debe venir de un contacto guardado en el teléfono.

WebOTP y códigos vinculados a dominio: el flujo web

Para verificaciones que ocurren en el navegador, el formato es una última línea con el dominio y el código, definido en la especificación de códigos de un solo uso vinculados a dominio. Chrome lo aprovecha a través de la API WebOTP y Safari lo usa para sugerir el código solo en el sitio correcto.

Tu clave de acceso es 482913.

@banca.ejemplo.com.mx #482913

La ventaja de este formato va más allá de Android: el código queda asociado a un dominio, así que el navegador solo lo ofrece en ese sitio.

Los tres formatos, lado a lado

FormatoFlujoQué lleva el mensajeQué hace el usuario
SMS RetrieverApp nativaEl código y la cadena de 11 caracteres de la app, en no más de 140 bytesNada: el código se completa solo
SMS User ConsentApp nativa, cuando no se puede incluir la cadenaUn código de 4 a 10 caracteres alfanuméricos con al menos un númeroAprueba un aviso del sistema
WebOTP / dominioNavegadorUna última línea con @dominio #códigoConfirma el código sugerido por el navegador

Qué implica para quien envía el OTP

En una plataforma de mensajería, el OTP rara vez lo redacta quien desarrolla la app. Lo arma una plantilla configurada por el cliente, pasa por la API del proveedor y llega al operador. Por eso el cambio se resuelve con coordinación, no con una línea de código. Estos son los puntos que revisaría, en complemento con lo que escribí sobre cómo diseñar el OTP bancario:

  • Una plantilla por flujo. El mensaje que verifica un acceso desde la app nativa y el que verifica un acceso desde la web no deberían ser el mismo. Cada uno lleva su marca: el hash para la app, la línea de dominio para la web.
  • Los 140 bytes cuentan en serio. Con codificación GSM-7 eso alcanza para 160 caracteres, pero una sola vocal con acento agudo como la á o la ó, que no forman parte del alfabeto GSM básico, pasa el mensaje a UCS-2, y ahí el límite baja a 70 caracteres. Una plantilla que diga “Tu código de verificación…”, con el hash al final, puede quedar fuera del formato sin que nadie lo note. Por eso el ejemplo de arriba dice “clave de acceso”.
  • El hash depende del certificado de firma. Si la app cambia su llave de firma, o si se prueba con una versión firmada con otro certificado, el hash cambia. Conviene que la plantilla lo reciba como parámetro y no como texto fijo.
  • El dominio tiene que coincidir con el sitio real. La línea de WebOTP funciona si el dominio es exactamente el del sitio donde el usuario está escribiendo el código.
  • Probar en dispositivos reales. Un mensaje que se ve bien en el panel de envíos puede no disparar el autocompletado. La prueba útil es la de punta a punta: plataforma, operador, teléfono con Android 17.

Qué implica para quien desarrolla la app

Del lado del equipo móvil, el punto de partida es identificar si la app lee SMS directamente para extraer códigos. Si lo hace, la migración a SMS Retriever o a SMS User Consent tiene que estar lista antes de actualizar el nivel de API al que apunta la app. Google Play, además, ya limitaba el permiso de lectura de SMS a casos muy específicos, así que para la mayoría de las apps bancarias y de servicios esta migración ordena algo que ya venía encaminado.

Hay un beneficio que no conviene perder de vista: con SMS Retriever el usuario no copia ni escribe el código, y cada paso manual que se elimina reduce abandono en el alta y en el inicio de sesión. Ese mismo razonamiento aparece cuando se combina el SMS con las API de red de los operadores: cada capa suma contexto sin agregar fricción.

Preguntas frecuentes

¿El usuario recibe el SMS tres horas tarde?

No. La app de mensajes predeterminada está exenta, así que la persona ve el SMS en el momento en que llega. La demora de tres horas aplica a las otras apps que tienen permiso para leer SMS y no son las destinatarias del código.

¿Tengo que cambiar algo si mi app ya usa SMS Retriever?

En principio, no: es el formato que el sistema privilegia. Sí conviene verificar dos cosas: que la cadena de la app corresponda al certificado con el que se firma la versión publicada y que la plantilla completa, con acentos incluidos, no supere los 140 bytes.

¿Qué pasa con las apps que todavía no apuntan a Android 17?

La retención de los mensajes con formato WebOTP ya aplica a todas las apps que corren en Android 17. La retención de los OTP sin formato aplica a las apps que declaran Android 17 (nivel de API 37) como objetivo. Es decir, el cambio llega de lleno en cuanto el equipo móvil actualiza ese nivel. Es mejor tener la migración lista antes.

¿Puedo usar el mismo SMS para la app y para la web?

Técnicamente se puede combinar, pero lo más ordenado es una plantilla por flujo: el mensaje que se dispara desde la app lleva la cadena de la app, y el que se dispara desde la web lleva la línea de dominio. Así cada formato hace su trabajo y el texto queda corto.

Mi lectura

Me parece una buena noticia para el SMS como canal de autenticación. El sistema operativo reconoce que el código tiene un destinatario y lo protege en consecuencia, sin pedirle nada al usuario. Lo que cambia es la responsabilidad del emisor: ya no alcanza con que el mensaje llegue, tiene que llegar con el formato que el teléfono sabe interpretar.

En la práctica, esto acerca tres equipos que no siempre trabajan juntos: el que diseña la plantilla, el que opera la plataforma de envío y el que desarrolla la app. Las organizaciones que ya tienen esa conversación armada van a resolverlo en días. Para el resto, es una buena excusa para armarla.

Fuentes

Seguir leyendo

¿Te sirvió? Compártelo con tu equipo:Compartir en LinkedIn

Sigue leyendo