Requisito del livello API target su Google Play: a che cosa punta il tuo bundle?
Google Play impone una soglia rigida a targetSdkVersion, e sale ogni anno. Sotto la soglia la Play Console blocca il caricamento e basta: non è il giudizio di un revisore, è un cancello. Questa pagina dà la soglia attuale, il calendario annuale e come leggere a che cosa punta davvero il tuo .aab o .apk prima di scoprirlo nel modo peggiore.
Ultima verifica: 24 luglio 2026.
La soglia attuale e il calendario annuale
La regola di Google è meccanica: la tua app deve puntare a un livello API entro un anno dall'ultima release maggiore di Android. Ogni autunno esce una nuova versione maggiore, quindi intorno al 31 agosto di ogni anno la soglia richiesta sale di uno. Vale per le app nuove e per ogni aggiornamento di un'app esistente: non puoi pubblicare una build che punta sotto la soglia.
Le app esistenti che non aggiorni hanno più margine, ma prima o poi devono adeguarsi per restare disponibili sui dispositivi più recenti. Ecco il calendario così com'è:
| Dal | App nuove e aggiornamenti devono puntare a | Le app esistenti devono puntare a |
|---|---|---|
| 31 ago. 2024 | API 34 (Android 14) | API 34 per restare individuabili |
| 31 ago. 2025 | API 35 (Android 15) | — |
| 31 ago. 2026 | API 36 (Android 16) | API 35 (Android 15) o superiore |
targetSdkVersion vs minSdkVersion vs compileSdkVersion
Gli sviluppatori confondono regolarmente questi tre valori, e solo uno è quello che Play impone. Si impostano in modo indipendente nel build.gradle:
| Proprietà | Che cosa controlla | Regola di Play? |
|---|---|---|
targetSdkVersion | Il livello API per cui la tua app dichiara di essere stata costruita e testata. Attiva i cambiamenti di comportamento di quella versione. È questo che Play controlla. | Sì — soglia rigida. |
minSdkVersion | La versione di Android più vecchia su cui l'app si installa. Più bassa = più dispositivi datati, più percorsi di codice legacy. | No. |
compileSdkVersion | Il livello API contro cui il codice viene compilato: quali API vede il compilatore. Di norma pari o superiore al target. | No, ma deve essere ≥ target per compilare. |
Puoi (e spesso lo fai) tenere un minSdkVersion basso per la copertura e insieme puntare all'ultimo livello API per soddisfare Play: i due valori non sono legati. Alzare targetSdkVersion significa dover gestire i cambiamenti di comportamento della nuova versione; non toglie il supporto ai dispositivi vecchi (quello è minSdkVersion).
L'errore esatto della Play Console
Quando un .aab punta sotto la soglia, la Play Console blocca la release con un messaggio di questa 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.
È un errore che blocca la pubblicazione, non un avviso: il bundle non verrà caricato. I due numeri del messaggio sono il tuo target attuale e la soglia richiesta; la soluzione è alzare targetSdkVersion al livello richiesto nel build.gradle e ricompilare.
Come leggere targetSdkVersion da un .aab / .apk senza Android Studio
Non serve una compilazione completa in Android Studio per controllare a che cosa punta un bundle. Il valore è nel manifest, ma il manifest dentro un artefatto compilato è codificato in binario (AXML in un APK, protobuf in un AAB), quindi `unzip` + `cat` non basta. Usa invece gli strumenti da riga di comando dell'SDK.
Per un .apk
# aapt (o aapt2) decodifica il manifest binario aapt dump badging app.apk | grep -o "targetSdkVersion:'[0-9]*'" # -> targetSdkVersion:'35' # oppure apkanalyzer (incluso nei cmdline-tools dell'SDK Android) apkanalyzer manifest target-sdk app.apk # -> 35
Per un .aab (App Bundle)
# bundletool legge il manifest protobuf con XPath java -jar bundletool.jar dump manifest --bundle=app.aab \ --xpath=/manifest/uses-sdk/@android:targetSdkVersion # -> 35
aapt, aapt2 e apkanalyzer stanno nei build-tools / cmdline-tools dell'SDK Android; bundletool è un jar autonomo di Google. Nessuno compila né esegue l'app: decodificano solo il manifest, quindi il controllo richiede un secondo su qualunque macchina con un JDK.
La via della proroga di un anno
Se davvero non riesci a rispettare la scadenza del 31 agosto, Google offre una proroga una tantum da richiedere dalla Play Console: sposta la tua scadenza al 1° novembre dello stesso anno. È pensata per veri blocchi tecnici, non per ritardi ordinari:
- La richiedi per singola app nella Play Console prima che la scadenza passi: compare un percorso dedicato quando la tua app viene segnalata come non conforme.
- Ti dà circa due mesi in più (fino al 1° novembre), non un altro anno.
- Serve a mantenere disponibile un'app esistente; non ti consente nel frattempo di pubblicare aggiornamenti che puntano sotto la soglia.
- È pensata per casi legittimi (una dipendenza non ancora compatibile, una migrazione importante). Google può respingere richieste che sembrano un modo per rimandare.
La proroga è una sospensione, non una soluzione: l'unica risposta duratura è alzare targetSdkVersion e gestire i cambiamenti di comportamento della nuova versione.
Domande frequenti
Quale livello API target richiede Google Play in questo momento?
Nella finestra 2025-2026 le app nuove e gli aggiornamenti devono puntare almeno al livello API 35 (Android 15). Dal 31 agosto 2026 la soglia per app nuove e aggiornamenti sale all'API 36 (Android 16), e le app esistenti devono puntare almeno all'API 35 per restare disponibili sui dispositivi più recenti.
Alzare targetSdkVersion fa perdere i telefoni vecchi?
No. Il supporto ai dispositivi datati è governato da minSdkVersion, che è indipendente. Puoi tenere un minSdkVersion basso e alzare comunque targetSdkVersion per soddisfare Play. Alzare il target però comporta gestire i cambiamenti di comportamento della nuova versione di Android.
La Play Console dice che il mio target è troppo basso ma Android Studio mostra il numero giusto. Perché?
Controlla il valore nell'artefatto realmente compilato, non solo nei sorgenti. Un product flavor, un override del manifest o una build vecchia possono pubblicare un targetSdkVersion più basso di quanto suggerisca il tuo build.gradle. Leggilo direttamente dal .aab/.apk con bundletool o aapt per vedere che cosa hai caricato davvero.
Posso avere più tempo dopo il 31 agosto?
Sì: la Play Console offre una proroga una tantum fino al 1° novembre dello stesso anno per le app che non riescono a rispettare la scadenza. È per blocchi tecnici legittimi e mantiene disponibile solo l'app esistente; non permette di pubblicare aggiornamenti sotto la soglia.
Il requisito del livello API target è la stessa cosa di un rifiuto in revisione?
No. È un cancello automatico al caricamento nella Play Console, applicato prima di qualsiasi revisione. Nessun revisore è coinvolto: il bundle semplicemente non si carica finché targetSdkVersion non raggiunge la soglia.
Da leggere anche: Perché Google Play rifiuta le app · Checklist di invio per Android
Fonti
Controlla la tua build prima di inviarla
Fai passare il tuo .ipa o .apk attraverso App Review Checker e individua questi problemi in pochi secondi.
Controlla un'app