Introduction to AOSP OTA for IoT Devices

Over-The-Air (OTA) updates are a critical component for the long-term maintainability and security of any connected device, especially those powered by Android Open Source Project (AOSP) in the Internet of Things (IoT) space. Whether it’s a smart display, an automotive infotainment system, or an industrial control panel, the ability to reliably deliver system updates ensures devices remain secure, functional, and equipped with the latest features without requiring physical intervention. This guide provides a comprehensive, step-by-step walkthrough for creating your first AOSP OTA update package, covering both full and incremental updates.

Understanding the AOSP update mechanism is crucial for device manufacturers and developers. It allows for custom modifications, security patches, and feature enhancements to be deployed efficiently across a fleet of devices. We’ll delve into setting up your build environment, generating different types of OTA packages, signing them for authenticity, and finally, deploying and verifying the update on a target AOSP-based IoT device.

Prerequisites for AOSP OTA Development

Before embarking on your AOSP OTA journey, ensure you have the following prerequisites in place:

• A powerful Linux workstation: Ubuntu 18.04 LTS or newer is recommended, with at least 16GB RAM (32GB+ preferred) and 200GB+ free disk space (SSD highly recommended).
• AOSP source code: Synchronized for your target IoT device or a generic AOSP branch (e.g., android-10.0.0_rXX) that you intend to modify.
• Basic Linux command-line proficiency: Familiarity with shell commands, file system navigation, and text editors.
• Understanding of Android build system: Knowledge of lunch, make, and common build targets.
• ADB and Fastboot tools: Installed and configured on your workstation.
• Target AOSP-based IoT device: A physical device (or emulator, though physical is better for OTA testing) running your base AOSP image.

Setting Up Your AOSP Build Environment

The first step is to ensure your AOSP build environment is correctly set up. If you already have a working AOSP build for your device, you can skip to the next section. Otherwise, follow these steps:

1. Synchronize AOSP Source Code

Initialize and synchronize the AOSP repository. Replace <branch_name> with your desired AOSP branch (e.g., android-10.0.0_r41).

mkdir AOSP_OTA_Workspacecd AOSP_OTA_Workspace/repo init -u https://android.googlesource.com/platform/manifest -b <branch_name>repo sync -j$(nproc)

2. Build Initial AOSP Image for Your Device

Once the source is synchronized, set up the build environment and select your target device’s configuration. The lunch command presents a list of available build targets. Choose the one that corresponds to your IoT device (e.g., aosp_arm64-userdebug for a generic 64-bit ARM AOSP device).

source build/envsetup.shlunch <target_product>-<target_variant> # e.g., lunch aosp_arm64-userdebug

Now, build the full AOSP image. This process can take several hours depending on your hardware.

make -j$(nproc)

After a successful build, your initial system images (system.img, boot.img, etc.) will be located in out/target/product/<device_name>/. Flash this image onto your target IoT device using fastboot.

adb reboot bootloaderfastboot flash boot out/target/product/<device_name>/boot.imgfastboot flash system out/target/product/<device_name>/system.imgfastboot reboot

Understanding OTA Package Types

There are primarily two types of OTA update packages in AOSP:

• Full OTA Package: Contains the entire system image. It can be applied regardless of the device’s current software version. These packages are larger but simpler to manage from a client perspective.
• Incremental OTA Package: Contains only the differences between a base build (the source) and a new build (the target). These are significantly smaller and more efficient for bandwidth-constrained environments but can only be applied if the device is running the exact source build specified in the package.

For your first OTA, we will generate a full package, then demonstrate an incremental one.

Generating a Full OTA Package

To create an update, you first need to make a change in your AOSP source code. For this example, let’s modify a simple system property.

1. Make a Minor Code Change

Edit a file, for instance, build/core/version_defaults.mk, to increment a build number or add a custom property. This change will serve as the differentiator for our new OTA.

# Example: Modify a version string in build/core/version_defaults.mkPRODUCT_VERSION_MAJOR := 10PRODUCT_VERSION_MINOR := 0PRODUCT_VERSION_MAINTENANCE := 0PRODUCT_VERSION_TAGS := "custom_iot_v1.1" # Original was custom_iot_v1.0

Alternatively, you could add a new file to `/system/etc/` or modify an existing `init.rc` script.

2. Build the OTA Package

After making your changes, rebuild the AOSP project. This time, instead of just make, we’ll use the otapackage target which automatically generates a full OTA zip file.

source build/envsetup.shlunch <target_product>-<target_variant>make -j$(nproc) otapackage

Upon successful completion, the full OTA package (e.g., aosp_arm64-ota-eng.<user>.zip) will be located in out/target/product/<device_name>/. This ZIP file is your full OTA update.

Generating an Incremental OTA Package

Incremental OTAs require two distinct builds: the original (source) and the new (target). The key is to generate target_files for both.

1. Generate Target Files for the Base Build

First, ensure you have your *original* AOSP source code checked out (the one your device is currently running). Then, build its `target_files` package.

source build/envsetup.shlunch <target_product>-<target_variant>make -j$(nproc) target-files-package

The output will be a ZIP file named like <device_name>-target_files-<build_id>.zip in out/target/product/<device_name>/. Rename this to something like base_target_files.zip for clarity.

2. Generate Target Files for the New Build

Now, make your desired changes in the AOSP source (e.g., another small change to version_defaults.mk or a new app). Rebuild the target-files-package.

# Make new code changes here...source build/envsetup.shlunch <target_product>-<target_variant>make -j$(nproc) target-files-package

Rename this new output ZIP to new_target_files.zip.

3. Create the Incremental OTA

Use the ota_from_target_files script to generate the incremental update.

build/make/tools/releasetools/ota_from_target_files -i <path_to_base_target_files.zip> <path_to_new_target_files.zip> <output_incremental_ota_file.zip>

Example:

build/make/tools/releasetools/ota_from_target_files -i out/target/product/<device_name>/base_target_files.zip out/target/product/<device_name>/new_target_files.zip out/target/product/<device_name>/incremental_update.zip

This command generates a small ZIP file containing only the deltas between the two builds.

Signing Your OTA Package

All AOSP OTA packages must be cryptographically signed to be accepted by the device’s recovery system. For development and testing, AOSP provides default test keys. For production, you must generate and use your own secure keys.

Using Test Keys (Development)

The otapackage and ota_from_target_files commands automatically sign the output with AOSP’s built-in test keys if not specified otherwise. For production, you would pass your own `key` arguments to the `ota_from_target_files` script.

Generating Production Keys (Critical for Release)

You should generate a set of production keys using the make_key script:

build/tools/create_product_keys/make_key <path_to_keys_dir>/releasekeybuild/tools/create_product_keys/make_key <path_to_keys_dir>/platformbuild/tools/create_product_keys/make_key <path_to_keys_dir>/sharedbuild/tools/create_product_keys/make_key <path_to_keys_dir>/mediabuild/tools/create_product_keys/make_key <path_to_keys_dir>/verity

Then, configure your product to use these keys in your device’s BoardConfig.mk or equivalent configuration files, or pass them directly to the `ota_from_target_files` script using the `-k` option.

Deploying and Testing the OTA

Once you have a signed OTA package (either full or incremental), it’s time to test it on your IoT device.

1. Sideloading via ADB

The simplest way to apply an OTA during development is via ADB sideload.

• Boot your AOSP device into recovery mode. This often involves holding specific hardware buttons during boot or using adb reboot recovery.
• In recovery, select the option to apply update from ADB.
• On your host machine, execute:

adb sideload <path_to_your_ota_package>.zip

The device will then verify the package signature and apply the update. After reboot, verify your changes.

2. Verification

After the update, ensure your changes are reflected on the device. For our example: navigate to Settings -> About device, or use adb shell getprop to check the modified system property.

adb shell getprop ro.build.tags

Confirm it shows custom_iot_v1.1 (or your corresponding modification).

Best Practices and Considerations

• Robust Rollback Strategy: Always have a plan for rolling back to a previous stable version in case an update causes critical issues. Dual A/B partitions (seamless updates) greatly simplify this, but require specific hardware and AOSP configuration.
• Network Conditions: For large fleets, consider network bandwidth and latency. Incremental OTAs are often preferred. Implement robust download and verification mechanisms on the device.
• Security: Never use test keys for production devices. Keep your production signing keys extremely secure. Revoke compromised keys immediately.
• User Experience: Provide clear communication to users about updates. Minimize downtime.
• Testing: Rigorously test OTAs on a small subset of devices before a full rollout.

Conclusion

Building your first AOSP OTA package is a foundational skill for any developer or manufacturer working with Android-based IoT devices. By following this detailed guide, you’ve learned to set up your environment, differentiate between full and incremental updates, generate signed packages, and deploy them to your target device. Mastering this process is key to delivering secure, feature-rich, and maintainable IoT products in a rapidly evolving technological landscape.