Esclusivo: 3 delle migliori funzionalità di Android 11 non saranno presenti su tutti i dispositivi

3 delle migliori funzionalità di Android 11 non verranno visualizzate su tutti gli smartphone e tablet. Questo perché Google non impone queste funzionalità.

Ogni anno Google rilascia una nuova versione del sistema operativo Android. Google ha rilasciato la prima anteprima per sviluppatori di Android 11 a febbraio, seguita dalla seconda, terza e quarta anteprima per sviluppatori negli ultimi mesi. All'inizio di questo mese, Google ha presentato il prima Android 11 Beta e ha parlato in modo approfondito delle migliori funzionalità che gli utenti possono apprezzare e che gli sviluppatori possono implementare. Tuttavia, ora abbiamo appreso che tre delle funzionalità principali di Android 11 non saranno disponibili su tutti i dispositivi Android.

Per capire come ciò sia possibile, dobbiamo spiegare brevemente come il sistema operativo Android viene distribuito da Google ai produttori di dispositivi smartphone. Android è un sistema operativo open source concesso in licenza con Apache 2.0, il che significa che chiunque, dagli sviluppatori indipendenti alle grandi aziende, è libero di modificare e distribuire il sistema operativo sui propri dispositivi. La maggior parte delle nuove funzionalità del sistema operativo che Google ha presentato per Android 11 faranno parte dell'Android Open Source Project (AOSP) che lo smartphone i produttori di dispositivi basano il proprio software su, ma la licenza Apache 2.0, come ho detto prima, consente a chiunque di modificare il software come ritiene adatto. Per mantenere la coerenza delle API e del comportamento della piattaforma tra i dispositivi Android, Google raggruppa la distribuzione di Google Mobile Services (che include applicazioni e framework come Google Play Store e Google Play Services) con contratti di licenza che impongono che i dispositivi rispettino le regole previste da Google "

Programma di compatibilità Android" (tra gli altri requisiti). Il Programma di compatibilità Android è costituito da più suite di test automatizzati e da una serie di regole enumerate nel programma Android Documento di definizione della compatibilità (CDDD).

Nel CDD, Google elenca le funzionalità software e hardware che i produttori di dispositivi "DEVONO" implementare, che sono solo "FORTEMENTE RACCOMANDATI" da implementare o "NON DOVREBBERO" implementare. Se una funzionalità è elencata come "OBBLIGATORIA" da implementare, il produttore del dispositivo deve aggiungerla altrimenti non potrà fornire app Google sui propri dispositivi. Se una funzionalità è elencata come "NON DOVREBBE" essere implementata, il produttore del dispositivo non può aggiungere tale funzionalità o non può raggruppare le app Google. Infine, se una funzionalità è elencata come "FORTEMENTE CONSIGLIATA", spetta al produttore del dispositivo decidere se desidera o meno implementare la funzionalità. Il CDD è un documento in continua evoluzione, ancor prima della sua pubblicazione ogni anno in seguito al rilascio pubblico di una nuova versione di Android. Google aggiorna frequentemente il documento per rimuovere funzionalità, cambiare il linguaggio per renderlo più chiaro e allentare i requisiti in base al feedback dei suoi partner. Tuttavia, una volta che Google renderà pubblico un CDD per una particolare versione di Android, tali requisiti verranno fissati nella pietra per i dispositivi certificati da Google che eseguono quella versione del sistema operativo Android.

Il CDD di Android 11 non diventerà pubblico fino alla fine di quest'anno, probabilmente all'inizio di settembre. Tuttavia, sviluppatore @deletescape ha condiviso una copia pre-rilascio di un documento che descrive in dettaglio le modifiche in arrivo al CDD, dandoci una prima occhiata a come Google sta dando forma ad Android 11 nell'ecosistema. La stragrande maggioranza delle oltre 60 modifiche apportate al CDD non sono molto interessanti per gli utenti: descrivono come i produttori di dispositivi devono implementare determinate API, dichiarare determinate funzionalità e implementare determinati kernel caratteristiche. Tuttavia, 3 delle modifiche al CDD hanno attirato la nostra attenzione perché riguardano alcune delle funzionalità più interessanti di Android 11. Ecco cosa abbiamo scoperto.

Controlli del dispositivo

Controlli dispositivo è una funzionalità di Android 11 che consente di visualizzare i controlli di automazione domestica intelligente nel menu di accensione. Puoi spegnere le luci, aprire la porta del garage, avviare l'aspirapolvere, modificare la temperatura della casa e fare molto altro senza aprire una dozzina di app diverse per la casa intelligente. Google ha aggiunto API che gli sviluppatori di app per la casa intelligente possono utilizzare per visualizzare i controlli nel menu di accensione. Pensiamo che questa sia una caratteristica interessante porta finalmente il tuo smartphone nella casa intelligente. Sfortunatamente, non vi è alcun obbligo per gli OEM di implementarlo effettivamente. Se un OEM ritiene che la funzionalità sia scadente o desidera intraprendere una strada diversa (ad esempio consentendo solo smart controlli domestici dai dispositivi nel proprio ecosistema), possono semplicemente disabilitare il supporto per Dispositivo Controlli.

Quando Google ha aggiunto per la prima volta i controlli dispositivo al CDD il 25 febbraio 2020, ne ha imposto l'inclusione aggiungendo un requisito "MUST" nella Sezione 2.2.3 - Requisiti software del palmare. Tuttavia, il 20 maggio 2020, Google ha aggiornato il testo per rimuovere il "MUST" proposto. La nuova Sezione 3.8.16 - Controlli dispositivo delinea come deve essere implementata la funzionalità ma in realtà non richiede che venga implementata in primo luogo! Ci auguriamo che gli OEM non disabilitino questa interessante funzionalità, ma non c'è modo per noi di sapere se l'hanno disabilitata finché non lo pronti a svelare le proprie versioni di Android basate su Android 11, cosa che avverrà solo tra diversi mesi Ora.

Sezione 3.8.16 proposta (nuova) - Controlli del dispositivo (aggiornata il 20/05/2020)

3.8.16 Controlli del dispositivo

Android include ControlsProviderService e API di controllo per consentire agli sviluppatori di pubblicare controlli del dispositivo per informazioni rapide su stato e azioni per gli utenti.

3.8.16.1 Il dispositivo controlla la disponibilità dell'utente

Se i dispositivi implementano i Controlli dispositivo, allora:

  • [C-1-1] DEVE segnalare che il flag android.software.controls.feature è TRUE
  • [C-1-2] DEVE fornire all'utente la possibilità di aggiungere, modificare, selezionare e utilizzare i preferiti dell'utente dai controlli registrati dalle app di terze parti tramite android.service.controls. ControlsProviderService e android.service.controls. API di controllo.
  • [C-1-3] DEVE fornire l'accesso a questa affordance utente entro tre interazioni dal Launcher
  • [C-1-4] DEVE rappresentare accuratamente in questa affordance utente il nome e l'icona di ogni app di terze parti che fornisce controlli tramite android.service.controls. ControlsProviderService API nonché qualsiasi icona, testo di stato, tipo di dispositivo, nome, struttura, zona, colore personalizzato e sottotitolo specificati forniti da android.service.controls. API di controllo

Al contrario, se le implementazioni dei dispositivi non implementano tali controlli, allora lo faranno

  • [C-2-1] DEVE riportare Null per ControlsProviderService e le API di controllo.

Per saperne di più

Conversazioni nelle notifiche

Conversazioni su Android 11. Fonte: Google

Uno dei maggiori vantaggi di Android rispetto a iOS è il modo in cui il primo gestisce le notifiche. Questo divario nell’usabilità diventerà ancora più ampio in Android 11 con l’introduzione di “Conversazioni”. In Android 11, notifiche dalle app di messaggistica sono raggruppati e visualizzati in una sezione separata nel pannello delle notifiche sopra la maggior parte delle altre notifiche. Ciò ti consente di visualizzare e rispondere rapidamente ai messaggi senza dover scorrere tutte le altre notifiche in sospeso. Sfortunatamente, questa elegante modifica alle notifiche potrebbe non essere disponibile su tutti i dispositivi. Google offre agli OEM la possibilità di scegliere se desiderano "raggruppare e visualizzare in anticipo le notifiche delle conversazioni". notifiche non di conversazione." Gli OEM personalizzano spesso il pannello delle notifiche, quindi non sorprende che Google offra agli OEM una scelta qui. Tuttavia, è un peccato che Google non scelga di applicare una maggiore coerenza nelle notifiche in Android 11.

Modifiche proposte al Paragrafo 3.8.3.1 - Presentazione delle Notifiche (Aggiornato il 4/08/2020)

Se le implementazioni del dispositivo consentono alle app di terze parti di avvisare gli utenti di eventi importanti, queste:

...

Android R introduce il supporto per la notifica di conversazione, ovvero una notifica che utilizza NotificationManager. MessageStyle e fornisce un ID collegamento persone pubblicato.

Le implementazioni del dispositivo sono:

  • [H-SR] FORTEMENTE CONSIGLIATO per raggruppare e visualizzare le notifiche di conversazione prima della non conversazione notifiche ad eccezione delle notifiche di servizio in primo piano in corso e importanza: alta notifiche.

Se le notifiche delle conversazioni sono raggruppate in una sezione separata, implementazioni del dispositivo

  • [H-1-8] DEVE visualizzare le notifiche di conversazione prima delle notifiche di non conversazione, ad eccezione delle notifiche di servizio in primo piano in corso e di importanza: notifiche elevate.

Le implementazioni del dispositivo sono:

  • [H-SR] FORTEMENTE RACCOMANDATO di fornire l'accesso alle seguenti azioni dalle notifiche di conversazione: visualizza questa conversazione come una bolla se l'app fornisce i dati richiesti per le bolle

L'implementazione AOSP soddisfa questi requisiti con l'interfaccia utente di sistema, le impostazioni e l'utilità di avvio predefinite.

Per saperne di più

IdentityCredential - Patenti di guida mobili

Infine, una delle funzionalità di cui sono più entusiasta è l'API IdentityCredential. Come abbiamo spiegato l'anno scorso, l'API IdentityCredential è progettata per consentire alle applicazioni di archiviare documenti di identità, come patenti di guida mobili, sul dispositivo. Diversi paesi (e alcuni stati degli Stati Uniti) in tutto il mondo consentono già ai propri cittadini di archiviare le proprie patenti di guida in un'app mobile. Tuttavia, Google sta lavorando per renderlo più sicuro archiviando i dati offline in un ambiente sicuro.

Un'immagine di esempio di una patente di guida digitale a cui si accede tramite l'app LA Wallet. Fonte: Inv

Il codice sorgente di Android 11 include l'API IdentityCredential (che gli sviluppatori chiameranno per archiviare i documenti di identità nella memoria del telefono ambiente sicuro) e IdentityCredential HAL (che si interfaccia con l'ambiente sicuro del telefono), ma gli OEM non sono tenuti a implementarli. Quando Google ha proposto per la prima volta l'inclusione di IdentityCredential nel CDD il 10 gennaio 2020, lo ha elencato come requisito. Tuttavia, hanno allentato questo requisito il 18 marzo 2020 e ora raccomandano vivamente solo agli OEM di supportare questa funzionalità. Non siamo sorpresi che Google abbia allentato questo requisito: l'aggiunta di una modifica che incide sull'ambiente di esecuzione affidabile richiederà uno sforzo di implementazione da parte degli OEM. È possibile che gli OEM abbiano semplicemente bisogno di più tempo per prepararsi a questo cambiamento. Per gli utenti, tuttavia, ciò significa che non vi è alcuna garanzia che il tuo particolare smartphone Android 11 supporti l’archiviazione sicura di una patente di guida mobile nell’ambiente protetto del telefono.

Dobbiamo notare che non esiste alcuna limitazione tecnica che impedisca l'adozione diffusa del sistema IdentityCredential tra i dispositivi Android 11. Uno dei requisiti per implementare il sistema IdentityCredential è che il dispositivo abbia un'esecuzione attendibile Ambiente (TEE) o un processore sicuro dedicato in cui una "applicazione attendibile" interagisce con l'identità memorizzata documenti. A partire da Android 7.0 Nougat, Google ha richiesto che tutti i moderni dispositivi Android supportino un "ambiente di esecuzione isolato" (secondo Paragrafo 2.2.5 – Modello di Sicurezza nella CDD). I dispositivi con processori ARM in genere dispongono di ARM TrustZone TEE e Google fornisce il file Sistema operativo affidabile che gira su TrustZone. La presenza di un TEE è sufficiente per supportare il sistema IdentityCredential, anche se sarebbe più sicuro se le credenziali fossero archiviate in una CPU sicura incorporata (come nel Unità di elaborazione sicura di alcuni processori Qualcomm Snapdragon) o una CPU sicura e discreta (come in Titan M. di Google O I nuovi chip di sicurezza di Samsung). In particolare, i dispositivi con CPU sicure e discrete potrebbero anche essere in grado di supportare la funzionalità "modalità di accesso diretto" del sistema IdentityCredential, che consentirà all'utente di recuperare il proprio documento di identità anche quando non c'è abbastanza energia rimasta nel dispositivo per avviare il sistema operativo principale.

Sezione 9.11.3 proposta (nuova) - Credenziali di identità (aggiornata il 18/03/2020)

Il sistema di credenziali di identità consente agli sviluppatori di app di archiviare e recuperare i documenti di identità dell'utente.

Implementazioni del dispositivo:

  • [C-SR] sono FORTEMENTE RACCOMANDATI di implementare il sistema di credenziali di identità.

Se le implementazioni del dispositivo implementano il sistema di credenziali di identità:

  • [C-0-1] DEVE restituire un valore non nullo per il IdentityCredentialStore#getInstance() metodo.
  • [C-0-2] DEVE implementare le API `android.security.identity.*` con codice che comunica con un utente attendibile applicazione in esecuzione in un Trusted Execution Environment (TEE) o in un ambiente sicuro dedicato processore. L'applicazione attendibile deve essere implementata in modo tale che Base informatica affidabile per il sistema di credenziali di identità non include il sistema operativo Android.

Per saperne di più

Google sta anche lavorando su una libreria IdentityCredential Jetpack per rendere più semplice per gli sviluppatori aggiungere il supporto per l'archiviazione sicura dell'identità documenti su Android, ma la vera sfida sarà convincere i governi ad autorizzare le app che utilizzano questa API per archiviare in modo sicuro gli ID governativi. Secondo Impegnarsi, La Corea del Sud ha appena implementato il supporto per l'archiviazione delle patenti di guida in un'app mobile, quindi stiamo iniziando a vedere un aumento nell'accettazione di questa tecnologia. Io, per esempio, sono entusiasta di vedere dove andrà a finire perché significherà una cosa in meno da portare con me quando esco.


Il documento che abbiamo ottenuto elencava le modifiche alla CDD entro la data in cui tali modifiche sono state apportate. Le ultime modifiche sono state apportate il 10 giugno 2020, il che significa che il documento in nostro possesso è abbastanza aggiornato. È possibile che Google possa rinnegare queste modifiche e apportare nuovamente tutti i requisiti prima del rilascio pubblico di Android 11, ma dubitiamo che Google all'improvviso realizzerà il CDD Di più rigoroso. Questi cambiamenti sono stati probabilmente allentati grazie al feedback degli OEM che sono quelli che dovranno tornare indietro e implementare queste funzionalità se non erano già stati pianificati di farlo. Ciò richiede tempo, impegno e denaro, il che ritarderebbe ulteriormente il rilascio di Android 11 per dispositivi non Google. Tuttavia, se Google renderà nuovamente necessarie queste funzionalità, pubblicheremo un aggiornamento sul portale XDA.