Soddisfa il requisito relativo ai livelli API target di Google Play

Quando carichi un APK, questo deve soddisfare i requisiti relativi al livello API target di Google Play.

A partire dal 31 agosto 2025:

• Le nuove app e gli aggiornamenti delle app devono avere come target Android 15 (livello API 35) o versioni successive per essere inviati a Google Play, ad eccezione delle app per Wear OS, Android Automotive OS e Android TV, che devono avere come target Android 14 (livello API 34) o versioni successive.
• Le app esistenti devono avere come target Android 14 (livello API 34) o versioni successive per rimanere disponibili per i nuovi utenti su dispositivi con sistema operativo Android superiore al livello API target della tua app. Le app che hanno come target Android 13 (livello API 33) o versioni precedenti, incluso Android 12 (livello API 31) o versioni precedenti per Wear OS e Android TV, saranno disponibili solo sui dispositivi con sistema operativo Android pari o precedente al livello API target della tua app.

Se hai bisogno di più tempo per aggiornare l'app, potrai richiedere un'estensione fino al 1° novembre 2025. Entro la fine dell'anno, potrai accedere ai moduli di estensione per la tua app in Play Console.

Le eccezioni a questi requisiti includono:

• App sempre private riservate agli utenti di un'organizzazione specifica e destinate esclusivamente alla distribuzione interna.

Nota: le app obsolete non sono disponibili per i nuovi utenti di dispositivi che eseguono versioni più recenti di Android. Per maggiori informazioni, consulta la sezione "Requisiti di disponibilità dell'app" dell'articolo Requisiti relativi al livello API target per le app Google Play nel Centro assistenza Play Console.

Perché scegliere come target SDK più recenti?

Ogni nuova versione di Android introduce modifiche che apportano miglioramenti alla sicurezza e alle prestazioni e migliorano l'esperienza utente di Android. Alcune di queste modifiche si applicano solo alle app che dichiarano esplicitamente il supporto tramite l'attributo manifest targetSdkVersion (noto anche come livello API target).

Se configuri la tua app in modo che abbia come target un livello API recente, ti assicuri che gli utenti possano beneficiare di questi miglioramenti, mentre la tua app può comunque essere eseguita su versioni precedenti di Android. Se scegli come target un livello API recente, la tua app può anche sfruttare le funzionalità più recenti della piattaforma per deliziare i tuoi utenti. Inoltre, a partire da Android 10 (livello API 29), gli utenti vedono un avviso quando avviano un'app per la prima volta se l'app ha come target Android 5.1 (livello API 22) o versioni precedenti.

Questo documento evidenzia i punti importanti da conoscere per aggiornare il livello API target in modo da soddisfare il requisito di Google Play. Consulta le istruzioni nelle sezioni seguenti, a seconda della versione a cui stai eseguendo la migrazione.

Nota :se il file Gradle contiene voci manifest, puoi confermare o modificare il valore corrente di targetSdkVersion nel file Gradle dell'app, come descritto in Configurare la build. In alternativa, puoi utilizzare l'attributo android:targetSdkVersion nel file manifest, come descritto nella documentazione dell'elemento manifest <uses-sdk>.

Esegui la migrazione da Android 12 e versioni successive (livello API 31) a una versione più recente

Per aggiornare la tua app in modo che abbia come target una versione più recente di Android, segui l'elenco delle modifiche al comportamento pertinenti:

• Modifiche al comportamento di Android 13
• Modifiche al comportamento di Android 14
• Modifiche del comportamento di Android 15
• Modifiche al comportamento di Android 16

Eseguire la migrazione da Android 11 (livello API 30) ad Android 12 (livello API 31)

Sicurezza e autorizzazioni

• Bluetooth: devi sostituire le dichiarazioni per le autorizzazioni BLUETOOTH e BLUETOOTH_ADMIN con le autorizzazioni BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE o BLUETOOTH_CONNECT. Non devi più effettuare richieste di autorizzazione di runtime LOCATION per le operazioni Bluetooth.
• Posizione: gli utenti possono richiedere alle app di recuperare solo informazioni sulla posizione approssimativa. Devi richiedere l'autorizzazione ACCESS_COARSE_LOCATION ogni volta che richiedi ACCESS_FINE_LOCATION.
  • Filtri per intent: se la tua app contiene attività, servizi o broadcast receiver che utilizzano filtri per intent, devi dichiarare esplicitamente l'attributo android:exported per questi componenti.
• Ibernazione: le app potrebbero essere messe in modalità di ibernazione se non vengono utilizzate per un periodo di tempo. In modalità di ibernazione, le autorizzazioni di runtime e la cache dell'app vengono reimpostate e non puoi eseguire job o avvisi. Puoi controllare lo stato di ibernazione della tua app.
• Modificabilità di PendingIntent: devi specificare la modificabilità di ogni oggetto PendingIntent creato dalla tua app.

Esperienza utente

• Notifiche personalizzate: le notifiche con visualizzazioni di contenuti personalizzati non utilizzeranno più l'intera area di notifica. Il sistema applicherà invece un modello standard. Questo modello garantisce che le notifiche personalizzate abbiano la stessa decorazione delle altre notifiche in tutti gli stati. Questo comportamento è quasi identico a quello di Notification.DecoratedCustomViewStyle.
• Modifiche alla verifica dei link per app Android: quando utilizzi la verifica dei link per app Android, assicurati che i filtri per intent includano la categoria BROWSABLE e supportino lo schema HTTPS.

Prestazioni

• Limitazioni di avvio dei servizi in primo piano: per avere come target Android 12 o versioni successive, la tua app non può avviare servizi in primo piano mentre viene eseguita in background, ad eccezione di alcuni casi speciali. Se un'app tenta di avviare un servizio in primo piano mentre è in esecuzione in background, si verifica un'eccezione (tranne in alcuni casi speciali).

  Valuta la possibilità di utilizzare WorkManager per pianificare e avviare il lavoro rapido mentre la tua app viene eseguita in background. Per completare le azioni urgenti richieste dall'utente, avvia i servizi di primo piano all'interno di una sveglia esatta.

• Limitazioni del trampolino di notifiche: quando gli utenti toccano le notifiche, alcune app rispondono avviando un componente dell'app che inizia l'attività che l'utente vede e con cui interagisce. Questo componente dell'app è noto come trampolino di notifica.

  Le app non devono avviare attività da servizi o ricevitori di trasmissione utilizzati come trampolini di lancio per le notifiche. Dopo che un utente tocca una notifica o un pulsante di azione all'interno della notifica, la tua app non può chiamare startActivity() all'interno di un servizio o di un ricevitore di trasmissione.

Visualizza l'insieme completo di modifiche che interessano le app che hanno come target Android 12 (livello API 31).

Esegui la migrazione da versioni precedenti ad Android 11 (livello API 30)

Seleziona la versione di Android da cui verrà eseguita la migrazione:

Eseguire la migrazione ad Android 5 (livello API 21)

Consulta la pagina Modifiche del comportamento relativa a ciascuna delle seguenti release per assicurarti che la tua app tenga conto delle modifiche introdotte in queste release:

• Android 5.0 (livello API 21)
• Android 4.4 (livello API 19).
• Android 4.1.x (livello API 16).

Continua seguendo le istruzioni riportate nella sezione successiva.

Esegui la migrazione ad Android 6 (livello API 23)

Le seguenti considerazioni si applicano alle app che hanno come target Android 6.0 e versioni successive della piattaforma:

• Autorizzazioni di runtime

  • Le autorizzazioni pericolose vengono concesse solo in fase di runtime. I flussi dell'interfaccia utente devono fornire le funzionalità per concedere queste autorizzazioni.

  • Ove possibile, assicurati che la tua app sia pronta a gestire il rifiuto delle richieste di autorizzazione. Ad esempio, se un utente rifiuta una richiesta di accesso al GPS del dispositivo, assicurati che la tua app abbia un altro modo per procedere.

Per un elenco esaustivo delle modifiche introdotte in Android 6.0 (livello API 23), consulta la pagina Modifiche al comportamento per quella versione della piattaforma.

Continua seguendo le istruzioni riportate nella sezione successiva.

Eseguire la migrazione ad Android 7 (livello API 24)

Le seguenti considerazioni si applicano alle app che hanno come target Android 7.0 e versioni successive della piattaforma:

• Modalità Sospensione e Standby delle app

  Progetta in base ai comportamenti descritti in Ottimizzazione per sospensione e standby delle app, che comprende le modifiche incrementali introdotte in diverse release della piattaforma.

  Quando un dispositivo è in modalità Sospensione e standby delle app, il sistema si comporta nel seguente modo:

  • Limita l'accesso alla rete
  • Posticipa sveglie, sincronizzazioni e job
  • Limita le scansioni GPS e Wi-Fi
  • Limita i messaggi Firebase Cloud Messaging con priorità normale.

• Modifiche alle autorizzazioni

  • Il sistema limita l'accesso alle directory private delle app.
  • L'esposizione di un URI file:// al di fuori della tua app attiva un FileUriExposedException. Se devi condividere file all'esterno dell'app, implementa FileProvider

• Il sistema vieta il collegamento a librerie non NDK.

Per un elenco esaustivo delle modifiche introdotte in Android 7.0 (livello API 24), consulta la pagina Modifiche al comportamento per quella versione della piattaforma.

Continua seguendo le istruzioni riportate nella sezione successiva.

Eseguire la migrazione ad Android 8 (livello API 26)

Le seguenti considerazioni si applicano alle app che hanno come target Android 8.0 e versioni successive della piattaforma:

• Limiti di esecuzione in background
  • Il sistema limita i servizi per le app non in esecuzione in primo piano.
    • startService() ora genera un'eccezione quando un'app tenta di invocarlo mentre startService() è vietato.
    • Per avviare i servizi in primo piano, un'app deve utilizzare startForeground() e startForegroundService().
    • Esamina attentamente le modifiche apportate all'API JobScheduler, come documentato nella pagina Modifiche al comportamento di Android 8.0 (livello API 26).
    • Firebase Cloud Messaging richiede la versione 10.2.1 dell' SDK Google Play Services o versioni successive.
    • Quando utilizzi Firebase Cloud Messaging, il recapito dei messaggi è soggetto a limiti di esecuzione in background. Quando è necessario un lavoro in background al momento della ricezione del messaggio, ad esempio per eseguire la sincronizzazione dei dati in background, l'app deve pianificare i job utilizzando Firebase Job Dispatcher o JobIntentService. Per saperne di più, consulta la documentazione di Firebase Cloud Messaging.
  • Trasmissioni implicite
    • Le trasmissioni implicite sono limitate. Per informazioni sulla gestione degli eventi in background, consulta la documentazione dell'API JobScheduler.
  • Limiti della posizione in background
    • Le app in esecuzione in background hanno un accesso limitato ai dati sulla posizione.
      • Sui dispositivi con Google Play Services, utilizza il provider di geolocalizzazione combinata per ricevere aggiornamenti periodici della posizione.
• Canali di notifica
  • Devi definire le proprietà di interruzione delle notifiche per ogni canale.
  • Per visualizzare le notifiche, devi assegnarle a un canale.
  • Questa versione della piattaforma supporta NotificationCompat.Builder.
• Privacy
  • ANDROID_ID è limitato in base alla chiave di firma dell'app.

Per un elenco esaustivo delle modifiche introdotte in Android 8.0 (livello API 26), consulta la pagina Modifiche al comportamento per quella versione della piattaforma.

Esegui la migrazione da Android 8 (API 26) ad Android 9 (API 28)

• Gestione alimentazione
  • I bucket di standby delle app introducono nuove limitazioni in background in base al coinvolgimento delle app, come job differiti, sveglie e quote per i messaggi ad alta priorità
  • Miglioramenti del risparmio energetico aumentano le limitazioni per le app in standby
• Autorizzazione per il servizio in primo piano
  • Devi richiedere l'autorizzazione normale FOREGROUND_SERVICE (non l'autorizzazione runtime)
• Modifiche alla privacy
  • Accesso limitato ai sensori in background
  • Accesso limitato ai registri delle chiamate, ora nel gruppo di autorizzazioni CALL_LOG
  • Accesso limitato ai numeri di telefono, che richiede l'autorizzazione READ_CALL_LOG
  • Accesso limitato alle informazioni sul Wi-Fi

Per un elenco esaustivo delle modifiche introdotte in Android 9.0 (livello API 28), consulta Modifiche al comportamento.

Esegui la migrazione da Android 9 (livello API 28) ad Android 10 (livello API 29)

• Notifiche con un intent a schermo intero
  • Devi richiedere l'autorizzazione normale USE_FULL_SCREEN_INTENT (non l'autorizzazione di runtime).
• Supporto per pieghevoli e dispositivi con schermi di grandi dimensioni
  • Ora più attività possono essere nello stato "Ripresa" contemporaneamente, ma solo una è effettivamente attiva.
    • Questa modifica influisce sul comportamento di onResume() e onPause().
    • Nuovo concetto di ciclo di vita "in primo piano ripreso" rilevabile tramite l'iscrizione a onTopResumedActivityChanged().
      • Solo un'attività può essere "ripresa in primo piano".
  • Quando resizeableActivity è impostato su false, le app possono specificare anche un minAspectRatio che aggiunge automaticamente barre nere all'app con proporzioni più strette.
• Modifiche alla privacy
  • Archiviazione con ambito
    • L'accesso allo spazio di archiviazione esterno è limitato solo a una directory specifica dell'app e a tipi specifici di contenuti multimediali che l'app ha creato.
  • Accesso limitato alla posizione mentre l'app è in background, che richiede l'autorizzazione ACCESS_BACKGROUND_LOCATION.
  • Accesso limitato a identificatori non ripristinabili come IMEI e numero di serie.
  • Accesso limitato alle informazioni sull'attività fisica, ad esempio il numero di passi dell'utente, che richiede l'autorizzazione ACTIVITY_RECOGNITION.
  • Accesso limitato ad alcune API telefonia, Bluetooth e Wi-Fi, che richiedono l'autorizzazione ACCESS_FINE_LOCATION.
  • Accesso limitato alle impostazioni Wi-Fi
    • Le app non possono più attivare o disattivare direttamente il Wi-Fi e devono farlo utilizzando i pannelli delle impostazioni.
    • Limitazioni all'avvio di una connessione a una rete Wi-Fi, che richiedono l'utilizzo di WifiNetworkSpecifier o WifiNetworkSuggestion.

Esegui la migrazione da Android 10 (livello API 29) ad Android 11 (livello API 30)

• Privacy
  • Applicazione dell'archiviazione isolata : le app devono adottare il modello di archiviazione isolata in cui i tipi di file specifici dell'app, multimediali e di altro tipo vengono salvati e a cui si accede utilizzando posizioni dedicate.
  • Reimpostazione automatica delle autorizzazioni: se gli utenti non interagiscono con un'app per alcuni mesi, il sistema reimposta automaticamente le autorizzazioni sensibili dell'app. Questa modifica non dovrebbe influire sulla maggior parte delle app. Se la tua app funziona principalmente in background senza interazioni con l'utente, puoi valutare la possibilità di chiedere agli utenti di disattivare il ripristino automatico.
  • Accesso alla posizione in background: le app devono richiedere separatamente l'autorizzazione di accesso alla posizione in primo piano e in background. La concessione dell'autorizzazione di accesso alla posizione in background può essere eseguita solo nelle impostazioni dell'app anziché nelle finestre di dialogo delle autorizzazioni di runtime.
  • Visibilità dei pacchetti: quando un'app esegue una query per l'elenco di app e servizi installati sul dispositivo, l'elenco restituito viene filtrato.
    • Se utilizzi i servizi Text-to-Speech o Riconoscimento vocale, devi aggiungere elementi di query per i servizi al file manifest.
• Sicurezza
  • I file `resource.arsc` compressi non sono più supportati
  • Ora è obbligatorio lo schema di firma dell'APK v2. Per motivi di compatibilità con le versioni precedenti, gli sviluppatori devono continuare a firmare anche con lo schema di firma dell'APK v1.
  • Limitazione dell'interfaccia non SDK. L'utilizzo di interfacce non SDK non è consigliato per le app che hanno come target il livello API 30, in quanto alcune di queste interfacce non SDK sono ora bloccate. Consulta l'elenco completo delle interfacce non SDK bloccate in Android 11 nella sezione Interfacce non SDK ora bloccate in Android 11.

Per un elenco esaustivo delle modifiche introdotte in Android 11 (livello API 30), consulta la pagina Modifiche al comportamento.

Continua l'aggiornamento all'API 31 seguendo le istruzioni riportate nella sezione precedente.

Modernizzare le app

Quando aggiorni il livello API target delle tue app, valuta la possibilità di adottare le funzionalità della piattaforma più recenti per modernizzare le tue app e deliziare i tuoi utenti.

• Valuta la possibilità di utilizzare CameraX, in versione beta, per sfruttare al meglio la fotocamera.
• Utilizza i componenti Jetpack per seguire le best practice, evitare di scrivere codice boilerplate e semplificare le attività complesse, in modo da poterti concentrare sul codice che ti interessa.
• Utilizza Kotlin per scrivere app migliori più velocemente e con meno codice.
• Assicurati di rispettare i requisiti e le best practice relativi alla privacy.
• Aggiungi il supporto del tema scuro alle tue app.
• Aggiungi il supporto della navigazione tramite gesti alle tue app.
• Esegui la migrazione della tua app da Google Cloud Messaging (GCM) all'ultima versione di Firebase Cloud Messaging.
• Sfrutta la gestione avanzata delle finestre.
  • Supporta proporzioni più grandi (maggiori di 16:9) per sfruttare i recenti progressi nell'hardware. Assicurati che le dimensioni dell'app vengano modificate per riempire lo spazio disponibile sullo schermo. Dichiara un rapporto di aspetto massimo solo come ultima risorsa. Per ulteriori informazioni sulle proporzioni massime, consulta Dichiarare il supporto dello schermo con limitazioni.
  • Aggiungi il supporto multi-finestra per aiutare la tua app ad aumentare la produttività e per gestire più display.
  • Se un'ottima esperienza con l'app ridotta migliorerebbe l'esperienza utente, aggiungi il supporto per la funzionalità Picture in picture.
    • Ottimizza per i dispositivi con ritaglio del display.
    • Non dare per scontata l'altezza della barra di stato. Utilizza invece WindowInsets e View.OnApplyWindowInsetsListener. Per saperne di più, guarda il video di droidcon NYC 2017 per una spiegazione.
    • Non dare per scontato che l'app abbia l'intera finestra. Conferma invece la sua posizione utilizzando View.getLocationInWindow(), non View.getLocationOnScreen(). * Quando gestisci MotionEvent, utilizza MotionEvent.getX() e MotionEvent.getY(), non MotionEvent.getRawX(), MotionEvent.getRawY().

Controllare e aggiornare gli SDK e le librerie

Assicurati che le dipendenze dell'SDK di terze parti supportino l'API 31: alcuni provider di SDK la pubblicano nel manifest, altri richiedono ulteriori indagini. Se utilizzi un SDK che non supporta l'API 31, dai la priorità alla collaborazione con il fornitore dell'SDK per risolvere il problema.

Inoltre, tieni presente che il targetSdkVersion della tua app o del tuo gioco potrebbe limitare l'accesso alle librerie della piattaforma Android private. Per maggiori dettagli, vedi NDK Apps Linking to Platform Libraries.

Devi anche verificare eventuali limitazioni esistenti nella versione della libreria di supporto Android che stai utilizzando. Come sempre, devi assicurarti la compatibilità tra la versione principale della libreria di supporto Android e il compileSdkVersion della tua app.

Ti consigliamo di scegliere una targetSdkVersion inferiore o uguale alla versione principale della libreria di supporto. Ti consigliamo di eseguire l'aggiornamento a una versione recente compatibile della libreria di supporto per usufruire delle funzionalità di compatibilità e delle correzioni di bug più recenti.

Testare l'app

Dopo aver aggiornato il livello API e le funzionalità dell'app in modo appropriato, devi testare alcuni casi d'uso principali. I seguenti suggerimenti non sono esaustivi, ma mirano a guidare la procedura di test. Ti suggeriamo di testare:

• La tua app viene compilata con l'API 29 senza errori o avvisi.

• La tua app ha una strategia per i casi in cui l'utente rifiuta le richieste di autorizzazione e richiede le autorizzazioni all'utente. Per farlo:

  • Vai alla schermata Informazioni app dell'app e disattiva ogni autorizzazione.
  • Apri l'app e assicurati che non si arresti in modo anomalo.
    • Esegui test dei casi d'uso principali e assicurati che le autorizzazioni richieste vengano richieste nuovamente.

• Gestisce Doze con i risultati previsti e senza errori.

  • Utilizzando adb, metti il dispositivo di test in modalità Doze mentre l'app è in esecuzione.
    • Testa tutti i casi d'uso che attivano i messaggi Firebase Cloud Messaging.
    • Testa tutti i casi d'uso che utilizzano Sveglie o Lavori.
    • Elimina eventuali dipendenze dai servizi in background.
  • Imposta l'app in modalità Standby app
    • Testa tutti i casi d'uso che attivano i messaggi Firebase Cloud Messaging.
    • Testa tutti i casi d'uso che utilizzano Sveglie.

• Gestisce le nuove foto / i nuovi video acquisiti

  • Verifica che la tua app gestisca le trasmissioni con limitazioni ACTION_NEW_PICTURE e ACTION_NEW_VIDEO correttamente (ovvero spostate nei job JobScheduler).
  • Assicurati che tutti i casi d'uso critici che dipendono da questi eventi continuino a funzionare.

• Gestisce la condivisione di file con altre app - Testa qualsiasi caso d'uso che condivida i dati dei file con qualsiasi altra app (anche un'altra app dello stesso sviluppatore)

  • Verifica che i contenuti siano visibili nell'altra app e non causino arresti anomali.

Ulteriori informazioni

Attiva la ricezione di email in Google Play Console per consentirci di inviarti aggiornamenti e annunci importanti da Android e Google Play, inclusa la nostra newsletter mensile per i partner.