July 2026 Summaries

Custom Android Open Source Project (AOSP) devices often include a vendor Over-The-Air (OTA) update client that device makers neither choose nor control, posing significant security and compliance risks. This inherited update mechanism, such as Rockchip's RKUpdateService, operates at the system level, allowing outbound traffic to vendor endpoints and accepting externally pushed code without the device team’s knowledge or consent. These default OTA clients are embedded in the System on Chip (SoC) vendor's reference builds and remain active unless explicitly removed, creating a potential unaudited entry point for unauthorized code. To mitigate this risk, organizations must take full ownership of the OTA update path by disabling the vendor's client and implementing a controlled update mechanism like Esper Airwave, which allows firmware updates through a governed channel without requiring Mobile Device Management (MDM) enrollment. This approach helps ensure compliance with regulatory frameworks that demand control over code delivery paths, an essential aspect often overlooked in security reviews that focus on application-level management rather than system-level infrastructure.

The challenge of installing an over-the-air (OTA) update agent on devices without an existing update mechanism is a significant logistical problem, as it involves establishing the OTA channel through alternative means. This constraint, often overlooked until deployment, requires that the agent be pre-installed via one of three methods: integrated into the firmware at the factory, delivered through an existing mobile device management (MDM) system, or manually sideloaded via USB. The most efficient and cost-effective approach is the first, baking the agent into the firmware before shipping. This preemptive step avoids costly manual interventions later, such as having technicians physically update each device. Esper Airwave addresses this by supporting all three installation paths and ensuring that the OTA agent is signed with the device owner's certificate, securing the update process against unauthorized access.

Android Enterprise and the Android Management API (AMAPI) rely on Google Mobile Services (GMS) for delivering firmware updates, which poses a challenge for custom AOSP and non-GMS devices that cannot utilize this managed-update path. This limitation affects various specialized hardware, such as kiosks and industrial devices, which often require custom AOSP builds for greater OS control. Esper's Airwave addresses this gap by enabling over-the-air (OTA) firmware updates without needing GMS, providing a delivery layer that manages device registration, package signing, approval gating, and targeted distribution to device groups. Airwave operates independently of Google services, making it capable of delivering signed OTA packages to any AOSP build with network connectivity, while adhering to cryptographic signing principles. However, it does not facilitate cross-major Android version upgrades unless a valid upgrade image is provided. This distinction highlights the separation between building and delivering updates, which is crucial for avoiding device issues like boot loops and bricked partitions. Airwave thus provides a vital solution for managing firmware deployment in non-GMS environments, distinguishing itself from traditional mobile device management systems that are bound by GMS dependencies.

In the context of Android firmware rollouts, sending a full Over-the-Air (OTA) update involves transferring the entire firmware image, typically 1 to 3 GB per device, which translates to extensive data usage—20 terabytes for 10,000 devices per update. This method, while simple, incurs significant bandwidth costs and network congestion, as often only a fraction of the firmware changes. Delta updates offer a more efficient alternative by transferring only the differences between the current and new builds, reducing data transfer by up to 90% for devices on recent versions. However, deltas are version-specific and require a system like Esper Airwave to automatically route each device to the appropriate update package, ensuring that the correct delta is applied or falling back on the full package if necessary. This automation alleviates the coordination burden, making delta updates feasible at fleet scale, leading to substantial bandwidth savings and more efficient rollouts.

Apple TVs are increasingly being used beyond consumer applications, serving as menu boards, lobby screens, and studio displays in commercial settings. This shift necessitates a robust management system to handle the lifecycle of these devices, as they need to be enrolled, configured, locked, updated, and recovered across numerous locations without physical interaction. Apple Business Manager (ABM) facilitates initial zero-touch enrollment, getting the devices online, but subsequent fleet management requires more comprehensive tools. Traditional Apple ecosystem management tools and signage CMS platforms fall short, as they are not designed for extensive Apple TV management. Esper emerges as a solution, treating Apple TV as a primary platform, alongside Android, iOS, Linux, and Windows, offering detailed configuration, app distribution, kiosk lockdown, OS-update control, and remote recovery. This approach ensures that Apple TVs are managed effectively at scale, without the need for physical interventions, making them reliable components of commercial digital signage infrastructure.

Apple TV and iPad both utilize Apple's Mobile Device Management (MDM) framework and Apple Business Manager (ABM) for device management, yet they diverge significantly in their management processes due to differing operational requirements. The primary differences lie in their enrollment paths, connectivity models, available MDM commands, and recovery options, which are tailored to their distinct uses: Apple TV is designed for static placement with ethernet connectivity and exclusive ABM enrollment, while iPad supports mobile use with Wi-Fi and cellular connections and offers additional enrollment paths such as QR code and Apple Configurator. Apple TV's management capabilities are more limited, lacking features like Lost Mode, Screen Lock, and Remote Viewer, which are available for iPad, and instead rely on factory reset and automatic re-enrollment for recovery. These differences necessitate unique configuration profiles for each device type, emphasizing that Apple TV management requires its own tailored approach rather than relying on iPad configurations.

Android Original Equipment Manufacturers (OEMs) face the challenge of delivering firmware updates efficiently and safely to their devices, which involves creating a comprehensive Over-The-Air (OTA) update system. This system requires six key infrastructure components: servers and backend, CDN distribution, cryptographic signing, staged rollout and rollback logic, per-device tracking, and a dedicated team for operations and maintenance. Building such an infrastructure in-house can divert engineering resources from core product development and may not offer a competitive advantage, as it is considered a standard expectation in the industry. Esper Airwave provides an alternative by offering a managed OTA solution that handles most of these components, allowing OEMs to focus on product development while ensuring secure and efficient firmware updates. The decision to build or buy OTA infrastructure depends on whether the OTA system is a core product offering or simply a necessary infrastructure that protects revenue without generating it.

An organization that standardized on Zebra scanners faced significant challenges when maintaining an in-house Android device management system, highlighting the complexities and costs associated with building versus buying such infrastructure. Initially, the team developed a custom provisioning layer for their 2,000 scanners as no available market solutions met their hardware needs. However, unforeseen issues arose following an Android upgrade that disrupted the system's configuration application without immediate detection, illustrating the long-term maintenance burden of in-house solutions. The article emphasizes that while building a custom system may appear cost-effective initially, ongoing maintenance costs, driven by frequent Android updates and OEM-specific variations, can quickly escalate, diverting valuable engineering resources from product development. The narrative argues that maintaining custom tooling becomes increasingly untenable as fleets grow in size and diversity, suggesting that purchasing a commercial platform that can adapt to OS changes might ultimately be more economical and reliable.