Modifiche al comportamento: tutte le app

La piattaforma Android 12 include modifiche al comportamento che potrebbero influire sulla tua app. Le seguenti modifiche al comportamento si applicano a tutte le app quando vengono eseguite su Android 12, indipendentemente da targetSdkVersion. Devi testare la tua app e poi modificarla in base alle esigenze per supportare correttamente questi elementi, ove applicabile.

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

Esperienza utente

Effetto overscroll elastico

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

Su Android 11 e versioni precedenti, un evento di overscroll fa sì che gli elementi visivi abbiano un bagliore; su Android 12 e versioni successive, gli elementi visivi si allungano e rimbalzano in un evento di trascinamento e si lanciano e rimbalzano in un evento di scorrimento rapido.

Per saperne di più, 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, devi eseguire la migrazione dell'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à degradata o indesiderata.

Per istruzioni, consulta Migrare l'implementazione della schermata iniziale esistente ad Android 12.

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

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

Risoluzione degli intent web

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

Le app possono ottenere questa approvazione eseguendo una delle seguenti operazioni:

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

Miglioramenti della modalità immersiva per la navigazione tramite gesti

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

Display#getRealSize e getRealMetrics: ritiro e vincoli

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

In Android 12 continuiamo a consigliare l'utilizzo di WindowMetrics e stiamo ritirando questi metodi:

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

Le app devono utilizzare le API WindowMetrics per eseguire query sui limiti della finestra e Configuration.densityDpi per eseguire query sulla densità corrente.

Per una compatibilità più ampia 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 utilizzo di WindowMetrics

Innanzitutto, assicurati che le attività della tua app siano completamente ridimensionabili.

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

Se la tua app crea un MediaProjection, i limiti devono essere dimensionati 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 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'istanza WindowContext e recuperare WindowMetrics dei limiti dell'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 rende la modalità multi-finestra un comportamento standard.

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 adattarsi alle dimensioni del display.

Sugli schermi piccoli (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 multi-finestra.

Anteprima della videocamera su schermi grandi

Le app della fotocamera in genere presuppongono una relazione fissa tra l'orientamento del dispositivo e le proporzioni dell'anteprima della fotocamera. Tuttavia, i fattori di forma con schermi di grandi dimensioni, come i dispositivi pieghevoli, e le modalità di visualizzazione come la modalità multi-finestra e multi-display, mettono in discussione questo presupposto.

Su Android 12, le app fotocamera che richiedono un orientamento dello schermo specifico e non sono ridimensionabili (resizeableActivity="false") entrano automaticamente in modalità ritratto in miniatura, che garantisce l'orientamento e le proporzioni corretti dell'anteprima della fotocamera. Su dispositivi pieghevoli e altri dispositivi con un livello di astrazione hardware (HAL) della fotocamera, 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 modo che corrisponda alle proporzioni dell'anteprima della fotocamera dell'app. Il ritaglio e la rotazione aggiuntiva garantiscono una corretta presentazione dell'anteprima della videocamera indipendentemente dall'orientamento del dispositivo e dallo stato piegato o aperto del dispositivo.

Ritardo dell'esperienza utente per le notifiche dei servizi in primo piano

Per offrire un'esperienza semplificata per i servizi in primo piano a esecuzione breve, i dispositivi con Android 12 o versioni successive possono ritardare la visualizzazione delle notifiche dei servizi in primo piano di 10 secondi, con alcune eccezioni. Questa modifica consente alle attività di breve durata di essere completate prima che vengano visualizzate le notifiche.

Prestazioni

Bucket di standby delle app con limitazioni

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

  1. Attiva: l'app è in uso o è stata utilizzata di recente.
  2. Set di lavoro: l'app viene utilizzata regolarmente.
  3. Frequente: l'app viene utilizzata spesso, ma non tutti i giorni.
  4. Raro: l'app non viene utilizzata di frequente.
  5. Limitato: l'app consuma molte risorse di sistema o potrebbe mostrare un comportamento indesiderato.

Il sistema prende in considerazione il comportamento della tua app, oltre ai modelli di utilizzo, per decidere se inserirla nel bucket con limitazioni.

È 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 inserisce la tua app in un bucket meno 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 limitazioni.

Testare il comportamento del bucket con accesso limitato

Per testare il comportamento dell'app quando il sistema la inserisce nel bucket con limitazioni, puoi spostarla manualmente in questo bucket. Per farlo, esegui questo comando in una finestra del terminale:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Posizione in primo piano e risparmio energetico

A partire da Android 12, la posizione in primo piano (incluso da un servizio in primo piano) può continuare a essere fornita mentre il risparmio energetico è attivo, anche quando lo schermo è spento.

In precedenza, la modalità Risparmio energetico interrompeva gli aggiornamenti della posizione quando lo schermo era spento. Questa modifica consente una migliore durata della batteria per gli utenti e significa che gli sviluppatori possono astenersi dal chiedere agli utenti di disattivare il risparmio energetico per garantire le consegne della posizione.

Le app che richiedono la posizione tramite un servizio in primo piano devono seguire questi passaggi:

  1. Chiama getLocationPowerSaverMode() per verificare il comportamento delle funzionalità di localizzazione del dispositivo quando è attivo il risparmio energetico.
  2. Se viene restituito LOCATION_MODE_FOREGROUND_ONLY, la tua app continuerà a ricevere aggiornamenti della posizione mentre è in primo piano o esegue un servizio in primo piano mentre il risparmio energetico è attivo e lo schermo è spento.

Sicurezza e privacy

Posizione approssimativa

La finestra di dialogo ha due gruppi di opzioni, uno sopra l&#39;altro
Figura 1. Finestra di dialogo delle autorizzazioni di sistema che consente all'utente di concedere informazioni sulla 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 richiedere anche l'autorizzazione ACCESS_COARSE_LOCATION per gestire il caso in cui l'utente conceda l'accesso alla posizione approssimativa alla tua app. Devi includere entrambe le autorizzazioni in un'unica 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 precise sulla posizione.
  • Approssimativa: fornisce l'accesso solo 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 sola opzione di attivazione/disattivazione. Gli utenti possono accedere alle opzioni attivabili/disattivabili da Impostazioni rapide, come mostrato nella figura 1, o dalla schermata Privacy nelle impostazioni di sistema.

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

Indicatori di 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.

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

Visibilità del pacchetto di autorizzazioni

Sui dispositivi che eseguono Android 12 o versioni successive, le app che hanno come target Android 11 (livello API 30) o versioni successive e che chiamano uno dei seguenti metodi ricevono un insieme filtrato di risultati, in base alla visibilità dei pacchetti dell'app in altre app:

Implementazione BouncyCastle rimossa

Android 12 rimuove molte implementazioni di BouncyCastle di algoritmi crittografici precedentemente ritirati, 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 di 512 bit. Conscrypt non supporta questa dimensione della chiave. Se necessario, aggiorna la logica di crittografia della tua app per utilizzare dimensioni delle chiavi diverse.

  • La tua app utilizza dimensioni delle chiavi non valide con KeyGenerator. L'implementazione di Conscrypt di KeyGenerator esegue una convalida aggiuntiva 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 un secondo momento non funziona se queste chiavi vengono utilizzate con un Cipher. Conscrypt non riesce a eseguire l'operazione.

  • Inizializzi le cifrature Galois/Counter Mode (GCM) utilizzando una dimensione diversa da 12 byte. L'implementazione di Conscrypt di GcmParameterSpec richiede un'inizializzazione di 12 byte, come consigliato dal NIST.

Notifiche di accesso agli appunti

Su Android 12 e versioni successive, quando un'app chiama getPrimaryClip() per accedere ai dati degli appunti da un'altra app per la prima volta, un messaggio toast notifica all'utente questo accesso agli appunti.

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

Informazioni sul testo nella descrizione della 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, l'azione intent ACTION_CLOSE_SYSTEM_DIALOGS è stata ritirata a partire da Android 12. Ad eccezione di alcuni casi 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 target dell'SDK della tua app:

  • Se la tua app ha come target Android 12 o versioni successive, si verifica un 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 esegue un test di strumentazione.

  • La tua app ha come target Android 11 o versioni precedenti e mostra una finestra sopra il riquadro delle notifiche.

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

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

Gli eventi touch non attendibili vengono bloccati

Per preservare la sicurezza del sistema e una buona esperienza utente, Android 12 impedisce alle app di consumare eventi tocco in cui una sovrapposizione 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 dei tocchi attraverso le proprie finestre, ad esempio utilizzando il flag FLAG_NOT_TOUCHABLE. Di seguito sono riportati alcuni esempi:

  • Overlay che richiedono l'autorizzazione SYSTEM_ALERT_WINDOW, come le finestre che utilizzano TYPE_APPLICATION_OVERLAY e utilizzano il flag FLAG_NOT_TOUCHABLE.
  • Finestre di attività che utilizzano il flag FLAG_NOT_TOUCHABLE.

Eccezioni

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

  • Interazioni all'interno dell'app.L'app mostra l'overlay, che viene visualizzato solo quando l'utente interagisce con l'app.

  • Finestre attendibili. Queste finestre includono (a titolo esemplificativo):

  • Finestre invisibili. La visualizzazione radice 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 di sistema sufficientemente traslucide quando l'opacità combinata è inferiore o uguale all'opacità di oscuramento massima del sistema per i tocchi. In Android 12, questa opacità massima è 0,8 per impostazione predefinita.

Rileva quando viene bloccato un tocco non attendibile

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

Untrusted touch due to occlusion by PACKAGE_NAME

Testare la modifica

I tocchi non attendibili vengono 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 vengono bloccati), esegui il 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 principale non vengono più completate quando si preme Indietro

Android 12 modifica la gestione predefinita della pressione del tasto Indietro di sistema nelle attività del launcher che si trovano alla radice delle relative attività. Nelle versioni precedenti, il sistema terminava queste attività alla pressione del tasto Indietro. In Android 12, il sistema sposta l'attività e il relativo task in background anziché terminarla. Il nuovo comportamento corrisponde a quello attuale quando si esce da un'app utilizzando il pulsante Home o il gesto.

Per la maggior parte delle app, questa modifica significa che gli utenti che utilizzano il pulsante Indietro per uscire dalla tua app possono riprenderla più rapidamente da uno stato caldo, anziché doverla riavviare completamente da uno stato freddo.

Ti consigliamo di testare le tue app con questa modifica. Se la tua app attualmente esegue l'override di onBackPressed() per gestire la navigazione indietro e completare Activity, aggiorna l'implementazione per chiamare super.onBackPressed() anziché completare. Chiamata super.onBackPressed() sposta l'attività e il relativo compito 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 indietro personalizzata, anziché eseguire l'override di onBackPressed(). Le API AndroidX Activity rimandano automaticamente al comportamento di sistema appropriato se non sono presenti componenti che intercettano la pressione del tasto Indietro del sistema.

Grafici e immagini

Miglioramento del cambio della frequenza di aggiornamento

In Android 12, le modifiche della frequenza di aggiornamento tramite setFrameRate() possono verificarsi indipendentemente dal fatto che il display supporti una transizione senza interruzioni alla nuova frequenza di aggiornamento. Una transizione senza interruzioni è una transizione che non presenta interruzioni visive, ad esempio una schermata nera per uno o due secondi. 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 in anticipo se la transizione al nuovo aggiornamento sarà probabilmente senza problemi chiamando il numero getAlternativeRefreshRates(). In genere, il callback onDisplayChanged() viene chiamato al termine del cambio della frequenza di aggiornamento, ma per alcuni display collegati esternamente, viene chiamato durante una transizione non fluida.

Ecco un esempio di come potresti 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 di Passpoint

In Android 12 vengono aggiunte le seguenti API:

  • isPasspointTermsAndConditionsSupported(): Termini e condizioni è una funzionalità Passpoint che consente alle implementazioni di rete di sostituire i captive portal non sicuri, che utilizzano reti aperte, con una rete Passpoint sicura. All'utente viene mostrata una notifica quando è necessario accettare i Termini e condizioni. Le app che suggeriscono reti Passpoint protette da termini e condizioni devono chiamare prima questa API per assicurarsi che il dispositivo supporti la funzionalità. Se il dispositivo non supporta la funzionalità, non sarà in grado di connettersi a questa rete e deve essere suggerita una rete alternativa o legacy.

  • isDecoratedIdentitySupported(): Quando si esegue l'autenticazione alle reti con una decorazione del prefisso, il prefisso dell'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 (vedi RFC 7542 per ulteriori informazioni).

    Android 12 implementa questa funzionalità in conformità con la specifica WBA per le estensioni PPS-MO. Le app che suggeriscono reti Passpoint che richiedono un'identità decorata 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 alla rete potrebbe non riuscire.

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

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

Limitazioni aggiornate relative alle interfacce non SDK

Android 12 include elenchi aggiornati di interfacce non SDK con limitazioni basati 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 12, alcune di queste modifiche potrebbero non interessarti immediatamente. 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 con certezza se la tua app utilizza interfacce non SDK, puoi testarla per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare una migrazione ad alternative SDK. Tuttavia, ci rendiamo conto 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 scoprire di più sulle modifiche apportate a 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 Limitazioni relative alle interfacce non SDK.