Come nelle release precedenti, Android 13 include modifiche del comportamento che potrebbero interessare dell'app. Le seguenti modifiche del comportamento si applicano esclusivamente alle app scelte come target Android 13 o versioni successive. Se la tua app ha come target Android 13 o versioni successive, modificare l'app in modo da supportare correttamente questi comportamenti, ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano tutte le app. con Android 13.
Privacy
L'autorizzazione alle notifiche influisce sull'aspetto dei servizi in primo piano
Se l'utente nega autorizzazione alle notifiche, non vede le notifiche relative ai servizi in primo piano riquadro a scomparsa delle notifiche. Tuttavia, gli utenti continueranno a visualizzare le notifiche relative ai servizi in primo piano nella Task Manager, indipendentemente dal fatto che sia stata concessa l'autorizzazione alle notifiche.
Nuova autorizzazione di runtime per i dispositivi Wi-Fi nelle vicinanze
Nelle versioni precedenti di Android, l'utente deve concedere all'app
ACCESS_FINE_LOCATION
per completare diversi casi d'uso comuni del Wi-Fi.
Perché è difficile per gli utenti associare le autorizzazioni di accesso alla posizione al Wi-Fi
di Android 13 (livello API 33) introduce un'autorizzazione di runtime nella
NEARBY_DEVICES
gruppo di autorizzazioni per le app che gestiscono le connessioni di un dispositivo all'accesso nelle vicinanze
punti di accesso tramite Wi-Fi. Questa autorizzazione,
NEARBY_WIFI_DEVICES,
soddisfa i seguenti casi d'uso relativi al Wi-Fi:
- 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.
Finché la tua app non ricava i dati sulla posizione fisica dalla rete Wi-Fi
API, richiedi NEARBY_WIFI_DEVICES anziché ACCESS_FINE_LOCATION quando
hanno come target Android 13 o versioni successive e utilizzano le API Wi-Fi. Quando dichiari
l'autorizzazione NEARBY_WIFI_DEVICES, dichiara con certezza che la tua app non ha mai
ricava informazioni sulla posizione fisica dalle API Wi-Fi. Per farlo, imposta il parametro
android:usesPermissionFlags a neverForLocation. Questo processo è
simile a quella utilizzata in Android 12 (livello API 31) e versioni successive quando
Dichiarare che le informazioni del dispositivo Bluetooth non vengono mai utilizzate
posizione.
Scopri di più su come richiedere l'autorizzazione ad 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 di altre app
creato, devi
richiedi una o più delle seguenti autorizzazioni multimediali granulari anziché
READ_EXTERNAL_STORAGE:
autorizzazione:
| 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 granulari per i contenuti multimediali appropriate per la tua app.
La Figura 1 mostra un'app che richiede l'autorizzazione READ_MEDIA_AUDIO.
Se richiedi sia l'autorizzazione READ_MEDIA_IMAGES sia
Autorizzazione READ_MEDIA_VIDEO contemporaneamente, solo una autorizzazione di sistema
.
Se in precedenza alla tua app era stato concesso
READ_EXTERNAL_STORAGE
l'autorizzazione READ_MEDIA_* richiesta viene concessa
automaticamente durante l'upgrade. Puoi utilizzare il seguente comando ADB per esaminare
autorizzazioni aggiornate:
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 "durante l'uso" l'accesso per sensori del corpo, come battito cardiaco, temperatura e percentuale di ossigeno nel sangue. Questo è molto simile a quello introdotto dal sistema per la località su Android 10 (livello API 29).
Se la tua app è destinata ad Android 13 e richiede l'accesso al sensore del corpo
durante l'esecuzione in background, devi dichiarare il nuovo
BODY_SENSORS_BACKGROUND
oltre all'autorizzazione esistente
BODY_SENSORS
autorizzazione.
Prestazioni e batteria
Utilizzo delle risorse della batteria
Se l'utente inserisce la tua app
"limitato" stato per
utilizzo della batteria in background
mentre la tua app ha come target Android 13, il sistema non pubblica
la trasmissione BOOT_COMPLETED o la trasmissione LOCKED_BOOT_COMPLETED fino alla
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
controlli multimediali da
PlaybackState azioni. Questo
consente al sistema di mostrare un insieme più completo di controlli tecnicamente
in modo coerente tra smartphone e tablet e anche
allinearsi al modo in cui
il rendering dei controlli viene eseguito su altre piattaforme Android, come Android Auto e
Android TV.
La figura 2 mostra un esempio di come appare su un telefono e un tablet, rispettivamente.
Prima di Android 13, il sistema visualizzava fino a cinque azioni dall'MediaStyle
nell'ordine in cui sono stati aggiunti.
In modalità compatta, ad esempio nelle impostazioni rapide per la compressione, fino a
tre azioni specificate con setShowActionsInCompactView()
sono stati mostrati.
A partire da Android 13, il sistema mostra fino a cinque pulsanti di azione in base
su PlaybackState, come descritto nella seguente tabella. In modalità compatta, solo le prime tre
spazi di azioni. Per le app che non hanno come target Android 13 o versioni successive
che non includono un PlaybackState, il sistema mostrerà i controlli basati su
l'elenco Action è stato aggiunto alla notifica MediaStyle, come descritto in
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 | Indietro | 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 alla
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,
setForceDark()
è deprecato, determinando un'interruzione se il metodo viene chiamato.
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; altrimenti è dark. Questo comportamento indica che i contenuti web
lo stile chiaro o scuro 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 gli stili di app appropriati automaticamente, ma devi testare l'app per verificare la presenza di eventuali casi in cui è possibile che tu abbia controllato manualmente le impostazioni della modalità Buio.
Se devi ancora personalizzare il comportamento del tema cromatico della tua app, utilizza la
setAlgorithmicDarkeningAllowed()
. Per la compatibilità con le versioni precedenti di Android,
consiglia di utilizzare lo stesso
setAlgorithmicDarkeningAllowed()
in AndroidX.
Consulta la documentazione relativa al metodo specifico per scoprire di più sul comportamento che puoi
che si aspettano nell'app in base al tipo
targetSdkVersion e tema
impostazioni.
Connettività
BluetoothAdapter#enable() e BluetoothAdapter#disable() deprecati
Per le app che hanno come target Android 13 (livello API 33) o versioni successive,
BluetoothAdapter#enable() e
I metodi BluetoothAdapter#disable() sono deprecati e sempre
restituisce 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à
App che utilizzano la pubblicità di Google Play Services
ID e
devono avere come target Android 13 (livello API 33) e versioni successive.
dichiarerà l'autorizzazione AD_ID normale nel
, 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 superiore, l'ID pubblicità viene automaticamente rimosso e sostituito con una stringa di zeri.
Se la tua app utilizza SDK che dichiarano l'autorizzazione AD_ID nella libreria
manifest, l'autorizzazione viene unita al file manifest dell'app
predefinito. In questo caso, non è necessario dichiarare l'autorizzazione nel
file manfiest.
Per scoprire di più, consulta Pubblicità ID in nella guida di Play Console.
Limitazioni non SDK aggiornate
Android 13 include elenchi aggiornati di elementi non SDK soggetti a restrizioni basate sulla collaborazione con gli sviluppatori Android e le applicazioni per i test interni. Quando possibile, facciamo in modo che le alternative pubbliche siano disponibili prima che vengano limitate le interfacce non SDK.
Se la tua app non ha come target Android 13, alcune di queste modifiche potrebbero non riguardarti immediatamente. Tuttavia, sebbene al momento tu possa utilizzare interfacce non SDK (in base all'API target dell'app ), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di danneggiare dell'app.
Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare app per scoprirlo. Se la tua app si basa su interfacce non SDK, dovresti iniziare a pianificare una migrazione alle alternative dell'SDK. Tuttavia, sappiamo che alcune app hanno e validi casi d'uso 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 ulteriori informazioni sulle modifiche in questa release di Android, consulta gli aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 13. Per scoprire di più sulle interfacce non SDK in generale, consulta Restrizioni relative alle interfacce non SDK. di archiviazione.