Cette page a été traduite par l'API Cloud Translation.

Configuration du noyau

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

Les options android-base permettent d'activer les principales fonctionnalités Android et doit être configuré comme spécifié par tous les appareils.
Les options android-base-ARCH activent les fonctionnalités de base fonctionnalités Android et doit être configuré comme spécifié par tous les appareils de l'architecture ARCH. Toutes les architectures n'ont pas de fichier correspondant d'options requises propres à l'architecture. Si votre architecture ne comporte pas il n'a pas de configuration de noyau spécifique à l'architecture requises pour Android.
android-recommended Ces options permettent d'activer les fonctionnalités avancées d'Android et sont facultatives pour les appareils.

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

Pour en savoir plus sur les contrôles déjà entrepris pour renforcer le noyau sur votre appareils, consultez la section Système et la sécurité du noyau. Pour en savoir plus sur les paramètres requis, consultez les Document de définition de compatibilité Android (CDD).

Générer la configuration du noyau

Pour les appareils dont le format defconfig est minimaliste, utilisez la 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 defconfig ou compiler un nouveau noyau avec les fonctionnalités Android est activé.

Exigences supplémentaires pour la configuration du noyau

Dans certains cas, le gestionnaire de la plateforme peut choisir parmi plusieurs noyaux pour satisfaire une dépendance Android. De telles dépendances ne peuvent pas exprimé dans les fichiers de fragment de configuration du noyau (décrits ci-dessus), car format pour ces fichiers n'est pas compatible avec les expressions logiques. Sur Android 9 et de niveau supérieur, la Compatibility Test Suite (CTS) et La suite de test fournisseur (VTS) vérifie que les conditions suivantes sont remplies:

CONFIG_OF=y ou CONFIG_ACPI=y
Les noyaux 4.4 et 4.9 disposent de CONFIG_ANDROID_LOW_MEMORY_KILLER=y OU qui incluent à 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 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 mode hôte USB MIDI, activez l'option suivante:

CONFIG_SND_USB_MIDI=y

Seccomp BPF avec TSYNC

Seccomp BPF (Secure Computing Berkeley Packet filter) est un filtre de sécurité du noyau qui permet de créer des bacs à sable qui définissent le contexte qu'un processus peut effectuer des appels système. Synchronisation des threads (TSYNC) permet d'utiliser BPF Seccomp à partir de programmes multithread. Ce la 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 verrouillage 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 Damon de verrouillage en direct Android.

vDSO32 sur ARM64

L'objet partagé dynamique virtuel (vDSO) est une alternative aux appels système qui, lorsqu'elles sont utilisées et configurées correctement, peuvent réduire les coûts de cycle. Android 10 est désormais 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). En utilisant vDSO32 (CONFIG_VDSO_COMPAT) sur l'architecture ARM64 fournit Augmentation de 0,4 % de l'autonomie de la batterie et autres améliorations des performances.

La communauté Linux travaille activement sur unifier des vDSO entre plusieurs 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 compilation arm32. L'équipe du noyau Android a rétroporté d'anciennes versions de la série de correctifs vDSO sur les appareils Pixel. Vous pourrez ainsi trouver des exemples de builds de noyau Pixel (chemin d'accès LINUX_FCC_CROSS_COMPILE_ARM32_PREBUILTS_BIN, Référence CROSS_COMPILE_ARM32 CONFIG_CROSS_COMPILE_ARM32).

Configuration à faible mémoire RAM

Régler le noyau et ActivityManager pour réduire la récupération directe

Une 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 défaillance sur une nouvelle page) et que le noyau dispose utilisé toute la mémoire disponible disponible. Cela nécessite que le noyau bloque l’allocation tout en libérant une page. Cela nécessite souvent des E/S de disque pour vider une page contenant un fichier corrompu ou attendez que lowmemorykiller arrête une processus. Cela peut entraîner des E/S supplémentaires dans n'importe quel thread, y compris un thread UI.

Pour éviter la récupération directe, le noyau a des filigranes qui déclenchent kswapd ou récupération en arrière-plan. Il s'agit d'un fil de discussion qui tente de libérer des pages. Ainsi, la prochaine fois qu'un thread réel sera alloué, il pourra aboutir rapidement.

Le seuil par défaut de déclenchement de la récupération en arrière-plan est assez faible, 2 Mo sur un appareil de 2 Go et 636 Ko sur un appareil de 512 Mo. La 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 tout processus alloue rapidement plus de quelques mégaoctets, cliquez sur "Récupération directe".

La prise en charge d'un noyau réglable est ajoutée dans la branche de noyau Android-3.4 en tant que correctif 92189d47f66c67e5fd92eafaa287e153197a454f ("ajouter des kilo-octets sans frais supplémentaires réglable"). La sélection de ce correctif sur le noyau d’un appareil permet ActivityManager pour indiquer au noyau d'essayer de conserver trois éléments en plein écran Tampons de mémoire de 32 bpp libres.

Ces seuils peuvent être configurés à l'aide du config.xml d'infrastructure.

<!-- 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 la LowMemoryKiller pour qu'elle corresponde aux attentes de l'ensemble de travail pages de fichiers (en cache) requises pour exécuter les processus de chaque priorité d'un bucket Cloud Storage. Si un appareil présente des exigences élevées pour l'ensemble de travail, par exemple si l'UI du fournisseur nécessite davantage 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 des pages reposant sur des fichiers, de sorte que les processus en arrière-plan soient arrêtés bien avant le thrashing de disque se produirait lorsque le cache deviendrait trop petit.

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