Modifiche al comportamento di Android 5.0

Livello API: 21

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

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

Per una panoramica generale delle nuove funzionalità della piattaforma, leggi invece le caratteristiche principali di Android Lollipop.

Video

Dev Byte: novità di Android 5.0

Byte per sviluppatori: 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 la pagina Introduzione ad ART. Ecco alcune delle principali nuove funzionalità:

• Compilation AOT (anticipazione del tempo)
• Garbage collection (GC) migliorata
• Supporto del debug migliorato

La maggior parte delle app Android dovrebbe funzionare senza alcuna modifica ai sensi di ART. Tuttavia, alcune tecniche che funzionano su Dalvik non funzionano su ART. Per informazioni sui problemi più importanti, consulta Verifica del comportamento delle app su Android Runtime (ART). Presta particolare attenzione se:

• L'app utilizza Java Native Interface (JNI) per eseguire il codice C/C++.
• Utilizzi strumenti di sviluppo che generano codice non standard (ad esempio alcuni offuscatori).
• Utilizzi tecniche incompatibili con la compattazione della garbage collection.

Notifiche

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

Stile di material design

Le notifiche sono visualizzate con testo scuro su sfondi bianchi (o molto chiari) per abbinarsi ai nuovi widget di Material Design. Assicurati che tutte le notifiche vengano visualizzate correttamente con la nuova combinazione di colori. Se le notifiche sembrano errate, correggile:

• Utilizza setColor() per impostare un colore di contrasto in un cerchio dietro l'immagine dell'icona.
• Aggiorna o rimuovi gli asset che prevedono colori. Il sistema ignora tutti i canali non alfa nelle icone di azione e nell'icona di notifica principale. Devi presupporre che queste icone siano solo alpha. Il sistema disegna icone di notifica bianche e 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à. Usa invece i metodi Notification.Builder per aggiungere suoni e vibrazioni.

Se il dispositivo è impostato su RINGER_MODE_SILENT, viene attivata la nuova modalità di priorità. Il dispositivo lascia la modalità prioritaria se la imposti su RINGER_MODE_NORMAL o RINGER_MODE_VIBRATE.

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

Visibilità schermata di blocco

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

Se la notifica non contiene informazioni personali o se vuoi consentire il controllo della riproduzione di contenuti multimediali 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 presentano lo stato di riproduzione di contenuti multimediali o i controlli di trasporto, valuta l'utilizzo del nuovo modello Notification.MediaStyle anziché di un oggetto RemoteViews.RemoteView personalizzato. Qualunque sia l'approccio scelto, assicurati di impostare la visibilità della notifica su VISIBILITY_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ù oggetti RemoteControlClient sulla schermata di blocco. Per ulteriori informazioni, consulta Se la tua app utilizza RemoteControlClient.

Notifica in evidenza

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

Esempi di condizioni che possono attivare notifiche in evidenza includono:

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

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

Media Controls e RemoteControlClient

La classe RemoteControlClient è ora deprecata. Passa alla nuova API MediaSession il prima possibile.

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

Android 5.0 introduce un nuovo modello Notification.MediaStyle per 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 metodo setSession() per comunicare al 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 in qualsiasi schermata di blocco (sicura o di altro tipo). Per maggiori informazioni, vedi Notifiche nella schermata di blocco.

Per visualizzare i controlli per la riproduzione di contenuti multimediali se la tua app è in esecuzione sulla piattaforma Android TV o Wear, implementa la classe MediaSession. Devi implementare MediaSession anche se la tua app deve ricevere eventi relativi ai pulsanti multimediali sui dispositivi Android.

getRecentTasks()

Con l'introduzione della nuova funzionalità Attività e documenti simultanei in Android 5.0 (consulta la sezione Attività e documenti simultanei nella schermata Recenti di seguito), il metodo ActivityManager.getRecentTasks() è ora deprecato per migliorare la privacy degli utenti. Per la compatibilità con le versioni precedenti, questo metodo restituisce comunque un piccolo sottoinsieme di dati, comprese le attività dell'applicazione chiamante e possibilmente alcune altre attività non sensibili (ad esempio Home). Se la tua app utilizza questo metodo per recuperare le proprie attività, usa 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 di indirizzi e migliora le prestazioni, pur supportando completamente le app a 32 bit esistenti. Il supporto del formato a 64 bit migliora anche le prestazioni di OpenSSL per la crittografia. Questa versione introduce inoltre nuove API NDK native multimediali e il supporto nativo per OpenGL ES (GLES) 3.1.

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

Associazione a un servizio

Il metodo Context.bindService() ora richiede un valore Intent esplicito e, se viene fornito un intent implicito, genera un'eccezione. Per garantire che la tua app sia sicura, utilizza un intent esplicito quando avvii o associ Service e non dichiarare filtri di 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:
  • Per impostazione predefinita, il sistema blocca i contenuti misti e i cookie di terze parti. Per consentire i contenuti misti e i cookie di terze parti, utilizza rispettivamente i metodi setMixedContentMode() e setAcceptThirdPartyCookies().
  • Ora il sistema sceglie in modo intelligente le parti del documento HTML da tracciare. Questo nuovo comportamento predefinito aiuta a ridurre l'ingombro della memoria e ad aumentare le prestazioni. Se vuoi eseguire il rendering dell'intero documento contemporaneamente, disabilita 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 visualizza sempre l'intero documento contemporaneamente.

Requisito di univocità per le autorizzazioni personalizzate

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

In alcuni casi, la definizione di autorizzazioni personalizzate è un approccio legittimo e sicuro. Tuttavia, a volte la creazione di autorizzazioni personalizzate non è necessaria e può persino introdurre potenziali rischi 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 di altre app che definiscono l'autorizzazione.

App che utilizzano autorizzazioni personalizzate duplicate

Qualsiasi app può definire qualsiasi autorizzazione personalizzata che vuole, pertanto è possibile che più app definiscano la stessa autorizzazione personalizzata. Ad esempio, se due app offrono una funzionalità simile, potrebbero derivare lo stesso nome logico delle loro autorizzazioni personalizzate. Le app possono anche incorporare librerie pubbliche comuni o esempi di codice che a loro volta includono le stesse definizioni di autorizzazioni personalizzate.

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

A partire da Android 5.0, il sistema applica una nuova limitazione di univocità sulle 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 cerca di installare un'app con un'autorizzazione personalizzata duplicata e non ha firmato con la stessa chiave dell'app residente che definisce l'autorizzazione, il sistema blocca l'installazione.

Considerazioni per l'app

In Android 5.0 e versioni successive, le app possono continuare a definire le proprie autorizzazioni personalizzate proprio come prima e a richiedere autorizzazioni personalizzate da 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 qualche elemento <permission> nel file manifest? In tal caso, sono effettivamente necessari per il corretto funzionamento della tua app o del tuo servizio? Oppure potresti utilizzare un'autorizzazione predefinita di sistema?
• Se la tua app contiene elementi <permission>, sai da dove vengono?
• Intendi che altre app richiedano le tue autorizzazioni personalizzate tramite <uses-permission>?
• Stai utilizzando un codice boilerplate o di esempio nella tua app che include elementi <permission>? Questi elementi di autorizzazione sono effettivamente necessari?
• Per le autorizzazioni personalizzate utilizzi nomi semplici o basati su termini comuni che altre app potrebbero condividere?

Nuove installazioni e aggiornamenti

Come accennato in precedenza, le nuove installazioni e gli aggiornamenti dell'app su dispositivi con Android 4.4 o versioni precedenti non sono interessati e non subiranno cambiamenti nel comportamento. Per le nuove installazioni e gli aggiornamenti su 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 dall'aggiornamento dei dispositivi ad Android 5.0 da parte degli utenti. Dopo l'installazione dell'aggiornamento di sistema, il sistema riconvalida le app installate, incluso un controllo delle relative autorizzazioni personalizzate. Se la tua app definisce un'autorizzazione personalizzata già definita da un'altra app già convalidata e l'app non è firmata con la stessa chiave dell'altra app, il sistema non reinstalla l'app.

Contenuti consigliati

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

• Se stai utilizzando autorizzazioni personalizzate nella tua app, valuta la loro origine e se ne hai effettivamente bisogno. Rimuovi tutti gli elementi <permission> dall'app, a meno che tu non abbia la certezza che siano necessari per il corretto funzionamento dell'app.
• Se possibile, sostituisci le autorizzazioni personalizzate con quelle predefinite di sistema.
• Se la tua app richiede autorizzazioni personalizzate, rinominale in modo che siano univoche per l'app, ad esempio aggiungendole al nome completo del pacchetto dell'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 venga 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 necessarie : il sistema consente di installare le app nel modo abituale.

Modifiche alla configurazione predefinita 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 ora sono abilitati,
• Le suite di crittografia AES-GCM (AEAD) sono ora abilitate
• Le suite di crittografia ECDH a chiave statica, MD5, 3DES e di esportazione sono ora disattivate.
• Le suite di crittografia Forward Secrecy (ECDHE e DHE) sono preferibili.

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

Tieni presente che il provider di sicurezza ProviderInstaller 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 nessuna delle suite di crittografia abilitate

Ad esempio, un server potrebbe supportare solo suite di crittografia 3DES o MD5. La soluzione migliore è migliorare la configurazione del server per abilitare suite di crittografia e protocolli più potenti e moderni. Idealmente, dovrebbero essere attivati TLSv1.2 e AES-GCM e dovrebbero essere abilitate e preferite le suite di crittografia Forward Secrecy (ECDHE, DHE).

Un'alternativa è modificare l'app per utilizzare SSLSocketFactory personalizzato per comunicare con il server. La fabbrica deve essere progettata per creare istanze SSLSocket con alcune delle suite di crittografia richieste dal server abilitate oltre alle suite di crittografia predefinite.

L'app non suppone correttamente le suite di crittografia utilizzate per la connessione al server

Ad esempio, alcune app contengono un X509TrustManager personalizzato che si interrompe perché prevede che il parametro authType sia RSA, ma rileva ECDHE_RSA o DHE_RSA.

Il server è intollerante a TLSv1.1, TLSv1.2 o alle nuove estensioni TLS

Ad esempio, l'handshake TLS/SSL con un server viene rifiutato erroneamente o si blocca. La soluzione migliore è eseguire l'upgrade del server per garantire la conformità al protocollo TLS/SSL. In questo modo il server negozierà correttamente questi protocolli più recenti o negozierà TLSv1 o i protocolli precedenti e ignorerà le estensioni TLS che non comprende. In alcuni casi, la disattivazione di TLSv1.1 e TLSv1.2 sul server può funzionare come misura temporanea fino all'upgrade del software del server.

Un'alternativa è modificare l'app per utilizzare SSLSocketFactory personalizzato per comunicare con il server. La fabbrica deve essere progettata per creare istanze SSLSocket con solo i protocolli abilitati correttamente supportati 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 e quest'ultimo ha il controllo del profilo gestito, lasciando il profilo personale e lo spazio di archiviazione dell'utente sotto il controllo dell'utente. Questa modifica può influire sul comportamento della tua app esistente nei modi seguenti.

Gestione degli intent

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

Per evitarlo, verifica che esista almeno un gestore per qualsiasi intent prima di attivarlo. Per verificare la presenza di un gestore valido, chiama Intent.resolveActivity(). Puoi vedere un esempio di questa operazione in Scatta foto semplicemente: scatta una foto con l'app Fotocamera.

Condivisione di file tra profili

Ogni profilo ha il proprio spazio di archiviazione per i file. Poiché l'URI di un file si riferisce a una posizione specifica nell'archiviazione dei file, significa che un URI del file valido su un profilo non è valido sull'altro. Questo non è di solito un problema per un'app, che di solito accede solo ai file che crea. Tuttavia, se un'app allega un file a un intent, non è sicuro allegare un URI del file, poiché in alcune circostanze l'intent potrebbe essere gestito sull'altro profilo. Ad esempio, un amministratore del dispositivo potrebbe specificare che gli eventi di acquisizione delle immagini devono essere gestiti dall'app Fotocamera sul 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 possono leggerla.

Per sicurezza, quando devi allegare un file a un intent 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 di contenuti, consulta Condivisione dei file. Ad esempio, l'amministratore del dispositivo potrebbe consentire alla fotocamera di gestire ACTION_IMAGE_CAPTURE nel profilo personale. L'elemento EXTRA_OUTPUT dell'intent di attivazione deve includere un URI di contenuti che specifichi dove archiviare la foto. L'app della fotocamera può scrivere l'immagine nella posizione specificata dall'URI e l'app che ha attivato l'intent potrebbe leggere il file, anche se si trova sull'altro profilo.

Supporto del widget della schermata di blocco rimosso

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