Requisito de nivel de API objetivo en Google Play: ¿a qué apunta tu bundle?
Google Play impone un mínimo duro a targetSdkVersion, y sube cada año. Por debajo de ese mínimo, Play Console bloquea la subida sin más: no es el criterio de un revisor, es una puerta. Esta página da el umbral actual, el calendario anual y cómo leer a qué apunta realmente tu .aab o .apk antes de enterarte por las malas.
Última revisión: 24 de julio de 2026.
El mínimo actual y el calendario anual
La regla de Google es mecánica: tu app tiene que apuntar a un nivel de API que esté dentro del año siguiente a la última versión mayor de Android. Cada otoño sale una versión mayor, así que alrededor del 31 de agosto de cada año el mínimo exigido sube en uno. Se aplica a apps nuevas y a todas las actualizaciones de una app existente: no puedes publicar una build que apunte por debajo del mínimo.
Las apps existentes que no actualizas tienen más margen, pero acaban teniendo que cumplir para seguir disponibles en dispositivos nuevos. Este es el calendario tal como está:
| Desde | Apps nuevas y actualizaciones deben apuntar a | Apps existentes deben apuntar a |
|---|---|---|
| 31 ago. 2024 | API 34 (Android 14) | API 34 para seguir siendo detectables |
| 31 ago. 2025 | API 35 (Android 15) | — |
| 31 ago. 2026 | API 36 (Android 16) | API 35 (Android 15) o superior |
targetSdkVersion vs minSdkVersion vs compileSdkVersion
Los desarrolladores confunden estos tres constantemente, y solo uno es el que Play exige. Se definen de forma independiente en build.gradle:
| Propiedad | Qué controla | ¿Regla de Play? |
|---|---|---|
targetSdkVersion | El nivel de API para el que tu app declara haber sido construida y probada. Activa los cambios de comportamiento de esa versión. Este es el que Play controla. | Sí, mínimo duro. |
minSdkVersion | La versión de Android más antigua en la que se instalará la app. Cuanto más baja, más dispositivos antiguos y más rutas de código heredado. | No. |
compileSdkVersion | El nivel de API contra el que se compila el código: qué APIs ve el compilador. Normalmente igual o superior al objetivo. | No, pero debe ser ≥ objetivo para compilar. |
Puedes (y sueles) mantener un minSdkVersion bajo para llegar a más gente y a la vez apuntar al último nivel de API para satisfacer a Play: no están relacionados. Subir targetSdkVersion implica que tienes que manejar los cambios de comportamiento de la nueva versión; no quita soporte de dispositivos antiguos (eso es minSdkVersion).
El error exacto de Play Console
Cuando un .aab apunta por debajo del mínimo, Play Console bloquea la versión con un mensaje de esta forma:
Your app currently targets API level 34 and must target at least API level 35 to ensure it is built on the latest APIs optimized for security and performance. To upload an app bundle it must target API level 35 or higher.
Es un error que bloquea la publicación, no un aviso: el bundle no se subirá. Los dos números del mensaje son tu objetivo actual y el mínimo exigido; la solución es subir targetSdkVersion al nivel requerido en build.gradle y recompilar.
Cómo leer targetSdkVersion de un .aab o .apk sin Android Studio
No hace falta una compilación completa de Android Studio para comprobar a qué apunta un bundle. El valor está en el manifiesto, pero el manifiesto dentro de un artefacto compilado está codificado en binario (AXML en un APK, protobuf en un AAB), así que `unzip` + `cat` no sirve. Usa las herramientas de línea de comandos del SDK.
Para un .apk
# aapt (o aapt2) descodifica el manifiesto binario aapt dump badging app.apk | grep -o "targetSdkVersion:'[0-9]*'" # -> targetSdkVersion:'35' # o apkanalyzer (viene con las cmdline-tools del SDK de Android) apkanalyzer manifest target-sdk app.apk # -> 35
Para un .aab (App Bundle)
# bundletool lee el manifiesto protobuf con XPath java -jar bundletool.jar dump manifest --bundle=app.aab \ --xpath=/manifest/uses-sdk/@android:targetSdkVersion # -> 35
aapt, aapt2 y apkanalyzer viven en las build-tools / cmdline-tools del SDK de Android; bundletool es un jar independiente de Google. Ninguno compila ni ejecuta la app: solo descodifican el manifiesto, así que la comprobación tarda un segundo en cualquier máquina con un JDK.
La vía de la prórroga de un año
Si de verdad no puedes cumplir el plazo del 31 de agosto, Google ofrece una prórroga única que se solicita desde Play Console: lleva tu fecha límite al 1 de noviembre del mismo año. Está pensada para bloqueos técnicos reales, no para retrasos rutinarios:
- La solicitas por app en Play Console antes de que venza el plazo: hay un flujo específico cuando tu app queda marcada como no conforme.
- Te da unos dos meses extra (hasta el 1 de noviembre), no otro año.
- Sirve para mantener disponible una app existente; no te deja publicar mientras tanto actualizaciones que apunten por debajo del mínimo.
- Está pensada para casos legítimos (una dependencia todavía incompatible, una migración grande). Google puede denegar solicitudes que parezcan una forma de escaquearse.
La prórroga es un aplazamiento, no una solución: la única respuesta duradera es subir targetSdkVersion y manejar los cambios de comportamiento de la nueva versión.
Preguntas frecuentes
¿Qué nivel de API objetivo exige Google Play ahora mismo?
En la ventana 2025-2026, las apps nuevas y las actualizaciones deben apuntar al menos al nivel de API 35 (Android 15). Desde el 31 de agosto de 2026, el mínimo para apps nuevas y actualizaciones sube a API 36 (Android 16), y las apps existentes deben apuntar al menos a API 35 para seguir disponibles en dispositivos nuevos.
¿Subir targetSdkVersion deja fuera a los móviles antiguos?
No. El soporte de dispositivos antiguos lo controla minSdkVersion, que es independiente. Puedes mantener un minSdkVersion bajo y aun así subir targetSdkVersion para cumplir con Play. Eso sí, subir el objetivo implica manejar los cambios de comportamiento de la nueva versión de Android.
Play Console dice que mi objetivo es demasiado bajo pero Android Studio muestra el número correcto. ¿Por qué?
Comprueba el valor en el artefacto realmente compilado, no solo en el código fuente. Un product flavor, una sobrescritura del manifiesto o una compilación antigua pueden publicar un targetSdkVersion menor del que sugiere tu build.gradle. Léelo directamente del .aab/.apk con bundletool o aapt para ver qué has subido de verdad.
¿Puedo conseguir más tiempo pasado el 31 de agosto?
Sí: Play Console ofrece una prórroga única hasta el 1 de noviembre del mismo año para las apps que no puedan cumplir el plazo. Es para bloqueos técnicos legítimos y solo mantiene disponible la app existente; no permite publicar actualizaciones por debajo del mínimo.
¿El requisito de API objetivo es lo mismo que un rechazo en la revisión?
No. Es una puerta automática de subida en Play Console, que actúa antes de cualquier revisión. No interviene ningún revisor: el bundle simplemente no se sube hasta que targetSdkVersion alcanza el mínimo.
Relacionado: Por qué Google Play rechaza apps · Checklist de envío para Android
Fuentes
Analiza tu build antes de enviar
Pasa tu .ipa o .apk por App Review Checker y detecta estos problemas en segundos.
Analizar una app