Exclusief: 3 van de beste functies van Android 11 zullen niet op elk apparaat aanwezig zijn

Elk jaar brengt Google een nieuwe versie van het Android-besturingssysteem uit. Google bracht in februari de eerste Android 11 Developer Preview uit, gevolgd door de tweede, derde en vierde developer previews van de afgelopen maanden. Eerder deze maand onthulde Google de eerste Android 11 bèta en diepgaand gesproken over de beste functies waarvan gebruikers kunnen genieten en die ontwikkelaars kunnen implementeren. We hebben nu echter vernomen dat drie van de belangrijkste functies in Android 11 niet op elk Android-apparaat beschikbaar zullen zijn.

Om te begrijpen hoe dat mogelijk is, moeten we kort uitleggen hoe het Android-besturingssysteem door Google wordt gedistribueerd naar makers van smartphoneapparaten. Android is een open source besturingssysteem gelicentieerd onder Apache 2.0, wat betekent dat iedereen, van indie-ontwikkelaars tot grote bedrijven, vrij is om het besturingssysteem op zijn eigen apparaten aan te passen en te distribueren. De meeste nieuwe OS-functies die Google voor Android 11 heeft onthuld, zullen deel uitmaken van het Android Open Source Project (AOSP) dat smartphone apparaatfabrikanten baseren hun eigen software op, maar de Apache 2.0-licentie laat, zoals ik al eerder zei, iedereen de software naar eigen inzicht aanpassen fit. Om consistentie in API's en platformgedrag tussen Android-apparaten te behouden, bundelt Google de distributie van Google Mobile Services (waaronder applicaties en frameworks zoals de Google Play Store en Google Play Services) met licentieovereenkomsten die voorschrijven dat apparaten zich moeten houden aan de regels van Google "

Android-compatibiliteitsprogramma" (naast andere vereisten). Het Android-compatibiliteitsprogramma bestaat uit meerdere geautomatiseerde testsuites en een reeks regels die in Android zijn opgesomd Compatibiliteitsdefinitiedocument (CDD).

In de CDD somt Google software- en hardwarefuncties op die apparaatfabrikanten "MOETEN" implementeren, die alleen "STERK AANBEVOLEN" zijn om te implementeren, of "MOETEN NIET" implementeren. Als een functie vermeld staat als 'MOET' geïmplementeerd worden, moet de fabrikant van het apparaat die functie toevoegen, anders kunnen ze geen Google-apps op hun apparaten leveren. Als een functie wordt vermeld als 'ZOU NIET' moeten worden geïmplementeerd, kan de fabrikant van het apparaat die functie niet toevoegen of kunnen ze geen Google-apps bundelen. Als een functie ten slotte wordt vermeld als 'STERK AANBEVOLEN', is het aan de fabrikant van het apparaat of hij de functie wel of niet wil implementeren. De CDD is een voortdurend veranderend document, zelfs vóór de jaarlijkse publicatie ervan na de publieke release van een nieuwe Android-versie. Google werkt het document regelmatig bij om functies te verwijderen, de taal duidelijker te maken en de vereisten te versoepelen op basis van feedback van zijn partners. Zodra Google echter een CDD openbaar maakt voor een bepaalde Android-versie, worden deze vereisten vastgelegd voor door Google gecertificeerde apparaten met die Android OS-versie.

De Android 11 CDD zal pas later dit jaar, waarschijnlijk begin september, openbaar worden. Echter, ontwikkelaar @verwijderscape heeft een pre-releaseversie gedeeld van een document met details over de veranderingen die naar de CDD komen, waardoor we al een eerste blik kunnen werpen op hoe Google Android 11 in het hele ecosysteem vormgeeft. De overgrote meerderheid van de ruim zestig wijzigingen in de CDD zijn niet erg interessant voor gebruikers; ze beschrijven hoe apparaatfabrikanten moeten bepaalde API's implementeren, bepaalde functies declareren en een bepaalde kernel implementeren functies. Drie van de wijzigingen in de CDD trokken echter onze aandacht omdat ze betrekking hebben op enkele van de meest interessante functies in Android 11. Dit is wat we hebben ontdekt.

Apparaatbedieningen

Apparaatbediening is een functie in Android 11 waarmee slimme domotica-bedieningen kunnen worden weergegeven in het aan/uit-menu. U kunt uw lichten uitschakelen, uw garagedeur openen, uw stofzuiger starten, de temperatuur van uw huis wijzigen en nog veel meer doen zonder een tiental verschillende smart home-apps te openen. Google heeft API's toegevoegd die ontwikkelaars van smart home-apps kunnen gebruiken om bedieningselementen in het energiemenu weer te geven. Wij vinden dit een leuke functie Brengt eindelijk uw smartphone in het slimme huis. Helaas is er geen vereiste voor OEM's om het daadwerkelijk te implementeren. Als een OEM denkt dat de functie zwak is of een andere route wil inslaan (zoals alleen smart thuisbedieningen vanaf apparaten in hun eigen ecosysteem), dan kunnen ze eenvoudig de ondersteuning voor Device uitschakelen Controles.

Toen Google op 25 februari 2020 voor het eerst Apparaatbedieningen aan de CDD toevoegde, hebben ze de opname ervan verplicht gesteld door een "MUST"-vereiste toe te voegen in Paragraaf 2.2.3 - Softwarevereisten voor draagbare apparaten. Op 20 mei 2020 heeft Google de tekst echter bijgewerkt om de voorgestelde "MOET" te verwijderen. De nieuwe paragraaf 3.8.16 - Apparaatbediening schetst hoe de functie moet worden geïmplementeerd, maar vereist niet dat deze überhaupt wordt geïmplementeerd! We hopen dat OEM's deze handige functie niet zullen uitschakelen, maar we kunnen pas weten of ze deze hebben uitgeschakeld klaar om hun eigen smaken van Android te onthullen die bovenop Android 11 zijn gebouwd, wat pas over enkele maanden zal gebeuren nu.

Voorgestelde sectie 3.8.16 (nieuw) - Apparaatbedieningen (bijgewerkt op 20-05-2020)

3.8.16 Apparaatbedieningen

Android bevat ControlsProviderService en Control API's waarmee ontwikkelaars apparaatbedieningen kunnen publiceren voor snelle status en actie voor gebruikers.

3.8.16.1 Apparaat bepaalt de betaalbaarheid van de gebruiker

Als apparaten Device Controls implementeren, dan:

• [C-1-1] MOET melden dat de vlag android.software.controls.feature WAAR is
• [C-1-2] MOET de gebruiker de mogelijkheid bieden om de favorieten van de gebruiker toe te voegen, te bewerken, te selecteren en te bedienen via de bedieningselementen die zijn geregistreerd door apps van derden via android.service.controls. ControlsProviderService en de android.service.controls. Beheer API's.
• [C-1-3] MOET toegang bieden tot deze gebruikersmogelijkheden binnen drie interacties vanuit de Launcher
• [C-1-4] MOET in deze gebruikersmogelijkheid de naam en het pictogram nauwkeurig weergeven van elke app van derden die bedieningselementen biedt via android.service.controls. ControlsProviderService API, evenals elk gespecificeerd pictogram, statustekst, apparaattype, naam, structuur, zone, aangepaste kleur en ondertiteling geleverd door android.service.controls. Controle-API

Omgekeerd: als apparaatimplementaties dergelijke controles niet implementeren, dan wel

• [C-2-1] MOET Null rapporteren voor de ControlsProviderService en de Control API's.

Lees verder

Gesprekken in meldingen

Een van de grootste voordelen van Android ten opzichte van iOS is de manier waarop eerstgenoemde omgaat met meldingen. Die kloof in bruikbaarheid zal in Android 11 nog groter worden met de introductie van ‘Gesprekken’. In Android 11, meldingen van berichten-apps zijn gegroepeerd en worden weergegeven in een apart gedeelte in het meldingenpaneel boven de meeste andere meldingen. Hierdoor kunt u snel berichten bekijken en erop reageren zonder dat u door al uw andere openstaande meldingen hoeft te bladeren. Helaas is deze handige wijziging in meldingen mogelijk niet op alle apparaten beschikbaar. Google geeft OEM's de mogelijkheid om te kiezen of ze 'gespreksmeldingen vooraf willen groeperen en weergeven niet-conversatiemeldingen." OEM's passen het meldingenpaneel regelmatig aan, en het is dan ook geen verrassing dat Google OEM's een keuze hier. Toch is het jammer dat Google er niet voor kiest om meer consistentie in meldingen in Android 11 af te dwingen.

Voorgestelde wijzigingen in paragraaf 3.8.3.1 - Presentatie van kennisgevingen (bijgewerkt op 4/08/2020)

Als apparaatimplementaties het mogelijk maken dat apps van derden gebruikers op de hoogte stellen van opmerkelijke gebeurtenissen:

...

Android R introduceert ondersteuning voor gespreksmelding, een melding die gebruikmaakt van NotificationManager. MessageStyle en biedt een gepubliceerde People Shortcut ID.

Apparaatimplementaties zijn:

• [H-SR] STERK AANBEVOLEN om gespreksmeldingen te groeperen en weer te geven voordat er geen gesprek plaatsvindt meldingen met uitzondering van doorlopende meldingen van voorgronddiensten en belang: hoog meldingen.

Als gespreksmeldingen zijn gegroepeerd in een aparte sectie, apparaatimplementaties

• [H-1-8] MOET gespreksmeldingen weergeven vóór niet-gespreksmeldingen, met uitzondering van doorlopende servicemeldingen op de voorgrond en belang: hoge meldingen.

Apparaatimplementaties zijn:

• [H-SR] STERK AANBEVOLEN om toegang te bieden tot de volgende acties vanuit gespreksmeldingen: geef dit gesprek weer als een bubbel als de app de vereiste gegevens voor bubbels levert

De AOSP-implementatie voldoet aan deze vereisten met de standaard systeemgebruikersinterface, instellingen en opstartprogramma.

Lees verder

IdentityCredential - Mobiele rijbewijzen

Ten slotte is een van de functies waar ik het meest enthousiast over ben de IdentityCredential API. Zoals we vorig jaar hebben beschrevenis de IdentityCredential API ontworpen om applicaties in staat te stellen identiteitsdocumenten, zoals mobiele rijbewijzen, op het apparaat op te slaan. Verschillende landen (en enkele Amerikaanse staten) over de hele wereld staan ​​hun burgers al toe hun rijbewijs op te slaan in een mobiele app. Google werkt er echter aan om dit veiliger te maken door de gegevens offline in een beveiligde omgeving te laten opslaan.

De broncode voor Android 11 bevat de IdentityCredential API (die ontwikkelaars zullen aanroepen om identiteitsdocumenten op te slaan in de telefoon). beveiligde omgeving) en de IdentityCredential HAL (die communiceert met de beveiligde omgeving van de telefoon), maar OEM's hoeven dit niet te doen implementeer ze. Toen Google op 10 januari 2020 voor het eerst voorstelde om IdentityCredential in de CDD op te nemen, vermeldden ze dit als een vereiste. Ze hebben deze vereiste echter op 18 maart 2020 versoepeld en bevelen nu alleen sterk aan dat OEM's deze functie ondersteunen. Het verbaast ons niet dat Google deze vereiste heeft versoepeld: het toevoegen van een wijziging die van invloed is op de vertrouwde uitvoeringsomgeving zal inspanning van OEM's vergen om te implementeren. Het is mogelijk dat OEM's simpelweg meer tijd nodig hebben om zich op deze verandering voor te bereiden. Voor gebruikers betekent dit echter dat er geen garantie is dat uw specifieke Android 11-smartphone het veilig opslaan van een mobiel rijbewijs in de beveiligde omgeving van de telefoon ondersteunt.

We moeten er rekening mee houden dat er geen technische beperking is die de wijdverbreide adoptie van het IdentityCredential-systeem op Android 11-apparaten verhindert. Een van de vereisten voor het implementeren van het IdentityCredential-systeem is dat het apparaat een Trusted Execution heeft Omgeving (TEE) of een speciale beveiligde processor waarin een "vertrouwde applicatie" interageert met de opgeslagen identiteit documenten. Sinds Android 7.0 Nougat vereist Google dat alle moderne Android-apparaten een "geïsoleerde uitvoeringsomgeving" ondersteunen (per Sectie 2.2.5 - Beveiligingsmodel in de CDD). Apparaten met ARM-processors zijn doorgaans voorzien van ARM's TrustZone TEE, en Google biedt de Betrouwbaar besturingssysteem dat draait op TrustZone. De aanwezigheid van een TEE is voldoende om het IdentityCredential-systeem te ondersteunen, hoewel het veiliger zou zijn als de inloggegevens worden opgeslagen in een ingebouwde, beveiligde CPU (zoals in de Veilige verwerkingseenheid van sommige Qualcomm Snapdragon-processors) of een discrete, veilige CPU (zoals in Titan M van Google of De nieuwe beveiligingschips van Samsung). Met name apparaten met afzonderlijke beveiligde CPU's kunnen mogelijk ook de "Direct Access-modus" -functie van het IdentityCredential-systeem ondersteunen, waarmee de gebruiker zijn identiteitsdocument kan opvragen, zelfs als er niet genoeg stroom meer in het apparaat zit om het hoofdbesturingssysteem op te starten.

Voorgestelde sectie 9.11.3 (nieuw) - Identiteitsreferentie (bijgewerkt op 18-03-2020)

Met het Identity Credential System kunnen app-ontwikkelaars identiteitsdocumenten van gebruikers opslaan en ophalen.

Apparaatimplementaties:

• [C-SR] wordt STERK AANBEVOLEN om het Identiteitsreferentiesysteem te implementeren.

Als apparaatimplementaties het Identity Credential System implementeren:

• [C-0-1] MOET niet-null retourneren voor de IdentityCredentialStore#getInstance() methode.
• [C-0-2] MOET de `android.security.identity.*` API's implementeren met code die communiceert met een vertrouwde applicatie die draait in een Trusted Execution Environment (TEE) of op een speciale beveiliging verwerker. De vertrouwde applicatie moet zodanig worden geïmplementeerd dat de Vertrouwde computerbasis want het Identiteitsreferentiesysteem omvat niet het Android-besturingssysteem.

Lees verder

Google werkt ook aan een IdentityCredential Jetpack-bibliotheek om het voor ontwikkelaars gemakkelijker te maken ondersteuning toe te voegen voor het veilig opslaan van identiteit documenten op Android, maar de echte uitdaging zal erin bestaan ​​om overheden zover te krijgen dat ze apps autoriseren die deze API gebruiken om overheids-ID's veilig op te slaan. Volgens EngadgetZuid-Korea heeft zojuist ondersteuning geïntroduceerd voor het opslaan van rijbewijzen in een mobiele app, dus we beginnen een toename te zien in de acceptatie van deze technologie. Ik ben bijvoorbeeld opgewonden om te zien waar dit naartoe gaat, omdat het betekent dat ik iets minder mee hoef te nemen als ik naar buiten ga.

---

In het document dat we hebben verkregen, staan ​​de wijzigingen in de CDD vermeld op de datum waarop deze wijzigingen zijn aangebracht. De laatste wijzigingen zijn doorgevoerd op 10 juni 2020, wat betekent dat het document dat we hebben redelijk actueel is. Het is mogelijk dat Google deze wijzigingen niet nakomt en alle vereisten opnieuw oplegt vóór de publieke release van Android 11, maar we betwijfelen of Google ineens de CDD zal doorvoeren. meer streng. Deze veranderingen zijn waarschijnlijk versoepeld als gevolg van feedback van OEM's, die degenen zijn die deze functies zullen moeten implementeren als ze dat nog niet van plan waren. Dat kost tijd, moeite en geld, wat de release van Android 11 voor niet-Google-apparaten alleen maar verder zou vertragen. Maar als Google deze functies opnieuw verplicht stelt, zullen we een update op de XDA Portal plaatsen.