Target API 36 su Google Play: proroga al 1° novembre 2026 e soluzione per Expo, Flutter e React Native

Il requisito del target API level 36 su Google Play significa che una release compilata per una versione precedente ad Android 16 non può essere pubblicata. A ottobre 2026 Play rifiuta ogni nuova app e ogni aggiornamento con un target inferiore, spesso con il messaggio Target SDK of artifact is too low. Le app che hanno ricevuto un avviso relativo alle norme potevano chiedere più tempo, ma la proroga scade il 1° novembre 2026. Questa guida spiega cosa ti offre ancora la proroga, come portare Expo, Flutter e React Native ad API 36 e cosa tende a rompersi quando lo fai.

Cosa blocca davvero il requisito del target API level 36?

Blocca gli invii. Dal 31 agosto 2026 non puoi caricare una nuova app per smartphone o un aggiornamento se il target non è l'API 36. Le app già pubblicate con target API 35 o superiore restano pienamente disponibili, anche per i nuovi utenti.

Secondo i requisiti del livello API target di Google, "le nuove app e gli aggiornamenti delle app devono avere come target Android 16 (API level 36) o superiore per essere inviati a Google Play". I requisiti variano in base al tipo di dispositivo, e l'unica esenzione totale riguarda le app permanentemente private destinate alla distribuzione interna in un'unica organizzazione.

Un'app esistente sotto questi livelli "sarà disponibile solo sui dispositivi con una versione del sistema operativo Android uguale o inferiore al livello API target dell'app". Chi l'ha già installata continua a usarla come prima. Chi ha uno smartphone più recente, invece, vede il messaggio che l'app "è stata creata per una versione precedente di Android".

Puoi ancora ottenere la proroga prima del 1° novembre 2026?

Solo se Play ha inviato alla tua app un avviso relativo alle norme e il modulo di richiesta è ancora visibile. Anche in quel caso la proroga dura al massimo fino al 1° novembre 2026: sono pochi giorni in più per una correzione quasi pronta, non un nuovo piano.

Google afferma di inviare alle app interessate "un link al modulo di richiesta di proroga tramite le Notifiche" e che il modulo è "disponibile nella pagina dei dettagli dell'avviso o del problema nella pagina Stato delle norme". Alle app già conformi Google non mostra alcun modulo.

1. Apri Play Console e seleziona l'app.
2. Cerca nella Posta in arrivo o nelle Notifiche il messaggio sul livello API target. Se c'è, segui il suo link.
3. Altrimenti vai in Stato delle norme, apri l'avviso o il problema sul livello API target e cerca il modulo di richiesta di proroga nella pagina dei dettagli.
4. Compila il modulo per ogni app interessata. Ogni app ha il proprio avviso.
5. Che la proroga venga concessa o no, pianifica il caricamento di una build con API 36 prima del 1° novembre 2026. Dopo quella data gli aggiornamenti richiedono l'API 36.

Come porti Expo, Flutter e React Native ad API 36?

La strada più pulita è aggiornare a una versione del framework che ha già come target l'API 36: Expo SDK 54, React Native 0.81 o Flutter 3.38. Se per ora non puoi aggiornare, puoi alzare il numero a mano, ma in quel caso devi gestire tu stesso le modifiche di comportamento di Android 16.

Expo. Il changelog dell'SDK 54 indica che SDK 54 e React Native 0.81 "ora hanno come target Android 16". Aggiorna con npx expo install expo@^54.0.0 --fix, esegui npx expo-doctor@latest e, se usi Continuous Native Generation, "elimina le cartelle android e ios se le hai generate per una versione precedente dell'SDK". Con l'SDK 53 puoi provare a impostare targetSdkVersion: 36 tramite il plugin expo-build-properties, ma React Native 0.79 gestisce ancora il tasto indietro con onBackPressed, quindi leggi la sezione successiva prima di pubblicare.

Flutter. Le note di rilascio di Flutter 3.38 indicano come valori predefiniti flutter.compileSdkVersion (API 36) e flutter.targetSdkVersion (API 36) e "consigliano vivamente di usare nei file di build le variabili del livello API fornite dall'SDK di Flutter". La versione 3.38 richiede inoltre almeno Java 17. Se nel modulo dell'app c'è targetSdk = 35 scritto a mano, l'aggiornamento di Flutter non lo cambierà, quindi controlla il file.

React Native bare. Imposta compileSdkVersion e targetSdkVersion a 36 in android/build.gradle. Dalla 0.81 in poi hai quasi finito. Sulle versioni precedenti aggiungi anche android:enableOnBackInvokedCallback="false" a <application> in AndroidManifest.xml. Senza questo, il tasto indietro fisico e il gesto indietro saltano la tua navigazione JavaScript.

Cosa si rompe quando un'app passa al target Android 16?

Più spesso si rompono la navigazione indietro e i layout per schermi grandi. Con target API 36, Android smette di chiamare onBackPressed, non permette più di disattivare l'edge-to-edge e ignora i blocchi di orientamento e ridimensionamento sui display larghi almeno 600dp.

Le modifiche più rilevanti per le app multipiattaforma, tratte dalle modifiche di comportamento di Android 16 di Google:

• Predictive back: "onBackPressed non viene chiamato e KeyEvent.KEYCODE_BACK non viene più inviato". Impostare android:enableOnBackInvokedCallback="false" è una disattivazione temporanea.
• Edge-to-edge: windowOptOutEdgeToEdgeEnforcement è "deprecato e disattivato", quindi un'intestazione o un pulsante in basso può finire sotto la barra di stato o la barra dei gesti.
• Schermi grandi: sui display larghi 600dp o più, screenOrientation, resizableActivity e i limiti di proporzioni vengono ignorati, il che può stirare i layout solo verticali. I giochi sono esenti. PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY è una disattivazione temporanea che "non si applicherà con target API level 37".
• Testo: elegantTextHeight viene ignorato, il che può cambiare l'altezza di riga per arabo, thailandese, tamil e diversi altri sistemi di scrittura.
• Sensori per la salute: BODY_SENSORS è sostituito da autorizzazioni granulari per la salute come READ_HEART_RATE.

Quali problemi hanno incontrato altri sviluppatori passando ad API 36?

Le segnalazioni pubbliche finora mostrano due tipi di problemi: un comportamento del tasto indietro che cambia senza alcun errore e librerie che fanno sì che il livello target del bundle ricevuto da Play sia diverso da quello indicato nei file del progetto.

Audius (React Native 0.79). Nella pull request #14635 il team di Audius riferisce che Google Play ha rifiutato entrambi i caricamenti della versione Android 1.5.186 con Target SDK of artifact is too low. Hanno portato compileSdk e targetSdk da 35 a 36, impostato i build tools a 36.0.0 e aggiunto android.suppressUnsupportedCompileSdk=36, perché "RN 0.79 fissa AGP 8.8". Hanno anche impostato enableOnBackInvokedCallback="false", dato che senza di esso il tasto indietro "avrebbe scavalcato React Navigation". Una PR successiva ha rimosso questa disattivazione dopo il passaggio a React Native 0.81, che registra da solo un OnBackPressedCallback.

Un'app Flutter 3.35.2. Nella issue Flutter #174516 uno sviluppatore ha impostato targetSdk 36 in Gradle e nel manifest, ma Play Console segnalava ancora "Your bundle targets SDK 34, but uses a Play Core library that cannot be used with that version." La rimozione della vecchia libreria com.google.android.play:core:1.10.3 ha causato errori R8 "Missing classes". Risolti quelli, è arrivato "You can't rollout this release because it doesn't allow any existing users to upgrade to the newly added app bundles." Il bundle è stato infine accettato dopo aver aggiunto regole keep di ProGuard, impostato minSdk in modo esplicito e disattivato gli split per lingua, densità e ABI, al prezzo di un download più pesante.

La lezione comune: cambiare il numero in Gradle non basta. Audius ha dovuto correggere il comportamento a runtime, e lo sviluppatore Flutter ha dovuto sistemare una dipendenza che cambiava ciò che Play leggeva dal bundle. Controlla l'artefatto compilato e fai test su un dispositivo Android 16, non solo il file di configurazione.

Come verifichi una build con API 36 prima di caricarla?

Leggi il livello target direttamente dal bundle di release, poi carica il bundle su un canale di test interno o chiuso e prova navigazione indietro, inset e layout per tablet su Android 16. Un rifiuto o un bug in produzione costano molto più tempo di questi controlli.

Esempio pratico: un'app Expo SDK 53 con target API 35 che ha bisogno di un altro aggiornamento.

1. Esegui npx expo install expo@^54.0.0 --fix, poi npx expo-doctor@latest, e correggi tutto ciò che segnala.
2. Se il progetto usa Continuous Native Generation, elimina le vecchie cartelle android e ios e ricompila. Altrimenti applica a mano le modifiche native dell'aggiornamento.
3. Compila l'AAB di release, ad esempio con eas build -p android --profile production.
4. Verifica il target con bundletool dump manifest --bundle app.aab --xpath /manifest/uses-sdk/@android:targetSdkVersion. Deve stampare 36.
5. Carica sul test interno. Su uno smartphone Android 16 premi indietro in ogni schermata annidata, controlla che intestazioni e pulsanti in basso non finiscano sotto le barre di sistema e ruota un tablet o un emulatore ridimensionabile.
6. Promuovi in produzione con note di rilascio che menzionano le correzioni per Android 16.

Per velocizzare i test, usa la configurazione dei tester della nostra guida al test chiuso su Google Play e prendi spunto per il testo dell'aggiornamento dai nostri esempi di note di rilascio. Se preferisci affidare la release a qualcun altro, il nostro servizio di pubblicazione sugli store copre Play Console e App Store Connect a $599 per entrambi gli store. Le quote degli account sviluppatore sono a parte.