Se acabó el periodo de gracia de la API 36 en Google Play, y los plazos de permisos de 2027 ya están fijados

Desde el 31 de agosto de 2026, Google Play solo acepta apps nuevas y actualizaciones de apps que apunten a Android 16 (nivel de API 36) o superior. Las apps de Wear OS, Android Automotive OS, Android TV y Android XR están exentas. Los equipos que necesitaban más tiempo podían solicitar una prórroga hasta el 1 de noviembre de 2026. Esa fecha ya pasó. Si su targetSdkVersion sigue por debajo de 36, ahora mismo no puede publicar una actualización en Play, y eso incluye el hotfix que quizá necesite la semana que viene.

Las apps existentes que no se actualizan tienen una regla aparte. Deben apuntar como mínimo a Android 15 (nivel de API 35) para seguir disponibles para usuarios nuevos en dispositivos con una versión de Android más reciente que la de destino de la app. Por debajo de ese nivel, la app solo aparece en dispositivos con la misma versión de Android o una anterior. Es decir, una app que nadie toca desde hace tiempo no se retira, simplemente cada vez es más difícil de encontrar.

Además, Google anunció el 29 de octubre de 2026 un conjunto de cambios de política, con fechas de aplicación repartidas a lo largo de 2027. Ninguno es urgente hoy. Todos son de esos que acaban en pánico si se descubren dos semanas antes del plazo.

El calendario de 2027

Estas son las fechas de la tabla de plazos de políticas de Google y de la página de políticas de Play:

• 27 de enero de 2027: contactos. La política de permiso de contactos restringe el acceso amplio a los contactos de los usuarios. Las apps que no necesiten un acceso amplio deben usar el selector de contactos de Android (Contact Picker).
• 27 de enero de 2027: ubicación precisa. Las apps que apunten a Android 17 (API 37 o superior) deben usar el botón de ubicación de Android para solicitudes de ubicación precisa puntuales u ocasionales. Si mantiene ACCESS_FINE_LOCATION, necesita una declaración en Play Console que explique por qué no bastan el botón de ubicación o la ubicación aproximada.
• 27 de enero de 2027: descuentos en suscripciones. Las suscripciones con descuentos continuos basados en requisitos de elegibilidad, como los planes para estudiantes, deben informar con claridad de los criterios de elegibilidad, de cómo funciona la verificación y de qué ocurre con el precio y los beneficios cuando el usuario deja de ser elegible.
• 14 de abril de 2027: AppFunctions. Las AppFunctions no deben engañar ni manipular a los agentes de IA, eludir sus controles de seguridad ni interferir con otras apps.
• 25 de agosto de 2027: ACCESS_LOCAL_NETWORK. El acceso a la red local queda restringido a las apps que lo necesiten para su funcionalidad principal cuando los selectores de dispositivos, como NsdManager, no sean suficientes. Las apps que apunten a Android 17 o superior necesitan una declaración en Play Console para usarlo.
• 25 de agosto de 2027: MANAGE_CONTACTS. Restringido a las apps cuya funcionalidad principal lo necesite cuando los selectores del sistema no basten, con una declaración en Play Console. El resto debe usar intents de plataforma de alcance acotado.

Por qué el cambio de API objetivo sigue pillando desprevenidos a los equipos

En nuestros proyectos nativos de Android, subir targetSdkVersion rara vez es lo difícil. Cambiar un número en Gradle lleva un minuto. El trabajo es todo lo que ese número activa: el nuevo comportamiento de la plataforma al que su app se acoge, las bibliotecas que no se han puesto al día y los dispositivos de prueba que no cubren la nueva versión. Hemos visto cómo un cambio de una línea se convertía en un sprint de tres semanas porque un SDK de pagos o una biblioteca BLE aún no había publicado una versión compatible.

El patrón que vemos con más frecuencia es este: la app funciona, nadie está asignado a ella, y el requisito de la API objetivo aparece como una advertencia de Play Console que cae en una bandeja de entrada compartida. Entonces surge un error real, la corrección está lista y la subida es rechazada. Ahora tiene que hacer una migración de plataforma bajo presión, con una incidencia abierta en producción. Esa es la situación en la que están muchos equipos esta semana.

Mi opinión sincera: trate el cambio anual de API objetivo como una dependencia propia, no como una tarea que le impone Google. Póngalo en la hoja de ruta cada primavera, cuando se anuncia el nuevo requisito, y hágalo mientras nada esté en llamas.

Los cambios de permisos importan más de lo que parece

Las reglas de 2027 comparten una misma idea. Los permisos amplios se sustituyen por selectores y botones del sistema, y si quiere conservar la versión amplia, tiene que justificarse en Play Console.

Lo hemos visto con más claridad en apps de salud y de IoT. Las apps de IoT tienden a pedir acceso a la red local pronto, porque el descubrimiento de dispositivos es la primera pantalla, y es fácil solicitar más de lo necesario. Si un selector basado en NsdManager cubre su flujo de descubrimiento, la regla de agosto de 2027 es sobre todo papeleo que puede evitar. Si no lo cubre, empiece ya a documentar por qué la funcionalidad principal necesita el permiso, porque eso es lo que pide la declaración.

Con los contactos pasa algo parecido. Muchas apps piden acceso completo a los contactos para una única pantalla de «invita a un amigo». El Contact Picker resuelve ese caso, y migrar a él antes de enero elimina un permiso que los usuarios ven con recelo de todos modos. Desde el punto de vista de la seguridad, también es una buena noticia. En nuestros trabajos de pentesting, los permisos excesivamente amplios son un hallazgo recurrente: datos que la app nunca necesitó, guardados en una caché local, al alcance de cualquiera que consiga un punto de apoyo en el dispositivo. Menos acceso significa menos que filtrar.

La regla del botón de ubicación solo se aplica cuando se apunta a Android 17, pero si publica un localizador de tiendas o un campo de pago de «usar mi ubicación», planifique ya el cambio de interfaz. Un botón de un toque es un flujo distinto al de un cuadro de diálogo de permiso en tiempo de ejecución, y el equipo de diseño querrá opinar.

No pase por alto las reglas de suscripciones y AppFunctions

La regla de transparencia en las suscripciones es fácil de pasar por alto porque pertenece al terreno de producto y legal, no al del código. Si ofrece un plan para estudiantes u otro basado en elegibilidad, alguien tiene que dejar por escrito el proceso de verificación y el precio posterior a la elegibilidad en la propia pantalla de pago. En el trabajo web y de backend que hacemos para clientes empresariales, este tipo de requisito suele implicar un cambio tanto en los textos de la app como en el servidor que decide quién sigue siendo elegible, así que involucre al equipo de backend desde el principio.

AppFunctions es un terreno más nuevo. La política es breve: no engañe a los agentes de IA, no eluda sus controles de seguridad, no interfiera con otras apps. Si expone acciones de su app a agentes, revíselas como lo haría con una API pública. Compruebe qué puede hacer cada función sin confirmación del usuario y dé por hecho que algo la invocará con entradas que no esperaba.

Qué hacer esta semana

1. Compruebe hoy su nivel de API objetivo. Si está por debajo de 36, la actualización bloquea ya todas sus versiones. Cree una rama, suba el nivel, ejecute toda su batería de pruebas en un dispositivo con Android 16 y actualice las bibliotecas que fallen.
2. Audite su manifiesto. Haga una lista de cada uso de READ_CONTACTS, MANAGE_CONTACTS, ACCESS_FINE_LOCATION y ACCESS_LOCAL_NETWORK, y junto a cada uno anote si un selector o un botón podría sustituirlo.
3. Ponga las fechas de 2027 en un calendario compartido, con un responsable para cada una, no solo un recordatorio en Slack.
4. Asigne a alguien a la bandeja de entrada de Play Console. La mayor parte de los problemas que vemos empiezan con una advertencia que nadie leyó.

Si quiere ver cómo hemos gestionado antes migraciones de plataforma como esta, nuestro portafolio incluye algunos ejemplos, y nuestro trabajo de desarrollo abarca tanto Android nativo como los backends que lo respaldan.

Si le suena familiar un targetSdkVersion atascado o una auditoría de permisos que siempre deja para después, hablemos.