Il periodo di tolleranza per l'API 36 di Google Play è finito, e le scadenze sui permessi del 2027 sono già in calendario

Dal 31 agosto 2026 Google Play accetta solo nuove app e aggiornamenti che abbiano come target Android 16 (API level 36) o superiore. Le app per Wear OS, Android Automotive OS, Android TV e Android XR sono escluse. I team che avevano bisogno di più tempo potevano chiedere una proroga fino al 1° novembre 2026. Quella data è passata. Se il tuo targetSdkVersion è ancora inferiore a 36, al momento non puoi pubblicare un aggiornamento su Play, hotfix compreso, anche quello che potrebbe servirti la settimana prossima.
Per le app esistenti che non vengono aggiornate c'è una regola a parte. Devono avere come target almeno Android 15 (API level 35) per restare disponibili ai nuovi utenti su dispositivi con una versione di Android più recente del target dell'app. Sotto quella soglia, l'app compare solo sui dispositivi con la stessa versione di Android o con una precedente. Quindi un'app che nessuno tocca da tempo non viene rimossa, ma diventa sempre più difficile da trovare.
In più, il 29 ottobre 2026 Google ha annunciato una serie di modifiche alle policy, con date di applicazione distribuite nel corso del 2027. Nessuna è urgente oggi. Ma sono tutte cose che si trasformano in panico se te ne accorgi due settimane prima della scadenza.
Il calendario del 2027
Ecco le date tratte dalla tabella Policy Deadlines di Google e dalla pagina delle policy di Play:
- 27 gennaio 2027: contatti. La policy sul permesso Contatti limita l'accesso esteso ai contatti degli utenti. Le app che non ne hanno bisogno devono usare l'Android Contact Picker.
- 27 gennaio 2027: posizione precisa. Le app con target Android 17 (API 37+) devono usare il pulsante di posizione di Android per le richieste di posizione precisa una tantum o sporadiche. Se mantieni
ACCESS_FINE_LOCATION, serve una dichiarazione nella Play Console che spieghi perché il pulsante di posizione o la posizione approssimativa non bastano. - 27 gennaio 2027: sconti sugli abbonamenti. Gli abbonamenti con sconti continuativi basati su requisiti di idoneità, come i piani per studenti, devono indicare chiaramente i criteri di idoneità, come funziona la verifica e cosa succede a prezzo e vantaggi quando l'utente non è più idoneo.
- 14 aprile 2027: AppFunctions. Le AppFunctions non devono ingannare o manipolare gli agenti di IA, aggirarne i controlli di sicurezza o interferire con altre app.
- 25 agosto 2027:
ACCESS_LOCAL_NETWORK. L'accesso alla rete locale è limitato alle app che ne hanno bisogno per la funzionalità principale quando i selettori di dispositivi comeNsdManagernon bastano. Le app con target Android 17 o superiore hanno bisogno di una dichiarazione nella Play Console per usarlo. - 25 agosto 2027:
MANAGE_CONTACTS. Limitato alle app la cui funzionalità principale lo richiede quando i selettori di sistema non bastano, con una dichiarazione nella Play Console. Tutti gli altri devono usare intent di piattaforma con ambito ristretto.
Perché l'aggiornamento del target API continua a cogliere i team di sorpresa
Nei nostri progetti Android nativi, alzare targetSdkVersion raramente è la parte difficile. Cambiare un numero in Gradle richiede un minuto. Il lavoro sta in tutto ciò che quel numero attiva: nuovi comportamenti della piattaforma a cui la tua app ora aderisce, librerie che non si sono ancora aggiornate e dispositivi di test che non coprono la nuova versione. Abbiamo visto una modifica di una riga trasformarsi in uno sprint di tre settimane perché l'SDK di pagamento o una libreria BLE non aveva ancora rilasciato una versione compatibile.
Lo schema che vediamo più spesso è questo: l'app funziona, nessuno è assegnato a seguirla e il requisito sul target API arriva come avviso della Play Console in una casella di posta condivisa. Poi compare un bug vero, la correzione è pronta e il caricamento viene rifiutato. A quel punto ti ritrovi a fare una migrazione di piattaforma sotto pressione, con un problema aperto in produzione. È la situazione in cui si trovano molti team questa settimana.
La mia opinione sincera: tratta l'aggiornamento annuale del target API come una dipendenza di cui sei responsabile, non come una seccatura imposta da Google. Mettilo in roadmap ogni primavera, quando viene annunciato il nuovo requisito, e fallo quando non c'è niente che brucia.
Le modifiche ai permessi contano più di quanto sembri
Le regole del 2027 condividono un'unica idea. I permessi ampi vengono sostituiti da selettori e pulsanti di sistema, e se vuoi mantenere la versione ampia devi giustificarti nella Play Console.
L'abbiamo notato soprattutto nelle app per la sanità e l'IoT. Le app IoT tendono a chiedere presto l'accesso alla rete locale, perché la scoperta dei dispositivi è la prima schermata, ed è facile chiedere più del necessario. Se un selettore basato su NsdManager copre il tuo flusso di scoperta, la regola di agosto 2027 è per lo più burocrazia che puoi evitare. Se non lo copre, comincia da subito ad annotare perché la funzionalità principale richiede il permesso, perché è proprio ciò che chiede la dichiarazione.
Per i contatti vale un discorso simile. Molte app richiedono l'accesso completo ai contatti per una sola schermata «invita un amico». Il Contact Picker gestisce questo caso, e passarci prima di gennaio elimina un permesso di cui gli utenti comunque diffidano. Dal lato della sicurezza è anche una buona notizia. Nei nostri penetration test, i permessi eccessivamente ampi sono un riscontro ricorrente: dati di cui l'app non ha mai avuto bisogno, in una cache locale, a disposizione di chiunque ottenga un punto d'appoggio sul dispositivo. Meno accesso significa meno cose da far trapelare.
La regola sul pulsante di posizione si applica solo quando passi al target Android 17, ma se hai un store locator o un campo «usa la mia posizione» nel checkout, pianifica subito la modifica dell'interfaccia. Un pulsante a un solo tocco è un flusso diverso da una finestra di dialogo per il permesso a runtime, e i designer vorranno dire la loro.
Non trascurare le regole su abbonamenti e AppFunctions
La regola sull'informativa degli abbonamenti è facile da perdere perché riguarda il prodotto e gli aspetti legali, non il codice. Se offri un piano per studenti o un altro piano basato sull'idoneità, qualcuno deve mettere per iscritto il processo di verifica e il prezzo successivo alla perdita dell'idoneità direttamente sulla paywall. Nei lavori web e backend che facciamo per i clienti enterprise, un requisito di questo tipo di solito comporta una modifica sia ai testi dell'app sia al server che decide chi è ancora idoneo, quindi coinvolgi presto il team backend.
Le AppFunctions sono un terreno più nuovo. La policy è breve: non ingannare gli agenti di IA, non aggirare i loro controlli di sicurezza, non interferire con altre app. Se esponi azioni dell'app agli agenti, rivedile come faresti con un'API pubblica. Controlla cosa può fare ogni funzione senza conferma dell'utente e dai per scontato che qualcosa la chiamerà con input che non avevi previsto.
Cosa fare questa settimana
- Controlla oggi il tuo target API level. Se è inferiore a 36, l'aggiornamento ora blocca ogni rilascio. Crea un branch, alza la versione, esegui l'intera suite di test su un dispositivo Android 16 e aggiorna le librerie che si rompono.
- Fai un audit del manifest. Elenca ogni uso di
READ_CONTACTS,MANAGE_CONTACTS,ACCESS_FINE_LOCATIONeACCESS_LOCAL_NETWORK, e accanto a ciascuno scrivi se un selettore o un pulsante potrebbe sostituirlo. - Metti le date del 2027 in un calendario condiviso, con un responsabile per ciascuna, non solo un promemoria su Slack.
- Assegna qualcuno alla casella della Play Console. La maggior parte dei problemi che vediamo inizia con un avviso che nessuno ha letto.
Se vuoi vedere come abbiamo gestito in passato migrazioni di piattaforma come questa, il nostro portfolio ha alcuni esempi, e il nostro lavoro di sviluppo copre sia Android nativo sia i backend che lo supportano.
Se un targetSdkVersion bloccato o un audit dei permessi che continui a rimandare ti suonano familiari, parliamone.