Drei der besten Funktionen von Android 11 werden nicht auf allen Smartphones und Tablets angezeigt. Das liegt daran, dass Google diese Funktionen nicht vorschreibt.
Jedes Jahr veröffentlicht Google eine neue Version des Android-Betriebssystems. Google veröffentlichte bereits im Februar die erste Entwicklervorschau für Android 11, gefolgt von der zweiten, dritten und vierten Entwicklervorschau in den letzten Monaten. Anfang dieses Monats stellte Google das vor erste Android 11 Beta und ausführlich über die besten Funktionen gesprochen, die Benutzer genießen und die Entwickler implementieren können. Allerdings haben wir jetzt erfahren, dass drei der Top-Funktionen von Android 11 nicht auf jedem Android-Gerät verfügbar sein werden.
Um zu verstehen, wie das möglich ist, müssen wir kurz erklären, wie das Android-Betriebssystem von Google an Smartphone-Gerätehersteller verteilt wird. Android ist ein Open-Source-Betriebssystem lizenziert unter Apache 2.0, was bedeutet, dass jeder, vom unabhängigen Entwickler bis zum großen Unternehmen, das Betriebssystem frei ändern und auf seinen eigenen Geräten verteilen kann. Die meisten der neuen Betriebssystemfunktionen, die Google für Android 11 vorgestellt hat, werden Teil des Android Open Source Project (AOSP) dieses Smartphones sein Gerätehersteller basieren auf ihrer eigenen Software, aber die Apache 2.0-Lizenz erlaubt, wie ich bereits erwähnt habe, jedem, die Software nach Belieben zu ändern fit. Um die Konsistenz der APIs und des Plattformverhaltens zwischen Android-Geräten aufrechtzuerhalten, bündelt Google die Verteilung der Google Mobile Services (einschließlich Anwendungen und Frameworks wie der Google Play Store und Google Play Services) mit Lizenzvereinbarungen, die vorschreiben, dass Geräte den Regeln von Google entsprechen "
Im CDD listet Google Software- und Hardwarefunktionen auf, die Gerätehersteller implementieren „MÜSSEN“, deren Implementierung nur „DRINGEND EMPFOHLEN“ wird oder deren Implementierung „NICHT“ implementiert werden sollte. Wenn eine Funktion als „MUSS implementiert“ aufgeführt ist, muss der Gerätehersteller diese Funktion hinzufügen, sonst kann er keine Google-Apps auf seinen Geräten bereitstellen. Wenn eine Funktion als „NICHT implementiert“ aufgeführt ist, kann der Gerätehersteller diese Funktion nicht hinzufügen oder Google-Apps nicht bündeln. Wenn schließlich eine Funktion als „DRINGEND EMPFOHLEN“ aufgeführt ist, liegt es am Gerätehersteller, ob er die Funktion implementieren möchte oder nicht. Das CDD ist ein sich ständig änderndes Dokument, bereits vor seiner Veröffentlichung jedes Jahr nach der Veröffentlichung einer neuen Android-Version. Google aktualisiert das Dokument regelmäßig, um Funktionen zu entfernen, die Sprache klarer zu gestalten und die Anforderungen basierend auf dem Feedback seiner Partner zu lockern. Sobald Google jedoch ein CDD für eine bestimmte Android-Version veröffentlicht, werden diese Anforderungen für Google-zertifizierte Geräte, auf denen diese Android-Betriebssystemversion ausgeführt wird, in Stein gemeißelt.
Das Android 11 CDD wird erst später in diesem Jahr veröffentlicht, voraussichtlich Anfang September. Entwickler @deletescape hat eine Vorabversion eines Dokuments geteilt, in dem die bevorstehenden Änderungen am CDD detailliert beschrieben werden. Dies gibt uns einen ersten Einblick in die Art und Weise, wie Google Android 11 im gesamten Ökosystem gestaltet. Die überwiegende Mehrheit der über 60 Änderungen am CDD ist für Benutzer nicht sehr interessant – sie beschreiben wie Gerätehersteller müssen bestimmte APIs implementieren, bestimmte Funktionen deklarieren und einen bestimmten Kernel implementieren Merkmale. Drei der Änderungen am CDD erregten jedoch unsere Aufmerksamkeit, da sie sich auf einige der interessantesten Funktionen in Android 11 beziehen. Das haben wir herausgefunden.
Gerätesteuerung
Gerätesteuerung ist eine Funktion in Android 11, die die Anzeige von Smart-Home-Automatisierungssteuerungen im Power-Menü ermöglicht. Sie können Ihr Licht ausschalten, Ihr Garagentor öffnen, Ihren Staubsauger starten, die Temperatur in Ihrem Zuhause ändern und vieles mehr, ohne ein Dutzend verschiedener Smart-Home-Apps öffnen zu müssen. Google hat APIs hinzugefügt, mit denen Entwickler von Smart-Home-Apps Steuerelemente im Power-Menü anzeigen können. Wir denken, dass dies eine nette Funktion ist bringt Ihr Smartphone endlich ins Smart Home. Leider besteht für OEMs keine Verpflichtung, es tatsächlich umzusetzen. Wenn ein OEM die Funktion für lahm hält oder einen anderen Weg einschlagen möchte (z. B. nur Smart Wenn Sie beispielsweise Heimsteuerungen von Geräten in ihrem eigenen Ökosystem nutzen, können Sie die Unterstützung für das Gerät einfach deaktivieren Kontrollen.
Als Google am 25. Februar 2020 zum ersten Mal Gerätekontrollen zum CDD hinzufügte, forderte es deren Aufnahme durch die Hinzufügung einer „MUSS“-Anforderung in Abschnitt 2.2.3 – Anforderungen an Handheld-Software. Am 20. Mai 2020 aktualisierte Google jedoch den Text, um das vorgeschlagene „MUSS“ zu entfernen. Der neue Abschnitt 3.8.16 – Gerätekontrollen beschreibt, wie die Funktion implementiert werden muss, erfordert jedoch nicht, dass sie überhaupt implementiert wird! Wir hoffen, dass OEMs diese praktische Funktion nicht deaktivieren, aber wir können erst dann herausfinden, ob sie sie deaktiviert haben sind bereit, ihre eigenen Android-Varianten auf Basis von Android 11 vorzustellen, was erst in einigen Monaten der Fall sein wird Jetzt.
Vorgeschlagener Abschnitt 3.8.16 (neu) – Gerätekontrollen (aktualisiert am 20.05.2020)
3.8.16 Gerätesteuerung
Android umfasst ControlsProviderService- und Control-APIs, mit denen Entwickler Gerätesteuerelemente veröffentlichen können, um Benutzern einen schnellen Status und Aktionen zu ermöglichen.
3.8.16.1 Gerät steuert die Benutzerfreundlichkeit
Wenn Geräte Gerätesteuerungen implementieren, dann:
- [C-1-1] MUSS das Flag „android.software.controls.feature“ als TRUE melden
- [C-1-2] MUSS einem Benutzer die Möglichkeit bieten, die Favoriten des Benutzers über die von Drittanbieter-Apps über android.service.controls registrierten Steuerelemente hinzuzufügen, zu bearbeiten, auszuwählen und zu bedienen. ControlsProviderService und android.service.controls. Steuer-APIs.
- [C-1-3] MUSS Zugriff auf dieses Benutzerangebot innerhalb von drei Interaktionen vom Launcher aus ermöglichen
- [C-1-4] In diesem Benutzerangebot MÜSSEN der Name und das Symbol jeder Drittanbieter-App, die Steuerelemente über android.service.controls bereitstellt, genau wiedergegeben werden. ControlsProviderService-API sowie alle angegebenen Symbole, Statustexte, Gerätetypen, Namen, Strukturen, Zonen, benutzerdefinierten Farben und Untertitel, die von android.service.controls bereitgestellt werden. Steuerungs-API
Umgekehrt: Wenn Geräteimplementierungen solche Steuerelemente nicht implementieren, dann tun sie es
- [C-2-1] MUSS Null für den ControlsProviderService und die Control-APIs melden.
mehr lesen
Gespräche in Benachrichtigungen
Einer der größten Vorteile von Android im Vergleich zu iOS ist die Art und Weise, wie ersteres mit Benachrichtigungen umgeht. Diese Lücke in der Benutzerfreundlichkeit wird in Android 11 mit der Einführung von „Konversationen“ noch größer. In Android 11 Benachrichtigungen von Messaging-Apps werden gruppiert und in einem separaten Abschnitt im Benachrichtigungsfeld über den meisten anderen angezeigt Benachrichtigungen. Auf diese Weise können Sie Nachrichten schnell anzeigen und beantworten, ohne durch alle anderen ausstehenden Benachrichtigungen scrollen zu müssen. Leider ist diese praktische Änderung an den Benachrichtigungen möglicherweise nicht auf allen Geräten verfügbar. Google gibt OEMs die Möglichkeit zu wählen, ob sie Konversationsbenachrichtigungen im Voraus gruppieren und anzeigen möchten Nicht-Konversationsbenachrichtigungen.“ OEMs passen das Benachrichtigungsfeld häufig an, und daher ist es keine Überraschung, dass Google OEMs mitteilt eine Wahl hier. Dennoch ist es bedauerlich, dass Google sich nicht dafür entscheidet, in Android 11 mehr Konsistenz bei den Benachrichtigungen durchzusetzen.
Vorgeschlagene Änderungen an Abschnitt 3.8.3.1 – Vorlage von Meldungen (aktualisiert am 04.08.2020)
Wenn Geräteimplementierungen es Drittanbieter-Apps ermöglichen, Benutzer über wichtige Ereignisse zu benachrichtigen, tun sie Folgendes:
...
Android R führt Unterstützung für Konversationsbenachrichtigungen ein, eine Benachrichtigung, die NotificationManager verwendet. MessageStyle und stellt eine veröffentlichte Personenverknüpfungs-ID bereit.
Geräteimplementierungen sind:
- [H-SR] WIRD DRINGEND EMPFOHLEN, Konversationsbenachrichtigungen vor Nichtkonversationen zu gruppieren und anzuzeigen Benachrichtigungen mit Ausnahme laufender Vordergrunddienstbenachrichtigungen und Wichtigkeit: hoch Benachrichtigungen.
Wenn Konversationsbenachrichtigungen in einem separaten Abschnitt gruppiert sind, Geräteimplementierungen
- [H-1-8] Konversationsbenachrichtigungen MÜSSEN vor Nicht-Konversationsbenachrichtigungen angezeigt werden, mit Ausnahme laufender Vordergrunddienstbenachrichtigungen und Wichtigkeit: Hoch-Benachrichtigungen.
Geräteimplementierungen sind:
- [H-SR] WIRD DRINGEND EMPFOHLEN, über Konversationsbenachrichtigungen Zugriff auf die folgenden Aktionen bereitzustellen: Diese Konversation als Blase anzeigen, wenn die App die erforderlichen Daten für Blasen bereitstellt
Die AOSP-Implementierung erfüllt diese Anforderungen mit der Standard-Systembenutzeroberfläche, den Einstellungen und dem Launcher.
mehr lesen
IdentityCredential – Mobile Führerscheine
Schließlich ist eine der Funktionen, die mich am meisten begeistert, die IdentityCredential-API. Wie wir letztes Jahr ausführlich dargelegt habenDie IdentityCredential-API soll es Anwendungen ermöglichen, Identitätsdokumente, wie z. B. mobile Führerscheine, auf dem Gerät zu speichern. Mehrere Länder (und einige US-Bundesstaaten) auf der ganzen Welt erlauben ihren Bürgern bereits, ihre Führerscheine in einer mobilen App zu speichern. Google arbeitet jedoch daran, die Sicherheit zu erhöhen, indem die Daten offline in einer sicheren Umgebung gespeichert werden.
Der Quellcode für Android 11 enthält die IdentityCredential-API (die Entwickler aufrufen werden, um Identitätsdokumente im Telefon zu speichern). sichere Umgebung) und das IdentityCredential HAL (das mit der sicheren Umgebung des Telefons verbunden ist), OEMs sind jedoch nicht dazu verpflichtet sie umsetzen. Als Google am 10. Januar 2020 erstmals die Aufnahme von IdentityCredential in das CDD vorschlug, wurde dies als Voraussetzung aufgeführt. Sie haben diese Anforderung jedoch am 18. März 2020 gelockert und empfehlen OEMs nur noch dringend, diese Funktion zu unterstützen. Wir sind nicht überrascht, dass Google diese Anforderung gelockert hat – das Hinzufügen einer Änderung, die sich auf die vertrauenswürdige Ausführungsumgebung auswirkt, erfordert Aufwand für die Implementierung seitens der OEMs. Es ist möglich, dass OEMs einfach mehr Zeit brauchen, um sich auf diese Änderung vorzubereiten. Für Benutzer bedeutet dies jedoch, dass es keine Garantie dafür gibt, dass Ihr bestimmtes Android 11-Smartphone die sichere Speicherung eines mobilen Führerscheins in der sicheren Umgebung des Telefons unterstützt.
Wir sollten beachten, dass es keine technische Einschränkung gibt, die der weit verbreiteten Einführung des IdentityCredential-Systems auf Android 11-Geräten entgegensteht. Eine der Voraussetzungen für die Implementierung des IdentityCredential-Systems ist, dass das Gerät über eine vertrauenswürdige Ausführung verfügt Umgebung (TEE) oder ein dedizierter sicherer Prozessor, in dem eine „vertrauenswürdige Anwendung“ mit der gespeicherten Identität interagiert Unterlagen. Seit Android 7.0 Nougat verlangt Google von allen modernen Android-Geräten die Unterstützung einer „isolierten Ausführungsumgebung“ (per Abschnitt 2.2.5 – Sicherheitsmodell im CDD). Geräte mit ARM-Prozessoren verfügen normalerweise über ARMs TrustZone TEE, und Google stellt das bereit Vertrauenswürdiges Betriebssystem das auf TrustZone läuft. Das Vorhandensein eines TEE reicht aus, um das IdentityCredential-System zu unterstützen. Allerdings wäre es sicherer, wenn die Anmeldeinformationen in einer eingebetteten sicheren CPU gespeichert würden (z. B. im Secure Processing Unit einiger Qualcomm Snapdragon-Prozessoren) oder eine diskrete sichere CPU (z. B. in Googles Titan M oder Samsungs neue Sicherheitschips). Insbesondere können Geräte mit diskreten sicheren CPUs möglicherweise auch die Funktion „Direktzugriffsmodus“ des IdentityCredential-Systems unterstützen. Dies ermöglicht es dem Benutzer, sein Ausweisdokument auch dann abzurufen, wenn das Gerät nicht mehr genügend Strom hat, um das Hauptbetriebssystem zu starten.
Vorgeschlagener Abschnitt 9.11.3 (neu) – Identitätsnachweis (aktualisiert am 18.03.2020)
Das Identity Credential System ermöglicht App-Entwicklern das Speichern und Abrufen von Benutzeridentitätsdokumenten.
Geräteimplementierungen:
- [C-SR] wird DRINGEND EMPFOHLEN, das Identity Credential System zu implementieren.
Wenn Geräteimplementierungen das Identity Credential System implementieren, gilt Folgendes:
- [C-0-1] MUSS einen Wert ungleich Null zurückgeben IdentityCredentialStore#getInstance() Methode.
- [C-0-2] MUSS die „android.security.identity.*“-APIs mit Code implementieren, der mit einem vertrauenswürdigen kommuniziert Anwendung, die entweder in einer Trusted Execution Environment (TEE) oder auf einem dedizierten sicheren Server ausgeführt wird Prozessor. Die vertrauenswürdige Anwendung muss so implementiert werden, dass die Vertrauenswürdige Computerbasis Für das Identity Credential System ist das Android-Betriebssystem nicht enthalten.
mehr lesen
Google arbeitet außerdem an einer IdentityCredential Jetpack-Bibliothek, um es Entwicklern zu erleichtern, Unterstützung für die sichere Speicherung von Identitäten hinzuzufügen Dokumente auf Android, aber die eigentliche Herausforderung wird darin bestehen, Regierungen dazu zu bringen, Apps mithilfe dieser API zu autorisieren, um Regierungsausweise sicher zu speichern. Entsprechend EngadgetSüdkorea hat gerade die Unterstützung für das Speichern von Führerscheinen in einer mobilen App eingeführt, sodass wir eine zunehmende Akzeptanz dieser Technologie feststellen können. Ich jedenfalls bin gespannt, wohin das führt, denn dann muss ich eine Sache weniger mitnehmen, wenn ich nach draußen gehe.
In dem Dokument, das wir erhalten haben, sind die Änderungen an der CDD bis zu dem Datum aufgeführt, an dem diese Änderungen vorgenommen wurden. Die letzten Änderungen wurden am 10. Juni 2020 vorgenommen, was bedeutet, dass das uns vorliegende Dokument ziemlich aktuell ist. Es ist möglich, dass Google auf diese Änderungen verzichtet und alle Anforderungen vor der öffentlichen Veröffentlichung von Android 11 erneut stellt. Wir bezweifeln jedoch, dass Google die CDD plötzlich veröffentlichen wird mehr streng. Diese Änderungen wurden wahrscheinlich aufgrund des Feedbacks von OEMs gelockert, die diejenigen sein werden, die zurückgehen und diese Funktionen implementieren müssen, wenn sie dies nicht bereits geplant hatten. Das kostet Zeit, Mühe und Geld, was die Veröffentlichung von Android 11 für Nicht-Google-Geräte nur noch weiter verzögern würde. Sollte Google diese Funktionen dennoch erneut erforderlich machen, werden wir ein Update auf dem XDA-Portal veröffentlichen.