Extremely nice blog post by Esper.io on the merits of GMS versus non-GMS. As you can see there is a limited case to be made for GMS certification, in instances of purpose-built self-service android kiosks. Adds complexity.
Having said that, ultimately if you have a customer who wants GMS certification and they are a large customer, then the customer is always right. We would recommend using a lockdown browser on GMS devices to give overall control.
GMS versus Non-GMS for Android Devices
Keith Szot April 30, 2020
Do you need to use Google Mobile Services (GMS)-certified devices for your single-purpose Android solutions?
The answer depends on what you’re trying to do.
Your average corporate-owned employee smartphone probably shouldn’t be running an opaque Android Open Source Project (AOSP) build. When it comes to dedicated devices like kiosks and single-purpose tablets, the answer is a bit more complex. Corporate-owned, single-used devices (COSU) don’t always need GMS capabilities, but depending on your specific requirements, GMS may still be the best way to go.
Non-GMS-certified AOSP devices can be the right solution for some single-purpose device use cases; it depends on what you’re trying to do and whether you need Google services and associated packages to get there. Non-GMS AOSP-based devices may be the only answer for some dedicated devices that fall into non-standard use cases, like smart displays for single-purpose fitness equipment.
On the other hand, being able to tap into the device diversity created by the mainstream consumer Android market brings relatively known quantities familiar to consumers and employees. But, what are the trade-offs?
Google Mobile Services: Pre-Installed Apps and Services
GMS is a bundle of applications and services by Google that comes pre-installed on GMS-certified Android devices. GMS is built on top of the Android Open Source Project (AOSP), which means manufacturers need to be licensed to pre-install the GMS bundle on devices.
The bundle varies a bit by region but typically includes:
- 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 on GMS devices that are not available for AOSP devices. Many mainstream Android apps are dependent on GMS package capabilities like SafetyNet APIs, Firebase Cloud Messaging (FCM), or Crashlytics. If you’re not aware that your GMS-dependent app won’t work on an AOSP device, you’ll be in a bad state.
The nuance is Google makes APIs available for many of its services which can be accessed by non-GMS Android devices primarily intended for browsers and standalone app integration on Windows and MacOS. An example is Google Drive with Google’s Drive API. By using the Drive API you can integrate Drive directly into your app without reliance on GMS, thus applicable to non-GMS AOSP devices. You can also implement programmatic access to Gmail using the Gmail API.
While there are big benefits for application developers with GMS providing a strong set of system packages specific to Android GMS devices to use (in many cases lowering development time and delivering superior experiences), you can access many of these services using programmatic APIs.
Consumer Android vs. Single-Purpose Android Devices
If you’re considering a device from a major Android original equipment manufacturer (OEM), you’ll benefit from the rigor around shipping a product sold to potentially millions of users. But the lifespan of these consumer products are typically well shorter than the lifespan of single-purpose device solutions, requiring the solution owner to switch to a new model on a frequent basis—typically yearly.
GMS Certification and Android Versions
The challenge is especially tough for device makers that are not a top Android OEM. The way the GMS program is set up, any devices that are submitted to GMS certification must run on either the current Android release or the previous version. Thus, if you are sourcing from a device maker and changes need to be made to the firmware and your device is now two releases behind the current Android version, the device loses the ability to be GMS certified for that new firmware release. Obtaining GMS certification adds to both cost (to pay for the testing process itself and the resources required to support testing) and timeline (it takes time to complete the process, typically months). Any changes to the firmware will require a recertification for GMS, significantly raising the bar to build and rollout firmware updates for GMS devices.
Device Maker Updates and GMS
It also means you will be at the mercy of the device maker for when system updates are pushed—including moving to new major releases of Android. There have been many changes in Android 10 impacting single-purpose device use cases, and based on the beta testing of Android 11 this will continue. Once the device maker pushes a system update out via firmware over-the-air (FOTA), any solution built on these devices will have limited options for controlling these updates. Some OEMs like Zebra provide robust system update management capabilities for GMS devices, but they’re the exception.
However as Android progresses to new versions and OEMs move on to new models, these updates will stop generally after 2 years. This is 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.
The second is to purposely use an older device that is done with updates yet can still be obtained in the open market at typically cheaper prices.
This approach has its disadvantages: security updates are no longer delivered for these devices and available inventory will become scarce after the manufacturing of these devices are stopped by the OEM. But this approach is viable for some customers.
How Android Devices Get Certified
Android is open source, but GMS isn’t. Manufacturers (OEMs) obtain a GMS license—known as a MADA— from Google, and then they’re required to pass a series of tests:
- Compatibility Test Suite (CTS)
- Compatibility Test Suite Verifier (CTS Verifier)
- CTS Audio Quality Test Suite (CAT)
- GMS Test Suite (GTS)
Achieving GMS certifications creates an agreement between manufacturers and Google. GMS devices are pre-loaded with Playstore apps and Android 9 or 10, and they’re subject to Google’s policies for privacy, including GMS agreements for privacy, data collection, and device updates.
GMS certification isn’t available for every type of device. Android for exercise equipment and medical devices are pretty standard use cases, but they are not a focus for Google and therefore face an uncertain and expensive road to obtaining GMS certification.
Pros of GMS-Certified Devices for Dedicated Devices
There are no universal pros for every single-purpose device. However, these GMS features could be beneficial in some cases.
- Generally, GMS smartphones and tablets are loaded with the latest version of Android or the preceding release—currently Android 9 or 10, soon to be Android 11 or 10
- GMS devices receive monthly Security Patch Updates
- GMS devices offer Google Play Store access that can be controlled by an EMM including Esper
- GMS devices include frequently-used APIs like location services
- GMS devices offer Google user authentication
- Android Enterprise support is included specifically for working with management platforms such as Esper
- Certainty of both the robustness and composition of the firmware image based on having to complete the GMS process
The pattern of updates to GMS-certified devices can be a pro or con, depending on use case. Access to updates depends on the OEM and device maker to prepare an update and push it through. Understanding a OEM’s approach to updates is a key part of due diligence when you’re sourcing GMS-certified or AOSP devices.
Google is stringent about enforcing security patch updates on GMS-certified devices which are released every month. With some exceptions for holidays and other blackout periods, security updates usually have to be applied within 30 days. This requirement doesn’t apply to non-GMS devices.
Cons of GMS-Certified Devices
- Devices are subject to Google’s Privacy and Terms of Use
- Pre-loaded apps use up available RAM and ROM
- Uncertain support for non-standard Android devices
- No support for Android versions other than 9 or 10
- Logistical limits to rapid deployment, staging, and provisioning
- Limitations on device policy and security configurations (like Google Play Protect)
Also, GMS-certified devices with the pre-installed bundle of apps and services use some data. How much data is hard to estimate and varies, depending on your network, data saver settings, and enabled GMS 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 there are many off-the-shelf designs that 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. We’ve found that by precisely defining the use case and requirements, oftentimes equivalent functionality can be delivered 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 out 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 easily manage both GMS and AOSP devices side-by-side. So if you have a customer that needs 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 Enhanced Android (EEA)—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 Enhanced Android you get seamless, true no touch provisioning. One of our customers is using EEA 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 parent’s smartphone should probably be a GMS-certified device.
Your boss’s smartphone should probably be a GMS-certified device.
But, enterprise dedicated devices don’t always need to be GMS-certified.
With non-GMS devices, you have 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 that’s deployed on a closed network could be more efficient and far more flexible. And Esper can make it even better using Esper Enhanced Android.
Please contact Esper if you’d like to discuss GMS versus AOSP for single-purpose Android-based solutions.
Related topic: How to Provision GMS and Non-GMS Devices in Esper
Latest News Circa Dec 2022
Self-Order & Digital Messaging Samsung
Self-Checkout & Disabled Shoppers – Food Institute
NRF 2023 KMA – Samsung, Pyramid, KioWare, Vispero,& Olea.
POS Clover Customer Self-Order Kiosk Case Study
Grocery Store Checkouts & Accessibility
Wendy’s Serves Up Big Kiosk Expansion As Wage Hikes Hit Fast Food(Opens in a new browser tab)
Wrap – Four Lane Drive-Thru Taco Bell Defy (with kiosk)(Opens in a new browser tab)
Drive-Thru Employee Headset Technology
Drive-Thru Whitepaper – Continuing Evolution