Utilisez les paramètres de configuration suivants comme base pour une configuration de noyau Android. Les paramètres sont organisés en fichiers .cfg pour android-base , android-base- ARCH et android-recommended :
- Les options
android-baseactivent les fonctionnalités principales d'Android et doivent être configurées comme spécifié par tous les appareils. - Les options
android-base- ARCHactivent les fonctionnalités principales d'Android et doivent être configurées comme spécifié par tous les appareils de l'architecture ARCH . Toutes les architectures n'ont pas un fichier correspondant d'options requises spécifiques à l'architecture. Si votre architecture n'a pas de fichier, elle n'a pas d'exigences de configuration de noyau spécifiques à l'architecture pour Android. -
android-recommended. Ces options activent les fonctionnalités avancées d'Android et sont facultatives pour les appareils.
Ces fichiers de configuration se trouvent dans le kernel/configs . Utilisez l'ensemble de fichiers de configuration correspondant à la version du noyau que vous utilisez.
Pour plus de détails sur les contrôles déjà effectués pour renforcer le noyau sur vos appareils, voir Sécurité du système et du noyau . Pour plus de détails sur les paramètres requis, consultez le document de définition de compatibilité Android (CDD) .
Générer la configuration du noyau
Pour les périphériques au format defconfig minimaliste, utilisez le script merge_config.sh dans l'arborescence du noyau pour activer les options :
ARCH=ARCH scripts/kconfig/merge_config.sh <...>/device_defconfig <...>/android-base.cfg <...>/android-base-ARCH.cfg <...>/android-recommended.cfg
Cela génère un fichier .config que vous pouvez utiliser pour enregistrer un nouveau fichier defconfig ou compiler un nouveau noyau avec les fonctionnalités Android activées.
Configuration requise supplémentaire du noyau
Dans certains cas, le responsable de la plate-forme peut choisir parmi plusieurs fonctionnalités du noyau pour satisfaire une dépendance Android. De telles dépendances ne peuvent pas être exprimées dans les fichiers de fragments de configuration du noyau (décrits ci-dessus) car le format de ces fichiers ne prend pas en charge les expressions logiques. Dans Android 9 et versions ultérieures, Compatibility Test Suite (CTS) et Vendor Test Suite (VTS) vérifient que les exigences suivantes sont satisfaites :
-
CONFIG_OF=youCONFIG_ACPI=y - Les noyaux 4.4 et 4.9 ont
CONFIG_ANDROID_LOW_MEMORY_KILLER=yOU ont à la foisCONFIG_MEMCG=yetCONFIG_MEMCG_SWAP=y -
CONFIG_DEBUG_RODATA=youCONFIG_STRICT_KERNEL_RWX=y -
CONFIG_DEBUG_SET_MODULE_RONX=youCONFIG_STRICT_MODULE_RWX=y - Pour ARM64 uniquement :
CONFIG_ARM64_SW_TTBR0_PAN=youCONFIG_ARM64_PAN=y
De plus, l'option CONFIG_INET_UDP_DIAG doit être définie sur y pour les noyaux 4.9 sous Android 9 et supérieur.
Activer les options du mode hôte USB
Pour l'audio en mode hôte USB, activez les options suivantes :
CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=y # CONFIG_USB_AUDIO is for a peripheral mode (gadget) driver
Pour le mode hôte USB MIDI, activez l'option suivante :
CONFIG_SND_USB_MIDI=y
Seccomp BPF avec TSYNC
Secure Computing Berkeley Packet Filter (Seccomp BPF) est une technologie de sécurité du noyau qui permet la création de bacs à sable qui définissent le contexte dans lequel un processus peut effectuer des appels système. La fonction de synchronisation des threads (TSYNC) permet l'utilisation de Seccomp BPF à partir de programmes multithreads. Cette capacité est limitée aux architectures prenant en charge Seccomp en amont (ARM, ARM64, x86 et x86_64).
Démon Android Live-Lock
Android 10 inclut le démon Android Live-Lock ( llkd ), qui est conçu pour détecter et atténuer les blocages du noyau. Pour plus de détails sur l'utilisation de llkd , reportez-vous à Android Live-Lock Daemon .
vDSO32 sur ARM64
L'objet partagé dynamique virtuel (vDSO) est une alternative aux appels système qui, lorsqu'il est utilisé et configuré correctement, peut réduire les coûts de cycle. Android 10 ajoute la prise en charge de vDSO32 sur les noyaux 64 bits (Android prend déjà en charge vDSO64 sur les noyaux 64 bits et vDSO32 sur les noyaux 32 bits). L'utilisation de vDSO32 ( CONFIG_VDSO_COMPAT ) sur l'architecture ARM64 offre une augmentation de 0,4 % de la durée de vie de la batterie et d'autres améliorations des performances.
La communauté Linux travaille activement à unifier les vDSO à travers les architectures . Vous pouvez configurer vDSO dans votre noyau Linux en activant vDSO32 avec CONFIG_COMPAT et CONFIG_CROSS_COMPILE_COMPAT_VDSO avec le triplet de compilateur arm32. L'équipe du noyau Android a rétroporté les anciennes versions de la série de correctifs vDSO dans les appareils Pixel, vous pouvez donc trouver des exemples dans les versions du noyau Pixel (chemin LINUX_FCC_CROSS_COMPILE_ARM32_PREBUILTS_BIN , référence CROSS_COMPILE_ARM32 et configuration CONFIG_CROSS_COMPILE_ARM32 ).
Configuration à faible RAM
Ajuster le noyau/ActivityManager pour réduire la récupération directe
La récupération directe se produit lorsqu'un processus ou le noyau tente d'allouer une page de mémoire (soit directement, soit en raison d'une erreur dans une nouvelle page) et que le noyau a utilisé toute la mémoire libre disponible. Cela nécessite que le noyau bloque l'allocation pendant qu'il libère une page. Cela nécessite souvent des E / S de disque pour vider une page sauvegardée sur un fichier sale ou attendre que lowmemorykiller arrête un processus. Cela peut entraîner des E/S supplémentaires dans n'importe quel thread, y compris un thread d'interface utilisateur.
Pour éviter la récupération directe, le noyau a des filigranes qui déclenchent kswapd ou la récupération en arrière-plan. Il s'agit d'un thread qui essaie de libérer des pages afin que la prochaine fois qu'un vrai thread alloue, il puisse réussir rapidement.
Le seuil par défaut pour déclencher la récupération en arrière-plan est assez bas, environ 2 Mo sur un appareil de 2 Go et 636 Ko sur un appareil de 512 Mo. Le noyau ne récupère que quelques mégaoctets de mémoire en arrière-plan. Cela signifie que tout processus qui alloue rapidement plus de quelques mégaoctets va rapidement être récupéré directement.
La prise en charge d'un noyau réglable est ajoutée dans la branche du noyau Android-3.4 en tant que correctif 92189d47f66c67e5fd92eafaa287e153197a454f ("ajouter des kilo-octets gratuits supplémentaires réglables"). Le fait de choisir ce correctif dans le noyau d'un périphérique permet à ActivityManager de dire au noyau d'essayer de garder trois tampons plein écran de 32 bpp de mémoire libre.
Ces seuils peuvent être configurés avec le framework config.xml .
<!-- Device configuration setting the /proc/sys/vm/extra_free_kbytes tunable in the kernel (if it exists). A high value will increase the amount of memory that the kernel tries to keep free, reducing allocation time and causing the lowmemorykiller to kill earlier. A low value allows more memory to be used by processes but may cause more allocations to block waiting on disk I/O or lowmemorykiller. Overrides the default value chosen by ActivityManager based on screen size. 0 prevents keeping any extra memory over what the kernel keeps by default. -1 keeps the default. --> <integer name="config_extraFreeKbytesAbsolute">-1</integer>
<!-- Device configuration adjusting the /proc/sys/vm/extra_free_kbytes tunable in the kernel (if it exists). 0 uses the default value chosen by ActivityManager. A positive value will increase the amount of memory that the kernel tries to keep free, reducing allocation time and causing the lowmemorykiller to kill earlier. A negative value allows more memory to be used by processes but may cause more allocations to block waiting on disk I/O or lowmemorykiller. Directly added to the default value chosen by ActivityManager based on screen size. --> <integer name="config_extraFreeKbytesAdjust">0</integer>
Régler LowMemoryKiller
ActivityManager configure les seuils de LowMemoryKiller pour qu'ils correspondent à ses attentes concernant l'ensemble de travail de pages sauvegardées sur fichier (pages mises en cache) nécessaires pour exécuter les processus dans chaque compartiment de niveau de priorité. Si un appareil a des exigences élevées pour l'ensemble de travail, par exemple si l'interface utilisateur du fournisseur nécessite plus de mémoire ou si davantage de services ont été ajoutés, les seuils peuvent être augmentés.
Les seuils peuvent être réduits si trop de mémoire est réservée aux pages sauvegardées sur fichier, de sorte que les processus d'arrière-plan sont tués bien avant que le disque ne se produise en raison de la taille insuffisante du cache.
<!-- Device configuration setting the minfree tunable in the lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to fire earlier, keeping more memory in the file cache and preventing I/O thrashing, but allowing fewer processes to stay in memory. A low value will keep more processes in memory but may cause thrashing if set too low. Overrides the default value chosen by ActivityManager based on screen size and total memory for the largest lowmemorykiller bucket, and scaled proportionally to the smaller buckets. -1 keeps the default. --> <integer name="config_lowMemoryKillerMinFreeKbytesAbsolute">-1</integer>
<!-- Device configuration adjusting the minfree tunable in the lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to fire earlier, keeping more memory in the file cache and preventing I/O thrashing, but allowing fewer processes to stay in memory. A low value will keep more processes in memory but may cause thrashing if set too low. Directly added to the default value chosen by ActivityManager based on screen size and total memory for the largest lowmemorykiller bucket, and scaled proportionally to the smaller buckets. 0 keeps the default. --> <integer name="config_lowMemoryKillerMinFreeKbytesAdjust">0</integer>