Quick answer: “It runs Android” says nothing about kiosk risk. Four layers decide your exposure — AOSP vs GMS certification, the security-patch window, device hardening, and who owns updates over the machine’s field life. Here is what to verify, and the RFQ questions to ask.
Overview
Short answer: “It runs Android” tells you nothing about whether a kiosk is safe, supported or updateable. For an unattended OEM/ODM terminal, four things decide your real risk: (1) whether it is plain AOSP or carries Google GMS certification (CTS/GTS), (2) the Android version and its guaranteed security-patch window, (3) whether the device is hardened and locked into kiosk mode, and (4) who ships security updates for the machine’s 5–7 year field life. Below is what to verify and the questions to put in your RFQ.
Why “runs Android” is a false reassurance
Android is not a product — it is an open-source base (AOSP) that anyone can load onto hardware. Two kiosks that both “run Android” can be completely different in risk: one is a certified, update-supported commercial device; the other is an uncertified build of an obsolete Android version with no security patches and an unlocked bootloader. For an unattended terminal handling payments or personal data, that difference is the whole procurement decision, yet most supplier datasheets hide it behind “Android 11” or “Android 13.”
The buyer’s real question is not which Android . It is: will this device still receive security fixes when it is standing in a public space in year four?
The four layers you actually need to audit
| Layer | What it covers | What to ask for |
|---|---|---|
| AOSP vs GMS | Plain open-source Android vs the Google-certified build with Play services | State which one, and whether the device passed CTS/GTS if GMS is claimed |
| OS version & patch window | The Android version and the guaranteed security-patch end date | The exact version, security patch level, and vendor commitment to update until X |
| Device hardening | Locked bootloader, verified boot, no root, kiosk/dedicated mode, disabled ports | Written configuration: bootloader state, kiosk-mode enforcement, disabled USB/debug |
| Update ownership | Who delivers patches and firmware over the field life | Named party, method (OTA/local), cadence, and what happens if the OEM exits |
Notice that only the first layer is about Google. The other three — patch window, hardening, update ownership — are the ones that actually fail in the field, and they are entirely within the OEM/ODM supplier’s control. That is where a weak datasheet usually reveals itself.
AOSP vs GMS: which do you actually need?
This is the most misunderstood layer. AOSP is the open-source base; it is free, needs no Google licence, and is perfectly adequate for many self-service kiosks that run a single custom application. GMS (Google Mobile Services) adds Play services, the Play Store and Google’s APIs — but to ship GMS legally you must pass Google’s compatibility testing (“CTS,” documented by Google at source.android.com ).
- Choose AOSP when the kiosk runs one locked-down application, needs no Google APIs or Play Store, and you want lower cost and fewer dependencies. It suits cash-handling and single-purpose self-service terminals where the software stack is fully controlled by you.
- Choose GMS when your application depends on Google Play services, Maps, Push, or Play Store distribution, or when your buyers or their auditors expect a Google-certified commercial device.
The procurement trap is a supplier claiming “Android with Google Play” without being able to show it passed compatibility testing. If GMS is on the device, ask for the CTS/GTS test result covering your exact model and build — an uncertified device can be blocked from Google services later, which is a live risk across a deployed fleet.
Version and patch window: the number to insist on
“Android 13” is not a support commitment. What matters is the guaranteed security-patch window — the date until which the device will keep receiving security fixes. A kiosk is a 5–7 year asset; if the OS stops receiving patches in year two, every year after is unmanaged exposure. Google publishes the current security-patch levels and monthly bulletins at source.android.com , so you can independently verify any patch level a supplier quotes. Ask for:
- The exact Android version and the current security-patch level, which you can cross-check in the device’s settings against Google’s published bulletins;
- The vendor’s written commitment to deliver security patches until a stated calendar date, not just “while supported”;
- Whether major-version OS upgrades are possible on this specific hardware, or whether the device is frozen at its shipping version for its whole field life;
- The delivery mechanism and cadence for pushing those patches to an already-deployed fleet (signed OTA vs manual sideload).
On an unattended, publicly reachable terminal, an un-patchable OS is a standing liability — and it is invisible on a spec sheet that only lists the version number.
Hardening is where kiosk deployments get breached
A kiosk is an Android device left alone with the public, and hardening is what stops a passer-by from turning it into a general-purpose computer. Android provides dedicated device and lock-task APIs for exactly this purpose (see Google’s dedicated devices overview ), so “we cannot do it” is not a credible answer. Verify, in writing, that the supplier ships the device with:
- A locked bootloader and verified boot , so the OS image cannot be replaced or tampered with in the field;
- Kiosk / dedicated-device mode enforced via the platform’s lock-task APIs, so the user cannot exit to the launcher, settings or browser;
- USB, ADB and debug ports disabled in the production build, not just hidden from the UI;
- No root access and a controlled application-allowlist that limits the terminal to its intended function;
- A signed, managed update path rather than a manual sideload that a technician must perform on site.
Ask whether these are set for the whole fleet by default, or only when a buyer remembers to request them. If hardening is optional and unverified, it is effectively absent. If your machine also handles payments, hardening overlaps with the payment-approval scope — see the PCI DSS/P2PE audit guide for payment kiosks .
Update ownership: the question nobody asks until year three
Unattended fleets fail in the maintenance phase, not at launch. The decisive question is simple: who ships patches for this fleet in year four, and what happens if our supplier disappears? A credible OEM/ODM answer names a party, a method, a cadence and a fallback — for example, that the OS image and update-server credentials are documented and escrowed, so a second party can take over. A vague “we will support it” is not an answer for a 5–7 year asset.
Copy-paste RFP questions for the Android layer
- Is the device AOSP or GMS? If GMS, provide the CTS/GTS evidence covering this exact model and build.
- State the exact Android version, the current security-patch level, and the guaranteed end date for security updates.
- Are major-version OS upgrades supported on this hardware, or is it frozen at the shipping version?
- Provide the production hardening configuration: bootloader state, verified boot, kiosk/dedicated-mode enforcement, disabled USB/ADB, and root status.
- How are security patches delivered to a deployed fleet, at what cadence, and by whom?
- If our supplier relationship ends, how do we obtain the OS image and update mechanism to keep patching the fleet?
- Does the device configuration preserve or violate any payment or data-protection approval we rely on?
Android is one layer of a risk-managed OEM/ODM buy. Lock the adjacent layers with the 2026 OEM/ODM kiosk certification checklist , confirm the factory paperwork with the 9 approval documents to collect before production , and — for payment terminals — pair this with the PCI/P2PE audit guide . For how the OS choice interacts with cash and payment hardware, see the payment kiosk cash integration guide , and for the customization model that sets your update obligations, see the custom kiosk OEM/ODM process, from brief to production .
Is AOSP less secure than GMS?
Not inherently. Security depends on hardening, the patch window and update discipline, not on whether Google services are present. A well-hardened, actively patched AOSP kiosk can be safer than an unmanaged GMS device. The real risk is an uncertified GMS claim or an un-patchable version, whichever base is used.
Can I lock down an Android kiosk so users cannot escape the app?
Yes — through the platform’s dedicated-device and lock-task mode, a locked bootloader, disabled debug and USB ports, and a controlled app allowlist. Ask the supplier to deliver these as production defaults with written confirmation, not as options you must request and verify yourself.
How long will my Android kiosk stay secure?
That depends on the vendor’s committed security-patch window, not the Android version alone. Insist on a written end date for security updates and a named party responsible for delivering them across the machine’s 5–7 year life.
Does a Google certificate on the datasheet mean the device is certified?
Only if it is the compatibility testing (CTS/GTS) evidence for that exact device and build. A generic “Android” or “Google” logo is not certification. Ask for the test result that covers the model you are buying.
Your next step
Stop accepting “it runs Android” as a specification. Ask for the version, the patch end date, the production hardening configuration and the named update owner — then verify each in writing before you commit. If you are evaluating an Android-based cash-handling or payment kiosk and want to see how the OS, hardening and update layers are documented, review a freestanding cash-handling kiosk , or request a quote or datasheet and we will send the platform and support details for our current production models.
