RushB-fr/freekiosk v1.2.20-beta.5

FreeKiosk v1.2.20-beta.5 - WebView Stability & Mode Switching

on GitHub

Fixed

• 🔄 Kiosk WebView refreshes randomly, wiping user input (#211): On some devices the WebView would reload on its own at random, losing anything the user had typed, even with auto-reload, the return button, and auto-restart all disabled. Root cause: MainActivity (the React Native host) declared android:configChanges for only the common set (keyboard|orientation|screenLayout|screenSize|smallestScreenSize|uiMode), so any other runtime configuration change recreated the whole activity, tearing down and rebuilding the React view tree, which reloads the WebView from its start URL and discards in-page state. The triggers are system-driven and unrelated to any FreeKiosk setting: a font-size or display-size (density) change, a locale change, and, on cellular tablets, a carrier/network change (mcc/mnc) as the modem registers/handoffs. Fixed by broadening MainActivity's configChanges to also handle fontScale|density|locale|layoutDirection|navigation|touchscreen|colorMode|mcc|mnc, so React Native absorbs these changes in place (updating dimensions/appearance) instead of the activity being recreated. The legitimate WebView remount on an actual renderer-process death (#198) is unchanged. Reported by @faif.

• 🔀 Documented POST /api/mode (and MQTT mode) command did nothing: "Endpoint not found" (#209): The REST doc (docs/rest-api.md) and MQTT doc (docs/MQTT.md) both documented a runtime display-mode switch, but the command was never wired on the native side, so POST /api/mode returned "Endpoint not found" and publishing to the MQTT set/mode topic was ignored. Fixed by adding the POST /api/mode route and handleSetMode() in KioskHttpServer and a mode case in the MQTT mapEntityToCommand(), both emitting the existing setMode command. The pre-existing JS onSetMode handler was also rewritten to cover all three display modes with clean transitions in every direction: it now persists the requested mode and target to storage and re-runs the app's canonical loadSettings() setup path (the same one used when you change the mode in Settings), instead of hand-rolling a partial per-mode switch. This fixes a real transition bug (switching external_app → webview never brought FreeKiosk back to the foreground, so the webview rendered invisibly behind the still-foreground launched app: it now calls KioskModule.bringToFront()), and adds the two previously missing cases: media_player (uses the stored playlist) and External App without a package (restores the stored multi-app grid). Because it delegates to loadSettings(), each mode is set up exactly as at boot (media items loaded, overlay/monitor started or stopped, dashboard variant honored) and the switch now persists across an app restart. Modes: { "mode": "webview", "url"?: "..." }, { "mode": "external_app", "package"?: "..." }, { "mode": "media_player" }. Docs updated to match. Reported by @alogblog.

• 🔐 Native Android screen-lock never prompts after screen off/on in multi-app / kiosk mode (#208): With a device that has both FreeKiosk (Device Owner, lock-task) and a native Android screen-lock (PIN/pattern/password) configured, the screen-lock silently never re-appeared after the screen turned off and back on: the device woke straight into the kiosk with no password. Root cause: Android disables the keyguard while in LockTask mode unless the app opts back in via LOCK_TASK_FEATURE_KEYGUARD, and FreeKiosk's setLockTaskFeatures() calls never set that flag. Fixed by adding the flag on every path that configures lock-task features (MainActivity.enableKioskRestrictions, KioskModule.startLockTask, and, importantly for the reported multi-app scenario, AppLauncherModule when re-applying features to launch a whitelisted app, which previously dropped the flag and re-suppressed the lock). It is gated on the existing opt-in "System screen-lock compatibility" setting (Security, Device Owner only, off by default) and a secure lock actually being set (KeyguardManager.isDeviceSecure()), the same gate as the boot deferral added in #199, so the keyguard is honored at runtime only when the admin has explicitly enabled screen-lock compatibility. Zero behavior change when the toggle is off or no screen-lock is set. ⚠️ Because this makes the native lock work as intended, the device then requires the password on every wake (as well as after every reboot), suitable only for attended devices; the in-app hint makes this explicit. The boot path is unchanged and remains opt-in. Reported by @23575437.