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 LTS (Long Term Supported). Ces correctifs peuvent inclure :
- Rétroportages et sélections de fonctionnalités en amont nécessaires pour les fonctionnalités Android
- Fonctionnalités prêtes pour les appareils Android mais toujours en cours de développement en amont (par exemple, optimisations du placement des tâches 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 du nouveau noyau commun Android à partir d android-mainline . Ce nouveau modèle évite l'effort important de transfert de port et de test des correctifs Android en obtenant le même résultat de manière incrémentielle. android-mainline est soumis à d'importants tests continus, ce modèle garantit un noyau de haute qualité dès 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 commencer un projet avant la déclaration de la version LTS, en fusionnant depuis android-mainline . Une fois la nouvelle branche commune du noyau créée, les partenaires peuvent modifier de manière transparente la source de fusion vers la nouvelle branche.
D'autres branches courantes du noyau 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 correctifs 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, de sorte que les branches sont nommées <androidRelease>-<kernel version> . Par exemple, le noyau 5.4 GKI pour Android 11 est nommé android11-5.4. Pour Android 12, il existe deux noyaux GKI supplémentaires, android12-5.4 et android12-5.10 .
Branches de noyau de dessert héritées
Les noyaux de dessert hérités ont été créés pour garantir que le développement de nouvelles fonctionnalités n'interfère pas avec la fusion à partir du noyau commun Android. Les branches ont été créées avant la version de 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 des 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 de dessert android-4.9* , il est donc pris en charge et testé avec sa version de plate-forme d'origine, Android 10. Il est également pris en charge et testé 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 dessert 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, donc la liste complète des noyaux de dessert pris en charge se trouve dans ce tableau.
| Lancement de la plate-forme Android | Noyau | Pris en charge jusqu'à |
|---|---|---|
| Android 10 | android-4.9-qandroid-4.14-qandroid-4.19-q | janvier 2023 |
| Android 11 | android-4.14-stableandroid-4.19-stable | janvier 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 mensuel de sécurité Android . Ils ont été créés pour chaque noyau de lancement lorsqu'il y avait 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, lorsque le bulletin de sécurité Android est publié, ces noyaux sont mis à jour avec les rétroportages des correctifs cités dans le bulletin qui sont pertinents pour les noyaux en amont et les noyaux communs Android. Ils ne reçoivent pas les 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 les versions de plate-forme Android 11 et ultérieures, 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 les versions de plateforme Android 11 ou ultérieures.
Par conséquent, la liste complète des 14 noyaux de version est présentée dans ce tableau, et aucun ne sera ajouté.
| Lancement de la plate-forme Android | Noyau | Pris en charge jusqu'à |
|---|---|---|
| Android 10 | android-4.9-q-releaseandroid-4.14-q-releaseandroid-4.19-q-release | janvier 2023 |
Fonctionnalité 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 indiqué dans 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 auxquels il manque les dernières fonctionnalités pour une version de la plate-forme peuvent toujours être utilisés pour lancer des appareils. Par conséquent, les noyaux conçus pour Android 10, comme android-4.19-q , peuvent être utilisés sur des 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 pour limiter le nombre de KMI stables qui doivent être pris en charge.
| Lancement de la plate-forme Android | Lancer les noyaux | Noyaux de fonctionnalités |
|---|---|---|
| Android 10 (2019) | android-4.9-qandroid-4.14-qandroid-4.19-q | android-4.9-qandroid-4.14-qandroid-4.19-q |
| Android 11 (2020) | android-4.14-stableandroid-4.19-stableandroid11-5.4 | android-4.14-stableandroid-4.19-stableandroid11-5.4 |
| Android 12 (2021) | android-4.19-stableandroid11-5.4 1android12-5.4android12-5.10 | android12-5.4android12-5.10 |
| Android 13 (2022) | android12-5.4 1android12-5.10 1android13-5.10android13-5.15 | android13-5.10android13-5.15 |
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 Vendor Interface Object - match kernel branches pour plus de détails. | ||
Hiérarchie commune du noyau
Branchement depuis android-mainline
Le niveau supérieur de la hiérarchie commune du noyau est illustré à la figure 1.
Figure 1. Création de noyaux communs à partir du noyau android-mainline
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 de 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 5.10 ; android12-5.10 a été créé lorsque le LTS a été déclaré et android13-5.10 se ramifiera à partir d' android12-5.10 à l'étape complète de la fonctionnalité 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.
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
Lorsqu'elle est 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 5.10 a été déclaré 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é terminée, elle entre dans la phase de stabilisation , appelée stab dans la figure 2. Les fonctionnalités partenaires et les corrections de bogues sont toujours acceptées, mais le suivi KMI est activé pour détecter toute modification affectant l'interface. Dans cette phase, les modifications avec rupture de KMI sont acceptées, mais la définition de KMI doit être mise à jour si nécessaire. Consultez la présentation de GKI pour plus de détails sur la surveillance KMI.
Phase congelé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 de rupture de KMI n'est acceptée à moins qu'un problème de sécurité grave ne soit identifié et ne puisse être atténué sans affecter la KMI stable. Pour éviter les ruptures 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 bogues 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 composant le KMI actuel ne sont pas affectées. Lorsque de nouvelles interfaces sont ajoutées à la KMI, elles deviennent immédiatement stables et ne peuvent pas être interrompues par de futures modifications.
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 très bien :
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 rétrocompatibilité 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 que la compatibilité est maintenue. 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, que ce soit pour le lancement ou 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é marqué 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 y a un problème de sécurité ou un autre événement qui nécessite l'acceptation d'un correctif de modification de KMI, le numéro de génération de 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 actuelle de KMI peut être trouvée à l'aide de la commande uname :
$ uname -r
5.4.61-android11-0-00153-ga972f59040e4
Le nombre après la version de la plate-forme est la génération KMI (0 dans ce cas).
Si la génération de KMI change, le noyau n'est pas compatible avec les modules du fournisseur conformes à la génération précédente de KMI, de sorte que les modules doivent être reconstruits et mis à jour de manière synchrone avec le noyau. Les changements de génération de KMI devraient être très rares.
Compatibilité entre les noyaux
Les exigences de compatibilité entre les noyaux de la même famille LTS changent à partir des nouveaux noyaux GKI.
Noyaux GKI
Les noyaux GKI conservent 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 des appareils exécutant Android 13. La compatibilité est vérifiée par 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 versions plus anciennes. Ainsi, un noyau android13-5.10 n'est pas pris en charge sur les appareils Android 12.
Noyaux hérités
Les noyaux de 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 indique les versions de noyau prises en charge et testées avec chaque version de la plate-forme Android.
| Lancement de la plate-forme Android | Noyaux pris en charge pour la mise à niveau | Noyaux pris en charge pour le lancement |
|---|---|---|
| Android 10 (2019) | android-3.18 (EOL)android-4.4-o (EOL)android-4.9-o (EOL)android-4.9-p (EOL)android-4.14-p (EOL) | android-4.9-q |
| Android 11 (2020) | android-4.4-o (EOL)android-4.4-p (EOL)android-4.9-o (EOL)android-4.9-p (EOL)Android-4.9-q android-4.14-p (EOL)android-4.14-q | android-4.14-stable |
| Android 12 (2021) | android-4.9-o (EOL)android-4.9-p (EOL)android-4.9-q (EOL)android-4.14-q | android-4.19-stable |
| Android 13 (2022) | android-4.9-q | android11-5.4 |
Prise en charge des durées de vie et des correctifs de sécurité
Les noyaux communs 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. Tant qu'un noyau est pris en charge, il continue de recevoir des fusions LTS en amont et des corrections de bogues 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 communs Android.
Les partenaires peuvent être sûrs qu'en fusionnant régulièrement à partir des noyaux communs d'Android, ils obtiennent tous les correctifs de sécurité du noyau possibles.
Tests communs du noyau
Les noyaux communs sont testés avec plusieurs systèmes CI en plus des tests en aval par les fournisseurs.
Tests fonctionnels du noyau Linaro
Les tests Linaro Kernel Functional Testing (LKFT) lancent diverses suites de tests, notamment kselftest, LTP, VTS et CTS sur un ensemble de dispositifs physiques arm32 et arm64. Les résultats des tests récents peuvent être trouvés ici .
Test KernelCI
Les tests de construction et de démarrage KernelCI sont lancés chaque fois qu'un nouveau correctif est validé dans une branche commune du noyau. Plusieurs centaines de configurations de construction sont testées et démarrées sur différentes cartes. Les résultats récents pour les noyaux Android peuvent être trouvés ici .
Tests de pré-soumission et de post-soumission Android
Les tests de pré-soumission sont utilisés pour empêcher l'introduction d'échecs dans les noyaux communs. Les résultats ne sont pas accessibles au public pour le moment.
Le test post-soumission d'Android est effectué lorsqu'un nouveau correctif est validé dans une branche commune du noyau. En saisissant aosp_kernel comme nom de branche partiel, vous voyez une liste des branches du noyau avec les résultats disponibles. Par exemple, les résultats pour android-mainline peuvent être trouvés ici .
Test de 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 d'essai
| Noyau commun Android | Versions de la plate-forme Android | Suites de tests | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Maître | 13 | 12 | 11 | dix | 9 (tarte) | LKFT | KernelCI | Pré-soumettre | Publier Soumettre | 0-jour | |
android-mainline | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android13-5.15 | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android12-5.10 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android11-5.4 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android-4.19-q | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ | android-4.9-q | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ |
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 communs Android. Le développement en amont est fortement encouragé, et une fois que le développement y est accepté, il peut être facilement rétroporté vers la branche ACK spécifique selon les besoins. L' équipe du noyau Android 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 .