Eksklusivt: 3 av Android 11s beste funksjoner vil ikke være på alle enheter

Hvert år slipper Google en ny versjon av Android-operativsystemet. Google ga ut den første Android 11 Developer Preview tilbake i februar etterfulgt av den andre, tredje og fjerde utviklerforhåndsvisningen i løpet av de siste månedene. Tidligere denne måneden avduket Google første Android 11 Beta og snakket i dybden om de beste funksjonene for brukere å nyte og for utviklere å implementere. Imidlertid har vi nå lært at tre av toppfunksjonene i Android 11 ikke vil være tilgjengelige på alle Android-enheter.

For å forstå hvordan det er mulig, må vi kort forklare hvordan Android OS distribueres fra Google til produsenter av smarttelefonenheter. Android er en åpen kildekode operativsystem lisensiert under Apache 2.0, noe som betyr at alle, fra indie-utviklere til store selskaper, står fritt til å endre og distribuere operativsystemet på sine egne enheter. De fleste av de nye OS-funksjonene som Google avduket for Android 11 vil være en del av Android Open Source Project (AOSP) som smarttelefonen enhetsprodusenter baserer sin egen programvare på, men Apache 2.0-lisensen, som jeg nevnte før, lar hvem som helst endre programvaren slik de ser passe. For å opprettholde konsistens i APIer og plattformadferd mellom Android-enheter, samler Google distribusjonen av Google Mobile Services (som inkluderer applikasjoner og rammeverk som Google Play Store og Google Play Services) med lisensavtaler som krever at enheter overholder reglene under Googles "

Android-kompatibilitetsprogram" (blant andre krav). Android-kompatibilitetsprogrammet består av flere automatiserte testsuiter og et sett med regler som er oppført i Android Kompatibilitetsdefinisjonsdokument (CDD).

I CDD-en lister Google opp programvare- og maskinvarefunksjoner som enhetsprodusenter "MÅ" implementere, bare er "STERKELIG ANBEFALT" å implementere, eller "IKKE SKAL" implementere. Hvis en funksjon er oppført som «MÅ» implementeres, må enhetsprodusenten legge til denne funksjonen, ellers kan de ikke sende Google-apper på enhetene sine. Hvis en funksjon er oppført som «BØR IKKE» implementere, kan ikke enhetsprodusenten legge til den funksjonen, eller de kan ikke samle Google-apper. Til slutt, hvis en funksjon er oppført som «ANBEFALT STERKT», er det opp til enhetsprodusenten om de vil implementere funksjonen eller ikke. CDD er et dokument i stadig endring, selv før det publiseres hvert år etter den offentlige utgivelsen av en ny Android-versjon. Google oppdaterer ofte dokumentet for å fjerne funksjoner, endre språket for å bli klarere og lempe på kravene basert på tilbakemeldinger fra partnerne. Men når Google offentliggjør en CDD for en bestemt Android-versjon, vil disse kravene bli satt i stein for Google-sertifiserte enheter som kjører den Android OS-versjonen.

Android 11 CDD blir ikke offentlig før senere i år, sannsynligvis i begynnelsen av september. Imidlertid, utvikler @deletescape delte en forhåndskopi av et dokument som beskriver endringer som kommer til CDD, noe som gir oss en tidlig titt på hvordan Google former Android 11 på tvers av økosystemet. De aller fleste av de over 60 endringene i CDD er ikke særlig interessante for brukere – de beskriver hvordan enhetsprodusenter må implementere visse APIer, deklarere visse funksjoner og implementere visse kjerne egenskaper. Imidlertid fanget 3 av endringene i CDD vår oppmerksomhet fordi de er relatert til noen av de mest interessante funksjonene i Android 11. Her er hva vi avdekket.

Enhetskontroller

Enhetskontroller er en funksjon i Android 11 som gjør det mulig å vise smarthusautomatiseringskontroller i strømmenyen. Du kan slå av lyset, åpne garasjeporten, starte støvsugeren, endre temperaturen i hjemmet og gjøre mye mer uten å åpne et dusin forskjellige smarthus-apper. Google la til API-er som utviklere av smarthus-apper kan bruke for å vise kontroller i strømmenyen. Vi synes dette er en fin funksjon som endelig bringer smarttelefonen din inn i det smarte hjemmet. Dessverre er det ingen krav til OEM om å implementere det. Hvis en OEM mener funksjonen er dårlig eller de ønsker å gå en annen vei (for eksempel bare tillate smart hjemmekontroller fra enheter i deres eget økosystem), så kan de ganske enkelt deaktivere støtte for Device Kontroller.

Da Google først la til enhetskontroller til CDD 25. februar 2020, ga de mandat til å inkludere den ved å legge til et "MÅ"-krav i avsnitt 2.2.3 - Krav til håndholdt programvare. Den 20. mai 2020 oppdaterte Google imidlertid teksten for å fjerne det foreslåtte "MÅ". Den nye delen 3.8.16 - Enhetskontroller skisserer hvordan funksjonen må implementeres, men krever faktisk ikke at den implementeres i utgangspunktet! Vi håper OEM-er ikke vil deaktivere denne smarte funksjonen, men det er ingen måte for oss å vite om de har deaktivert den før de er klare til å avduke sine egne smaker av Android bygget på toppen av Android 11, noe som ikke vil skje før flere måneder fra nå.

Foreslått del 3.8.16 (Ny) – Enhetskontroller (Oppdatert 20.5.2020)

3.8.16 Enhetskontroller

Android inkluderer ControlsProviderService og Control APIer for å tillate utviklere å publisere enhetskontroller for rask status og handling for brukere.

3.8.16.1 Enhetskontroller brukerøkonomi

Hvis enheter implementerer enhetskontroller, gjør de følgende:

• [C-1-1] MÅ rapportere android.software.controls.feature-flagget for å være SANN
• [C-1-2] MÅ gi en brukerstøtte med muligheten til å legge til, redigere, velge og betjene brukerens favoritter fra kontrollene som er registrert av tredjepartsappene gjennom android.service.controls. ControlsProviderService og android.service.controls. Kontroller APIer.
• [C-1-3] MÅ gi tilgang til denne brukertilskuddet innen tre interaksjoner fra startprogrammet
• [C-1-4] MÅ nøyaktig gjengi navnet og ikonet for hver tredjepartsapp som gir kontroller via android.service.controls i denne brukerstøtten. ControlsProviderService API samt spesifisert ikon, statustekst, enhetstype, navn, struktur, sone, egendefinert farge og undertekst levert av android.service.controls. Kontroll API

Omvendt, hvis enhetsimplementeringer ikke implementerer slike kontroller, vil de

• [C-2-1] MÅ rapportere Null for ControlsProviderService og Control API-ene.

Les mer

Samtaler i varsler

En av Androids største fordeler sammenlignet med iOS er hvordan førstnevnte håndterer varsler. Dette gapet i brukervennlighet vil bli enda større i Android 11 med introduksjonen av «Samtaler». I Android 11, varsler fra meldingsapper er gruppert sammen og vises i en egen del i varslingspanelet over de fleste andre varsler. Dette lar deg raskt se og svare på meldinger uten å måtte bla gjennom alle andre ventende varsler. Dessverre kan det hende at denne smarte endringen i varsler ikke er tilgjengelig på alle enheter. Google gir OEM-er muligheten til å velge om de vil "gruppere og vise samtalevarsler i forkant ikke-samtalevarsler." OEM-er tilpasser ofte varslingspanelet, og derfor er det ingen overraskelse at Google gir OEM-er et valg her. Likevel er det uheldig at Google ikke velger å håndheve mer konsistens i varsler i Android 11.

Foreslåtte endringer i avsnitt 3.8.3.1 - Presentasjon av varsler (Oppdatert 4/08/2020)

Hvis enhetsimplementeringer tillater tredjepartsapper å varsle brukere om bemerkelsesverdige hendelser, gjør de følgende:

...

Android R introduserer støtte for samtalevarsling, som er et varsel som bruker NotificationManager. MessageStyle og gir en publisert People Shortcut ID.

Enhetsimplementeringer er:

• [H-SR] ANBEFALES STERKT for å gruppere og vise samtalevarsler i forkant av ikke-samtale varsler med unntak av pågående forgrunnstjenestevarsler og viktighet: høy varsler.

Hvis samtalevarsler er gruppert i en egen seksjon, enhetsimplementeringer

• [H-1-8] MÅ vise samtalevarsler foran ikke-samtalevarsler med unntak av pågående forgrunnstjenestevarsler og viktighet: høye varsler.

Enhetsimplementeringer er:

• [H-SR] ANBEFALES STERKT for å gi tilgang til følgende handlinger fra samtalevarsler: vis denne samtalen som en boble hvis appen gir de nødvendige dataene for bobler

AOSP-implementeringen oppfyller disse kravene med standard System UI, Settings og Launcher.

Les mer

IdentityCredential - Mobile førerkort

Til slutt, en av funksjonene jeg er mest begeistret for er IdentityCredential API. Som vi beskrev i fjor, IdentityCredential API er utformet for å tillate applikasjoner å lagre identitetsdokumenter, for eksempel mobile førerkort, på enheten. Flere land (og noen amerikanske stater) rundt om i verden tillater allerede innbyggerne å lagre førerkortene sine i en mobilapp. Google jobber imidlertid med å gjøre dette sikrere ved å ha dataene lagret offline i et sikkert miljø.

Kildekoden for Android 11 inkluderer IdentityCredential API (som utviklere vil ringe for å lagre identitetsdokumenter i telefonens sikkert miljø) og IdentityCredential HAL (som har grensesnitt med telefonens sikre miljø), men OEM-er er ikke pålagt å implementere dem. Da Google først foreslo inkludering av IdentityCredential i CDD 10. januar 2020, oppførte de det som et krav. De lempet imidlertid på dette kravet 18. mars 2020, og anbefaler nå kun på det sterkeste at OEM-er støtter denne funksjonen. Vi er ikke overrasket over at Google lempet på dette kravet – å legge til en endring som påvirker det pålitelige utførelsesmiljøet vil kreve innsats fra OEM-er for å implementere. Det er mulig at OEM-er ganske enkelt trenger mer tid for å gjøre seg klar for denne endringen. For brukere betyr det imidlertid at det ikke er noen garanti for at din spesifikke Android 11-smarttelefon støtter sikker lagring av et mobilt førerkort i telefonens sikre miljø.

Vi bør merke oss at det ikke er noen teknisk begrensning som hindrer utbredt bruk av IdentityCredential-systemet blant Android 11-enheter. Et av kravene for å implementere IdentityCredential-systemet er at enheten har en Trusted Execution Miljø (TEE) eller en dedikert sikker prosessor der en "betrodd applikasjon" samhandler med den lagrede identiteten dokumenter. Siden Android 7.0 Nougat har Google krevd at alle moderne Android-enheter støtter et "isolert utførelsesmiljø" (pr. Seksjon 2.2.5 - Sikkerhetsmodell i CDD). Enheter med ARM-prosessorer har vanligvis ARM-er TrustZone TEE, og Google gir Pålitelig OS som kjører på TrustZone. Tilstedeværelsen av en TEE er nok til å støtte IdentityCredential-systemet, selv om det ville være sikrere hvis legitimasjonen er lagret i en innebygd sikker CPU (som f.eks. Sikker behandlingsenhet for noen Qualcomm Snapdragon-prosessorer) eller en diskret sikker CPU (som f.eks Googles Titan M eller Samsungs nye sikkerhetsbrikker). Spesielt kan enheter med diskrete sikre CPUer også være i stand til å støtte funksjonen "Direct Access mode" i IdentityCredential-systemet, som vil tillate brukeren å hente opp sitt identitetsdokument selv når det ikke er nok strøm igjen i enheten til å starte opp hovedoperativsystemet.

Foreslått del 9.11.3 (Ny) – Identitetslegitimasjon (oppdatert 18.3.2020)

Identity Credential System lar apputviklere lagre og hente brukeridentitetsdokumenter.

Enhetsimplementeringer:

• [C-SR] ANBEFALES STERKT for å implementere Identity Credential System.

Hvis enhetsimplementeringer implementerer Identity Credential System:

• [C-0-1] MÅ returnere ikke-null for IdentityCredentialStore#getInstance() metode.
• [C-0-2] MÅ implementere `android.security.identity.*` APIer med kode som kommuniserer med en klarert applikasjon som kjører enten i et Trusted Execution Environment (TEE) eller på en dedikert sikker prosessor. Den klarerte applikasjonen må implementeres slik at Trusted Computing Base for Identity Credential System inkluderer ikke Android-operativsystemet.

Les mer

Google jobber også med et IdentityCredential Jetpack-bibliotek for å gjøre det enklere for utviklere å legge til støtte for sikker lagring av identitet dokumenter på Android, men den virkelige utfordringen vil være å få myndighetene til å autorisere apper som bruker denne API-en for sikker lagring av offentlige ID-er. I følge Engadget, Sør-Korea har nettopp lansert støtte for lagring av førerkort i en mobilapp, så vi begynner å se en økning i aksept for denne teknologien. Jeg er spent på å se hvor dette går, for det vil bety en ting mindre å ha med meg når jeg går utenfor.

---

Dokumentet som vi fikk tak i, listet opp endringer i CDD innen datoen disse endringene ble gjort. De siste endringene ble gjort 10. juni 2020, noe som betyr at dokumentet vi har er ganske oppdatert. Det er mulig at Google kan avstå fra disse endringene og stille dem alle kravene igjen før den offentlige utgivelsen av Android 11, men vi tviler på at Google plutselig vil lage CDD mer strenge. Disse endringene ble sannsynligvis avslappet på grunn av tilbakemeldinger fra OEM-er som er de som må gå tilbake og implementere disse funksjonene hvis de ikke allerede var planlagt å gjøre det. Det tar tid, krefter og penger, noe som bare ville forsinket utgivelsen av Android 11 for ikke-Google-enheter ytterligere. Likevel, hvis Google gjør disse funksjonene nødvendige igjen, vil vi legge ut en oppdatering på XDA-portalen.