Introduction to Android Things Kernel Customization

Android Things (AT) provides a robust, managed platform specifically designed for Internet of Things (IoT) devices. While it significantly simplifies application development for embedded systems, its success in diverse IoT landscapes often hinges on deep hardware integration. Many embedded projects require support for specific, proprietary hardware components not directly supported by the standard Android Things distribution, or demand highly optimized performance and power characteristics that necessitate low-level adjustments.

This is where Linux kernel customization becomes not just an option, but a necessity. By porting and tailoring the underlying Linux kernel, developers gain the ability to unlock the full potential of their hardware, integrate new peripherals, and fine-tune system behavior to meet stringent embedded requirements. This expert guide will walk you through the comprehensive process of porting and customizing the Linux kernel for Android Things, enabling you to take full control over your embedded device’s hardware.

Understanding the Android Things OS Stack

Android Things is fundamentally built upon the Android Open Source Project (AOSP), which itself is a highly modified and optimized Linux distribution. To effectively customize the kernel, it’s crucial to understand its position within the broader Android Things software stack:

• Applications (APK): The user-facing software developed using Android Studio.
• Android Framework (Java/Kotlin): Provides the APIs and services for applications.
• Android Runtime (ART) & Libraries (C/C++): Executes application code and offers system-level functionalities.
• Hardware Abstraction Layer (HAL): Standardized interfaces for Android to interact with hardware.
• Linux Kernel: The very foundation, responsible for managing the CPU, memory, peripherals, and providing drivers for the hardware.
• Device Hardware: The physical components of your embedded device.

The Linux kernel is the bedrock of this architecture. Customizations at this layer directly impact hardware support, power efficiency, real-time capabilities, and overall system stability. Modifying the kernel allows you to bypass the limitations of existing HAL implementations and directly interface with your specific hardware.

Prerequisites and Environment Setup

Hardware and Software Requirements

• Linux Development Machine: A powerful workstation running a recent Ubuntu LTS version (e.g., 18.04, 20.04) is highly recommended.
• Ample Storage: At least 200GB of free disk space for the AOSP source code and build artifacts.
• High-Speed Internet: For syncing the AOSP repository.
• Target Android Things Device: This could be a development board like a Raspberry Pi 3, an NXP i.MX series board, or a custom PCB.
• Device’s Technical Documentation: Essential datasheets, schematics, and any Board Support Packages (BSPs) from the SoC manufacturer.
• JTAG/UART Debugger: Optional but highly recommended for debugging critical boot failures, especially during initial porting.

Setting up the AOSP Build Environment

Before you can build a custom kernel for Android Things, you need to set up the full AOSP build environment. This involves installing various tools and downloading the AOSP source code. Follow the official AOSP guide for detailed setup, but here are the key steps:

sudo apt-get updatesudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 lib32ncurses5-dev x11proto-core-dev libx11-dev libgl1-mesa-dev libxml2-utils xsltproc fontconfig imagemagickgit config --global user.name "Your Name"git config --global user.email "[email protected]"

Next, initialize and sync the AOSP repository. Make sure to choose the correct Android Things branch (e.g., android-things-1.0.2_r1 or a later version if available):

repo init -u https://android.googlesource.com/platform/manifest -b android-things-1.0.2_r1 --depth=1repo sync -j8

The --depth=1 option creates a shallow clone, saving disk space, but may limit historical analysis. The -j8 option speeds up the sync using 8 parallel jobs (adjust based on your CPU cores).

Acquiring and Configuring the Kernel Source

Identifying Your Device’s Base Kernel

For existing Android Things devices, you can often determine the current kernel version and configuration by accessing the device via ADB:

adb shell uname -a

This command provides details like the kernel version, build date, and architecture. Many AT devices leverage a common Android kernel, or a specific vendor-supplied kernel. For a completely custom board, you’ll typically start with a generic Linux kernel (e.g., from kernel/common in AOSP) or a board-specific BSP provided by your SoC vendor.

Getting the Kernel Source

Navigate to the kernel directory within your AOSP tree. If you’re using a generic Android kernel, it’s often located at kernel/common. If your board uses a specific kernel variant, it might be in kernel/.

cd kernel/common

You can clone the appropriate kernel branch. For example, for an Android Things 5.4 LTS kernel:

git clone https://android.googlesource.com/kernel/common.git -b android-things-5.4-lts kernel_at_5.4cd kernel_at_5.4

For vendor-specific kernels, you might need to download a Board Support Package (BSP) directly from the SoC manufacturer’s website and integrate it into your AOSP source tree.

Configuring the Kernel

The kernel configuration (`.config` file) dictates which features, drivers, and optimizations are compiled into your kernel. This is a critical step for adding support for new hardware.

First, set up your architecture and cross-compiler environment variables. The cross-compiler is located within your AOSP prebuilts:

export ARCH=arm64export CROSS_COMPILE=/path/to/aosp/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-

Now, start with a base configuration file. Many boards have a default configuration (`defconfig`) provided by the vendor or AOSP:

make <board_defconfig>

For example, for a Raspberry Pi 3, it might be `make rpi3_defconfig`. If no exact match, you might start with a generic `arm64_defconfig`.

For fine-grained customization, use menuconfig:

make menuconfig

This launches a text-based interface where you can enable/disable modules, add support for specific file systems, network protocols, input devices, and crucially, new drivers for your custom hardware (e.g., I2C/SPI sensors, custom displays, specialized network interfaces). Save your configuration as a new `defconfig` for future use.

Customizing and Building the Kernel

Integrating Device Tree Overlays (DTBO)

Modern ARM-based embedded systems utilize Device Trees (DT) to describe hardware. This eliminates the need for hardcoding hardware details directly into the kernel source. Instead, Device Tree Source (`.dts`) files describe peripherals, memory maps, and other hardware components.

For new or custom hardware, you will likely need to modify existing `.dts` files or create new ones in the `arch/arm64/boot/dts/` directory of your kernel source. These files are then compiled into Device Tree Blob (`.dtb`) files.

Here’s an example of adding a custom I2C sensor to a device tree:

&i2c1 {status = "okay";custom_sensor@68 {compatible = "vendor,custom-sensor";reg = <0x68>;};};

This snippet enables `i2c1` and defines a new device node for a custom sensor at address `0x68` on that bus.

Adding Custom Kernel Modules

If your device requires specific drivers not present in the mainline kernel, you can write them as loadable kernel modules (`.ko`). These modules can be dynamically loaded and unloaded, which is useful for development and for optional hardware.

Create a Kbuild file in your custom driver’s directory:

obj-m := custom_driver.o

Then, compile the module (assuming you are in the kernel source root):

make M=$PWD

Building the Kernel and Modules

After all configurations and source modifications are complete, build the kernel image and any external modules:

make -j$(nproc) Image.gz dtbs modules

The `Image.gz` (or `Image`) file is your compressed kernel image. The compiled device tree blobs will be in the `arch/arm64/boot/dts/` directory, and modules will be packaged into a `modules.tar.gz` or similar archive in the root of your kernel build directory.

Integrating with Android Things and Flashing

Placing Kernel Artifacts

Once your custom kernel is built, you need to copy the compiled artifacts into the appropriate locations within your AOSP build tree so that Android Things can incorporate them into the final system image. The exact paths depend on your specific Android Things board configuration.

cp arch/arm64/boot/Image.gz /path/to/aosp/device/google/at-rpi3/kernel/cp arch/arm64/boot/dts/*.dtb /path/to/aosp/device/google/at-rpi3/dtbs/

If you built any custom kernel modules, they need to be placed such that the Android Things build system packages them into the `vendor` or `system_ext` partition. This typically involves modifying the board’s `BoardConfig.mk` or `device.mk` files to include your modules.

Building Android Things with Custom Kernel

Now, rebuild the entire Android Things operating system, which will incorporate your custom kernel and any changes.

source build/envsetup.shlunch aosp_rpi3-userdebug  # Replace 'aosp_rpi3-userdebug' with your board's lunch targetmake -j$(nproc)

This command compiles the entire AOSP source tree, generating all necessary images (boot, system, vendor, etc.) for your Android Things device, including your custom kernel.

Flashing the Device

Finally, flash the newly built Android Things image onto your target device. Ensure your device is connected via USB and is in fastboot mode.

adb reboot bootloaderfastboot flash boot /path/to/aosp/out/target/product/rpi3/boot.imgfastboot flash system /path/to/aosp/out/target/product/rpi3/system.imgfastboot flash vendor /path/to/aosp/out/target/product/rpi3/vendor.imgfastboot reboot

Verify that your device boots correctly and that all custom hardware is recognized and functional.

Debugging and Advanced Considerations

• Boot Loops: These are common and often result from incorrect kernel configurations, missing device tree entries, or critical driver failures. Connect a UART console to capture early boot messages, which are invaluable for diagnosis.
• Driver Issues: Use dmesg to check kernel logs for driver loading errors, and logcat to see if Android components are interacting correctly with the hardware abstraction layer. Ensure device nodes (`/dev/`) are created for your peripherals.
• Performance Tuning: For specific IoT applications, you might need to adjust kernel schedulers, memory management parameters, and power governors for optimal performance or low-power operation.
• Security: When introducing new drivers or modules, pay close attention to security implications. Ensure critical drivers are hardened, and disable any unnecessary kernel features or modules to reduce the attack surface.

Conclusion

Customizing the Linux kernel for Android Things is a complex but incredibly rewarding endeavor. It empowers developers to extend hardware compatibility, integrate specialized peripherals, and optimize performance and power consumption for their unique embedded applications. While the learning curve can be steep, gaining this level of control over the lowest layers of your IoT stack unlocks immense potential for innovation and differentiation in the rapidly evolving embedded world. This guide provides a solid foundation for you to embark on your own Android Things kernel porting journey, enabling you to build truly bespoke and optimized IoT solutions.