3 af de bedste funktioner i Android 11 vises ikke på alle smartphones og tablets. Det er fordi Google ikke kræver disse funktioner.
Hvert år udgiver Google en ny version af Android-operativsystemet. Google frigav den første Android 11 Developer Preview tilbage i februar efterfulgt af den anden, tredje og fjerde udvikler preview i løbet af de sidste par måneder. Tidligere på måneden afslørede Google første Android 11 Beta og talte i dybden om de bedste funktioner for brugere at nyde og for udviklere at implementere. Men vi har nu erfaret, at tre af de bedste funktioner i Android 11 ikke vil være tilgængelige på alle Android-enheder.
For at forstå, hvordan det er muligt, skal vi kort forklare, hvordan Android OS distribueres fra Google til producenter af smartphoneenheder. Android er en open source operativsystem licenseret under Apache 2.0, hvilket betyder, at alle, fra indie-udviklere til store virksomheder, frit kan ændre og distribuere operativsystemet på deres egne enheder. De fleste af de nye OS-funktioner, som Google afslørede til Android 11, vil være en del af Android Open Source Project (AOSP), den smartphone enhedsproducenter baserer deres egen software på, men Apache 2.0-licensen, som jeg nævnte før, lader enhver ændre softwaren, som de ser passe. For at opretholde ensartethed i API'er og platformadfærd mellem Android-enheder, samler Google distributionen af Google Mobile Services (som omfatter applikationer og rammer som Google Play Butik og Google Play Services) med licensaftaler, der kræver, at enheder overholder reglerne under Googles "
I CDD'en oplister Google software- og hardwarefunktioner, som enhedsproducenter "SKAL" implementere, kun er "STÆRKT ANBEFALES" at implementere eller "BØR IKKE" implementere. Hvis en funktion er angivet som "SKAL" implementere, så skal enhedsproducenten tilføje denne funktion, ellers kan de ikke sende Google-apps på deres enheder. Hvis en funktion er angivet som "BØR IKKE" implementere, kan enhedsproducenten ikke tilføje denne funktion, eller de kan ikke samle Google-apps. Endelig, hvis en funktion er angivet som "STÆRKT ANBEFALET", så er det op til enhedsproducenten, om de vil implementere funktionen eller ej. CDD er et dokument i konstant forandring, selv før det udgives hvert år efter den offentlige udgivelse af en ny Android-version. Google opdaterer ofte dokumentet for at fjerne funktioner, ændre sproget for at være tydeligere og lempe kravene baseret på feedback fra dets partnere. Men når Google offentliggør en CDD for en bestemt Android-version, vil disse krav blive sat i sten for Google-certificerede enheder, der kører den Android OS-version.
Android 11 CDD'en bliver ikke offentlig før senere i år, sandsynligvis i begyndelsen af september. Dog udvikler @deletescape delte en pre-release kopi af et dokument, der detaljerede ændringer, der kommer til CDD, hvilket giver os et tidligt kig på, hvordan Google former Android 11 på tværs af økosystemet. Langt de fleste af de over 60 ændringer af CDD'en er ikke særlig interessante for brugerne – de beskriver, hvordan enhedsproducenter skal implementere visse API'er, deklarere visse funktioner og implementere visse kerne funktioner. 3 af ændringerne til CDD'en fangede dog vores opmærksomhed, fordi de vedrører nogle af de mest interessante funktioner i Android 11. Her er, hvad vi afslørede.
Enhedskontrol
Device Controls er en funktion i Android 11, der gør det muligt at vise smart home automation-kontrol i strømmenuen. Du kan slukke dit lys, åbne din garageport, starte din støvsuger, ændre dit hjems temperatur og gøre meget mere uden at åbne et dusin forskellige smarthome-apps. Google tilføjede API'er, som udviklere af smarthome-apps kan bruge til at vise kontrolelementer i strømmenuen. Det synes vi er en pæn funktion bringer endelig din smartphone ind i det smarte hjem. Desværre er der ingen krav til OEM'er om rent faktisk at implementere det. Hvis en OEM mener, at funktionen er dårlig, eller de ønsker at gå en anden vej (såsom kun at tillade smart hjemmekontroller fra enheder i deres eget økosystem), så kan de simpelthen deaktivere understøttelse af Device Kontrolelementer.
Da Google første gang føjede Device Controls til CDD'en den 25. februar 2020, beordrede de dets medtagelse ved at tilføje et "MUST"-krav i afsnit 2.2.3 - Krav til håndholdt software. Den 20. maj 2020 opdaterede Google dog teksten for at fjerne det foreslåede "MUST". Det nye afsnit 3.8.16 - Enhedskontrol skitserer, hvordan funktionen skal implementeres, men kræver faktisk ikke, at den implementeres i første omgang! Vi håber, at OEM'er ikke vil deaktivere denne smarte funktion, men der er ingen måde for os at vide, om de har deaktiveret den, før de er klar til at afsløre deres egne varianter af Android bygget oven på Android 11, hvilket først sker flere måneder fra kl. nu.
Foreslået afsnit 3.8.16 (Ny) - Enhedskontrol (Opdateret 20/5/2020)
3.8.16 Enhedskontrol
Android inkluderer ControlsProviderService og Control API'er for at give udviklere mulighed for at udgive enhedskontroller for hurtig status og handling for brugerne.
3.8.16.1 Enheden kontrollerer brugeroverkommelighed
Hvis enheder implementerer Device Controls, så:
- [C-1-1] SKAL rapportere android.software.controls.feature-flaget for at være SAND
- [C-1-2] SKAL give en brugeroverkommelighed med mulighed for at tilføje, redigere, vælge og betjene brugerens favoritter fra de kontroller, der er registreret af 3. parts apps via android.service.controls. ControlsProviderService og android.service.controls. Styr API'er.
- [C-1-3] SKAL give adgang til denne brugerpris inden for tre interaktioner fra startprogrammet
- [C-1-4] SKAL nøjagtigt gengive i denne brugerpris navnet og ikonet for hver tredjepartsapp, der leverer kontrol via android.service.controls. ControlsProviderService API samt ethvert specificeret ikon, statustekst, enhedstype, navn, struktur, zone, brugerdefineret farve og undertekst leveret af android.service.controls. Kontrol API
Omvendt, hvis enhedsimplementeringer ikke implementerer sådanne kontroller, så er de
- [C-2-1] SKAL rapportere Null for ControlsProviderService og Control API'erne.
Læs mere
Samtaler i meddelelser
En af Androids største fordele sammenlignet med iOS er, hvordan førstnævnte håndterer notifikationer. Denne kløft i brugervenlighed bliver endnu større i Android 11 med introduktionen af "Samtaler". I Android 11, notifikationer fra beskedapps er grupperet sammen og vises i et separat afsnit i meddelelsespanelet over de fleste andre meddelelser. Dette lader dig hurtigt se og svare på beskeder uden at skulle rulle gennem alle dine andre afventende notifikationer. Desværre er denne smarte ændring af notifikationer muligvis ikke tilgængelig på alle enheder. Google giver OEM'er mulighed for at vælge, om de vil "gruppere og vise samtalemeddelelser forud for notifikationer uden samtaler." OEM'er tilpasser ofte meddelelsespanelet, og det er derfor ingen overraskelse, at Google giver OEM'er et valg her. Alligevel er det uheldigt, at Google ikke vælger at håndhæve mere konsistens i meddelelser i Android 11.
Foreslåede ændringer til afsnit 3.8.3.1 - Præsentation af meddelelser (Opdateret 4/08/2020)
Hvis enhedsimplementeringer tillader tredjepartsapps at underrette brugere om bemærkelsesværdige hændelser, skal de:
...
Android R introducerer understøttelse af samtalebesked, som er en notifikation, der bruger NotificationManager. MessageStyle og giver et offentliggjort persongenvejs-id.
Enhedsimplementeringer er:
- [H-SR] ANBEFALES STÆRKT at gruppere og vise samtalemeddelelser forud for ikke-samtale meddelelser med undtagelse af løbende forgrundstjenestemeddelelser og vigtighed: høj meddelelser.
Hvis samtalemeddelelser er grupperet i en separat sektion, enhedsimplementeringer
- [H-1-8] SKAL vise samtalemeddelelser forud for ikke-samtalemeddelelser med undtagelse af løbende forgrundstjenestemeddelelser og vigtighed: høje meddelelser.
Enhedsimplementeringer er:
- [H-SR] ANBEFALES STÆRKT at give adgang til følgende handlinger fra samtalemeddelelser: vis denne samtale som en boble, hvis appen leverer de nødvendige data til bobler
AOSP-implementeringen opfylder disse krav med standard System UI, Settings og Launcher.
Læs mere
IdentityCredential - Mobilkørekort
Endelig er en af de funktioner, som jeg er mest begejstret for, IdentityCredential API. Som vi nævnte sidste år, IdentityCredential API er designet til at tillade applikationer at gemme identitetsdokumenter, såsom mobile kørekort, på enheden. Adskillige lande (og nogle amerikanske stater) rundt om i verden tillader allerede deres borgere at gemme deres kørekort i en mobilapp. Google arbejder dog på at gøre dette mere sikkert ved at have data gemt offline i et sikkert miljø.
Kildekoden til Android 11 inkluderer IdentityCredential API (som udviklere vil kalde for at gemme identitetsdokumenter i telefonens sikkert miljø) og IdentityCredential HAL (som forbinder med telefonens sikre miljø), men OEM'er er ikke forpligtet til at implementere dem. Da Google første gang foreslog inkludering af IdentityCredential i CDD den 10. januar 2020, anførte de det som et krav. De lempede dog dette krav den 18. marts 2020 og anbefaler nu kun kraftigt, at OEM'er understøtter denne funktion. Vi er ikke overraskede over, at Google lempede dette krav – at tilføje en ændring, der påvirker det betroede eksekveringsmiljø, vil kræve en indsats fra OEM'er at implementere. Det er muligt, at OEM'er simpelthen har brug for mere tid til at blive klar til denne ændring. For brugere betyder det dog, at der ikke er nogen garanti for, at din specifikke Android 11-smartphone understøtter sikker opbevaring af et mobilt kørekort i telefonens sikre miljø.
Vi bør bemærke, at der ikke er nogen teknisk begrænsning, der forhindrer den udbredte anvendelse af IdentityCredential-systemet blandt Android 11-enheder. Et af kravene til implementering af IdentityCredential-systemet er, at enheden har en Trusted Execution Miljø (TEE) eller en dedikeret sikker processor, hvor en "betroet applikation" interagerer med den lagrede identitet Dokumenter. Siden Android 7.0 Nougat har Google krævet, at alle moderne Android-enheder understøtter et "isoleret eksekveringsmiljø" (pr. Afsnit 2.2.5 - Sikkerhedsmodel i CDD). Enheder med ARM-processorer har typisk ARM'er TrustZone TEE, og Google leverer Troværdigt OS der kører på TrustZone. Tilstedeværelsen af en TEE er nok til at understøtte IdentityCredential-systemet, selvom det ville være mere sikkert, hvis legitimationsoplysningerne er gemt i en indlejret sikker CPU (som f.eks. Sikker behandlingsenhed i nogle Qualcomm Snapdragon-processorer) eller en diskret sikker CPU (såsom i Googles Titan M eller Samsungs nye sikkerhedschips). Især kan enheder med diskrete sikre CPU'er muligvis også understøtte funktionen "Direct Access mode" i IdentityCredential-systemet, hvilket vil give brugeren mulighed for at trække deres identitetsdokument frem, selv når der ikke er nok strøm tilbage i enheden til at starte det primære OS.
Foreslået afsnit 9.11.3 (Ny) - Identitetsoplysninger (Opdateret 18/3/2020)
Identity Credential System giver app-udviklere mulighed for at gemme og hente brugeridentitetsdokumenter.
Enhedsimplementeringer:
- [C-SR] ANBEFALES STÆRKT for at implementere Identity Credential System.
Hvis enhedsimplementeringer implementerer Identity Credential System, de:
- [C-0-1] SKAL returnere non-null for IdentityCredentialStore#getInstance() metode.
- [C-0-2] SKAL implementere `android.security.identity.*` API'erne med kode, der kommunikerer med en betroet applikation, der kører i enten et Trusted Execution Environment (TEE) eller på en dedikeret sikker processor. Den betroede applikation skal implementeres således, at Trusted Computing Base for Identity Credential System inkluderer ikke Android-operativsystemet.
Læs mere
Google arbejder også på et IdentityCredential Jetpack-bibliotek for at gøre det nemmere for udviklere at tilføje support til sikker lagring af identitet dokumenter på Android, men den virkelige udfordring bliver at få regeringer til at godkende apps, der bruger denne API til sikkert at opbevare stats-id'er. Ifølge Engadget, Sydkorea har netop udrullet support til lagring af kørekort i en mobilapp, så vi begynder at se en stigning i accepten af denne teknologi. Jeg er spændt på at se, hvor det går hen, for det vil betyde en ting mindre at have med mig, når jeg går udenfor.
Dokumentet, som vi fik, anførte ændringer til CDD'en på den dato, disse ændringer blev foretaget. De seneste ændringer blev foretaget den 10. juni 2020, hvilket betyder, at det dokument, vi har, er nogenlunde opdateret. Det er muligt, at Google kunne give afkald på disse ændringer og stille dem alle krav igen før den offentlige udgivelse af Android 11, men vi tvivler på, at Google pludselig vil lave CDD'en mere strenge. Disse ændringer blev sandsynligvis lempet på grund af feedback fra OEM'er, som er dem, der bliver nødt til at gå tilbage og implementere disse funktioner, hvis de ikke allerede var planlagt til at gøre det. Det tager tid, kræfter og penge, hvilket blot ville forsinke udgivelsen af Android 11 til ikke-Google-enheder endnu mere. Alligevel, hvis Google gør disse funktioner påkrævet endnu en gang, sender vi en opdatering på XDA-portalen.