Come nelle release precedenti, Android 13 include modifiche del comportamento che potrebbero interessare la tua app. Le seguenti modifiche del comportamento si applicano esclusivamente alle app destinate ad Android 13 o versioni successive. Se la tua app ha come target Android 13 o versioni successive, devi modificarla in modo che supporti correttamente questi comportamenti, ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano tutte le app in esecuzione su Android 13.
Privacy
L'autorizzazione alle notifiche influisce sull'aspetto dei servizi in primo piano
Se l'utente nega l'autorizzazione alle notifiche, non vedrà le notifiche relative ai servizi in primo piano nel riquadro a scomparsa delle notifiche. Tuttavia, gli utenti continueranno a vedere le notifiche relative ai servizi in primo piano in Task Manager, indipendentemente dal fatto che l'autorizzazione alle notifiche sia stata 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 relativi al Wi-Fi.
Poiché è difficile per gli utenti associare le autorizzazioni di accesso alla posizione alle funzionalità Wi-Fi, Android 13 (livello API 33) introduce un'autorizzazione di runtime nel
NEARBY_DEVICES
gruppo di autorizzazioni 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 casi d'uso relativi al Wi-Fi quali:
- Trova o collega i dispositivi nelle vicinanze, ad esempio stampanti o dispositivi di trasmissione di contenuti multimediali.
Questo flusso di lavoro consente alla tua app di svolgere i seguenti tipi di attività:
- Ricevi informazioni AP fuori banda, ad esempio tramite BLE.
- Individua e connettiti ai dispositivi tramite Wi-Fi Aware e connettiti utilizzando un hotspot solo locale.
- Individua e connettiti ai dispositivi tramite Wi-Fi Direct.
- Avvia una connessione a un SSID noto, come un'auto o un dispositivo per la smart home.
- Avvia un hotspot solo locale.
- Raggio d'azione ai 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 se scegli come target Android 13 o versioni successive e utilizzi le API Wi-Fi. Quando dichiari
l'autorizzazione NEARBY_WIFI_DEVICES, dichiara con certezza che la tua app non
dera mai informazioni sulla posizione fisica dalle API Wi-Fi. Per farlo, imposta l'attributo
android:usesPermissionFlags su neverForLocation. Questa procedura è
simile a quella utilizzata in Android 12 (livello API 31) e versioni successive, quando
dichiari che le informazioni del dispositivo Bluetooth non vengono mai utilizzate per
la geolocalizzazione.
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 a file multimediali creati da altre app, devi
richiedere una o più delle seguenti autorizzazioni per i contenuti multimediali granulari anziché
l'autorizzazione
READ_EXTERNAL_STORAGE:
| Tipo di contenuto multimediale | Autorizzazione alla 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 dell'autorizzazione di sistema.
Se alla tua app era stata concessa l'autorizzazione
READ_EXTERNAL_STORAGE, tutte le autorizzazioni READ_MEDIA_* richieste vengono concesse automaticamente durante l'upgrade. Per esaminare le autorizzazioni aggiornate, puoi utilizzare il seguente comando ADB:
adb shell cmd appops get --uid PACKAGE_NAME
L'uso dei sensori del corpo in background richiede una nuova autorizzazione
Android 13 introduce il concetto di accesso "durante l'uso" per i sensori del corpo, come il battito cardiaco, la temperatura e la 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 a 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 nello stato "Con restrizioni" per l'utilizzo della batteria in background mentre l'app ha come target Android 13, il sistema non trasmette la trasmissione BOOT_COMPLETED o LOCKED_BOOT_COMPLETED finché l'app non viene avviata per altri motivi.
Esperienza utente
Controlli multimediali derivati da PlaybackState
Per le app che hanno come target Android 13 (livello API 33) e versioni successive, il sistema ricava i controlli multimediali dalle azioni PlaybackState. In questo modo, il sistema può mostrare un insieme più completo di controlli, tecnicamente coerenti tra smartphone e tablet e in linea con il rendering dei controlli dei contenuti multimediali su altre piattaforme Android, come Android Auto e Android TV.
La figura 2 mostra un esempio di come appare rispettivamente su un telefono e un tablet.
Prima di Android 13, il sistema mostrava fino a cinque azioni dalla notifica MediaStyle
nell'ordine in cui erano state aggiunti.
In modalità compatta, ad esempio nelle impostazioni rapide compresse, sono state mostrate fino a tre azioni specificate con setShowActionsInCompactView().
A partire da Android 13, il sistema mostra fino a cinque pulsanti di azione in base
al PlaybackState, come descritto nella tabella che segue. In modalità compatta vengono
visualizzati solo i primi tre slot di azione. Per le app che non hanno come target Android 13 o quelle
che non includono un PlaybackState, il sistema mostrerà i controlli basati sull'elenco
Action aggiunto alla notifica MediaStyle, come descritto nel
paragrafo precedente.
| Slot | Azione | Criteri |
|---|---|---|
| 1 | Riproduci |
Lo stato corrente di PlaybackState è uno dei seguenti:
|
| Rotella di caricamento |
Lo stato corrente di PlaybackState è uno dei seguenti:
|
|
| Metti in pausa | Lo stato corrente di PlaybackState non è uno dei precedenti. |
|
| 2 | Precedente | Le azioni di PlaybackState includono ACTION_SKIP_TO_PREVIOUS. |
| Personalizzata | PlaybackState azioni non includono ACTION_SKIP_TO_PREVIOUS e PlaybackState azioni personalizzate includono un'azione personalizzata che non è stata ancora eseguita. |
|
| Vuoto | PlaybackState Gli extra includono 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 | PlaybackState azioni non includono ACTION_SKIP_TO_NEXT e PlaybackState azioni personalizzate includono un'azione personalizzata che non è stata ancora eseguita. |
|
| Vuoto | PlaybackState Gli extra includono un valore booleano true per la chiave SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Personalizzata | PlaybackState azioni personalizzate includono un'azione personalizzata che non è stata ancora eseguita. |
| 5 | Personalizzata | PlaybackState azioni personalizzate includono un'azione personalizzata che non è stata ancora eseguita. |
Le azioni personalizzate vengono inserite nell'ordine in cui sono state aggiunte a PlaybackState.
Tema cromatico 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() è deprecato e, se richiamato, il metodo è autonomo.
Al contrario, WebView ora imposta sempre
la query multimediale prefers-color-scheme in base all'attributo tema dell'app,
isLightTheme. In altre parole, se isLightTheme è true o non specificato, prefers-color-scheme è light; in caso contrario, è dark. Con questo comportamento, lo stile chiaro o scuro dei contenuti web viene applicato automaticamente per corrispondere al tema dell'app, se i contenuti lo supportano.
Per la maggior parte delle app, il nuovo comportamento dovrebbe applicare automaticamente gli stili dell'app appropriati, ma dovresti testare l'app per verificare la presenza di eventuali casi in cui tu abbia controllato manualmente le impostazioni della modalità Buio.
Se devi ancora personalizzare il comportamento del tema cromatico della tua app, usa 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 relativa a quel metodo per scoprire di più sul comportamento che puoi aspettarti nella tua app a seconda delle impostazioni di targetSdkVersion e del tema dell'app.
Connettività
BluetoothAdapter#enable() e BluetoothAdapter#disable() deprecati
Per le app che hanno come target Android 13 (livello API 33) o versioni successive, i metodi BluetoothAdapter#enable() e BluetoothAdapter#disable() sono deprecati 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 che 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 con 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 dell'app per
impostazione predefinita. In questo caso, non è necessario dichiarare l'autorizzazione nel file manifest dell'app.
Per scoprire di più, consulta la sezione ID pubblicità nella Guida di Play Console.
Limitazioni non SDK aggiornate
Android 13 include elenchi aggiornati di interfacce non SDK limitate in base alla collaborazione con sviluppatori Android e agli ultimi test interni. Se 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 riguardarti 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 danneggiare l'app.
Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testarla per scoprirlo. Se la tua app si basa su interfacce non SDK, dovresti iniziare a pianificare una migrazione a alternative SDK. Tuttavia, sappiamo 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à nella tua app, devi richiedere una nuova API pubblica.
Per scoprire di più sulle modifiche in questa release di Android, consulta gli aggiornamenti alle limitazioni relative all'interfaccia non SDK in Android 13. Per saperne di più sulle interfacce non SDK in generale, consulta Restrizioni relative alle interfacce non SDK.