Scadenza API 36 su Google Play: cosa cambia il 31 agosto 2026

Google alza una volta l’anno la soglia minima del livello API di destinazione del Play Store, e il 2026 è il ciclo di API 36. La parte confusa non è il numero. La parte confusa è che "il requisito sul livello API di destinazione" sono in realtà due regole con lo stesso nome: una governa che cosa puoi caricare, l’altra, più bassa, governa chi può ancora installare quello che è già pubblicato. Quasi tutte le pagine che si posizionano su questa domanda le confondono, ed è così che gli sviluppatori finiscono per rifare un’applicazione che non andava rifatta, o per ignorare un avviso di Play Console che invece contava.

Questo articolo le separa, ti dà i numeri per tipo di dispositivo e poi risponde alla domanda che ad agosto arriva davvero alla nostra assistenza: che cosa succede a un’app che è a metà di un test chiuso (closed testing) da 12 tester e 14 giorni? PrimeTestLab segue quel lato del test per gli sviluppatori, quindi vediamo questo scontro di tempi di continuo, e le indicazioni di quella sezione valgono sia che tu usi un servizio sia che recluti i tester da solo. Ogni data e ogni livello qui sotto sono stati verificati sulle pagine di Google il 9 agosto 2026, e tutto ciò che Google non ha davvero documentato è segnalato come tale invece di essere riempito con un’ipotesi sicura di sé.

La regola in una frase

Dal 31 agosto 2026 una normale app per telefoni, tablet, pieghevoli o Android Auto deve avere come destinazione Android 16, livello API 36 o superiore per essere inviata a Google Play, che sia un’app del tutto nuova o l’aggiornamento di una già pubblicata. Questa singola frase copre la maggior parte dei lettori. Le eccezioni, e la soglia più bassa e separata per le app che non tocchi, sono l’argomento del resto dell’articolo.

Un solo nome, due regole diverse

Google usa l’espressione "requisito sul livello API di destinazione" per due cose che si comportano in modo del tutto diverso. Tenerle separate è la cosa più utile che puoi fare con questa pagina.

Quindi un’app ferma su API 35 senza aggiornamenti in programma è conforme il 31 agosto secondo la regola 2, e diventa non conforme nell’istante in cui provi a pubblicare qualcosa secondo la regola 1. Non è una contraddizione, è il progetto: Google alza l’asticella per ciò che entra nello store più in fretta di quanto la alzi per ciò che ci resta.

Le tre parole che Google definisce con precisione

La policy poggia su tre termini, e il significato di ciascuno decide sotto quale regola ti trovi:

• App nuova: un’app "non ancora pubblicata su Google Play". Il primo caricamento di un nome di pacchetto.
• App esistente: un’app già pubblicata su Google Play.
• Aggiornamento dell’app: una nuova versione di un’app esistente inviata alla revisione per sostituire quella attuale. Un aggiornamento si giudica con la regola di invio, non con quella di visibilità.

Requisiti per tipo di dispositivo

"App Android" non è una riga sola. Telefoni, tablet, pieghevoli e Android Auto salgono ad API 36. Wear OS e Android Automotive OS si fermano ad API 35. Android TV e Android XR si fermano ad API 34. Le soglie per un’app che non aggiorni sono più basse ancora, e il selettore qui sotto passa da un insieme all’altro.

Android Auto non è Android Automotive OS

Questi due nomi costano tempo vero agli sviluppatori ogni anno. Android Auto proietta un’app dal telefono allo schermo dell’auto, quindi l’app è un’app per telefoni e segue la regola dei telefoni: API 36. Android Automotive OS è il sistema operativo che gira sul veicolo stesso ed è una delle eccezioni con destinazione più bassa indicate esplicitamente: API 35. Se pubblichi un’app di musica o navigazione per entrambi, ti serve la più alta delle due.

Riguarda anche te? Rispondi a tre domande

Se il 31 agosto sia un tuo problema dipende da tre cose: che cosa stai per fare, per quale tipo di dispositivo pubblichi e quale destinazione ha davvero la tua build attuale. Lo strumento qui sotto applica le soglie pubblicate da Google a quella combinazione e ti dice sotto quale delle due regole ti trovi.

Se il verdetto dice che sei a posto, dai comunque un’occhiata alla checklist prima della scadenza in fondo, perché "il mio sorgente imposta destinazione 36" e "l’artefatto che Google ha valutato dichiara 36" non sono la stessa affermazione. La falsa sicurezza più diffusa di tutto questo ciclo è uno sviluppatore che legge il proprio file Gradle invece del bundle che ha caricato.

Che cosa succede davvero se sfori il 31 agosto

Due cose diverse, a seconda della regola sotto cui ti trovi. Se provi a caricare una build sotto la soglia, l’invio non soddisfa il requisito. Se semplicemente lasci stare un’app pubblicata sotto la soglia di visibilità, smette di essere trovabile e installabile per i nuovi utenti su dispositivi con una versione di Android più recente di quella per cui è progettata. Nessuno dei due esiti è la cancellazione.

Se provi a caricare

Nota a che cosa è legata questa conseguenza: all’atto di caricare. Il calendario da solo non fa nulla a una build già online. È per questo che un’app può essere perfettamente conforme il 1º settembre e bloccata il 2, solo perché hai deciso di pubblicare una correzione di bug.

Se lasci un’app pubblicata sotto la soglia

È la parte che i concorrenti descrivono come "la tua app sparisce", e sbagliano in un modo che conta. La formulazione di Google è che l’app "smetterà di essere trovabile" per un gruppo preciso di utenti. In concreto:

• I nuovi utenti su dispositivi più recenti perdono l’accesso. Se il dispositivo di un utente esegue una versione di Android superiore alla destinazione della tua app, Google Play non gliela mostra e non gliela installa più.
• I nuovi utenti su dispositivi più vecchi non sono toccati. Un dispositivo che esegue lo stesso livello API della destinazione dell’app, o uno inferiore, può ancora riceverla.
• Chi l’ha già installata non è toccato. Chiunque abbia già installato l’app può continuare a trovarla, reinstallarla e usarla sulle versioni di Android supportate.
• I link diretti dicono la verità. A un utente su un dispositivo più recente non idoneo che apre il tuo link del Play Store viene detto che l’app è stata "creata per una versione precedente di Android".

Che cosa non succede

Ogni agosto questa policy genera le stesse quattro paure nei forum di assistenza di Google. Nessuna di esse è ciò che la pagina sul livello API di destinazione descrive.

Passare ad API 36 elimina il supporto ai telefoni più vecchi?

No, non di per sé. targetSdk dichiara il livello di comportamento Android per cui la tua app è costruita e testata. minSdk decide la versione più vecchia di Android su cui può essere installata. Sono numeri distinti, e alzare la destinazione a 36 non alza da solo il minimo: la tua app può continuare a supportare versioni di Android più vecchie fino a quel minimo, purché il tuo codice e le dipendenze aggiornate restino compatibili.

È l’equivoco che genera più allarme a ogni ciclo. Uno sviluppatore legge "deve avere come destinazione Android 16", assume che significhi "gira solo su Android 16" e conclude che Google gli ha appena cancellato la maggior parte dei dispositivi raggiungibili. Sposta il minimo qui sotto e guarda che cosa cambia davvero.

I tre numeri, e quale controlla Google Play

Che cosa significa se la tua app è in test chiuso proprio adesso

Se hai un account sviluppatore personale nuovo e stai facendo il test chiuso obbligatorio da 12 tester e 14 giorni consecutivi, la scadenza cade in mezzo alla tua finestra. La mossa sicura è portare la build con API 36 nello stesso canale chiuso prima del 31 agosto, tenere tutti i tester attivati e non lasciare mai che una scadenza ti costringa a cambiare canale o a ricominciare con altri tester.

La pagina di Google sull’API di destinazione e quella sul test chiuso sono scritte da team diversi per scopi diversi, e nessuna delle due parla dell’altra. Questo lascia un vuoto reale, e la cosa onesta da fare è mostrarti esattamente dove finisce il terreno documentato.

Che cosa è verificato

• Un account personale nuovo che rientra nei criteri deve fare un test chiuso con almeno 12 tester attivati continuamente negli ultimi 14 giorni prima di poter richiedere l’accesso in produzione. Vale per gli account personali creati dopo il 13 novembre 2023. Verificato
• La documentazione per sviluppatori di Google dice che un APK caricato deve soddisfare i requisiti sul livello API di destinazione di Play, e non pubblica nessuna eccezione per i canali di test. Quella formulazione vale per qualsiasi canale, non è specifica dei test, quindi pianifica un caricamento nuovo sul canale chiuso dopo la scadenza come se richiedesse API 36. È una deduzione forte, non una regola documentata sui canali di test. Parziale
• Le indicazioni di Google invitano gli sviluppatori a continuare ad aggiornare l’app in test chiuso mentre risolvono i problemi, e definiscono il periodo valido intorno alla continuità dell’attivazione dei tester, non intorno a un artefatto congelato. Verificato
• Il test interno ha un tetto di 100 tester e non sostituisce il test chiuso che dà i requisiti. Verificato

Che cosa Google non ha documentato

Poiché la risposta è ignota, la strategia giusta non è provare a indovinarla. È rendere la domanda irrilevante avendo una build conforme nel canale prima della data: è sicura in entrambi i casi e non ti costa nulla se l’artefatto vecchio avrebbe comunque continuato a funzionare.

La sequenza sicura in ogni caso

1. Tieni lo stesso canale chiuso e lo stesso gruppo di tester

   Non creare un canale nuovo per ospitare la build con API 36 e non rimuovere i tester attivati. La continuità di 14 giorni che Google conta riguarda i tester che restano attivati, quindi l’iscrizione è il bene che stai proteggendo.

2. Compila e testa API 36 prima della scadenza, non il giorno stesso

   Tratta la migrazione come un compito a sé, con il suo giro di test. Scoprire il 30 agosto che il layout a tutto schermo si rompe è una giornata molto diversa dallo scoprirlo il 10.

3. Caricala sul canale chiuso esistente con un versionCode più alto

   Ogni bundle che ne sostituisce un altro ha bisogno di un versionCode incrementato. Google definisce il periodo valido intorno alla continuità dell’attivazione dei tester e invita esplicitamente a continuare a correggere i problemi durante il test, ma non pubblica una garanzia assoluta che copra ogni scenario di sostituzione della build. Mantieni lo stesso canale e gli stessi tester attivati, e dopo controlla il contatore in Play Console. Il meccanismo completo dell’aggiornamento a test in corso vale la lettura se è il tuo primo ciclo.

4. Verifica che la versione sia arrivata davvero ai tester

   Una versione pubblicata non è la stessa cosa di una versione consegnata. Controlla che la versione chiusa sia attiva, che il versionCode sia più alto e che i tester nella lista degli attivati vedano l’aggiornamento.

5. Ricontrolla lo stato delle norme dopo la lavorazione

   Dai tempo al bundle di essere elaborato, poi riapri la pagina dello stato delle norme dell’app. Se l’avviso sull’API di destinazione resta, lavora la lista di diagnosi invece di cancellare versioni a caso.

6. Chiedi la proroga solo se la migrazione davvero non ce la fa

   Ti compra tempo fino al 1º novembre 2026 e si richiede per ogni app interessata. Non è un motivo per fermare il lavoro tecnico.

Come chiedere la proroga al 1º novembre 2026

Gli sviluppatori interessati possono chiedere una proroga che tiene attiva la distribuzione fino al 1º novembre 2026. Si richiede per singola app, dall’avviso sulle norme di quell’app in Play Console. Google non la descrive come automatica, garantita o come un’esenzione permanente, quindi continua la migrazione mentre la richiesta è aperta.

Google Play Console · screenshot reale Clicca per ingrandire

1. Apri l’app interessata in Play Console

   L’accesso alla proroga è per singola app, non per account. Se pubblichi più app, mettiti in conto di ripeterlo per ognuna di quelle interessate.

   Verificato
2. Vai allo stato delle norme

   Solo le app che Google considera non conformi dovrebbero riportare il problema sull’API di destinazione. Se l’app è già conforme, non c’è nulla da prorogare né alcun modulo da trovare.

   Verificato
3. Apri l’avviso sull’API di destinazione o i dettagli del problema

   Il titolo del problema mostrato nello screenshot qui sopra è App must target Android 16 (API level 36) or higher. La formulazione può ancora variare per app e per fase di distribuzione, quindi consideralo ciò che un account reale ha visto e non una stringa universale garantita.

   Verificato
4. Segui il link della proroga nel problema o nelle notifiche

   Google indirizza una parte degli sviluppatori interessati tramite la notifica dell’app invece che dal pannello del problema. Controlla entrambi prima di concludere che l’opzione non esiste per te.

   Verificato
5. Invia le informazioni richieste

   Google non pubblica le domande esatte nella pagina di assistenza pubblica, quindi considera non verificato qualsiasi elenco di "quello che chiedono". Rispondi basandoti sul tuo piano di migrazione reale.

   Parziale
6. Considera il 1º novembre 2026 il limite definitivo

   La proroga sposta la data, non elimina il requisito. Quello che non sei riuscito a finire entro il 31 agosto deve essere pronto entro il 1º novembre.

   Verificato
7. Continua la migrazione mentre la richiesta è aperta

   Nella formulazione di Google non c’è nulla che prometta l’approvazione. Pianificare su una proroga che non hai ancora ricevuto è l’ipotesi più costosa disponibile in questo ciclo.

   Parziale

Un’ultima distinzione da tenere a mente: Google lega la nota sulla proroga al requisito di API 36, e nel testo la descrive quasi sempre come qualcosa che preserva la distribuzione di un’app esistente. Non percorre con la stessa precisione tutte le combinazioni di app nuova, aggiornamento e app esistente. Prima di dare per scontato che una proroga copra un caricamento specifico che hai in programma, leggi che cosa dice di coprire l’avviso della tua app.

Come portare un’app ad API 36

Quattro passaggi: installa l’SDK di API 36, porta compileSdk e targetSdk a 36, aggiorna le dipendenze che si rompono quando lo fai e testa le modifiche di comportamento di Android 16. Cambiare il numero è una modifica di una riga. Dimostrare che l’app funziona ancora è la migrazione vera e propria.

Passaggio 1: installa l’SDK di Android 16

Apri Android Studio, vai su SDK Manager e installa la Android SDK Platform per il livello API 36 insieme ai build tools 36.x.x attuali. Senza la piattaforma installata, alzare compileSdk produce soltanto un errore di build che sembra non avere nulla a che fare con quello che hai appena cambiato.

Passaggio 2: alza i livelli nella tua build

Scegli il tuo stack. Il percorso del file e le righe esatte cambiano, la destinazione no: il manifest dentro il bundle che carichi deve dichiarare destinazione 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
}

Passaggio 3: aggiorna dipendenze e strumenti del framework

Alzare il livello di compilazione è il punto in cui le dipendenze vecchie cedono. Mettiti in conto di toccare Android Gradle Plugin, Gradle stesso, Kotlin, le librerie AndroidX, Google Play services e qualsiasi SDK di pubblicità o analytics che porti codice nativo. Questo articolo di proposito non pubblica "le versioni giuste", perché le versioni compatibili cambiano ogni settimana e un elenco fisso qui sarebbe fuorviante nel giro di quindici giorni. Prendile dalle note di rilascio aggiornate del tuo framework il giorno in cui migri.

Passaggio 4: compila, carica e verifica l’artefatto

• Genera un Android App Bundle firmato e incrementa il versionCode.
• Testa l’artefatto di release, non solo una build di debug. Minificazione e riduzione delle risorse rompono cose che le build di debug nascondono.
• Carica sul canale previsto e verifica in Play Console che l’artefatto riporti livello API di destinazione 36.
• A lavorazione conclusa, passa in rassegna tutti i canali attivi e riapri lo stato delle norme.

Comportamenti di Android 16 da testare prima di pubblicare API 36

Passare a destinazione API 36 attiva i comportamenti di Android 16 per la tua app sui dispositivi con Android 16. I comportamenti prioritari da testare sono il layout a tutto schermo, il ritorno predittivo, la libertà di orientamento sugli schermi grandi, i permessi sulla salute, la pianificazione a intervallo fisso e il layout del testo. Spunta qui sotto ciò che ti riguarda e ottieni la lista di test della tua app invece di una generica.

Layout a tutto schermo e ritorno predittivo: il raggio d’impatto più ampio

Il layout a tutto schermo ha un raggio d’impatto ampio perché non richiede che la tua app usi API esotiche. Su Android 16 un’app con destinazione API 36 non può più usare il vecchio attributo di esclusione, quindi i contenuti che davano per scontato che le barre di sistema lasciassero spazio ora ci finiscono sotto. Il sintomo è estetico fino al momento esatto in cui un pulsante principale finisce sotto la barra dei gesti e smette di essere toccabile.

Il ritorno predittivo ha un raggio d’impatto altrettanto ampio. Se la tua app registra una gestione dell’indietro vecchio stile, quel percorso potrebbe semplicemente non scattare come prima una volta che il ritorno predittivo è attivo per impostazione predefinita con destinazione 36. Prova l’indietro da ogni livello di navigazione che hai: modali, WebView, moduli con modifiche non salvate e l’ultima schermata prima dell’uscita.

Che cosa non è una rottura universale di destinazione 36

E il requisito sulle pagine da 16 KB?

Requisito diverso, data diversa, stesse app. La scadenza sull’API di destinazione riguarda il livello che dichiara il tuo manifest. Il requisito sulle pagine da 16 KB riguarda il fatto che le tue librerie native funzionino su dispositivi con pagine di memoria da 16 KB. Le indicazioni attuali di Google indicano il 1º febbraio 2027 come data oltre la quale gli aggiornamenti delle app interessate senza supporto a 16 KB non potranno più essere rilasciati.

• Chi riguarda: il requisito di Google si applica alle app con destinazione API 35 o superiore sui dispositivi Google Play a 64 bit. All’interno di quel gruppo, le app che includono librerie native .so, direttamente o tramite un SDK, sono quelle che più probabilmente avranno bisogno di ricompilazione e allineamento espliciti. Se la tua app è solo Kotlin o Java, in genere è già compatibile, ma vale comunque la pena testarla invece di darlo per scontato.
• Che cosa non è: non fa parte della scadenza del 31 agosto 2026 sull’API di destinazione, e superare l’uno non significa superare l’altro.
• Perché arrivano insieme: chi alza il livello di destinazione questo mese ricompila comunque, ed è lì che il controllo sulle pagine viene a galla. È questa coincidenza di tempi a farli confondere.

Se la tua app include librerie native, tratta il controllo sulle pagine come un compito a sé, con il suo giro di test, invece di infilarlo nella build di API 36 all’ultimo momento. Le due modifiche toccano parti diverse della build, e fare il debug di entrambe insieme è il modo in cui una migrazione da una settimana ne diventa una da tre.

Hai caricato API 36 e l’avviso è ancora lì

Di solito è una di tre cose: il bundle non ha finito la lavorazione e lo stato delle norme non si è aggiornato, un artefatto più vecchio è ancora su un altro canale attivo, oppure l’artefatto che hai caricato non dichiara davvero 36 anche se il tuo progetto lo fa. Scendi lungo la lista e non metterti a cancellare versioni.

Il titolo del problema che gli sviluppatori stanno segnalando è Your app must target Android 16 (API level 36) or higher, in inglese come appare in Play Console. Google non ha pubblicato una stringa di errore canonica e completa per ogni flusso di caricamento, quindi tratta le formulazioni esatte che trovi online, quella compresa, come osservate e non ufficiali.

Un’abitudine sola risolve gran parte di tutto questo in modo definitivo: dopo ogni caricamento, rileggi il livello API di destinazione dall’artefatto in Play Console e annotalo accanto al versionCode. Ci vogliono dieci secondi ed elimina dalla tua settimana l’intera categoria dei "sono sicuro di averlo sistemato".

La checklist prima della scadenza

Quattordici voci, nell’ordine in cui succedono davvero. Le ultime quattro sono quelle che si saltano, e sono proprio quelle che decidono se l’avviso sparisce.

Dove entra PrimeTestLab in questa scadenza

Per essere chiari sul confine: non migriamo il tuo codice. Alzare targetSdk, aggiornare le dipendenze e sistemare le modifiche di comportamento di Android 16 è la tua build, e questo articolo è tutto il nostro contributo a quella parte. Quello di cui ci occupiamo è l’altra metà dello scontro: i 12 tester reali, attivati per 14 giorni consecutivi, che a un account personale nuovo servono prima di poter arrivare alla produzione.

Il problema sono i tempi. A chi pubblica per la prima volta ad agosto 2026 si chiede di fare nella stessa finestra due cose difficili e senza alcun rapporto tra loro: pubblicare una build con API 36 e tenere in piedi per due settimane di fila un test chiuso valido. La build è un compito di ingegneria risolvibile. Trovare dodici persone vere che restino attivate per quattordici giorni, su dispositivi reali, è la parte che si mangia un mese in silenzio.

Fare il test chiuso da soli oppure affidarlo

In che ordine affrontarlo questo mese

Se hai davanti entrambi i problemi, affrontali in parallelo e non in sequenza. Avvia subito il test chiuso, perché i suoi 14 giorni sono tempo di calendario che non puoi comprimere, e porta avanti la migrazione ad API 36 accanto a quello. Quando è pronta, spingi la build conforme nello stesso canale chiuso, con un versionCode più alto e gli stessi tester ancora attivati. Così la scadenza e la finestra di test smettono di contendersi le stesse due settimane.

Domande frequenti

In sintesi

Fotografia delle norme verificata il 9 agosto 2026. Google aggiorna queste pagine senza preavviso, quindi controlla le fonti primarie qui sopra prima di prendere decisioni basate su una data. Questo articolo è programmato per una nuova verifica subito dopo il 31 agosto e di nuovo dopo il 1º novembre 2026.