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; viene applicato 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:
![](https://developer.android.com/static/images/about/versions/12/custom-collapsed-view.png?authuser=6&hl=it)
![](https://developer.android.com/static/images/about/versions/12/custom-expanded-view.png?authuser=6&hl=it)
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.
Attiva la modifica delle notifiche personalizzate:
- Cambia il
targetSdkVersion
dell'app inS
per attivare il nuovo comportamento. - Ricompila.
- Installa la tua app su un dispositivo o un emulatore con Android 12.
- Cambia il
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 utilizzaresetBigCustomContentView
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).
Modifiche alla verifica di Android App Links
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](https://developer.android.com/static/images/toast.png?authuser=6&hl=it)
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 comeSameSite=Lax
. - I cookie con
SameSite=None
devono specificare anche l'attributoSecure
, 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:
Nel file manifest viene visualizzato il seguente avviso di lint:
When using intent filters, please specify android:exported as well
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:
- Crea un oggetto
PendingIntent
che è associata all'attività che gli utenti vedono dopo aver toccato notifica. - 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 saperne di più sulle interfacce non SDK in generale, consulta Restrizioni relative alle interfacce non SDK di archiviazione.