Utilisez les paramètres de configuration suivants comme base pour une configuration du kernel Android. Les paramètres sont organisés dans des fichiers .cfg pour android-base, android-base-ARCH et android-recommended:
- Les options
android-baseactivent les principales fonctionnalités Android et doivent être configurées comme spécifié par tous les appareils. - Les options
android-base-ARCHactivent 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 dispose pas de fichier, elle n'a pas d'exigences de configuration du noyau spécifiques à l'architecture pour Android. android-recommended. Ces options activent les 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 de fichiers de configuration correspondant à la version du kernel que vous utilisez.
Pour en savoir plus sur les contrôles déjà mis en place pour renforcer le noyau sur vos appareils, consultez la section Sécurité du système et du noyau. Pour en savoir plus sur les paramètres requis, consultez le document de définition de compatibilité (CDD) Android.
Générer la configuration du noyau
Pour les appareils dont le format defconfig est 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 kernel avec les fonctionnalités Android activées.
Exigences de configuration du noyau supplémentaires
Dans certains cas, le responsable de la plate-forme peut choisir parmi plusieurs fonctionnalités du noyau pour répondre à une dépendance Android. Ces dépendances ne peuvent pas être exprimées dans les fichiers de fragment de configuration du noyau (décrits ci-dessus), car le format de ces fichiers n'est pas compatible avec les expressions logiques. Sous Android 9 et versions ultérieures, la suite de tests de compatibilité (CTS) et la suite de tests du fournisseur (VTS) vérifient que les exigences suivantes sont respectées :
CONFIG_OF=youCONFIG_ACPI=y- Les noyaux 4.4 et 4.9 contiennent
CONFIG_ANDROID_LOW_MEMORY_KILLER=yOUCONFIG_MEMCG=yetCONFIG_MEMCG_SWAP=y CONFIG_DEBUG_RODATA=youCONFIG_STRICT_KERNEL_RWX=yCONFIG_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 ou version ultérieure.
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 de créer des bacs à sable qui définissent le contexte dans lequel un processus peut effectuer des appels système. La fonctionnalité de synchronisation des threads (TSYNC) permet d'utiliser BPF Seccomp à partir de programmes multithread. Cette capacité est limitée aux architectures compatibles avec Seccomp en amont (ARM, ARM64, x86 et x86_64).
Daemon de verrouillage en direct Android
Android 10 inclut le daemon de blocage en direct Android (llkd), conçu pour détecter et atténuer les interblocages du noyau.
Pour en savoir plus sur l'utilisation de llkd, consultez Daemon de verrouillage en direct Android.
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 est compatible avec vDSO32 sur les noyaux 64 bits (Android est déjà compatible avec 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 d'augmenter l'autonomie de la batterie de 0,4 % et d'améliorer d'autres performances.
La communauté Linux travaille activement à l'unification des vDSO sur les différentes architectures. Vous pouvez configurer vDSO dans votre kernel Linux en activant vDSO32 avec CONFIG_COMPAT et CONFIG_CROSS_COMPILE_COMPAT_VDSO avec le triplet du compilateur arm32.
L'équipe du kernel Android a rétroporté d'anciennes versions de la série de correctifs vDSO sur les appareils Pixel. Vous trouverez donc des exemples dans les builds du kernel Pixel (chemin LINUX_FCC_CROSS_COMPILE_ARM32_PREBUILTS_BIN, référence CROSS_COMPILE_ARM32 et configuration CONFIG_CROSS_COMPILE_ARM32).
Configuration de la RAM faible
Ajuster le kernel et 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 (directement ou 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 effacer une page sale basée sur un fichier 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'UI.
Pour éviter la récupération directe, le noyau comporte des filigranes qui déclenchent kswapd ou la récupération en arrière-plan. Il s'agit d'un thread qui tente de libérer des pages afin que la prochaine fois qu'un thread réel effectue une allocation, il puisse y parvenir rapidement.
Le seuil par défaut pour déclencher la récupération en arrière-plan est assez faible, 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 qui alloue rapidement plus de quelques mégaoctets va rapidement atteindre la récupération directe.
La prise en charge d'un paramètre du noyau est ajoutée dans la branche du noyau Android-3.4 en tant que correctif 92189d47f66c67e5fd92eafaa287e153197a454f ("add extra free kbytes tunable"). Sélectionner ce correctif dans le noyau d'un appareil permet à ActivityManager d'indiquer au noyau d'essayer de libérer trois mémoires tampons de 32 bpp en plein écran.
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 increases 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 increases 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 des pages basées sur des fichiers (pages mises en cache) requises pour exécuter les processus dans chaque bucket de niveau de priorité. Si un appareil présente 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 d'autres 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 pour les pages basées sur des fichiers, de sorte que les processus en arrière-plan soient arrêtés bien avant que le rafales de disque ne se produisent en raison de la taille trop faible du cache.
<!-- Device configuration setting the minfree tunable in the lowmemorykiller in the kernel. A high value causes 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 keeps 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 causes 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 keeps 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>