Modifiche del comportamento: tutte le app

La piattaforma Android 12 include modifiche del comportamento che potrebbero influisce sulla tua app. Le seguenti modifiche del comportamento si applicano a tutte le app quando vengono vengono eseguiti su Android 12, indipendentemente da targetSdkVersion. Dovresti testare l'app e poi modificarla in base alle esigenze per supportarle correttamente, dove applicabile.

Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano solo le app che hanno come target Android 12.

Esperienza utente

Allunga effetto overscroll

Sui dispositivi con Android 12 e versioni successive, il comportamento visivo dello scorrimento per overscroll eventi.

Su Android 11 e versioni precedenti, un evento overscroll consente di avere gli elementi visivi un bagliore; su Android 12 e versioni successive, gli elementi visivi si allungano e si riprendono un evento di trascinamento, per poi spostarsi e riprendersi.

Per ulteriori informazioni, consulta la guida allo scorrimento animato gesti.

Schermate iniziali delle app

Se in precedenza hai implementato una schermata iniziale personalizzata in Android 11 oppure dovrai eseguire la migrazione dell'app all'API SplashScreen per assicurarti viene visualizzata correttamente a partire da Android 12. La mancata migrazione dell'app comporterà in un'esperienza di avvio dell'app ridotta o non intenzionale.

Per le istruzioni, vedi Eseguire la migrazione della schermata iniziale esistente implementazione su Android 12.

Inoltre, a partire da Android 12, il sistema applica sempre il nuovo schermata iniziale predefinita di sistema attiva freddo e avvii caldi per tutte le app. Per impostazione predefinita, questa schermata iniziale predefinita di sistema è creata utilizzando icona in Avvio applicazioni e windowBackground dei tuoi tema (se è di un solo colore).

Per maggiori dettagli, consulta la guida per gli sviluppatori sulle schermate iniziali.

Risoluzione dell'intent web

A partire da Android 12 (livello API 31), un intent web generico viene risolto in un attività nella tua app solo se è approvata per il dominio specifico contenuti nell'intent web. Se la tua app non viene approvata per il dominio, l'intent web si risolve invece nell'app browser predefinita dell'utente.

Le app possono ottenere questa approvazione in uno dei seguenti modi:

Se la tua app richiama intent web, valuta la possibilità di aggiungere una richiesta o una finestra di dialogo che chieda all'utente per confermare l'azione.

Miglioramenti alla modalità immersiva per la navigazione tramite gesti

Android 12 consolida il comportamento esistente per consentire agli utenti di esegui comandi di navigazione tramite gesti in modalità immersiva . Nella Inoltre, Android 12 offre un comportamento di compatibilità con le versioni precedenti immersivo .

Display#getRealSize e getRealMetrics: deprecazione e vincoli

I dispositivi Android sono disponibili in molti fattori di forma, ad esempio modelli schermi, tablet e pieghevoli. Per eseguire il rendering dei contenuti in modo appropriato per ogni dispositivo, l'app deve determinare le dimensioni dello schermo o del display. Nel tempo, Android ha fornito API diverse per recuperare queste informazioni. Su Android 11, abbiamo introdotto la WindowMetrics API e questi metodi sono stati ritirati:

In Android 12 consigliamo sempre di utilizzare WindowMetrics ritirando questi metodi:

Per mitigare il comportamento delle applicazioni che utilizzano le API display per recuperare il limiti dell'applicazione, Android 12 vincola i valori restituiti dalle API per le app non ridimensionabili completamente. Ciò potrebbe influire app che usano queste informazioni con MediaProjection.

Le app devono usare le API WindowMetrics per eseguire query sui limiti dalla finestra e Configuration.densityDpi per eseguire query sulla densità attuale.

Per una compatibilità più ampia con le versioni precedenti di Android, puoi utilizzare il Jetpack WindowManager, che include un corso WindowMetrics che supporta Android 4.0 (livello API 14) e versioni successive.

Esempi di come utilizzare WindowMetrics

Innanzitutto, assicurati che le attività dell'app siano completamente ridimensionabili.

Un'attività deve basarsi su WindowMetrics di un contesto di attività per qualsiasi relativi all'interfaccia utente, in particolare WindowManager.getCurrentWindowMetrics() o Jetpack WindowMetricsCalculator.computeCurrentWindowMetrics().

Se l'app crea un elemento MediaProjection, i limiti devono essere dimensionati correttamente poiché la proiezione acquisisce la partizione del display in cui l'app proiettore in esecuzione.

Se l'app è completamente ridimensionabile, il contesto dell'attività restituisce i limiti corretti. in questo modo:

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Java

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Se l'app non è completamente ridimensionabile, deve eseguire query da un WindowContext di Compute Engine e recupera la WindowMetrics dei limiti di attività utilizzando WindowManager.getMaximumWindowMetrics(): o il metodo Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Java

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Tutte le app in modalità multi-finestra

Android 12 utilizza il comportamento standard della modalità multi-finestra.

Su schermi di grandi dimensioni (sw >= 600 dp), la piattaforma supporta tutte le app in modalità multi-finestra indipendentemente dalla configurazione dell'app. Se resizeableActivity="false", l'app viene messa in modalità di compatibilità quando necessario per supportare il display dimensioni.

Su schermi di piccole dimensioni (sw < 600 dp), il sistema controlla lo stato minWidth e minHeight per determinare se l'attività può essere eseguita in modalità multi-finestra. Se resizeableActivity="false", all'app viene impedito l'esecuzione in modalità multi-finestra a prescindere dal numero minimo e larghezza e altezza.

Per ulteriori informazioni, consulta la sezione Supporto multi-finestra.

Anteprima della fotocamera su schermi di grandi dimensioni

Le app con fotocamera in genere presuppongono una relazione fissa tra l'orientamento il dispositivo e le proporzioni dell'anteprima della fotocamera. Ma gli schermi più grandi come i dispositivi pieghevoli e le modalità di visualizzazione come multi-finestra e multi-display, metti in discussione questa ipotesi.

Su Android 12, le app della fotocamera che richiedono una schermata specifica orientato e non ridimensionabili (resizeableActivity="false") automaticamente inserisci la modalità verticale integrata, che garantisce l'orientamento e le proporzioni corretti proporzioni dell'anteprima della fotocamera. Su pieghevoli e altri dispositivi dotati di fotocamera HAL (Hardware Astrazione Layer), Viene applicata una rotazione aggiuntiva all'output della fotocamera per compensare la fotocamera orientamento del sensore e l'output della fotocamera viene ritagliato per corrispondere alle proporzioni dell'anteprima della fotocamera dell'app. Il ritaglio e la rotazione extra assicurano il corretto funzionamento presentazione dell'anteprima della fotocamera indipendentemente dall'orientamento del dispositivo e piegata o se il dispositivo è aperto.

Ritardo UX per le notifiche dei servizi in primo piano

Per offrire un'esperienza semplificata per i video in primo piano breve , i dispositivi che eseguono Android 12 o versioni successive può ritardare la visualizzazione del servizio in primo piano notifiche di 10 secondi, con alcune eccezioni. Questo modifica consente di completare attività di breve durata prima delle notifiche vengono visualizzate.

Prestazioni

Bucket standby dell'app limitato

Android 11 (livello API 30) ha introdotto la funzionalità limitata bucket come standby dell'app Bucket. A partire da Android 12, questo bucket è attivo per impostazione predefinita. Il bucket con restrizioni ha la priorità più bassa (e le restrizioni massime) in tutti i bucket. I bucket in ordine di priorità, dalla più alta alla più bassa, sono:

  1. Attiva: l'app è attualmente in uso o è stata utilizzata molto di recente.
  2. Set di lavoro: l'app è in uso regolare.
  3. Frequente: l'app viene utilizzata spesso, ma non tutti i giorni.
  4. Raro: l'app non viene utilizzata di frequente.
  5. Con limitazioni: l'app utilizza una grande quantità di risorse di sistema o può presentare comportamenti indesiderati.

Oltre ai modelli di utilizzo, il sistema tiene conto del comportamento dell'app per decidi se posizionare la tua app nel bucket con restrizioni.

È meno probabile che la tua app venga inserita nel bucket con limitazioni se utilizza le risorse di sistema in modo più responsabile. Inoltre, il sistema posiziona l'app in un un bucket restrittivo se l'utente interagisce direttamente con la tua app.

Controllare se l'app si trova nel bucket con limitazioni

Per verificare se il sistema ha inserito la tua app nel bucket con limitazioni, chiama getAppStandbyBucket() Se il valore restituito di questo metodo è STANDBY_BUCKET_RESTRICTED, la tua app si trova nel bucket con restrizioni.

Testa il comportamento del bucket limitato

Per testare il comportamento della tua app quando il sistema la inserisce nelle aree con limitazioni puoi spostare manualmente la tua app in quel bucket. Per farlo, esegui il comando questo comando in una finestra del terminale:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Sicurezza e privacy

Posizione approssimativa

La finestra di dialogo offre due serie di opzioni, una sopra altro
Figura 1. Finestra di dialogo delle autorizzazioni di sistema che consente all'utente per concedere informazioni sulla posizione approssimativa.

Sui dispositivi con Android 12 o versioni successive, gli utenti possono richiesta che la tua app abbia accesso solo alla posizione approssimativa informazioni.

Se la tua app richiede ACCESS_FINE_LOCATION l'autorizzazione di runtime, devi richiedere anche ACCESS_COARSE_LOCATION l'autorizzazione a gestire il caso in cui l'utente concede l'accesso alla posizione approssimativa alla tua app. Devi includere entrambe le autorizzazioni in un unico runtime richiesta.

La finestra di dialogo delle autorizzazioni di sistema include le seguenti opzioni per l'utente: come mostrato nella figura 1:

  • Esatta: fornisce l'accesso a informazioni sulla posizione esatta.
  • Approssimativa: fornisce l'accesso solo a informazioni sulla posizione approssimativa.

Attivazione/disattivazione di microfono e fotocamera

I dispositivi supportati con Android 12 o versioni successive consentono agli utenti di: attivare e disattivare l'accesso alla fotocamera e al microfono per tutte le app sul dispositivo, mediante premendo una singola opzione di attivazione/disattivazione. Gli utenti possono accedere alle opzioni attivabili Impostazioni rapide, come mostrato in figura 1 o dalla schermata Privacy nelle impostazioni di sistema.

Scopri di più su questi argomenti attiva/disattiva e come controllarli che la tua app rispetti le best practice relative ai CAMERA e RECORD_AUDIO autorizzazioni aggiuntive.

Indicatori microfono e fotocamera

Sui dispositivi con Android 12 o versioni successive, quando un'app accede sul microfono o sulla fotocamera, nella barra di stato viene visualizzata un'icona.

Scopri di più su questi argomenti indicatori e come verifica che la tua app rispetti le best practice relative ai CAMERA e RECORD_AUDIO autorizzazioni aggiuntive.

I riquadri delle Impostazioni rapide sono etichettati come &quot;Accesso alla fotocamera&quot; e &quot;Accesso al microfono&quot;
Figura 2. Attivazione/disattivazione di microfono e fotocamera Impostazioni rapide.
Un rettangolo arrotondato nell&#39;angolo in alto a destra, che include un&#39;icona a forma di fotocamera e un&#39;icona di microfono
Figura 3. Gli indicatori del microfono e della fotocamera, che mostrano l'accesso recente ai dati.

Visibilità del pacchetto di autorizzazioni

Sui dispositivi con Android 12 o versioni successive, le app che hanno come target Android 11 (livello API 30) o versioni successive che richiamano uno dei seguenti metodi riceveranno un insieme filtrato di risultati, basati sul pacchetto dell'app visibilità su altre app:

Implementazione di BouncyCastle rimossa

Android 12 rimuove molti Implementazioni di BouncyCastle algoritmi crittografici precedentemente deprecati, inclusi tutti gli algoritmi AES degli algoritmi. Il sistema utilizza invece Conserva le implementazioni questi algoritmi.

Questa modifica interessa la tua app se si verifica una delle seguenti condizioni:

  • L'app utilizza dimensioni della chiave a 512 bit. Conscrypt non supporta questa dimensione della chiave. Se necessario, aggiorna la logica di crittografia dell'app in modo da utilizzare chiavi di dimensioni diverse.

  • La tua app utilizza dimensioni della chiave non valide con KeyGenerator. L'implementazione di Conscrypt KeyGenerator esegue anche dei parametri chiave, rispetto a BouncyCastle. Ad esempio, Conscrypt non consente alla tua app di generare una chiave AES a 64 bit perché AES supporta solo Chiavi a 128, 192 e 256 bit.

    BouncyCastle consente di generare chiavi di dimensioni non valide, ma in seguito non riesce se queste chiavi vengono utilizzate con una Cipher. Prima la crittografia non riesce.

  • Inizializzi le crittografie Galois/Counter Mode (GCM) utilizzando una dimensione diversa più di 12 byte. L'implementazione di Conscrypt GcmParameterSpec richiede un'istanza l'inizializzazione di 12 byte, consigliata dal NIST.

Notifiche di accesso agli appunti

Su Android 12 e versioni successive, quando un'app chiama getPrimaryClip() per accedere ai dati dei clip da un per la prima volta, un messaggio popup invia una notifica all'utente dell'accesso agli appunti.

Il testo all'interno del messaggio toast contiene il seguente formato: APP pasted from your clipboard.

Informazioni sul testo nella descrizione del clip

Su Android 12 e versioni successive, getPrimaryClipDescription() può rilevare i seguenti dettagli:

Le app non possono chiudere le finestre di dialogo di sistema

Per migliorare il controllo degli utenti durante l'interazione con le app e il sistema, la ACTION_CLOSE_SYSTEM_DIALOGS L'azione intent è stata ritirata a partire da Android 12. Tranne alcuni speciali, quando la tua app tenta di richiamare un intent che contiene questa azione, il sistema esegue una delle seguenti operazioni in base alla versione dell'SDK target della tua app:

  • Se la tua app ha come target Android 12 o versioni successive, una SecurityException.

  • Se la tua app ha come target Android 11 (livello API 30) o versioni precedenti, l'intent non eseguire e il seguente messaggio apparirà Logcat:

    E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.

Eccezioni

Nei seguenti casi, un'app può comunque chiudere le finestre di dialogo di sistema su Android 12 o versioni successive:

  • La tua app esegue una strumentazione test.

  • La tua app ha come target Android 11 o versioni precedenti e mostra una finestra che si trova sopra la notifica riquadro a scomparsa.

  • La tua app ha come target Android 11 o versioni precedenti. Inoltre, l'utente ha ha interagito con una notifica, utilizzando possibilmente l'azione della notifica pulsanti e la tua app elaborazione di un servizio o trasmissione ricevente in risposta all'azione dell'utente.

  • La tua app ha come target Android 11 o versioni precedenti e ha uno stato attivo servizio di accessibilità. Se la tua app ha come target Android 12 e vuole chiudere la barra delle notifiche, usa il GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE l'azione di accessibilità.

Gli eventi tocco non attendibili sono bloccati

Per preservare la sicurezza del sistema e una buona esperienza utente, Android 12 impedisce alle app di utilizzare le funzioni touch eventi in cui un overlay oscura l'app in modo non sicuro. In altre parole, il sistema blocca i tocchi che passano attraverso determinate finestre, con alcune eccezioni.

App interessate

Questa modifica interessa le app che scelgono di consentire il passaggio attraverso le finestre, ad esempio usando FLAG_NOT_TOUCHABLE flag. Alcuni esempi, senza alcuna limitazione, sono:

Eccezioni

Nei seguenti casi, "passthrough" tocchi consentiti:

  • Interazioni all'interno dell'app. La tua app mostra l'overlay e l'overlay appare solo quando l'utente interagisce con l'app.

  • Finestre attendibili. Queste finestre includono, a titolo esemplificativo, il seguenti:

    di Gemini Advanced.

  • Finestre invisibili. La vista principale della finestra è GONE oppure INVISIBLE.

  • Finestre completamente trasparenti. La Proprietà alpha è 0,0 per la finestra.

  • Finestre di avviso di sistema sufficientemente traslucide. Il sistema considera un insieme delle finestre di avviso di sistema in modo che siano sufficientemente traslucide in caso di opacità combinata è inferiore o uguale all'opacità massima di occultamento del sistema per i tocchi. In Android 12, l'opacità massima è pari a 0,8 per impostazione predefinita.

Rileva quando un tocco non attendibile viene bloccato

Se un'azione tocco viene bloccata dal sistema, Logcat registra il seguente messaggio:

Untrusted touch due to occlusion by PACKAGE_NAME

Testa la modifica

I tocchi non attendibili sono bloccati per impostazione predefinita sui dispositivi con Android 12 o versioni successive. Per consentire i tocchi non attendibili, esegui il seguente comando ADB in una finestra del terminale:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

Per ripristinare il comportamento predefinito (i tocchi non attendibili sono bloccati), esegui lo seguente comando:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Ciclo di vita dell'attività

Le attività di Avvio applicazioni non vengono più terminate con la pressione indietro

Android 12 cambia la gestione predefinita del sistema Premi Indietro in Avvio app di quelle che sono alla base delle loro attività. Nelle versioni precedenti, il sistema finirebbe queste attività con la pressione sul retro. In Android 12, il sistema si sposta l'attività e la sua attività in background anziché completarla. Il nuovo comportamento corrisponde a quello attuale quando esci da un'app usando il pulsante Home o il gesto.

Per la maggior parte delle app, questa modifica significa che gli utenti che usano Indietro per uscire di riprendere più rapidamente lo stato caldo delle app, anziché dover riavviare completamente l'app da un stato freddo.

Ti consigliamo di testare le tue app con questa modifica. Se la tua app al momento sostituisce onBackPressed() per gestire Torna alla navigazione a ritroso e completa la Activity, aggiorna l'implementazione per chiamare fino a super.onBackPressed() anziché alla fine. Chiamata in corso super.onBackPressed() sposta l'attività e la relativa attività in background quando siano appropriati e offrano un'esperienza di navigazione più coerente tra le app.

Inoltre, tieni presente che, in generale, consigliamo di utilizzare le API AndroidX Activity per offrendo una navigazione a ritroso personalizzata, anziché eseguire l'override di onBackPressed(). API AndroidX Activity automaticamente il comportamento del sistema se non sono presenti componenti che intercettano il sistema Back press.

Elementi grafici e immagini

Miglioramento del cambio della frequenza di aggiornamento

In Android 12, la frequenza di aggiornamento cambia utilizzando setFrameRate() può verificarsi a prescindere dal fatto che il display supporti una transizione fluida la nuova frequenza di aggiornamento; una transizione perfetta è quella senza immagini interruzioni, ad esempio lo schermo nero per un secondo o due. In precedenza, se il display non supportava una transizione fluida, in genere continuava a utilizzare la stessa frequenza di aggiornamento dopo la chiamata di setFrameRate(). Puoi determinare avanzare se la transizione al nuovo aggiornamento probabilmente avverrà senza problemi chiamata al numero getAlternativeRefreshRates(). In genere, il callback onDisplayChanged() viene richiamata dopo il completamento dell'opzione di frequenza di aggiornamento, ma per alcuni collegati esternamente, viene chiamato durante una transizione fluida.

Ecco un esempio di come implementare questa funzionalità:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Java

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Connettività

Aggiornamenti passpoint

In Android 12 vengono aggiunte le seguenti API:

  • isPasspointTermsAndConditionsSupported(): Termini e condizioni è un passpoint che consente alle implementazioni di rete di sostituire i captive portal non sicuri, che usano reti aperte, con una rete Passpoint sicura. La notifica è mostrati all'utente quando è necessario accettare termini e condizioni. App che suggeriscono reti Passpoint controllate da Termini e condizioni deve prima chiamare questa API per assicurarsi che il dispositivo supporti la funzionalità. Se il dispositivo non supporta questa funzionalità, non potrà connettersi a questa rete ed è necessario suggerire una rete alternativa o legacy.

  • isDecoratedIdentitySupported(): Quando esegui l'autenticazione sulle emittenti con una decorazione del prefisso, il prefisso di identità consente agli operatori di rete di aggiornare l'accesso alla rete identificatore (NAI) per eseguire il routing esplicito attraverso più proxy all'interno di una rete AAA (vedi RFC 7542 per di più al riguardo).

    Android 12 implementa questa funzionalità in conformità alla specifica WBA per PPS-MO . Le app che suggeriscono reti Passpoint che richiedono un'identità dichiarata devono chiama prima questa API per assicurarti che il dispositivo supporti la funzionalità. Se il dispositivo non supporta la funzionalità, l'identità non verrà modificata e l'autenticazione sulla rete potrebbe non riuscire.

Per creare un suggerimento di Passpoint, le app devono utilizzare la PasspointConfiguration, Credential e HomeSp corsi. Questi Queste classi descrivono il profilo Passpoint, definito in Wi-Fi Alliance Passpoint la specifica del prodotto.

Per ulteriori informazioni, vedi API di suggerimento Wi-Fi per la connettività a internet.

Limitazioni aggiornate relative all'interfaccia non SDK

Android 12 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 12, alcune di queste modifiche potrebbero non riguardarti immediatamente. Tuttavia, sebbene al momento tu possa utilizzare interfacce non SDK (a seconda del livello 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 12. Per scoprire di più sulle interfacce non SDK in generale, consulta Restrizioni relative alle interfacce non SDK di archiviazione.