Exclusiv: 3 dintre cele mai bune funcții ale Android 11 nu vor fi pe fiecare dispozitiv

În fiecare an, Google lansează o nouă versiune a sistemului de operare Android. Google a lansat prima previzualizare pentru dezvoltatori Android 11 în februarie, urmată de a doua, a treia și a patra previzualizare pentru dezvoltatori în ultimele luni. La începutul acestei luni, Google a dezvăluit primul Android 11 Beta și a vorbit în profunzime despre cele mai bune funcții pe care utilizatorii le pot bucura și pe care dezvoltatorii le pot implementa. Cu toate acestea, acum am aflat că trei dintre funcțiile de top din Android 11 nu vor fi disponibile pe fiecare dispozitiv Android.

Pentru a înțelege cum este posibil acest lucru, trebuie să explicăm pe scurt modul în care sistemul de operare Android este distribuit de la Google către producătorii de dispozitive smartphone. Android este un sistem de operare open-source licențiat sub Apache 2.0, ceea ce înseamnă că oricine, de la dezvoltatori indie la companii mari, este liber să modifice și să distribuie sistemul de operare pe propriile dispozitive. Cele mai multe dintre noile funcții ale sistemului de operare pe care Google le-a dezvăluit pentru Android 11 vor face parte din Android Open Source Project (AOSP) pentru acel smartphone. producătorii de dispozitive își bazează propriul software, dar licența Apache 2.0, așa cum am menționat mai înainte, permite oricui să modifice software-ul așa cum vede. potrivi. Pentru a menține coerența API-urilor și a comportamentului platformei între dispozitivele Android, Google grupează distribuția serviciilor mobile Google (care include aplicații și cadre precum Google Play Store și Google Play Services) cu acorduri de licență care impun ca dispozitivele să respecte regulile Google "

Programul de compatibilitate Android" (printre alte cerințe). Programul de compatibilitate Android constă din mai multe suite de testare automate și un set de reguli enumerate în Android Document de definire a compatibilităţii (CDD).

În CDD, Google enumeră funcțiile software și hardware pe care producătorii de dispozitive „TREBUIE” să le implementeze, sunt doar „RECOMANDAT CU FORT” să le implementeze sau „NU TREBUIE” să le implementeze. Dacă o funcție este listată ca fiind „TREBUIE” implementată, atunci producătorul dispozitivului trebuie să adauge acea caracteristică sau nu poate livra aplicații Google pe dispozitivele sale. Dacă o funcție este listată ca „NU TREBUIE” implementată, atunci producătorul dispozitivului nu poate adăuga acea caracteristică sau nu poate combina aplicații Google. În cele din urmă, dacă o caracteristică este listată ca „RECOMANDAT FOARTE”, atunci depinde de producătorul dispozitivului dacă dorește sau nu să implementeze caracteristica. CDD-ul este un document în continuă schimbare, chiar înainte de publicarea sa în fiecare an, după lansarea publică a unei noi versiuni Android. Google actualizează frecvent documentul pentru a elimina funcții, pentru a schimba limba pentru a fi mai clară și pentru a relaxa cerințele pe baza feedbackului de la partenerii săi. Cu toate acestea, odată ce Google face public un CDD pentru o anumită versiune Android, aceste cerințe vor fi stabilite în piatră pentru dispozitivele certificate de Google care rulează acea versiune a sistemului de operare Android.

CDD-ul Android 11 nu va deveni public decât la sfârșitul acestui an, probabil la începutul lunii septembrie. Cu toate acestea, dezvoltatorul @deletescape a distribuit o copie pre-lansare a unui document care detaliază modificările care vin la CDD, oferindu-ne o privire devreme asupra modului în care Google modelează Android 11 în ecosistem. Marea majoritate a celor peste 60 de modificări ale CDD-ului nu sunt foarte interesante pentru utilizatori – ei descriu cum Producătorii de dispozitive trebuie să implementeze anumite API-uri, să declare anumite caracteristici și să implementeze anumite nuclee Caracteristici. Cu toate acestea, 3 dintre modificările aduse CDD-ului ne-au atras atenția deoarece se referă la unele dintre cele mai interesante caracteristici din Android 11. Iată ce am descoperit.

Comenzile dispozitivului

Comenzile dispozitivului este o funcție din Android 11 care permite afișarea controalelor inteligente pentru automatizarea casei în meniul de alimentare. Puteți să vă stingeți luminile, să deschideți ușa garajului, să porniți aspiratorul, să schimbați temperatura casei și să faceți multe altele fără a deschide o duzină de aplicații diferite pentru casă inteligentă. Google a adăugat API-uri pe care dezvoltatorii de aplicații pentru casă inteligentă le pot folosi pentru a suprafață controalele din meniul de alimentare. Credem că aceasta este o caracteristică bună care în cele din urmă aduce smartphone-ul tău în casa inteligentă. Din păcate, nu există nicio cerință ca OEM-urile să o implementeze efectiv. Dacă un OEM consideră că funcția este slabă sau dorește să meargă pe o altă cale (cum ar fi să permită doar smart comenzile de acasă de la dispozitivele din propriul ecosistem), atunci pot pur și simplu dezactiva suportul pentru dispozitiv Controale.

Când Google a adăugat pentru prima dată comenzile dispozitivului la CDD pe 25 februarie 2020, a impus includerea acestuia adăugând o cerință „TREBUIE” în ​​Secțiunea 2.2.3 – Cerințe software portabile. Cu toate acestea, pe 20 mai 2020, Google a actualizat textul pentru a elimina „TREBUIE” propus. Noua Secțiune 3.8.16 - Device Controls subliniază modul în care funcția trebuie implementată, dar nu necesită de fapt ca aceasta să fie implementată în primul rând! Sperăm că OEM-urile nu vor dezactiva această funcție ingenioasă, dar nu avem cum să știm dacă au dezactivat-o până când nu gata să-și dezvăluie propriile arome de Android construit pe Android 11, ceea ce nu se va întâmpla decât după câteva luni de la acum.

Secțiunea propusă 3.8.16 (nouă) - Comenzile dispozitivului (Actualizat 20.5.2020)

3.8.16 Comenzi dispozitiv

Android include ControlsProviderService și Control API-uri pentru a permite dezvoltatorilor să publice comenzile dispozitivului pentru starea și acțiunea rapidă pentru utilizatori.

3.8.16.1 Device Controls User Affordance

Dacă dispozitivele implementează Controlul dispozitivelor, atunci acestea:

• [C-1-1] TREBUIE să raporteze indicatorul android.software.controls.feature ca fiind TRUE
• [C-1-2] TREBUIE să ofere utilizatorului posibilitatea de a adăuga, edita, selecta și opera favoritele utilizatorului din comenzile înregistrate de aplicațiile terțe prin intermediul android.service.controls. ControlsProviderService și android.service.controls. Control API-uri.
• [C-1-3] TREBUIE să ofere acces la acest utilizator în termen de trei interacțiuni de la Lansator
• [C-1-4] TREBUIE să redeze cu acuratețe în acest utilizator affordance numele și pictograma fiecărei aplicații terță parte care oferă controale prin intermediul android.service.controls. ControlsProviderService API, precum și orice pictogramă specificată, text de stare, tip de dispozitiv, nume, structură, zonă, culoare personalizată și subtitrare furnizate de android.service.controls. Control API

În schimb, dacă implementările dispozitivelor nu implementează astfel de controale, atunci acestea

• [C-2-1] TREBUIE să raporteze Null pentru ControlsProviderService și Control API.

citeşte mai mult

Conversații în Notificări

Unul dintre cele mai mari avantaje ale Androidului în comparație cu iOS este modul în care primul gestionează notificările. Acest decalaj în utilizare va deveni și mai mare în Android 11 odată cu introducerea „Conversații”. În Android 11, notificări din aplicațiile de mesagerie sunt grupate și sunt afișate într-o secțiune separată în panoul de notificări, deasupra celorlalte notificări. Acest lucru vă permite să vedeți și să răspundeți rapid la mesaje fără a fi nevoie să parcurgeți toate celelalte notificări în așteptare. Din păcate, este posibil ca această modificare ingenioasă a notificărilor să nu fie disponibilă pe toate dispozitivele. Google le oferă OEM-urilor opțiunea de a alege dacă doresc să „grupeze și să afișeze notificări de conversație înainte notificări non-conversații." OEM-urile personalizează frecvent panoul de notificări și, prin urmare, nu este surprinzător faptul că Google oferă OEM-urilor o alegere aici. Cu toate acestea, este regretabil că Google nu alege să impună mai multă consistență în notificări în Android 11.

Modificări propuse la Secțiunea 3.8.3.1 - Prezentarea notificărilor (Actualizat la 4/08/2020)

Dacă implementările dispozitivelor permit aplicațiilor terțe să notifice utilizatorii despre evenimente notabile, acestea:

...

Android R introduce suport pentru notificarea conversației, care este o notificare care utilizează NotificationManager. MessageStyle și oferă un ID de comandă rapidă pentru persoane publicat.

Implementările dispozitivului sunt:

• [H-SR] RECOMANDĂ INFORT pentru a grupa și a afișa notificări de conversație înainte de non conversație notificări, cu excepția notificărilor în curs de desfășurare a serviciilor de prim-plan și importanță: mare notificări.

Dacă notificările de conversație sunt grupate într-o secțiune separată, implementările dispozitivului

• [H-1-8] TREBUIE să afișeze notificări de conversație înaintea notificărilor fără conversație, cu excepția notificărilor de serviciu în prim-plan în curs și a importanței: notificări ridicate.

Implementările dispozitivului sunt:

• [H-SR] RECOMANDĂ INFORT pentru a oferi acces la următoarele acțiuni din notificările de conversație: afișați această conversație ca un balon dacă aplicația furnizează datele necesare pentru bule

Implementarea AOSP îndeplinește aceste cerințe cu interfața implicită de sistem, Setări și Lansatorul.

citeşte mai mult

IdentityCredential - Licențe de conducere pentru mobil

În cele din urmă, una dintre caracteristicile de care sunt cel mai încântat este API-ul IdentityCredential. După cum am detaliat anul trecut, API-ul IdentityCredential este conceput pentru a permite aplicațiilor să stocheze documente de identitate, cum ar fi permisele de conducere mobile, pe dispozitiv. Mai multe țări (și unele state din SUA) din întreaga lume permit deja cetățenilor lor să-și stocheze permisele de conducere într-o aplicație mobilă. Cu toate acestea, Google lucrează pentru a face acest lucru mai sigur prin stocarea datelor offline într-un mediu securizat.

Codul sursă pentru Android 11 include API-ul IdentityCredential (pe care dezvoltatorii îl vor apela pentru a stoca documente de identitate în telefonul). mediu securizat) și IdentityCredential HAL (care interfață cu mediul securizat al telefonului), dar OEM nu li se cere să implementează-le. Când Google a propus pentru prima dată includerea IdentityCredential în CDD pe 10 ianuarie 2020, a enumerat-o ca o cerință. Cu toate acestea, au relaxat această cerință pe 18 martie 2020 și acum recomandă insistent doar ca OEM-urile să accepte această caracteristică. Nu suntem surprinși că Google a relaxat această cerință – adăugarea unei modificări care are un impact asupra mediului de execuție de încredere va necesita efort din partea OEM pentru implementare. Este posibil ca OEM-urile pur și simplu să aibă nevoie de mai mult timp pentru a se pregăti pentru această schimbare. Pentru utilizatori, totuși, asta înseamnă că nu există nicio garanție că smartphone-ul tău Android 11 va accepta stocarea în siguranță a unui permis de conducere mobil în mediul securizat al telefonului.

Trebuie să reținem că nu există nicio limitare tehnică care să împiedice adoptarea pe scară largă a sistemului IdentityCredential printre dispozitivele Android 11. Una dintre cerințele pentru implementarea sistemului IdentityCredential este ca dispozitivul să aibă o execuție de încredere. Environment (TEE) sau un procesor securizat dedicat în care o „aplicație de încredere” interacționează cu identitatea stocată documente. De la Android 7.0 Nougat, Google a cerut ca toate dispozitivele moderne Android să accepte un „mediu de execuție izolat” (per Secțiunea 2.2.5 - Modelul de securitate în CDD). Dispozitivele cu procesoare ARM dispun de obicei de ARM TrustZone TEE, iar Google oferă Sistem de operare de încredere care rulează pe TrustZone. Prezența unui TEE este suficientă pentru a sprijini sistemul IdentityCredential, deși ar fi mai sigur dacă acreditările sunt stocate într-un CPU securizat încorporat (cum ar fi în Unitatea de procesare sigură a unor procesoare Qualcomm Snapdragon) sau un procesor securizat discret (cum ar fi în Titan M de la Google sau Noile cipuri de securitate Samsung). În special, dispozitivele cu procesoare securizate discrete pot fi, de asemenea, capabile să accepte caracteristica „Modul de acces direct” a sistemului IdentityCredential, ceea ce va permite utilizatorului să își ridice documentul de identitate chiar și atunci când nu mai există suficientă putere în dispozitiv pentru a porni sistemul de operare principal.

Secțiunea propusă 9.11.3 (nouă) - Acreditare de identitate (Actualizată la 18.03.2020)

Sistemul de acreditări de identitate permite dezvoltatorilor de aplicații să stocheze și să recupereze documentele de identitate ale utilizatorului.

Implementări dispozitiv:

• [C-SR] sunt RECOMANDATE CU FOND pentru a implementa Sistemul de acreditări de identitate.

Dacă implementările dispozitivelor implementează sistemul de acreditări de identitate, acestea:

• [C-0-1] TREBUIE să returneze non-null pentru IdentityCredentialStore#getInstance() metodă.
• [C-0-2] TREBUIE să implementeze API-urile `android.security.identity.*` cu cod care comunică cu o persoană de încredere aplicație care rulează fie într-un mediu de execuție de încredere (TEE), fie într-un mediu securizat dedicat procesor. Aplicația de încredere trebuie implementată astfel încât Baza de calcul de încredere pentru Sistemul de acreditări de identitate nu include sistemul de operare Android.

citeşte mai mult

De asemenea, Google lucrează la o bibliotecă IdentityCredential Jetpack pentru a facilita dezvoltatorilor să adauge suport pentru stocarea în siguranță a identității. documente pe Android, dar adevărata provocare va fi ca guvernele să autorizeze aplicațiile care utilizează acest API pentru a stoca în siguranță ID-urile guvernamentale. Conform Engadget, Coreea de Sud tocmai a lansat suport pentru stocarea permiselor de conducere într-o aplicație mobilă, așa că începem să vedem o creștere a acceptării acestei tehnologii. Eu, unul, sunt încântat să văd unde se duce asta pentru că va însemna un lucru mai puțin de purtat cu mine când ies afară.

---

Documentul pe care l-am obținut a enumerat modificările aduse CDD-ului până la data la care au fost făcute aceste modificări. Ultimele modificări au fost făcute pe 10 iunie 2020, ceea ce înseamnă că documentul pe care îl avem este destul de actualizat. Este posibil ca Google să renunțe la aceste modificări și să le facă din nou toate cerințele înainte de lansarea publică a Android 11, dar ne îndoim că Google va face dintr-o dată CDD Mai mult stringente. Aceste modificări au fost probabil relaxate din cauza feedback-ului de la OEM, care sunt cei care vor trebui să se întoarcă și să implementeze aceste caracteristici dacă nu erau deja planificați să facă acest lucru. Acest lucru necesită timp, efort și bani, ceea ce ar întârzia și mai mult lansarea Android 11 pentru dispozitivele non-Google. Totuși, dacă Google face ca aceste funcții să fie necesare încă o dată, vom publica o actualizare pe portalul XDA.