Introduction

Over-The-Air (OTA) updates are a critical component of any successful Android Open Source Project (AOSP) based Internet of Things (IoT) deployment. While standard AOSP OTA mechanisms provide a robust foundation, unique IoT device requirements often demand a deeper level of customization. This article delves into advanced OTA scripting techniques and customizations for AOSP, moving beyond simple package installations to address complex scenarios like conditional updates, device-specific configurations, and integration with proprietary hardware or services.

Understanding AOSP OTA Fundamentals

Before diving into advanced topics, a quick recap of standard AOSP OTA is essential. AOSP utilizes block-based updates (since Android 5.0) and A/B (seamless) updates (since Android 7.0) to ensure system integrity and a robust update experience. The core components involved are:

• update_engine: For A/B updates, this daemon manages the update process, including downloading, verifying, and applying updates to the inactive partition.
• updater-script: Used primarily for non-A/B or recovery-based updates, this script defines the installation steps executed by the recovery system. Even with A/B, understanding its syntax is beneficial for custom post-update actions.
• Update Package (`.zip`): Contains the updated system images, metadata, and the updater-script.

Our focus will primarily be on extending the capabilities offered by these components, especially through sophisticated updater-script logic and update_engine configuration.

Advanced updater-script Techniques

The updater-script (found in META-INF/com/google/android/updater-script) offers powerful primitives for conditional logic and file system operations. While A/B updates minimize its role in core system image flashing, it’s invaluable for custom post-installations.

1. Conditional Updates and Device Specificity

IoT ecosystems often involve multiple device variants or specific hardware configurations. updater-script allows for conditional execution based on device properties.

# Example: Update specific to a device model or software versionassert(getprop("ro.product.device") == "my_iot_device" || abort("This package is for my_iot_device."));assert(getprop("ro.build.version.sdk") == "29" || abort("Requires Android 10 (SDK 29) or higher."));# Custom action for a specific hardware revisionif getprop("ro.hardware.revision") == "v2.0" then  ui_print("Applying v2.0 hardware optimizations...");  # Perform v2.0 specific configurations  run_program("/system/bin/sh", "-c", "echo 'hardware.v2_optimized=true' >> /system/etc/custom.conf");endif;

This snippet demonstrates how to check device properties like ro.product.device and ro.build.version.sdk, aborting the update if conditions are not met. It also shows a conditional execution block based on a custom hardware revision property.

2. Custom Pre/Post-Install Actions

Beyond flashing images, advanced scenarios require modifying system properties, installing proprietary applications, or performing data migrations.

• Modifying System Properties: Update crucial system properties before the next boot.

# Example: Set a custom boot property for a kiosk mode setupset_perm(0, 0, 0755, "/system/etc/init/custom_kiosk.rc");# Modify a service configurationrun_program("/system/bin/sh", "-c", "sed -i 's/SOME_VAR=.*/SOME_VAR=NEW_VALUE/' /system/etc/myservice.conf");

• Installing Third-Party Applications: Integrate a custom application directly into the system or data partition.

# Example: Push a custom APK to /data/app (user installable) or /system/priv-app (privileged)package_extract_file("system/priv-app/MyProprietaryApp/MyProprietaryApp.apk", "/system/priv-app/MyProprietaryApp/MyProprietaryApp.apk");set_perm_recursive(0, 0, 0755, 0644, "/system/priv-app/MyProprietaryApp");# Or for a data partition app (will be installed on first boot)package_extract_file("data/preinstall/MyApp.apk", "/data/preinstall/MyApp.apk");

• Data Migration and Cleanup: Essential for maintaining application state or removing deprecated files.

# Example: Migrate old configuration filesif file_exists("/data/misc/old_config.xml") then  run_program("/system/bin/mv", "/data/misc/old_config.xml", "/data/misc/new_config.xml");endif;# Cleanup temporary files or logsdelete("/data/local/tmp/update_logs.zip");

3. Integrating with External Services (Reporting)

For robust fleet management, devices should report update status (success/failure) to a central server. This can be achieved by launching a custom service or using `curl` if available in the recovery image (less common).

# Example: Trigger a post-update script that reports statusrun_program("/system/bin/sh", "-c", "/system/bin/custom_post_update_reporter.sh &");# The custom_post_update_reporter.sh script (bundled in the update.zip and extracted)  # might contain:  # #!/system/bin/sh  # sleep 30 # Give system a chance to boot  # /system/bin/curl -X POST -d "device_id=$(getprop ro.serialno)&status=success" https://myiotplatform.com/update_status

Customizing the update_engine (A/B Updates)

For A/B devices, update_engine is the core. Its behavior can be customized through build configurations and runtime parameters, particularly for IoT scenarios where network conditions or power constraints are critical.

• Modifying Update Policies: The default policies often need adjustment. You can define custom update conditions (e.g., only update on Wi-Fi, during specific hours, or when battery is above a certain threshold) by modifying the update_engine source code or by integrating a custom update client that calls update_engine with specific flags.

// Example (conceptual C++ snippet in a custom update client interacting with update_engine)update_engine::UpdateAttemptFlags flags = update_engine::UpdateAttemptFlags::kNone;if (!isWifiConnected() || batteryLevel < 50) {  flags |= update_engine::UpdateAttemptFlags::kOfflineUpdate;}if (isOffPeakHours()) {  flags |= update_engine::UpdateAttemptFlags::kDeferredUpdate;}  // Call update_engine D-Bus API with these flags

• Customizing Update Progress Reporting: The update_engine provides D-Bus interfaces to monitor update progress. For IoT, integrating this with a custom UI or a cloud reporting mechanism is crucial.

# Conceptual D-Bus interaction to get update status (from a shell script or custom service)gdbus call --system --dest org.chromium.UpdateEngine --object-path /org/chromium/UpdateEngine --method org.chromium.UpdateEngine.GetStatus

Secure Over-The-Air (SOTA) Considerations

Security is paramount for IoT devices. Advanced OTA ensures not just functionality but also integrity and authenticity.

• Signing Updates: Always sign your update packages with production release keys. Never use test keys in production environments. The AOSP build system handles this when you specify the correct signing keys in your product’s device tree.

# Build command with release keysmake otapackage -k path/to/your/releasekey_folder

• Encryption of Update Packages: While AOSP OTA does not natively encrypt the update ZIP itself, the download channel should always be secured (HTTPS). For ultimate confidentiality, you might implement client-side decryption of an inner payload within the update ZIP, using device-specific keys.
• Rollback Prevention: Implement anti-rollback mechanisms to prevent devices from booting into older, vulnerable software versions. This is primarily handled by Android Verified Boot (AVB) and setting appropriate anti-rollback versions in your bootloader and system partitions.

Practical Example: Custom Post-Update Kiosk Mode Configuration

Let’s walk through a scenario where, after a core AOSP update, we need to:

1. Install a proprietary Kiosk application.
2. Set a custom system property to enable Kiosk mode on first boot.
3. Clean up temporary update files.

Step 1: Prepare your Update Package

Inside your AOSP source tree, place your Kiosk APK in a custom folder (e.g., device/mycompany/mydevice/ota_files/kiosk/MyKioskApp.apk). Edit your device.mk to include this file:

# device/mycompany/mydevice/device.mkPRODUCT_COPY_FILES +=     device/mycompany/mydevice/ota_files/kiosk/MyKioskApp.apk:system/priv-app/MyKioskApp/MyKioskApp.apk

Step 2: Create a Custom updater-script Snippet

You’ll typically modify the auto-generated updater-script during the OTA package generation process, or provide your own post-install script that gets called. For simplicity, assume we inject this into the main script:

# ... standard update_engine apply_patch_update calls ...ui_print("Installing custom Kiosk application...");package_extract_file("system/priv-app/MyKioskApp/MyKioskApp.apk", "/system/priv-app/MyKioskApp/MyKioskApp.apk");set_perm_recursive(0, 0, 0755, 0644, "/system/priv-app/MyKioskApp");ui_print("Setting Kiosk mode property...");# This command writes to the system property service which will persist across rebootsrun_program("/system/bin/setprop", "persist.mycompany.kiosk_mode", "enabled");ui_print("Cleaning up temporary update files...");delete("/data/local/tmp/update_cache/*");

This script first ensures the application binary is in place with correct permissions, then uses the setprop utility (if available in recovery, or more reliably, a script launched on first boot) to persist a custom property. Finally, it cleans up a hypothetical cache.

Step 3: Build the OTA Package

. build/envsetup.shlunch my_iot_device-userengmake otapackage

The resulting .zip package will contain your custom application and the modified updater-script logic.

Conclusion

Advanced AOSP OTA scripting and customization are indispensable for delivering robust, secure, and feature-rich updates to IoT devices with unique requirements. By leveraging conditional logic in updater-script, customizing update_engine behavior, and adhering to stringent security practices, developers can create highly tailored update solutions. This ensures not only the longevity and stability of IoT deployments but also provides a flexible framework for future feature enhancements and critical security patches, keeping your fleet updated and secure in the field.