Fecha límite de API 36 en Google Play: qué cambia el 31 de agosto de 2026

Google sube una vez al año el umbral de nivel de API objetivo de Play Store, y 2026 es el ciclo de API 36. El número no es la parte confusa. Lo confuso es que "el requisito de nivel de API objetivo" son en realidad dos reglas con un solo nombre: una gobierna lo que puedes subir y otra, más baja, gobierna quién puede seguir instalando lo que ya está publicado. Casi todas las páginas que posicionan para esta pregunta mezclan ambas, y así es como hay quien reconstruye una app que no hacía falta reconstruir, o ignora un aviso de Play Console que sí importaba.

Este artículo las separa, te da los números por formato de dispositivo y luego responde a la pregunta que de verdad nos llega al soporte en agosto: ¿qué le hace todo esto a una app que está en mitad de una prueba cerrada (closed testing) de 12 testers durante 14 días de forma continua? En la documentación oficial de Google en español, esos testers aparecen como verificadores. PrimeTestLab se encarga de esa parte de las pruebas para los desarrolladores, así que vemos el choque de calendarios constantemente, y lo que se explica en esa sección vale igual si contratas un servicio o si reclutas tú. Cada fecha y cada nivel de abajo se comprobaron contra las páginas de Google el 9 de agosto de 2026, y todo lo que Google no ha documentado de verdad se marca como tal en lugar de rellenarse con una suposición segura de sí misma.

La regla en una frase

A partir del 31 de agosto de 2026, una app normal de teléfono, tablet, plegable o Android Auto debe apuntar a Android 16, nivel de API 36 o superior para poder enviarse a Google Play, tanto si es una app totalmente nueva como si es la actualización de una ya publicada. Esa sola frase cubre a la mayoría de lectores. Las excepciones, y el umbral más bajo para las apps que no vas a tocar, son de lo que trata el resto del artículo.

Un nombre, dos reglas distintas

Google usa la expresión "requisito de nivel de API objetivo" para dos cosas que no se comportan igual en absoluto. Mantenerlas separadas es lo más valioso que puedes llevarte de esta página.

Así que una app que descansa tranquila en API 35 sin actualizaciones previstas cumple el 31 de agosto según la regla 2, y deja de cumplir en el instante en que intentas publicar cualquier cosa según la regla 1. No es una contradicción, es el diseño: Google sube el listón de lo que entra en la tienda más rápido que el de lo que se queda dentro.

Los tres términos que Google define con precisión

La política se apoya en tres términos, y cada uno tiene un significado concreto que decide bajo qué regla estás:

• App nueva: una app "que aún no se ha publicado en Google Play". La primera subida de un nombre de paquete.
• App existente: una app que ya está publicada en Google Play.
• Actualización: una versión nueva de una app existente enviada a revisión para sustituir a la actual. Una actualización se juzga por la regla de envío, no por la de disponibilidad.

Requisitos por formato de dispositivo

"App de Android" no es una sola fila. Teléfonos, tablets, plegables y Android Auto pasan a API 36. Wear OS y Android Automotive OS se quedan en API 35. Android TV y Android XR se quedan en API 34. Los umbrales para una app que no vas a actualizar son todavía más bajos, y el selector de abajo alterna entre los dos conjuntos.

Android Auto no es Android Automotive OS

Estos dos nombres cuestan tiempo real a los desarrolladores cada año. Android Auto proyecta una app desde el teléfono a la pantalla del coche, así que la app es una app de teléfono y sigue la regla del teléfono: API 36. Android Automotive OS es el sistema operativo que corre en el propio vehículo, y es una de las excepciones con objetivo más bajo citadas expresamente: API 35. Si desarrollas una app de multimedia o navegación que llega a ambos, te aplica el más alto de los dos.

¿Te afecta a ti? Responde tres preguntas

Que el 31 de agosto sea tu problema depende de tres cosas: qué estás a punto de hacer, qué formato de dispositivo publicas y a qué apunta de verdad tu compilación actual. La herramienta de abajo aplica los umbrales publicados por Google a esa combinación y te dice bajo cuál de las dos reglas estás.

Si el veredicto dice que estás en regla, aun así te conviene la lista antes de la fecha del final, porque "mi código fuente pone objetivo 36" y "el artefacto que Google evaluó declara 36" no son la misma afirmación. La falsa sensación de seguridad más común de todo este ciclo es un desarrollador leyendo su archivo de Gradle en lugar de su paquete subido.

Qué pasa de verdad si no llegas al 31 de agosto

Dos cosas distintas, según la regla bajo la que estés. Si intentas subir una compilación por debajo del umbral, el envío no cumple el requisito. Si simplemente dejas una app publicada sin tocar por debajo del umbral de disponibilidad, deja de ser localizable e instalable para los usuarios nuevos cuyo dispositivo ejecuta una versión de Android más reciente que la que apunta. Ninguno de los dos desenlaces es una eliminación.

Si intentas subir

Fíjate a qué está atada esta consecuencia: al acto de subir. El calendario por sí solo no le hace nada a una compilación que ya está publicada. Por eso una app puede cumplir perfectamente el 1 de septiembre y estar bloqueada el 2 de septiembre, solo porque decidiste publicar una corrección de errores.

Si dejas una app publicada por debajo del umbral

Este es el caso que la competencia describe como "tu app desaparece", y es falso de una forma que importa. La redacción de Google es que la app "dejará de estar disponible" para un grupo concreto de usuarios. En concreto:

• Los usuarios nuevos con dispositivos recientes pierden el acceso. Si el dispositivo de alguien ejecuta una versión de Android superior al objetivo de tu app, Google Play ya no se la muestra ni se la instala.
• Los usuarios nuevos con dispositivos antiguos no se ven afectados. Un dispositivo con el mismo nivel de API que el objetivo de la app, o inferior, puede seguir recibiéndola.
• Quien ya la instaló no se ve afectado. Cualquiera que ya haya instalado la app puede seguir encontrándola, reinstalándola y usándola en las versiones de Android compatibles.
• Los enlaces directos dicen la verdad. A quien abra tu enlace de Play Store desde un dispositivo reciente no elegible se le indica que la app se hizo para una versión anterior de Android.

Lo que no pasa

Cada agosto esta política genera los mismos cuatro miedos en los foros de soporte de Google. Ninguno es lo que describe la página del nivel de API objetivo.

¿Apuntar a API 36 mata la compatibilidad con dispositivos antiguos?

No, no por sí solo. targetSdk declara el nivel de comportamiento de Android para el que tu app está construida y probada. minSdk decide la versión de Android más antigua en la que puede instalarse. Son números separados, y subir el objetivo a 36 no sube el mínimo: tu app puede seguir siendo compatible con versiones de Android más antiguas hasta ese mínimo, siempre que tu código y las dependencias actualizadas sigan siendo compatibles.

Este es el malentendido que más alarma genera en cada ciclo. Un desarrollador lee "debe orientarse a Android 16", entiende "solo funciona en Android 16" y concluye que Google acaba de borrar la mayor parte de sus dispositivos alcanzables. Mueve el mínimo aquí abajo y mira qué cambia de verdad.

Los tres números, y cuál vigila Google Play

Qué significa esto si tu app está ahora mismo en prueba cerrada

Si tienes una cuenta personal de desarrollador nueva y estás corriendo la prueba cerrada obligatoria de 12 testers durante 14 días de forma continua, la fecha cae en mitad de tu ventana. El movimiento seguro es meter la compilación con API 36 en el mismo canal cerrado antes del 31 de agosto, mantener a todos los testers participando y no dejar que una fecha te obligue a cambiar de canal ni a empezar de cero con otros testers.

La página de Google sobre el nivel de API objetivo y su página sobre la prueba cerrada las escriben equipos distintos con fines distintos, y ninguna se refiere a la otra. Eso deja un hueco real, y lo honesto es enseñarte exactamente dónde termina el terreno documentado.

Lo que está verificado

• Una cuenta personal nueva afectada "debe realizar una prueba cerrada" con al menos 12 testers que hayan aceptado participar durante 14 días de forma continua antes de poder solicitar acceso a producción. Esto vale para las cuentas personales creadas después del 13 de noviembre de 2023. Verificado
• La documentación para desarrolladores de Google dice que un APK subido debe cumplir los requisitos de nivel de API objetivo de Play, y no publica ninguna excepción para los canales de pruebas (en la consola en es-419, segmentos de pruebas). Esa redacción es independiente del canal, no específica de las pruebas, así que una subida nueva al canal cerrado después de la fecha debe planificarse como si exigiera API 36. Es una inferencia sólida, no una regla documentada para canales de pruebas. Parcial
• Las propias indicaciones de Google animan a los desarrolladores a seguir actualizando la app durante la prueba cerrada mientras corrigen problemas, y definen el periodo válido en torno a la continuidad de la participación de los testers, no en torno a un artefacto congelado. Verificado
• La prueba interna tiene un tope de 100 testers y no sustituye a la prueba cerrada que sí cuenta. Verificado

Lo que Google no ha documentado

Como la respuesta se desconoce, la estrategia correcta no es predecirla. Es dejar la pregunta sin objeto teniendo una compilación conforme en el canal antes de la fecha, algo que es seguro pase lo que pase y no te cuesta nada si el artefacto antiguo hubiera seguido corriendo igualmente.

La secuencia que es segura en cualquier caso

1. Mantén el mismo canal cerrado y el mismo grupo de testers

   No crees un canal nuevo para alojar la compilación con API 36 y no quites a nadie que haya aceptado participar. La continuidad de 14 días que cuenta Google va de que los testers sigan participando, así que esa participación es el activo que estás protegiendo.

2. Compila y prueba API 36 antes de la fecha, no ese mismo día

   Trata la migración como una tarea propia con su propia ronda de pruebas. Descubrir una rotura de diseño de borde a borde el 30 de agosto es un día muy distinto a descubrirla el 10 de agosto.

3. Súbela al canal cerrado existente con un código de versión superior

   Cada paquete de reemplazo necesita un código de versión incrementado. Google define el periodo válido en torno a la continuidad de la participación de los testers y anima explícitamente a seguir corrigiendo problemas durante la prueba, pero no publica una garantía absoluta que cubra todos los casos de reemplazo de versión. Mantén el mismo canal y los mismos testers, y comprueba después el contador de Play Console. Toda la mecánica de actualizar en mitad de la prueba vale la pena si es tu primer ciclo.

4. Confirma que la versión llegó de verdad a los testers

   Una versión publicada no es lo mismo que una versión entregada. Comprueba que la versión cerrada está en vivo, que el código de versión es superior y que los testers de la lista ven la actualización.

5. Vuelve a revisar el estado de políticas tras el procesamiento

   Dale tiempo al paquete para procesarse y luego vuelve a abrir la página de estado de políticas de la app. Si el aviso del nivel de API objetivo sigue ahí, recorre la lista de diagnóstico en lugar de borrar versiones al azar.

6. Pide la prórroga solo si la migración de verdad no llega a tiempo

   Te compra hasta el 1 de noviembre de 2026 y se pide para cada app afectada. No es motivo para pausar el trabajo técnico.

Cómo solicitar la prórroga hasta el 1 de noviembre de 2026

Los desarrolladores afectados pueden pedir una prórroga que mantiene la distribución hasta el 1 de noviembre de 2026. Se solicita por app, desde el aviso de políticas de esa app en Play Console. Google no la describe como automática, ni como segura, ni como una exención permanente, así que sigue con la migración mientras la solicitud esté abierta.

Google Play Console · captura real Haz clic para ampliar

1. Abre la app afectada en Play Console

   El acceso a la prórroga es de la app, no de la cuenta. Si publicas varias apps, cuenta con repetirlo para cada una de las afectadas.

   Verificado
2. Ve a Policy status

   Solo se espera que lleven el problema del nivel de API objetivo las apps que Google considera no conformes. Si la app ya cumple, aquí no hay nada que prorrogar ni ningún formulario que encontrar.

   Verificado
3. Abre el aviso del nivel de API objetivo o los detalles del problema

   El título del problema que se ve en la captura de arriba es App must target Android 16 (API level 36) or higher. La redacción puede variar según la app y el estado del despliegue: tómala como lo que vio una cuenta real, no como una cadena universal garantizada.

   Verificado
4. Sigue el enlace de prórroga del problema, o el de tus notificaciones

   Google encamina a parte de los desarrolladores afectados por la notificación de la app en lugar del panel del problema. Mira los dos sitios antes de concluir que la opción no existe para ti.

   Verificado
5. Envía la información solicitada

   Google no publica las preguntas exactas en su página de ayuda pública, así que trata cualquier lista de "las preguntas que hacen" como no verificada. Responde desde tu plan de migración real.

   Parcial
6. Toma el 1 de noviembre de 2026 como el límite duro

   La prórroga mueve la fecha, no elimina el requisito. Lo que no pudiste terminar para el 31 de agosto tiene que estar listo para el 1 de noviembre.

   Verificado
7. Sigue migrando mientras la solicitud está abierta

   Nada en la redacción de Google promete la aprobación. Planificar contando con una prórroga que no has recibido es la suposición más cara disponible este ciclo.

   Parcial

Una última distinción que conviene retener: Google engancha la nota de la prórroga al requisito de API 36, y su texto casi siempre describe la prórroga como algo que preserva la distribución de una app existente. No recorre con la misma precisión todas las combinaciones de app nueva, actualización y app existente. Antes de dar por hecho que una prórroga cubre cierta subida que tienes planeada, lee qué dice cubrir el aviso de tu propia app.

Cómo pasar una app a API 36

Cuatro pasos: instalar el SDK de API 36, subir compileSdk y targetSdk a 36, actualizar las dependencias que se rompen al hacerlo y probar los cambios de comportamiento de Android 16. Cambiar el número es una edición de una línea. Demostrar que la app sigue funcionando es la migración de verdad.

Paso 1: instalar el SDK de Android 16

Abre Android Studio, ve al SDK Manager e instala la plataforma SDK de Android para el nivel de API 36 junto con las build tools 36.x.x actuales. Sin la plataforma instalada, subir compileSdk solo produce un error de compilación que parece no tener nada que ver con lo que hiciste.

Paso 2: subir los niveles en tu compilación

Elige tu stack. La ruta del archivo y las líneas exactas cambian, el destino no: el manifiesto que va dentro del paquete que subes tiene que declarar objetivo 36.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Paso 3: actualizar dependencias y herramientas del framework

Subir el nivel de compilación es donde fallan las dependencias antiguas. Cuenta con tocar el Android Gradle Plugin, el propio Gradle, Kotlin, las bibliotecas de AndroidX, los servicios de Google Play y cualquier SDK de publicidad o analítica que traiga código nativo. Este artículo no publica a propósito "las versiones correctas", porque las versiones compatibles cambian cada semana y una lista fija aquí engañaría en quince días. Tómalas de las notas de versión actuales de tu propio framework el día que migres.

Paso 4: compilar, subir y verificar el artefacto

• Genera un Android App Bundle firmado e incrementa el código de versión.
• Prueba el artefacto de versión, no solo una compilación de depuración. La minificación y la reducción de recursos rompen cosas que las compilaciones de depuración ocultan.
• Sube al canal previsto y confirma en Play Console que el artefacto informa del nivel de API objetivo 36.
• Tras el procesamiento, revisa todos los canales activos y vuelve a abrir el estado de políticas.

Comportamientos de Android 16 que probar antes de publicar con API 36

Apuntar a API 36 activa los comportamientos de Android 16 para tu app en dispositivos con Android 16. Los comportamientos prioritarios que hay que probar son el diseño de borde a borde, el retroceso predictivo, la libertad de orientación en pantallas grandes, los permisos de salud, la planificación a intervalo fijo y el diseño de texto. Marca abajo lo que aplique y obtendrás la lista de pruebas de tu app en lugar de una genérica.

Borde a borde y retroceso predictivo: el mayor radio de impacto

El diseño de borde a borde tiene un radio de impacto amplio porque no necesita que tu app use ninguna API exótica. En Android 16, una app que apunta a API 36 ya no puede usar el atributo de exclusión anterior, así que el contenido que daba por hecho que las barras del sistema le dejarían sitio ahora corre por debajo de ellas. El síntoma es cosmético justo hasta el momento en que un botón principal queda bajo la barra de gestos y deja de poder tocarse.

El retroceso predictivo tiene un radio de impacto igual de amplio. Si tu app registra un manejo del retroceso a la antigua, esa ruta puede sencillamente no dispararse como antes una vez que el retroceso predictivo está activo por defecto para objetivo 36. Prueba el retroceso desde cada profundidad de navegación: modales, WebViews, formularios con datos sin guardar y la última pantalla antes de salir.

Lo que no es una rotura universal del objetivo 36

¿Y el requisito de páginas de 16 KB?

Otro requisito, otra fecha, las mismas apps. La fecha del nivel de API objetivo va del nivel que declara tu manifiesto. El requisito de páginas de 16 KB va de si tus bibliotecas nativas funcionan en dispositivos con páginas de memoria de 16 KB. Las indicaciones actuales de Google nombran el 1 de febrero de 2027 como la fecha a partir de la cual las actualizaciones afectadas sin compatibilidad con 16 KB ya no podrán publicarse.

• A quién afecta: el requisito de Google se aplica a apps que apuntan a API 35 o superior en dispositivos de 64 bits de Google Play. Dentro de ese grupo, las que empaquetan bibliotecas nativas .so, directamente o a través de un SDK, son las que con más probabilidad necesitan trabajo real de recompilación y alineación. Si tu app es solo Kotlin o Java, por lo general ya es compatible, pero conviene probarlo en vez de darlo por hecho.
• Lo que no es: no forma parte de la fecha del nivel de API objetivo del 31 de agosto de 2026, y cumplir uno no cumple el otro.
• Por qué caen juntos: todo el que sube su nivel objetivo este mes recompila de todos modos, y es justo entonces cuando aflora la comprobación de páginas. Ese calendario es lo que hace que se confundan.

Si tu app empaqueta bibliotecas nativas, trata la comprobación de páginas como una tarea propia con su propia ronda de pruebas en lugar de algo que metes en la versión con API 36 a última hora. Los dos cambios tocan partes distintas de la compilación, y depurarlos a la vez es la forma más segura de convertir una migración de una semana en una de tres.

Subiste API 36 y el aviso sigue ahí

Normalmente es una de tres cosas: el paquete no ha terminado de procesarse y el estado de políticas no se ha actualizado, un artefacto antiguo sigue en otro canal activo, o el artefacto que subiste no declara realmente 36 aunque tu proyecto sí. Recorre la lista y no empieces a borrar versiones.

El título del problema que reportan ahora los desarrolladores es Your app must target Android 16 (API level 36) or higher. Google no ha publicado un mensaje de error canónico completo para cada flujo de subida, así que trata cualquier redacción exacta que encuentres en internet, incluida esa, como observada y no como oficial. Se deja en inglés porque así se registró.

Un hábito resuelve casi todo esto de forma permanente: después de cada subida, lee el nivel de API objetivo de vuelta desde el artefacto en Play Console y anótalo junto al código de versión. Cuesta diez segundos y elimina de tu semana toda la categoría de "estoy seguro de que ya lo arreglé".

La lista antes de la fecha

Catorce puntos, en el orden en que ocurren de verdad. Los cuatro últimos son los que la gente se salta, y son los que deciden si el aviso desaparece.

Dónde encaja PrimeTestLab en esta fecha

Para que la frontera quede clara: no migramos tu código. Subir targetSdk, actualizar dependencias y arreglar los cambios de comportamiento de Android 16 es tu compilación, y este artículo es toda nuestra aportación a esa parte. Lo que sí cubrimos es la otra mitad del choque: los 12 testers reales, participando durante 14 días de forma continua que una cuenta personal nueva necesita antes siquiera de poder llegar a producción.

El problema es el calendario. A quien publica por primera vez en agosto de 2026 se le pide hacer dos cosas difíciles y sin relación en la misma ventana: sacar una compilación con API 36 y sostener una prueba cerrada válida durante dos semanas seguidas. La compilación es una tarea de ingeniería resoluble. Reclutar a doce personas reales que sigan participando durante catorce días, en dispositivos reales, es la parte que se come un mes en silencio.

Hacer la prueba cerrada tú mismo o delegarla

El orden en el que hacerlo este mes

Si tienes los dos problemas a la vez, llévalos en paralelo y no en serie. Arranca la prueba cerrada ya, porque sus 14 días son tiempo de calendario que no puedes comprimir, y haz la migración a API 36 al lado. Empuja la compilación conforme al mismo canal cerrado cuando esté lista, con un código de versión superior y los mismos testers todavía participando. Así la fecha y la ventana de pruebas dejan de competir por la misma quincena.

Preguntas frecuentes

En resumen

Instantánea de políticas verificada el 9 de agosto de 2026. Google actualiza estas páginas sin avisar, así que consulta las fuentes primarias de arriba antes de actuar sobre cualquier fecha. Este artículo tiene programada una nueva verificación justo después del 31 de agosto y otra tras el 1 de noviembre de 2026.