Implement Android package launch command

[SamratB8]

Summary

Add service-layer support for launching an installed Android application package on a selected device or emulator.

The implementation should determine whether the package has a launchable activity and should return a structured result when the package cannot be launched.

This issue should include the ADB service and a basic launch action in the Apps interface.

Background

An installed package identifier does not always directly identify the activity that Android should open.

The implementation must therefore use a reliable ADB-supported launch strategy instead of assuming a fixed activity name.

Dependencies

This issue depends on:

• Issue Create process runner for executing ADB commands #4 — Create process runner for executing ADB commands
• Issue Add connected-device details panel #31 — Add connected-device details panel
• Issue Implement installed-package listing through ADB #32 — Implement installed-package listing through ADB
• Issue Display installed Android packages in WinDroid Studio #33 — Display installed Android packages in WinDroid Studio

Launch Strategy

Research and use a reliable command such as:

adb -s <device-serial> shell monkey -p <package-name> -c android.intent.category.LAUNCHER 1

or another properly justified ADB method that resolves and launches the package’s main activity.

Do not hardcode an activity name such as:

.MainActivity

because activity names differ between applications.

Proposed Service API

Task<AdbCommandResult> LaunchPackageAsync(
    string deviceSerial,
    string packageName,
    CancellationToken cancellationToken = default);

Validation Requirements

Before running the command:

• Device serial must be present
• Package identifier must be present
• Values must be passed as separate process arguments
• Control characters should be rejected
• ADB must be available

Package identifiers should not be interpolated into a shell-command string.

Service Requirements

The service should:

• Use the shared process runner
• Target the explicitly selected device
• Run asynchronously
• Support cancellation
• Capture standard output
• Capture standard error
• Capture exit code
• Return a clear success result
• Return a clear not-launchable result
• Return useful output for missing packages
• Avoid throwing for expected command failures

WinUI Requirements

In the Apps interface:

• Allow a package to be selected
• Add a Launch action
• Disable Launch when no package is selected
• Disable or guard the action while launching
• Display the result in the output panel
• Show a clear error if the selected device disconnects
• Avoid launching a package on the wrong device after selection changes

Tasks

• Research and document the launch command
• Add a launch-package service method
• Validate device serial and package identifier
• Use safe process arguments
• Return a structured command result
• Add cancellation support
• Add package selection in the Apps UI
• Add Launch button or action
• Add progress state
• Add success and failure logging
• Add tests for validation and command construction
• Handle packages without launcher activities

Error Cases

Handle at least:

• No device selected
• No package selected
• Device disconnects
• Package is not installed
• Package has no launchable activity
• ADB is missing
• Command returns a non-zero exit code
• Operation is cancelled

Out of Scope

This issue does not need to:

• Launch a specific internal activity selected by the user
• Pass Android intent extras
• Open deep links
• Start Android services
• Add shortcuts to the Windows Start Menu
• Create separate Windows windows for Android apps
• Monitor the launched process
• Retrieve app icons or display names

Acceptance Criteria

• A selected launchable package can be started on the selected device.
• The command explicitly targets the selected device.
• Device serial and package identifier are passed safely.
• The implementation does not assume .MainActivity.
• Packages without a launchable activity return a clear message.
• Missing or disconnected devices are handled safely.
• Launch progress and results are shown in WinDroid Studio.
• Standard output, standard error, and exit code are captured.
• The UI remains responsive during launch.
• Relevant command-construction and validation tests pass.
• The full solution builds successfully in Debug and Release configurations.
• No new compiler warnings are introduced.