Oltre a nuove funzionalità, Android 6.0 (livello API 23) include una serie di modifiche al sistema e al comportamento delle API. Questo documento evidenzia alcune delle modifiche principali che dovresti comprendere e tenere presenti nelle tue app.
Se hai già pubblicato un'app per Android, tieni presente che queste modifiche della piattaforma influiscono sulla tua app.
Autorizzazioni di runtime
Questa release introduce un nuovo modello di autorizzazioni in cui gli utenti possono gestire direttamente le autorizzazioni app in fase di runtime. Questo modello offre agli utenti maggiore visibilità e controllo sulle autorizzazioni, semplificando al contempo i processi di installazione e aggiornamento automatico per gli sviluppatori di app. Gli utenti possono concedere o revocare le autorizzazioni singolarmente per le app installate.
Sulle app destinate ad Android 6.0 (livello API 23) o versioni successive, assicurati di verificare la presenza di autorizzazioni e di richiedere le autorizzazioni in fase di runtime. Per determinare se all'app è stata concessa un'autorizzazione, chiama il
nuovo metodo
checkSelfPermission()
. Per richiedere un'autorizzazione, chiama il nuovo metodo requestPermissions()
. Anche se la tua app non ha come target Android 6.0 (livello API 23), devi testare l'app in base al nuovo modello di autorizzazioni.
Per maggiori dettagli sul supporto del nuovo modello di autorizzazioni nella tua app, consulta Utilizzo delle autorizzazioni di sistema. Per suggerimenti su come valutare l'impatto sulla tua app, consulta Note sull'utilizzo delle autorizzazioni.
Sospensione e standby delle app
Questa release introduce nuove ottimizzazioni per il risparmio energetico per le app e i dispositivi inattivi. Queste funzionalità interessano tutte le app, pertanto assicurati di testare le tue app in queste nuove modalità.
- Sospensione. Se un utente scollega un dispositivo e lo lascia fermo, con lo schermo spento, per un determinato periodo di tempo, il dispositivo entra in modalità Sospensione, in cui prova a mantenere il sistema in stato di sospensione. In questa modalità, i dispositivi riprendono periodicamente le normali operazioni per brevi periodi di tempo, in modo che possa avvenire la sincronizzazione delle app e il sistema possa eseguire eventuali operazioni in sospeso.
- Standby delle app. La modalità standby delle app consente al sistema di stabilire che un'app è inattiva quando l'utente non la utilizza attivamente. Il sistema determina se l'utente non tocca l'app per un determinato periodo di tempo. Se il dispositivo è scollegato, il sistema disabilita l'accesso alla rete e sospende le sincronizzazioni e i processi per le app che ritiene inattive.
Per scoprire di più su queste modifiche relative al risparmio energetico, consulta Ottimizzazione di sospensione e standby delle app.
Rimozione del client HTTP Apache
La release 6.0 di Android rimuove il supporto per il client HTTP Apache. Se la tua app utilizza questo client e ha come target Android 2.3 (livello API 9) o versioni successive, usa invece la classe HttpURLConnection
. Questa API è più efficiente perché riduce l'utilizzo della rete attraverso una memorizzazione nella cache trasparente di compressione e risposta e riduce al minimo il consumo di energia. Per continuare a utilizzare le API HTTP Apache, devi prima dichiarare la seguente dipendenza in fase di compilazione nel file build.gradle
:
android { useLibrary 'org.apache.http.legacy' }
BoringSSL
Android sta abbandonando OpenSSL nella libreria BoringSSL. Se nell'app utilizzi l'NDK di Android, non collegarti a librerie crittografiche che non fanno parte dell'API NDK, ad esempio libcrypto.so
e libssl.so
. Queste
librerie non sono API pubbliche e potrebbero subire modifiche o non funzionare senza preavviso tra le release e i dispositivi.
Inoltre, potresti esporti a vulnerabilità di sicurezza. Puoi invece modificare il tuo codice nativo per chiamare le API di crittografia Java tramite JNI o per collegarti in modo statico a una libreria di crittografia di tua scelta.
Accesso all'identificatore hardware
Per offrire agli utenti una maggiore protezione dei dati, a partire da questa release Android rimuove l'accesso programmatico all'identificatore hardware locale del dispositivo per le app che utilizzano le API Wi-Fi e Bluetooth. I metodi WifiInfo.getMacAddress()
e BluetoothAdapter.getAddress()
ora restituiscono un valore costante di 02:00:00:00:00:00
.
Per accedere agli identificatori hardware dei dispositivi esterni nelle vicinanze tramite la ricerca di Bluetooth e reti Wi-Fi,
la tua app deve ora disporre delle autorizzazioni ACCESS_FINE_LOCATION
o
ACCESS_COARSE_LOCATION
:
Nota: quando un dispositivo con Android 6.0 (livello API 23) avvia una scansione di reti Wi-Fi o Bluetooth in background, l'operazione è visibile ai dispositivi esterni in quanto ha origine da un indirizzo MAC casuale.
Notifiche
In questa release viene rimosso il metodo Notification.setLatestEventInfo()
. Utilizza invece il corso Notification.Builder
per creare notifiche. Per aggiornare più volte una notifica, riutilizza l'istanza Notification.Builder
. Chiama il metodo build()
per ottenere l'aggiornamento di Notification
istanze.
Il comando adb shell dumpsys notification
non stampa più il testo della notifica.
Utilizza il comando adb shell dumpsys notification --noredact
per stampare il testo
in un oggetto di notifica.
Modifiche all'AudioManager
L'impostazione diretta del volume o la disattivazione dell'audio di stream specifici tramite la classe AudioManager
non è più supportata. Il metodo setStreamSolo()
è deprecato, quindi devi chiamare il metodo requestAudioFocus()
. Allo stesso modo, il metodo setStreamMute()
è obsoleto; chiama invece il metodo adjustStreamVolume()
e passa nel valore della direzione ADJUST_MUTE
o ADJUST_UNMUTE
.
Selezione del testo
Quando gli utenti selezionano testo nella tua app, ora puoi mostrare azioni di selezione del testo, come Taglia, Copia e Incolla in una barra degli strumenti mobile. L'implementazione dell'interazione utente è simile a quella per la barra delle azioni contestuale, come descritto in Attivare la modalità di azione contestuale per singole viste.
Per implementare una barra degli strumenti mobile per la selezione del testo, apporta le seguenti modifiche nelle app esistenti:
- Nell'oggetto
View
oActivity
, modifica le chiamateActionMode
dastartActionMode(Callback)
astartActionMode(Callback, ActionMode.TYPE_FLOATING)
. - Prendi invece la tua implementazione esistente di
ActionMode.Callback
e amplialaActionMode.Callback2
. - Esegui l'override del metodo
onGetContentRect()
per fornire le coordinate dell'oggettoRect
dei contenuti (ad esempio un rettangolo di selezione del testo) nella vista. - Se il posizionamento del rettangolo non è più valido e questo è l'unico elemento da invalidare, chiama il metodo
invalidateContentRect()
.
Se utilizzi la versione 22.2 della
Android Support Library, tieni presente che le barre degli strumenti mobili non sono
compatibili con le versioni precedenti e appcompat assume il controllo di ActionMode
oggetti per impostazione predefinita. In questo modo si impedisce la visualizzazione delle barre degli strumenti mobili. Per abilitare il supporto ActionMode
in un AppCompatActivity
, chiama getDelegate()
, quindi chiama setHandleNativeActionModesEnabled()
sull'oggetto AppCompatDelegate
restituito e imposta il parametro di input su false
. Questa chiamata restituisce il controllo degli oggetti ActionMode
al framework. Nei dispositivi con Android 6.0 (livello API 23), che consente al framework di supportare le modalità ActionBar
o della barra degli strumenti mobile, sui dispositivi con Android 5.1 (livello API 22) o versioni precedenti sono supportate solo le modalità ActionBar
.
Modifiche ai preferiti nel browser
In questa release non sono più supportati i preferiti globali. I metodi android.provider.Browser.getAllBookmarks()
e android.provider.Browser.saveBookmark()
sono stati rimossi. Analogamente, le autorizzazioni READ_HISTORY_BOOKMARKS
e WRITE_HISTORY_BOOKMARKS
vengono rimosse. Se la tua app ha come target Android 6.0 (livello API 23) o versioni successive, non accedere ai preferiti del provider globale e non utilizzare le autorizzazioni relative ai preferiti. L'app dovrebbe invece archiviare
i dati dei preferiti internamente.
Modifiche all'archivio chiavi Android
Con questa release, il provider dell'archivio chiavi Android non supporta più i DSA. ECDSA è ancora supportato.
Le chiavi che non richiedono la crittografia at-rest non verranno più eliminate quando la schermata di blocco sicura viene disattivata o reimpostata (ad esempio, dall'utente o da un amministratore del dispositivo). Le chiavi che richiedono la crittografia at-rest verranno eliminate durante questi eventi.
Modifiche relative a Wi-Fi e rete
In questa release vengono introdotte le seguenti modifiche al comportamento delle API Wi-Fi e di rete.
- Ora le app possono modificare lo stato degli oggetti
WifiConfiguration
solo se li hai creati. Non puoi modificare o eliminareWifiConfiguration
oggetti creati dall'utente o da altre app. -
In precedenza, se un'app forzava il dispositivo a connettersi a una rete Wi-Fi specifica utilizzando
enableNetwork()
con l'impostazionedisableAllOthers=true
, il dispositivo si disconnetteva da altre reti, ad esempio la rete dati. In questa release, il dispositivo non si disconnette più da queste altre reti. Se iltargetSdkVersion
della tua app è“20”
o un valore inferiore, è bloccato sulla rete Wi-Fi selezionata. Se il valore ditargetSdkVersion
dell'app è“21”
o superiore, utilizza le API multirete (ad esempioopenConnection()
,bindSocket()
e il nuovo metodobindProcessToNetwork()
) per assicurarti che il relativo traffico di rete venga inviato sulla rete selezionata.
Modifiche al servizio della fotocamera
In questa release, il modello per l'accesso alle risorse condivise nel servizio della fotocamera è stato modificato da quello precedente "primo arrivato, primo servizio" a un modello di accesso in cui sono preferiti i processi ad alta priorità. Le modifiche al comportamento del servizio includono:
- L'accesso alle risorse del sottosistema della fotocamera, inclusa l'apertura e la configurazione di un dispositivo della fotocamera, viene assegnato in base alla "priorità" del processo dell'applicazione client. Ai processi di applicazione con attività visibili all'utente o in primo piano viene generalmente assegnata una priorità più alta, il che rende più affidabile l'acquisizione e l'utilizzo delle risorse della fotocamera.
- I client della fotocamera attivi per le app con priorità inferiore possono essere "rimossi" quando un'applicazione con priorità più alta tenta di utilizzare la fotocamera. Nell'API
Camera
deprecata,onError()
viene richiesto per il client rimosso. Nell'APICamera2
, viene chiamatoonDisconnected()
per il client eliminato. - Sui dispositivi con hardware della videocamera appropriato, processi applicativi separati possono aprire e utilizzare contemporaneamente dispositivi di videocamera separati. Tuttavia, i casi d'uso multi-processo, in cui l'accesso simultaneo causa un significativo peggioramento delle prestazioni o delle funzionalità di uno qualsiasi dei dispositivi della fotocamera aperti, ora vengono rilevati e non consentiti dal servizio della fotocamera. Questa modifica potrebbe comportare "espulsione" per i client con priorità inferiore, anche quando nessun'altra app tenta direttamente di accedere alla stessa fotocamera.
- La modifica dell'utente corrente comporta la rimozione dei client della fotocamera attivi nelle app di proprietà dell'account utente precedente. L'accesso alla fotocamera è limitato ai profili utente di proprietà dell'utente corrente del dispositivo. In pratica, ciò significa che un account "Ospite", ad esempio, non sarà in grado di abbandonare i processi in esecuzione che utilizzano il sottosistema della videocamera quando l'utente è passato a un altro account.
Durata
Il runtime ART ora implementa correttamente le regole di accesso per il metodo newInstance()
. Questa modifica risolve un problema per cui Dalvik controllava in modo errato le regole di accesso nelle versioni precedenti.
Se la tua app utilizza il metodo newInstance()
e vuoi eseguire l'override dei controlli di accesso, chiama il metodo setAccessible()
con il parametro di input impostato su true
. Se la tua app utilizza la libreria appcompat v7 o la libreria recyclerview v7, devi aggiornare l'app in modo che utilizzi le versioni più recenti di queste librerie. In caso contrario, assicurati che tutte le classi personalizzate a cui viene fatto riferimento in XML siano aggiornate in modo che i relativi costruttori delle classi siano accessibili.
Questa release aggiorna il comportamento del linker dinamico. Il linker dinamico ora comprende la differenza tra il soname
di una libreria e il relativo percorso (
bug pubblico 6670) e la ricerca per soname
è ora implementata. Le app che in precedenza funzionavano con voci DT_NEEDED
errate (di solito percorsi assoluti nel file system della macchina di compilazione) potrebbero restituire un errore quando vengono caricate.
Il flag dlopen(3) RTLD_LOCAL
è ora implementato correttamente. Tieni presente che RTLD_LOCAL
è l'impostazione predefinita, pertanto saranno interessate le chiamate a dlopen(3)
che non hanno utilizzato in modo esplicito RTLD_LOCAL
(a meno che la tua app non abbia utilizzato esplicitamente RTLD_GLOBAL
). Con RTLD_LOCAL
, i simboli non saranno disponibili per le librerie caricate dalle chiamate successive a dlopen(3)
(anziché le voci DT_NEEDED
).
Nelle versioni precedenti di Android, se la tua app richiedeva al sistema di caricare una libreria condivisa con
trasferimenti di testo, veniva mostrato un avviso, ma consentiva comunque il caricamento della libreria.
A partire da questa release, il sistema rifiuta questa libreria se la versione dell'SDK target dell'app è 23 o successive. Per aiutarti a rilevare se il caricamento di una libreria non è riuscito, la tua app deve registrare l'errore dlopen(3)
e includere il testo descrittivo del problema restituito dalla chiamata dlerror(3)
. Per saperne di più sulla gestione delle località di destinazione del testo, consulta questa guida.
Convalida APK
La piattaforma ora esegue una convalida più rigorosa degli APK. Un APK viene considerato danneggiato se nel file manifest viene dichiarato un file, ma non presente nell'APK stesso. Se uno qualsiasi dei contenuti viene rimosso, deve essere nuovamente firmato un APK.
Connessione USB
Le connessioni dei dispositivi tramite la porta USB sono ora impostate sulla modalità solo ricarica per impostazione predefinita. Per accedere al dispositivo e ai suoi contenuti tramite una connessione USB, gli utenti devono concedere esplicitamente l'autorizzazione per tali interazioni. Se l'app supporta le interazioni degli utenti con il dispositivo tramite una porta USB, tieni presente che l'interazione deve essere esplicitamente attivata.
Modifiche ad Android for Work
Questa release include le seguenti modifiche al comportamento di Android for Work:
- Contatti di lavoro in contesti personali. Google Dialer
Registro chiamate ora mostra i contatti di lavoro quando l'utente visualizza le chiamate precedenti.
Se imposti
setCrossProfileCallerIdDisabled()
sutrue
, i contatti del profilo di lavoro vengono nascosti nel registro chiamate di Google Dialer. I contatti di lavoro possono essere visualizzati insieme ai contatti personali sui dispositivi tramite Bluetooth solo se impostisetBluetoothContactSharingDisabled()
sufalse
. Il valore predefinito ètrue
. - Rimozione della configurazione Wi-Fi: le configurazioni Wi-Fi aggiunte da un proprietario del profilo (ad esempio tramite chiamate al metodo
addNetwork()
) vengono ora rimosse se il profilo di lavoro viene eliminato. - Blocco della configurazione Wi-Fi. Qualsiasi configurazione Wi-Fi creata da un proprietario del dispositivo attivo non può più essere modificata o eliminata dall'utente se il valore di
WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN
è diverso da zero. L'utente può comunque creare e modificare le proprie configurazioni Wi-Fi. I proprietari di dispositivi attivi hanno il privilegio di modificare o rimuovere qualsiasi configurazione Wi-Fi, incluse quelle non create da loro. - Scarica il controller dei criteri dei dispositivi tramite l'aggiunta di un Account Google: quando un Account Google che richiede la gestione tramite un'app controller dei criteri dei dispositivi (DPC) viene aggiunto a un dispositivo al di fuori di un contesto gestito, il flusso di aggiunta account ora chiede all'utente di installare il WPC appropriato. Questo comportamento vale anche per gli account aggiunti tramite Impostazioni > Account e nella configurazione guidata iniziale del dispositivo.
- Modifiche a comportamenti specifici dell'API
DevicePolicyManager
:- La chiamata del metodo
setCameraDisabled()
influisce sulla fotocamera solo per l'utente chiamante; la chiamata dal profilo gestito non influisce sulle app della fotocamera in esecuzione sull'utente principale. - Inoltre, il metodo
setKeyguardDisabledFeatures()
è ora disponibile per i proprietari del profilo e per i proprietari dei dispositivi. - Un proprietario di profilo può impostare le seguenti limitazioni per il blocco tastiera:
KEYGUARD_DISABLE_TRUST_AGENTS
eKEYGUARD_DISABLE_FINGERPRINT
, che influiscono sulle impostazioni del blocco tastiera per l'utente principale del profilo.KEYGUARD_DISABLE_UNREDACTED_NOTIFICATIONS
, che influisce solo sulle notifiche generate dalle applicazioni nel profilo gestito.
- I metodi
DevicePolicyManager.createAndInitializeUser()
eDevicePolicyManager.createUser()
sono stati ritirati. - Il metodo
setScreenCaptureDisabled()
ora blocca anche la struttura di evento indiretto quando un'app dell'utente specificato è in primo piano. - L'impostazione predefinita di
EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM
è SHA-256. SHA-1 è ancora supportato per compatibilità con le versioni precedenti, ma verrà rimosso in futuro.EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM
ora accetta solo SHA-256. - Le API di inizializzazione del dispositivo che esistevano in Android 6.0 (livello API 23) ora sono state rimosse.
EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS
è stato rimosso, pertanto il provisioning degli ostacoli NFC non può sbloccare in modo programmatico un dispositivo protetto contro il ripristino dei dati di fabbrica.- Ora puoi utilizzare il
EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
aggiuntivo per passare dati all'app del proprietario del dispositivo durante il provisioning NFC del dispositivo gestito. - Le API Android for Work sono ottimizzate per le autorizzazioni di runtime M, inclusi i profili di lavoro, il livello di assistenza e altro ancora. Le nuove API di autorizzazione
DevicePolicyManager
non interessano le app pre-M. - Quando gli utenti escono dalla parte sincrona del flusso di configurazione avviato tramite un intent
ACTION_PROVISION_MANAGED_PROFILE
oACTION_PROVISION_MANAGED_DEVICE
, il sistema ora restituisce un codice risultatoRESULT_CANCELED
.
- La chiamata del metodo
- Modifiche ad altre API:
- Utilizzo dei dati: la classe
android.app.usage.NetworkUsageStats
è stata rinominataNetworkStats
.
- Utilizzo dei dati: la classe
- Modifiche alle impostazioni generali:
- Non è più possibile configurare queste impostazioni tramite
setGlobalSettings()
:BLUETOOTH_ON
DEVELOPMENT_SETTINGS_ENABLED
MODE_RINGER
NETWORK_PREFERENCE
WIFI_ON
- Ora è possibile configurare queste impostazioni globali tramite
setGlobalSettings()
:
- Non è più possibile configurare queste impostazioni tramite