Les composants GNU, ou pourquoi Android n'est pas une distribution GNU/Linux

Rédigé par antistress le 20 mai 2013 (mis à jour le 24 avril 2016) - 8 commentaires

Le logo du projet GNU (un gnou)

Note : Ce billet aborde la question sous un angle purement technique.

On peut se demander pourquoi les pilotes des appareils fonctionnant sous Android (spécialement les ordiphones et tablettes) ne marchent pas avec nos distributions GNU/Linux habituelles (ou, autrement dit, pourquoi nos distributions GNU/Linux ne peuvent pas facilement tourner sur un appareil fonctionnant sous Android), alors que les deux partagent le même noyau : Linux (d'autant que celui-ci est censé inclure la plupart des pilotes).

Pour rappel, une distribution GNU/Linux inclut généralement a minima :

  • un noyau : Linux (créé en 1991),
  • des composants du projet GNU (lancé en 1984) comme glibc (pour GNU C Library – la bibliothèque C GNU créée en 1987), coreutils (pour GNU Core Utilities – les outils de base GNU), Bash (pour Bourne-Again shell – le shell GNU).

S'il s'agit d'une distribution pour poste de travail (et pas seulement pour serveur), celle-ci inclura en outre :

  • un serveur d'affichage : X.Org, dérivé en 2004 de XFree86 (lui-même créé en 1991) et qui devrait céder prochainement sa place au récent Wayland (ou à Mir, dans le cas d'Ubuntu),
  • un environnement logiciel comme GNOME (lancé 1997, basé sur la boite à outils graphiques GTK+), KDE (lancé en 1996, basé sur la boite à outils graphiques Qt) ou Xfce (lancé en 1996 et basé sur GTK+).

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).

Android utilise en effet son propre environnement d'exécution (Dalvik), sa propre boite à outils graphiques, son propre serveur d'affichage (SurfaceFlinger) mais surtout sa propre bibliothèque C, Bionic libc, et ses propres API qui ne suivent pas nécessairement la norme POSIX (au lieu d'exploiter celles fournies par le noyau).

Les conséquences de ces choix sont que les applications conçues pour Android ne fonctionnent pas directement sur une distribution GNU/Linux mais aussi, de manière plus embêtante – et peut-être plus étonnante – que les pilotes conçus pour Android sont inutilisables en l'état par une distribution GNU/Linux.

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) – ainsi que pour les API spécifiques d'Android.

Lorsque ces pilotes sont libres, il est possible d'adapter et de compiler leur code pour GNU/Linux. Hélàs c'est rarement le cas (ces pilotes tournent délibérément en espace utilisateur au lieu d'être inclus dans le noyau afin de ne pas être « contaminés » par la licence GNU GPL du noyau qui obligerait à les rendre libres).

À noter que Firefox OS, dont la sortie est prévue pour cet été, repose également sur un noyau Linux et la bibliothèque Bionic libc de manière à pouvoir utiliser directement les pilotes conçus pour Android et être ainsi, dès sa sortie, compatible avec un grande variété d'appareils.

Inversement, nos distributions GNU/Linux sont compatibles avec un nombre beaucoup plus restreint d'appareils mobiles car les fabricants ne se donnent pas la peine de réaliser des pilotes pour celles-ci.

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 fermés conçus pour Android (via la bibliothèque libre Libhybris conçue initialement pour le projet Mer – plus ici, ici et ).

Notons pour finir que, si Firefox OS fournit également son propre environnement d'exécution (Gecko), cela ne fait pas obstacle à l'utilisation des logiciels conçus pour Firefox OS sur nos distributions GNU/Linux ou n'importe quel autre système puisque cet environnement met en œuvre les technologies Web (HTML, CSS et JavaScript) que n'importe quel navigateur peut exécuter.

Exemples pratiques :

  • Systèmes utilisant GNU et Linux : Debian, Ubuntu (inclus Ubuntu Touch), Fedora, Mageia, openSUSE, Red Hat... mais aussi Tizen, Mer, QtMoko, Open webOS...
  • Systèmes utilisant GNU mais pas Linux : Il existe à présent des GNU/*BSD (GNU/kFreeBSD, GNU/kNetBSD), en attendant l'arlésienne GNU/Hurd (qui, en toute logique, devrait s'appeler GNU tout court).
  • Systèmes utilisant Linux mais pas GNU : Chromium OS, Android OSP (et ses dérivés : CyanogenMod, Replicant...), Firefox OS...

Lire aussi : À quand les smartphones et tablettes libres ? sur LinuxFr.org.

(billet mis à jour à partir des remarques ci-dessous de PaulK – merci à lui)

8 commentaires

#1  - Paul Kocialkowski a dit :

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).

Répondre
#2  - antistress a dit :

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).

Répondre
#3  - Paul Kocialkowski a dit :

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).

Répondre
#4  - antistress a dit :

@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 ?

Répondre
#5  - Paul Kocialkowski a dit :

> 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.

Répondre
#6  - antistress a dit :

@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

Répondre
#7  - antistress a dit :

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

Répondre
#8  - Magic Banana a dit :

Autre petite chose : GNOME fait parti du projet GNU.

Répondre

Fil RSS des commentaires de cet article

Écrire un commentaire

NB : en publiant votre commentaire, vous acceptez qu'il soit placé sous la licence CC BY-SA comme indiqué aux conditions d'utilisation du site

Quelle est la deuxième lettre du mot vgtm ?