Come le 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 ha come target Android 12, devi modificare l'app per supportare questi comportamenti correttamente, ove applicabile.
Assicurati di esaminare anche l'elenco delle modifiche del comportamento che interessano tutte le app eseguite 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 layout e stili personalizzati. Ciò ha causato la presenza di anti-pattern che potrebbero confondere gli utenti o causare problemi di compatibilità del layout su dispositivi diversi.
Per le app che hanno come target Android 12, le notifiche con visualizzazioni di contenuti personalizzate non utilizzeranno più l'intera area di notifica; 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 della notifica e le autorizzazioni di espansione (in stato compresso), l'icona della notifica, il nome dell'app e l'Andance di compressione (in 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.
La seguente illustrazione mostra una notifica personalizzata nel modello standard:
I seguenti esempi mostrano come le notifiche personalizzate vengono visualizzate in stato compresso e espanso:
La modifica in Android 12 interessa le app che definiscono sottoclassi personalizzate di
Notification.Style
o che utilizzano i metodi
setCustomContentView(RemoteViews)
setCustomBigContentView(RemoteViews)
e setCustomHeadsUpContentView(RemoteViews)
di
Notification.Builder
.
Se la tua app utilizza notifiche completamente personalizzate, ti consigliamo di eseguire il test con il nuovo modello il prima possibile.
Attiva la modifica per le notifiche personalizzate:
- Cambia l'impostazione
targetSdkVersion
dell'app inS
per attivare il nuovo comportamento. - Ricompila.
- Installa la tua app su un dispositivo o emulatore con Android 12.
- Cambia l'impostazione
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, c'è meno spazio in orizzontale.
Tutte le notifiche sono espandibili per le app destinate ad Android 12. In genere, questo significa che se utilizzi
setCustomContentView
, dovrai utilizzare anchesetBigCustomContentView
per assicurarti che gli stati compressi ed espansi siano coerenti.Per assicurarti che lo stato "Guarda avanti" abbia l'aspetto previsto, non dimenticare di aumentare l'importanza del canale di notifica impostandola su "ALTA" (Apparirà sullo schermo).
Modifiche alla verifica con Link per app Android
Sulle 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 offrono un maggiore controllo agli sviluppatori di app e agli utenti finali.
Se ti affidi alla verifica tramite link per app Android per aprire i link web nella tua app, assicurati di utilizzare il formato corretto quando aggiungi filtri di intent per la verifica tramite 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 della tua app per testare l'affidabilità delle tue dichiarazioni.
Miglioramenti del comportamento della modalità 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 sia per la navigazione tramite gesti che per la navigazione basata su elementi.
Per ulteriori informazioni, vedi Miglioramenti alla funzionalità Picture in picture.
Nuovo design per i toast
In Android 12, la visualizzazione toast è stata rinnovata. I toast ora sono limitati a due righe di testo e mostrano l'icona dell'applicazione accanto al testo.
Per ulteriori dettagli, vedi 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 garantire maggiore sicurezza e privacy, nonché per 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 determina se questo può essere inviato con qualsiasi
richiesta o solo con le richieste dello stesso sito. Le seguenti modifiche alla tutela della privacy migliorano la gestione predefinita dei cookie di terze parti e contribuiscono a proteggerti dalla condivisione accidentale tra siti:
- I cookie senza un attributo
SameSite
vengono trattati comeSameSite=Lax
. - I cookie con
SameSite=None
devono specificare anche l'attributoSecure
, ovvero 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, pertanto i cookie non vengono inviati, a meno che non siano contrassegnati correttamente come
SameSite=None; Secure
.
Per gli sviluppatori è buona norma identificare le dipendenze dei cookie tra siti nei flussi utente critici e assicurarsi che l'attributo SameSite
sia impostato esplicitamente con i valori appropriati, ove necessario. Devi specificare esplicitamente i cookie che possono funzionare su 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.
Testare 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. Se riscontri problemi, potrebbe essere necessario aggiornare i cookie per supportare i nuovi comportamenti SameSite.
Controlla la presenza di problemi di accesso e contenuti incorporati, nonché flussi di accesso, acquisti e altri flussi di autenticazione in cui l'utente inizia su una pagina non sicura e passa a una pagina protetta.
Per testare un'app con WebView, devi abilitare i nuovi comportamenti di SameSite per l'app che vuoi testare completando uno dei seguenti passaggi:
Attiva manualmente i comportamenti di SameSite sul dispositivo di test attivando/disattivando il flag dell'interfaccia utente 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 versione 89.0.4385.0 o successive.
Compila la tua app per avere 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 di WebView su Android, consulta la pagina Iniziare a utilizzare il debug remoto dei dispositivi Android.
Altre risorse
Per ulteriori informazioni sui comportamenti moderni di SameSite e sull'implementazione in Chrome e WebView, visita la pagina degli aggiornamenti di Chromium SameSite. Se trovi un bug in WebView o Chromium, puoi segnalarlo nel tracker dei problemi pubblico di Chromium.
I sensori di movimento hanno una frequenza limitata
Per proteggere le 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 provenienti da determinati sensori di movimento e sensori di posizione.
Scopri di più sulla limitazione di frequenza del sensore.
Ibernazione delle app
Android 12 espande il comportamento di reimpostazione automatica delle autorizzazioni introdotto in Android 11 (livello API 30). Se la tua app è destinata ad Android 12 e l'utente non interagisce con l'app per alcuni mesi, il sistema reimposta automaticamente le autorizzazioni concesse e mette la tua app nello stato di ibernazione.
Leggi ulteriori informazioni 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 dell'app.
Limitazione backup ADB
Per contribuire a proteggere i dati privati dell'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 per i test o lo sviluppo si basano sui 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 dei componenti più sicura
Se la tua app ha come target Android 12 o versioni successive e contiene attività, servizi o ricevitori di trasmissione che utilizzano filtri 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 contenente 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 ricevitore di trasmissione che utilizza
filtri di 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:
Nel file manifest viene visualizzato il seguente avviso lint:
When using intent filters, please specify android:exported as well
Quando tenti di compilare l'app, viene visualizzato il seguente messaggio di errore relativo alla 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 mostra 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'
Modificabilità 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 di mutabilità dell'intent in sospeso
Per determinare se nella tua app mancano dichiarazioni di mutabilità, cerca il seguente avviso di lint in Android Studio:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
Lanci per intent non sicuri
Per migliorare la sicurezza della piattaforma, Android 12 e versioni successive forniscono una funzionalità di debug che rileva lanci non sicuri degli intent. Quando il sistema rileva un avvio non sicuro, si verifica una violazione di tipo StrictMode.
Esibizione
Limitazioni relative al lancio di servizi in primo piano
Le app destinate ad Android 12 o versioni successive non possono avviare i servizi in primo piano mentre sono in esecuzione in background, tranne in alcuni casi speciali. Se un'app tenta di avviare un servizio in primo piano durante l'esecuzione in background, si verifica un'eccezione (tranne nei pochi casi speciali).
Valuta la possibilità di utilizzare WorkManager per pianificare e iniziare il lavoro accelerato mentre l'app viene eseguita in background. Per completare le azioni sensibili al fattore tempo 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 agli utenti. Scopri di più sui casi d'uso accettabili per impostare una sveglia esatta.
Disattiva la modifica del comportamento
Mentre prepari la tua app per avere come target Android 12, puoi disattivare temporaneamente la modifica del comportamento nella variante della build di cui è possibile eseguire il debug per scopi di test. Per farlo, completa una delle seguenti attività:
- Nella schermata dell'impostazione 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 macchina di sviluppo, esegui questo comando:
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
Limitazioni relative al trampolino per le 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 è noto come modello di trampolino di notifica.
Per migliorare le prestazioni e l'UX delle app, le app destinate ad Android 12 o
versioni successive non possono avviare attività dai servizi o
ricevitori di trasmissione utilizzati come
tabelle elastiche 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 ricevitore di trasmissione.
Quando la tua app tenta di avviare un'attività da un servizio o un ricevitore di trasmissioni che funge da trampolino di notifica, 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.
Identifica quali componenti dell'app fungono da trampolini di notifica
Quando testi l'app, dopo aver toccato una notifica puoi identificare il servizio o il ricevitore della trasmissione che ha eseguito la funzione di trampolino delle notifiche nella tua app. Per farlo, esamina 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 dopo aver toccato una notifica.
Aggiorna la tua app
Se la tua app avvia un'attività da un servizio o da un ricevitore che funge da trampolino di notifica, completa i seguenti passaggi di migrazione:
- Crea un oggetto
PendingIntent
associato all'attività visualizzata dagli utenti dopo aver toccato la notifica. - 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 degli extra quando pubblichi la notifica. Per il logging centralizzato, utilizza ActivityLifecycleCallbacks o osservatori del ciclo di vita di Jetpack.
Attiva/disattiva il comportamento
Durante il test di una versione di cui è possibile eseguire il debug della tua 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) come target. Il backup e ripristino di Android ha due formati:
- Backup sul cloud:i dati utente vengono archiviati nel Google Drive di un utente per poter essere ripristinati in un secondo momento sul 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 usando 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 e Effettuare il backup di coppie chiave-valore con Android Backup Service.
Modifiche alla funzionalità di trasferimento D2D
Per le app eseguite su e che hanno come target Android 12 e versioni successive:
La specifica delle regole di inclusione ed esclusione con il meccanismo di configurazione XML non influisce sui trasferimenti D2D, anche se influisce comunque sul backup e ripristino basato su cloud (ad esempio i backup di Google Drive). Per specificare regole per i trasferimenti D2D, devi utilizzare la nuova configurazione trattata nella prossima sezione.
Sui dispositivi di alcuni produttori di dispositivi, se specifichi
android:allowBackup="false"
, vengono disattivati i backup su Google Drive, ma non i trasferimenti D2D per l'app.
Nuovo formato di inclusione ed esclusione
Le app eseguite su Android 12 e versioni successive che hanno come target Android 12 e versioni successive utilizzano un formato diverso per la configurazione XML. Questo formato rende esplicita la differenza tra il backup di Google Drive e il trasferimento D2D, richiedendo di specificare separatamente le regole di inclusione ed esclusione per i backup sul cloud e per il trasferimento D2D.
Facoltativamente, puoi anche utilizzarla per specificare le regole per il backup, nel qual caso la configurazione utilizzata in precedenza viene ignorata sui dispositivi con Android 12 o versioni successive. La configurazione meno recente è ancora necessaria per i dispositivi con Android 11 o versioni precedenti.
Modifiche al formato XML
Di seguito è riportato il formato utilizzato per la configurazione di 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 sono riportate 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 della guida al backup dei dati utente con Backup automatico.
Flag del manifest per le app
Indirizza le tue 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 con i dispositivi Bluetooth più facilmente, 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 della tua app. Anziché dichiarare un set di autorizzazioni Bluetooth legacy, dichiara un set più moderno di autorizzazioni Bluetooth.
Peer-to-peer simultanei + 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 a internet simultanee possono mantenere connessioni Wi-Fi simultanee sia al dispositivo peer che alla rete principale che fornisce internet, rendendo l'esperienza utente più fluida. Le app destinate ad 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
solo per 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 valore
WifiInfo
. - Se è disponibile più di una rete Wi-Fi e l'app per le chiamate ha attivato una connessione peer-to-peer, il
WifiInfo
corrispondente al dispositivo peer viene restituito. - Se è disponibile più di una rete Wi-Fi e l'app per le chiamate non ha attivato una connessione peer-to-peer, viene restituita la connessione
WifiInfo
della connessione 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 quelle che attivano connessioni peer-to-peer, evitando le chiamate
WifiManager.getConnectionInfo()
, utilizzando invece
NetworkCallback.onCapabilitiesChanged()
per recuperare tutti gli oggetti WifiInfo
che corrispondono al valore NetworkRequest
utilizzato per registrare
NetworkCallback
. L'elemento 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 mDNS Replyer
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 mDNSRispondier, 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, determinando un risveglio più frequente del sistema e un consumo maggiore. 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 interrompe successivamente.
Poiché questa modifica influisce sulla disponibilità del daemon mDNSResponder, le app che presuppongono che il daemon mDNSResponder venga avviato dopo la chiamata del metodo getSystemService()
potrebbero ricevere messaggi dal sistema che indicano che il daemon mDNSResponder non è disponibile. Le app che usano 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 silicon 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 è necessario. In questo caso, qualsiasi libreria condivisa nativa è accessibile indipendentemente dal fatto che sia una libreria NDK.
Limitazioni non SDK aggiornate
Android 12 include elenchi aggiornati di interfacce non SDK limitate in base alla collaborazione con gli sviluppatori Android e ai test interni più recenti. Quando possibile, ci assicuriamo che siano disponibili alternative pubbliche prima di limitare le interfacce non SDK.
Se la tua app non è destinata ad Android 12, alcune di queste modifiche potrebbero non essere applicabili immediatamente. Tuttavia, anche se al momento puoi utilizzare alcune interfacce non SDK (a seconda del livello API target della tua app), l'utilizzo di metodi o campi non SDK comporta sempre un rischio elevato di danneggiare la tua app.
Se non hai la certezza che la tua app utilizzi interfacce non SDK, puoi testare l'app per scoprirlo. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare una migrazione alle alternative SDK. Ciononostante, siamo consapevoli che alcune app hanno casi d'uso validi per l'utilizzo di interfacce non SDK. Se non riesci a trovare un'alternativa all'utilizzo di un'interfaccia non SDK per una funzionalità nella tua app, devi richiedere una nuova API pubblica.
Per scoprire di più sulle modifiche in questa release di Android, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 12. Per scoprire di più sulle interfacce non SDK in generale, consulta Restrizioni sulle interfacce non SDK.