Le Compatibility Definition Document (CDD), qui explique aux constructeurs comment s’assurer que leurs appareils sont compatibles avec Android, vient d’être mis à jour. On y trouve une curieuse mention des « Android Extensions », qui laissent présager l’arrivée de bibliothèques partagées.

Avant de plonger dans les Android Extensions, il est nécessaire de rappeler certains points, liés de près à la fragmentation du système. Celle-ci n’est en effet pas si simple.

Android propose tout un lot de technologies fournies sous la forme d’API (Application Programming Interface), qui permettent aux développeurs de faire appel à ses fonctionnalités. Ces API sont réparties en deux grands lots, les unes dans la base du système, les autres dans les Services Google Play.

Les deux grands lots d'API dans Android

La base d’Android, c’est AOSP (Android Open Source Project), le socle open source du projet. Les API qui s’y trouvent se réfèrent toutes à des fonctions centrales, comme la gestion des fichiers, le démarrage, le noyau Linux, les paramètres, tout ce qui touche à l’interface, le contrôle du volume, l’écran verrouillé et ainsi de suite.

De leur côté, les Services Google Play se concentrent tout ce qui concerne les applications et les technologies de type Auto, Pay, les jeux, la gestion des DRM, la synchronisation, etc.

La différence entre les deux ensembles est importante car elle intervient dans la compréhension de la fragmentation d’Android, un sujet récurrent. Elle est évidente quand on inspecte les parts de marché de chaque version du système, mais elle ne se manifeste pas forcément dans le support des applications.

Pourquoi ? Parce que les Services Google Play sont mis à jour indépendamment du système, et cela passe par une nouvelle version diffusée sur le Play Store. Pour qu’une API d’AOSP évolue, il faut une mise à jour du système.

Le blocage des mises à jour par les constructeurs

La firme est bien placée pour savoir que diffuser les mises à jour d’Android est complexe, ce qui provoque un ralentissement de l’utilisation des API liées à AOSP. L’écrasante majorité des appareils vendus provient de constructeurs tiers, dont Google ne contrôle pas le cycle de mise à jour.

Même s’ils bénéficient d’un support garanti de 18 mois pour les mises à jour, la période est vite écoulée. Sans parler de tous les vieux appareils restent sur d’anciennes moutures, avec les énormes risques de sécurité que cela suppose.

Pour Google, la situation est problématique. Non seulement les critiques sur la sécurité sont nombreuses et régulières, mais les développeurs ne peuvent jamais profiter complètement des nouveautés puisqu’une immense majorité des appareils ne fonctionne pas sur les dernières révisions d’Android.

Une situation très différente par exemple de ce que connait Apple, puisque la même version d’iOS est diffusée simultanément à l’ensemble des appareils compatibles. Mais alors, comment sortir de cette impasse ?

Vers des API système déportées ?

Dans la nouvelle version du CDD (pour Android 7.0 Nougat), Google parle des Android Extensions. Il est question d’éléments que les constructeurs auraient l’obligation de charger, quelle que soit l’ampleur des modifications qu’ils apporteront au système.

En théorie, notamment selon nos confrères d’Ars Technica, cela permettrait notamment de déporter vers les Extensions tout un ensemble de briques du système, qui pourraient alors être mise à jour sur le même modèle que les Services Google Play.

En somme, diminuer le nombre d’éléments dont les constructeurs doivent s’occuper. Le texte indique clairement que ces Extensions seraient obligatoires, signifiant probablement au passage qu’elles ne peuvent pas être modifiées. Ars Technica précise qu’actuellement, ces Extensions ne contiennent que deux fichiers, pratiquement vides : GoogleExtShared.apk et GoogleExtServices.apk.

Pourquoi alors les rendre obligatoires ? Nos confrères suggèrent qu’ils seraient alors installés et donc pris en charge par le Play Store… qui pourrait les mettre à jour automatiquement.

GoogleExtServices serait ainsi l’équivalent des Services Google Play d’AOSP : un ensemble grandissant de briques que les constructeurs ne peuvent pas bloquer. Les mises à jour seraient plus régulières, permettant aux développeurs de profiter beaucoup plus rapidement des nouvelles API. GoogleExtShared est présenté comme une bibliothèque partagée, ce qui reviendrait à déporter du système de base des morceaux de code auxquels les applications doivent souvent faire face.

Il faudra sans doute attendre encore avant d’en savoir davantage, et de confirmer une telle possibilité, car Google n’a donné pour l’instant aucune explication complémentaire sur le sujet.

D’autres points importants dans le CDD

Même si les Extensions ont largement attiré l’attention des médias, d’autres éléments importants figurent dans la nouvelle version du CDD. Par exemple, il est désormais « fortement recommandé » aux constructeurs de ne pas s’appuyer sur des technologies propriétaires pour les recharges rapides sur les appareils mobiles.

Autre point significatif, l’obligation pour les constructeurs qui souhaitent utiliser Nougat de proposer un mode multifenêtre si la taille de l’écran le permet. Pour tous les autres, le mode peut être refusé lors de la phase d’implémentation.

Enfin, tous les appareils doivent être munis de capacité de blocage des appels. Même si ce type de fonction se retrouve presque partout, Google préfère manifestement s’assurer de sa présence.