App Mobile

Android: target API 36 e verifica degli sviluppatori, cosa controllare

Dal 31 agosto 2026 Google Play chiede il target Android 16 (API 36), con proroga possibile al 1° novembre. Il 30 settembre è partita la verifica degli sviluppatori in quattro paesi, Italia esclusa, e le app su Google Play vanno registrate nella Play Console.

7 ottobre 2026· 7 min·di NaCode Studios

In breve

Dal 31 agosto 2026 Google Play accetta nuove app e aggiornamenti solo con target Android 16 (API 36). Il 30 settembre è partita la verifica degli sviluppatori in Brasile, Indonesia, Singapore e Thailandia, e chi pubblica su Google Play doveva registrare entro quella data le app non registrate in automatico. L'Italia non è tra i quattro paesi, ma questa registrazione riguarda ogni sviluppatore su Google Play: controlla il target della tua app e il suo stato di registrazione.

Aggiornato al 7 ottobre 2026. Il testo riassume le pagine ufficiali di Google, la più recente aggiornata il 1° ottobre. Date e regole possono cambiare: le fonti sono in fondo.

Target API 36 e proroga

Secondo Google, dal 31 agosto 2026 nuove app e aggiornamenti devono avere come target Android 16 (API 36) o superiore. Le app già pubblicate devono avere come target almeno Android 15 (API 35) per restare disponibili ai nuovi utenti con un Android più recente del loro target. Wear OS, Android Automotive OS, Android TV e Android XR hanno soglie più basse.

Un'app che non si adegua resta sullo store, ma solo per i dispositivi con la stessa versione di Android del suo target o una precedente. Chi l'ha già installata continua a usarla; i download di nuovi utenti possono calare. Sono escluse dai requisiti le app permanentemente private di una singola organizzazione, destinate a uso interno.

Chi ha bisogno di più tempo può chiedere una proroga al 1° novembre 2026, per continuare a distribuire l'app a tutti gli utenti. Secondo Google il modulo si raggiunge dal dettaglio dell'avviso, nella pagina Stato secondo le norme della Play Console, e l'avviso arriva solo alle app non conformi.

Cosa cambia alzando il target

Il target sta nel file Gradle dell'app (in un progetto Flutter sta nella cartella android e segue la versione di Flutter finché non lo fissi a mano). Il nuovo target porta con sé cambi di comportamento da verificare nell'app: Google ne elenca molti, qui ne riportiamo tre che toccano layout e navigazione.

Cambiamento	Con target API 36	Via d'uscita
Schermi grandi (da 600dp)	Orientamento, ridimensionamento e proporzioni bloccati dall'app vengono ignorati	Opt-out temporaneo, che non vale per il target API 37
Tasto indietro	Su Android 16 l'indietro predittivo è attivo e `onBackPressed` non viene più chiamato	Opt-out temporaneo nel manifest, senza data di fine indicata
Schermo intero (edge-to-edge)	Su Android 16 l'app non può più rinunciarvi	Nessuna: il layout va adattato

Con target 36 un'app che blocca lo schermo in verticale riempie la finestra su tablet, pieghevoli e finestre ridimensionabili, senza bande ai lati; fanno eccezione i giochi e chi sceglie il comportamento originale dalle impostazioni del dispositivo. Chi intercetta il tasto indietro con codice proprio deve migrare alle API supportate o impostare android:enableOnBackInvokedCallback su false.

La verifica degli sviluppatori

Dal 30 settembre 2026 la verifica vale per gli utenti di Brasile, Indonesia, Singapore e Thailandia, sui dispositivi Android certificati, ma solo per le installazioni da Google Play e dagli store di Honor, OPPO, Samsung, Transsion, vivo e Xiaomi: chi non ha verificato l'identità e registrato le app non può farle installare da questi store. Altri store e APK scaricati direttamente restano fuori da questa fase, e nel 2027 la verifica si estenderà a tutte le app sui dispositivi certificati. Le pagine di Google nominano solo quei quattro paesi: l'Italia non compare.

Per chi pubblica su Google Play, una nota di Google del 15 luglio chiede di registrare nella Play Console, entro il 30 settembre 2026, le app non registrate in automatico (il 99% lo è), per evitare la rimozione globale da Google Play.

Se pubblichi solo su Google Play usi l'account Play Console che hai già: con Play App Signing le app idonee sono registrate in automatico, e vanno registrate le app di tutti i formati di dispositivo.
Se distribuisci anche fuori da Google Play la registrazione passa dalla Play Console; se distribuisci solo fuori serve un account Android Developer Console, che costa 25 dollari per la distribuzione completa. Per registrare un pacchetto serve un APK firmato con la chiave privata.
Un'organizzazione deve indicare il sito web, verificato con Google Search Console, presentare documenti che ne confermino l'identità e avere un numero D-U-N-S, che è gratuito ma può richiedere fino a 28 giorni.
L'account a distribuzione limitata (fino a 20 dispositivi, senza documento d'identità né costo) è pensato per test e uso personale: secondo noi non per un'app aziendale.

Per gli utenti esperti esiste una procedura avanzata, con un giorno di attesa, per installare app non verificate; secondo noi non è un percorso da chiedere a clienti o dipendenti.

Senza la chiave di firma non si possono registrare i pacchetti, avverte Google, che raccomanda con forza una soluzione sicura per custodirla. Consigliamo di sapere chi la custodisce prima di iniziare.

Cosa significa per il tuo progetto

I due obblighi hanno tempi diversi: il target 36 ti serve al prossimo aggiornamento, mentre la registrazione era dovuta il 30 settembre e va controllata ora nella home della Play Console. Se l'app gira anche fuori dallo store, per esempio come APK ai dipendenti sul campo, Google distingue i dispositivi gestiti (MDM o profilo di lavoro Android Enterprise), dove la registrazione delle app private non serve, da quelli personali o non gestiti, dove la guida di Android Enterprise la richiede.

Cosa controlliamo prima

SpaceClub, la piattaforma per i locali notturni che sviluppiamo come prodotto, ha app per iOS e Android costruite con Flutter, quindi le regole degli store Android valgono anche per noi. Il nostro sviluppo di app mobile arriva fino alla pubblicazione sugli store: se ci chiedi di controllare la tua app prima di una scadenza, partiamo da due punti che il codice non risolve, cioè chi è titolare dell'account sviluppatore e chi custodisce la chiave di firma. La registrazione collega il pacchetto all'account e alla chiave: se uno dei due è in mano a un fornitore che non lavora più con te, va sistemato prima di tutto il resto. Solo dopo guardiamo il codice: target, librerie, cambi della tabella, prove su tablet.

Il risultato è un'analisi scritta con preventivo e roadmap concordati prima di toccare il codice, poi rilasci uno alla volta, ciascuno verificabile. Un limite: la verifica dell'identità spetta a Google e si fa con i documenti dell'azienda titolare dell'account, quindi la registrazione parte da chi lo possiede; noi possiamo prepararla e seguirla, non sostituirci a lui.

Cosa non sappiamo ancora

Non è chiaro come stia andando nei quattro paesi: Android Headlines scrive il 2 ottobre che le regole sono attive, mentre le pagine di Google non riportano dati su app bloccate o rimosse.
Per l'Europa Google parla di 2027 e di diffusione globale, senza un calendario per paese.
Non sappiamo se il modulo di proroga sia già disponibile: la pagina di Google per sviluppatori, aggiornata il 1° ottobre, dice ancora "più avanti nell'anno", senza data.
Non è chiaro come si applichi l'obbligo alle app private sui dispositivi non gestiti: la guida di Android Enterprise indica il 30 settembre 2026 senza nominare paesi, le pagine per sviluppatori ne citano quattro.

Se vuoi che guardiamo la tua app Android, leggi come lavoriamo nello sviluppo di app mobile oppure scrivici.

Fonti

Hai un progetto in mente?

Costruiamolo insieme

Possiamo aiutarti a trasformare un’idea in un prodotto digitale solido, veloce e pronto a crescere.