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

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

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:

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.

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.