Questa pagina è stata tradotta dall'API Cloud Translation.

Soddisfa il requisito relativo ai livelli API target di Google Play

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

A partire dal 31 agosto 2024:

Le nuove app e gli aggiornamenti delle app devono avere come target Android 14 (livello API 34) o versioni successive per essere inviati a Google Play; ad eccezione delle app per Wear OS e Android TV, che devono avere come target Android 13 (livello API 33) o versioni successive.
Le app esistenti devono avere come target Android 13 (livello API 33) 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 destinate ad Android 12 (livello API 31) o versioni precedenti (Android 10 (livello API 29) o versioni precedenti per Wear OS e Android 11 (livello API 30) o versioni precedenti per Android TV) saranno disponibili soltanto sui dispositivi con sistema operativo Android uguale 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 2024. Potrai accedere ai moduli di estensione dell'app in Play Console entro la fine dell'anno.

Le eccezioni a questi requisiti includono:

App sempre private riservate agli utenti di un'organizzazione specifica e destinate esclusivamente alla distribuzione interna.
App che hanno come target Android Automotive OS o che sono pacchettizzate da APK che hanno come target il sistema operativo Android Automotive.

Perché scegliere come target SDK più recenti?

Ogni nuova versione di Android introduce modifiche che apportano miglioramenti della sicurezza e delle 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 trarre vantaggio da questi miglioramenti, mentre la tua app può continuare a essere eseguita su versioni precedenti di Android. Inoltre, scegliere come target un livello API recente consente alla tua app di sfruttare le ultime funzionalità della piattaforma per soddisfare gli 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 che devi conoscere per aggiornare il tuo livello API target per soddisfare il requisito di Google Play. Consulta le istruzioni nelle sezioni seguenti, a seconda della versione a cui stai eseguendo la migrazione.

Eseguire 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 del comportamento pertinenti:

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

Sicurezza e autorizzazioni

Bluetooth: devi sostituire le dichiarazioni relative alle autorizzazioni BLUETOOTH e BLUETOOTH_ADMIN con le autorizzazioni BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE o BLUETOOTH_CONNECT. Non devi più effettuare richieste di autorizzazione di runtime di LOCATION per le operazioni Bluetooth.
Posizione: gli utenti possono chiedere 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 l'app contiene attività, servizi o ricevitori di broadcast che utilizzano filtri di intent, devi dichiarare esplicitamente l'attributo android:exported per questi componenti.
Letargo: le app possono 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 dell'app.
Mutabilità dell'intent in sospeso: devi specificare la mutabilità di ogni oggetto PendingIntent creato dalla tua app.

Esperienza utente

Notifiche personalizzate: le notifiche con visualizzazioni dei contenuti personalizzate non utilizzeranno più l'area di notifica completa; il sistema applica invece un modello standard. Questo modello garantisce che le notifiche personalizzate abbiano lo stesso livello di decorazione delle altre notifiche in tutti gli stati. Questo comportamento è quasi identico a quello di Notification.DecoratedCustomViewStyle.
Modifiche alla verifica tramite Android App Link: quando utilizzi la verifica tramite Android App Link, assicurati che i filtri per intent includano la categoria BROWSABLE e supportino lo schema HTTPS.

Prestazioni

Limitazioni relative al lancio di 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 nei pochi casi speciali).

Potresti usare WorkManager per pianificare e avviare il lavoro accelerato mentre l'app viene eseguita in background. Per completare le azioni urgenti richieste dall'utente, avvia i servizi in primo piano entro una sveglia esatta.
Restrizioni relative al trampolino per le notifiche: quando gli utenti toccano le notifiche, alcune app rispondono avviando un componente dell'app che avvia l'attività che l'utente vede e con cui interagisce. Questo componente dell'app è noto come trampolino per le notifiche.

Le app non devono avviare attività da servizi o broadcast receiver usati come trampolini 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 broadcast receiver.

Visualizza l'insieme completo di modifiche che interessano le app destinate ad Android 12 (livello API 31).

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

Seleziona la versione di Android da cui eseguire la migrazione:

Eseguire la migrazione ad Android 5 (livello API 21)

Consulta la pagina Modifiche di comportamento relativa a ciascuna delle seguenti release per assicurarti che la tua app abbia preso in considerazione le modifiche introdotte in queste release:

Continua seguendo le istruzioni nella sezione successiva.

Eseguire la migrazione ad Android 6 (livello API 23)

Le seguenti considerazioni si applicano alle app destinate ad Android 6.0 e versioni successive della piattaforma:

Autorizzazioni di runtime
- Le autorizzazioni pericolose vengono concesse solo in fase di runtime. I flussi di UI devono fornire le autorizzazioni per concedere queste autorizzazioni.
- Se 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 l'app abbia un altro modo per procedere.

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

Continua seguendo le istruzioni nella sezione successiva.

Eseguire la migrazione ad Android 7 (livello API 24)

Le seguenti considerazioni si applicano alle app destinate ad Android 7.0 e versioni successive della piattaforma:

Sospensione e standby delle app

Progetta i comportamenti descritti in Ottimizzare per sospensione e standby delle app, che include le modifiche incrementali introdotte in diverse release della piattaforma.

Quando un dispositivo è in modalità Sospensione e standby delle app, il sistema si comporta come segue:
- Limita l'accesso alla rete
- Rimanda sveglie, sincronizzazioni e job
- Limita le ricerche con GPS e Wi-Fi
- Limita i messaggi Firebase Cloud Messaging a priorità normale.
Modifiche alle autorizzazioni
- Il sistema limita l'accesso alle directory private delle app.
- L'esposizione di un URI file:// all'esterno dell'app attiva un FileUriExposedException. Se devi condividere file all'esterno dell'app, implementa FileProvider
Il sistema non consente il collegamento a librerie non NDK.

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

Continua seguendo le istruzioni nella sezione successiva.

Eseguire la migrazione ad Android 8 (livello API 26)

Le seguenti considerazioni si applicano alle app destinate ad 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 richiamarla mentre startService() è vietato.
  - Per avviare i servizi in primo piano, un'app deve usare startForeground() e startForegroundService().
  - Esamina attentamente le modifiche apportate all'API JobScheduler, come documentato nella pagina Modifiche del comportamento di Android 8.0 (livello API 26).
  - Firebase Cloud Messaging richiede la versione 10.2.1 o successive dell' SDK Google Play Services.
  - Quando si utilizza Firebase Cloud Messaging, la consegna dei messaggi è soggetta 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, la tua app deve pianificare i job utilizzando Firebase Job Dispatcher o JobIntentService. Per ulteriori informazioni, 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 per la posizione in background
  - Le app in esecuzione in background hanno accesso limitato ai dati sulla posizione.
    - Sui dispositivi con Google Play Services, utilizza il fornitore di servizi di geolocalizzazione integrato per ricevere aggiornamenti periodici sulla posizione.
Canali di notifica
- Dovresti definire le proprietà di interruzione delle notifiche in base al canale.
- Affinché le notifiche vengano visualizzate, devi assegnare le notifiche a un canale.
- Questa versione della piattaforma supporta NotificationCompat.Builder.
Privacy
- L'ambito di ANDROID_ID è basato sulla chiave di firma dell'app.

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

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

Gestione alimentazione
- I bucket Standby delle app apportano nuove restrizioni in background in base al coinvolgimento delle app, come job differiti, allarmi e quote sui messaggi ad alta priorità
- I miglioramenti al risparmio energetico aumentano i limiti delle app in standby delle app
Autorizzazione per i servizi in primo piano
- È necessario richiedere l'autorizzazione normale FOREGROUND_SERVICE (non l'autorizzazione di runtime)
Modifiche relative alla privacy
- Accesso limitato ai sensori in background
- Accesso limitato ai registri 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 completo delle modifiche introdotte in Android 9.0 (livello API 28), consulta le modifiche al comportamento.

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

Notifiche con intent a schermo intero
- Devi richiedere l'autorizzazione normale USE_FULL_SCREEN_INTENT (non l'autorizzazione di runtime).
Supporto di dispositivi pieghevoli e con schermi di grandi dimensioni
- Ora più attività possono essere nello stato "ripristinato" contemporaneamente, ma in realtà solo una è attiva.
  - Questa modifica influisce sul comportamento di onResume() e onPause().
  - Nuovo concetto di ciclo di vita di "ripreso in alto", che può essere rilevato abbonandoti a onTopResumedActivityChanged().
    - È possibile "ripresa più in alto" una sola attività.
- Se l'opzione resizeableActivity è impostata su false, le app possono specificare anche una minAspectRatio che applica automaticamente un letterbox all'app con proporzioni più strette.
Modifiche relative 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 creati dall'app.
- Accesso limitato alla posizione mentre l'app è in background, che richiede l'autorizzazione ACCESS_BACKGROUND_LOCATION.
- Accesso limitato agli identificatori non reimpostabili come IMEI e numero di serie.
- Accesso limitato alle informazioni sull'attività fisica, come il numero di passi dell'utente, che richiede l'autorizzazione ACTIVITY_RECOGNITION.
- Accesso limitato ad alcune API di 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 riquadri delle impostazioni.
  - Limitazioni relative all'avvio di una connessione a una rete Wi-Fi che richiedono l'utilizzo di WifiNetworkSpecifier o WifiNetworkSuggestion.

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

Privacy
- Applicazione dell'archiviazione con ambito : le app devono adottare il modello di archiviazione con ambito in cui vengono salvati e consultati tipi di file specifici delle app, multimediali e di altro tipo utilizzando posizioni dedicate.
- Reimpostazione automatica delle autorizzazioni: se gli utenti non hanno interagito con un'app per alcuni mesi, il sistema reimposta automaticamente le autorizzazioni sensibili dell'app. Questo non dovrebbe influire sulla maggior parte delle app. Se l'app funziona principalmente in background senza interazioni dell'utente, puoi richiedere agli utenti di disattivare la reimpostazione automatica.
- 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'accesso all'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 trovare l'elenco di app e servizi installati sul dispositivo, l'elenco restituito viene filtrato.
  - Se utilizzi i servizi di sintesi vocale o di riconoscimento vocale, dovrai aggiungere al file manifest elementi di query per i servizi.
Sicurezza
- I file "resource.arsc" compressi non sono più supportati
- Ora è richiesto lo schema di firma dell'APK v2. Per motivi di compatibilità con le versioni precedenti, gli sviluppatori devono anche continuare a firmare 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, poiché alcune di queste interfacce non SDK sono ora bloccate. Consulta Interfacce non SDK che ora sono bloccate in Android 11 per un elenco completo delle interfacce non SDK bloccate.

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

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

Modernizza le app

Quando aggiorni il livello API target delle tue app, valuta la possibilità di adottare funzionalità della piattaforma recenti per modernizzare le tue app e soddisfare le esigenze dei tuoi utenti.

Prendi in considerazione l'utilizzo di CameraX, in versione beta, per sfruttare al meglio la fotocamera.
Utilizza i componenti di Jetpack per seguire le best practice, liberarti dalla scrittura di 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 in materia di privacy.
Aggiungi il supporto del tema scuro alle tue app.
Aggiungi il supporto della navigazione tramite gesti alle tue app.
Esegui la migrazione dell'app da Google Cloud Messaging (GCM) alla versione più recente di Firebase Cloud Messaging.
Sfrutta la gestione avanzata delle finestre.
- Supporta proporzioni più grandi (più di 16:9) per sfruttare i recenti progressi dell'hardware. Assicurati che l'app venga ridimensionata per riempire lo spazio disponibile sullo schermo. Dichiara le proporzioni massime solo come ultima risorsa. Per maggiori informazioni sulle proporzioni massime, consulta la pagina Dichiarare il supporto per lo schermo limitato.
- Aggiungi il supporto multi-finestra per consentire alla tua app di aumentare la produttività e per gestire più display.
- Se un'esperienza con l'app ridotta a icona ottimale migliorerebbe l'esperienza utente, aggiungi il supporto per Picture in picture.
  - Ottimizza per i dispositivi con ritaglio display.
  - Non considerare l'altezza della barra di stato. Usa invece WindowInsets e View.OnApplyWindowInsetsListener. Per ulteriori informazioni, guarda il video droidcon NYC 2017 per la 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, usa 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 file manifest, mentre altri richiedono ulteriori indagini. Se utilizzi un SDK che non supporta l'API 31, assegna la priorità alla collaborazione con il provider di SDK per risolvere il problema.

Inoltre, tieni presente che l'elemento targetSdkVersion dell'app o del gioco potrebbe limitare l'accesso alle librerie private della piattaforma Android; per maggiori dettagli, consulta la pagina relativa al collegamento delle app NDK alle librerie della piattaforma.

Dovresti anche verificare eventuali limitazioni esistenti nella versione della Libreria di supporto Android in uso. Come sempre, devi garantire la compatibilità tra la versione principale di Android Support Library e compileSdkVersion dell'app.

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

Testare l'app

Dopo aver aggiornato il livello API e le funzionalità dell'app in base alle tue esigenze, devi testare alcuni casi d'uso principali. I seguenti suggerimenti non sono esaustivi, ma hanno lo scopo di guidare il processo di test. Ti consigliamo di eseguire un test:

Che la tua app venga compilata nell'API 29 senza errori o avvisi.
Che la tua app abbia una strategia per i casi in cui l'utente rifiuta le richieste di autorizzazione e chiede all'utente di concedergli le autorizzazioni. Per farlo:
- Vai alla schermata Informazioni app dell'app e disattiva ogni autorizzazione.
- Apri l'app e assicurati che non ci siano arresti anomali.
  - Esegui test dei casi d'uso principali e assicurati che vengano richieste nuovamente le autorizzazioni richieste.
Gestisce la funzionalità Sospensione con risultati previsti e nessun errore.
- Utilizzando ADB, posiziona il dispositivo di test in Sospensione mentre l'app è in esecuzione.
  - Testa tutti i casi d'uso che attivano i messaggi di Firebase Cloud Messaging.
  - Testa tutti i casi d'uso che utilizzano allarmi o job.
  - Elimina qualsiasi dipendenza dai servizi in background.
- Impostare l'app in Standby delle app
  - Testa tutti i casi d'uso che attivano i messaggi di Firebase Cloud Messaging.
  - Testa tutti i casi d'uso che utilizzano le sveglie.
Gestisce le nuove foto o i nuovi video realizzati
- Verifica che l'app gestisca le trasmissioni ACTION_NEW_PICTURE e ACTION_NEW_VIDEO limitate (ovvero sia spostato 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 con un'altra app dello stesso sviluppatore)
- Verifica che i contenuti siano visibili nell'altra app e non attivano arresti anomali.

Ulteriori informazioni

Attiva le 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.