[wx85105157]

Some firmware (XGIMI/GMUI projectors) drive their settings through a started service instead of a settings activity: the standard android.settings.SETTINGS / WIFI_SETTINGS actions resolve to nothing and the only entry point is the vendor service, which answers its own action with the page to open as a string extra. These changes let a config name that service so the launcher's Settings button, quick panel and Wi-Fi pill start it directly, instead of landing on a debug entry point the user has to click through:

• Config: settings_service / settings_service_action / settings_service_extra / settings_page / settings_page_wifi, read from the config.json overlay, with empty in-code defaults (no config.xml entries: the keys are config.json-only, and keeping them out of the resource table helps the size gate). All empty -> behaviour is unchanged, byte for byte.
• SystemSettings.startSettingsService: starts the named service with the page as the extra.
• MainActivity / HomeKeyService / LauncherSettingsActivity / QuickSettingsActivity: use it for the Settings button, the quick-panel TV-settings row and the Wi-Fi pill, falling back to the usual intent when no service is configured.
• Also: a Settings button/key held ~700 ms opens Launcher settings, for remotes with no other way into them. Timed from the DOWN so a real key repeat or input --longpress is treated as a hold.

Verification: compiled and run on a real XGIMI H3 (Android 8.0); the GMUI settings service is reached from the launcher via the config above. Default-off, config-driven, no new permissions. Size check: release APK 588,961 B (merged with current main incl. HomeSettingsActivity), under the 576 KB gate. The XGIMI H3 config.json that sets these keys lands as a small follow-up once this and the device-list PR (#3197) are in, since a shipped config.json may only use keys the launcher on main already reads (tests/test_shipped_config_keys_are_read).

[github-actions]

maintainer-bot review · this one needs a maintainer decision · Leans: rework (55%)

Thank you for tracking down how XGIMI/GMUI firmware opens its settings through a service; making it config-only with empty defaults keeps every other TV unchanged. Could you move the hold-Settings-to-open-launcher-settings timer (and the settings_key_panel handling in MainActivity) into its own PR, and add a Tested on line for the projector you ran this on?

Why it goes to a maintainer: a bigger launcher change (237 lines) the bot would send back: rework or a home in the showcase/addons is the maintainer's call.
The bot's own suggestion would be: a few changes first.

Checks

• Note: possibly collides with Add XGIMI H3 projector (XK03E, GMUI/Android 8.0) to the device list #3197 (PR 3197 includes the config.json for the GMUI settings-service feature that PR 3198 implements in launcher code; Launcher: reach a TV's settings when they are a service, not an activity #3198 first)
• Note: possibly collides with Launcher: a key in both app_keys and the Settings keys opens only its app_keys target #3600 (both PRs modify HomeKeyService.java on and around line 268 in the onKeyEvent method, changing the order of key handling branches)
• Launcher: 237 lines changed in launcher/ (tests not counted)
• OK: no new permission, no network use
• Note: touches the Home/launch path: HomeKeyService.java
• Size: size/M (+234 -26, 9 files)

This is a suggestion; a maintainer makes the final call. A maintainer can comment /bot review to run it again.

_{Reviewed by maintainer-bot · runs on 0G Private Computer}

[Gathin23]

@wx85105157 thank you for tracing how GMUI opens its settings through a service; keeping it config.json-only with empty defaults is just right. With about 1.7 KB of launcher room left, could you drop the hold-Settings-to-launcher-settings timer from this PR and trim it to the service route alone, then post the release APK's byte change? It needs to land at a few hundred bytes to fit. We'll check back in 7 days.

[SaviorOneZero]

At 770698e, the service-route portion changes Wi-Fi navigation even with all new options empty:

openNetworkPill() (no VPN target) / the Wi-Fi long-click → openNetworkSettings() → openSettingsPage() → ACTION_SETTINGS when no service is configured. Before this PR those entry points passed ACTION_WIFI_SETTINGS to systemIntent. A configured service that fails also falls back to general Settings.

A small local fix keeps the service call and its Wi-Fi/front-page choice inside openNetworkSettings(), but uses open(systemIntent(Settings.ACTION_WIFI_SETTINGS)) when that call returns false. The ordinary Settings button keeps its existing route.

With the three exact routing methods and controlled service/launch boundaries, 5/8 cases pass before, 8/8 after. The failing cases cover the ordinary pill tap, Wi-Fi long-click and failed-service fallback; controls retain service pages, ordinary Settings and VPN-app routing.

This is local Java method-level evidence, not a full Activity, Android UI or TV test. The two-file proposal changes one routing method plus the regression test, adds no dependency, permission, polling or additional service call, and leaves the timer removal you've requested separate. I have not measured the release APK byte change.