Modifiche del comportamento: tutte le app

La piattaforma Android 12 include modifiche del comportamento che potrebbero influire sulla tua app. Le seguenti modifiche del comportamento si applicano a tutte le app quando vengono eseguite su Android 12, indipendentemente da targetSdkVersion. Ti consigliamo di testare l'app e di modificarla in base alle esigenze per supportarle correttamente, ove applicabile.

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

Esperienza utente

Effetto Estendi overscroll

Sui dispositivi con Android 12 e versioni successive, il comportamento visivo per gli eventi di scorrimento orizzontale cambia.

Su Android 11 e versioni precedenti, un evento di scorrimento orizzontale fa brillare gli elementi visivi; su Android 12 e versioni successive, gli elementi visivi si allungano e si rimuovono da un evento di trascinamento, che poi si tirano indietro e si rimbalzano contro un evento fling.

Per ulteriori informazioni, consulta la guida all'animazione dei gesti di scorrimento.

Schermate iniziali delle app

Se in precedenza hai implementato una schermata iniziale personalizzata in Android 11 o versioni precedenti, dovrai eseguire la migrazione della tua app all'API SplashScreen per assicurarti che venga visualizzata correttamente a partire da Android 12. Se non esegui la migrazione dell'app, l'esperienza di avvio dell'app sarà ridotta o involontaria.

Per le istruzioni, consulta Eseguire la migrazione dell'implementazione esistente della schermata iniziale ad Android 12.

Inoltre, a partire da Android 12, il sistema applica sempre la nuova schermata iniziale predefinita di sistema Android su a freddo e avvii tiepidi per tutte le app. Per impostazione predefinita, questa schermata iniziale predefinita di sistema viene creata utilizzando l'elemento icona in Avvio applicazioni dell'app e windowBackground del tema (se è di un solo colore).

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

Risoluzione dell'intent web

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

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

• Verifica il dominio utilizzando Android App Links.

  Sulle app destinate ad Android 12 o versioni successive, il sistema cambia la modalità di verifica automatica dei link per app Android della tua app. Nei filtri intent dell'app, verifica di includere la categoria BROWSABLE e di supportare lo schema https.

  Su Android 12 o versioni successive, puoi verificare manualmente i link per app Android della tua app per verificare in che modo questa logica aggiornata influisce sulla tua app.

• Richiedi all'utente di associare la tua app al dominio nelle impostazioni di sistema.

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

Miglioramenti alla modalità immersiva per la navigazione tramite gesti

Android 12 raggruppa il comportamento esistente per consentire agli utenti di eseguire più facilmente i comandi di navigazione tramite gesti in modalità immersiva. Inoltre, Android 12 fornisce comportamento di compatibilità con le versioni precedenti per la modalità immersiva fissa.

Display#getRealSize e getRealMetrics: ritiro e vincoli

I dispositivi Android sono disponibili in molti fattori di forma, come schermi di grandi dimensioni, tablet e pieghevoli. Per visualizzare correttamente i contenuti per ogni dispositivo, la tua app deve determinare le dimensioni dello schermo o del display. Nel corso del tempo, Android ha fornito API diverse per il recupero di queste informazioni. In Android 11, abbiamo introdotto l'API WindowMetrics e ritirato i seguenti metodi:

• Display.getSize()
• Display.getMetrics()

In Android 12 continueremo a consigliare l'utilizzo di WindowMetrics e ritireremo questi metodi:

• Display.getRealSize()
• Display.getRealMetrics()

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

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

Per una maggiore compatibilità con le versioni precedenti di Android, puoi utilizzare la libreria Jetpack WindowManager, che include una classe 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à dovrebbe basarsi su WindowMetrics in un contesto di attività per qualsiasi lavoro correlato alla UI, in particolare WindowManager.getCurrentWindowMetrics() o WindowMetricsCalculator.computeCurrentWindowMetrics() di Jetpack.

Se l'app crea un MediaProjection, i limiti devono essere ridimensionati correttamente poiché la proiezione acquisisce la partizione di visualizzazione in cui è in esecuzione l'app del proiettore.

Se l'app è completamente ridimensionabile, il contesto dell'attività restituisce i limiti corretti, ad esempio:

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

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

Se l'app non è completamente ridimensionabile, deve eseguire una query da un'istanza WindowContext e recuperare il WindowMetrics dei limiti delle attività utilizzando WindowManager.getMaximumWindowMetrics() o il metodo Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().

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

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 adotta 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 loro configurazione. Se resizeableActivity="false", l'app viene attivata in modalità di compatibilità quando necessario per adattarsi alle dimensioni del display.

Su schermi di piccole dimensioni (sw < 600 dp), il sistema controlla minWidth e minHeight di un'attività per determinare se può essere eseguita in modalità multi-finestra. Se resizeableActivity="false", l'app non può essere eseguita in modalità multi-finestra, indipendentemente dalla larghezza e dall'altezza minime.

Per ulteriori informazioni, vedi Supporto della modalità multi-finestra.

Anteprima della videocamera su schermi grandi

Le app per fotocamera in genere presuppongono una relazione fissa tra l'orientamento del dispositivo e le proporzioni dell'anteprima della fotocamera. Tuttavia, i fattori di forma degli schermi di grandi dimensioni, come i dispositivi pieghevoli e le modalità di visualizzazione come multi-finestra e multi-display, sfidano questa ipotesi.

Su Android 12, le app della fotocamera che richiedono un orientamento specifico dello schermo e non sono ridimensionabili (resizeableActivity="false") entrano automaticamente nella modalità verticale integrata, che garantisce l'orientamento e le proporzioni corretti dell'anteprima della fotocamera. Sui pieghevoli e su altri dispositivi con un livello di astrazione hardware della fotocamera (HAL), viene applicata una rotazione aggiuntiva all'output della fotocamera per compensare l'orientamento del sensore della fotocamera e l'output della fotocamera viene ritagliato in base alle proporzioni dell'anteprima della fotocamera dell'app. Il ritaglio e la rotazione aggiuntiva assicurano una corretta presentazione dell'anteprima della fotocamera indipendentemente dall'orientamento e dallo stato del dispositivo aperto o piegato.

Ritardo UX per le notifiche del servizio in primo piano

Per offrire un'esperienza semplificata per i servizi in primo piano a breve esecuzione, i dispositivi che eseguono Android 12 o versioni successive possono ritardare di 10 secondi la visualizzazione delle notifiche dei servizi in primo piano, con alcune eccezioni. Questa modifica offre la possibilità di completare attività di breve durata prima della visualizzazione delle relative notifiche.

Esibizione

Bucket standby delle app limitato

Android 11 (livello API 30) ha introdotto il bucket con restrizioni come bucket di standby delle app. A partire da Android 12, questo bucket è attivo per impostazione predefinita. Il bucket limitato ha la priorità più bassa (e le restrizioni più alte) tra tutti i bucket. I bucket in ordine di priorità da alta a bassa sono:

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

Il sistema prende in considerazione il comportamento della tua app, oltre ai pattern di utilizzo, per decidere se inserirlo nel bucket limitato.

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

Controlla se la tua app si trova nel bucket limitato

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

Testa il comportamento del bucket limitato

Per verificare il comportamento della tua app quando il sistema la inserisce nel bucket con restrizioni, puoi spostare manualmente l'app in quel bucket. Per farlo, esegui questo comando in una finestra del terminale:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Sicurezza e privacy

Posizione approssimativa

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

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

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

• Precisa: fornisce l'accesso a informazioni sulla posizione esatta.
• Approssimativa: fornisce l'accesso soltanto alle 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 premendo una singola opzione di attivazione/disattivazione. Gli utenti possono accedere alle opzioni attivabili dalle Impostazioni rapide, come mostrato nella Figura 1, o dalla schermata Privacy nelle impostazioni di sistema.

Scopri di più su questi attivazioni e su come verificare che la tua app rispetti le best practice relative alle autorizzazioni di CAMERA e RECORD_AUDIO.

Indicatori microfono e fotocamera

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

Scopri di più su questi indicatori e su come verificare che la tua app segua le best practice relative alle autorizzazioni CAMERA e RECORD_AUDIO.

Visibilità del pacchetto di autorizzazioni

Sui dispositivi con Android 12 o versioni successive, le app destinate ad Android 11 (livello API 30) o versioni successive che chiamano uno dei metodi indicati di seguito ricevono un insieme filtrato di risultati in base alla visibilità dei pacchetti delle app nelle altre app:

• getAllPermissionGroups()
• getPermissionGroupInfo()
• getPermissionInfo()
• queryPermissionsByGroup()

Implementazione di BouncyCastle rimossa

Android 12 rimuove molte implementazioni BouncyCastle di algoritmi di crittografia precedentemente deprecate, inclusi tutti gli algoritmi AES. Il sistema utilizza invece le implementazioni Conscrypt di questi algoritmi.

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

• La tua app utilizza dimensioni delle chiavi a 512 bit. Conscrypt non supporta questa dimensione della chiave. Se necessario, aggiorna la logica di crittografia dell'app in modo che utilizzi chiavi di dimensioni diverse.

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

  BouncyCastle consente di generare chiavi di dimensioni non valide, ma in seguito non va a buon fine se queste chiavi vengono utilizzate con un elemento Cipher. La crittografia non va a buon fine.

• Inizializziamo le crittografie Galois/Counter Mode (GCM) utilizzando una dimensione diversa da 12 byte. L'implementazione di Conscrypt di GcmParameterSpec richiede un'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'altra app per la prima volta, un messaggio toast comunica all'utente che è stato eseguito l'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:

• Testo stilizzato, utilizzando isStyledText().
• Varie classificazioni di testo, ad esempio URL, utilizzando getConfidenceScore().

Le app non possono chiudere le finestre di dialogo di sistema

Per migliorare il controllo da parte degli utenti durante l'interazione con le app e il sistema, l'azione dell'intent ACTION_CLOSE_SYSTEM_DIALOGS è deprecata a partire da Android 12. Fatta eccezione per alcuni casi speciali, quando l'app cerca di invocare un intent contenente questa azione, il sistema esegue una delle seguenti operazioni in base alla versione dell'SDK target dell'app:

• Se la tua app ha come target Android 12 o versioni successive, si verifica un errore SecurityException.

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

  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 sta eseguendo un test di strumentazione.

• L'app ha come target Android 11 o versioni precedenti e mostra una finestra sopra il cassetto di notifica.

• La tua app ha come target Android 11 o versioni precedenti. Inoltre, l'utente ha interagito con una notifica, probabilmente utilizzando i pulsanti di azione della notifica e l'app sta elaborando un servizio o ricevitore di trasmissione in risposta a questa azione dell'utente.

• La tua app ha come target Android 11 o versioni precedenti e dispone di un servizio di accessibilità attivo. Se la tua app è destinata ad Android 12 e vuole chiudere la barra delle notifiche, utilizza invece l'azione di accessibilità GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.

Gli eventi touch non attendibili sono bloccati

Per preservare la sicurezza del sistema e una buona esperienza utente, Android 12 impedisce alle app di consumare eventi touch in cui un overlay nasconde 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 ai tocchi attraverso le finestre, ad esempio utilizzando il flag FLAG_NOT_TOUCHABLE. Alcuni esempi includono, a titolo esemplificativo:

• Gli overlay che richiedono l'autorizzazione SYSTEM_ALERT_WINDOW, ad esempio le finestre che utilizzano TYPE_APPLICATION_OVERLAY e che utilizzano il flag FLAG_NOT_TOUCHABLE.
• Finestre di attività che utilizzano il flag FLAG_NOT_TOUCHABLE.

Eccezioni

Nei seguenti casi, sono consentiti tocchi "pass-through":

• Interazioni all'interno dell'app: l'overlay viene visualizzato nella tua app, mentre l'overlay viene visualizzato solo quando l'utente interagisce con l'app.

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

  • Finestre Accessibilità
  • Finestre IME (Input Method Editor)
  • Finestre dell'assistente

• Finestre invisibili. La visualizzazione principale della finestra è GONE o INVISIBLE.

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

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

Rileva quando un tocco non attendibile è bloccato

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

Untrusted touch due to occlusion by PACKAGE_NAME

Prova 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 questo 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à dell'Avvio app root non vengono più terminate con la pressione indietro

Android 12 modifica la gestione predefinita del sistema. Premi Indietro nelle attività di Avvio app che sono alla base delle loro attività. Nelle versioni precedenti, il sistema completava queste attività con Indietro. In Android 12, il sistema ora sposta l'attività e la relativa attività in background invece di completarla. Il nuovo comportamento corrisponde al comportamento attuale quando esci da un'app utilizzando il pulsante Home o il gesto.

Per la maggior parte delle app, questa modifica significa che gli utenti che utilizzano Indietro per uscire dall'app possono riprendere più rapidamente l'app da uno stato caldo, anziché dover riavviare completamente l'app da uno stato a freddo.

Ti consigliamo di testare le tue app con questa modifica. Se al momento la tua app esegue l'override di onBackPressed() per gestire la navigazione indietro e completare la Activity, aggiorna l'implementazione in modo da chiamare il numero super.onBackPressed() anziché terminare. La chiamata a super.onBackPressed() sposta l'attività e la relativa attività in background quando opportuno e offre un'esperienza di navigazione più coerente per gli utenti nelle app.

Tieni inoltre presente che, in generale, consigliamo di utilizzare le API AndroidX Activity per fornire una navigazione a ritroso personalizzata, anziché eseguire l'override di onBackPressed(). Le API AndroidX Activity si riferiscono automaticamente al comportamento di sistema appropriato se non sono presenti componenti che intercettano la pressione del sistema.

Grafica e immagini

Cambio della frequenza di aggiornamento migliorato

In Android 12, le variazioni della frequenza di aggiornamento utilizzando setFrameRate() possono verificarsi indipendentemente dal fatto che il display supporti una transizione senza interruzioni alla nuova frequenza di aggiornamento. Una transizione fluida è quella che non presenta interruzioni visive, ad esempio una schermata nera per uno o due secondi. In precedenza, se il display non supportava una transizione senza interruzioni, in genere continuava a utilizzare la stessa frequenza di aggiornamento dopo la chiamata di setFrameRate(). Puoi determinare in anticipo se la transizione al nuovo aggiornamento sarà probabilmente fluida chiamando il numero getAlternativeRefreshRates(). In genere, il callback onDisplayChanged() viene chiamato dopo il completamento dell'opzione della frequenza di aggiornamento, ma per alcuni display collegati esternamente viene chiamato durante una transizione non fluida.

Ecco un esempio di come implementare questa funzionalità:

// 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)

// 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 di Passpoint

In Android 12 vengono aggiunte le seguenti API:

• isPasspointTermsAndConditionsSupported(): Termini e condizioni è una funzionalità di Passpoint che consente ai deployment di rete di sostituire i captive portal non sicuri, che utilizzano reti aperte, con una rete Passpoint sicura. Quando termini e condizioni devono essere accettati, viene visualizzata una notifica all'utente. Le app che suggeriscono reti Passpoint controllate da termini e condizioni devono 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 reti con un prefisso, il prefisso di identità decorato consente agli operatori di rete di aggiornare l'identificatore di accesso alla rete (NAI) per eseguire il routing esplicito tramite più proxy all'interno di una rete AAA (per ulteriori informazioni, consulta il documento RFC 7542).

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

Per creare un suggerimento di Passpoint, le app devono utilizzare le classi PasspointConfiguration, Credential e HomeSp. Queste classi descrivono il profilo Passpoint, definito nella specifica Passpoint di Wi-Fi Alliance.

Per ulteriori informazioni, consulta la pagina relativa all'API di suggerimento Wi-Fi per la connettività a internet.

Limitazioni aggiornate per le interfacce non SDK

Android 12 include elenchi aggiornati di interfacce non SDK limitate in base alla collaborazione con gli sviluppatori Android e ai test interni più recenti. Quando possibile, ci assicuriamo che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.

Se la tua app non è destinata ad Android 12, alcune di queste modifiche potrebbero non essere applicabili immediatamente. Tuttavia, anche se al momento puoi utilizzare alcune interfacce non SDK (a seconda del livello API target della tua app), l'utilizzo di metodi o campi non SDK comporta sempre un rischio elevato di danneggiare la tua app.

Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare l'app per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare una migrazione alle alternative SDK. Ciononostante, siamo consapevoli 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 Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 12. Per scoprire di più sulle interfacce non SDK in generale, consulta Restrizioni sulle interfacce non SDK.