GMS vs. Non-GMS for Android Devices

When it comes to Android, not all versions of the operating system are the same — far from it, in fact. One of the defining differences is the way in which the OS is built: does it use Google Mobile Services (GMS) or is it a pure AOSP device? There’s a big difference between the two, and one may be better than the other depending on what you’re trying to do.

What is GMS?

GMS stands for Google Mobile Services. It's a bundle of applications and services built by Google that comes pre-installed on GMS-certified Android devices. GMS is not part of the Android Open Source Project (AOSP), which means device manufacturers need to be licensed to pre-install the GMS bundle on devices. 

The GMS bundle varies a bit by region, but typically includes apps like:

• Google Chrome
• Google Search
• YouTube
• Google PlayStore
• Gmail
• Google Drive
• Google Duo
• Google Maps
• Google Photos
• Google Play Music
• Google Play Speech

In addition, specific packages from Google are available only on GMS-certified devices. Many mainstream Android applications are dependent on GMS package capabilities like SafetyNet APIs, Firebase Cloud Messaging (FCM), or Crashlytics. If you have an app with GMS dependencies, switching to non-GMS Android requires some planning — but it's far from impossible.

Google makes APIs available for many of its services on Windows and macOS via the browser or standalone app support, making integration achievable for non-GMS Android devices. For example, using the Google Drive API, you can integrate Drive directly into your Android app without any reliance on GMS. You can also implement programmatic access to Gmail using the Gmail API.

While there are real benefits for app developers working with GMS devices (like lowering development time and potentially delivering superior experiences), you can still access many of these services using Google's own programmatic APIs.

Consumer Android vs. dedicated Android devices

If you’re considering a device from a major Android manufacturer (often referred to as an OEM), you’ll benefit from the rigor applied to shipping a product sold to potentially millions of users. But the lifespan of these consumer products is typically shorter than dedicated device solutions, requiring the solution owner to switch to a new model on a frequent basis — typically yearly.

GMS Certification and Android Versions

But what if you aren't a major OEM, or aren't working with one? That's where the real challenges start. To become GMS certified, a device must run on either the current or next-most current version of Android (i.e., if Android 12 is the current release of Android, you could submit a device running Android 11 and still receive GMS certification — but not one running Android 10). This requirement also applies to firmware updates: if your manufacturer issues a new firmware update that puts your device two releases behind the current Android version, you can't GMS certify that device on the new firmware.

And there are other roadblocks to consider. GMS certification adds to both cost (to pay for the testing process and the resources required to support it) and timeline (the process typically takes months). And, as we established, any changes to your firmware will require recertification for GMS. This significantly raises the bar to build and roll out firmware updates for GMS devices.

Device Maker Updates and GMS

Choosing GMS hardware also means you'll be at the mercy of the manufacturer when system updates are pushed — including moving to new major releases of Android. There have been many changes in Android impacting single-purpose device use cases over the years, and because of Android's annual development cycle, more such changes will always be at most a year away. Once your devices start receiving a system update from the manufacturer via firmware over-the-air (FOTA), you're often powerless to pause the rollout or opt out. Some OEMs provide robust system update management for GMS devices, but they’re the exception.

As Android progresses to new versions and OEMs move on to new product models, those updates will stop, often after two or three years. This is also dependent on how each OEM handles preparing and passing through updates from Google. But the key is that — eventually — GMS devices become stable firmware images. We’ve seen customers use this in two ways.

The first is to standardize on a new or recently available GMS device and deal with the update cycle until it finishes — riding the wave.

The second is to purposely choose an older device that's firmware-stable, but can still be obtained in the open market (typically, at lower prices).

The latter approach has real disadvantages: Security updates are no longer delivered for these devices, and available inventory (and spare parts) will become scarce after the manufacturer stops producing new units. But this approach can be viable for some use cases.

How Android devices get certified

We've established that Android is open source, while GMS isn’t. Manufacturers obtain a GMS license— known as a MADA (Mobile Application Distribution Agreement) — from Google, and then are required to pass a series of tests:

1. Compatibility Test Suite (CTS)
2. Compatibility Test Suite Verifier (CTS Verifier)
3. CTS Audio Quality Test Suite (CAT)
4. GMS Test Suite (GTS)

Obtaining GMS certifications creates an agreement between the manufacturer and Google. GMS devices are pre-loaded with Play Store apps, and they’re subject to Google’s policies for privacy, including the GMS agreements for privacy, data collection, and device updates. 

GMS certification also isn’t available for every type of device. For example, Android for exercise equipment and medical devices are pretty standard use cases out in the real world. Still, they're not a core focus of Google's business, and thus they face an uncertain and expensive road to obtaining GMS certification.

Pros of GMS-certified dedicated Android devices

There are no universal pros for every single-purpose device. However, these GMS features could be beneficial depending on what your device is doing.

1. Generally, GMS smartphones and tablets are loaded with the latest version of Android or the preceding release
2. Monthly security patch updates (though in reality, this varies)
3. Google Play Store access that can be controlled by an EMM, including Esper
4. Frequently-used APIs like location services
5. Google user authentication
6. Android Enterprise support is included specifically for working with management platforms such as Esper
7. Certainty of both the robustness and composition of the firmware image based on having to complete the GMS process

FOTA updates to GMS-certified devices can be a pro or con depending on your particular use case. Access to updates depends on the OEM and device maker to prepare the firmware and push it through. Understanding an OEM’s approach to updates is a key part of due diligence when you’re sourcing any Android device, GMS certified or not.

Google is also quite stringent about enforcing security patch updates on GMS-certified devices, which are released every month by Google. With some exceptions for holidays and other blackout periods, security updates must be applied within 30 days. This requirement doesn’t apply to non-GMS devices.

Cons of GMS-Certified Devices

1. Devices are subject to Google’s Privacy and Terms of Use
2. Pre-loaded apps use up available RAM and ROM
3. Uncertain support for non-standard Android devices
4. No support for Android versions other than 9 or 10
5. Logistical limits to rapid deployment, staging, and provisioning
6. Limitations on-device policy and security configurations (like Google Play Protect)

Also, when you pre-install GMS-certified devices with the apps and services, some data is used. How much data is hard to estimate and varies, depending on your network, data saver settings, and enabled GMS Android apps. Esper provides the capability to disable in-ROM apps completely, thus removing this as an issue for Esper customers.

How Does Non-GMS AOSP Android Stack Up?

AOSP is a great option for single or limited-use case solutions. If you own or control the APKs used for your solution, Esper offers everything you need to manage app updates and versions to your AOSP device fleet. Furthermore, you benefit from Android’s gargantuan developer ecosystem bringing millions of Android developers into the fold. The mainstream knowledge of Android programming greatly benefits companies creating single-purpose solutions on AOSP. It also means all the technology investments made by industry technology players to support Android are available for AOSP as well, including AWS, Azure, and GCP.

However, for third-party APKs, this can introduce challenges. Customers have to be diligent on obtaining third-party APKs for inclusion into AOSP devices—some of these APKs may have malware in them or violate the terms for the APK based on taking them from the Google Play store. Additionally, the app providers can change the usage terms on the fly, as recently happened with Netflix. While Netflix is not making it entirely clear that their app will no longer work on AOSP devices (versus rooted Android devices), it does mean customers with AOSP devices in their fleet will have to figure it out.

All non-GMS-certified devices are considered AOSP. This is a huge spectrum, especially when you consider the fact that GMS certification literally extends to “standard” Android devices in the US market. One well-known uncertified AOSP is the Amazon Kindle. With AOSP, you can work with the Asia ODM ecosystem to create your own device completely dialed in for your use case across industrial design (ID), mechanical engineering (ME), and firmware including in-ROM apps and Android system behavior. Additionally, many off-the-shelf designs can be quickly tailored to your needs at economical pricing.

However, comparing security and stability between GMS and non-GMS devices for single-purpose Android device fleets depends enormously on where you’re sourcing your device.

• Are you targeting the creation of purpose-built devices for a very specific use case requiring design targets across ID, ME, and firmware?
• Do you have a specific economic envelope based on bill-of-materials (BOM) cost that you are willing to trade-off for one-time non-recoverable engineering (NRE) upfront expenditures?
• Does your use case require a version other than Android 9 or 10?

If you answered yes to one or more of those questions, an AOSP from a trusted device maker may be a better choice than a GMS-certified device. 

If you go the AOSP route and procure devices from the Asia ODM supply chain, you need to proceed carefully. We’ve seen instances where serial numbers were not included in the AOSP build, when the firmware image provided in the evaluation units were different than what was delivered in final order, undesired system behavior based on how the ODM set up the Android Framework for the firmware build, and misaligned expectations regarding ongoing firmware updates for these devices and in some cases lack of firmware over-the-air (FOTA) update capabilities. Furthermore, if the firmware image is provided as a binary, you have no insight into the code included in that firmware image—we’ve seen mysterious traffic, detected via Wireshark, communicating with endpoints offshore. If you are dealing with an ODM you have to negotiate all the terms associated with firmware up front, things can get messy if the contract is signed and these aspects are not addressed at that time.

What if Your App is Reliant on Google GMS packages?

This is a common blocker we see with customers building their app assuming a GMS device. By defining the use case and requirements precisely, we’ve found that you can often deliver equivalent functionality through AOSP without GMS. But this takes due diligence and careful design to achieve an AOSP-ready app. It goes back to GMS providing advantages for app developers, thus trading off superior economics and fine-grained control from a hardware and firmware perspective with ease of development. Esper is very experienced with these tradeoffs, and we are happy to help customers navigate these choppy and confusing waters.

Can you add GMS to a Non-GMS Device?

Technically you can add GMS components to non-GMS AOSP builds. This is how candidates for GMS are built; they all start with AOSP. But commercially shipping non-GMS certified devices that include GMS components and services without obtaining GMS certification is not allowed by Google. 

If you have a use case that unequivocally requires some part of GMS, you should probably deploy a GMS-certified device.

Another approach to consider is a mixed fleet. Pursue GMS devices for use cases that require GMS services and capabilities. Then use AOSP devices for the part of the fleet that does not. Esper allows you to manage both GMS and AOSP devices side-by-side easily. So if you have a customer that needs Google Play services— Google Play apps or access to a managed Google Play Store on the device, use GMS devices. For other customers that just need your AOSP ready APK, use AOSP devices. Also, your AOSP APK will be able to work on GMS devices as well.

Is there a better AOSP for single-purpose Android devices?

AOSP can be a wild and woolly world; you don’t necessarily know what you are getting into. Furthermore, the particular needs to improve the operational and development experience are typically unaddressed. This is one reason why we created Esper Foundation for Android (Foundation)—our customers get full source code access to know exactly what is included in the ROM image, can set up the firmware build exactly to their specifications, and a commitment for security patches within 30 days of availability in the AOSP tree delivered via Esper’s built in FOTA support. Additionally, with Esper Foundation for Android, you get seamless, true no-touch provisioning. One of our customers is using Foundation to drop-ship directly from the factory to the end deployment site. Just turn on the device; it provisions automatically and is ready to go.

So, GMS or Non-GMS?

Your average corporate-owned employee smartphone probably shouldn’t be running a specialty Android Open Source Project (AOSP) build. But when it comes to dedicated devices — kiosks, single-purpose tablets, or display signage — the answer is more complex. Also known as corporate-owned, single-use devices (COSU), these machines don’t always need GMS capabilities. Depending on your specific requirements, GMS could be the way to go — but you do have other, potentially better options available.

Non-GMS Android can be the right solution for single-purpose device use cases, but it still depends on what you’re trying to do and whether you need Google services and associated packages (applications) to get there. Non-GMS Android may be the only answer for some dedicated devices that fall into non-standard use cases, like smart displays for single-purpose fitness equipment. 

GMS, on the other hand, allows you to tap into the mainstream consumer Android market, which brings relatively known quantities familiar to consumers and employees. But there are trade-offs to consider.

With non-GMS devices, you have the ultimate flexibility to provision, deploy, and design purpose-built devices to fit your use cases. There are tradeoffs, including the fact you’re cut off from Google apps and services that would normally be available to developers. However, AOSP devices give you the flexibility to make updates on your own schedule and keep your firmware where you want it.

GMS vs. non-GMS depends on:

• Hardware brand
• Hardware models
• Quantity of devices
• Distribution
• Device agents
• Firmware quality and update infrastructure
• Applications
• APIs
• Use cases

If you do not need any GMS applications or services, a high-quality AOSP device that’s deployed on a closed network could be more efficient and far more flexible. And Esper can make it even better using Esper Foundation for Android, providing a pleasant user experience. If you want to discuss GMS versus AOSP solutions (or just have questions), get in touch with us today.

Device Selection Guide