EDLA vs GMS: Which Android Licence a Commercial Display Needs

1. Two decisions hide behind the word Android

A specification line that reads Android tells you very little about what the panel can run. Android is a layered product, and a commercial display can ship on any of three levels: the open source base with nothing added, a vendor build with the Google layer removed, or a licensed build carrying the Google app suite.

Buyers tend to meet the difference after the order, not before it. The panel arrives, the content application asks for a Google account, and the install stops at a login screen. Nothing on the invoice mentioned that this was possible, because the invoice only said Android.

This article separates the two decisions that one word conceals: which licence route the manufacturer holds, and whether the device is certified at all under Google's compatibility programme. The first decides what ships preinstalled. The second decides what your IT department can do with the fleet afterwards.

For interactive flat panels, kiosks and signage the practical answer is usually EDLA. The rest of this article explains why, and what to write into an RFQ so the answer stops being a matter of chance. The interactive flat panel selection guide covers the hardware side of the same purchase.

2. AOSP, GMS, MADA and EDLA in plain terms

AOSP, the Android Open Source Project, is the free base layer. Any manufacturer can build on it and ship a device with no Google software and no licence. AOSP devices are entirely legal, they boot normally, and they run third-party applications that you install yourself.

GMS, Google Mobile Services, is the layer above: Play Store, Chrome, Gmail, Maps, YouTube and Play Protect. Google licenses this layer rather than selling it, and the licence is granted for a device category rather than for a company.

Two routes cover most hardware. MADA, the Mobile Application Distribution Agreement, is written for consumer devices with a battery and screens between roughly 3.3 and 18 inches. EDLA, the Enterprise Device Licensing Agreement, was introduced at the end of 2022 for dedicated and enterprise hardware: digital signage, kiosks, point-of-sale terminals, ruggedised handhelds, interactive whiteboards and slot-in modules. In practice a device with no battery, or a screen above 18 inches, falls under EDLA.

The split matters because a licence is not transferable between categories. A factory holding MADA for tablets cannot ship the same build on a 65 inch panel and remain inside the agreement. Our own interactive flat panel line sits in the EDLA category for exactly this reason: it is a large, battery-free, fixed-installation device.

3. What the licence changes on the panel itself

Without a licence there is no Play Store, so applications arrive by sideload. That means copying an installation package onto the device, allowing installation from unknown sources, and repeating the process by hand or by script for every unit in the fleet.

Features built on Google services stop working quietly. Push notifications, screen casting, single sign-on with a Google account, Play Protect scanning and a number of mapping functions are delivered through GMS rather than through the operating system. A panel without GMS can launch an application and still fail at the parts inside it.

Certification also sets the ceiling on fleet management. Devices enrolled through the Android Management API, the channel used by mainstream mobile device management platforms, can be configured as fully managed or as a dedicated kiosk device. Uncertified AOSP builds have limited support for that API, so enrolment is often unavailable and the estate is managed by whatever tool the vendor happens to supply.

For one showroom panel, sideloading costs an afternoon. For two hundred units spread across a retail chain, it becomes a support obligation with no owner and no schedule. The same arithmetic applies to the rotation flat panel where the device is expected to run a fixed application set unattended.

4. Sideloading is a maintenance cost, not a workaround

The bill for missing Google services arrives in stages. Installation is the visible one. Update delivery is the one that keeps arriving.

An application installed from a package file does not update itself unless the vendor built a separate update channel for it. A corporate portal or a payment application that adds a security requirement keeps working until the day it stops, and that day arrives in the field rather than in a laboratory.

Security patching is the second stage. Certified enterprise devices carry a commitment to security updates across the early years of the product lifecycle, delivered through Google's update channel. An uncertified build depends entirely on the manufacturer choosing to publish firmware, and on the buyer knowing where to find it.

The third stage is labour. Every device needing manual intervention consumes technician time, and technician time is priced by travel rather than by the hour. A licence saved at the purchase order is repaid one site visit at a time.

5. Certification is a test programme, not a logo

EDLA certification runs through Google's standard compatibility workflow. The device has to satisfy the Compatibility Definition Document for its Android version, and it has to pass the test suites Google applies across the ecosystem.

Those suites are broad. The Compatibility Test Suite alone covers well over four million test cases for a recent Android release. In addition there is the Google Test Suite for application integration, the Vendor Test Suite for the hardware abstraction layer and kernel, the Security Test Suite for patch integrity, and manual verification for anything that cannot be automated.

The engineering conditions are specific. The build must declare the enterprise device feature, the device needs a touch interface and USB debugging, and the chipset has to be registered in Google's system. Memory and storage floors also apply, and those floors have been raised as Android versions have advanced.

A factory completes this cycle once per platform, and it takes months. Most buyers do not want to fund that cycle for a single project. Which is why the useful question is not whether a factory can certify, but which already-certified platform it is building your panel on.

6. The lifecycle commitment you are actually buying

The licence carries obligations that outlast the shipment. Manufacturers commit to security updates across the early years of the device lifecycle, and EDLA devices receive quarterly Android security patches through Google's channel rather than through the vendor's own server.

This is the part public tenders have started to test. A specification asking for Android can be answered by an AOSP build. A specification asking for a certified enterprise device with a stated patch commitment cannot be answered that way, which is exactly why the wording matters.

The commitment also has a geography. MADA licences are issued in several regional versions, and EDLA has historically been divided between Russia and the rest of the world. A product licensed for one region is not automatically the product that lands in another, even when the model number looks the same.

For a buyer, the useful move is to make the commitment explicit in writing: which certification, for which Android version, in which market, and who publishes patches after the first year. If the answer is verbal, treat it as absent.

7. Where Android in a tender goes wrong

Specifications rarely fail because the buyer chose the wrong platform. They fail because the platform was never pinned down, and every bidder answered a slightly different question while all of them stayed technically compliant.

Three phrases cause most of the damage. Android based leaves the licence route open. Supports Google Play describes an intention rather than a certificate. Android OS in a technology column is fully satisfied by an AOSP build, because AOSP is Android.

The reliable check is documentary. A certified device can be located in the licence holder's device list, and the declared enterprise feature can be read from the shipped software build. Ask for the model name and Android version that appear in the certificate, not the family name from the brochure.

It is worth asking one further question: which chipset the certified baseline runs on. A baseline tied to a platform still in production is a supportable product for years. A baseline tied to a platform at end of life becomes an orphan at the next patch cycle, and the panels are still on the wall when that happens. The same reasoning applies to bar displays and other fixed-function panels in a managed estate.

8. What to put in the RFQ

None of this needs to become a research project. Seven lines in the request for quotation will settle the licence question before pricing is compared, and they cost nothing to write.

1. The licence route required, named as EDLA or MADA rather than Android.
2. The Android version covered by the certificate, and the model name exactly as it appears in it.
3. The target markets, so regional licence versions are confirmed before the order rather than after it.
4. The security update commitment in years, and which party publishes the patches.
5. Whether the device will be enrolled through the Android Management API, and in which mode.
6. The chipset platform behind the certified build, and its stated production status.
7. A sample unit carrying the production build, so Play Store availability and management enrolment can be checked on the bench.

Two of these lines do the heavy lifting. Naming the licence route removes the ambiguity that lets an AOSP build pass as a licensed one. Naming the chipset platform tells you whether the certified baseline will still be supported when the warranty ends.

If the project mixes operating systems, the trade-offs between Android and Windows on the same hardware are covered in the player platform comparison. Licence status sits underneath that decision either way.

Android licence routes against what a buyer can actually do with the device

Route	Written for	Screen and battery	Google apps	Fleet management	Typical devices
AOSP, uncertified	Any manufacturer	No limit	None, sideload only	Limited API support	Custom signage builds, low-cost panels
GMS via MADA	Consumer mobile devices	3.3 to 18 inch, battery	Full suite with Play Store	All Android Enterprise modes	Smartphones, tablets
GMS via EDLA	Enterprise and dedicated devices	Above 18 inch, or battery-free	Full suite with Play Store	Fully managed and kiosk modes	Signage, kiosks, POS, interactive panels
Windows or OPS module	Not an Android licence	Set by the module	Not applicable	Windows management tools	Meeting rooms, control rooms, mixed estates

Frequently Asked Questions