Je me permet de corriger ici quelques erreurs et imprécisions techniques présentes dans la dépêche :

> Android, sorti fin 2007, a pour seul point commun Linux, le noyau du système d'exploitation (rappelons à ce sujet que, depuis octobre 2011, les projets Android et Linux collaborent pour minimiser les différences entre la version utilisée par le premier et celle publiée par le second).

Le compilateur gcc, un projet GNU, est en outre utilisé par les deux systèmes (mais n'est pas distribué dans le système sur Android). Il s'agit d'un détail cependant.

> Ces choix correspondent, pour la plupart, au fait que les besoins pour un ordiphone ou une tablette sont plus limités que pour un PC, tout comme les ressources matérielles (processeur, mémoire). Les solutions logicielles retenues ont donc généralement des fonctionnalités plus limitées mais une empreinte mémoire plus faible.

Je ne vois pas du tout ce-qui permet de justifier une telle affirmation : cela semble tout bonnement inventé selon un principe de "logique" faillible. Android est au niveau des performances bel et bien beaucoup plus lourd qu'une distribution GNU/Linux avec les logiciels appropriés. Un exemple en est la comparaison entre un Nexus S sous Android et sous SHR: GNU/Linux, avec le serveur Xorg, est bien plus rapide (à noyaux et blobs égaux).

> Ces pilotes sont en effet conçus pour la bibliothèque C d'Android (Bionic libc) qui n'est pas compatible avec la bibliothèque C du projet GNU (glibc).

Cela me semble-être une grossière simplification. Les pilotes ne sont pas écrits pour une certaine libc (qui par ailleurs suit des normes POSIX) et pour peu que ces drivers soient libres, ils peuvent tout à fait-être recompilés et linkés avec la glibc. Si par contre ils ne sont pas libres, alors effectivement, seule la librairie avec laquelle ces pilotes sont linkés permettra de les exécuter, mais ce n'est là rien de spécifique à Android.

La raison évidente qui explique que les drivers Android ne fonctionnent pas sous GNU/Linux est bien naturellement une question d'API: Android, son framework et le reste utilisent des API spécifiques pour de tels drivers qui n'ont pas d'implémentation sous GNU/Linux (bien que ce-soit tout à fait réalisable, et je crois qu'il s'agit du projet libhybris).

> Face à cette situation, deux solutions sont possibles : développer des pilotes (libres), notamment par rétro-ingénierie (c'est, par exemple, ce qui est en train d'être réalisé pour les GPU embarqués dans les ordiphones et tablettes) ou s'arranger pour pouvoir utiliser les pilotes (libres ou non) conçus pour Android (via la bibliothèque libre Libhybris conçue initialement pour le projet Mer – plus ici, ici et là).

Si les pilotes pour Android sont libres, alors le code peut-être réutilisé pour GNU/Linux, ce-qui est effectivement mis en œuvre quand des distributions GNU/Linux sont portées sur des téléphones Android (c'est le cas pour le projet SHR par exemple).

Salut PaulK, merci pour ton riche commentaire, c'est très instructif comme d'habitude.
Étant simple utilisateur, je gravis péniblement les échelons de la connaissance au fur et à mesure de mes investigations sur le Web. Je pensais avoir compris pourquoi il fallait des pilotes différents malgré un noyau commun (ça me turlupinait) mais je vois que je n'avais pas deviné tout à fait juste...

Sinon, j'ai écrit "Ces choix correspondent, pour la plupart, au fait que les besoins pour un ordiphone ou une tablette sont plus limités que pour un PC, tout comme les ressources matérielles (processeur, mémoire). Les solutions logicielles retenues ont donc généralement des fonctionnalités plus limitées mais une empreinte mémoire plus faible" en pensant à la Bionic libc et à SurfaceFlinger qui, d'après mes lectures sur le Web, sont plus légers dans tous les sens du terme (fonctions, mémoire).

Par ailleurs, désolé du ton de mon commentaire précédent, bien trop agressif à mon goût, qui s'explique par un certain manque de sommeil et un énervement passager qui n'a rien à voir avec cet article.

Bref, sur le fond, le problème avec les "pilotes" est que globalement, les pilotes sous GNU/Linux sont dans le noyau et utilisent des interfaces "standardisées" pour que l'user-space soit générique (par exemple: ALSA, V4L2, etc).

Sur Android, de nombreux constructeurs n'utilisent pas ces interfaces et implémentent les choses à leur sauce. De fait, c'est l'user-space qui doit s'adapter au noyau avec des couches d'abstraction matérielles (les HAL, qui sont les véritables drivers sur Android). Typiquement, on a: Linux <-> HAL <-> Framework Android <-> Applications.

Ces drivers utilisent donc les API du framework Android qui ne sont pas standard.

Sur GNU/Linux, on a plutôt des briques qui implémentent les interfaces standard du noyau et des logiciels qui viennent utiliser ces briques. Par exemple pour l'Audio: Linux et ALSA <-> Pulseaudio <-> Applications (totem par exemple).

@PaulK : pas de soucis, ayant déjà un peu échangé avec toi, je n'y ai rien vu de désobligeant.

Pour que je comprenne bien : FirefoxOS, par exemple, utilise un noyau Linux tel que modifié par Android OSP https://wiki.mozilla.org/B2G/Architecture#Kernel_.28Linux.29
Ce noyau est associé à des bibliothèques couramment utilisées dans nos distributions GNU/Linux (libusb, bluez, etc) mais aussi à des HAL d'Android (GPS, camera...) , soit un mélange des deux mondes pour pouvoir tourner sur un maximum d'appareils https://wiki.mozilla.org/B2G/Architecture#Terminology

Sinon, y a t-il une raison à ce que les API du framework Android ne soient pas standards ?

> Ce noyau est associé à des bibliothèques couramment utilisées dans nos distributions GNU/Linux (libusb, bluez, etc) mais aussi à des HAL d'Android (GPS, camera...) , soit un mélange des deux mondes pour pouvoir tourner sur un maximum d'appareils https://wiki.mozilla.org/B2G/Architecture#Terminology

Oui, en fait, Android réutilise les librairies GNU/Linux qui existent déjà pour certains types de matériel (WiFi, Bluetooth par exemple) et implémente ses propres API pour d'autres (Audio, Camera, NFC, etc). Bref, c'est un peu curieux.

> Sinon, y a t-il une raison à ce que les API du framework Android ne soient pas standards ?

La raison est que les API standards sont celles du noyau (V4L2, ALSA) et que les constructeurs ne veulent pas que les véritables drivers soient dans le noyau, mais plutôt en userspace, puisqu'ils ont obligation de libérer les sources du noyau utilisées, alors que ce n'est pas le cas pour l'user-space. Du coup, Android a créé des API pour les librairies fournies par les constructeurs, mais elles ne sont propres qu'à Android et ne sont pas une norme ou un standard.

@PaulK qui écrit "Un exemple en est la comparaison entre un Nexus S sous Android et sous SHR: GNU/Linux, avec le serveur Xorg, est bien plus rapide (à noyaux et blobs égaux)."
Tu as dû voir ces liens également, au sujet des performances de Weston/Wayland https://linuxfr.org/users/gabin_2-0/journaux/mir-est-peut-etre-une-heresie-mais#comment-1453793 & http://liens.planet-libre.org/?i5AW0w

@PaulK : J'ai tenté de corriger le billet pour tenir compte de tes explications...

Autre petite chose : GNOME fait parti du projet GNU.