Close projection-launched app on exit

[ptuchik]

What changed

• remember whether the projected app task was already running or was launched by BYDMate
• restore pre-existing tasks to the tablet on the second steering-wheel press
• remove tasks launched solely for cluster projection on the second press
• add a narrow helper Binder transaction for removing one task by ID
• fall back to restoring the task to the tablet when task removal is unsupported or fails

Why

launchAndForce() automatically launches a missing projection target, but the projection manager previously retained only the package name. On exit it therefore always moved the task to display 0, even when BYDMate had launched the app solely for projection.

The manager now records the task origin before projection and applies the matching exit behavior without force-stopping the package.

User impact

• App already open: tablet → cluster → tablet
• App initially closed: launch on cluster → close task

Validation

• ./gradlew :app:testDebugUnitTest :app:lintDebug --stacktrace
• focused projection state and Binder marshalling regression tests
• git diff --check

Physical validation on a DiLink 5.0 head unit is still recommended because ActivityTaskManager.removeTask() is a private/vendor-dependent path. The implementation safely restores the task to the tablet if removal is unavailable.

[AndyShaman]

Hi @ptuchik — thanks for a genuinely well-crafted PR. The daemon protocol extension, the marshalling tests and the restore fallback all follow the codebase conventions closely, and the problem you describe is real. After walking through how the steering-wheel star is actually used on this head unit, we've decided not to take the change — let me explain the workflow it would break.

The cluster is not touchable. Building or changing a route can only be done on the tablet (main display). So the star works as a display toggle, not an "exit":

1. Navigator lives on the cluster — often map-only (speed cameras, traffic), with no route at all
2. The driver decides they need a route → star → Navigator moves to the tablet alive
3. They build the route by touch → star → Navigator goes back onto the cluster, now guiding

Why the origin heuristic misfires here: cluster projection is typically started by an automation right when the car starts, when nothing else is running yet — so the Navigator task is virtually always classified as LAUNCHED_FOR_PROJECTION. With this PR, every star press to leave projection would remove the task — precisely at the moment the driver pulled Navigator to the tablet to build a route. The map-only → "now I need a route" transition becomes impossible without relaunching the app.

If auto-close is valuable for your use case (map-only driving where a route is never built), we think the meaningful close signal is not who launched the task but whether route guidance is active: a task with live guidance must never be removed, while a map-only session is disposable. It would also need to be opt-in behind a setting, since the default star semantics must stay "move between displays". If that matches how you drive, feel free to open an issue and we can design it on that basis.

Thanks again — the TX_REMOVE_TASK groundwork is nicely done, and we may reuse the idea later behind a guidance-aware gate.

[ptuchik]

Thanks for detailed and explanatory answer, but it would kill the task only if it was launched via button, so if the user wants to play with routes or navigation, he can open from tablet and then the full behavior will be as previously. Anyways if he wants to set some destination and route a navigation he must do multiple touches on tablet and so just one more touch to open app on tablet would not be a problem, but in case he wants just see the map on cluster then close, with this PR he could start with button and stop with button.

Anyways, thanks for review!
Regards,