Healthcare kiosk app development 2026: Android for nursing homes
TL;DR
Healthcare kiosk app development in 2026 is Android Enterprise work first and screen design second: the app must own the tablet through a device owner, enroll without a technician, obey commands from far away and log nurses in with a badge.
- Lock task mode has existed since Android 5.0. It hides Home, Overview and notifications, and only apps a device policy controller allowlists can use it.
- QR code provisioning needs Android 7.0 and zero-touch needs 8.0, so your hardware list decides how many hands touch each of 300 tablets.
- Remote reboot needs Android 7.0 on a fully managed device. Update policy needs 6.0.
- ISO/IEC 15693 badges read through Android's NfcV class, and HIPAA requires each user to have an individual ID on a shared screen.
- Below Android 6.0 Google's dedicated-device controls are missing, so a kiosk rests on undocumented APIs.
What a nursing home tablet has to survive
The CDC counts 14,700 nursing homes in the United States, with 1.6 million licensed beds and 1.2 million residents in 2022. Long corridors and several floors put the care system on wall tablets wherever a nurse stands.
The nurse using it is rarely technical, and nobody from IT is on site when it freezes overnight.
HIPAA shapes the login. Under 45 CFR 164.312, assigning each user an individual identifier is required and automatic logoff is addressable. A shared tablet is fine. A shared login is not.
The screens inside the lock follow the rules in our guide to software for non-technical clinical staff.
September 30, 2026: Android developer verification starts
Google's developer verification takes effect on September 30, 2026 in Brazil, Indonesia, Singapore and Thailand, with a global rollout in 2027.
The Android Enterprise team says apps installed by an EMM's device policy controller and private apps in managed Google Play are exempt indefinitely, while other apps on fully managed devices need verification from September 2027. Google's private apps page exempts private apps on any device enrolled in Android Enterprise. A hand-copied APK on an unenrolled tablet is not.
Under Google's approved DPC allowlist, only DPCs verified by Android Enterprise may install apps during enrollment, and the Play Protect guidance says an unapproved DPC is blocked there. Plan for one from the first pilot.
How we put this guide together
Every Android version and API here comes from Google's documentation, read in October 2026. The pages that rank for kiosk queries come from MDM vendors such as Hexnode and Scalefusion: they explain how to configure a kiosk, not how to build the app inside it. The requirement pattern comes from one long-term care scoping record, described without the client's name.
Mercury Development builds this software: read this as an interested engineering view.
Five ways to lock an Android tablet at a glance
| Approach | Who can exit | Android floor | Remote restart | Fits |
|---|---|---|---|---|
| Screen pinning | The user, at any time | 5.0 | No | Demos only |
| Lock task mode under your own DPC | Only your DPC | 5.0, full controls from 6.0 | 7.0+ | A vendor running its own fleet |
| MDM vendor kiosk, such as Hexnode or Scalefusion | The MDM admin | 6.0+ for the dedicated-device set | 7.0+ | Facilities whose IT already runs an MDM |
| Android Management API kiosk policy | The policy | 6.0+ for the dedicated-device set | 7.0+ | Vendors who let Google's DPC do the locking |
| Custom launcher on pre-6.0 Android | Whoever finds the gap | Below 6.0 | Workarounds | Avoid |
Lock the OS with lock task mode and a device owner
Google's lock task mode guide lists the defaults: a blank status bar, no Home or Overview, no other apps, no lock screen. Only apps the DPC passes to setLockTaskPackages() can enter it.
Startup takes three pieces. The device owner, set during provisioning, allowlists your app and holds the right to block reset and reboot remotely. The app declares android:lockTaskMode="if_whitelisted" and registers as the persistent preferred Home handler, so a power cut ends on your screen, not the launcher. Then come the restrictions in Google's dedicated devices cookbook: DISALLOW_FACTORY_RESET, DISALLOW_SAFE_BOOT, DISALLOW_ADD_USER.
On Android 9.0 and later, DISALLOW_SYSTEM_ERROR_DIALOGS restarts a hung app instead of showing a dialog. On 6.0 and later, STAY_ON_WHILE_PLUGGED_IN keeps wall units awake.
One trap: the long-press power menu is the only lock task feature on by default. Turn it off with setLockTaskFeatures() on 9.0 and later, and add DISALLOW_CREATE_WINDOWS so other apps cannot draw overlays over yours.
Provision 300 tablets without a technician
Google's dedicated device requirements set a floor for each enrollment method:
- DPC identifier (
afw#) and NFC provisioning: Android 6.0 and later. - QR code provisioning: Android 7.0 and later, listed as required for EMMs.
- Zero-touch provisioning: Android 8.0 and later, 7.1 on Pixel.
- Dedicated device enrollment without a Google Account sign-in: Android 8.0 and later.
The AOSP provisioning page adds a detail that breaks older playbooks: Android 10 removed Android Beam, so NFC provisioning there needs NFC tags, not a phone-to-phone bump.
We stage once per site: a QR code carries Wi-Fi, the DPC and the enrollment token, and the policy then installs the kiosk app silently, which fully managed devices allow from 6.0. Zero-touch hardware skips even the scan.
Restart, reconfigure and update from eight hours away
A site eight hours away turns every support call into a trip unless the device takes commands.
- Remote reboot needs Android 7.0. Google's device control guide adds that only a device owner can call
reboot(), and the call fails during an active phone call. - Facility settings, such as a tablet's unit or a monitor's view-only flag, ship as managed configurations, not a new APK.
- A system update policy needs Android 6.0 and freeze periods need 9.0. The cookbook says dedicated devices can suspend OTA updates for up to 90 days.
Push beats polling every few seconds. Google's Doze guidance says a device left unplugged, stationary and dark enters Doze and loses network access. A wall monitor on power rarely gets there. A tablet on a med cart does, and Firebase Cloud Messaging still reaches it.
What this upkeep costs per year is broken down in our guide to healthcare app maintenance cost.
NFC badge login with ISO/IEC 15693
ISO/IEC 15693 badges are contactless vicinity cards. Android reads them through the NfcV tag class, which sends raw commands with transceive(). Keep that call off the main thread and run reader mode while the kiosk is in the foreground, so a tap never wakes another app.
ISO lists ISO/IEC 15693-3:2019, the anticollision and transmission protocol, as withdrawn on May 7, 2026 and revised by a 2026 edition. If your badge supplier documents against the 2019 text, ask what changed.
Test on the exact tablet: antennas differ between models. For HIPAA, treat the tap as identification, add a short PIN for writes and an idle timeout back to the badge prompt.
Why Android below 6.0 costs more and breaks more
Google's dedicated device list sets 6.0 as the floor for lock task management, dedicated-device security policies, advanced kiosk controls and update policy. Silent installs and stay-awake-on-power start there too. On 5.0 and 5.1, removing an app from the allowlist does not even stop lock task mode.
Below that line a kiosk is a custom launcher plus workarounds that the next firmware can break. Our assessment on one requirement was blunt: kiosk mode before 6.0 means system hacks and undocumented APIs, higher cost and lower reliability.
The October 2026 Android Security Bulletin patches AOSP 14 through 17 and says devices on Android 10 and later may receive security updates. The Lenovo Tab 3 Business TB3-X70F shipped with Android 6.0, so a 10-inch business tablet bought for a facility can start life far below the patched range.
Build on an MDM or ship your own DPC
Most facilities should not run a custom DPC. Hexnode's kiosk guide covers single-app, multi-app and web kiosks and notes that kiosk activation on Android Enterprise requires device owner mode. Scalefusion lists senior living and hospice among its healthcare uses. Both configure the lock, not your care app.
The Android Management API is the third route: an app with installType: KIOSK launches at boot, runs full screen and stays pinned, with Google's own DPC doing the locking.
For a vendor selling into many facilities: build the app to run under any EMM, read settings from managed configurations, and let AMAPI or the facility's MDM own the device. Write your own DPC only for behavior no EMM exposes, and get it approved first.
The MDM platforms themselves are compared in our review of Android kiosk mode for healthcare.
What a nursing home kiosk requirement looked like
One long-term care requirement in our scoping records shows the full shape. It is a single record, so we draw no rate from it.
The client wanted a native Android care app for skilled nursing facilities on tablets and wall monitors that starts with the OS and blocks access to it. Monitors were view-only, tablets view and edit. Some sites sat eight hours from the main office, so restarts and settings had to be remote, and a rollout of, for example, 300 touch panels needed minimal technician time. Nurses would sign in with ISO/IEC 15693 badges on a named 10-inch Lenovo tablet.
Our analysis set Android 6.0 as the floor and flagged what to test first: manufacturer variation, NFC scan stability across devices, and an API spec and device list that did not yet exist. The client preferred push to polling, as did we.
Which setup fits your rollout
- One facility already on an MDM: use its single-app kiosk and spend the budget on the app.
- A vendor shipping to many facilities: an EMM-agnostic app with managed configurations, on AMAPI or the customer's MDM.
- Hundreds of new tablets per rollout: zero-touch capable hardware on Android 8.0 or later, with QR codes as the fallback.
- Badge login required: choose the tablet after an NFC read test with the real badges.
- A fleet below Android 6.0: price a hardware refresh against the workaround budget before committing to either.
Design for the nurse first, then for the fleet
Our view: a kiosk fails twice. Once when the nurse cannot finish a task in a few taps, and again when the far tablet needs a human to fix it. Choose hardware last, after the NFC and enrollment tests.
On ORIGOSafeDriver the app had to control a driver's phone, although Apple and Google guidelines normally do not let apps take over devices; we wrote our own modem driver when the manufacturer's proved unstable, added remote debugging and cut data traffic to 8 MB per device per month. MiMedia, whose apps we developed across platforms, shipped factory-installed as the default gallery app on Micromax smartphones. On Kensington Proximo we delivered a fully functional Android app in 3 months on a pre-release Samsung BLE SDK that supported only the Galaxy S4. We build to HIPAA and GDPR requirements.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The requirement review and Android platform checks behind this article's kiosk architecture come from scoping work in the practice he leads.
Send us your device list and we will map the kiosk stack
Tell us which tablets and monitors you run, their Android versions, how badges work today and how far your sites are. We will map the lockdown, enrollment and remote support each device allows, and flag the hardware we would test before you buy more.