Introduction: The Criticality of Optimization in Embedded Android Things

Android Things, Google’s embedded operating system built on Android, offers a robust platform for IoT devices. However, for specialized embedded systems like those in automotive, industrial control, or smart appliances, every kilobyte of storage and every millisecond of boot time can be critical. A lean, fast-booting OS image enhances user experience, reduces power consumption, extends hardware lifespan, and often minimizes manufacturing costs by allowing the use of less expensive eMMC or flash storage. This guide delves into expert-level techniques for customizing the Android Things OS, focusing on optimizing image size and boot performance.

Understanding the Android Things AOSP Build Process

At its core, Android Things leverages the Android Open Source Project (AOSP). Customizing Android Things means engaging with the AOSP build system. This involves selecting appropriate device targets, configuring the kernel, modifying system components, and ultimately building a flashable image. The process typically starts with syncing the AOSP source code, choosing a target board (like an i.MX or Raspberry Pi 3/4 based Android Things board support package), and then systematically paring down or optimizing components.

# Initialize AOSP repository toolsync repo init -u https://android.googlesource.com/platform/manifest -b android-things-1.0_r2# Sync the source coderepo sync -j8

Key Areas for Image Size and Boot Time Optimization

1. Kernel Configuration (Defconfig Hacking)

The Linux kernel is the foundation of Android. A stock kernel often includes drivers and features unnecessary for a specific embedded device. Modifying the defconfig file for your target board allows you to strip out unwanted modules, reducing both kernel image size and initialization overhead. This requires a deep understanding of your hardware and its peripherals.

• Example: Removing USB host support if only device mode is used.
• Example: Disabling filesystem support (e.g., ext3, JFS) not used by your rootfs.

Navigate to your kernel source (e.g., kernel/msm or kernel/imx) and find the appropriate defconfig. You can then use make menuconfig to interactively deselect features or directly edit the .config file generated by a previous build. After making changes, rebuild the kernel.

# Example: Entering kernel config for a specific boardcd kernel/your_board_kernel_sourceARCH=arm64 CROSS_COMPILE=aarch64-linux-android- make your_board_defconfigARCH=arm64 CROSS_COMPILE=aarch64-linux-android- make menuconfig# Make changes, save, then buildkernelARCH=arm64 CROSS_COMPILE=aarch64-linux-android- make -j8

2. Device Tree Overlays (DTO) and Board Configuration

Device trees (DT) describe the hardware components to the kernel. While not directly reducing image size, an optimized DTO ensures the kernel only initializes relevant hardware, preventing unnecessary probes and speeding up boot. For custom boards, creating a minimalistic DTO is crucial.

3. Stripping Unused AOSP Modules and Apps

Android Things, even in its optimized form, can contain components not essential for your single-purpose device. This includes system services, pre-installed apps, and even entire framework modules. Identifying and removing these is a primary source of size reduction.

• Removing AOSP Apps: Edit the device’s product.mk or device.mk file. Look for variables like PRODUCT_PACKAGES and remove unnecessary entries.
• Disabling System Services: This is more advanced and requires modifying build flags or initialization scripts. For instance, if you don’t use Wi-Fi, you might disable related services.

# Example snippet from device/your-vendor/your-device/device.mk# Comment out or remove packages not neededPRODUCT_PACKAGES +=     Settings     QuickSearchBox #    Gallery2 #    Email #    Browser2

Careful analysis of dependencies is required to avoid breaking core functionalities. Start with obvious candidates like web browsers, email clients, or gallery apps if your device has no display or dedicated UI.

4. Bootloader Optimization (U-Boot/Little Kernel)

The bootloader (e.g., U-Boot, Little Kernel) is the first piece of software to run. Optimizing it can shave precious seconds off boot time. This involves:

• Removing Unused Features: Stripping out drivers for interfaces not present on your board (e.g., SATA, SCSI, extra USB controllers).
• Minimizing Delays: Reducing default boot delays or splash screen durations.
• Fastboot Integration: Ensure a highly optimized fastboot implementation to speed up initial system loading.

Modifications typically involve editing the bootloader’s source code and rebuilding it. This is platform-specific and requires expertise in the chosen bootloader.

5. Filesystem Selection and Compression

The choice of filesystem for your root partition and user data can impact both size and performance.

• Squashfs: For read-only partitions (like /system), Squashfs offers excellent compression and minimal overhead, significantly reducing image size. However, it’s read-only.
• F2FS (Flash-Friendly File System): For writable partitions, F2FS is optimized for NAND flash memory, offering better performance and longevity compared to traditional ext4 in many embedded scenarios.

To use Squashfs for /system, you might need to adjust your BoardConfig.mk or device makefiles to specify the filesystem type for partitions. Android Things typically uses ext4 for /system by default, so this would be a significant change.

6. Dalvik/ART Runtime Optimization

Android uses the ART (Android Runtime) to execute app code. Pre-compilation (AOT) and profile-guided optimization (PGO) are key to application launch speed. While Android Things typically uses AOT during the build process, ensuring all critical system apps are fully optimized is vital. During the build, ART pre-compiles applications into native code. Ensuring this process is thorough for all critical system components minimizes runtime overhead.

Step-by-Step Optimization Workflow (Illustrative)

1. Set up AOSP Environment: Follow official Android Things documentation to sync the source code and prepare your build environment.
2. Target Selection: Choose the appropriate target for your board (e.g., aosp_rpi3_atv for Raspberry Pi 3).
3. Kernel Customization:
   1. Navigate to your kernel source directory.
   2. make your_board_defconfig
   3. make menuconfig to open the configuration editor.
   4. Deselect unnecessary drivers and features. Save and exit.
   5. Build the kernel: make -j$(nproc)
4. Device Configuration Tweaks:
   1. Edit device/your-vendor/your-device/device.mk or product.mk.
   2. Remove unwanted entries from PRODUCT_PACKAGES.
   3. Review and disable any unnecessary services or features through build flags or init scripts (advanced).
5. Build the Image:

   . build/envsetup.shlunch aosp_your_board_target-userdebugmake -j$(nproc)

6. Flash and Test: Flash your custom image to the device using fastboot or a board-specific flashing tool.
7. Measure and Iterate: Measure boot time and image size. Repeat the process, incrementally optimizing until desired targets are met.

Measuring the Impact

After each optimization, it’s crucial to measure the actual impact. Use tools like:

• du -sh <image_file>: To check image size.
• Boot logs (dmesg, logcat): Analyze boot stages and identify bottlenecks.
• Boot time analysis tools: Many bootloaders provide timing information. Custom scripts can parse kernel logs to pinpoint initialization durations of various services.

Conclusion

Optimizing Android Things OS image size and boot time is a meticulous, iterative process that demands a deep understanding of AOSP, kernel internals, and embedded system design. By systematically stripping unnecessary components, fine-tuning kernel configurations, and optimizing bootloader and filesystem choices, developers can significantly enhance the performance and efficiency of their Android Things-powered embedded devices. These performance hacks not only lead to a snappier, more responsive user experience but also contribute to lower manufacturing costs and extended device longevity, making your IoT solution more competitive and robust.