Configuration du noyau

Utilisez les paramètres de configuration suivants comme base pour une configuration du noyau Android. Les paramètres sont organisés en fichiers .cfg pour android-base , android-base- ARCH et android-recommended :

  • Les options android-base activent les fonctionnalités Android de base et doivent être configurées comme spécifié par tous les appareils.
  • Les options android-base- ARCH activent les fonctionnalités de base d'Android et doivent être configurées comme spécifié par tous les appareils de l'architecture ARCH . Toutes les architectures ne disposent pas d'un fichier correspondant d'options requises spécifiques à l'architecture. Si votre architecture ne possède pas de fichier, elle n'a pas d'exigences supplémentaires de configuration du noyau spécifiques à l'architecture pour Android.
  • android-recommended . Ces options activent des fonctionnalités Android avancées et sont facultatives pour les appareils.

Ces fichiers de configuration se trouvent dans le dépôt kernel/configs . Utilisez l'ensemble des fichiers de configuration qui correspond à la version du noyau que vous utilisez.

Pour plus de détails sur les contrôles déjà entrepris pour renforcer le noyau sur vos appareils, consultez 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 appareils dotés d'un 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.

Exigences supplémentaires de configuration 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. Sous Android 9 et versions ultérieures, Compatibility Test Suite (CTS) et Vendor Test Suite (VTS) vérifient que les exigences suivantes sont remplies :

  • CONFIG_OF=y ou CONFIG_ACPI=y
  • Les noyaux 4.4 et 4.9 ont CONFIG_ANDROID_LOW_MEMORY_KILLER=y OU ont à la fois CONFIG_MEMCG=y et CONFIG_MEMCG_SWAP=y
  • CONFIG_DEBUG_RODATA=y ou CONFIG_STRICT_KERNEL_RWX=y
  • CONFIG_DEBUG_SET_MODULE_RONX=y ou CONFIG_STRICT_MODULE_RWX=y
  • Pour ARM64 uniquement : CONFIG_ARM64_SW_TTBR0_PAN=y ou CONFIG_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 MIDI en mode hôte USB, 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 sandbox qui définissent le contexte dans lequel un processus peut effectuer des appels système. La fonctionnalité de synchronisation des threads (TSYNC) permet l'utilisation de Seccomp BPF à partir de programmes multithread. 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 ), conçu pour détecter et atténuer les blocages du noyau. Pour plus de détails sur l'utilisation de llkd , reportez-vous à Démon Android Live-Lock .

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 permet 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 à l'unification des vDSO sur toutes 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 du compilateur arm32. L'équipe du noyau Android a rétroporté les anciennes versions de la série de correctifs vDSO sur 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 de RAM faible

Ajustez 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'un défaut 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 disque pour vider une page sauvegardée dans 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 comporte des filigranes qui déclenchent kswapd ou une récupération en arrière-plan. Il s'agit d'un fil qui tente de libérer des pages afin que la prochaine fois qu'un véritable fil effectue une allocation, 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 lors de la récupération en arrière-plan. Cela signifie que tout processus allouant rapidement plus de quelques mégaoctets sera rapidement récupéré directement.

La prise en charge d'un réglage du noyau est ajoutée dans la branche du noyau Android-3.4 en tant que correctif 92189d47f66c67e5fd92eafaa287e153197a454f ("ajouter des kilo-octets libres supplémentaires réglables"). Le fait de sélectionner ce correctif sur le noyau d'un périphérique permet à ActivityManager d'indiquer au noyau d'essayer de conserver trois tampons de mémoire plein écran de 32 bpp libres.

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 des fichiers (pages mises en cache) requises 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 des fichiers, de sorte que les processus en arrière-plan soient supprimés bien avant que le disque ne se produise en raison d'un cache trop petit.

<!-- 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>