Note d’exploration — Air sur Android (Vendor Interface, racine de confiance, GPU)
Statut : exploration. Pas une décision, pas un ADR, pas de spec. Horizon 2ᵉ temps (après les couches fondatrices). Capture un raisonnement pour le futur ; aucune ressource engagée. Datée 2026-06-13.
But
Faire d’Air un socle portable pour téléphones/tablettes, posé sur le kernel Android fourni par le vendor, en amenant l’infrastructure minimale (systemd ou équivalent + services Air). Objectif central : le vendor (ex. Fairphone) n’a peu à faire — Air fournit le contrat d’intégration, le vendor branche son matériel. Résultat visé : un OS portable hors-Google (pas de GMS/Play), avec sa couche graphique.
Modèle : un « Air Vendor Interface » (analogue de Project Treble)
Ce qui a rendu Android portable entre fabricants : le split system/vendor +
des HAL à interface stable (HIDL→AIDL) + le VINTF. Air fait son équivalent,
natif et hors-Google : une surface d’intégration minimale, stable,
versionnée (sur la C-ABI / air-runtime + des traits HAL couche 1) que le
vendor implémente — et rien de plus. Même philosophie de joint que partout
ailleurs (DNS maison, air-device, air-keystore).
Frontière 80/20 — ce qui rend le travail vendor petit
Le 80 % « gratuit » : Air parle directement aux interfaces kernel standard
(couche 0 = syscalls natifs ; air-device = sysfs/uevent). Sur un kernel Android,
beaucoup est déjà standard côté kernel et le vendor a déjà les drivers :
DRM/KMS (affichage), evdev (entrée), ALSA/PipeWire (audio), USB,
sous-système TEE / Trusty (sécurité). Air consomme l’ABI kernel sans passer
par le userspace Android.
Le 20 % dur (là où l’effort vendor se concentre ; Air fournit des contrats propres, pas l’implémentation) :
- Modem / RIL (téléphonie) — très propriétaire ; le plus gros morceau.
- Caméra — HAL Android énorme/blob-lourd ;
libcamera= voie ouverte mais tuning vendor conséquent. - GPU userspace — driver GL/Vulkan : soit blob Adreno/Mali, soit Mesa (Panfrost Mali, Freedreno/Turnip Adreno). Le point sensible de l’indépendance graphique.
- Capteurs / empreinte, énergie/suspend (wakelocks Android vs runtime PM
Linux), secure key/attestation → backends
air-keystore.
Racine de confiance / TEE (cf. la discussion détaillée)
Sur Android, pas un « enclave » mais deux étages : TEE (TrustZone on-SoC ; Trusted OS QSEE/Qualcomm, Kinibi/Trustonic, ou Trusty/Google) et StrongBox (puce SE discrète, ex. Titan M). On y accède via un driver kernel (SMC vers TrustZone, ou SPI/I²C vers le SE) mais le protocole/le TA sont contrôlés par le vendor. Pas de chemin universel « kernel seul, sans vendor » vers les TEE propriétaires :
- GP TEE Client API (
libteec,/dev/tee0) ou Trusty (/dev/trusty-ipc) = utilisables depuis du userspace Linux sans SDK vendor — mais minorité des appareils commerciaux (OP-TEE / Trusty). - QSEE/Kinibi = blobs userspace propriétaires → dépendance vendor de fait.
- Plafond dur : on ne déploie pas son propre TA/applet sans les clés de secure-boot du vendor.
⇒ Dessin Air : air-keystore (fournisseur clés/attestation) à backends
enfichables (GP-TEE, Trusty, shim blobs vendor).
Point fort de la piste vendor (vs portage utilisateur). Un end-user qui déverrouille le bootloader perd l’attestation. Mais un vendor qui signe (Fairphone) peut livrer Air avec ses propres clés AVB et re-verrouiller → verified-boot intact, racine de confiance possédée par le vendor. Le problème d’attestation ne se pose donc pas pour un partenaire vendor.
Ne pas réinventer — appuis existants
- Halium / libhybris : userspace GNU/Linux sur kernel + HAL Android du vendor (pont glibc↔blobs bionic). Voie de transition « réutiliser les blobs au minimum » ; c’est ainsi que tournent Ubuntu Touch (UBports), droidian, Mobian. Air pourrait offrir un backend Halium.
- postmarketOS : philosophie inverse (kernel mainline, zéro blob) — cible idéale long terme, plus de portage kernel.
- Mesa (Panfrost/Freedreno/Turnip) : GPU libre, indispensable au hors-Google.
- Treble / VINTF : modèle de l’interface vendor.
Partenaire : Fairphone
Contacts existants ; support long, bootloader déverrouillable, esprit libre. Nuance : leurs /e/OS (Murena) et LineageOS restent de l’AOSP dégooglisé (de l’Android) — passer à Air (userspace Linux non-Android) est un saut bien plus grand que /e/OS. Mais comme vendor signataire, Fairphone garde une chaîne de confiance intacte (cf. ci-dessus) → premier partenaire idéal.
Esquisse de plan (2ᵉ temps)
- Définir l’Air Vendor Interface (stable, versionnée, C-ABI) + les traits HAL couche 1.
- Backends de référence pour les interfaces kernel standard (le 80 %).
air-keystore+ HAL Air à backends enfichables pour le 20 % dur ; option pont Halium pour réutiliser les blobs existants en transition.- Couche graphique hors-Google via Mesa (
air-wm/Wayland — couche 3 Air). - Modèle de sécurité vendor-signé (re-lock AVB clés vendor).
Liens
[[air-strategie-systemd-remplacement]] · [[air-pilier-integrite-binaires]] · [[air-piste-libc-compat]] · ADR-005 (systemd) · ADR-006 (profils base/desktop) · ADR-003 (compositeur Wayland) · ADR-010 (entitlements signés).
Licence du document : MPL 2.0 Statut : note d’exploration, non engageante. Toute suite passerait par un ADR.