From the late 1990s through the 2010s, rugged handheld computers largely ran on Microsoft Windows CE. When the mainstream platform reached end-of-life in 2018, enterprises were forced to migrate. For most, Android, already gaining traction before CE shut down, was the clear option thanks to its openness, broad vendor support, and strong developer base. However, in 2025, buyers are still trying to replace CE’s decades of predictability in the Android era.

With CE, updates were infrequent and mostly opt-in. Android, built first as a consumer OS rather than an enterprise/rugged platform, runs at a constant cadence that creates an upgrade treadmill. Teams must repeatedly validate that all core apps, relevant device settings, and peripherals still function as expected. If replacement units arrive with a newer Android version that cannot be rolled back, it pressures organizations to update the entire fleet for parity. Android updates variably with frequent minor fixes plus an annual major release, putting teams in a near-permanent test cycle and with too little time to establish a stable, reliable baseline. Many buyers wish there was an Android Enterprise Long-Term Stable track, a consistent standard with schedulable patch windows that could be deferred as needed. Google instead emphasizes that regular patching is non-negotiable for avoiding large-scale breaches and points to extended support commitments (like 10-year update promises on leading consumer devices) as proof that fleets do not need to be frequently replacing hardware. Backporting fixes to older versions is limited, and Google argues that brittleness across versions is a universal OS problem, not unique to Android. In the absence of a formal long-term enterprise track, a common best practice is to keep a small set of “N+1 devices” at each site to trial the latest OS and package versions before broad rollout, reducing the risk of bad update surprises.

Android has made real strides on security, which was previously a significant concern for enterprises. With longer device support and stronger built-in protection, the OS has never looked better for enterprise use on paper. In practice, satisfaction still lags because enterprise environments value reliability above all. Recent security hardening, such as stricter Play Protect behavior, amplifies operational risks when legacy, essential line-of-business apps are blocked, removed, or broken by policy changes. Frontline workers cannot afford downtime when a device stops scanning or a login screen fails mid-shift. Security matters, but it becomes moot when devices fail after updates or approved apps disappear without warning.

The Android Team acknowledges this friction. Play Protect can be disabled entirely (though Google discourages this), target API waivers and special permissions are available for legacy or in-house apps through Managed Google Play, and they argue that similar disruptions occurred in past Windows transitions (i.e., XP to 7). OEM programs such as Zebra’s Lifeguard extend patch availability and attempt to cushion these transitions. As a result, CISOs now make many of these decisions and teams must deal with the impact when security-first changes collide with fragile but business-critical apps.

Across rugged and dedicated enterprise devices, deployments are consolidating on Google Mobile Services (GMS). While the Android Open Source Project (AOSP) is the open-source base of Android, GMS is Google’s proprietary layer of mobile services and Google Play Services. Google positions the shift toward GMS as a tradeoff. Enterprises give up some AOSP flexibility in exchange for consistent behavior across OEMs such as Zebra, Honeywell, and Samsung. OEMs can still ship AOSP-only devices, but doing so forfeits services like Google Play, push infrastructure, Play Protect, and newer AI capabilities. Closed forks such as Fire OS (Amazon) or Quest OS (Meta) can succeed because they own the entire stack and app catalog, but they are poor fits for ISV ecosystems. In March 2025, Google also tightened control over how AOSP components update and how deviations from upstream source code are handled (even though AOSP remains open). Practically, this raises the risk and lowers the supportability of “AOSP-only” paths and pushes fleets further toward GMS.

The tradeoff with GMS is its restrictions on running custom software. Consumer-focused protections can collide with corporate deployments. Google Play Protect, as the built-in malware and risk-scanning system, can automatically block or remove apps it deems risky. On corporate devices, unilateral removals can take down critical workflows. Many line-of-business apps are old but essential, and there may be no vendor available to modernize them. Operations leaders therefore want a consent model that surfaces risk but requires approval before removing an approved app. Few want to walk away from GMS entirely, most simply want control over what GMS does and when. Despite Android’s tightened security posture and extended software support, frontline operations still face significant friction. The winners in 2026 will be the companies that turn a consumer-oriented secure-by-default stance into reliability and control that enterprise teams can plan around.