Core Kernel Requirements

Android 8.0 and higher mandate a minimum kernel version and kernel configuration, which are verified by the Vendor Test Suite (VTS) and over-the-air (OTA) updates. Android device kernels must enable kernel .config support and the option to read the kernel configuration at runtime through the procfs file system.

Kernel .config support

All device kernels must enable the entirety of android-base.cfg, which must include the following kernel-config options (or their kernel-version equivalent): 

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Kernel version

For Android 9, the minimum Long Term Support (LTS) kernel version requirements are 4.4.107, 4.9.84, and 4.14.42.

  • All SoCs productized in 2018 must launch with kernel 4.9.84 or higher.
  • All other SoCs launching Android devices running Android 9 must use kernel 4.4.107 or higher.
  • Device kernels based on 4.14 must include the 4.14.42 or higher LTS release.
  • Regardless of launch date, all SoCs with device launches on Android 8.0 and higher remain subject to the kernel changes required to enable Treble.
  • Older Android devices upgrading to Android 8.0 or higher can continue to use their original base kernel version.

For details on LTS kernels, see Long-term stable kernels and Android Common Kernels

Devicetree support

If the platform doesn't support the Advanced Configuration and Power Interface (ACPI) specification, devicetree support in the kernel must be enabled and bootloaders must pass the hardware description in the form of a devicetree to the kernel. The devicetree must also be available for Android to read, and it must be able to pass vendor- and ODM-specific parameters to Android. CONFIG_OF is mandatory, along with all other device- and subsystem-specific CONFIG_OF_* kernel config options.

Using DebugFS

The implementation of the vendor interface can't rely on the DebugFS file system to access debug information. That's because in Android 7.0–10, DebugFS can be enabled, but VTS testing might be done with DebugFS unmounted.

In Android 11, DebugFS can't be accessed or mounted on production devices, so device manufacturers must remove it. Before Android 11, dumpstate accessed binder statistics from DebugFS. Because user builds launching with Android 11 or higher can’t access DebugFS, dumpstate accesses binder statistics from binderfs. To enable Binderfs, enable the kernel config CONFIG_ANDROID_BINDERFS.

In Android 11, VTS enforces these two requirements:

  • CONFIG_DEBUG_FS isn't enabled in the device’s kernel config.
  • DebugFS isn't listed under /proc/filesystems.

DebugFS in Android 12

Devices that launch with Android 12 using kernel versions higher than v5.4 are required to ship with the GKI kernel. So that partners can access DebugFS in userdebug builds while they develop on the GKI kernel, the kernel config CONFIG_DEBUG_FS is enabled in the GKI defconfig. Never mount DebugFS in user builds for devices launching on both Android 11 and Android 12.

Userdebug builds have better test coverage than user builds and get heavily tested throughout the development cycle. The following plan minimizes the difference between the two build types with respect to DebugFS access, and provides these benefits:

  • Prevents userdebug builds from accidentally depending on DebugFS for new functionality
  • Ensures that any existing functionality that's broken by the lack of DebugFS is known early in the development cycle

Debugfs accesses in userdebug builds are categorized as follows:

  1. DebugFS file initializations during device boot, such as a write access to a file in DebugFS to turn on debug data collection.
  2. Bugreport generation: The dumpstate HAL reads DebugFS files when DumpstateBoard() is invoked by dumpstate. This information becomes part of the bug report.
  3. Device-specific testing and validation.

The following table describes how each of these three categories is supported in Android 11 and Android 12. Note that the following only applies to userdebug builds since DebugFS can’t be mounted in user builds.

Use case Android 11 userdebug build Android 12 userdebug build
One-time DebugFS files initialization, during startup. This access happens only once during boot time. Vendor init does this. Dumpstate HAL performs this during HAL initialization. To enable the same, init mounts DebugFS in userdebug builds before the HAL initializes. Init calls umount() on DebugFS when the device has completed booting.
Bugreport generation: The dumpstate HAL reads DebugFS files, which become part of the bug report. Done by dumpstate HAL within DumpstateBoard() when invoked by the dumpstate tool. Done by dumpstate HAL within DumpstateBoard() when invoked by dumpstate (DumpstateDevice.cpp). The dumpstate tool (part of the Android framework) ensures that DebugFS mounts during the invocation.
Device-specific testing and validation Adb root and shell Adb root and shell. Mount DebugFS from the adb shell with root access1.

1To mount DebugFS from adb shell with root access, use this command:

adb shell mount -t debugfs debugfs /sys/kernel/debug.

Required Partner Actions

Partners must enact the following based on these changes in Android 12 devices:

  • Make all boot time initializations of DebugFS nodes happen during the dumpstate HAL initialization. For an example of how to do this, see DNM: Example for boot time initialization of DebugFS files.
  • Don’t allow DebugFS access during runtime. The following exceptions apply:
    • Bugreport generation (comes from the dumpstate HAL)
    • Testing and validation (accessible by adb root and shell - ensure that DebugFS is mounted first)

Developers can set the debug persistent property persist.dbg.keep_debugfs_mounted to keep DebugFs mounted across reboots on userdebug and eng builds.

GTS compliance tests ensure that the DebugFS filesystem isn’t mounted in user builds. Sepolicy neverallow statements ensure that in devices launching on Android 12 or higher, unauthorized processes aren't provided access to DebugFs.