Quando carichi un APK, questo deve soddisfare i requisiti relativi ai livelli API target di Google Play.
A partire dal 31 agosto 2023:
Le nuove app devono avere come target Android 13 (livello API 33) o versioni successive, ad eccezione delle app Wear OS, che devono avere come target una versione compresa tra Android 11 (livello API 30) e Android 13 (livello API 33).
Gli aggiornamenti delle app devono avere come target Android 13 o versioni successive e adattarsi ai cambiamenti di comportamento in Android 13; ad eccezione delle app per Wear OS, che devono avere come target Android 11.
Le app sempre private, limitate agli utenti di un'organizzazione specifica e destinate esclusivamente alla distribuzione interna, non devono soddisfare i requisiti dei livelli API target.
Nota: a partire dal 2022, alcune app obsolete non saranno disponibili per i nuovi utenti di dispositivi che eseguono versioni più recenti di Android.
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. 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ò ancora essere eseguita su versioni precedenti di Android. Scegliere come target un livello API recente consente inoltre 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 visualizzano un avviso quando avviano un'app per la prima volta se 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 al fine di soddisfare il requisito di Google Play.
Quando esegui la migrazione da versioni precedenti, consulta l'elenco completo delle modifiche di seguito.
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>.
Eseguire la migrazione da Android 12 (livello API 31) ad Android 13 (livello API 33)
Per aggiornare l'app in modo che abbia come target Android 13, segui l'elenco delle modifiche del comportamento.
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 è più necessario effettuare
LOCATION
richieste di autorizzazione di runtime per le operazioni Bluetooth. - Posizione: gli utenti possono richiedere alle app di recuperare soltanto 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 trasmissione che utilizzano filtri di intent, devi dichiarare esplicitamente l'attributo android:exported per questi componenti.
- Ibernazione: le app possono essere impostate in modalità di ibernazione se non vengono utilizzate per un determinato 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à dell'intent in attesa: devi specificare la mutabilità di ogni oggetto PendingIntent creato dall'app.
Esperienza utente
- Notifiche personalizzate:
le notifiche con visualizzazioni di contenuti personalizzate non utilizzeranno più l'area di notifica completa;
il sistema applica 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 tramite link per app Android, assicurati che i filtri per intent includano la categoria BROWSABLE e supportino lo schema HTTPS.
Prestazioni
Limitazioni per il lancio dei servizi in primo piano: per avere come target Android 12 o versioni successive, la tua app non può avviare i servizi in primo piano mentre è in esecuzione in background, tranne in 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 casi speciali).
Valuta la possibilità di utilizzare WorkManager per pianificare e iniziare il lavoro accelerato mentre l'app viene eseguita in background. Per completare le azioni sensibili al tempo richieste dall'utente, avvia i servizi in primo piano all'interno di una sveglia esatta.
Limitazioni del trampolino di notifica: 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 di notifica.
Le app non devono avviare attività da servizi o ricevitori di trasmissioni utilizzati come trampolini di notifica. Dopo che un utente ha toccato un pulsante di notifica o di azione all'interno della notifica, l'app non può chiamare
startActivity()
all'interno di un servizio o di un ricevitore di trasmissione.
Visualizza l'insieme completo delle modifiche che interessano le app destinate ad Android 12 (livello API 31).
Migrazione da versioni precedenti ad Android 11 (livello API 30)
Seleziona la versione di Android da cui eseguire la migrazione:
Esegui la migrazione ad Android 5 (livello API 21)
Consulta la rispettiva pagina Modifiche del comportamento per ciascuna delle seguenti release per assicurarti che la tua app sia stata responsabile delle modifiche introdotte in queste release:
Continua seguendo le istruzioni nella sezione successiva.
Esegui 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:
-
-
Le autorizzazioni pericolose vengono concesse solo in fase di runtime. I flussi dell'interfaccia utente devono fornire le offerte per concedere queste autorizzazioni.
-
Dove 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 relativa alla versione della piattaforma in questione.
Continua seguendo le istruzioni nella sezione successiva.
Esegui 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 in base ai comportamenti descritti nell'articolo Ottimizzazione 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 lavori
- Limita le ricerche GPS e di reti 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://
al di fuori della tua app attiva unFileUriExposedException
. Se devi condividere file all'esterno della tua app, implementaFileProvider
-
Il sistema vieta 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 relativa alla versione della piattaforma in questione.
Continua seguendo le istruzioni nella sezione successiva.
Esegui 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 che non sono in esecuzione in primo piano.
-
startService()
ora genera un'eccezione quando un'app tenta di richiamarla mentrestartService()
è vietato. -
Per avviare i servizi in primo piano, un'app deve utilizzare
startForeground()
estartForegroundService()
. - Esamina attentamente le modifiche apportate all'API JobScheduler, come documentato nella pagina Modifiche del comportamento per Android 8.0 (livello API 26).
- Firebase Cloud Messaging richiede la versione 10.2.1 dell' SDK di Google Play Services o versioni successive.
- Quando utilizzi Firebase Cloud Messaging, la consegna dei messaggi è soggetta a limiti di esecuzione in background. Quando è necessario un lavoro in background alla ricezione del messaggio, ad esempio per eseguire la sincronizzazione dei dati in background, la tua app dovrebbe pianificare i job tramite 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
.
-
Le trasmissioni implicite sono limitate. Per informazioni sulla gestione degli eventi in background, consulta la documentazione dell'API
-
Limiti delle località in background
-
Le app eseguite in background hanno accesso limitato ai dati sulla posizione.
- Sui dispositivi con Google Play Services, utilizza il fuso orario del fornitore di servizi di geolocalizzazione per ricevere aggiornamenti periodici sulla posizione.
-
Le app eseguite in background hanno accesso limitato ai dati sulla posizione.
-
Il sistema limita i servizi per le app che non sono in esecuzione in primo piano.
-
Canali di notifica
- Devi 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 dipende dalla 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 relativa alla versione della piattaforma in questione.
Migrazione da Android 8 (API 26) ad Android 9 (API 28)
-
Gestione dell'alimentazione
- I bucket App Standby introducono nuove limitazioni in background basate sul coinvolgimento in app, come job differiti, allarmi e quote sui messaggi ad alta priorità
- Miglioramenti del risparmio energetico aumentano le limitazioni per le app in standby delle app
-
Autorizzazione per i servizi in primo piano
- È necessario richiedere l'autorizzazione normale
FOREGROUND_SERVICE
(non l'autorizzazione di runtime)
- È necessario richiedere l'autorizzazione normale
-
Modifiche relative alla privacy
- Accesso limitato ai sensori in background
- Accesso limitato ai log chiamate, ora nel gruppo di autorizzazioni
CALL_LOG
- Accesso limitato ai numeri di telefono, richiesta
dell'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 del comportamento.
Migrazione da Android 9 (livello API 28) ad Android 10 (livello API 29)
-
Notifiche con intent a schermo intero
-
È necessario richiedere l'autorizzazione normale
USE_FULL_SCREEN_INTENT
(non l'autorizzazione di runtime).
-
È necessario richiedere l'autorizzazione normale
-
Supporto per dispositivi pieghevoli e con schermi di grandi dimensioni
-
Ora più attività possono trovarsi nello stato "ripresa" contemporaneamente, ma solo una è effettivamente in stato attivo.
-
Questa modifica influisce sul comportamento di
onResume()
eonPause()
. -
Nuovo concetto di ciclo di vita di "più alto ripreso", che può essere rilevato
sottoscrivendo un abbonamento a
onTopResumedActivityChanged()
.- Solo un'attività può essere "ripresa più in alto".
-
Questa modifica influisce sul comportamento di
-
Quando l'opzione
resizeableActivity
è impostata sufalse
, le app possono specificare anche un valoreminAspectRatio
che applica automaticamente l'attributo letterbox all'app in proporzioni più strette.
-
Ora più attività possono trovarsi nello stato "ripresa" contemporaneamente, ma solo una è effettivamente in stato attivo.
-
Modifiche relative alla privacy
-
Archiviazione mirata
- L'accesso allo spazio di archiviazione esterno è limitato solo a una directory specifica dell'app e a tipi di contenuti multimediali specifici creati dall'app.
-
Accesso limitato alla posizione mentre l'app è in background,
richiesta dell'autorizzazione
ACCESS_BACKGROUND_LOCATION
. - Accesso limitato agli identificatori non reimpostabili, come il codice IMEI e il 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 richiede l'autorizzazione
ACCESS_FINE_LOCATION
. -
Accesso limitato alle impostazioni Wi-Fi
- Le app non possono più abilitare o disabilitare direttamente il Wi-Fi e devono farlo utilizzando i pannelli delle impostazioni.
-
Limitazioni relative all'avvio di una connessione a una rete Wi-Fi,
che richiede l'utilizzo di
WifiNetworkSpecifier
oWifiNetworkSuggestion
.
-
Archiviazione mirata
Migrazione da Android 10 (livello API 29) ad Android 11 (livello API 30)
-
Privacy
- Applicazione forzata dell'archiviazione mirata : le app devono adottare il modello di archiviazione con ambito, in cui i tipi di file specifici delle app, dei contenuti multimediali e di altro tipo vengono salvati e sono accessibili tramite 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 la tua app funziona principalmente in background senza interazioni da parte degli utenti, ti consigliamo di 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 delle app e dei servizi installati sul dispositivo, l'elenco restituito viene filtrato.
- Se utilizzi i servizi di Sintesi vocale o di riconoscimento vocale, dovrai aggiungere elementi di query per i servizi al file manifest.
-
Sicurezza
- I file "resource.arsc" compressi non sono più supportati
- Lo schema di firma dell'APK v2 è ora obbligatorio. Per motivi di compatibilità con le versioni precedenti, gli sviluppatori devono anche continuare a firmare con la versione 1 dello schema di firma dell'APK.
- Restrizione 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 ora sono bloccate. Per un elenco completo delle interfacce non SDK bloccate, consulta Interfacce non SDK che ora sono bloccate in Android 11.
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.
Modernizzare le app
Quando aggiorni il livello API target delle tue app, valuta la possibilità di adottare funzionalità recenti della piattaforma per modernizzare le app e soddisfare gli utenti.
- Valuta la possibilità di utilizzare FotocameraX, in versione beta, per sfruttare al meglio la fotocamera.
- Utilizza i componenti Jetpack per seguire le best practice, liberarti dalla scrittura di codice boilerplate e semplificare le attività complesse in modo da poter concentrarti sul codice che ti interessa.
- Usa 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) alla versione più recente di Firebase Cloud Messaggiging.
- Sfrutta la gestione avanzata delle finestre.
- Supporta proporzioni più grandi (più di 16:9) per sfruttare i recenti miglioramenti dell'hardware. Assicurati che l'app venga ridimensionata in modo da riempire lo spazio disponibile sullo schermo. Dichiara le proporzioni massime come ultima risorsa. Per ulteriori informazioni sulle proporzioni massime, consulta la pagina Dichiarare il supporto dello schermo limitato.
- Aggiungi il supporto di più finestre per aiutare la tua app ad aumentare la produttività e per gestire più display.
- Se un'esperienza dell'app ridotta al minimo migliora l'esperienza utente, aggiungi il supporto per la funzionalità Picture in picture.
- Ottimizza per i dispositivi con ritaglio del display.
- Non assumere l'altezza della barra di stato. Usa invece
WindowInsets
eView.OnApplyWindowInsetsListener
. Guarda questo video per una spiegazione. - Non dare per scontato che l'app abbia l'intera finestra. Conferma invece la posizione utilizzando
View.getLocationInWindow()
, nonView.getLocationOnScreen()
. - Quando gestisci
MotionEvent
, utilizzaMotionEvent.getX()
eMotionEvent.getY()
, nonMotionEvent.getRawX()
,MotionEvent.getRawY()
.
Controlla e aggiorna 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 proprio file manifest; altri richiederanno un'analisi aggiuntiva. 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'targetSdkVersion
della tua app o del tuo gioco potrebbe limitare l'accesso alle librerie private della piattaforma Android. Per maggiori dettagli, consulta la sezione Collegamento delle app NDK alle librerie di piattaforme.
Dovresti inoltre verificare eventuali restrizioni
che potrebbero esistere nella versione di Android Support Library che stai utilizzando.
Come sempre, devi garantire la compatibilità tra la versione principale
di Android Support Library e compileSdkVersion
della tua app.
Ti consigliamo di scegliere un valore targetSdkVersion
inferiore o uguale alla versione principale della libreria di supporto. Ti invitiamo a eseguire l'aggiornamento a una libreria di assistenza compatibile recente per sfruttare le ultime 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 testare:
- Che l'app venga compilata nell'API 29 senza errori o avvisi.
- Che l'app abbia una strategia per i casi in cui l'utente rifiuta le richieste di autorizzazione e chiede all'utente 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 i test dei casi d'uso principali e assicurati che vengano richieste nuovamente le autorizzazioni richieste.
- Gestisce la sospensione con risultati previsti e nessun errore.
- Utilizzando adb, posiziona il dispositivo di test in modalità Sospensione mentre l'app è in esecuzione.
- Testa i casi d'uso che attivano i messaggi di Firebase Cloud Messaging.
- Testa i casi d'uso che utilizzano Sveglie o Offerte di lavoro.
- Elimina le eventuali dipendenze dai servizi in background.
- Imposta la tua app in standby delle app
- Testa i casi d'uso che attivano i messaggi di Firebase Cloud Messaging.
- Testa i casi d'uso che usano le sveglie.
- Utilizzando adb, posiziona il dispositivo di test in modalità Sospensione mentre l'app è in esecuzione.
- Gestisce le nuove foto e / o i nuovi video acquisiti.
- Verifica che la tua app
gestisca le trasmissioni con restrizioni
ACTION_NEW_PICTURE
eACTION_NEW_VIDEO
correttamente (ovvero, le trasmissioni siano spostate nei job JobScheduler). - Assicurati che tutti i casi d'uso critici che dipendono da questi eventi continuino a funzionare.
- Verifica che la tua app
gestisca le trasmissioni con restrizioni
- Gestisce la condivisione di file con altre app
- Testa qualsiasi caso d'uso che condivide dati dei file con qualsiasi altra app (anche un'altra app dello stesso sviluppatore)
- Testa che i contenuti siano visibili nell'altra app e non provochi arresti anomali.
Ulteriori informazioni
Attiva la ricezione delle email in Google Play Console per consentirci di inviarti annunci e aggiornamenti importanti da Android e Google Play, inclusa la nostra newsletter mensile per i partner.