Come le versioni precedenti, Android 13 include modifiche al comportamento che potrebbero influire sulla tua app. Le seguenti modifiche al comportamento si applicano esclusivamente alle app che hanno come target Android 13 o versioni successive. Se la tua app ha come target Android 13 o versioni successive, devi modificarla per supportare correttamente questi comportamenti, ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche al comportamento che interessano tutte le app in esecuzione su Android 13.
Privacy
L'autorizzazione per le notifiche influisce sull'aspetto del servizio in primo piano
Se l'utente nega l'autorizzazione per le notifiche, non visualizzerà gli avvisi relativi ai servizi in primo piano nel riquadro delle notifiche. Tuttavia, gli utenti continuano a visualizzare le notifiche relative ai servizi in primo piano in Task Manager, indipendentemente dal fatto che l'autorizzazione per le notifiche sia concessa.
Nuova autorizzazione di runtime per i dispositivi Wi-Fi nelle vicinanze
Nelle versioni precedenti di Android, l'utente deve concedere alla tua app l'autorizzazione
ACCESS_FINE_LOCATION
per completare diversi casi d'uso comuni del Wi-Fi.
Poiché è difficile per gli utenti associare le autorizzazioni di accesso alla posizione alla funzionalità Wi-Fi, Android 13 (livello API 33) introduce un'autorizzazione di runtime nel gruppo di autorizzazioni NEARBY_DEVICES per le app che gestiscono le connessioni di un dispositivo ai punti di accesso nelle vicinanze tramite Wi-Fi. Questa autorizzazione,
NEARBY_WIFI_DEVICES,
soddisfa i casi d'uso del Wi-Fi, ad esempio:
- Trovare o connettersi a dispositivi nelle vicinanze, come stampanti o dispositivi di trasmissione multimediale.
Questo flusso di lavoro consente all'app di svolgere i seguenti tipi di attività:
- Ricevi informazioni sul punto di accesso fuori banda, ad esempio tramite BLE.
- Rileva e connettiti ai dispositivi tramite Wi-Fi Aware e connettiti utilizzando un hotspot solo locale.
- Rilevare e connettersi a dispositivi tramite Wi-Fi Direct.
- Avvia una connessione a un SSID noto, ad esempio un'auto o un dispositivo per la smart home.
- Avvia un hotspot solo locale.
- Raggio d'azione per i dispositivi Wi-Fi Aware nelle vicinanze.
Se la tua app non ricava informazioni sulla posizione fisica dalle API Wi-Fi, richiedi NEARBY_WIFI_DEVICES anziché ACCESS_FINE_LOCATION quando scegli come target Android 13 o versioni successive e utilizzi le API Wi-Fi. Quando dichiari
l'autorizzazione NEARBY_WIFI_DEVICES, dichiara con fermezza che la tua app non
deriva mai informazioni sulla posizione fisica dalle API Wi-Fi. Per farlo, imposta l'attributo
android:usesPermissionFlags su neverForLocation. Questa procedura è
simile a quella che esegui in Android 12 (livello API 31) e versioni successive quando
affermi che le informazioni sui dispositivi Bluetooth non vengono mai utilizzate per
la posizione.
Scopri di più su come richiedere l'autorizzazione per accedere ai dispositivi Wi-Fi nelle vicinanze.
Autorizzazioni granulari per i contenuti multimediali
READ_MEDIA_AUDIO.Se la tua app ha come target Android 13 o versioni successive e deve
accedere ai file multimediali creati da altre app, devi
richiedere una o più delle seguenti autorizzazioni multimediali granulari anziché l'autorizzazione
READ_EXTERNAL_STORAGE:
| Tipo di media | Autorizzazione per la richiesta |
|---|---|
| Immagini e foto | READ_MEDIA_IMAGES |
| Video | READ_MEDIA_VIDEO |
| File audio | READ_MEDIA_AUDIO |
Prima di accedere ai file multimediali di un'altra app, verifica che l'utente abbia concesso le autorizzazioni multimediali granulari appropriate alla tua app.
La Figura 1 mostra un'app che richiede l'autorizzazione READ_MEDIA_AUDIO.
Se richiedi contemporaneamente l'autorizzazione READ_MEDIA_IMAGES e l'autorizzazione
READ_MEDIA_VIDEO, viene visualizzata una sola finestra di dialogo
di autorizzazione di sistema.
Se alla tua app è stata precedentemente concessa l'autorizzazione
READ_EXTERNAL_STORAGE, le autorizzazioni READ_MEDIA_* richieste vengono concesse
automaticamente durante l'upgrade. Puoi utilizzare il seguente comando ADB per esaminare
le autorizzazioni aggiornate:
adb shell cmd appops get --uid PACKAGE_NAME
L'utilizzo dei sensori del corpo in background richiede una nuova autorizzazione
Android 13 introduce il concetto di accesso "mentre è in uso" per i sensori del corpo, come battito cardiaco, temperatura e percentuale di ossigeno nel sangue. Questo modello di accesso è molto simile a quello introdotto dal sistema per la posizione in Android 10 (livello API 29).
Se la tua app ha come target Android 13 e richiede l'accesso alle informazioni dei sensori del corpo durante l'esecuzione in background, devi dichiarare la nuova autorizzazione
BODY_SENSORS_BACKGROUND
oltre all'autorizzazione
BODY_SENSORS
esistente.
Prestazioni e batteria
Utilizzo delle risorse della batteria
Se l'utente imposta la tua app sullo
stato "con limitazioni" per
l'utilizzo della batteria in background
mentre la tua app ha come target Android 13, il sistema non invia il
broadcast BOOT_COMPLETED o il broadcast LOCKED_BOOT_COMPLETED finché l'app
non viene avviata per altri motivi.
Esperienza utente
Controlli multimediali derivati da PlaybackState
Per le app destinate ad Android 13 (livello API 33) e versioni successive, il sistema deriva
i controlli multimediali dalle azioni
PlaybackState. In questo modo
il sistema può mostrare un insieme più ricco di controlli tecnicamente
coerenti tra smartphone e tablet, e anche in linea con il rendering dei controlli
multimediali su altre piattaforme Android come Android Auto e
Android TV.
La figura 2 mostra un esempio di come appare su uno smartphone e un tablet, rispettivamente.
Prima di Android 13, il sistema mostrava fino a cinque azioni dalla notifica MediaStyle nell'ordine in cui erano state aggiunte.
In modalità compatta, ad esempio nelle impostazioni rapide compresse, venivano visualizzate fino a tre azioni specificate con setShowActionsInCompactView().
A partire da Android 13, il sistema mostra fino a cinque pulsanti di azione in base
a PlaybackState, come descritto nella tabella seguente. In modalità compatta, vengono visualizzati solo i primi tre
slot di azioni. Per le app che non hanno come target Android 13 o quelle
che non includono un PlaybackState, il sistema mostrerà i controlli in base
all'elenco Action aggiunto alla notifica MediaStyle, come descritto nel
paragrafo precedente.
| Slot | Azione | Criteri |
|---|---|---|
| 1 | Riproduci |
Lo stato attuale di PlaybackState è uno dei seguenti:
|
| Rotellina di caricamento |
Lo stato attuale di PlaybackState è uno dei seguenti:
|
|
| Metti in pausa | Lo stato attuale di PlaybackState non è nessuno dei precedenti. |
|
| 2 | Indietro | Le azioni di PlaybackState includono ACTION_SKIP_TO_PREVIOUS. |
| Personalizzata | Le azioni PlaybackState non includono ACTION_SKIP_TO_PREVIOUS e le azioni personalizzate PlaybackState includono un'azione personalizzata che non è ancora stata inserita. |
|
| Vuoto | PlaybackState extras include un valore booleano true per la chiave SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Avanti | Le azioni di PlaybackState includono ACTION_SKIP_TO_NEXT. |
| Personalizzata | Le azioni PlaybackState non includono ACTION_SKIP_TO_NEXT e le azioni personalizzate PlaybackState includono un'azione personalizzata che non è ancora stata inserita. |
|
| Vuoto | PlaybackState extras include un valore booleano true per la chiave SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Personalizzata | PlaybackState Azioni personalizzate include un'azione personalizzata che non è ancora stata posizionata. |
| 5 | Personalizzata | PlaybackState Azioni personalizzate include un'azione personalizzata che non è ancora stata posizionata. |
Le azioni personalizzate vengono inserite nell'ordine in cui sono state aggiunte al
PlaybackState.
Tema di colore dell'app applicato automaticamente ai contenuti WebView
Per le app che hanno come target Android 13 (livello API 33) o versioni successive, il metodo
setForceDark()
è ritirato e non ha effetto se viene chiamato.
WebView ora imposta sempre
la media query prefers-color-scheme in base all'attributo tema dell'app,
isLightTheme. In altre
parole, se isLightTheme è true o non è specificato, prefers-color-scheme è
light; altrimenti, è dark. Questo comportamento significa che lo stile chiaro o scuro dei contenuti web viene applicato automaticamente in base al tema dell'app se i contenuti lo supportano.
Per la maggior parte delle app, il nuovo comportamento dovrebbe applicare automaticamente gli stili appropriati, ma devi testare la tua app per verificare eventuali casi in cui potresti aver controllato manualmente le impostazioni della modalità Buio.
Se devi ancora personalizzare il comportamento del tema dei colori della tua app, utilizza il metodo
setAlgorithmicDarkeningAllowed(). Per la compatibilità con le versioni precedenti di Android, ti
consigliamo di utilizzare il metodo
setAlgorithmicDarkeningAllowed()
equivalente in AndroidX.
Consulta la documentazione di questo metodo per scoprire di più sul comportamento che puoi
aspettarti nella tua app a seconda delle impostazioni
targetSdkVersion e del tema
dell'app.
Connettività
BluetoothAdapter#enable() e BluetoothAdapter#disable() sono deprecati
Per le app che hanno come target Android 13 (livello API 33) o versioni successive, i metodi
BluetoothAdapter#enable() e
BluetoothAdapter#disable() sono ritirati e restituiscono sempre
false.
I seguenti tipi di app sono esenti da queste modifiche:
- App del proprietario del dispositivo
- App del proprietario del profilo
- App di sistema
Google Play Services
Autorizzazione richiesta per l'ID pubblicità
Le app che utilizzano l'ID
pubblicità di Google Play Services e
hanno come target Android 13 (livello API 33) e versioni successive devono
dichiarare l'autorizzazione normale AD_ID nel file
manifest dell'app, come segue:
<manifest ...>
<!-- Required only if your app targets Android 13 or higher. -->
<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>
<application ...>
...
</application>
</manifest>
Se la tua app non dichiara questa autorizzazione quando ha come target Android 13 o versioni successive, l'ID pubblicità viene rimosso automaticamente e sostituito da una stringa di zeri.
Se la tua app utilizza SDK che dichiarano l'autorizzazione AD_ID nel file manifest della libreria, l'autorizzazione viene unita al file manifest della tua app per impostazione predefinita. In questo caso, non è necessario dichiarare l'autorizzazione nel file manifest dell'app.
Per saperne di più, consulta la sezione ID pubblicità nel Centro assistenza Play Console.
Limitazioni non SDK aggiornate
Android 13 include elenchi aggiornati di interfacce non SDK con limitazioni in base alla collaborazione con gli sviluppatori Android e ai test interni più recenti. Ove possibile, ci assicuriamo che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.
Se la tua app non ha come target Android 13, alcune di queste modifiche potrebbero non interessarti immediatamente. Tuttavia, anche se al momento puoi utilizzare alcune interfacce non SDK (a seconda del livello API target della tua app), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di interruzione dell'app.
Se non sai con certezza se la tua app utilizza interfacce non SDK, puoi testarla per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare una migrazione ad alternative SDK. Tuttavia, ci rendiamo conto che alcune app hanno casi d'uso validi per l'utilizzo di interfacce non SDK. Se non riesci a trovare un'alternativa all'utilizzo di un'interfaccia non SDK per una funzionalità della tua app, devi richiedere una nuova API pubblica.
Per scoprire di più sulle modifiche apportate a questa release di Android, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 13. Per scoprire di più sulle interfacce non SDK in generale, consulta Limitazioni relative alle interfacce non SDK.