Cambiamenti del comportamento: app destinate ad Android 13 o versioni successive

Come le release 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 alle notifiche influisce sull'aspetto del servizio in primo piano

Se l'utente nega l' autorizzazione alle notifiche, non vede gli avvisi relativi ai servizi in primo piano nel riquadro delle notifiche. Tuttavia, gli utenti continuano a vedere gli avvisi relativi ai servizi in primo piano in Gestione attività, indipendentemente dal fatto che l'autorizzazione alle notifiche sia stata concessa o meno.

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 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 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 alla tua app di svolgere questi tipi di attività:
  • Ricevere informazioni sul punto di accesso fuori banda, ad esempio tramite BLE.
  • Rilevare e connettersi ai dispositivi tramite Wi-Fi Aware e connettersi utilizzando un hotspot solo locale.
  • Rilevare e connettersi ai dispositivi tramite Wi-Fi Direct.
• Avviare una connessione a un SSID noto, ad esempio un'auto o un dispositivo per la smart home.
• Avviare un hotspot solo locale.
• Misurare la distanza dai 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, afferma con decisione che la tua app non ricava 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

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 granulari per i contenuti multimediali anziché l'autorizzazione READ_EXTERNAL_STORAGE:

Prima di accedere ai file multimediali di un'altra app, verifica che l'utente abbia concesso alla tua app le autorizzazioni granulari per i contenuti multimediali appropriate.

La Figura 1 mostra un'app che richiede l'autorizzazione READ_MEDIA_AUDIO.

Se richiedi contemporaneamente le autorizzazioni READ_MEDIA_IMAGES e READ_MEDIA_VIDEO, viene visualizzata una sola finestra di dialogo delle autorizzazioni di sistema.

Se alla tua app è stata precedentemente concessa l'autorizzazione READ_EXTERNAL_STORAGE, tutte le autorizzazioni READ_MEDIA_* richieste vengono concesse automaticamente durante l'upgrade. Puoi utilizzare il seguente comando ADB per esaminare le autorizzazioni di cui è stato eseguito l'upgrade:

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 "durante l'utilizzo" per i sensori del corpo, come frequenza cardiaca, 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 BODY_SENSORS_BACKGROUND autorizzazione in aggiunta 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 BOOT_COMPLETED broadcast o il LOCKED_BOOT_COMPLETED broadcast 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 deriva i controlli multimediali dalle PlaybackState azioni. In questo modo, il sistema può mostrare un insieme più ricco di controlli tecnicamente coerenti tra smartphone e tablet, che si allineano anche al modo in cui i controlli multimediali vengono visualizzati su altre piattaforme Android come Android Auto e Android TV.

La Figura 2 mostra un esempio di come appare rispettivamente su uno smartphone e un tablet.

Prima di Android 13, il sistema visualizzava fino a cinque azioni dalla MediaStyle notifica nell'ordine in cui erano state aggiunte. In modalità compatta, ad esempio nelle impostazioni rapide compresse, venivano mostrate fino a tre azioni specificate con setShowActionsInCompactView()

A partire da Android 13, il sistema visualizza 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 azione. Per le app che non hanno come target Android 13 o che non includono un PlaybackState, il sistema visualizzerà i controlli in base all'elenco Action aggiunto alla notifica MediaStyle, come descritto nel paragrafo precedente.

Le azioni personalizzate vengono inserite nell'ordine in cui sono state aggiunte a PlaybackState.

Il tema cromatico dell'app viene applicato automaticamente ai contenuti WebView

Per le app che hanno come target Android 13 (livello API 33) o versioni successive, il setForceDark() metodo è obsoleto e non ha alcun effetto se viene chiamato.

Invece, WebView ora imposta sempre la query supporti prefers-color-scheme in base all'attributo del tema dell'app, isLightTheme. In altre parole, se isLightTheme è true o non è specificato, prefers-color-scheme è light; in caso contrario, è dark. Questo comportamento significa che lo stile chiaro o scuro dei contenuti web viene applicato automaticamente in modo che corrisponda al tema dell'app, se i contenuti lo supportano.

Per la maggior parte delle app, il nuovo comportamento dovrebbe applicare automaticamente gli stili appropriati dell'app, ma devi testare la tua app per verificare se hai controllato manualmente le impostazioni della modalità Buio.

Se devi comunque personalizzare il comportamento del tema cromatico della tua app, utilizza invece il setAlgorithmicDarkeningAllowed() metodo. Per la compatibilità con le versioni precedenti di Android, ti consigliamo di utilizzare il metodo equivalente setAlgorithmicDarkeningAllowed() in AndroidX.

Consulta la documentazione di questo 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à

I metodi BluetoothAdapter#enable() e BluetoothAdapter#disable() sono obsoleti

Per le app che hanno come target Android 13 (livello API 33) o versioni successive, i BluetoothAdapter#enable() e BluetoothAdapter#disable() sono obsoleti e restituiscono sempre false.

I seguenti tipi di app sono esenti da queste modifiche:

• App Proprietario del dispositivo
• App 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 dell'app per impostazione predefinita. In questo caso, non devi dichiarare l'autorizzazione nel file manifest dell'app.

Per saperne di più, consulta l'articolo ID pubblicità nel Centro assistenza Play Console.

Restrizioni non SDK aggiornate

Android 13 include elenchi aggiornati di interfacce non SDK con limitazioni basate sulla collaborazione con gli sviluppatori Android e sui 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 influire immediatamente su di te. 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 se la tua app utilizza interfacce non SDK, puoi testare la tua app per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare la migrazione alle 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à della tua app, devi richiedere una nuova API pubblica.

Per saperne di più sulle modifiche in questa release di Android, consulta Aggiornamenti alle limitazioni delle interfacce non SDK in Android 13. Per saperne di più sulle interfacce non SDK in generale, consulta Limitazioni delle interfacce non SDK interfaces.