[M-khalifa]

HomeKeyService swaps a tap's target for its front: entry while the button's own app is already in front, but InputKeyService read only the plain entry. With both helpers bound, both call RemoteKeys.handle for the same press and the first copy decides, so when InputKeyService saw the release first the plain target opened and the front: alternative was lost. The selection now lives in RemoteKeys.tap(), with the package in front kept in RemoteKeys.frontPackage (still set only by HomeKeyService's window events, cleared when it goes away), and both helpers use it. With only InputKeyService bound nothing is in front and it opens the plain entry, as before; setups without front: entries are unchanged. docs/launcher.md now says front: entries need HomeKeyService bound and InputKeyService follows it then (with INPUT_KEY_SERVICE=1 alone nothing is in front). Found by reading the code, then reproduced on a TV (below).

Tested on: TCL Q6 (G10), Google TV 14, build UTT2.250416.001

On the TV, HomeKeyService and InputKeyService both on, app_keys: ["29:<YouTube>", "front:29:com.android.tv.settings"], the key pressed through a USB keyboard (so it reaches the helpers the way a remote button does; input keyevent does not reach them on this set): press once from Home (YouTube opens), then again with YouTube in front, three runs per APK. main: the second press opened Settings in 2 of 3 runs and YouTube again in 1 (the front: entry lost to InputKeyService). This branch: Settings in 3 of 3.

• gradlew --no-daemon testReleaseUnitTest lintRelease assembleRelease: BUILD SUCCESSFUL, unit tests pass (RemoteKeysTest 30/30), lint 0 errors (98 warnings, as on main), release APK 587,353 B (main: 587,321 B, +32 B; gate 589,824 B).
• New JUnit RemoteKeysTest.tapPicksTheFrontEntryOnlyWhileTheButtonsAppIsInFront covers the shared selection. It does not compile on main (no RemoteKeys.tap), so it is red there, and with tap() changed to always return the plain target it fails (mutation check); it cannot drive the services' onKeyEvent, which needs a real KeyEvent.
• Python tests that pin the helpers' source (test_sony_settings_key_note, test_key_filter, test_app_keys_action_words, test_home_long_press_home and others): OK.

Overlaps #3600 next to HomeKeyService.onKeyEvent's app_keys lookup (different lines in the same block); whichever merges second needs a small rebase, which I will push.

If this touches the launcher

• Verified on a real TV (above)
• D-pad checked from every edge (n/a, no UI change)
• No network, no background service, no new permission
• New strings in values/strings.xml and the other values-* folders (n/a, no strings)
• Anything TV-specific is in config.xml or a theme, not in code

---

Reviewed with cross-review 1.2.1 (SkillArray, MIT license): https://github.com/M-khalifa/SkillArray

[github-actions]

maintainer-bot review · this one needs a maintainer decision

Thanks for the PR! Couldn't review this one automatically; it goes to the maintainer.

Checks

• Launcher: 29 lines changed in launcher/ (tests not counted)
• OK: no new permission, no network use
• Note: touches the Home/launch path: HomeKeyService.java
• Size: size/S (+40 -10, 5 files)

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