Introduction: Unlocking Custom Hardware with Android Things

Android Things, Google’s embedded operating system for IoT devices, offers a streamlined development experience by extending the Android platform to a new class of hardware. While Google officially ended support for Android Things, its core architecture and capabilities remain highly relevant for custom embedded projects, especially when commercial off-the-shelf boards don’t meet specific industrial or specialized requirements. Porting Android Things to unsupported hardware, such as custom-designed PCB boards, presents a unique challenge and opportunity for deep hardware-software integration. This guide provides an expert-level, step-by-step walkthrough for achieving this complex porting task.

Why Port Android Things to Custom Hardware?

• Specific Hardware Requirements: Custom form factors, unique sensor arrays, or specialized peripheral interfaces not found on existing Android Things boards.
• Cost Optimization: Tailoring the Bill of Materials (BOM) to reduce unnecessary components for mass production.
• Security and Control: Full control over the software stack, boot process, and hardware security features.
• Legacy Device Modernization: Bringing Android’s rich ecosystem to older, but still functional, embedded systems.

Prerequisites: Laying the Foundation

Before embarking on the porting journey, ensure you have the necessary hardware and software resources:

Hardware Requirements

• Target SoC (System-on-Chip): An ARM Cortex-A series processor (e.g., NXP i.MX, Rockchip, Qualcomm Snapdragon Embedded) with a robust Linux BSP (Board Support Package) available.
• Memory: Minimum 2GB RAM (DDR3/DDR4) for a functional Android Things experience; 4GB or more is recommended for performance.
• Storage: eMMC or NAND flash storage, 8GB minimum, 16GB+ recommended.
• Debug Peripherals: Essential UART console access for bootloader and kernel debugging.
• Connectivity: Ethernet, Wi-Fi, and/or Bluetooth modules integrated and supported by the SoC.
• Input/Output: GPIOs, I2C, SPI, PWM controllers for interacting with custom peripherals.

Development Environment (Host PC)

• Operating System: Linux (Ubuntu 18.04 LTS or newer is highly recommended).
• Processor: Multi-core CPU (Intel i7/i9 or AMD Ryzen 7/9) for faster AOSP builds.
• RAM: At least 32GB RAM.
• Storage: 500GB+ SSD for AOSP source code and build artifacts.
• Software Tools: Git, Repo tool, Android SDK/NDK, Java Development Kit (OpenJDK 8 is often required for older AOSP branches), various build utilities.

Understanding Android Things Architecture for Porting

Android Things, at its core, is a specialized version of Android Open Source Project (AOSP) optimized for embedded IoT devices. Key architectural components relevant to porting include:

• Linux Kernel: The foundation, providing drivers for the SoC and peripherals.
• Bootloader: U-Boot or Fastboot, responsible for initializing hardware and loading the kernel.
• Hardware Abstraction Layers (HALs): Standardized interfaces that allow the Android framework to interact with underlying hardware drivers. Custom HALs are crucial for unique hardware.
• User Space Drivers: Android Things offers specific APIs (e.g., Peripheral I/O API) that allow user-space applications to directly access GPIO, I2C, SPI, PWM, and UART. This relies on corresponding kernel drivers and sometimes a custom HAL.

Step 1: Setting Up the AOSP Build Environment

The first step is to synchronize the Android Things AOSP source code and set up your build environment. Note that direct Android Things branches might be deprecated; you may need to use a general AOSP branch and adapt it.

# Install necessary packages for Ubuntu (adjust as needed for other distros)sudo apt-get install git-core gnupg flex bison 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 imagemagick openssh-server openjdk-8-jdk# Configure Gitgit config --global user.name "Your Name"git config --global user.email "[email protected]"# Download the 'repo' toolmkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repocmd chmod a+x ~/bin/repo# Initialize AOSP (e.g., Android 8.1, similar to Android Things 1.0.x)mkdir android_things_customcd android_things_customrepo init -u https://android.googlesource.com/platform/manifest -b android-8.1.0_r1# For a specific Android Things branch if still available (highly unlikely for new projects):# repo init -u https://android.googlesource.com/platform/manifest -b at-1.0.4-release# Synchronize the source codereso sync -j$(nproc)

Step 2: Kernel Porting and Device Tree Adaptation

The Linux kernel is the bedrock. You’ll likely start with a vendor-provided BSP kernel for your SoC and adapt it for your specific board. The Device Tree Blob (DTB) is paramount here.

Kernel Source Integration

Place your kernel source (often from `device/qcom/msm8996-common/kernel` for Qualcomm, or `kernel/` root for other vendors) into your AOSP build tree, typically under `kernel//`. Configure `BoardConfig.mk` to point to this kernel.

Device Tree (.dts) Customization

The Device Tree describes your custom board’s hardware to the kernel. You’ll need to create or modify a `.dts` file (e.g., `arch/arm64/boot/dts//-custom-board.dts`).

// Example: Customizing a Device Tree for a new GPIO LED/ {    model = "Custom Android Things Board";    compatible = ",-custom-board", ",";    aliases {        serial0 = &uart1;        gpio-led0 = &gpio_led;    };    memory {        reg = <0x0 0x80000000 0x0 0x80000000>; // Example 2GB RAM    };    // ... other standard components like CPU, GIC, clocks    soc {        #address-cells = <2>;        #size-cells = <2>;        compatible = "simple-bus";        ranges;        gpio_led: gpio-led@0 {            compatible = "gpio-leds";            status = "okay";            led {                label = "custom-board:blue:status";                gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; // GPIO controller 2, pin 5                default-state = "off";            };        };        // ... other custom peripherals (I2C sensors, SPI displays, etc.)        // Ensure all necessary power domains, clocks, and pinmuxes are correctly defined.    };};

You must ensure all relevant hardware components (UART, I2C, SPI, GPIO controllers, display, touch, Wi-Fi, Bluetooth) are correctly defined in the DTB, matching your board’s schematics and layout.

Step 3: Hardware Abstraction Layer (HAL) Development

HALs are crucial. For Android Things, you’ll need to implement or adapt existing HALs for your specific hardware, especially for Peripheral I/O.

Creating a Custom Board Device Folder

Create a new device folder, e.g., `device//`. This folder will contain configuration files like `BoardConfig.mk`, `device.mk`, and `vendorsetup.sh`.

Implementing Peripheral I/O HAL

Android Things uses a specialized `android.hardware.iot` interface for GPIO, I2C, SPI, UART, and PWM. You might need to implement a default HAL for these if your SoC vendor doesn’t provide one tailored for Android Things.

For example, to implement a simple GPIO HAL:

// Example: Placeholder for a custom GPIO HAL structure in C++// This would typically involve using libgpiod or a direct kernel driver interface.namespace android::hardware::iot::gpio::V1_0::implementation {    // Implement IGpio.hal methods    Return<void> open(const hidl_string& name, open_cb _hidl_cb) {        // Logic to open GPIO device node or mmap GPIO registers        // Return handle and status    }    Return<void> close(int32_t handle) {        // Logic to close GPIO handle    }    Return<void> setDirection(int32_t handle, Direction direction) {        // Logic to set GPIO direction (input/output)    }    Return<void> setValue(int32_t handle, Value value) {        // Logic to set GPIO value (high/low)    }    Return<void> getValue(int32_t handle, getValue_cb _hidl_cb) {        // Logic to read GPIO value        // Return value    }}

This HAL would then interact with your kernel’s GPIO drivers (e.g., `/dev/gpiochipX`). Ensure your `device.mk` correctly includes these HALs:

PRODUCT_PACKAGES +=     [email protected]     [email protected]     // ... etc.

Step 4: Building the Android Things Image

Once the kernel and HALs are ready, you can proceed to build the full Android Things image.

# Source the build environment. . build/envsetup.sh# Select your custom board configuration. This will be defined in device///vendorsetup.shlunch -userdebug# Start the build processmake -j$(nproc)

This process can take several hours depending on your machine’s power. Upon successful completion, you’ll find the generated images (e.g., `boot.img`, `system.img`, `userdata.img`, `vendor.img`, `dtb.img`) in `out/target/product//`.

Step 5: Flashing and Initial Boot

Flashing the images to your custom board usually involves `fastboot` or a vendor-specific flashing tool.

# Reboot your board into fastboot mode (procedure varies by SoC/bootloader)# For example, hold a button during power-on, or use a specific USB command.fastboot flash boot out/target/product//boot.imgfastboot flash system out/target/product//system.imgfastboot flash vendor out/target/product//vendor.imgfastboot flash userdata out/target/product//userdata.img# Optionally flash the device tree if it's separate (not bundled in boot.img)fastboot flash dtb out/target/product//dtb.img# Erase cache and rebootfastboot erase cachefastboot reboot

Monitor the serial console (UART) for boot messages. This is critical for debugging early boot failures.

Step 6: Debugging and Iteration

The first boot is rarely perfect. Be prepared for extensive debugging.

• Serial Console (UART): The most important tool. Look for kernel panics, driver initialization failures, or bootloader issues.
• `adb logcat`: Once Android boots sufficiently, use `adb` to check system logs for HAL errors, service crashes, or application issues.
• `dmesg`: Check kernel messages for driver loading status and hardware errors.
• Peripherals Testing: Write small Android Things apps to test GPIO, I2C, SPI, and other peripherals through the Peripheral I/O API.
• Network Connectivity: Ensure Wi-Fi/Ethernet drivers load and connect correctly.

Each failure point will require you to go back to the relevant step (kernel, device tree, HALs), make corrections, rebuild, and re-flash.

Conclusion

Porting Android Things to unsupported custom hardware is a challenging but immensely rewarding endeavor. It provides unparalleled control over your embedded system, enabling highly specialized IoT devices that perfectly match your application’s needs. While the process demands deep expertise in Linux kernel development, AOSP architecture, and hardware design, following these steps will equip you to tackle the complexities and successfully bring Android Things to life on your unique custom board.