Desde el 27 de enero de 2027, Google Play reserva el permiso READ_CONTACTS para las apps que no pueden funcionar sin él. Si tu app pide la agenda solo para invitar a alguien o compartir un contacto, tendrás que cambiar al selector de contactos de Android y quitar el permiso. Si de verdad necesitas acceso continuo a toda la agenda, lo mantienes, pero declarándolo en Play Console. Y antes de eso, el 27 de octubre de 2026 empiezan los avisos en la revisión previa: no bloquean nada, solo marcan el problema. Aquí tienes a quién afecta, cómo distinguir los dos casos y qué hacer con cada uno.

Qué cambia exactamente

En abril de 2026 Google anunció una nueva política de permisos de contactos. La idea es sencilla: READ_CONTACTS deja de ser el permiso por defecto para cualquier función que toque la agenda y pasa a estar reservado para las apps que no pueden funcionar sin él.

La mayoría de apps no entran en ese grupo. Pides la agenda para que el usuario invite a un amigo, comparta un contacto o elija a alguien de una lista. Para todo eso, Google quiere que uses el selector de contactos del sistema (el Contact Picker) o el Sharesheet, que no necesitan permiso. El acceso amplio queda para el puñado de apps que de verdad trabajan sobre la agenda completa: una app de mensajería que cruza tu lista con sus usuarios, un marcador, un CRM que sincroniza.

Si quitas el acceso amplio, además tienes que quitar READ_CONTACTS del manifiesto cuando tu app apunte a Android 17 o superior. Si lo mantienes, tendrás que justificarlo con una Play Developer Declaration en Play Console.

Las dos fechas que todo el mundo está mezclando

Aquí es donde el ruido de los últimos meses ha hecho daño. Vas a encontrar artículos y trackers que hablan del "28 de octubre" como si fuera el día en que te echan de la tienda. No lo es.

Son dos fechas distintas:

  • 27 de octubre de 2026: arrancan las comprobaciones previas (pre-review) en Play Console. El sistema te marca los posibles problemas de permisos de contactos y de ubicación. Es un aviso, no un bloqueo: tu app sigue publicándose y actualizándose.
  • 27 de enero de 2027: la política entra en vigor. Es la fecha que figura en la tabla oficial de plazos de Google, y la que manda.

Dicho de otra forma: octubre es la alarma, enero es la puerta. Tienes tres meses entre una cosa y la otra, y conviene usarlos, no gastarlos discutiendo qué fecha es la buena.

¿Te afecta? Clasifica cada sitio donde pides la agenda

No es una decisión de app entera, es una decisión por función. Una misma app puede tener un uso que hay que migrar y otro que hay que declarar. Repasa cada punto donde pides contactos y mételo en uno de dos cajones.

Cajón A, uso puntual. El usuario elige a alguien para invitarlo, enviarle algo o rellenar un campo. No necesitas la lista entera ni la quieres guardar. Aquí migras al selector y borras el permiso.

Cajón B, necesidad real y continua. La función central de tu app depende de leer toda la agenda: detectar qué contactos ya usan tu servicio, mantener un sincronizado, un cliente de correo o de mensajería. Aquí mantienes READ_CONTACTS y preparas la declaración.

El error que vas a ver estos meses es gente arrancando READ_CONTACTS de apps que sí lo necesitan, por miedo al aviso de octubre. Si tu caso es el cajón B, no lo toques: documenta por qué lo necesitas y envía la declaración. Quitar un permiso que de verdad hace falta rompe tu producto para cumplir una norma que no te obligaba a ello.

El selector de contactos, en la práctica

En nativo esto no es nuevo. El selector es un Intent con ACTION_PICK que abre la interfaz de la app de Contactos del sistema. El usuario elige un contacto, tú recibes solo esa fila, y el acceso es temporal: dura lo que vive tu Activity. Nada de permisos, nada de UI propia.

val pickIntent = Intent(Intent.ACTION_PICK, ContactsContract.Contacts.CONTENT_URI)
startActivityForResult(pickIntent, PICK_CONTACT_REQUEST)

Las versiones recientes de AndroidX lo envuelven en la Activity Result API con ActivityResultContracts.PickContact(), que es por donde deberías ir en código nuevo.

Si trabajas en Flutter, el punto de partida suele ser un plugin tipo flutter_contacts, que declara READ_CONTACTS para leer la agenda. Para un flujo de "elige a una persona", eso es justo lo que la política restringe ahora. Tienes dos salidas: envolver el ACTION_PICK nativo en un platform channel propio, o usar un plugin de selección que no pida el permiso. En los dos casos el resultado es el que buscas: el usuario elige, tú recibes un contacto, y el manifiesto se queda sin READ_CONTACTS.

Un aviso que se escapa fácil: revisa qué permisos acaban en tu manifiesto final por culpa de las dependencias. Un plugin que ya no usas puede seguir arrastrando el permiso vía manifest merging, y el pre-review te lo va a marcar igual aunque tu código no lo toque.

La ubicación va por el mismo camino

La misma tanda de cambios toca los permisos de ubicación, con la misma fecha del 27 de enero de 2027. El patrón es idéntico: para un uso puntual de ubicación precisa, el botón de ubicación pasa a ser el mínimo recomendado, y en Android 17+ añades el flag onlyForLocationButton al manifiesto. Para ubicación precisa y persistente, Play Developer Declaration explicando por qué el botón o la ubicación aproximada no te sirven. Y de paso, el geofencing ya no cuenta como uso aprobado de foreground service: para eso toca la Geofence API. Si tu app pide ubicación, el ejercicio de clasificación es el mismo que con los contactos.

Qué haríamos nosotros

Cuando auditamos una app para esto, el orden es este:

  1. Buscar READ_CONTACTS y ACCESS_FINE_LOCATION en el código y en los manifiestos de todas las dependencias, no solo en el tuyo. El pre-review mira el manifiesto final.
  2. Clasificar cada uso en los dos cajones de arriba. La mayoría caen en el A.
  3. Migrar los del cajón A al selector y quitar el permiso. Son cambios acotados y testeables uno a uno.
  4. Para el cajón B, redactar la declaración con el caso de uso real antes de que se te eche el tiempo encima. La declaración se revisa, no es un trámite instantáneo.

Hazlo contra la fecha de enero, no contra el aviso de octubre, pero empieza ya. Tres meses se van rápido cuando la migración hay que probarla en las dos tiendas y en varias versiones de Android. Y si tu app lleva tiempo sin que nadie mire el manifiesto a fondo, esta es una buena excusa para hacer esa limpieza completa, no solo el parche de contactos.

En resumen

A partir de enero de 2027, leer la agenda entera deja de salir gratis. Para casi todas las apps el cambio es pequeño y mecánico: selector en lugar de permiso. Para las pocas que de verdad necesitan la agenda completa, es papeleo, no una migración. Lo único que no deberías hacer es las dos cosas a la vez por confundir las fechas.

En Dribba mantenemos y actualizamos apps Flutter en producción, y este tipo de cumplimiento de tienda es parte del trabajo. Si quieres que revisemos dónde está tu app frente a este cambio, hablamos.