Modifiche ad Android 6.0

Oltre a nuove funzionalità, Android 6.0 (livello API 23) include una serie di modifiche di sistema e del comportamento delle API. Questo documento evidenzia alcune delle principali modifiche che devi comprendere e tenere in considerazione nelle tue app.

Se hai già pubblicato un'app per Android, tieni presente che queste modifiche nella piattaforma influiscono sulla tua app.

Autorizzazioni di runtime

Questa release introduce un nuovo modello di autorizzazioni in cui gli utenti possono ora 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 singolarmente le autorizzazioni per le app installate.

Sulle app destinate ad Android 6.0 (livello API 23) o versioni successive, assicurati di controllare e richiedere le autorizzazioni in fase di runtime. Per determinare se alla tua 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 testarla in base al nuovo modello di autorizzazioni.

Per maggiori dettagli sul supporto del nuovo modello di autorizzazioni nell'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 del risparmio energetico per app e dispositivi inattivi. Queste funzionalità interessano tutte le app, pertanto assicurati di testare le tue app nelle 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 tenta di mantenere il sistema in stato di sospensione. In questa modalità, i dispositivi riprendono periodicamente a funzionare normalmente 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: lo standby delle app consente al sistema di determinare che un'app è inattiva quando l'utente non la utilizza attivamente. Il sistema effettua questa determinazione quando l'utente non tocca l'app per un determinato periodo di tempo. Se il dispositivo non è collegato alla corrente, il sistema disattiva l'accesso alla rete e sospende le sincronizzazioni e i processi per le app che ritiene inattive.

Per ulteriori informazioni su queste modifiche relative al risparmio energetico, consulta Ottimizzazione di sospensione e standby delle app.

Rimozione del client HTTP Apache

La release Android 6.0 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, utilizza invece la classe HttpURLConnection. Questa API è più efficiente perché riduce l'utilizzo della rete tramite una memorizzazione nella cache trasparente di compressione e risposta, e riduce al minimo il consumo di energia. Per continuare a utilizzare le API Apache HTTP, devi prima dichiarare la seguente dipendenza in fase di compilazione nel file build.gradle: 

android {
    useLibrary 'org.apache.http.legacy'
}

BoringSSL

Android passerà da OpenSSL alla libreria BoringSSL. Se usi l'NDK di Android nella tua app, non effettuare il collegamento 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 cambiare o interrompersi senza preavviso nelle varie release e dispositivi. Inoltre, potresti esporti a vulnerabilità di sicurezza. Modifica il 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 Bluetooth e ricerche di reti Wi-Fi, la tua app ora deve 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 proviene da un indirizzo MAC casuale.

Notifiche

In questa release viene rimosso il metodo Notification.setLatestEventInfo(). Utilizza invece la classe Notification.Builder per creare notifiche. Per aggiornare ripetutamente una notifica, riutilizza l'istanza Notification.Builder. Chiama il metodo build() per ottenere l'aggiornamento delle istanze Notification.

Il comando adb shell dumpsys notification non stampa più il testo della notifica. Usa invece il comando adb shell dumpsys notification --noredact per stampare il testo in un oggetto notifica.

Modifiche AudioManager

L'impostazione diretta del volume o la disattivazione di stream specifici tramite la classe AudioManager non è più supportata. Il metodo setStreamSolo() è deprecato e devi invece chiamare il metodo requestAudioFocus(). Allo stesso modo, il metodo setStreamMute() viene ritirato. Al contrario, chiama il metodo adjustStreamVolume() e trasmetti il valore di direzione ADJUST_MUTE o ADJUST_UNMUTE.

Selezione del testo

Schermata che mostra nuove funzionalità di selezione del testo all'interno di una barra degli strumenti mobile

Quando gli utenti selezionano del testo nella tua app, ora puoi visualizzare 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 tue app esistenti:

  1. Nell'oggetto View o Activity, modifica le chiamate ActionMode da startActionMode(Callback) a startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Esegui invece l'implementazione esistente di ActionMode.Callback e ampliala ActionMode.Callback2.
  3. Esegui l'override del metodo onGetContentRect() per fornire le coordinate dell'oggetto Rect del contenuto (ad esempio un rettangolo di selezione del testo) nella vista.
  4. Se la posizione del rettangolo non è più valida e si tratta dell'unico elemento da invalidare, chiama il metodo invalidateContentRect().

Se utilizzi la versione 22.2 della libreria di supporto Android, tieni presente che le barre degli strumenti mobili non sono compatibili con le versioni precedenti e appcompat assume il controllo degli oggetti ActionMode 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, mentre sui dispositivi con Android 5.1 (livello API 22) o versioni precedenti sono supportate solo le modalità ActionBar.

Modifiche ai preferiti del browser

In questa release è stato rimosso il supporto per i preferiti globali. I metodi android.provider.Browser.getAllBookmarks() e android.provider.Browser.saveBookmark() sono stati rimossi. Analogamente, vengono rimosse le autorizzazioni READ_HISTORY_BOOKMARKS e WRITE_HISTORY_BOOKMARKS. Se la tua app ha come target Android 6.0 (livello API 23) o versioni successive, non accedere ai preferiti del provider globale o 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 di 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, da parte dell'utente o di un amministratore del dispositivo). Le chiavi che richiedono la crittografia at-rest verranno eliminate durante questi eventi.

Modifiche relative a Wi-Fi e rete

Questa release introduce le seguenti modifiche al comportamento delle API Wi-Fi e di rete.

  • Ora le tue app possono modificare lo stato degli oggetti WifiConfiguration solo se li hai creati. Non ti è consentito modificare o eliminare gli oggetti WifiConfiguration 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'impostazione disableAllOthers=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 il valore di targetSdkVersion della tua app è “20” o inferiore, è bloccato sulla rete Wi-Fi selezionata. Se il valore di targetSdkVersion della tua app è “21” o successivo, usa le API multinetwork (come openConnection(), bindSocket() e il nuovo metodo bindProcessToNetwork()) per assicurarti che il relativo traffico di rete venga inviato sulla rete selezionata.

Modifiche al servizio della fotocamera

In questa release, il modello per accedere alle risorse condivise nel servizio fotocamera è stato cambiato dal precedente modello di accesso "first come, first serve" 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, incluse l'apertura e la configurazione di un dispositivo videocamera, 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ù elevata, 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ù elevata tenta di utilizzare la fotocamera. Nell'API Camera deprecata, onError() viene richiesto il client rimosso. Nell'API Camera2, viene chiamato onDisconnected() per il client rimosso.
  • Sui dispositivi con hardware della fotocamera appropriato, processi applicativi separati sono in grado di aprire e utilizzare in modo indipendente dispositivi con videocamere separati. Tuttavia, i casi d'uso multi-processo in cui l'accesso simultaneo causa un significativo degrado delle prestazioni o delle funzionalità di qualsiasi dispositivo della fotocamera aperta, vengono ora rilevati e non consentiti dal servizio della fotocamera. Questa modifica potrebbe comportare l'eliminazione dei client con priorità inferiore anche quando nessun'altra app tenta direttamente di accedere alla stessa fotocamera.
  • Se modifichi l'utente corrente, i client fotocamera attivi nelle app di proprietà dell'account utente precedente vengono rimossi. L'accesso alla fotocamera è limitato ai profili utente di proprietà dell'attuale utente del dispositivo. In pratica, questo significa che un account "Ospite", ad esempio, non potrà 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 corregge 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 soname di una libreria e il relativo percorso ( bug pubblico 6670) e la ricerca tramite soname è ora implementata. Le app che in precedenza funzionavano con voci DT_NEEDED errate (di solito percorsi assoluti nel file system della macchina di build) potrebbero non funzionare al momento del caricamento.

Il flag dlopen(3) RTLD_LOCAL è ora implementato correttamente. Tieni presente che RTLD_LOCAL è l'impostazione predefinita, quindi saranno interessate le chiamate a dlopen(3) che non utilizzavano esplicitamente RTLD_LOCAL (a meno che la tua app non utilizzi esplicitamente RTLD_GLOBAL). Con RTLD_LOCAL, i simboli non saranno resi disponibili alle librerie caricate dalle chiamate successive a dlopen(3) (e non fanno riferimento alle voci DT_NEEDED).

Nelle versioni precedenti di Android, se la tua app richiedeva al sistema di caricare una libreria condivisa con trasferimenti del testo, veniva visualizzato un avviso, ma consentiva comunque il caricamento della libreria. A partire da questa release, il sistema rifiuta questa libreria se la versione dell'SDK di destinazione 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 della descrizione del problema restituito dalla chiamata dlerror(3). Per scoprire di più sulla gestione delle riassegnazioni del testo, consulta questa guida.

Convalida APK

La piattaforma ora esegue una convalida più rigorosa degli APK. Un APK viene considerato danneggiato se viene dichiarato un file nel file manifest, ma non presente nell'APK stesso. Se uno qualsiasi dei contenuti viene rimosso, è necessario firmare di nuovo l'APK.

Connessione USB

I collegamenti dei dispositivi tramite la porta USB sono ora impostati sulla modalità di sola ricarica per impostazione predefinita. Per accedere al dispositivo e ai suoi contenuti tramite una connessione USB, gli utenti devono concedere esplicitamente l'autorizzazione per queste interazioni. Se la tua 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. Il registro chiamate di Google Dialer ora mostra i contatti di lavoro quando l'utente visualizza le chiamate precedenti. Se imposti setCrossProfileCallerIdDisabled() su true, i contatti del profilo di lavoro vengono nascosti nel Registro chiamate di Google Telefono. I contatti di lavoro possono essere visualizzati insieme ai contatti personali sui dispositivi tramite Bluetooth solo se imposti setBluetoothContactSharingDisabled() su false. 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 viene aggiunto a un dispositivo al di fuori di un contesto gestito, il flusso per l'aggiunta di account ora chiede all'utente di installare il WPC appropriato. Questo comportamento si applica anche agli account aggiunti tramite Impostazioni > Account e nella configurazione guidata iniziale del dispositivo.
  • Modifiche a comportamenti specifici dell'API DevicePolicyManager:
    • La chiamata del metodo setCameraDisabled() ha effetto solo sulla videocamera dell'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 dei profili e per i proprietari dei dispositivi.
    • Il proprietario di un profilo può impostare le seguenti restrizioni per il blocco tastiera:
    • I metodi DevicePolicyManager.createAndInitializeUser() e DevicePolicyManager.createUser() sono stati ritirati.
    • Il metodo setScreenCaptureDisabled() ora blocca anche la struttura di assistenza quando un'app dell'utente in questione è in primo piano.
    • L'impostazione predefinita di EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM è SHA-256. SHA-1 è ancora supportato per la 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 dei dispositivi esistenti in Android 6.0 (livello API 23) sono state rimosse.
    • EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS è stato rimosso, pertanto il provisioning del contatto NFC non può sbloccare in modo programmatico un dispositivo protetto dopo il ripristino dei dati di fabbrica.
    • Ora puoi utilizzare l'opzione EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE aggiuntiva per trasmettere dati all'app del proprietario 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. Le nuove API di autorizzazione DevicePolicyManager non influiscono sulle app precedenti all'M.
    • Quando gli utenti escono dalla parte sincrona del flusso di configurazione avviato tramite un intent ACTION_PROVISION_MANAGED_PROFILE o ACTION_PROVISION_MANAGED_DEVICE, il sistema ora restituisce un codice risultato RESULT_CANCELED.
  • Modifiche ad altre API:
    • Utilizzo dei dati: la classe android.app.usage.NetworkUsageStats è stata rinominata NetworkStats.
  • Modifiche alle impostazioni globali: