Modifiche del comportamento: app che hanno come target Android 12

Come nelle release precedenti, Android 12 include modifiche del comportamento che potrebbero interessare la tua app. Le seguenti modifiche del comportamento si applicano esclusivamente alle app che hanno come target Android 12 o versioni successive. Se la tua app ha come target Android 12, devi modificarla per supportare correttamente questi comportamenti, ove applicabile.

Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano tutte le app in esecuzione su Android 12.

Esperienza utente

Notifiche personalizzate

Android 12 modifica l'aspetto e il comportamento delle notifiche completamente personalizzate. In precedenza, le notifiche personalizzate potevano utilizzare l'intera area di notifica e fornire i propri layout e stili. Ciò causava comportamenti anti-pattern che potevano confondere gli utenti o causare problemi di compatibilità del layout su dispositivi diversi.

Per le app destinate ad Android 12, le notifiche con visualizzazioni dei contenuti personalizzate non utilizzeranno più l'area di notifica completa; il sistema applica invece un modello standard. Questo modello garantisce che le notifiche personalizzate abbiano la stessa decorazione delle altre notifiche in tutti gli stati, ad esempio l'icona e gli inviti di espansione della notifica (nello stato compresso) e l'icona, il nome dell'app e l'invito compressione della notifica (nello stato di espansione). Questo comportamento è quasi identico a quello di Notification.DecoratedCustomViewStyle.

In questo modo, Android 12 rende tutte le notifiche visivamente coerenti e facili da scansionare, con un'espansione delle notifiche rilevabile e familiare per gli utenti.

L'illustrazione seguente mostra una notifica personalizzata nel modello standard:

I seguenti esempi mostrano come verrebbero visualizzate le notifiche personalizzate in stato compresso ed espanso:

La modifica in Android 12 interessa le app che definiscono sottoclassi personalizzate di Notification.Style o che utilizzano i metodi di Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) e setCustomHeadsUpContentView(RemoteViews).

Se la tua app utilizza notifiche completamente personalizzate, ti consigliamo di eseguire il test con il nuovo modello appena possibile.

  1. Attiva la modifica delle notifiche personalizzate:

    1. Cambia il targetSdkVersion dell'app in S per attivare il nuovo comportamento.
    2. Ricompila.
    3. Installa la tua app su un dispositivo o un emulatore con Android 12.

  2. Testa tutte le notifiche che utilizzano visualizzazioni personalizzate, assicurandoti che abbiano l'aspetto previsto nell'area. Durante il test, tieni conto di queste considerazioni e apporta le modifiche necessarie:

    • Le dimensioni delle visualizzazioni personalizzate sono cambiate. In generale, l'altezza prevista per le notifiche personalizzate è inferiore rispetto a prima. Nello stato compresso, l'altezza massima dei contenuti personalizzati è diminuita da 106 dp a 48 dp. Inoltre, lo spazio orizzontale è ridotto.

    • Tutte le notifiche sono espandibili per le app destinate ad Android 12. In genere, questo significa che se utilizzi setCustomContentView, ti consigliamo di utilizzare anche setBigCustomContentView per assicurarti che gli stati compressi ed espansi siano coerenti.

    • Per assicurarti che lo stato "Avviso" venga visualizzato come previsto, non dimenticare di aumentare l'importanza del canale di notifica impostandola su "ALTO" (poppa sullo schermo).

Nelle app destinate ad Android 12 o versioni successive, il sistema apporta diverse modifiche alla modalità di verifica dei link per app Android. Queste modifiche migliorano l'affidabilità dell'esperienza di collegamento delle app e forniscono un maggiore controllo agli sviluppatori di app e agli utenti finali.

Se ti affidi alla verifica di Android App Link per aprire i link web nella tua app, assicurati di utilizzare il formato corretto quando aggiungi filtri per intent per la verifica di Link per app Android. In particolare, assicurati che questi filtri per intent includano la categoria BROWSABLE e supportino lo schema https.

Puoi anche verificare manualmente i link dell'app per testare l'affidabilità delle tue dichiarazioni.

Miglioramenti del comportamento di Picture in picture

Android 12 introduce miglioramenti del comportamento per la modalità Picture in picture (PIP) e miglioramenti estetici consigliati alle animazioni di transizione sia per la navigazione tramite gesti che per la navigazione basata su elementi.

Per ulteriori informazioni, consulta la sezione Miglioramenti alla funzionalità Picture in picture.

Nuovo design di Toast

In Android 12, la visualizzazione toast è stata riprogettata. I toast sono ora limitati a due righe di testo e mostrano l'icona dell'applicazione accanto al testo.

Immagine di un dispositivo Android che mostra un popup toast con la scritta "Invio di messaggio in corso" accanto all'icona di un'app

Per ulteriori dettagli, consulta Panoramica dei toast.

Sicurezza e privacy

Posizione approssimativa

Sui dispositivi con Android 12 o versioni successive, gli utenti possono richiedere la precisione della posizione approssimativa per la tua app.

Cookie SameSite moderni in WebView

Il componente WebView di Android è basato su Chromium, il progetto open source alla base del browser Chrome di Google. Chromium ha introdotto modifiche alla gestione dei cookie di terze parti per offrire maggiore sicurezza e privacy e offrire agli utenti maggiore trasparenza e controllo. A partire da Android 12, queste modifiche sono incluse anche in WebView se le app hanno come target Android 12 (livello API 31) o versioni successive.

L'attributo SameSite di un cookie controlla se può essere inviato con qualsiasi richiesta o solo con richieste dallo stesso sito. Le seguenti modifiche relative alla protezione della privacy migliorano la gestione predefinita dei cookie di terze parti e contribuiscono alla protezione da condivisione involontaria tra siti:

  • I cookie senza un attributo SameSite vengono trattati come SameSite=Lax.
  • I cookie con SameSite=None devono specificare anche l'attributo Secure, il che significa che richiedono un contesto sicuro e devono essere inviati tramite HTTPS.
  • I link tra le versioni HTTP e HTTPS di un sito ora vengono trattati come richieste tra siti, quindi i cookie non vengono inviati a meno che non siano contrassegnati correttamente come SameSite=None; Secure.

Per gli sviluppatori, le linee guida generali prevedono l'identificazione delle dipendenze dei cookie tra siti nei flussi utente critici e la garanzia che l'attributo SameSite sia impostato esplicitamente con i valori appropriati, ove necessario. Devi specificare esplicitamente i cookie che possono funzionare tra siti web o nelle navigazioni sullo stesso sito che passano da HTTP a HTTPS.

Per indicazioni complete per gli sviluppatori web su queste modifiche, consulta SameSite Cookies Explained e Schemeful SameSite.

Testa i comportamenti di SameSite nella tua app

Se la tua app utilizza WebView o se gestisci un sito web o un servizio che utilizza i cookie, ti consigliamo di testare i tuoi flussi su Android 12 WebView. In caso di problemi, potrebbe essere necessario aggiornare i cookie per supportare i nuovi comportamenti di SameSite.

Controlla i problemi relativi ad accessi e contenuti incorporati, nonché ai flussi di accesso, agli acquisti e ad altri flussi di autenticazione in cui l'utente inizia su una pagina non sicura e passa a una pagina sicura.

Per testare un'app con WebView, devi attivare i nuovi comportamenti di SameSite per l'app che vuoi testare completando uno dei seguenti passaggi:

Per informazioni sul debug remoto per WebView su Android, consulta la guida introduttiva al debug remoto dei dispositivi Android.

Altre risorse

Per ulteriori informazioni sui comportamenti moderni di SameSite e sul lancio in Chrome e WebView, visita la pagina degli aggiornamenti di SameSite di Chromium. Se trovi un bug in WebView o Chromium, puoi segnalarlo nel tracker problemi di Chromium pubblico.

I sensori di movimento hanno un limite di frequenza

Per proteggere le informazioni potenzialmente sensibili degli utenti, se la tua app ha come target Android 12 o versioni successive, il sistema pone un limite alla frequenza di aggiornamento dei dati provenienti da determinati sensori di movimento e sensori di posizione.

Scopri di più sulla limitazione della frequenza dei sensori.

Letargo delle app

Android 12 amplia il comportamento di ripristino automatico delle autorizzazioni che è stato introdotto in Android 11 (livello API 30). Se la tua app ha come target Android 12 e l'utente non interagisce con l'app per alcuni mesi, il sistema ripristina automaticamente le autorizzazioni concesse e imposta la tua app in stato di ibernazione.

Scopri di più nella guida sulla ibernazione delle app.

Dichiarazione di attribuzione nel controllo dell'accesso ai dati

L'API di controllo dell'accesso ai dati, introdotta in Android 11 (livello API 30), consente di creare tag di attribuzione in base ai casi d'uso della tua app. Questi tag consentono di determinare più facilmente quale parte della tua app esegue un tipo specifico di accesso ai dati.

Se la tua app ha come target Android 12 o versioni successive, devi dichiarare questi tag di attribuzione nel file manifest dell'app.

Limitazione backup ADB

Per proteggere i dati privati delle app, Android 12 modifica il comportamento predefinito del comando adb backup. Per le app destinate ad Android 12 (livello API 31) o versioni successive, quando un utente esegue il comando adb backup, i dati dell'app vengono esclusi da tutti gli altri dati di sistema esportati dal dispositivo.

Se i flussi di lavoro di test o sviluppo si basano su dati dell'app utilizzando adb backup, ora puoi attivare l'esportazione dei dati dell'app impostando android:debuggable su true nel file manifest dell'app.

Esportazione più sicura dei componenti

Se la tua app ha come target Android 12 o versioni successive e contiene attività, servizi o ricevitori di trasmissione che utilizzano filtri per intent, devi dichiarare esplicitamente l'attributo android:exported per questi componenti dell'app.

Se il componente dell'app include la categoria LAUNCHER, imposta android:exported su true. Nella maggior parte degli altri casi, imposta android:exported su false.

Il seguente snippet di codice mostra un esempio di servizio che contiene un filtro per intent il cui attributo android:exported è impostato su false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Messaggi in Android Studio

Se la tua app contiene un'attività, un servizio o un broadcast receiver che utilizza filtri di intent, ma non dichiara android:exported, vengono visualizzati i seguenti messaggi di avviso, a seconda della versione di Android Studio che utilizzi:

Android Studio 2020.3.1 Canary 11 o versioni successive

Vengono visualizzati i seguenti messaggi:

  1. Nel file manifest viene visualizzato il seguente avviso di lint:

    When using intent filters, please specify android:exported as well

  2. Quando tenti di compilare la tua app, viene visualizzato il seguente messaggio di errore di build:

    Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.
Versioni precedenti di Android Studio

Se tenti di installare l'app, Logcat visualizza il seguente messaggio di errore:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Cambiabilità degli intent in attesa

Se la tua app ha come target Android 12, devi specificare la mutabilità di ogni oggetto PendingIntent creato dall'app. Questo requisito aggiuntivo migliora la sicurezza della tua app.

Testa la modifica della mutabilità dell'intent in attesa

Per determinare se nella tua app mancano dichiarazioni di mutabilità, cerca il seguente avviso Lint in Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Lanci per intenzione non sicuri

Per migliorare la sicurezza della piattaforma, Android 12 e versioni successive offrono una funzionalità di debug che rileva lanci di intent non sicuri. Quando il sistema rileva un avvio non sicuro, si verifica una violazione di StrictMode.

Esibizione

Limitazioni relative al lancio dei servizi in primo piano

Le app destinate ad Android 12 o versioni successive non possono avviare servizi in primo piano mentre vengono eseguite in background, ad eccezione di alcuni casi speciali. Se un'app tenta di avviare un servizio in primo piano mentre è in esecuzione in background, si verifica un'eccezione (tranne nei pochi casi speciali).

Valuta la possibilità di utilizzare WorkManager per pianificare e avviare il lavoro accelerato mentre l'app viene eseguita in background. Per completare le azioni urgenti richieste dall'utente, avvia i servizi in primo piano all'interno di una sveglia esatta.

Autorizzazione Sveglia esatta

Per incoraggiare le app a risparmiare risorse di sistema, le app destinate ad Android 12 e versioni successive che impostano sveglie esatte devono avere accesso alla funzionalità "Sveglie e promemoria" visualizzata nella schermata Accesso speciale per le app nelle impostazioni di sistema.

Per ottenere questo accesso speciale all'app, richiedi l'autorizzazione SCHEDULE_EXACT_ALARM nel manifest.

Le sveglie esatte devono essere utilizzate solo per le funzionalità rivolte all'utente. Scopri di più sui casi d'uso accettabili per l'impostazione di una sveglia esatta.

Disattiva la modifica del comportamento

Mentre prepari la tua app per avere come target Android 12, puoi disattivare temporaneamente il cambiamento del comportamento nella variante della build di cui è possibile eseguire il debug a scopo di test. Per farlo, completa una delle seguenti attività:

  • Nella schermata di impostazione delle Opzioni sviluppatore, seleziona Modifiche alla compatibilità delle app. Nella schermata visualizzata, tocca il nome dell'app, poi disattiva REQUIRE_EXACT_ALARM_PERMISSION.

  • In una finestra del terminale sul computer di sviluppo, esegui questo comando:

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

Restrizioni sul trampolino per le notifiche

Quando gli utenti interagiscono con le notifiche, alcune app rispondono ai tocchi di notifica avviando un componente dell'app che avvia l'attività che l'utente finale vede e con cui interagisce. Questo componente dell'app è noto come trappolino delle notifiche.

Per migliorare le prestazioni e l'UX, le app destinate ad Android 12 o versioni successive non possono avviare attività da servizi o ricevitori di trasmissione usati come trampolini per le notifiche. In altre parole, dopo che l'utente tocca una notifica o un pulsante di azione al suo interno, la tua app non può chiamare startActivity() all'interno di un servizio o di un broadcast receiver.

Quando l'app tenta di avviare un'attività da un servizio o un broadcast receiver che funge da trampolino per le notifiche, il sistema impedisce l'avvio dell'attività e in Logcat viene visualizzato il seguente messaggio:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Identificare quali componenti dell'app fungono da trampolini per le notifiche

Durante il test dell'app, dopo aver toccato una notifica, puoi identificare il servizio o il broadcast receiver che ha fungeto da trampolino per le notifiche nell'app. A tale scopo, guarda l'output del seguente comando nel terminale:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

Una sezione dell'output include il testo "NotifInteractionLog". Questa sezione contiene le informazioni necessarie per identificare il componente che viene avviato in seguito a un tocco di notifica.

Aggiorna la tua app

Se l'app avvia un'attività da un servizio o un broadcast receiver che funge da trampolino per le notifiche, completa i seguenti passaggi di migrazione:

  1. Crea un oggetto PendingIntent associato all'attività che gli utenti vedono dopo aver toccato la notifica.
  2. Utilizza l'oggetto PendingIntent che hai creato nel passaggio precedente come parte della creazione della notifica.

Per identificare l'origine dell'attività, ad esempio per eseguire il logging, utilizza ulteriori opzioni quando pubblichi la notifica. Per il logging centralizzato, utilizza ActivityLifecycleCallbacks o gli osservatori del ciclo di vita di Jetpack.

Attiva/disattiva il comportamento

Durante il test di una versione di cui è possibile eseguire il debug dell'app, puoi attivare e disattivare questa limitazione utilizzando il flag di compatibilità dell'app NOTIFICATION_TRAMPOLINE_BLOCK.

Backup e ripristino

Sono state apportate modifiche al funzionamento del backup e ripristino nelle app eseguite su Android 12 (livello API 31) e che hanno come target. Il backup e ripristino di Android ha due forme:

  • Backup nel cloud: i dati utente vengono archiviati sul Google Drive dell'utente in modo da poter essere ripristinati su quel dispositivo o su un nuovo dispositivo.
  • Trasferimenti da dispositivo a dispositivo (D2D): i dati utente vengono inviati direttamente al nuovo dispositivo dell'utente dal suo dispositivo precedente, ad esempio tramite un cavo.

Per ulteriori informazioni sulle modalità di backup e ripristino dei dati, vedi Effettuare il backup dei dati utente con Backup automatico e Effettuare il backup di coppie chiave-valore con Android Backup Service.

Modifiche alla funzionalità di trasferimento D2D

Per le app che hanno come target Android 12 e versioni successive e che hanno come target:

  • Specificare le regole di inclusione ed esclusione con il meccanismo di configurazione XML non influisce sui trasferimenti D2D, ma interessa comunque il backup e ripristino basati su cloud (come i backup di Google Drive). Per specificare regole per i trasferimenti D2D, devi utilizzare la nuova configurazione descritta nella prossima sezione.

  • Sui dispositivi di alcuni produttori di dispositivi, l'indicazione di android:allowBackup="false" disattiva i backup su Google Drive, ma non disattiva i trasferimenti D2D per l'app.

Nuovo formato di inclusione ed esclusione

Le app che hanno come target Android 12 e versioni successive utilizzano un formato diverso per la configurazione XML. Questo formato fa la differenza tra il backup di Google Drive e il trasferimento D2D in quanto richiede di specificare separatamente le regole di inclusione ed esclusione per i backup sul cloud e per il trasferimento D2D.

Facoltativamente, puoi anche specificare le regole per il backup. In questo caso, la configurazione utilizzata in precedenza viene ignorata sui dispositivi con Android 12 o versioni successive. Per i dispositivi con Android 11 o versioni precedenti è comunque necessaria la configurazione precedente.

Modifiche al formato XML

Di seguito è riportato il formato utilizzato per la configurazione del backup e ripristino in Android 11 e versioni precedenti:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Di seguito vengono mostrate le modifiche nel formato in grassetto.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Per ulteriori informazioni, consulta la sezione corrispondente nella guida al backup dei dati utente con Backup automatico.

Flag del file manifest per le app

Punta le app alla nuova configurazione XML utilizzando l'attributo android:dataExtractionRules nel file manifest. Quando punti alla nuova configurazione XML, l'attributo android:fullBackupContent che rimanda alla configurazione precedente viene ignorato sui dispositivi con Android 12 o versioni successive. Il seguente esempio di codice mostra le nuove voci del file manifest:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Connettività

Autorizzazioni Bluetooth

Android 12 introduce le autorizzazioni BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE e BLUETOOTH_CONNECT. Queste autorizzazioni consentono alle app destinate ad Android 12 di interagire più facilmente con i dispositivi Bluetooth, in particolare per le app che non richiedono l'accesso alla posizione del dispositivo.

Per preparare il dispositivo al targeting di Android 12 o versioni successive, aggiorna la logica dell'app. Anziché dichiarare un insieme precedente di autorizzazioni Bluetooth, dichiara un insieme più moderno di autorizzazioni Bluetooth.

Peer-to-peer simultanea + connessione a internet

Per le app che hanno come target Android 12 (livello API 31) o versioni successive, i dispositivi che supportano connessioni peer-to-peer e internet simultanee possono mantenere connessioni Wi-Fi simultanee sia al dispositivo peer che alla rete principale di fornitura di internet, semplificando l'esperienza utente. Le app che hanno come target Android 11 (livello API 30) o versioni precedenti continuano a riscontrare il comportamento precedente, in cui la rete Wi-Fi principale viene disconnessa prima della connessione al dispositivo peer.

Compatibilità

WifiManager.getConnectionInfo() è in grado di restituire WifiInfo per una sola rete. Per questo motivo, il comportamento dell'API è cambiato nei seguenti modi in Android 12 e versioni successive:

  • Se è disponibile una sola rete Wi-Fi, viene restituito il relativo WifiInfo.
  • Se è disponibile più di una rete Wi-Fi e l'app per le chiamate ha attivato una connessione peer-to-peer, viene restituito il WifiInfo corrispondente al dispositivo peer.
  • Se è disponibile più di una rete Wi-Fi e l'app chiamante non ha attivato una connessione peer-to-peer, viene restituito il WifiInfo della connessione che fornisce internet principale.

Per offrire una migliore esperienza utente sui dispositivi che supportano due reti Wi-Fi simultanee, consigliamo di eseguire la migrazione di tutte le app, in particolare di quelle che attivano connessioni peer-to-peer, anziché di chiamare WifiManager.getConnectionInfo(), anziché utilizzare NetworkCallback.onCapabilitiesChanged() per recuperare tutti gli oggetti WifiInfo corrispondenti a NetworkRequest utilizzato per registrare NetworkCallback. getConnectionInfo() è deprecato a partire da Android 12.

Il seguente esempio di codice mostra come ottenere WifiInfo in un NetworkCallback:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

API nativa mDNSResponder

Android 12 cambia quando le app possono interagire con il daemon mDNSResponder utilizzando l'API nativa mDNSResponder. In precedenza, quando un'app registrava un servizio sulla rete e chiamava il metodo getSystemService(), il servizio NSD del sistema avviava il daemon mDNSResponder, anche se l'app non aveva ancora chiamato alcun metodo NsdManager. Il daemon ha quindi sottoscritto il dispositivo nei gruppi multicast con tutti i nodi, determinando una riattivazione più frequente del sistema e un consumo maggiore di energia. Per ridurre al minimo l'utilizzo della batteria, in Android 12 e versioni successive il sistema ora avvia il daemon mDNSResponder solo quando è necessario per gli eventi NSD e lo arresta successivamente.

Poiché questa modifica influisce sulla disponibilità del daemon mDNSResponder, le app che presuppongono che il daemon mDNSResponder verrà avviato dopo la chiamata al metodo getSystemService() potrebbero ricevere messaggi dal sistema che indicano che il daemon mDNSResponder non è disponibile. Le app che utilizzano NsdManager e non usano l'API nativa mDNSResponder non sono interessate da questa modifica.

Librerie dei fornitori

Librerie condivise native fornite dal fornitore

Le librerie condivise native non NDK fornite da fornitori di silicio o produttori di dispositivi non sono accessibili per impostazione predefinita se l'app ha come target Android 12 (livello API 31) o versioni successive. Le librerie sono accessibili solo quando vengono richieste esplicitamente tramite il tag <uses-native-library>.

Se l'app ha come target Android 11 (livello API 30) o versioni precedenti, il tag <uses-native-library> non è obbligatorio. In questo caso, qualsiasi libreria condivisa nativa è accessibile, indipendentemente dal fatto che si tratti o meno di una libreria NDK.

Limitazioni non SDK aggiornate

Android 12 include elenchi aggiornati di interfacce non SDK limitate in base alla collaborazione con sviluppatori Android e agli ultimi test interni. Se 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 riguardarti 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 danneggiare la tua app.

Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testarla per scoprirlo. Se la tua app si basa su interfacce non SDK, dovresti iniziare a pianificare una migrazione a alternative SDK. Tuttavia, sappiamo 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 gli aggiornamenti alle limitazioni relative all'interfaccia non SDK in Android 12. Per scoprire di più sulle interfacce non SDK in generale, consulta Restrizioni relative alle interfacce non SDK.