Exigences de base du noyau

Android 8.0 ou version ultérieure exigent une version et un noyau minimales de votre configuration, qui sont vérifiées par la suite de test fournisseur (VTS) et Over The Air (OTA). Les noyaux d'appareils Android doivent activer le noyau .config et la possibilité de lire la configuration du noyau au moment de l'exécution via le procfs.

Compatibilité avec les fichiers .config du noyau

Tous les noyaux de périphériques doivent permettre l’intégralité android-base.cfg, qui doit inclure les éléments suivants : Les options kernel-config (ou leur équivalent en version kernel): 

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Version de noyau

Pour Android 9, le support à long terme (LTS) minimal les versions de noyau requises sont 4.4.107, 4.9.84 et 4.14.42.

  • Tous les SoC produits en 2018 doivent être lancés avec un kernel 4.9.84 ou version ultérieure.
  • Tous les autres SoC proposant des appareils Android fonctionnant sous Android 9 vous devez utiliser le kernel 4.4.107 ou une version ultérieure.
  • Les noyaux d'appareils basés sur la version 4.14 doivent inclure la version LTS 4.14.42 ou ultérieure. de sortie.
  • Quelle que soit la date de lancement, tous les SoC équipés d'appareils sont lancés sous Android 8.0. et supérieurs restent soumis aux modifications du noyau nécessaires à l’activation de Treble.
  • Les anciens appareils Android qui passent à Android 8.0 ou version ultérieure peuvent continuer à : utilisent la version de base d'origine du noyau.

Pour en savoir plus sur les noyaux LTS, consultez Long terme noyaux stables et Android Common Kernels

Compatibilité avec Devicetree

Si la plate-forme n'est pas compatible avec la spécification ACPI (Advanced Configuration and Power Interface), la prise en charge de devicetree dans le noyau doit être activée et les bootloaders doivent transmettre le description du matériel sous la forme d'une arborescence de périphériques vers le noyau. L'arborescence des appareils doit également être disponible en lecture sur Android, et doit être capable de transmettre des et les paramètres propres à l'ODM vers Android. CONFIG_OF est obligatoire, ainsi que tous les autres CONFIG_OF_* propres à l'appareil et aux sous-systèmes. de configuration du noyau.

Utiliser DebugFS

L'implémentation de l'interface fournisseur ne peut pas s'appuyer sur DebugFS pour accéder aux informations de débogage. En effet, sur Android 7.0 à 10, DebugFS peut être activé. mais les tests VTS peuvent être effectués avec DebugFS désinstallé.

Sous Android 11, DebugFS est inaccessible ou ne peut être installé sur appareils de production, les fabricants doivent donc le supprimer. Avant Android 11, dumpstate a accédé aux statistiques de liaison à partir de DebugFS. Parce que les builds utilisateur lancés avec Android 11 ou version ultérieure ne peuvent pas accéder DebugFS, dumpstate accède aux statistiques de liaison de binderfs Pour activer Binderfs, activez le noyau CONFIG_ANDROID_BINDERFS.

Dans Android 11, le VTS applique les deux exigences suivantes:

  • CONFIG_DEBUG_FS n'est pas activé dans la configuration du noyau de l'appareil.
  • DebugFS ne figure pas sous /proc/filesystems.

DebugFS dans Android 11

Le tableau suivant décrit en quoi chacune de ces trois catégories est compatible avec Android 11. Notez que Les éléments suivants ne s'appliquent qu'aux builds userdebug, car DebugFS ne peut pas être installés dans des builds utilisateur. N'installez jamais DebugFS dans les builds utilisateur pour les appareils. sur Android 11.

Cas d'utilisation Version de débogage utilisateur Android 11
Initialisation unique des fichiers DebugFS, au démarrage. Cet accès n'est effectué qu'une seule fois au démarrage. C'est ce que fait l'initialisation du fournisseur.
Génération de rapport de bug: la fonction HAL de dumpstate lit Fichiers DebugFS, qui feront partie du rapport de bug. Terminée par la couche de protection HAL dans DumpstateBoard() en cas d'appel par l'outil dumpstate.
Tests et validations spécifiques à l'appareil Racine et shell ADB