3 des meilleures fonctionnalités d'Android 11 n'apparaîtront pas sur tous les smartphones et tablettes. C'est parce que Google n'impose pas ces fonctionnalités.
Chaque année, Google publie une nouvelle version du système d'exploitation Android. Google a publié le premier aperçu du développeur Android 11 en février, suivi des deuxième, troisième et quatrième aperçus du développeur au cours des derniers mois. Plus tôt ce mois-ci, Google a dévoilé le première version bêta d'Android 11 et a parlé en profondeur des meilleures fonctionnalités dont les utilisateurs peuvent profiter et que les développeurs peuvent mettre en œuvre. Cependant, nous avons appris que trois des principales fonctionnalités d'Android 11 ne seront pas disponibles sur tous les appareils Android.
Pour comprendre comment cela est possible, nous devons expliquer brièvement comment le système d'exploitation Android est distribué par Google aux fabricants de smartphones. Android est un système d'exploitation open source sous licence Apache 2.0, ce qui signifie que n'importe qui, des développeurs indépendants aux grandes entreprises, est libre de modifier et de distribuer le système d'exploitation sur ses propres appareils. La plupart des nouvelles fonctionnalités du système d'exploitation dévoilées par Google pour Android 11 feront partie du projet Android Open Source (AOSP) sur ce smartphone. les fabricants d'appareils basent leur propre logiciel sur cette base, mais la licence Apache 2.0, comme je l'ai déjà mentionné, permet à quiconque de modifier le logiciel comme bon lui semble. ajuster. Afin de maintenir la cohérence des API et du comportement de la plate-forme entre les appareils Android, Google regroupe la distribution des services mobiles Google (qui incluent applications et cadres tels que Google Play Store et Google Play Services) avec des accords de licence exigeant que les appareils respectent les règles de Google "
Dans le CDD, Google répertorie les fonctionnalités logicielles et matérielles que les fabricants d'appareils « DOIVENT » mettre en œuvre, sont uniquement « FORTEMENT RECOMMANDÉES » ou « NE DEVRAIENT PAS » mettre en œuvre. Si une fonctionnalité est répertoriée comme implémentation « DOIT », le fabricant de l'appareil doit ajouter cette fonctionnalité, sinon il ne peut pas proposer d'applications Google sur ses appareils. Si une fonctionnalité est répertoriée comme implémentée « NE DEVRAIT PAS », le fabricant de l'appareil ne peut pas ajouter cette fonctionnalité ou il ne peut pas regrouper les applications Google. Enfin, si une fonctionnalité est répertoriée comme « FORTEMENT RECOMMANDÉE », il appartient alors au fabricant de l'appareil de décider s'il souhaite ou non implémenter la fonctionnalité. Le CDD est un document en constante évolution, avant même sa publication chaque année suite à la sortie publique d'une nouvelle version d'Android. Google met fréquemment à jour le document pour supprimer des fonctionnalités, modifier la langue pour qu'elle soit plus claire et assouplir les exigences en fonction des commentaires de ses partenaires. Cependant, une fois que Google aura rendu public un CDD pour une version particulière d'Android, ces exigences seront gravées dans le marbre pour les appareils certifiés Google exécutant cette version du système d'exploitation Android.
Le CDD Android 11 ne sera rendu public que plus tard cette année, probablement début septembre. Cependant, le développeur @supprimerscape a partagé une copie préliminaire d'un document qui détaille les changements à venir sur le CDD, nous donnant un premier aperçu de la façon dont Google façonne Android 11 dans l'écosystème. La grande majorité des plus de 60 modifications apportées au CDD ne sont pas très intéressantes pour les utilisateurs: elles décrivent comment les fabricants d'appareils doivent implémenter certaines API, déclarer certaines fonctionnalités et implémenter certains noyaux caractéristiques. Cependant, 3 des modifications apportées au CDD ont retenu notre attention car elles concernent certaines des fonctionnalités les plus intéressantes d'Android 11. Voici ce que nous avons découvert.
Contrôles des appareils
Les contrôles des appareils sont une fonctionnalité d'Android 11 qui permet d'afficher les commandes domotiques intelligentes dans le menu d'alimentation. Vous pouvez éteindre vos lumières, ouvrir la porte de votre garage, démarrer votre aspirateur, modifier la température de votre maison et bien plus encore sans ouvrir une douzaine d'applications de maison intelligente différentes. Google a ajouté des API que les développeurs d'applications pour maison intelligente peuvent utiliser pour afficher les commandes dans le menu d'alimentation. Nous pensons qu'il s'agit d'une fonctionnalité intéressante qui amène enfin votre smartphone dans la maison intelligente. Malheureusement, les constructeurs OEM ne sont pas tenus de le mettre en œuvre. Si un OEM pense que la fonctionnalité est boiteuse ou s'il souhaite emprunter une voie différente (par exemple, autoriser uniquement les contrôles domestiques à partir d'appareils de leur propre écosystème), ils peuvent alors simplement désactiver la prise en charge de l'appareil Contrôles.
Lorsque Google a ajouté pour la première fois les contrôles des appareils au CDD le 25 février 2020, ils ont rendu obligatoire leur inclusion en ajoutant une exigence « DOIT » dans la section 2.2.3 – Exigences relatives aux logiciels portables. Cependant, le 20 mai 2020, Google a mis à jour le texte pour supprimer le « MUST » proposé. La nouvelle section 3.8.16 – Contrôles des appareils décrit comment la fonctionnalité doit être implémentée, mais n'exige pas réellement qu'elle soit implémentée en premier lieu! Nous espérons que les OEM ne désactiveront pas cette fonctionnalité intéressante, mais nous n'avons aucun moyen de savoir s'ils l'ont désactivée jusqu'à ce qu'ils le soient. prêts à dévoiler leurs propres versions d'Android construites sur Android 11, ce qui n'arrivera que plusieurs mois après maintenant.
Section 3.8.16 proposée (nouvelle) - Contrôles des appareils (mise à jour le 20/05/2020)
3.8.16 Contrôles des appareils
Android inclut les API ControlsProviderService et Control pour permettre aux développeurs de publier des contrôles d'appareil pour un état et une action rapides pour les utilisateurs.
3.8.16.1 Capacité de l'utilisateur à contrôler les appareils
Si les appareils implémentent des contrôles d’appareils, ils :
- [C-1-1] DOIT signaler que l'indicateur android.software.controls.feature est VRAI
- [C-1-2] DOIT fournir à l'utilisateur la possibilité d'ajouter, de modifier, de sélectionner et d'utiliser les favoris de l'utilisateur à partir des commandes enregistrées par les applications tierces via android.service.controls. ControlsProviderService et android.service.controls. API de contrôle.
- [C-1-3] DOIT fournir l'accès à cette fonctionnalité utilisateur dans un délai de trois interactions à partir du lanceur.
- [C-1-4] DOIT restituer avec précision dans cette fonctionnalité utilisateur le nom et l'icône de chaque application tierce qui fournit des contrôles via android.service.controls. API ControlsProviderService ainsi que toute icône spécifiée, texte d'état, type d'appareil, nom, structure, zone, couleur personnalisée et sous-titre fournis par android.service.controls. API de contrôle
À l’inverse, si les implémentations d’appareils n’implémentent pas de tels contrôles, alors elles
- [C-2-1] DOIT rapporter Null pour ControlsProviderService et les API de contrôle.
En savoir plus
Conversations dans les notifications
L'un des plus grands avantages d'Android par rapport à iOS est la manière dont le premier gère les notifications. Cet écart en termes de convivialité s'élargira encore plus dans Android 11 avec l'introduction des « Conversations ». Sous Android 11, les notifications des applications de messagerie sont regroupés et sont affichés dans une section distincte dans le panneau de notification au-dessus de la plupart des autres notifications. Cela vous permet de voir et de répondre rapidement aux messages sans avoir à faire défiler toutes vos autres notifications en attente. Malheureusement, cette astucieuse modification des notifications peut ne pas être disponible sur tous les appareils. Google donne aux OEM la possibilité de choisir s'ils souhaitent « regrouper et afficher les notifications de conversation avant notifications hors conversation. " Les OEM personnalisent fréquemment le panneau de notification, et il n'est donc pas surprenant que Google donne aux OEM un choix ici. Il est néanmoins regrettable que Google ne choisisse pas d'imposer plus de cohérence dans les notifications dans Android 11.
Modifications proposées à la section 3.8.3.1 - Présentation des notifications (mise à jour le 4/08/2020)
Si les implémentations d'appareils permettent à des applications tierces d'informer les utilisateurs d'événements notables, elles :
...
Android R introduit la prise en charge de la notification de conversation, qui est une notification qui utilise NotificationManager. MessageStyle et fournit un ID de raccourci de personnes publié.
Les implémentations d'appareils sont :
- [H-SR] FORTEMENT RECOMMANDÉ de regrouper et d'afficher les notifications de conversation avant une non-conversation notifications à l'exception des notifications de service de premier plan en cours et importance: élevée notifications.
Si les notifications de conversation sont regroupées dans une section distincte, les implémentations d'appareils
- [H-1-8] DOIT afficher les notifications de conversation avant les notifications de non-conversation, à l'exception des notifications de service de premier plan en cours et de l'importance: notifications élevées.
Les implémentations d'appareils sont :
- [H-SR] FORTEMENT RECOMMANDÉ de donner accès aux actions suivantes à partir des notifications de conversation: afficher cette conversation sous forme de bulle si l'application fournit les données requises pour les bulles
L'implémentation AOSP répond à ces exigences avec l'interface utilisateur système, les paramètres et le lanceur par défaut.
En savoir plus
IdentityCredential - Permis de conduire mobiles
Enfin, l’une des fonctionnalités qui me passionne le plus est l’API IdentityCredential. Comme nous l'avions détaillé l'année dernière, l'API IdentityCredential est conçue pour permettre aux applications de stocker des documents d'identité, tels que des permis de conduire mobiles, sur l'appareil. Plusieurs pays (et certains États américains) dans le monde autorisent déjà leurs citoyens à stocker leur permis de conduire dans une application mobile. Cependant, Google s'efforce de rendre cela plus sécurisé en stockant les données hors ligne dans un environnement sécurisé.
Le code source d'Android 11 inclut l'API IdentityCredential (que les développeurs appelleront pour stocker les documents d'identité dans le dossier du téléphone). environnement sécurisé) et le IdentityCredential HAL (qui s'interface avec l'environnement sécurisé du téléphone), mais les OEM ne sont pas tenus de le faire. les mettre en œuvre. Lorsque Google a proposé pour la première fois l'inclusion d'IdentityCredential dans le CDD le 10 janvier 2020, ils l'ont répertorié comme une exigence. Cependant, ils ont assoupli cette exigence le 18 mars 2020 et recommandent désormais uniquement aux OEM de prendre en charge cette fonctionnalité. Nous ne sommes pas surpris que Google ait assoupli cette exigence: l'ajout d'un changement ayant un impact sur l'environnement d'exécution fiable nécessitera des efforts de mise en œuvre de la part des OEM. Il est possible que les équipementiers aient simplement besoin de plus de temps pour se préparer à ce changement. Pour les utilisateurs, cependant, cela signifie que rien ne garantit que votre smartphone Android 11 prendra en charge le stockage sécurisé d'un permis de conduire mobile dans l'environnement sécurisé du téléphone.
Il convient de noter qu'aucune limitation technique n'empêche l'adoption généralisée du système IdentityCredential parmi les appareils Android 11. L'une des conditions requises pour la mise en œuvre du système IdentityCredential est que l'appareil dispose d'un système d'exécution sécurisé. Environnement (TEE) ou processeur sécurisé dédié dans lequel une « application de confiance » interagit avec l'identité stockée documents. Depuis Android 7.0 Nougat, Google exige que tous les appareils Android modernes prennent en charge un « environnement d'exécution isolé » (par Section 2.2.5 - Modèle de sécurité dans le CDD). Les appareils équipés de processeurs ARM comportent généralement des processeurs ARM Zone de confiance TEE, et Google fournit le Système d'exploitation fiable qui fonctionne sur TrustZone. La présence d'un TEE est suffisante pour prendre en charge le système IdentityCredential, bien qu'il serait plus sécurisé si les informations d'identification étaient stockées dans un processeur sécurisé intégré (comme dans le Unité de traitement sécurisée de certains processeurs Qualcomm Snapdragon) ou un processeur sécurisé discret (comme dans Le Titan M de Google ou Les nouvelles puces de sécurité de Samsung). Notamment, les appareils dotés de processeurs sécurisés discrets peuvent également prendre en charge la fonctionnalité « Mode d'accès direct » du système IdentityCredential, ce qui permettra à l'utilisateur de récupérer sa pièce d'identité même s'il n'y a plus assez de puissance dans l'appareil pour démarrer le système d'exploitation principal.
Article 9.11.3 proposé (nouveau) - Titre d'identité (mis à jour le 18/03/2020)
Le système d'identification d'identité permet aux développeurs d'applications de stocker et de récupérer les documents d'identité des utilisateurs.
Implémentations d'appareils :
- [C-SR] est FORTEMENT RECOMMANDÉ de mettre en œuvre le système d'identification et d'identification.
Si les implémentations d'appareils implémentent le système d'identification d'identité, elles :
- [C-0-1] DOIT renvoyer une valeur non nulle pour le IdentityCredentialStore#getInstance() méthode.
- [C-0-2] DOIT implémenter les API `android.security.identity.*` avec du code communiquant avec un application s'exécutant soit dans un environnement d'exécution de confiance (TEE), soit sur un site sécurisé dédié. processeur. L'application de confiance doit être implémentée de telle sorte que le Base informatique fiable pour le système d'identification d'identité n'inclut pas le système d'exploitation Android.
En savoir plus
Google travaille également sur une bibliothèque IdentityCredential Jetpack pour permettre aux développeurs d'ajouter plus facilement la prise en charge du stockage sécurisé des identités. documents sur Android, mais le véritable défi sera d'amener les gouvernements à autoriser les applications utilisant cette API pour stocker en toute sécurité les identifiants gouvernementaux. Selon Engadget, la Corée du Sud vient de déployer la prise en charge du stockage des permis de conduire dans une application mobile, nous commençons donc à constater une légère acceptation de cette technologie. Pour ma part, je suis impatient de voir où cela me mènera, car cela signifiera une chose de moins à emporter avec moi lorsque je sors.
Le document que nous avons obtenu répertoriait les modifications apportées au CDD à la date à laquelle ces modifications ont été apportées. Les dernières modifications ont été apportées le 10 juin 2020, ce qui signifie que le document dont nous disposons est assez à jour. Il est possible que Google revienne sur ces changements et impose à nouveau toutes les exigences avant la sortie publique d'Android 11, mais nous doutons que Google fasse tout d'un coup le CDD. plus strict. Ces changements ont probablement été assouplis en raison des commentaires des constructeurs OEM qui devront revenir en arrière et implémenter ces fonctionnalités s'ils n'avaient pas déjà prévu de le faire. Cela prend du temps, des efforts et de l’argent, ce qui ne ferait que retarder encore davantage la sortie d’Android 11 pour les appareils non Google. Néanmoins, si Google rend ces fonctionnalités à nouveau requises, nous publierons une mise à jour sur le portail XDA.