Modifiche al comportamento di Android 5.0

Livello API: 21

Oltre a nuove funzionalità e capacità, Android 5.0 include una serie di modifiche al sistema e al comportamento delle API. Questo documento mette in evidenza alcune delle modifiche principali che devi comprendere e tenere conto nelle tue app.

Se hai già pubblicato un'app per Android, tieni presente che la tua app potrebbe essere interessata da queste modifiche in Android 5.0.

Per una panoramica generale delle nuove funzionalità della piattaforma, consulta invece gli aspetti salienti di Android Lollipop.

Video

Dev Byte: le novità di Android 5.0

Dev Byte: notifiche

Runtime Android (ART)

In Android 5.0, il runtime ART sostituisce Dalvik come impostazione predefinita della piattaforma. Il runtime ART è stato introdotto in Android 4.4 su base sperimentale.

Per una panoramica delle nuove funzionalità di ART, consulta Introduzione a ART. Ecco alcune delle principali nuove funzionalità:

• Compilazione ahead-of-time (AOT)
• Garbage collection (GC) migliorata
• Supporto per il debug migliorato

La maggior parte delle app per Android dovrebbe funzionare senza modifiche in ART. Tuttavia, alcune tecniche che funzionano su Dalvik non funzionano su ART. Per informazioni sui problemi più importanti, consulta Verificare il comportamento delle app nell'ambiente di runtime Android (ART). Presta particolare attenzione se:

• La tua app utilizza l'interfaccia nativa Java (JNI) per eseguire codice C/C++.
• Utilizzi strumenti di sviluppo che generano codice non standard (ad esempio alcuni obfuscator).
• Utilizzi tecniche incompatibili con la raccolta del garbage collecting con compressione.

Notifiche

Assicurati che le notifiche tengano conto di queste modifiche di Android 5.0. Per scoprire di più sulla progettazione delle notifiche per Android 5.0 e versioni successive, consulta la guida al design delle notifiche.

Stile Material Design

Le notifiche sono disegnate con testo scuro su sfondi bianchi (o molto chiari) per abbinarsi ai nuovi widget in Material Design. Assicurati che tutte le notifiche abbiano un aspetto corretto con la nuova combinazione di colori. Se le notifiche sembrano sbagliate, correggile:

• Utilizza setColor() per impostare un colore di sfondo in un cerchio dietro l'immagine dell'icona.
• Aggiorna o rimuovi gli asset che includono il colore. Il sistema ignora tutti i canali non alfa nelle icone delle azioni e nell'icona di notifica principale. Devi assumere che queste icone saranno solo alpha. Il sistema disegna le icone di notifica in bianco e le icone di azione in grigio scuro.

Suoneria e vibrazione

Se al momento aggiungi suoni e vibrazioni alle notifiche utilizzando le classi Ringtone, MediaPlayer o Vibrator, rimuovi questo codice in modo che il sistema possa presentare correttamente le notifiche in modalità priorità. Utilizza invece i metodi Notification.Builder per aggiungere suoni e vibrazioni.

Se imposti il dispositivo su RINGER_MODE_SILENT, il dispositivo entrerà nella nuova modalità di priorità. Il dispositivo esce dalla modalità prioritaria se lo imposti su RINGER_MODE_NORMAL o RINGER_MODE_VIBRATE.

In precedenza, Android utilizzava STREAM_MUSIC come stream principale per regolare il volume sui tablet. In Android 5.0, lo stream del volume principale per smartphone e tablet è ora unificato e viene controllato da STREAM_RING o STREAM_NOTIFICATION.

Visibilità della schermata di blocco

Per impostazione predefinita, in Android 5.0 le notifiche vengono visualizzate nella schermata di blocco dell'utente. Gli utenti possono scegliere di proteggere le informazioni sensibili dall'esposizione, nel qual caso il sistema oscura automaticamente il testo visualizzato dalla notifica. Per personalizzare questa notifica oscurata, utilizza setPublicVersion().

Se la notifica non contiene informazioni personali o se vuoi consentire il controllo della riproduzione multimediale nella notifica, chiama il metodo setVisibility() e imposta il livello di visibilità della notifica su VISIBILITY_PUBLIC.

Riproduzione di contenuti multimediali

Se stai implementando notifiche che mostrano lo stato della riproduzione dei contenuti multimediali o i controlli di trasporto, ti consigliamo di utilizzare il nuovo modello Notification.MediaStyle anziché un oggetto RemoteViews.RemoteView personalizzato. Qualunque approccio scelga, assicurati di impostare la visibilità della notifica suVISIBILITY_PUBLIC in modo che i controlli siano accessibili dalla schermata di blocco. Tieni presente che, a partire da Android 5.0, il sistema non mostra più gli oggetti RemoteControlClient nella schermata di blocco. Per ulteriori informazioni, consulta Se la tua app utilizza RemoteControlClient.

Notifica in evidenza

Ora le notifiche possono essere visualizzate in una piccola finestra mobile (chiamata anche notifica in primo piano) quando il dispositivo è attivo (ovvero sbloccato e con lo schermo acceso). Queste notifiche hanno un aspetto simile alla forma compatta della notifica, tranne per il fatto che la notifica in anteprima mostra anche i pulsanti di azione. Gli utenti possono eseguire un'azione su una notifica in anteprima o ignorarla senza uscire dall'app corrente.

Ecco alcuni esempi di condizioni che possono attivare le notifiche in evidenza:

• L'attività dell'utente è in modalità a schermo intero (l'app utilizza fullScreenIntent)
• La notifica ha priorità elevata e utilizza suonerie o vibrazioni

Se la tua app implementa le notifiche in uno di questi scenari, assicurati che le notifiche in evidenza vengano visualizzate correttamente.

Controlli multimediali e RemoteControlClient

La classe RemoteControlClient è stata ritirata. Passa alla nuova API MediaSession il prima possibile.

Le schermate di blocco in Android 5.0 non mostrano i controlli per i trasporti per MediaSession o RemoteControlClient. La tua app può invece fornire il controllo della riproduzione dei contenuti multimediali dalla schermata di blocco tramite una notifica. In questo modo, la tua app avrà un maggiore controllo sulla presentazione dei pulsanti multimediali, offrendo al contempo un'esperienza coerente agli utenti su dispositivi bloccati e sbloccati.

Android 5.0 introduce un nuovo Notification.MediaStyle modello a questo scopo. Notification.MediaStyle converte le azioni di notifica che hai aggiunto con Notification.Builder.addAction() in pulsanti compatti incorporati nelle notifiche di riproduzione dei contenuti multimediali della tua app. Passa il token di sessione al metodosetSession() per informare il sistema che questa notifica controlla una sessione multimediale in corso.

Assicurati di impostare la visibilità della notifica su VISIBILITY_PUBLIC per contrassegnarla come sicura da mostrare su qualsiasi schermata di blocco (sicura o meno). Per ulteriori informazioni, consulta la sezione Notifiche nella schermata di blocco.

Per visualizzare i controlli di riproduzione dei contenuti multimediali se la tua app è in esecuzione sulla piattaforma Android TV o Wear, implementa la classe MediaSession. Dovresti anche implementare MediaSession se la tua app deve ricevere eventi pulsanti media su dispositivi Android.

getRecentTasks()

Con l'introduzione della nuova funzionalità di attività e documenti contemporaneamente in Android 5.0 (vedi Attività e documenti contemporaneamente nella schermata Recenti di seguito), il metodo ActivityManager.getRecentTasks() è stato ritirato per migliorare la privacy dell'utente. Per la compatibilità con le versioni precedenti, questo metodo restituisce comunque un piccolo sottoinsieme dei suoi dati, incluse le attività dell'applicazione chiamante e, eventualmente, alcune altre attività non sensibili (come Home). Se la tua app utilizza questo metodo per recuperare le proprie attività, utilizza getAppTasks() per recuperare queste informazioni.

Supporto a 64 bit nell'NDK di Android

Android 5.0 introduce il supporto per i sistemi a 64 bit. Il miglioramento a 64 bit aumenta lo spazio degli indirizzi e migliora le prestazioni, supportando al contempo completamente le app a 32 bit esistenti. Il supporto a 64 bit migliora anche le prestazioni di OpenSSL per la crittografia. Inoltre, questa release introduce nuove API NDK per i media nativi, nonché il supporto nativo di OpenGL ES (GLES) 3.1.

Per utilizzare il supporto a 64 bit fornito in Android 5.0, scarica e installa la revisione 10c di NDK dalla pagina Android NDK. Per ulteriori informazioni su modifiche importanti e correzioni di bug all'NDK, consulta le note di rilascio della revisione 10c.

Associazione a un servizio

Il metodo Context.bindService() ora richiede un Intent esplicito e genera un'eccezione se viene fornito un intent implicito. Per garantire la sicurezza della tua app, utilizza un'intent esplicita quando avvii o leghi il tuo Service e non dichiarare i filtri intent per il servizio.

WebView

Android 5.0 modifica il comportamento predefinito della tua app.

• Se la tua app ha come target il livello API 21 o versioni successive:
  • Il sistema blocca per impostazione predefinita i contenuti misti e i cookie di terze parti. Per consentire contenuti misti e cookie di terze parti, utilizza rispettivamente i metodi setMixedContentMode() e setAcceptThirdPartyCookies().
  • Ora il sistema sceglie in modo intelligente le parti del documento HTML da disegnare. Questo nuovo comportamento predefinito contribuisce a ridurre l'impronta di memoria e ad aumentare le prestazioni. Se vuoi eseguire il rendering dell'intero documento contemporaneamente, disattiva questa ottimizzazione chiamando enableSlowWholeDocumentDraw().
• Se la tua app ha come target livelli API inferiori a 21: il sistema consente contenuti misti e cookie di terze parti e esegue sempre il rendering dell'intero documento contemporaneamente.

Requisito di unicità per le autorizzazioni personalizzate

Come descritto nella panoramica delle autorizzazioni, le app per Android possono definire autorizzazioni personalizzate per gestire l'accesso ai componenti in modo proprietario, senza utilizzare le autorizzazioni di sistema predefinite della piattaforma. Le app definiscono le autorizzazioni personalizzate negli elementi <permission> dichiarati nei file manifest.

Esistono alcuni scenari in cui la definizione di autorizzazioni personalizzate è un approccio legittimo e sicuro. Tuttavia, la creazione di autorizzazioni personalizzate è talvolta non necessaria e può persino comportare un potenziale rischio per un'app, a seconda del livello di protezione assegnato alle autorizzazioni.

Android 5.0 include una modifica del comportamento per garantire che solo un'app possa definire una determinata autorizzazione personalizzata, a meno che non sia firmata con la stessa chiave delle altre app che definiscono l'autorizzazione.

App che utilizzano autorizzazioni personalizzate duplicate

Qualsiasi app può definire qualsiasi autorizzazione personalizzata, pertanto può capitare che più app definiscano la stessa autorizzazione personalizzata. Ad esempio, se due app offrono una funzionalità simile, potrebbero avere lo stesso nome logico per le autorizzazioni personalizzate. Le app potrebbero anche incorporare librerie pubbliche comuni o esempi di codice che includono le stesse definizioni di autorizzazioni personalizzate.

In Android 4.4 e versioni precedenti, gli utenti potevano installare più app di questo tipo su un determinato dispositivo, anche se il sistema assegnava il livello di protezione specificato dall'app installata per prima.

A partire da Android 5.0, il sistema applica una nuova limitazione di unicità per le autorizzazioni personalizzate per le app firmate con chiavi diverse. Ora solo un'app su un dispositivo può definire una determinata autorizzazione personalizzata (in base al nome), a meno che l'altra app che definisce l'autorizzazione non sia firmata con la stessa chiave. Se l'utente tenta di installare un'app con un'autorizzazione personalizzata duplicata e non è firmata con la stessa chiave dell'app residente che definisce l'autorizzazione, il sistema blocca l'installazione.

Considerazioni per la tua app

In Android 5.0 e versioni successive, le app possono continuare a definire le proprie autorizzazioni personalizzate come prima e a richiedere autorizzazioni personalizzate ad altre app tramite il meccanismo <uses-permission>. Tuttavia, con il nuovo requisito introdotto in Android 5.0, devi valutare attentamente i possibili impatti sulla tua app.

Ecco alcuni aspetti da considerare:

• La tua app dichiara elementi <permission> nel file manifest? In caso affermativo, sono effettivamente necessari per il corretto funzionamento della tua app o del tuo servizio? In alternativa, potresti utilizzare un'autorizzazione predefinita di sistema?
• Se nella tua app sono presenti elementi <permission>, sai da dove provengono?
• Vuoi che altre app richiedano le tue autorizzazioni personalizzate tramite <uses-permission>?
• Nella tua app utilizzi codice boilerplate o di esempio che include elementi <permission>? Questi elementi di autorizzazione sono effettivamente necessari?
• Le tue autorizzazioni personalizzate utilizzano nomi semplici o basati su termini comuni che altre app potrebbero condividere?

Nuove installazioni e aggiornamenti

Come accennato sopra, le nuove installazioni e gli aggiornamenti della tua app sui dispositivi con Android 4.4 o versioni precedenti non sono interessati e il comportamento non cambia. Per le nuove installazioni e gli aggiornamenti sui dispositivi con Android 5.0 o versioni successive, il sistema impedisce l'installazione della tua app se definisce un'autorizzazione personalizzata già definita da un'app residente esistente.

Installazioni esistenti con aggiornamento di sistema Android 5.0

Se la tua app utilizza autorizzazioni personalizzate ed è ampiamente distribuita e installata, è possibile che venga interessata quando gli utenti aggiornano i propri dispositivi ad Android 5.0. Dopo l'installazione dell'aggiornamento di sistema, il sistema convalida nuovamente le app installate, incluso un controllo delle autorizzazioni personalizzate. Se la tua app definisce un'autorizzazione personalizzata già definita da un'altra app che è già stata convalidata e la tua app non è firmata con la stessa chiave dell'altra app, il sistema non reinstalla la tua app.

Consigli

Sui dispositivi con Android 5.0 o versioni successive, ti consigliamo di esaminare immediatamente la tua app, apportare le modifiche necessarie e pubblicare la versione aggiornata il prima possibile per i tuoi utenti.

• Se utilizzi autorizzazioni personalizzate nella tua app, valuta la loro origine e se ne hai effettivamente bisogno. Rimuovi tutti gli elementi <permission> dalla tua app, a meno che non sia certo che siano necessari per il corretto funzionamento della tua app.
• Se possibile, valuta la possibilità di sostituire le autorizzazioni personalizzate con quelle predefinite del sistema.
• Se la tua app richiede autorizzazioni personalizzate, rinominale in modo che siano univoche per la tua app, ad esempio aggiungendole al nome completo del pacchetto della tua app.
• Se hai una suite di app firmate con chiavi diverse e le app accedono a un componente condiviso tramite un'autorizzazione personalizzata, assicurati che l'autorizzazione personalizzata sia definita una sola volta nel componente condiviso. Le app che utilizzano il componente condiviso non devono definire l'autorizzazione personalizzata, ma devono richiedere l'accesso tramite il meccanismo <uses-permission>.
• Se hai una suite di app firmate con la stessa chiave, ogni app può definire le stesse autorizzazioni personalizzate in base alle necessità. Il sistema consente di installare le app nel solito modo.

Modifiche alla configurazione predefinita di TLS/SSL

Android 5.0 introduce modifiche alla configurazione TLS/SSL predefinita utilizzata dalle app per HTTPS e altro traffico TLS/SSL:

• I protocolli TLSv1.2 e TLSv1.1 sono ora abilitati,
• Le suite di crittografia AES-GCM (AEAD) sono ora attivate,
• Le suite di crittografia ECDH con chiavi statiche, MD5, 3DES ed esportazione sono ora disattivate.
• Sono preferibili le suite di crittografia con Forward Secrecy (ECDHE e DHE).

Queste modifiche potrebbero causare interruzioni della connettività HTTPS o TLS/SSL in un numero limitato di casi elencati di seguito.

Tieni presente che ProviderInstaller per la sicurezza di Google Play Services offre già queste modifiche su tutte le versioni della piattaforma Android a partire da Android 2.3.

Il server non supporta nessuno dei pacchetti di crittografia abilitati

Ad esempio, un server potrebbe supportare solo le suite di crittografia 3DES o MD5. La correzione preferita è migliorare la configurazione del server per attivare protocolli e suite di crittografia più efficaci e moderni. Idealmente, TLS 1.2 e AES-GCM devono essere attivati e i pacchetti di crittografia con segretezza in avanti (ECDHE, DHE) devono essere attivati e preferiti.

Un'alternativa è modificare l'app in modo da utilizzare un'istanza SSLSocketFactory personalizzata per comunicare con il server. La factory deve essere progettata per creare istanze SSLSocket in cui sono abilitate alcune delle suite di crittografia richieste dal server, oltre alle suite di crittografia predefinite.

L'app fa supposizioni errate sulle suite di crittografia utilizzate per connettersi al server

Ad esempio, alcune app contengono un X509TrustManager personalizzato che si arresta in modo anomalo perché si aspetta che il parametro authType sia RSA, ma rileva ECDHE_RSA o DHE_RSA.

Il server non è tollerante nei confronti di TLS 1.1, TLS 1.2 o delle nuove estensioni TLS

Ad esempio, l'handshake TLS/SSL con un server viene rifiutato erroneamente o si blocca. La soluzione preferita è eseguire l'upgrade del server in modo che sia conforme al protocollo TLS/SSL. In questo modo, il server negozierà correttamente questi protocolli più recenti o negozierà TLS 1.0 o protocolli precedenti e ignorerà le estensioni TLS che non conosce. In alcuni casi, la disattivazione di TLSv1.1 e TLSv1.2 sul server può essere una misura temporanea fino all'upgrade del software del server.

Un'alternativa è modificare l'app in modo da utilizzare un'istanza SSLSocketFactory personalizzata per comunicare con il server. La factory deve essere progettata per creare istanza di SSLSocket con solo i protocolli abilitati supportati correttamente dal server.

Supporto per i profili gestiti

Gli amministratori dei dispositivi possono aggiungere un profilo gestito a un dispositivo. Questo profilo è di proprietà dell'amministratore, che ha il controllo sul profilo gestito, lasciando al contempo l'utente il controllo sul suo profilo personale e sullo spazio di archiviazione. Questa modifica può influire sul comportamento della tua app esistente nei seguenti modi.

Gestione degli intent

Gli amministratori del dispositivo possono limitare l'accesso alle applicazioni di sistema dal profilo gestito. In questo caso, se un'app attiva un intent dal profilo gestito che in genere verrebbe gestito dall'applicazione e non esiste un gestore adatto per l'intent nel profilo gestito, l'intent genera un'eccezione. Ad esempio, l'amministratore del dispositivo può impedire alle app nel profilo gestito di accedere all'applicazione della videocamera di sistema. Se la tua app è in esecuzione nel profilo gestito e chiama startActivityForResult() per MediaStore.ACTION_IMAGE_CAPTURE e non è presente alcuna app nel profilo gestito in grado di gestire l'intent, si verifica un ActivityNotFoundException.

Puoi evitarlo controllando che sia presente almeno un gestore per ogni intent prima di attivarlo. Per verificare la presenza di un gestore valido, chiama Intent.resolveActivity(). Puoi vedere un esempio di come eseguire questa operazione in Scattare foto in modo semplice: scattare una foto con l'app Fotocamera.

Condivisione di file tra profili

Ogni profilo ha il proprio spazio di archiviazione dei file. Poiché un URI file fa riferimento a una posizione specifica nello spazio di archiviazione dei file, un URI file valido in un profilo non è valido nell'altro. Di solito non è un problema per un'app, che in genere accede solo ai file che crea. Tuttavia, se un'app collega un file a un intent, non è sicuro allegare un URI file, poiché in alcune circostanze l'intent potrebbe essere gestito nell'altro profilo. Ad esempio, un amministratore del dispositivo potrebbe specificare che gli eventi di acquisizione di immagini devono essere gestiti dall'app Fotocamera nel profilo personale. Se l'intent viene attivato da un'app nel profilo gestito, la videocamera deve essere in grado di scrivere l'immagine in una posizione in cui le app del profilo gestito possano leggerla.

Per sicurezza, quando devi allegare un file a un'intenzione che potrebbe passare da un profilo all'altro, devi creare e utilizzare un URI dei contenuti per il file. Per ulteriori informazioni sulla condivisione di file con URI dei contenuti, vedi Condividere file. Ad esempio, l'amministratore del dispositivo potrebbe consentire il controllo di ACTION_IMAGE_CAPTURE dalla videocamera nel profilo personale. Il EXTRA_OUTPUT dell'intent di attivazione deve contenere un URI di contenuti che specifica dove deve essere archiviata la foto. L'app Fotocamera può scrivere l'immagine nella posizione specificata dall'URI e l'app che ha attivato l'intent sarà in grado di leggere il file, anche se si trova nell'altro profilo.

Supporto dei widget della schermata di blocco rimosso

Android 5.0 rimuove il supporto dei widget della schermata di blocco, ma continua a supportare i widget nella schermata Home.