FreeKiosk turns an Android tablet into a locked down signage screen

What problem a kiosk app actually solves

The project description names the use cases with unusual precision: digital signage, dashboards, POS and single purpose devices, positioned as a free alternative to Fully Kiosk. That list is the real requirement set, and it explains the design. A tablet on a reception desk showing a dashboard, a menu board in a shop, a terminal at a counter, none of these need a full Android experience. They need a screen that always shows the right thing, cannot be swiped away, cannot be exited, and ideally can be reconfigured remotely when the content changes. The commercial product in this space solves that and charges per device, which is a cost that scales badly when a deployment is a hundred tablets rather than three. The pitch FreeKiosk makes is control without licence costs, and the reason teams choose it is listed as free and MIT licensed, Device Owner support for true lockdown, working in WebView mode or External App mode, a native REST API and MQTT integration, headless ADB provisioning for mass rollout, and a privacy-first stance with no mandatory tracking layer. The audience is a small team running a fleet, probably with mixed hardware and no budget line for software licences.

Device Owner is what separates lockdown from a full screen

Most kiosk apps are a full screen app, and the user can leave it with a gesture, uninstall it, or see the launcher. The difference the README draws is Device Owner mode, described as true lockdown, and it is a specific Android mechanism rather than a setting in the app. A device owner is a profile with administrative privileges provisioned at setup time, and it is what allows an app to lock the task, control boot behaviour, apply status bar policies and handle PIN access without the user being able to intervene. The capability table lists lock task, boot behaviour, status bar policies and PIN access under device control, and the comparison table records that both FreeKiosk and the paid alternative support Device Owner mode, so this is table stakes rather than a differentiator. What is a differentiator is the rest of the row set. MQTT with Home Assistant discovery is marked as available in FreeKiosk and absent in Fully Kiosk, and the automation row counts 40 plus REST endpoints. The architectural point is that the Android policy work happens in native code, because the tech stack lists React Native and TypeScript for the interface with Kotlin native modules for Android policy and system control, and the package dependencies confirm the shape with react-native-webview for the WebView mode, react-native-brightness-newarch for screen control, react-native-keychain for credential storage, react-native-fs, react-native-vision-camera, react-native-paper for the interface and i18next with react-i18next for translations.

Four kiosk modes, and the documentation map that explains them

The capability table lists the modes as WebView, External App, Dashboard, and a Media and Multi-App evolution, and the docs map links each area to a file. The WebView mode is the one most deployments want, since a dashboard or a menu board is a web page and pinning it in a controlled WebView removes the browser chrome and the address bar. External App mode is for the case where the thing you want to display is already an installed application, which is the point of the single purpose device and the POS use case. Dashboard mode is the project calling out its own interface as a display target. The documentation structure is worth noting on its own, because the README says it gives the essentials and points to complete docs in the docs/ directory, and the map lists Installation Guide, Features and Modes, Integrations Overview, REST API Docs, MQTT Docs, ADB Configuration, Roadmap and Changelog, and a Development Guide. The ADB Configuration page is the one to read first for a fleet, because headless ADB provisioning for mass rollout is listed as a core capability and the install flow is built around it. There is also a per-platform package.json with a patches/ directory and a postinstall script that runs patch-package, which tells you the project applies patches to its own dependencies at install time, which is a normal React Native practice and a useful signal for anyone auditing the build.

Installing and provisioning a tablet

The install path is short because most of the work is provisioning rather than installation. The README's four steps are to download the latest APK from Releases, install it on an Android 8.0 or newer tablet, configure the URL or app plus a PIN, and start kiosk mode. For production lockdown the device has to be enrolled as device owner, and that is a single adb command.

adb shell dpm set-device-owner com.freekiosk/.DeviceAdminReceiver

That command has consequences worth stating plainly. The device owner can only be set on a device that has no accounts and no existing user, so in practice a fresh tablet from the box, or one that has been factory reset. On a used device you have to remove the accounts first, and if the tablet was already enrolled under Google you will be fighting the factory reset wizard. The project calls this out from the other side too, because a factory-reset tablet can be provisioned end to end by scanning a QR code at the Android setup wizard, which is the intended path for the fleet and the reason the cloud exists. So there are two provisioning routes, adb for a single device under your hands and QR for a rollout, and the second one currently depends on the open beta cloud.

The cloud is the part to plan around, not the app

FreeKiosk Cloud is described as an open beta, self-service sign-up, available from v2.0.0-beta.1, and the README is unusually clear about its limits. The v2.0.0-beta.x builds are published as GitHub pre-releases, and the wording is that the feature works and is in daily use, but the OTA update path, QR provisioning and Lock Mode behaviour have not yet been proven across enough real hardware for the project to call it done. The cloud itself offers live telemetry, configuration pushed to devices or groups, remote commands, screenshots, and over-the-air app updates. The part that decides whether you can rely on it is the promise about the server. The management server will be released as open source so you can self-host it, and the project says that is the intended end state rather than an afterthought, with the reason given plainly, that a kiosk platform you cannot host yourself is only half free, and that it is being held back until it is stable and feature-complete rather than publishing something painful to run. No date is set, and the README says it would rather say that plainly than announce a date it might miss. The good news for a local-only deployment is that the app itself is unaffected. It stays free and MIT licensed, the cloud is entirely opt-in, nothing leaves the device until you enroll, and every kiosk feature, the REST API and the MQTT integration work exactly as before without a cloud account, and always will.

Where the licence and the open beta sit against the paid product

The comparison table in the README is the honest summary of the trade. On price, FreeKiosk is free and Fully Kiosk is paid per device. On open source, FreeKiosk is MIT and the other is closed source. Device Owner mode and the REST API are both present in each. MQTT with Home Assistant discovery is present only in FreeKiosk. Cloud fleet management is where FreeKiosk is behind, marked as an open beta against a delivered feature in the paid product, and self-hostable management server is marked as planned once stable against hosted only. So the pattern is clear and unusual. The local capabilities of the kiosk app are at parity or better, and the gap is entirely in the fleet management layer, where the commercial product is the finished thing and FreeKiosk is a beta with a stated intention to open it. The MIT licence covers the app, and the README says the cloud is opt-in, which is a licensing and architecture point rather than a pricing one, since an enrolled device starts talking to the vendor's servers. The roadmap snapshot shows the sequence: v1.2.x for reliability and operational hardening, already shipped, v2.0.0-beta.x for cloud fleet management in open beta, v2.0.0 for the cloud out of beta once the OTA update path, QR provisioning and Lock Mode behaviour are proven on real fleets, and later the management server released for self-hosting. The repository is not archived and the last push was on 2026-10-16, so the bet you are making is on the beta maturing, and the release list on record shows the beta line moving quickly, with v2.0.0-beta.6 on 2026-10-14 covering shared tablets, cloud and Portuguese, v2.0.0-beta.5 on 2026-10-07 covering printing, dashboard and tablet fixes, and v2.0.0-beta.4 on 2026-09-24 covering fleet reliability and Wi-Fi push.

Editorial conclusion

FreeKiosk suits a team that has a shelf of Android tablets to turn into signage, dashboards or single purpose devices and wants to avoid a per device licence fee, since the app itself is MIT licensed and every kiosk feature, the REST API and the MQTT integration work with no account at all. It is the wrong tool if you need fleet management today, because the cloud is an open beta and the README says the OTA update path, QR provisioning and Lock Mode behaviour have not yet been proven across enough real hardware. It is also the wrong tool if you cannot run adb against the devices, since the Device Owner path that gives real lockdown is provisioned over adb. Before you roll it out, decide explicitly whether you are enrolling devices in the cloud, because nothing leaves the device until you enroll, and check Lock Mode and the update path on your own hardware first.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. RushB-fr/freekiosk on GitHub