Exklusivt: 3 av Android 11:s bästa funktioner finns inte på alla enheter

Varje år släpper Google en ny version av operativsystemet Android. Google släppte den första Android 11 Developer Preview tillbaka i februari följt av den andra, tredje och fjärde utvecklarförhandsvisningen under de senaste månaderna. Tidigare denna månad avslöjade Google första Android 11 Beta och pratade ingående om de bästa funktionerna för användare att njuta av och för utvecklare att implementera. Men vi har nu lärt oss att tre av de bästa funktionerna i Android 11 inte kommer att vara tillgängliga på alla Android-enheter.

För att förstå hur det är möjligt måste vi kortfattat förklara hur Android OS distribueras från Google till tillverkare av smartphoneenheter. Android är en operativsystem med öppen källkod licensierad under Apache 2.0, vilket innebär att alla, från indieutvecklare till stora företag, är fria att modifiera och distribuera operativsystemet på sina egna enheter. De flesta av de nya OS-funktionerna som Google presenterade för Android 11 kommer att vara en del av Android Open Source Project (AOSP) som smartphone enhetstillverkare baserar sin egen programvara på, men Apache 2.0-licensen, som jag nämnde tidigare, låter vem som helst modifiera programvaran som de ser passa. För att upprätthålla konsekvens i API: er och plattformsbeteende mellan Android-enheter, paketerar Google distributionen av Googles mobiltjänster (som inkluderar applikationer och ramverk som Google Play Butik och Google Play Services) med licensavtal som kräver att enheter följer reglerna enligt Googles "

Android-kompatibilitetsprogram" (bland andra krav). Android-kompatibilitetsprogrammet består av flera automatiska testsviter och en uppsättning regler som räknas upp i Android Kompatibilitetsdefinitionsdokument (CDD).

I CDD: n listar Google mjukvaru- och hårdvarufunktioner som enhetstillverkare "MÅSTE" implementera, endast "REKOMMENDERAS STARKT" att implementera eller "SKA INTE" implementera. Om en funktion är listad som "MÅSTE" implementeras måste enhetstillverkaren lägga till den funktionen annars kan de inte skicka Google-appar på sina enheter. Om en funktion är listad som "SKA INTE" implementera, kan enhetstillverkaren inte lägga till den funktionen eller så kan de inte bunta Google-appar. Slutligen, om en funktion är listad som "STARKT REKOMMENDERAD", är det upp till enhetstillverkaren om de vill implementera funktionen eller inte. CDD är ett ständigt föränderligt dokument, även innan det publiceras varje år efter den offentliga lanseringen av en ny Android-version. Google uppdaterar ofta dokumentet för att ta bort funktioner, ändra språket för att bli tydligare och lätta på kraven baserat på feedback från sina partners. Men när Google gör en CDD offentlig för en viss Android-version kommer dessa krav att sättas i sten för Google-certifierade enheter som kör den Android OS-versionen.

Android 11 CDD kommer inte att bli offentlig förrän senare i år, troligen i början av september. Dock utvecklare @deletescape delade en pre-release-kopia av ett dokument som beskriver ändringar som kommer till CDD, vilket ger oss en tidig titt på hur Google formar Android 11 i ekosystemet. De allra flesta av de över 60 ändringarna av CDD är inte särskilt intressanta för användare – de beskriver hur enhetstillverkare måste implementera vissa API: er, deklarera vissa funktioner och implementera vissa kärnor Funktioner. Men 3 av ändringarna i CDD fångade vår uppmärksamhet eftersom de relaterar till några av de mest intressanta funktionerna i Android 11. Här är vad vi upptäckte.

Enhetskontroller

Enhetskontroller är en funktion i Android 11 som gör det möjligt för smarta hemautomationskontroller att visas i strömmenyn. Du kan släcka belysningen, öppna garageporten, starta din dammsugare, ändra temperaturen i ditt hem och göra mycket mer utan att öppna ett dussin olika smarta hemappar. Google lade till API: er som utvecklare av appar för smarta hem kan använda för att visa kontroller i strömmenyn. Vi tycker att detta är en snygg funktion som äntligen tar din smartphone in i det smarta hemmet. Tyvärr finns det inget krav på att OEM-tillverkare faktiskt ska implementera det. Om en OEM tycker att funktionen är dålig eller om de vill gå en annan väg (som att bara tillåta smart hemkontroller från enheter i deras eget ekosystem), så kan de helt enkelt inaktivera stödet för Enhet Kontroller.

När Google först lade till enhetskontroller till CDD den 25 februari 2020, beordrade de att det skulle inkluderas genom att lägga till ett "MÅSTE"-krav i avsnitt 2.2.3 - Krav på handhållen programvara. Men den 20 maj 2020 uppdaterade Google texten för att ta bort det föreslagna "MÅSTE". Det nya avsnittet 3.8.16 - Enhetskontroller beskriver hur funktionen måste implementeras men kräver faktiskt inte att den implementeras i första hand! Vi hoppas att OEM-tillverkare inte kommer att inaktivera den här snygga funktionen, men det finns inget sätt för oss att veta om de har inaktiverat den förrän de är redo att avslöja sina egna smaker av Android byggda ovanpå Android 11, vilket inte kommer att hända förrän flera månader från nu.

Föreslagna avsnitt 3.8.16 (Ny) - Enhetskontroller (Uppdaterad 2020-05-20)

3.8.16 Enhetskontroller

Android inkluderar ControlsProviderService och Control API: er för att tillåta utvecklare att publicera enhetskontroller för snabb status och åtgärder för användare.

3.8.16.1 Enheten kontrollerar användarens ekonomi

Om enheter implementerar enhetskontroller, då:

• [C-1-1] MÅSTE rapportera flaggan för android.software.controls.feature för att vara TRUE
• [C-1-2] MÅSTE ge användaren råd med möjligheten att lägga till, redigera, välja och använda användarens favoriter från kontrollerna som registrerats av tredje parts appar via android.service.controls. ControlsProviderService och android.service.controls. Styr API: er.
• [C-1-3] MÅSTE ge tillgång till detta användarpris inom tre interaktioner från startprogrammet
• [C-1-4] MÅSTE exakt återge namnet och ikonen för varje tredjepartsapp som tillhandahåller kontroller via android.service.controls i detta användartillstånd. ControlsProviderService API samt eventuell specificerad ikon, statustext, enhetstyp, namn, struktur, zon, anpassad färg och undertext som tillhandahålls av android.service.controls. Styr API

Omvänt, om enhetsimplementeringar inte implementerar sådana kontroller, då de

• [C-2-1] MÅSTE rapportera Null för ControlsProviderService och Control API: erna.

Läs mer

Konversationer i aviseringar

En av Androids största fördelar jämfört med iOS är hur den förstnämnda hanterar aviseringar. Det gapet i användbarhet kommer att bli ännu större i Android 11 med introduktionen av "Conversations". I Android 11, aviseringar från meddelandeappar är grupperade och visas i ett separat avsnitt i meddelandepanelen ovanför de flesta andra meddelanden. Detta låter dig snabbt se och svara på meddelanden utan att behöva bläddra igenom alla dina andra väntande aviseringar. Tyvärr kanske den här smarta ändringen av aviseringar inte är tillgänglig på alla enheter. Google ger OEM-tillverkare möjlighet att välja om de vill "gruppera och visa konversationsmeddelanden i förväg meddelanden utan konversation." OEM-tillverkare anpassar ofta meddelandepanelen, så det är ingen överraskning att Google ger OEM-tillverkare ett val här. Ändå är det olyckligt att Google inte väljer att genomdriva mer konsekvens i aviseringar i Android 11.

Föreslagna ändringar av avsnitt 3.8.3.1 - Presentation av meddelanden (Uppdaterad 2020-08-04)

Om enhetsimplementeringar tillåter tredjepartsappar att meddela användare om anmärkningsvärda händelser, gör de:

...

Android R introducerar stöd för konversationsavisering, vilket är ett meddelande som använder NotificationManager. MessageStyle och tillhandahåller ett publicerat People Shortcut ID.

Enhetsimplementationer är:

• [H-SR] REKOMMENDERAS STARKT att gruppera och visa konversationsaviseringar före icke-konversation aviseringar med undantag för pågående förgrundstjänstaviseringar och betydelse: hög meddelanden.

Om konversationsmeddelanden grupperas i en separat sektion, enhetsimplementeringar

• [H-1-8] MÅSTE visa konversationsaviseringar före icke-konversationsaviseringar med undantag för pågående förgrundstjänstaviseringar och vikt: höga aviseringar.

Enhetsimplementationer är:

• [H-SR] REKOMMENDERAS STARKT att ge åtkomst till följande åtgärder från konversationsaviseringar: visa den här konversationen som en bubbla om appen tillhandahåller de nödvändiga uppgifterna för bubblor

AOSP-implementeringen uppfyller dessa krav med standardsystemgränssnittet, inställningarna och startprogrammet.

Läs mer

IdentityCredential - Mobila körkort

Slutligen, en av de funktioner som jag är mest exalterad över är IdentityCredential API. Som vi beskrev förra året, IdentityCredential API är utformat för att tillåta applikationer att lagra identitetsdokument, såsom mobila körkort, på enheten. Flera länder (och vissa amerikanska stater) runt om i världen tillåter redan sina medborgare att lagra sina körkort i en mobilapp. Google arbetar dock för att göra detta säkrare genom att ha data lagrad offline i en säker miljö.

Källkoden för Android 11 inkluderar IdentityCredential API (som utvecklare kommer att anropa för att lagra identitetsdokument i telefonens säker miljö) och IdentityCredential HAL (som samverkar med telefonens säkra miljö), men OEM-tillverkare behöver inte genomföra dem. När Google först föreslog inkludering av IdentityCredential i CDD den 10 januari 2020, angav de det som ett krav. De lättade dock på detta krav den 18 mars 2020 och rekommenderar nu bara starkt att OEM-tillverkare stödjer denna funktion. Vi är inte förvånade över att Google lättade på detta krav – att lägga till en förändring som påverkar den pålitliga exekveringsmiljön kommer att kräva ansträngning från OEM-tillverkare att implementera. Det är möjligt att OEM-tillverkare helt enkelt behöver mer tid för att förbereda sig för denna förändring. För användare betyder det dock att det inte finns någon garanti för att just din Android 11-smarttelefon kommer att stödja säker lagring av ett mobilt körkort i telefonens säkra miljö.

Vi bör notera att det inte finns någon teknisk begränsning som hindrar den utbredda adoptionen av IdentityCredential-systemet bland Android 11-enheter. Ett av kraven för att implementera IdentityCredential-systemet är att enheten har en Trusted Execution Miljö (TEE) eller en dedikerad säker processor där en "betrodd applikation" interagerar med den lagrade identiteten dokument. Sedan Android 7.0 Nougat har Google krävt att alla moderna Android-enheter ska stödja en "isolerad exekveringsmiljö" (pr. Avsnitt 2.2.5 - Säkerhetsmodell i CDD). Enheter med ARM-processorer har vanligtvis ARM TrustZone TEE och Google tillhandahåller Pålitligt OS som körs på TrustZone. Närvaron av en TEE är tillräckligt för att stödja IdentityCredential-systemet, även om det skulle vara säkrare om referenserna lagras i en inbäddad säker CPU (som i Säker processorenhet för vissa Qualcomm Snapdragon-processorer) eller en diskret säker CPU (som i Googles Titan M eller Samsungs nya säkerhetschips). Speciellt kan enheter med diskreta säkra CPU: er också kunna stödja funktionen "Direct Access mode" i IdentityCredential-systemet, vilket gör att användaren kan hämta sitt identitetsdokument även när det inte finns tillräckligt med ström kvar i enheten för att starta upp huvudoperativsystemet.

Föreslaget avsnitt 9.11.3 (Ny) – Identitetsuppgifter (Uppdaterad 2020-03-18)

Identity Credential System tillåter apputvecklare att lagra och hämta användaridentitetsdokument.

Enhetsimplementationer:

• [C-SR] REKOMMENDERAS STARKT för att implementera Identity Credential System.

Om enhetsimplementeringar implementerar Identity Credential System:

• [C-0-1] MÅSTE returnera icke-null för IdentityCredentialStore#getInstance() metod.
• [C-0-2] MÅSTE implementera API: erna `android.security.identity.*` med kod som kommunicerar med en betrodd applikation som körs i antingen en Trusted Execution Environment (TEE) eller på en dedikerad säker processor. Den betrodda applikationen måste implementeras så att Trusted Computing Base för Identity Credential System inkluderar inte Android-operativsystemet.

Läs mer

Google arbetar också på ett IdentityCredential Jetpack-bibliotek för att göra det enklare för utvecklare att lägga till stöd för säker lagring av identitet dokument på Android, men den verkliga utmaningen blir att få regeringar att godkänna appar som använder detta API för att säkert lagra statliga ID: n. Enligt Engadget, Sydkorea har precis lanserat stöd för att lagra körkort i en mobilapp, så vi börjar se en ökning av acceptansen för denna teknik. Jag, för en, är exalterad över att se vart detta leder eftersom det kommer att innebära en sak mindre att bära med mig när jag går ut.

---

Dokumentet som vi fick angav ändringar i CDD vid det datum då dessa ändringar gjordes. De senaste ändringarna gjordes den 10 juni 2020, vilket innebär att dokumentet som vi har är ganska uppdaterat. Det är möjligt att Google kan avstå från dessa ändringar och ställa alla krav igen innan den offentliga lanseringen av Android 11, men vi tvivlar på att Google helt plötsligt kommer att göra CDD: n Mer stränga. Dessa förändringar var sannolikt lättade på grund av feedback från OEM-tillverkare som är de som måste gå tillbaka och implementera dessa funktioner om de inte redan var planerade att göra det. Det tar tid, ansträngning och pengar, vilket bara skulle försena lanseringen av Android 11 för enheter som inte kommer från Google ytterligare. Ändå, om Google gör dessa funktioner nödvändiga igen, kommer vi att publicera en uppdatering på XDA-portalen.