Non-GMS vs nGMS vs GMS Firmware — Choosing the Right Android Build Before Hardware Ships
A system integrator completes a 200-device deployment across a municipal fleet. Three months later, the customer requests Google Play access for a new application. The integrator checks the firmware documentation and discovers that switching from the current Non-GMS build to a GMS-certified build requires a factory reset on every device. Two hundred tablets must be recalled from vehicles, wiped, reflashed, and redeployed. The firmware decision made six months earlier — before any hardware shipped — now costs four weeks of fleet downtime. Firmware type is a procurement decision, not an afterthought.

Field Observation
Firmware type is the specification most frequently omitted from hardware evaluation matrices — and the one most expensive to correct after deployment:
Firmware type rarely appears in the comparison spreadsheet
The gap surfaces when a customer requests an app that requires Google Play
At that point, the only path forward is a factory reset across the fleet
About the Author
TOPICON Hardware Engineering Team
Specialists in Android firmware architecture, GMS certification pathways, and OEM deployment planning for system integrators managing fleet device rollouts across regulated and commercial environments.
Three Firmware Types, Three Different Deployment Profiles
Android on a rugged tablet is not a single operating system. It is a base platform — Android Open Source Project — that can be assembled with or without Google's proprietary applications and certification. The three common configurations differ in what is preinstalled, how applications are updated, and whether the build carries Google's official compatibility certification.

Non-GMS: Maximum Control, Minimum Google Dependency
A Non-GMS build runs Android Open Source Project without Google Mobile Services. There is no Gmail, no Google Play Store, no Google Maps, no Google account framework. Applications are installed through the fleet's MDM platform or side-loaded from APK files distributed through the integrator's own infrastructure.
This configuration is specified in three environments. Government and defence deployments where Google services are prohibited by policy or network architecture. Industrial kiosk applications where the device runs a single customer-built app and nothing else. And fleets operating in network-restricted environments where Google's servers are unreachable or blocked.
The advantage is control. The integrator determines exactly what software runs on the device, when it updates, and where it connects. The MDM platform managing the fleet pushes configuration and applications without any dependency on Google's infrastructure. The trade-off is the absence of Google Play services — applications that depend on Google Play Services APIs will not function on a Non-GMS build, regardless of how they are installed.
nGMS: Google Applications Without CTS Certification
An nGMS build preinstalls the Google application suite — Gmail, Google Play Store, Google Maps, and the supporting framework — but does not carry Google's official CTS certification. The applications function normally. Google Play delivers updates. The device behaves like a consumer Android tablet for application management purposes.
The distinction is certification, not capability. CTS — the Compatibility Test Suite — is a Google-defined test battery that validates an Android build against the Android Compatibility Definition Document. Passing CTS means the device has been verified to behave consistently with the Android platform specification. An nGMS build has not been through this verification. It may pass some or all of the CTS test cases in practice, but Google has not issued certification.
For many commercial fleets, this distinction does not matter. A logistics operator running a proprietary dispatch application alongside Google Maps and Gmail has no certification requirement. The Android tablet platform for fleet applications delivers the Google ecosystem and the application update mechanism without the certification overhead. For customers whose contracts or regulatory frameworks require certified hardware, nGMS is not sufficient.
GMS: Official Certification and Its Constraints
A GMS build carries Google's official certification — the device has passed CTS testing and is permitted to preinstall Google Mobile Services under Google's licensing terms. This is the configuration specified by customers who require certified Android hardware: certain enterprise procurement frameworks, regulated industries, and deployments where a Google-certified device is a contractual requirement.
On the TOPICON platform, GMS-certified firmware is available for Android 14 (MDT865) and Android 16 (MDT880). The certification is version-specific — a GMS build certified for Android 14 does not automatically extend to Android 16. Each Android version upgrade requires a separate certification cycle.
The constraint that surprises most integrators is the security patch process. A GMS-certified build cannot be modified freely. Bug fixes, feature additions, and security patches that alter the system image must go through Google's Security Maintenance Release (SMR) process. The integrator cannot simply push a firmware update when a defect is discovered — the fix must be submitted, reviewed, and released through Google's certification pipeline. This preserves the integrity of the certification, but it removes the firmware update flexibility that Non-GMS and nGMS builds retain.
GMS Provisioning on TOPICON Rugged Tablets
Walk-through of the GMS firmware provisioning process on rugged Android tablets — applicable to certified fleet builds.
Firmware Switching: Why It Requires a Factory Reset
The three firmware types are not interchangeable through a simple update. Moving between Non-GMS and either GMS or nGMS — in either direction — requires a factory reset. The system partitions differ, the application framework differs, and the device storage must be reformatted to apply the new build.
This is not a technical limitation that can be engineered away. The Non-GMS build and the GMS build are structurally different operating system images. Applying one over the other without wiping the device would leave residual system components that conflict with the new build. Google's certification process specifically requires a clean installation for CTS validation.
For a deployed fleet, this means every affected device must be recalled from service, wiped, reflashed, re-enrolled in MDM, and redeployed. For a 200-device fleet, this is a four-week operation with associated vehicle downtime. The OEM firmware configuration decision must be finalised before hardware ships, because changing it afterwards carries a cost that no integration project budgets for.

Single Point of Failure
A firmware type that does not match the deployment's application requirements is a single point of failure that cannot be corrected without recalling every device. The device ships, installs, runs, and passes acceptance testing. The mismatch surfaces months later when the customer requests an application that requires Google Play Services, or when an audit requires CTS-certified hardware. At that point, the integrator faces a choice between recalling the fleet for a factory reset or delivering a solution the customer cannot use. Neither option is acceptable. The firmware decision is made at procurement — before a single unit leaves the factory — and it cannot be revisited without a full redeployment.
Selection Guide by Deployment Profile
Frequently Asked Questions
Can a Non-GMS device be upgraded to nGMS or GMS after deployment?
Yes, but it requires a factory reset. The system partitions differ between Non-GMS and the Google-integrated builds. The device must be wiped and reflashed with the new firmware image. For a deployed fleet, this means recalling each device from service, performing the reset and reflash, re-enrolling in MDM, and redeploying. The cost of this operation should be factored into the procurement decision if any possibility exists that Google Play access will be required later.
What does CTS certification actually verify?
CTS — the Compatibility Test Suite — validates that an Android build conforms to the Android Compatibility Definition Document. It tests API behaviour, hardware abstraction, security features, and application compatibility across thousands of test cases. Passing CTS means the device behaves consistently with the Android platform specification. For most commercial deployments this consistency matters little. For customers whose contracts require certified Android hardware, it is the determining factor.
Why does a GMS build require SMR approval for security patches?
GMS certification validates a specific firmware image. Any change to the system image — including security patches — invalidates that certification until the modified build passes validation again. Google's Security Maintenance Release process is the pathway for certified devices to receive patches without losing certification. The trade-off is that the integrator cannot push a fix on their own schedule. The patch must go through Google's review and release process, which affects the firmware update flexibility that Non-GMS and nGMS builds retain.
Does firmware type affect MDM functionality?
The core MDM capabilities — remote screen control, OTA updates, configuration sync, audit trails — function on all three firmware types through the TOPICON MDM platform. The difference is in how applications are distributed. Non-GMS builds require APK side-loading through MDM or the integrator's own distribution channel. nGMS and GMS builds can use Managed Google Play for silent application distribution in addition to MDM-based deployment.
Specifying Firmware for a Fleet Deployment? Decide Before Hardware Ships.
Non-GMS, nGMS, and GMS each serve a different deployment profile — and switching between them after deployment requires a factory reset across the fleet. Discuss your application requirements and certification needs before the firmware image is locked.
