Feature request -> Lite Mode: optional configurable foreground app (let the watchdog keep a chosen dashboard app on top)

[chochb]

Context
In Lite Mode the WebView is disabled and KioskService no longer brings MainActivity to the foreground — which is correct, but it means ShellyElevate doesn't manage any foreground app. Keeping the chosen dashboard app (HA Companion, Fully Kiosk, WallPanel) alive/on top is left entirely to an external launcher.

Request
Add an optional setting, e.g. liteForegroundPackage (string, default empty), and an optional liteForegroundActivity. When Lite Mode is on and this is set:

• BootReceiver launches that package on boot (instead of nothing).
• The existing KioskService 30s watchdog checks whether the configured package is foreground; if not, it relaunches it (the same mechanism already used for MainActivity in normal mode, just pointed at a configurable target).
• Empty value keeps current behaviour (no foreground management).

Why
This reuses the watchdog/boot logic already in place and turns Lite Mode into a full appliance experience with a third-party dashboard: crash/background recovery for the chosen app, without needing a separate kiosk launcher. Settable via the existing POST /settings so it fits the current config model.

Offer to help
Happy to actively contribute here, not just test. I have three different Wall Display models on hand — X2, X2i and XL — so I can validate behaviour across the model range, which should help catch the model-specific edge cases. Specifically I can:

• test builds on real hardware (X2 / X2i / XL) and provide logs/feedback,
• validate the watchdog and boot behaviour across reboots/crash scenarios on each model,
• and contribute the code itself via PR — wiring liteForegroundPackage/liteForegroundActivity into BootReceiver and the existing KioskService 30s foreground check, plus the POST /settings handling.

Just let me know your preferred approach for the watchdog target resolution and I'll align the implementation with the existing patterns.

[RapierXbox]

ok so what do you think of this. i was thinking about this for a while but never got around to it. i want to move away from lite mode entirely and replace it with a new setting called something like frontend or renderer. there you could choose between the standard webview with url bar or an entirely different application or maybe even streaming a prerendered chrome instance from a server. that last one is more of a future idea but it would be pretty cool since you could then even show camera feeds on underpowered hardware. anyway just looking for some feedback

[chochb]

Like the abstraction — folding liteMode into a mode selector is the right move. One pushback from running the external-app setup (HA minimal foregrounded) for a while: I'd pull "external app" out of the renderer concept. A WebView lives in ShellyElevate's process, so attach/reload/swipe/wake all make sense on it. An external app is its own process — ShellyElevate can only launch it and keep it foregrounded. Same interface for both = leaky abstraction (attach(container)/reload() are meaningless for an external app). Suggestion — two orthogonal settings: - `renderer` (embedded): `webview` | `none` | `stream` later. `liteMode:true` migrates to `none`. - `foregroundApp`: package to keep foregrounded via watchdog, or empty. The "default app" case modeled as a launcher/watchdog function, not rendering. Still removes liteMode, just doesn't disguise external-app as a renderer. Two open points: 1. Move hardware hooks (proximity wake, brightness, sleep) into the service so they work in every mode — with an external app up front, ShellyElevate draws nothing but should still own screen + sensors. 2. Watchdog: boot-launch only, or re-foreground on crash/backgrounding? The latter is the real wall-display need. Streaming: keep it a separate issue — it's a remote-desktop client (decode + input backchannel), different tier. Caveat: hardware too weak to render camera feeds locally still has to decode the stream, which is often the real bottleneck.

…

Am 18.06.2026 um 19:14 schrieb RapierXbox ***@***.***>: RapierXbox left a comment (RapierXbox/ShellyElevate#80) <#80 (comment)> ok so what do you think of this. i was thinking about this for a while but never got around to it. i want to move away from lite mode entirely and replace it with a new setting called something like frontend or renderer. there you could choose between the standard webview with url bar or an entirely different application or maybe even streaming a prerendered chrome instance from a server. that last one is more of a future idea but it would be pretty cool since you could then even show camera feeds on underpowered hardware. anyway just looking for some feedback — Reply to this email directly, view it on GitHub <#80?email_source=notifications&email_token=AGZ4KQGJXFKXBGBN4OSZMU35AQPNVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGQ2DANJSGA2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4744405204>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGZ4KQDA4BEAUHNLR5FZVYD5AQPNVAVCNFSNUABFKJSXA33TNF2G64TZHM4DANZWGY2TENBTHNEXG43VMU5TINRYGE4DENRUGAZKC5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AGZ4KQEKQ7ZQD27WI5XCOVD5AQPNVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGQ2DANJSGA2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AGZ4KQFM7VLS2P5DINLB2E35AQPNVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGQ2DANJSGA2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.