Noyaux communs Android

Les noyaux communs AOSP (également connus sous le nom de noyaux communs Android ou ACK ) sont en aval des noyaux kernel.org et incluent des correctifs intéressant la communauté Android qui n'ont pas été fusionnés dans les noyaux principaux ou pris en charge à long terme (LTS). Ces correctifs peuvent inclure :

  • Rétroportages et sélections de fonctionnalités en amont nécessaires aux fonctionnalités Android
  • Fonctionnalités prêtes pour les appareils Android mais encore en cours de développement en amont (par exemple, optimisations du placement des tâches d'Energy Aware Scheduler).
  • Fonctionnalités fournisseur/OEM utiles pour d’autres partenaires de l’écosystème (par exemple, sdcardfs).

android-mainline est la principale branche de développement des fonctionnalités Android. La ligne principale Linux est fusionnée avec android-mainline chaque fois que Linus Torvalds publie une version ou une version candidate. Avant 2019, les noyaux communs Android étaient construits en clonant le noyau LTS récemment déclaré et en ajoutant les correctifs spécifiques à Android. Ce processus a changé en 2019 pour créer une branche entre le nouveau noyau commun Android et android-mainline . Ce nouveau modèle évite les efforts importants nécessaires pour transférer le port et tester les correctifs Android en obtenant le même résultat de manière incrémentielle. android-mainline subit des tests continus importants, ce modèle garantit un noyau de haute qualité dès le jour de sa publication.

Lorsqu'un nouveau LTS est déclaré en amont, le noyau commun correspondant est dérivé de android-mainline . Cela permet aux partenaires de démarrer un projet avant la déclaration de la version LTS, en fusionnant depuis android-mainline . Une fois la nouvelle branche du noyau commun créée, les partenaires peuvent facilement modifier la source de fusion vers la nouvelle branche.

D'autres branches de noyau courantes reçoivent des fusions régulières de leur noyau LTS associé. Ces fusions sont normalement effectuées immédiatement après la publication de la version LTS. Par exemple, lorsque Linux 4.19.64 a été publié, il a été fusionné avec les noyaux communs 4.19 (par exemple, android-4.19-q ). Les partenaires sont fortement encouragés à fusionner régulièrement les noyaux communs dans leurs noyaux de produits pour rester à jour avec les corrections de bogues spécifiques à LTS et Android.

Branche du noyau ACK KMI

Les noyaux GKI ont une interface de module de noyau stable. Le KMI est identifié de manière unique par la version du noyau et la version de la plate-forme Android, les branches sont donc nommées <androidRelease>-<kernel version> . Par exemple, le noyau GKI 5.4 pour Android 11 s'appelle android11-5.4. Pour Android 12, il existe deux noyaux GKI supplémentaires, android12-5.4 et android12-5.10 .

Branches de noyaux de dessert hérités

Les anciens noyaux de dessert ont été créés pour garantir que le développement de nouvelles fonctionnalités n'interférerait pas avec la fusion à partir du noyau commun Android. Les branches ont été créées avant la version dessert associée et reçoivent des fusions régulières de LTS, mais aucune nouvelle fonctionnalité. Par exemple, android-4.9-q reçoit les fusions de la branche LTS 4.9.y.

Si une version du noyau n'était pas un noyau de lancement, aucun noyau dessert n'a été créé, mais le noyau associé à la version de plate-forme la plus récente est valide pour la mise à niveau vers les futures versions de la plate-forme Android. Par exemple, android-4.9-q était la dernière des branches dessert android-4.9* , elle est donc prise en charge et testée avec sa version de plate-forme d'origine, Android 10. Elle est également prise en charge et testée avec les versions de plate-forme qui prennent en charge les mises à niveau des appareils exécutant 4.9. noyaux : Android 11 et Android 12.

Étant donné que le schéma de dénomination des desserts pour les versions de la plate-forme Android a été abandonné avec Android 10, les dernières versions de desserts qui auraient été appelées android-4.14-r et android-4.19-r ont été appelées à la place android-4.14-stable et android-4.19-stable .

Les noyaux de dessert sont remplacés par les noyaux GKI à partir d'Android 11, la liste complète des noyaux de dessert pris en charge se trouve donc dans ce tableau.

Version de la plateforme Android Noyau Pris en charge jusqu'à
Android 10 android-4.9-q
android-4.14-q
android-4.19-q
janvier 2023
Android 11 android-4.14-stable
android-4.19-stable
janvier 2024
décembre 2024

Branches du noyau de la version héritée

Les noyaux de version sont maintenus pour fournir des rétroportages des correctifs cités dans le bulletin de sécurité mensuel Android . Ils ont été créés pour chaque noyau de lancement lors d'une nouvelle version de la plate-forme Android. Ils sont obsolètes lorsque la version du noyau ou de la plate-forme associée est obsolète, comme décrit dans Durées de vie du support et correctifs de sécurité .

Chaque mois, lors de la publication du Bulletin de sécurité Android, ces noyaux sont mis à jour avec des rétroportages des correctifs cités dans le bulletin qui concernent les noyaux en amont et les noyaux communs Android. Ils ne reçoivent pas de correctifs LTS, donc le numéro de version mineure ne change jamais. Ils ne contiennent pas de rétroportages pour les correctifs spécifiques au fournisseur.

Dans Android 11 et les versions ultérieures de la plate-forme, les partenaires doivent fusionner à partir des noyaux dessert ou GKI pour appliquer les correctifs cités dans le bulletin de sécurité Android. Aucun noyau de version ne sera créé pour Android 11 ou les versions ultérieures de la plate-forme.

Par conséquent, la liste complète des 14 noyaux de version est présentée dans ce tableau et aucun ne sera ajouté.

Version de la plateforme Android Noyau Pris en charge jusqu'à
Android 10 android-4.9-q-release
android-4.14-q-release
android-4.19-q-release
janvier 2023

Fonctionnalités et lancement des noyaux

Chaque version de la plate-forme Android prend en charge le lancement de nouveaux appareils basés sur l'une des trois versions du noyau Linux. Comme le montre le tableau ci-dessous, les noyaux de lancement pour Android 11 sont android-4.14-stable , android-4.19-stable et android11-5.4 .

Étant donné que les mises à niveau du noyau ne sont généralement pas requises lors de la mise à jour de la version de la plate-forme, les noyaux qui ne disposent pas des dernières fonctionnalités d'une version de la plate-forme peuvent toujours être utilisés pour lancer des périphériques. Par conséquent, les noyaux conçus pour Android 10, comme android-4.19-q , peuvent être utilisés sur les appareils même après la mise à niveau de la version de la plate-forme vers Android 11. À partir d'Android 12, il y aura moins de noyaux de fonctionnalités que de noyaux de lancement afin de limiter le nombre de noyaux de fonctionnalités. des KMI stables qui doivent être pris en charge.

Version de la plateforme Android Lancer les noyaux Noyaux de fonctionnalités
Android 14 (2023) android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10 1
android14-6.1
android14-5.15
Android 13 (2022) android13-5.15
android13-5.10
android12-5.10 1
android12-5.4 1
android11-5.4 1
android13-5.15
android13-5.10
Android 12 (2021) android12-5.10
android12-5.4
android11-5.4 1
android-4.19-stable
android12-5.10
android12-5.4
Android 11 (2020) android11-5.4
android-4.19-stable
android-4.14-stable
android11-5.4
android-4.19-stable
android-4.14-stable
Android 10 (2019) android-4.19-q
android-4.14-q
android-4.9-q

android-4.19-q
android-4.14-q
android-4.9-q

1 Des restrictions supplémentaires peuvent s'appliquer si le BSP associé a été mis à jour pour la version de la plateforme. De manière plus générale, le numéro de version Android du noyau doit être supérieur ou égal à la version FCM cible . Voir Objet d'interface fournisseur - faire correspondre les branches du noyau pour plus de détails.

Hiérarchie commune du noyau

Branche depuis la ligne principale Android

Le niveau supérieur de la hiérarchie commune du noyau est illustré à la figure 1.

Création de noyaux communs à partir du noyau principal Android

Figure 1. Création de noyaux communs à partir du noyau principal Android

Notez que le nouveau noyau commun Android android12-5.10 a été dérivé d' android-mainline en 2020. En 2021, lorsque le prochain LTS a été déclaré, android13-5.15 a été dérivé d' android-mainline .

Comme le montre la figure 1, chaque version du noyau constitue la base de deux noyaux GKI. Par exemple, les deux noyaux v5.4 sont android11-5.4 et android12-5.4 , qui sont tous deux des noyaux de fonctionnalités pour leurs versions de plate-forme respectives. Ce sera également le cas pour la version 5.10 ; android12-5.10 a été créé lorsque le LTS a été déclaré et android13-5.10 dérivera d' android12-5.10 au jalon complet des fonctionnalités du noyau au printemps 2021 pour permettre le développement de fonctionnalités pour Android 13.

Cycle de vie de la branche ACK KMI

Le cycle de vie d'une branche ACK KMI est illustré ci-dessous dans la figure 2.

5.10 Cycle de vie de la branche ACK KMI

Figure 2. 5.10 Cycle de vie de la branche ACK KMI

Pour clarifier le processus de développement et le cycle de vie des branches, la figure 2 se concentre sur les branches ACK KMI pour 5.10.

Chaque branche ACK KMI passe par trois phases indiquées sur la figure 2 par des couleurs différentes dans chaque branche. Comme indiqué, LTS est régulièrement fusionné quelle que soit la phase.

Phase de développement

Une fois créée, une branche ACK KMI entre dans la phase de développement ( dev dans la figure 2) et est ouverte aux contributions de fonctionnalités pour la prochaine version de la plate-forme Android. Dans la figure 2, android12-5.10 a été créé lorsque la version 5.10 a été déclarée comme nouveau noyau LTS en amont. La deuxième branche ACK KMI pour une version du noyau peut être créée plus tôt pour permettre le développement de la version suivante. Dans la figure 2, android13-5.10 est créé lorsque android12-5.10 sort de la phase de développement.

Phase de stabilisation

Lorsque la branche ACK KMI est déclarée fonctionnalité complète, elle entre dans la phase de stabilisation , appelée stab dans la figure 2. Les fonctionnalités partenaires et les corrections de bugs sont toujours acceptées, mais le suivi KMI est activé pour détecter toute modification affectant l'interface. Au cours de cette phase, les modifications rompant le KMI sont acceptées, mais la définition du KMI doit être mise à jour si nécessaire. Consultez la présentation de GKI pour plus de détails sur la surveillance KMI.

Phase gelée KMI

Avant qu'une nouvelle version de plate-forme ne soit transmise à AOSP, la branche ACK KMI est gelée et reste gelée pendant toute la durée de vie de la branche. Cela signifie qu'aucune modification violant le KMI n'est acceptée, à moins qu'un problème de sécurité grave ne soit identifié et ne peut être atténué sans affecter le KMI stable. Pour éviter les pannes de KMI, certains correctifs fusionnés à partir de LTS peuvent être modifiés ou supprimés si le correctif n'est pas requis pour les appareils Android.

Lorsqu'une branche ACK KMI est gelée, les corrections de bugs et les fonctionnalités partenaires peuvent être acceptées tant que le noyau commun KMI existant n'est pas cassé. Le KMI peut être étendu avec de nouveaux symboles exportés tant que les interfaces comprenant le KMI actuel ne sont pas affectées. Lorsque de nouvelles interfaces sont ajoutées au KMI, elles deviennent immédiatement stables et ne peuvent pas être interrompues par des modifications futures.

Par exemple, une modification qui ajoute un champ à une structure utilisée par un noyau commun d'interface KMI n'est pas autorisée car elle modifie la définition de l'interface :

struct foo {
  int original_field1;
  int original_field2;
  int new_field;  // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

Cependant, ajouter une nouvelle fonction est une bonne chose :

struct foo2 {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo2 &myarg)
{
  do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

Pendant toute la durée de vie du noyau GKI, la compatibilité ascendante avec l'espace utilisateur est maintenue afin que le noyau puisse être utilisé en toute sécurité pour la version de la plate-forme Android avec laquelle l'appareil a été lancé. Des tests continus avec les versions précédentes garantissent le maintien de la compatibilité. Ainsi, dans la figure 2, le noyau android12-5.10 peut être utilisé pour les appareils Android 12 et Android 13. Étant donné que la version de la plate-forme Android est également compatible avec les versions précédentes, le noyau android12-5.4 peut être utilisé pour les appareils Android 13 soit pour le lancement, soit pour la mise à niveau.

Lors de l'entrée dans la phase gelée, la branche est git-tagged avec la chaîne de version KMI contenant le numéro de génération KMI. Par exemple, lorsque android11-5.4 a été gelé, il a été étiqueté avec la chaîne de version KMI 5.4-android11-0 , où le 0 final est le numéro de génération KMI. S'il existe un problème de sécurité ou un autre événement nécessitant l'acceptation d'un correctif modifiant le KMI, le numéro de génération du KMI est incrémenté et la branche est réétiquetée. Par exemple, si un tel changement est accepté dans android11-5.4 , la branche sera étiquetée avec la nouvelle version de KMI, 5.4-android11-1 . La génération KMI actuelle peut être trouvée à l'aide de la commande uname :

$ uname -r
5.4.61-android11-0-00153-ga972f59040e4

Le numéro après la version de la plateforme est la génération KMI (0 dans ce cas).

Si la génération KMI change, le noyau n'est pas compatible avec les modules du fournisseur conformes à la génération KMI précédente, les modules doivent donc être reconstruits et mis à jour de manière synchrone avec le noyau. Les changements de génération KMI devraient être très rares.

Compatibilité entre les noyaux

Les exigences de compatibilité entre les noyaux d'une même famille LTS évoluent à partir des nouveaux noyaux GKI.

Noyaux GKI

Les noyaux GKI maintiennent une compatibilité descendante avec toutes les versions de la plate-forme Android prenant en charge la version du noyau. De plus, les versions de la plate-forme Android sont rétrocompatibles avec les noyaux GKI des versions précédentes. Vous pouvez donc utiliser en toute sécurité le noyau android12-5.4 développé pour Android 12 sur les appareils exécutant Android 13. La compatibilité est vérifiée grâce à des tests VTS et CTS continus des noyaux GKI avec toutes les versions prises en charge.

Le KMI est stable afin que le noyau puisse être mis à jour sans nécessiter une reconstruction des modules du noyau dans l'image du fournisseur.

La compatibilité KMI n'est pas maintenue entre les différents noyaux GKI. Ainsi, par exemple, un android12-5.10 ne peut pas être remplacé par un noyau android13-5.10 sans reconstruire tous les modules.

Les noyaux GKI sont pris en charge uniquement pour leurs versions initiales et ultérieures. Ils ne sont pas pris en charge pour les anciennes versions. Ainsi, un noyau android13-5.10 n'est pas pris en charge sur les appareils Android 12.

Noyaux hérités

Les noyaux dessert hérités ( *-q et *-stable ) ne sont pas rétrocompatibles entre les versions de la plate-forme Android, mais les noyaux des deux versions précédentes de la plate-forme Android sont pris en charge pour la mise à niveau. Par conséquent, un appareil lancé avec Android 10 utilisant un noyau basé sur android-4.19-q peut soit continuer à utiliser le noyau android-4.19-q lors de la mise à niveau vers Android 2020, soit mettre à jour le code spécifique au fournisseur pour prendre en charge android-4.19-stable .

Matrice de compatibilité

Ce tableau montre les versions du noyau prises en charge et testées avec chaque version de la plateforme Android.

Version de la plateforme Android Noyaux pris en charge pour la mise à niveau Noyaux pris en charge pour le lancement
Android 14 (2023) android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.14-stable
android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
Android 13 (2022) android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.9-q (EOL)
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
Android 12 (2021) android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.14-p (EOL)
android-4.9-q (EOL)
android-4.9-p (EOL)
android-4.9-o (EOL)
android-4.19-stable
android11-5.4
android12-5.4
android12-5.10
Android 11 (2020) android11-5.4
android-4.19-stable
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.14-p (EOL)
android-4.9-q (EOL)
android-4.9-p (EOL)
android-4.9-o (EOL)
android-4.4-p (EOL)
android-4.4-o (EOL)
android11-5.4
android-4.19-stable
android-4.14-stable
Android 10 (2019) android-4.14-stable
android-4.14-p (EOL)
android-4.9-p (EOL)
android-4.9-o (EOL)
android-4.4-p (EOL)
android-4.4-o (EOL)
android-3.18 (EOL)
android-4.14-stable
android-4.19-q (EOL)
android-4.14-q (EOL)
android-4.9-q (EOL)

Durées de vie du support et correctifs de sécurité

Les noyaux courants Android sont pris en charge jusqu'à ce que le noyau LTS associé ou la version de la plate-forme Android ne soit plus pris en charge. Même si un noyau est pris en charge, il continue de recevoir des fusions LTS en amont et des corrections de bugs pour le code spécifique à Android. Ces correctifs incluent tous les correctifs de sécurité du noyau cités dans les bulletins de sécurité Android mensuels qui concernent les noyaux courants d'Android.

Les partenaires peuvent être sûrs qu'en fusionnant régulièrement les noyaux communs d'Android, ils obtiennent tous les correctifs de sécurité du noyau possibles.

Tests de noyau courants

Les noyaux communs sont testés avec plusieurs systèmes CI en plus des tests en aval effectués par les fournisseurs.

Test fonctionnel du noyau Linux

Les tests Linux Kernel Functional Test (LKFT) lancent diverses suites de tests, notamment kselftest, LTP, VTS et CTS sur un ensemble d'appareils physiques arm32 et arm64. Les résultats des tests récents peuvent être trouvés ici .

Tests KernelCI

Les tests de construction et de démarrage de KernelCI sont lancés chaque fois qu'un nouveau correctif est validé dans une branche commune du noyau. Plusieurs centaines de configurations de build sont testées et démarrées sur diverses cartes. Les résultats récents pour les noyaux Android peuvent être trouvés ici .

Tests Android avant et après la soumission

Les tests de pré-soumission sont utilisés pour empêcher l'introduction de pannes dans les noyaux communs d'Android. Le résumé des résultats du test peut être trouvé dans l'onglet « Vérifications » du changement de code dans Gerrit du noyau commun Android.

Les tests post-soumission Android sont effectués sur les nouvelles versions publiées dans les branches du noyau commun Android lorsque de nouveaux correctifs sont validés dans une branche du noyau commun Android sur ci.android.com . En saisissant aosp_kernel comme nom de branche partielle dans ci.android.com , vous voyez une liste de branches du noyau avec des résultats disponibles. Par exemple, les résultats pour android-mainline peuvent être trouvés ici . Lorsque vous cliquez sur une version particulière, vous trouverez l'état du test dans l'onglet Test Results .

Les tests définis par test-mapping avec le groupe de tests kernel-presubmit dans l'arborescence des sources de la plate-forme Android seront exécutés en tant que pré-soumission pour les branches du noyau Android. Par exemple, la configuration suivante dans test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING activera vts_kernel_proc_file_api_test comme test préalable lors de l'enregistrement du code du noyau commun Android.

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

Test 0 jour

Les tests 0-day effectuent des tests patch par patch sur toutes les branches communes du noyau Android lorsque de nouveaux correctifs sont validés. Divers tests de démarrage, fonctionnels et de performances sont exécutés. Rejoignez le groupe public cros-kernel-buildreports

Matrice de tests

Noyau commun Android Versions de la plateforme Android Suites de tests
Principal 14 13 12 11 dix LKFT NoyauCI Pré-soumission Publier Soumettre 0 jour
android-mainline
android14-6.1
android14-5.15
android13-5.15
android13-5.10
android12-5.10
android12-5.4
android11-5.4
android-4.19-stable
android-4.19-stable
android-4.14-stable

Contribuer aux noyaux communs Android

En règle générale, le développement de fonctionnalités doit être effectué sur Linux principal et non sur les noyaux courants d'Android. Le développement en amont est fortement encouragé, et une fois le développement accepté, il peut être facilement rétroporté vers la branche ACK spécifique si nécessaire. L' équipe Android Kernel est heureuse de soutenir les efforts de mise en amont au profit de l'écosystème Android.

Soumettez les correctifs à Gerrit et conformez-vous à ces directives de contribution .