Modifiche del comportamento: app che hanno come target Android 12

Come nelle release precedenti, Android 12 include modifiche del comportamento che potrebbero influire sulla 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 è che hanno come target Android 12, devi modificare l'app per supportare questi comportamenti in modo appropriato, ove applicabile.

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

Esperienza utente

Notifiche personalizzate

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

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

In questo modo, Android 12 rende tutte le notifiche visivamente coerenti e facili scansione, 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 un file compresso e uno stato espanso:

La modifica in Android 12 interessa le app che definiscono sottoclassi personalizzate 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 testare con lo il prima 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, verificando che abbiano lo stesso aspetto delle tue notifiche. che si aspettano all'ombra. Durante il test, tieni conto di queste considerazioni e apporta le modifiche necessarie:

    • Le dimensioni delle visualizzazioni personalizzate sono cambiate. In generale, l'altezza delle notifiche personalizzate è inferiore rispetto a prima. Nella cartella compressa , 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, dovrai anche utilizzare setBigCustomContentView per assicurarti che gli stati compressi ed espansi siano coerenti.

    • Per assicurarti che la casella di controllo "Guarda avanti" come previsto, non dimenticare per aumentare l'importanza del canale di notifica a "HIGH" (Appare schermo).

Nelle app destinate ad Android 12 o versioni successive, il sistema diverse modifiche alla funzionalità Link per app Android verificati. Questi modifiche migliorano l'affidabilità dell'esperienza di collegamento delle app e offrono per gli sviluppatori di app e gli utenti finali.

Se utilizzi la verifica tramite link per app Android per aprire i link web nella tua app: verifica di utilizzare il formato corretto quando aggiungi l'intent filtri per Verifica tramite link per app Android. In particolare, assicurati che questi intent i filtri includono la categoria BROWSABLE e supportano lo schema https.

Puoi anche manualmente verifica 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 per le animazioni di transizione di entrambi i gesti la navigazione basata su elementi e la navigazione basata su elementi.

Guarda la sezione Picture in picture miglioramenti per ulteriori informazioni.

Nuovo design di Toast

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

Immagine di un dispositivo Android che mostra la lettura di un popup che mostra 'Invio messaggio' 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 posizione approssimativa precisione per la tua app.

Cookie SameSite moderni in WebView

Il componente WebView di Android è basato su Chromium, progetto open source su cui si basa il browser Chrome di Google. Introduzione a Chromium modifiche alla gestione dei cookie di terze parti per garantire maggiore sicurezza e privacy e offrono agli utenti maggiore trasparenza e controllo. A partire da Android 12, queste modifiche sono incluse anche in WebView quando le app target Android 12 (livello API 31) o versioni successive.

L'attributo SameSite di un cookie controlla se può essere inviato con qualsiasi o solo con richieste sullo stesso sito. Le seguenti funzionalità di tutela della privacy modifiche migliorano la gestione predefinita dei cookie di terze parti e aiutano a proteggere rispetto alla condivisione tra siti involontaria:

  • I cookie senza un attributo SameSite vengono trattati come SameSite=Lax.
  • I cookie con SameSite=None devono specificare anche l'attributo Secure, nel senso 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 cross-site di richieste, quindi i cookie non vengono inviati a meno che non siano contrassegnati in modo appropriato come SameSite=None; Secure.

Per gli sviluppatori, la guida generale è identificare il cookie cross-site nei flussi utente critici e assicurati che SameSite sia impostato in modo esplicito con i valori appropriati ove necessario. Devi specificare esplicitamente i cookie autorizzati a funzionare su più siti web o nelle navigazioni nello stesso sito, che passano da HTTP a HTTPS.

Per indicazioni complete per gli sviluppatori web su queste modifiche, consulta l'articolo relativo ai cookie SameSite Spiegato e strategico SameSite.

Testa i comportamenti di SameSite nella tua app

Se la tua app utilizza WebView oppure se gestisci un sito web o un servizio che utilizza cookie, ti consigliamo di testare i flussi su Android 12 WebView. Se riscontri problemi, potrebbe essere necessario aggiornare i cookie per supportare la nuova Comportamenti di SameSite.

Verifica la presenza di problemi relativi ad accessi e contenuti incorporati, nonché ai flussi di accesso, e altri flussi di autenticazione in cui l'utente inizia su un account pagina di destinazione e le transizioni a una pagina sicura.

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

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

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

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

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

Per informazioni sul debug remoto per WebView su Android, leggi l'articolo Per iniziare. con il debug remoto dei dispositivi Android.

Altre risorse

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

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 all'aggiornamento la velocità dei dati da determinati sensori di movimento e sensori di posizione.

Scopri di più su sensor una limitazione di frequenza.

Letargo delle app

Android 12 estende la reimpostazione automatica delle autorizzazioni comportamento dell'utente introdotto in Android 11 (livello API 30). Se la tua app ha come target Android 12 e l'utente non interagisce con la tua app per alcuni mesi, il sistema reimposta automaticamente le autorizzazioni concesse e inserisce l'app in una stato di ibernazione.

Scopri di più nella guida sulle app in ibernazione.

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 per creare l'attribuzione tag in base a i casi d'uso delle app. Questi tag consentono di stabilire più facilmente quale parte l'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 in il file manifest dell'app.

Limitazione backup ADB

Per proteggere i dati privati delle app, Android 12 modifica il comportamento predefinito dell' 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 e i dati di sistema esportati dal dispositivo.

Se i flussi di lavoro di test o sviluppo si basano su dati dell'app utilizzando adb backup, puoi attivare l'esportazione dei dati dell'app impostando android:debuggable a 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 trasmettere destinatari che usano intent filtri, devi esplicitamente dichiara il Attributo android:exported per questi componenti dell'app.

Se il componente dell'app include Categoria LAUNCHER, impostata Da android:exported a 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 intent filtro 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 per intent ma non dichiara android:exported, il seguente avviso vengono visualizzati messaggi, 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 provi a compilare la tua app, viene visualizzato il seguente messaggio di errore relativo alla build dell'immagine:

    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 il mutabilità di ogni oggetto PendingIntent che create 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 l'icona 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 funzione di debug che rileva gli avvii non sicuri di intent. Quando il sistema rileva un avvio non sicuro, Si verifica una violazione di StrictMode.

Prestazioni

Limitazioni relative al lancio dei servizi in primo piano

Le app destinate ad Android 12 o versioni successive non possono avviare le app in primo piano durante l'esecuzione nel in background, fatta eccezione per alcuni tipi di assistenza. 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 caricamento rapido lavoro mentre l'app viene eseguita in background. Per completare azioni urgenti richieste dall'utente, avviare i servizi in primo piano all'interno di un sveglia.

Autorizzazione Sveglia esatta

Per incoraggiare le app a preservare le risorse di sistema, quelle che hanno come target Android 12 e versioni successive e imposta esattamente allarmi devono avere accesso alla sezione "Sveglie e promemoria" la funzionalità visualizzata nella schermata Accesso speciale per le app in impostazioni di sistema.

Per ottenere questo accesso speciale all'app, richiedi il SCHEDULE_EXACT_ALARM nel file manifest.

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

Disattiva la modifica del comportamento

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

  • Nella schermata di impostazione delle Opzioni sviluppatore, seleziona Compatibilità app. Modifiche. Nella schermata visualizzata, tocca il nome dell'app, quindi 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 notifiche, alcune app rispondono la notifica viene toccata avviando un'app che alla fine avvia l'attività che l'utente vede e con cui interagisce. Questo componente dell'app è noto come trappolino per le notifiche.

Per migliorare le prestazioni e l'esperienza utente, le app destinate ad Android 12 o di un livello superiore non possono avviare attività da servizi o ricevitori di broadcast utilizzati come trampolini per le notifiche. In altre parole, dopo che l'utente tocca una notifica, o un pulsante di azione in la notifica, l'app non può chiamare startActivity(): all'interno di un servizio o di un broadcast receiver.

Quando la tua app prova ad avviare un'attività da un servizio o un broadcast receiver che funge da trampolino per le notifiche, il sistema impedisce all'attività di inizierà e verrà visualizzato il seguente messaggio Logcat:

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 quale o il broadcast receiver ha svolto la funzione di trampolino per le notifiche nell'app. Per farlo, osserva 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 inizia in seguito al tocco di una notifica.

Aggiorna la tua app

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

  1. Crea un oggetto PendingIntent che è associata all'attività che gli utenti vedono dopo aver toccato notifica.
  2. Utilizza come parte l'oggetto PendingIntent che hai creato nel passaggio precedente di costruire di notifica.

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

Attiva/disattiva il comportamento

Quando testi una versione di cui è possibile eseguire il debug dell'app, puoi attivare e disattivare questa opzione 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 e target Android 12 (livello API 31). Il backup e ripristino di Android ha due forme:

  • Backup sul cloud: i dati utente vengono archiviati sul Google Drive dell'utente in modo che potrà essere ripristinata in un secondo momento su quel dispositivo o su un nuovo dispositivo.
  • Trasferimenti da dispositivo a dispositivo (D2D): i dati utente vengono inviati direttamente al il nuovo dispositivo dell'utente dal dispositivo precedente, ad esempio utilizzando un cavo.

Per ulteriori informazioni sulle modalità di backup e ripristino dei dati, vedi Eseguire il backup degli utenti i dati con Backup automatico e Esegui il backup di coppie chiave-valore 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:

  • Specifica delle regole di inclusione ed esclusione con il file XML meccanismo di configurazione di Google non influisce sui trasferimenti D2D, anche se influisce sul backup e ripristino basati su cloud (ad esempio i backup di Google Drive). A le regole per i trasferimenti D2D, devi utilizzare la nuova configurazione nella prossima sezione.

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

Nuovo formato di inclusione ed esclusione

Le app in esecuzione su Android 12 e versioni successive e che hanno come target utilizzano una per la configurazione XML. Questo formato fa la differenza tra il backup di Google Drive e il trasferimento D2D in modo esplicito richiedendo l'autorizzazione specificare le regole di inclusione ed esclusione separatamente per i backup sul cloud e per D2D trasferimento.

Facoltativamente, puoi utilizzarlo anche per specificare le regole per il backup, nel qual caso utilizzata in precedenza viene ignorata sui dispositivi con Android 12 o in alto. Per i dispositivi con Android 11 è ancora necessaria la configurazione precedente o inferiore.

Modifiche al formato XML

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

<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 la guida al backup dei dati utente con Backup automatico.

Flag del file manifest per le app

Indirizza le app alla nuova configurazione XML utilizzando Attributo android:dataExtractionRules nel file manifest . Quando punti alla nuova configurazione XML, L'attributo android:fullBackupContent che punta alla configurazione precedente viene ignorato su dispositivi con Android 12 o versioni successive. Il seguente esempio di codice mostra la nuova 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 BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE, e BLUETOOTH_CONNECT autorizzazioni aggiuntive. Queste autorizzazioni semplificano le app che hanno come target Android 12 per interagire con il Bluetooth dispositivi mobili, soprattutto per le app che non richiedono l'accesso alla posizione del dispositivo.

Per preparare il dispositivo al targeting di Android 12 o versioni successive, esegui l'aggiornamento dalla logica della tua app. Anziché dichiarare un insieme legacy di dispositivi Bluetooth autorizzazioni, dichiarano un insieme più moderno di dispositivi Bluetooth autorizzazioni.

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 le connessioni peer-to-peer e internet simultanee possono mantenere sia al dispositivo peer che alla rete principale di fornitura di internet; rendendo più fluida l'esperienza utente. Targeting per app Android 11 (livello API 30) o versioni precedenti continuano a riscontrare il comportamento precedente, ovvero la rete Wi-Fi principale viene disconnessa prima di connettersi al peer dispositivo.

Compatibilità

WifiManager.getConnectionInfo() può restituire WifiInfo per in una singola 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 un avviso connessione peer-to-peer, il valore WifiInfo corrispondente al dispositivo peer è restituito.
  • Se è disponibile più di una rete Wi-Fi e l'app per le chiamate non attivare una connessione peer-to-peer, l'istanza principale Viene restituito WifiInfo.

Per offrire una migliore esperienza utente sui dispositivi che supportano il doppio della modalità simultanea. Reti Wi-Fi, consigliamo tutte le app, in particolare quelle che attivano connessioni peer-to-peer: eseguire la migrazione dalle chiamate WifiManager.getConnectionInfo() e usa invece NetworkCallback.onCapabilitiesChanged() per ottenere tutti gli oggetti WifiInfo che corrispondono a NetworkRequest utilizzato per la registrazione il NetworkCallback. getConnectionInfo() è deprecato dal giorno 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 il momento in cui le app possono interagire con il daemon mDNSResponder utilizzando l'API nativa mDNSResponder. In precedenza, quando un'app registrava un servizio sulla rete e chiamato getSystemService() , il servizio NSD del sistema ha avviato il daemon mDNSResponder, anche se l'app non aveva ancora chiamato nessun metodo NsdManager. Il daemon ha quindi sottoscritto dispositivo ai gruppi multicast con tutti i nodi, con conseguente riattivazione del sistema spesso e consumano molta energia. Per ridurre al minimo l'utilizzo della batteria, in Android 12 e più in alto il sistema ora avvia il daemon mDNSResponder solo quando è necessario. per gli eventi NSD e lo interrompe in seguito.

Poiché questa modifica influisce sulla disponibilità del daemon mDNSResponder, le app presuppongono che il daemon mDNSResponder verrà avviato dopo la chiamata Il metodo getSystemService() potrebbe ricevere dal sistema messaggi che dicono che il daemon mDNSResponder non è disponibile. App che usano NsdManager e non utilizzare l'API nativa mDNSResponder non sono interessati da questa modifica.

Librerie dei fornitori

Librerie condivise native fornite dal fornitore

Librerie condivise native non NDK forniti 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. La le librerie sono accessibili solo quando vengono richieste esplicitamente tramite <uses-native-library> del tag.

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 nativo condiviso indipendentemente dal fatto che si tratti o meno di una libreria NDK.

Limitazioni non SDK aggiornate

Android 12 include elenchi aggiornati di elementi non SDK soggetti a restrizioni basate sulla collaborazione con gli sviluppatori Android e le applicazioni per i test interni. Quando possibile, facciamo in modo che le alternative pubbliche siano disponibili prima che vengano limitate le interfacce non SDK.

Se la tua app non ha come target Android 12, alcune di queste modifiche potrebbero non riguardarti immediatamente. Tuttavia, sebbene al momento tu possa utilizzare interfacce non SDK (a seconda del livello API target dell'app), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di danneggiare dell'app.

Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare app per scoprirlo. Se la tua app si basa su interfacce non SDK, dovresti iniziare a pianificare una migrazione alle alternative dell'SDK. Tuttavia, sappiamo che alcune app hanno e validi casi d'uso per l'utilizzo di interfacce non SDK. Se non riesci a trovare un'alternativa all'utilizzo di un'interfaccia non SDK per una funzionalità della tua app, devi richiedere una nuova API pubblica.

Per ulteriori informazioni sulle modifiche in questa release di Android, consulta gli aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 12. Per scoprire di più sulle interfacce non SDK in generale, consulta Restrizioni relative alle interfacce non SDK di archiviazione.