Introduction: The Industrial IoT Challenge with Android Things

Android Things provides a robust platform for IoT devices, offering the familiarity of Android’s development model. However, when it comes to integrating highly specialized industrial sensors with demanding real-time constraints, high data rates, or proprietary communication protocols, the standard Hardware Abstraction Layer (HAL) might fall short. The HAL is designed for abstraction, which sometimes introduces latency or limits direct hardware access essential for industrial applications. This article explores how to bypass these limitations by delving into Android Things’ underlying Linux kernel, enabling direct control over General Purpose Input/Output (GPIO) pins and integrating custom sensor drivers for industrial precision.

Going beyond the HAL means developing kernel modules, modifying device trees, and interacting directly with the Linux kernel’s subsystems. This approach grants unparalleled control, allowing for microsecond-level timing, specialized interrupt handling, and efficient data acquisition crucial for applications in industrial automation, robotics, or high-reliability embedded systems.

Setting Up Your Android Things AOSP Build Environment

To modify the kernel, you first need a complete Android Things AOSP (Android Open Source Project) build environment. This involves syncing the Android source code, selecting your target device (e.g., NXP i.MX8M Nano kit), and building the entire OS. Ensure you have ample disk space (200GB+) and a powerful Linux workstation.

# Initialize repo and sync Android Things source
repo init -u https://android.googlesource.com/platform/manifest -b android-things-1.0.3
repo sync -j8

# Set up environment for your target device (example for NXP i.MX8M Nano)
source build/envsetup.sh
lunch aosp_imx8mn_at_kit-userdebug

# Build the entire Android Things OS
make -j$(nproc)

This initial build will compile the kernel, bootloader, and Android userspace components, providing the necessary toolchains and kernel headers for custom module development.

Understanding the Android Things Kernel and Device Tree

Android Things runs on a Linux kernel. All hardware on your board, including GPIO pins, UARTs, SPI, I2C, etc., is described in a Device Tree Blob (DTB). The kernel uses this DTB at boot time to identify and initialize hardware components.

Kernel Source Location

The kernel source code for your specific device will typically be located within the AOSP tree, often under kernel/prebuilts/<architecture>/<kernel_version>/ or specific board vendor directories like device/nxp/imx8mn/. You’ll need the exact kernel version and configuration that Android Things uses for your board to ensure module compatibility.

Device Tree Overlays and Modifications

Device Tree Source (DTS) files (.dts) and Device Tree Source Include (DTSI) files (.dtsi) describe your hardware. These are compiled into a DTB (.dtb) that the bootloader passes to the kernel. To define a new industrial sensor or modify GPIO behavior, you’ll often need to add or modify nodes in these files.

Developing a Custom GPIO Kernel Module: A High-Speed Pulse Counter Example

Let’s develop a simple kernel module to count pulses on a specific GPIO pin, exposing the count via the sysfs filesystem. This demonstrates interrupt handling and userspace communication.

Module Structure and Initialization

Our module will request a GPIO, configure it as an input, and set up an interrupt service routine (ISR) to increment a counter on each rising edge.

// my_gpio_pulse_counter.c
#include <linux/module.h>
#include <linux/init.h>
#include <linux/gpio.h>
#include <linux/interrupt.h>
#include <linux/sysfs.h>
#include <linux/kobject.h>

#define GPIO_PULSE_PIN 23 // Example GPIO pin number (BCM numbering for RPi, or platform-specific)

static unsigned long pulse_count = 0;
static int irq_num;
static struct kobject *pulse_kobj;

static irqreturn_t pulse_isr(int irq, void *dev_id) {
    pulse_count++;
    return IRQ_HANDLED;
}

static ssize_t pulse_count_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf) {
    return sprintf(buf, "%lun", pulse_count);
}

static struct kobj_attribute pulse_count_attribute = 
    __ATTR(pulses, 0444, pulse_count_show, NULL);

static int __init my_gpio_init(void) {
    int ret;

    if (!gpio_is_valid(GPIO_PULSE_PIN)) {
        printk(KERN_ERR "GPIO %d is not validn", GPIO_PULSE_PIN);
        return -ENODEV;
    }

    ret = gpio_request_one(GPIO_PULSE_PIN, GPIOF_IN, "my_pulse_counter");
    if (ret < 0) {
        printk(KERN_ERR "Failed to request GPIO %dn", GPIO_PULSE_PIN);
        return ret;
    }

    irq_num = gpio_to_irq(GPIO_PULSE_PIN);
    if (irq_num < 0) {
        printk(KERN_ERR "Failed to get IRQ for GPIO %dn", GPIO_PULSE_PIN);
        gpio_free(GPIO_PULSE_PIN);
        return irq_num;
    }

    ret = request_irq(irq_num, pulse_isr, IRQF_TRIGGER_RISING | IRQF_SHARED, "my_pulse_counter_irq", (void *)GPIO_PULSE_PIN);
    if (ret < 0) {
        printk(KERN_ERR "Failed to request IRQ %dn", irq_num);
        gpio_free(GPIO_PULSE_PIN);
        return ret;
    }

    pulse_kobj = kobject_create_and_add("my_gpio_pulse_counter", kernel_kobj);
    if (!pulse_kobj) {
        printk(KERN_ERR "Failed to create kobjectn");
        free_irq(irq_num, (void *)GPIO_PULSE_PIN);
        gpio_free(GPIO_PULSE_PIN);
        return -ENOMEM;
    }

    ret = sysfs_create_file(pulse_kobj, &pulse_count_attribute.attr);
    if (ret) {
        printk(KERN_ERR "Failed to create sysfs filen");
        kobject_put(pulse_kobj);
        free_irq(irq_num, (void *)GPIO_PULSE_PIN);
        gpio_free(GPIO_PULSE_PIN);
        return ret;
    }

    printk(KERN_INFO "GPIO Pulse Counter module loaded. Monitoring GPIO %dn", GPIO_PULSE_PIN);
    return 0;
}

static void __exit my_gpio_exit(void) {
    sysfs_remove_file(pulse_kobj, &pulse_count_attribute.attr);
    kobject_put(pulse_kobj);
    free_irq(irq_num, (void *)GPIO_PULSE_PIN);
    gpio_free(GPIO_PULSE_PIN);
    printk(KERN_INFO "GPIO Pulse Counter module unloaded. Total pulses: %lun", pulse_count);
}

module_init(my_gpio_init);
module_exit(my_gpio_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("A simple GPIO pulse counter kernel module");
MODULE_VERSION("0.1");

Makefile for the Module

# Makefile
KDIR := $(YOUR_AOSP_ROOT)/prebuilts/kernel-build-tools/<platform>/android-msm-pixel-4.9
PWD := $(shell pwd)

obj-m := my_gpio_pulse_counter.o

all:
	$(MAKE) -C $(KDIR) M=$(PWD) modules

clean:
	$(MAKE) -C $(KDIR) M=$(PWD) clean

Replace $(YOUR_AOSP_ROOT)/prebuilts/kernel-build-tools/<platform>/android-msm-pixel-4.9 with the actual path to your Android Things kernel build directory within your AOSP setup.

Modifying the Device Tree for Custom Hardware

While the example module directly uses a hardcoded GPIO pin, for more robust industrial integration, you would define your sensor and its connected GPIOs within the device tree. This allows the kernel to probe your hardware automatically and associate it with a driver.

Locate your board’s primary DTS file (e.g., imx8mn-at-kit.dts) or a relevant DTSI file. Add a new node like this:

&gpio1 { /* or whatever GPIO controller your pin belongs to */
    my_pulse_sensor: pulse_sensor {
        compatible = "my-company,pulse-counter";
        gpio-controller;
        #gpio-cells = <2>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_pulse>;
        status = "okay";
        interrupts = <GIC_SPI 23 IRQ_TYPE_EDGE_RISING>; /* Example for interrupt line */
        pulse-gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>; /* Example specific pin */
    };
};

&iomuxc_snvs_gpr { /* Or your board's specific pinctrl definition */
    pinctrl_gpio_pulse:
        pinctrl_gpio_pulse_grp {
            fsl,pins = <
                MX8MN_IOMUXC_SNVS_GPIO1_IO06__GPIO1_IO06  0x190
            >;
        };
};

After modifying the DTS, compile it into a new DTB (or rebuild the entire AOSP to incorporate it) and flash it to your device. Your kernel module can then look for the my-company,pulse-counter compatible string, abstracting the specific GPIO pin number.

Building, Deploying, and Testing Your Kernel Module

1. **Build**: Navigate to your module’s directory and run make. This will generate my_gpio_pulse_counter.ko.

2. **Deploy**: Push the module to your Android Things device:

adb push my_gpio_pulse_counter.ko /data/local/tmp/

3. **Load**: Connect via ADB shell and load the module:

adb shell
su
insmod /data/local/tmp/my_gpio_pulse_counter.ko

4. **Verify**: Check kernel messages and module status:

dmesg | grep "Pulse Counter"
lsmod | grep my_gpio_pulse_counter

5. **Test Sysfs**: Simulate pulses on GPIO 23 (e.g., by connecting it to VCC momentarily if it’s open collector, or another GPIO configured as output). Then read the count:

cat /sys/kernel/my_gpio_pulse_counter/pulses

You should see the pulse count incrementing.

Integrating with Android Userspace Application

Once your kernel module is functioning, an Android application can interact with it. For simple sysfs attributes, the app can read files directly using standard Java I/O streams from /sys/kernel/my_gpio_pulse_counter/pulses. For more complex interactions, you might expose a character device (/dev/my_sensor) and use JNI (Java Native Interface) to call native C/C++ code that performs ioctl operations on the device file.

Challenges and Advanced Considerations

• Real-time Capabilities: For extremely high-speed or time-critical industrial sensors, you might need a real-time Linux kernel (PREEMPT_RT patch set). While Android Things uses a mainline kernel, deep real-time guarantees often require specific kernel configurations and tuning.
• Power Management: Custom kernel modules must properly integrate with the device’s power management framework to ensure efficient sleep/wake cycles without losing sensor data or causing unexpected behavior.
• Security: Modifying the kernel directly introduces security risks. Ensure your kernel modules are secure, hardened, and only expose necessary functionalities.
• OTA Updates: Kernel modules must be compatible with the exact kernel version. Android Things OTA updates might update the kernel, potentially breaking compatibility with your custom modules. Plan for re-compilation and re-deployment strategies.
• Error Handling and Robustness: Industrial environments are harsh. Your driver needs robust error handling, self-correction mechanisms, and fault tolerance.

Conclusion

By venturing beyond the standard HAL and directly interacting with the Android Things kernel, you unlock a powerful capability for integrating complex and high-performance industrial sensors. Developing custom kernel modules and adapting the device tree provides granular control, enabling you to meet stringent industrial requirements for latency, data acquisition, and specialized hardware interaction. While this path demands a deeper understanding of Linux kernel internals and embedded systems, it’s essential for transforming Android Things into a truly versatile platform for advanced Industrial IoT applications.