Les appareils Android sont réputés utiliser un noyau spécifique à Android. C’est vrai dans la mesure où il est construit pour Android, mais en réalité il est très similaire au noyau Linux. Dans cette série d’articles sur le noyau d’Android je vais aborder les détails de ce processus afin de comprendre pourquoi Android a ajouté ce niveau de complexité.

Android Common Kernels (ACK)

Les noyaux d’Android, ou Android Common Kernels (ACK) sont des dérivés du noyau Linux combinant une branche stable de celui-ci (appelée Long Term Supported ou LTS) et une collection de modifications (patchs) permettant d’atteindre le niveau de support adéquat pour une version donnée d’Android.

Un noyau Android doit répondre à plusieurs contraintes:

• être stable : il doit être assez stable pour être déployés sur des appareils avec un minimum de bugs (ou de failles de sécurité),
• être maintenu : le noyau doit être maintenu suffisament longtemps pour couvrir la durée de vie de appareils,
• fonctionnalités : il doit proposer au minimum le niveau de fonctionnalités attendu par la ou les versions d’Android qu’il supporte.

Chaque version du noyau Android est nommée <android-version>-<linux-lts> où :

• android-version est la version d’Android courante au moment où ce noyau a été publié. Selon sa maturité un noyau peut être (ou pas) compatible avec l’une ou l’autre des versions d’Android. La matrice des compatibilités est documentée ici : Android Common Kernel - Compatibility matrix.
• linux-lts est la version Long Term Supported (LTS) du noyau Linux sur laquelle ce noyau Android est basé. Les différentes releases LTS du noyau Linux sont consultables sur le site du noyau lui même: Linux - Releases

Branche principale du noyau

La logique de développement du noyau Android voudrait que toute modification au noyau soit d’abord faite au noyau Linux (“upstream”), avant de redescendre dans la noyau Android par des merges réguliers. Suivant cette logique, l’ACK possède une branche android-mainline qui reçoit des merges réguliers en provenance de la branche principale du noyau Linux (master) lorsque Linus Torvalds publie une version, ou une candidate.

Ceci étant dit, il n’est pas toujours possible de se contenter du la branche master de Linux. Pour deux raisons :

• une fonctionnalité prête pour les appareils Android n’est pas nécessairement prête pour une intégration dans Linux (ces discussions peuvent parfois être longue),
• un changement peut être propre à Android et n’aura jamais vraiment sa place dans Linux.

Dans ce cas les patchs on un préfix dans la première ligne du message de commit :

• ANDROID: ... lorsque c’est une modification spécifique à Android,
• UPSTREAM: ... lorsque le patch vient de la branche master du noyau Linux mais n’a pas encore été intégrée par un merge de celui-ci,
• FROMGIT: ... lorsque le patch provient du dépôt Git de l’un des mainteneurs (https://git.kernel.org/pub/scm/linux/kernel/git/...),
• FROMLIST: ... lorsque le patch a été envoyé sur la mailing list du noyau (LKML) mais n’a pas encore été accepté.

Pour se faire une idée, on peut consulter les journaux de la branche android-mainline : https://android.googlesource.com/kernel/common/+log/refs/heads/android-mainline.

Linux, versions stables à long terme (LTS)

Le noyau Linux a adopté en 2005 un processus de release permettant de sélectionner une version dit “stable à long terme” (Long Term Supported ou LTS) chaque année. Cette version est maintenue pendant une durée de deux ans, une nouvelle livraison de ce noyau a lieu chaque semaine. Ce sont les versions 4.4.x, 4.9.x, 4.14.x, 4.19.x, 5.4.x, 5.10.x, 6.12.x and 6.18.x. Plus d’informations sur les LTS encore maintenues sont disponible sur kernel.org/releases

Une version LTS reçoit alors entre 6 et 8 correctifs par jour. Plus le temps passe, plus la version actuelle du noyau diverge de ses LTS. Par conséquent l’application des correctifs peut être de plus en plus difficile à mesure que le temps passe.

Le graphique suivant illustre grossièrement le processus:

---
config:
  theme: 'default'
  themeVariables:
    'git0': '#3465a4'
    'git1': '#ad7fa8'
    'git2': '#fcaf3e'
  gitGraph:
    mainBranchName: 'master'
    showCommitLabel: false
    parallelCommits: true
---
gitGraph
  commit
  commit
  branch 6.12
  commit tag:"v6.12"
  commit
  commit
  commit
  commit
  commit
  commit
  commit
  commit
  commit
  checkout master
  commit
  commit
  commit
  commit
  commit
  commit
  branch 6.18
  commit tag:"v6.18"
  checkout master
  commit
  commit
  commit
  commit
  checkout 6.18
  commit
  commit
  commit

La branche master du noyau intègre tous les changements au fur et à mesure de leur soumission aux divers mainteneurs. Lorsqu’un patch admis dans master, il peut être appliqué sur une ou plusieurs LTS à condition de respecter les règles de stabilité du noyau :

• avoir été intégré dans master (Linux mainline, aussi appelé upstream),
• être (évidemment) correct et testé,
• ne pas dépasser 100 lignes
• suivre les règles de soumission : Documentation/process/submitting-patches.rst
• doit être un correction pour un bug qui a un impact sur les utilisateur, ou juste un identifiant de périphérique.

Ces règles permettent de garantir la stabilité et simplifient le travail de maintenance. Les branches LTS (6.12 et 6.18 sur le graphique) vont alors régulièrement recevoir des corrections de ce type jusqu’à la fin de leur période de support. Ce noyau deviendra alors obsolète et devra être mis à jour.

D’une LTS à un noyau Android stable

Lorsqu’une nouvelle version LTS est annoncée par le noyau Linux, une branche correspondante est créée dans le noyau Android, à partir de la branche android-mainline, suivant la dénomination mentionée précédement: androidXX-Y.ZZ. Elle recevra, par des merges réguliers, les améliorations fournie par la version LTS de Linux.

On peut repérer ces mises à jour en regardant les commits de merge qui ressemblent à celui-ci:

commit 50e8de680435dfb61c1efbe10901c2cf9d97433a
author Greg Kroah-Hartman <gregkh@google.com>
Sat Aug 15 11:23:19 2026 +0000
committer android-test-infra-autosubmit@system.gserviceaccount.com <android-test-infra-autosubmit@system.gserviceaccount.com>
Thu Aug 27 03:03:30 2026 -0700

Merge tag 'android16-6.12.92_r00' into android16-6.12

This merges the android16-6.12.92_r00 tag into the android16-6.12 branch,
catching it up with the latest LTS releases.

It contains the following commits:

*   8a6dad0f5ad3 Merge ff43460784b7 ("arm64: debug: split single stepping exception entry") into android16-6.12-lts
|\
| * ff43460784b7 arm64: debug: split single stepping exception entry
* | 781db77fd619 Merge 956e2dd2b072 ("arm64: debug: refactor reinstall_suspended_bps()") into android16-6.12-lts
...

Sur une branche stable, on trouvera également des commits ayant le préfix BACKPORT: ..., il indique que le patch a déjà été accepté (ou sur la liste de mail) en amont mais n’a pas pu être appliqué de manière transparente, lorsqu’il y a un conflit au moment du cherry-pick par exemple.

Quelques statistiques

Histoire de rendre tout ça concret, faisons un peu de statistiques sur la branche android16-6.12. On peut cloner le dépôt du noyau comme suit :

git clone https://android.googlesource.com/kernel/common

Ce qui nous place sur la branche android-mainline par défaut. En parcourant l’historique de la branche j’ai estimé son point de création autour du patch suivant:

$ git show c0d49d669443
commit c0d49d669443da6576d51597df8d71e19d9826f0
Merge: bbb3f0a52148 a53bb4b36b92
Author: Aleksei Vetrov <vvvvvv@google.com>
Date:   Wed Nov 20 15:02:21 2024 +0000

    Merge branch 'aosp/android-mainline' into 'android16-6.12'

    This catches up android16-6.12 with android-mainline to 6.12-rc7.

    Bug: 367265496
    Change-Id: I072760fe7a0f14fcfb67d4e4992939db4b810b63
    Signed-off-by: Matthias Maennich <maennich@google.com>
    Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>

diff --cc build.config.common
index 4dc465d75aa4,683e57364d25..0743c04d507f
--- a/build.config.common
+++ b/build.config.common
@@@ -1,16 -1,5 +1,7 @@@
  . ${ROOT_DIR}/${KERNEL_DIR}/build.config.constants

 -BRANCH=android-mainline
 +KMI_GENERATION=0
 +
 +BRANCH=android16-6.12

Ensuite on extrait le nombre de patchs appliqués depuis lors :

$ git log --graph --oneline c0d49d669443..origin/android16-6.12 | wc -l
23954

En filtrant les patchs avec le TAG: préfixant le titre du commit, on peut se faire une idée des divergences d’une branche:

Conclusion

Les noyaux Android répondent à des contraintes plus serrées que celles du noyau Linux, notammement en terme de délais et de mise en production. La manière dont ces branches sont gérées reflètent ces besoins, ainsi que la nécessité de stabilisation. Par on peut constater que les branches sont majoritairement composées de patch en provenance du noyau Linux, ou sur le point d’être soumis. Les noyaux Android ne sont donc pas si divergents.

Dans un prochain article nous regarderons comment les noyaux Android conservent une ABI stable pour une version donnée, afin de permettre des mises à jour régulières du noyau sans affecter le reste du système.