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 modifiche principali che dovresti comprendere e tenere presenti 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 le caratteristiche principali di Android Lollipop.

Video

Byte per sviluppatori: 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 Introduzione ad ART. Alcune delle principali nuove funzionalità sono:

• Compilazione in anticipo (AOT)
• Garbage collection (GC) migliorata
• Supporto del debug migliorato

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

• La tua app utilizza Java Native Interface (JNI) per eseguire il codice C/C++.
• Utilizzi strumenti di sviluppo che generano codice non standard (come 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 ulteriori informazioni sulla progettazione delle notifiche per Android 5.0 e versioni successive, consulta la guida alla progettazione delle notifiche.

Stile del Material Design

Le notifiche sono disegnate con testo scuro su sfondi bianchi (o molto chiari) per abbinarsi ai nuovi widget 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 includono 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 traccia le icone di notifica bianche e quelle di azione di colore grigio scuro.

Suono 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 vibrazione.

L'impostazione del dispositivo su RINGER_MODE_SILENT determina l'attivazione della nuova modalità di priorità per il dispositivo. Il dispositivo esce dalla modalità Priorità 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 master per smartphone 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 mostrano lo stato di riproduzione di contenuti multimediali o controlli di trasporto, valuta l'utilizzo del nuovo modello Notification.MediaStyle anziché di un oggetto RemoteViews.RemoteView personalizzato. Qualunque sia l'approccio che scegli, 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ù gli oggetti RemoteControlClient sulla schermata di blocco. Per scoprire di più, consulta l'articolo Se la tua app utilizza RemoteControlClient.

Avviso

Le notifiche ora possono essere visualizzate in una piccola finestra mobile (detta anche notifica in evidenza) quando il dispositivo è attivo, ovvero se il dispositivo è sbloccato e lo schermo è attivo. Queste notifiche sono simili alla forma compatta della notifica, ad eccezione del fatto 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à elevata 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ò però fornire un controllo per la 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 su tutti i dispositivi bloccati e sbloccati.

Android 5.0 introduce un nuovo modello Notification.MediaStyle a questo scopo. Notification.MediaStyle converte le azioni di notifica aggiunte con Notification.Builder.addAction() in pulsanti compatti incorporati nelle notifiche di riproduzione dei contenuti multimediali dell'app. Passa il token di sessione al metodo setSession() 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 per la visualizzazione in qualsiasi schermata di blocco (protetta o meno). Per maggiori informazioni, consulta 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 dei pulsanti multimediali sui dispositivi Android.

getRecentTasks()

Con l'introduzione della nuova funzionalità per 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, incluse le attività dell'applicazione chiamante e possibilmente altre attività non sensibili (come la home page). 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 degli indirizzi e migliora le prestazioni, continuando a supportare completamente le app a 32 bit esistenti. Il supporto del formato a 64 bit migliora anche le prestazioni di OpenSSL per la crittografia. Inoltre, questa release introduce nuove API NDK native, nonché il supporto nativo per OpenGL ES (GLES) 3.1.

Per utilizzare il supporto del formato 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 dell'NDK.

Associazione a un servizio

Il metodo Context.bindService() ora richiede un valore Intent esplicito e genera un'eccezione se viene fornito un intent implicito. Per assicurarti che la tua app sia sicura, utilizza un intent esplicito quando avvii o associ Service e non dichiarare filtri per intent per il servizio.

WebView

Android 5.0 modifica il comportamento predefinito per la tua app.

• Se la tua app ha come target il livello API 21 o un livello successivo:
  • Il sistema blocca i contenuti misti e i cookie di terze parti per impostazione predefinita. Per consentire contenuti misti e cookie di terze parti, utilizza rispettivamente i metodi setMixedContentMode() e setAcceptThirdPartyCookies().
  • Il sistema ora sceglie in modo intelligente le parti del documento HTML da disegnare. Questo nuovo comportamento predefinito consente di ridurre l'ingombro di memoria e aumentare le prestazioni. Se vuoi eseguire il rendering dell'intero documento contemporaneamente, disabilita l'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 ed esegue sempre il rendering dell'intero documento in una sola volta.

Requisito di univocità per le autorizzazioni personalizzate

Come documentato nella panoramica sulle autorizzazioni, le app per Android possono definire autorizzazioni personalizzate come 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 un numero limitato di scenari in cui la definizione di autorizzazioni personalizzate è un approccio legittimo e sicuro. Tuttavia, a volte la creazione di autorizzazioni personalizzate non è necessaria e può anche introdurre 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 che vuole, pertanto può succedere che più app definiscano la stessa autorizzazione personalizzata. Ad esempio, se due app offrono una funzionalità simile, potrebbero derivare lo stesso nome logico delle relative 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 al sistema era assegnato il livello di protezione specificato dall'app installata per la prima volta.

A partire da Android 5.0, il sistema applica una nuova restrizione 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 (come determinato dal 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 sull'app

In Android 5.0 e versioni successive, le app possono continuare a definire le proprie autorizzazioni personalizzate esattamente 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 elementi <permission> nel file manifest? Se sì, sono effettivamente necessarie per il corretto funzionamento della tua app o del tuo servizio? Oppure 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>?
• Stai utilizzando boilerplate o codice di esempio nella tua app che include elementi <permission>? Questi elementi di autorizzazione sono effettivamente necessari?
• Per le autorizzazioni personalizzate vengono usati nomi semplici o basati su termini comuni che altre app potrebbero condividere?

Nuove installazioni e aggiornamenti

Come accennato in precedenza, per le nuove installazioni e gli aggiornamenti dell'app sui dispositivi con Android 4.4 o versioni precedenti non ci sono modifiche e non sono previste modifiche al 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 sia interessata dall'aggiornamento dei dispositivi ad Android 5.0 da parte degli utenti. In seguito all'installazione dell'aggiornamento di sistema, il sistema riconvalida le app installate, compreso 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 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> dall'app, a meno che tu non abbia la certezza che siano necessari per il corretto funzionamento dell'app.
• Se possibile, valuta la possibilità di sostituire le autorizzazioni personalizzate con quelle predefinite di 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 dell'app.
• Se hai una suite di app firmate con chiavi diverse e 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 una tua suite di app è firmata con la stessa chiave, ogni app può definire le stesse autorizzazioni personalizzate necessarie; il sistema consente di installare le app nel modo consueto.

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 sono ora 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 disabilitate.
• Sono preferite le suite di crittografia 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 il provider di sicurezza ProviderInstaller di Google Play Services offre già queste modifiche ad Android 2.3 per tutte le versioni della piattaforma Android.

Il server non supporta nessuna delle suite di crittografia abilitate

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

Un'alternativa è modificare l'app per utilizzare SSLSocketSocket personalizzato per comunicare con il server. Il valore di fabbrica dovrebbe essere progettato per creare istanze SSLSocket che dispongono di alcune delle suite di crittografia richieste dal server, oltre alle suite di crittografia predefinite.

L'app fa delle ipotesi errate sulle suite di crittografia utilizzate per la connessione al server

Ad esempio, alcune app contengono un elemento X509TrustManager personalizzato che si guasta 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 per errore o si blocca. La soluzione migliore è eseguire l'upgrade del server in modo che rispetti il protocollo TLS/SSL. In questo modo il server negozierà correttamente questi protocolli più recenti o negozierà TLSv1 o 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 SSLSocketSocket 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 al dispositivo. Questo profilo è di proprietà dell'amministratore e quest'ultimo ha il controllo del profilo gestito, lasciando il profilo personale e il relativo spazio di archiviazione sotto il controllo dell'utente. Questa modifica può influire sul comportamento della tua app esistente nei seguenti modi.

Gestione degli intent

Gli amministratori dei dispositivi possono limitare l'accesso alle applicazioni di sistema dal profilo gestito. In questo caso, se un'app attiva un intent dal profilo gestito che verrebbe normalmente gestito da quell'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 sul profilo gestito di accedere all'applicazione della fotocamera del sistema. Se la tua app è in esecuzione sul profilo gestito e chiama startActivityForResult() per MediaStore.ACTION_IMAGE_CAPTURE e sul profilo gestito non esiste alcuna app in grado di gestire l'intent, viene restituito un ActivityNotFoundException.

Puoi evitarlo controllando che esista almeno un gestore per qualsiasi intento prima di attivarlo. Per verificare la presenza di un gestore valido, chiama Intent.resolveActivity(). Puoi vederne un esempio in Scatta foto con l'app Fotocamera.

Condivisione di file tra profili

Ogni profilo dispone del proprio spazio di archiviazione di file. Poiché l'URI di un file fa riferimento a una posizione specifica nell'archiviazione dei file, ciò significa che l'URI di un 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 l'URI di un 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 delle immagini devono essere gestiti dall'app Fotocamera sul profilo personale. Se l'intent viene attivato da un'app nel profilo gestito, la fotocamera 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 può passare da un profilo all'altro, devi creare e utilizzare un URI di contenuto per il file. Per ulteriori informazioni sulla condivisione di file con URI dei contenuti, consulta Condivisione dei file. Ad esempio, l'amministratore del dispositivo potrebbe consentire la gestione di ACTION_IMAGE_CAPTURE da parte della videocamera nel profilo personale. L'elemento EXTRA_OUTPUT dell'intent di attivazione deve contenere un URI di contenuti che specifica dove archiviare la foto. L'app Fotocamera può scrivere l'immagine nella posizione specificata dall'URI e l'app che ha attivato l'intent sarebbe in grado di leggere il file, anche se l'app 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 e continua a supportare i widget nella schermata Home.