Modifiche al comportamento: app che hanno come target Android 12

Come le release precedenti, Android 12 include modifiche al comportamento che possono influire sulla tua app. Le seguenti modifiche al 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 in modo da supportare correttamente questi comportamenti, ove applicabile.

Assicurati di esaminare anche l'elenco delle modifiche al 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 personalizzate. In precedenza, le notifiche personalizzate potevano utilizzare l'intera area di notifica e fornire layout e stili personalizzati. Ciò ha comportato antipattern 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. Al suo posto, il sistema applicherà 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 della notifica e le affordance di espansione (nello stato compresso) e l'icona della notifica, il nome dell'app e l'affordance di compressione (nello stato espanso). Questo comportamento è quasi identico a quello di Notification.DecoratedCustomViewStyle.

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

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

Gli esempi riportati di seguito mostrano come vengono visualizzate le notifiche personalizzate in stato compresso e espanso:

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

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

  1. Attiva la modifica delle notifiche personalizzate:

    1. Modifica targetSdkVersion in S per attivare il nuovo comportamento.
    2. Esegui nuovamente la compilazione.
    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 in modalità scura. Durante i test, tieni conto di queste considerazioni e apporta le modifiche necessarie:

    • Le dimensioni delle viste personalizzate sono cambiate. In generale, l'altezza delle notifiche personalizzate è inferiore a prima. Nello stato chiuso, l'altezza massima dei contenuti personalizzati è diminuita da 106 dp a 48 dp. Inoltre, lo spazio orizzontale è inferiore.

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

    • Per assicurarti che lo stato "Avviso" sia visualizzato come previsto, non dimenticare di impostare l'importanza del canale di notifica su "ELEVATA" (notifica sullo schermo).

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

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

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

Miglioramenti al comportamento di Picture in picture

Android 12 introduce miglioramenti al comportamento della modalità Picture in picture (PiP) e miglioramenti estetici consigliati alle animazioni di transizione sia per la navigazione con i gesti sia per la navigazione basata sugli elementi.

Per saperne di più, consulta la sezione Miglioramenti della funzionalità Picture in picture.

Nuovo design dei toast

In Android 12, la visualizzazione toast è stata nuovamente progettata. Ora le notifiche popup sono limitate a due righe di testo e mostrano l'icona dell'applicazione accanto al testo.

Immagine di un dispositivo Android che mostra un popup di notifica con la dicitura "Messaggio inviato" accanto a un'icona di app

Per ulteriori dettagli, consulta la Panoramica delle notifiche popup.

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 che alimenta il browser Chrome di Google. Chromium ha introdotto modifiche alla gestione dei cookie di terze parti per garantire maggiore sicurezza e privacy e offrire agli utenti maggiore trasparenza e controllo. A partire da Android 12, queste modifiche sono incluse anche in WebView quando 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 same-site. Le seguenti modifiche che tutelano la privacy migliorano la gestione predefinita dei cookie di terze parti e contribuiscono a proteggere dalla condivisione tra siti non intenzionale:

  • 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 cross-site, pertanto i cookie non vengono inviati a meno che non siano contrassegnati come SameSite=None; Secure.

Per gli sviluppatori, le indicazioni generali sono di identificare le dipendenze dei cookie cross-site nei flussi utente critici e assicurarsi che l'attributo SameSite sia impostato esplicitamente con i valori appropriati, se necessario. Devi specificare esplicitamente i cookie che possono essere utilizzati su più siti web o tra navigazioni nello stesso sito che passano da HTTP a HTTPS.

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

Testare i comportamenti 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 flussi su WebView di Android 12. Se riscontri problemi, potrebbe essere necessario aggiornare i cookie per supportare i nuovi comportamenti SameSite.

Fai attenzione a problemi di accesso e contenuti incorporati, nonché a flussi di accesso, acquisti e 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 SameSite per l'app che vuoi testare completando uno dei seguenti passaggi:

  • Attiva manualmente i comportamenti SameSite sul dispositivo di test attivando/disattivando il flag UI webview-enable-modern-cookie-same-site in WebView devtools.

    Questo approccio ti consente di eseguire test su qualsiasi dispositivo con Android 5.0 (livello API 21) o versioni successive, incluso Android 12, e WebView 89.0.4385.0 o versioni successive.

  • Compila l'app in modo che abbia come target Android 12 (livello API 31) entro il giorno targetSdkVersion.

    Se utilizzi questo approccio, devi utilizzare un dispositivo con Android 12.

Per informazioni sul debug remoto per WebView su Android, vedi Iniziare con il debug remoto dei dispositivi Android.

Altre risorse

Per ulteriori informazioni sui comportamenti moderni di SameSite e sul loro implementazione 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 dei problemi di Chromium pubblico.

I sensori di movimento hanno una frequenza limitata

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

Scopri di più sulla limitazione della frequenza di acquisizione del sensore.

Ibernazione dell'app

Android 12 espande il comportamento di ripristino automatico delle autorizzazioni 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 reimposta automaticamente le autorizzazioni concesse e mette l'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), ti consente di creare tag di attribuzione in base ai casi d'uso della tua app. Questi tag ti 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 della tua app.

Limitazione del backup ADB

Per contribuire a proteggere i dati privati delle app, Android 12 modifica il comportamento predefinito del comando adb backup. Per le app che hanno come target Android 12 (livello API 31) o versioni successive, quando un utente esegue il comando adb backup, i dati dell'app vengono esclusi da qualsiasi altro dato di sistema esportato dal dispositivo.

Se i tuoi flussi di lavoro di test o sviluppo si basano sui dati dell'app che utilizzano 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 annunci broadcast che utilizzano filtri di 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 di intenti 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 i filtri per intent, ma non dichiara android:exported, vengono visualizzati i seguenti messaggi di avviso, a seconda della versione di Android Studio in uso:

Android Studio 2020.3.1 Canary 11 o versioni successive

Vengono visualizzati i seguenti messaggi:

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

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

  2. Quando provi a compilare l'app, viene visualizzato il seguente messaggio di errore di compilazione:

    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 provi a 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'

Mutabilità degli intent in attesa

Se la tua app ha come target Android 12, devi specificare la mutabilità di ogni oggetto PendingIntent creato dalla tua 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 le dichiarazioni di mutabilità, cerca il seguente avviso lint in Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Avviamenti di intent non sicuri

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

Prestazioni

Limitazioni di avvio dei servizi in primo piano

Le app che hanno come target Android 12 o versioni successive non possono avviare servizi in primo piano mentre sono in esecuzione in background, tranne che per alcuni casi speciali. Se un'app tenta di avviare un servizio in primo piano mentre è in esecuzione in background, si verifica un'eccezione (tranne che per alcuni 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 entro un avviso esatto.

Autorizzazione Sveglia esatta

Per incoraggiare le app a risparmiare risorse di sistema, le app che hanno come target Android 12 e versioni successive e impostano sveglie precise devono avere accesso alla funzionalità "Sveglie e promemoria" visualizzata nella schermata Accesso speciale alle app nelle impostazioni di sistema.

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

Gli allarmi esatti devono essere utilizzati solo per le funzionalità rivolte agli utenti. Scopri di più sui casi d'uso accettabili per l'impostazione di un'anticipazione esatta.

Disattivare la modifica del comportamento

Mentre prepari la tua app per il target Android 12, puoi disattivare temporaneamente la modifica del comportamento nella variante di compilazione di debug per scopi di test. Per farlo, completa una delle seguenti attività:

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

  • In una finestra del terminale sulla tua macchina di sviluppo, esegui il seguente comando:

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

Limitazioni relative al trampolino di notifiche

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

Per migliorare le prestazioni e l'esperienza utente delle app, le app che hanno come target Android 12 o versioni successive non possono avviare attività da servizi o broadcast receiver utilizzati come trampolini di notifica. 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'entità di ricezione di trasmissione.

Quando l'app tenta di avviare un'attività da un servizio o un'entità BroadcastReceiver che funge da trampolino di notifica, il sistema impedisce l'avvio dell'attività e viene visualizzato il seguente messaggio in Logcat:

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

Identificare i componenti dell'app che fungono da trampolini di notifica

Quando testi la tua app, dopo aver toccato una notifica, puoi identificare il servizio o il ricevitore di trasmissione che ha agito come trampolino di notifiche nella tua app. Per farlo, controlla l'output del seguente comando del 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 si avvia come risultato di un tocco della notifica.

Aggiorna la tua app

Se la tua app avvia un'attività da un servizio o un'attività di ricezione di trasmissione che funge da trampolino di notifiche, completa i seguenti passaggi di migrazione:

  1. Crea un oggetto PendingIntent associato all'attività che gli utenti visualizzano dopo aver toccato la notifica.
  2. Utilizza l'oggetto PendingIntent creato nel passaggio precedente per creare la notifica.

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

Attiva/disattiva il comportamento

Quando testi una versione di debug dell'app, puoi attivare e disattivare questa limitazione utilizzando il flag di compatibilità dell'app NOTIFICATION_TRAMPOLINE_BLOCK.

Backup e ripristino

Il funzionamento del backup e del ripristino è cambiato nelle app che vengono eseguite su Android 12 (livello API 31) e hanno come target questo sistema operativo. Il backup e il ripristino di Android hanno due forme:

  • Backup sul cloud: i dati utente vengono archiviati su Google Drive dell'utente in modo che possano essere successivamente 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 dispositivo precedente, ad esempio tramite un cavo.

Per ulteriori informazioni su come viene eseguito il backup e il ripristino dei dati, consulta Effettuare il backup dei dati utente con Backup automatico ed Effettuare il backup delle coppie chiave-valore con Android Backup Service.

Modifiche alla funzionalità di trasferimento D2D

Per le app che funzionano su Android 12 e versioni successive e che hanno come target questa versione:

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

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

Nuovo formato di inclusione ed esclusione

Le app che funzionano su Android 12 e versioni successive e che hanno come target questo sistema operativo utilizzano un formato diverso per la configurazione XML. Questo formato rende esplicita la differenza tra il backup di Google Drive e il trasferimento D2D richiedendoti di specificare le regole di inclusione ed esclusione separatamente per i backup sul cloud e per il trasferimento D2D.

Se vuoi, puoi utilizzarlo anche per specificare regole per il backup, in tal caso la configurazione utilizzata in precedenza viene ignorata sui dispositivi con Android 12 o versioni successive. La configurazione precedente è ancora necessaria per i dispositivi con Android 11 o versioni precedenti.

Modifiche al formato XML

Di seguito è riportato il formato utilizzato per la configurazione del backup e del 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 sono riportate le modifiche al 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 della guida al backup dei dati utente con il backup automatico.

Flag del manifest per le app

Indica alle app la nuova configurazione XML utilizzando l'attributo android:dataExtractionRules nel file manifest. Quando fai riferimento alla nuova configurazione XML, l'attributo android:fullBackupContent che rimanda alla vecchia configurazione 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 semplificano l'interazione con i dispositivi Bluetooth per le app destinate ad Android 12, in particolare per quelle che non richiedono l'accesso alla posizione del dispositivo.

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

Connessione peer-to-peer + a internet simultanea

Per le app che hanno come target Android 12 (livello API 31) o versioni successive, i dispositivi che supportano connessioni peer-to-peer e a internet simultanee possono mantenere connessioni Wi-Fi simultanee sia con il dispositivo peer sia con la rete di provider di servizi internet principale, rendendo l'esperienza utente più fluida. Le app che hanno come target Android 11 (livello API 30) o versioni precedenti continuano a presentare 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 il WifiInfo per solo una rete. Per questo motivo, il comportamento dell'API è stato modificato nel seguente modo 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 di chiamata 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 di chiamata non ha attivato una connessione peer-to-peer, viene restituito il valore WifiInfo della connessione principale che fornisce internet.

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

Il seguente esempio di codice mostra come ottenere il 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 ai gruppi multicast di tutti i nodi, causando il risveglio del sistema più frequentemente e l'utilizzo di energia aggiuntiva. 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 in seguito.

Poiché questa modifica influisce sul momento in cui il daemon mDNSResponder è disponibile, le app che presuppongono che il daemon mDNSResponder venga avviato dopo aver chiamato il metodo getSystemService() potrebbero ricevere dal sistema messaggi che indicano che il daemon mDNSResponder non è disponibile. Le app che utilizzano NsdManager e non utilizzano l'API nativa mDNSResponder non sono interessate da questa modifica.

Biblioteche del fornitore

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 utilizzando 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 di una libreria NDK.

Limitazioni non SDK aggiornate

Android 12 include elenchi aggiornati di interfacce non SDK con limitazioni in base alla collaborazione con gli sviluppatori Android e ai test interni più recenti. Ove possibile, ci assicuriamo che siano disponibili alternative pubbliche prima di applicare limitazioni alle 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 interrompere la tua 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 la migrazione a alternative SDK. Tuttavia, 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 saperne di più sulle interfacce non SDK in generale, consulta Limitazioni relative alle interfacce non SDK.