Remote ADB Server Fails Shell Check on Older Remote ADB Versions (e.g., on android 5.1)

[hunter-dev-916]

When the client application connects to a remote ADB server that corresponds to an older ADB version (specifically, one that does not advertise modern host features, such as version 5.1 from an older Android platform-tools release), it fails to initiate a shell session.

The resulting error message is:

"Remote ADB server does not support shell feature"

Reproduction Context
An android with version approximately 5.1 (or any older version lacking modern feature flags).

Client Behavior: The client application executes an internal check for supported host features before attempting a shell connection.

Expected Behavior
The shell session should successfully start, as the basic ADB shell functionality is confirmed to be working:

Using the official Android Platform-Tools utility, the command adb shell works successfully against the same older ADB server instance. This confirms that the underlying server does support the core shell protocol, even without newer feature flags.

Actual Behavior
The connection is rejected by the client-side logic due to the absence of specific feature flags, preventing shell execution.

Root Cause Analysis
The client-side code performs a strict check against the features reported by the ADB server via the host-features command:

let supported_features = self.host_features()?;
if !supported_features.contains(&HostFeatures::ShellV2)
    && !supported_features.contains(&HostFeatures::Cmd)
{
    return Err(RustADBError::ADBShellNotSupported);
}

This logic dictates that a shell connection requires the server to explicitly advertise either the ShellV2 or Cmd features.

Older ADB daemon on old android device (like 5.1) do not return these any features in the response to the host-features command (try adb host-features), but they still support the basic, legacy shell: protocol. Because the required features are missing, the client incorrectly concludes that the shell is unsupported and returns an error before even attempting the connection.

Suggested Resolution
To maintain backwards compatibility, the shell support check should be modified to:

Prioritize Modern Features: Check for ShellV2 or Cmd first.

Fall back for Legacy Support: If those modern features are absent, the client should attempt the legacy shell connection (shell:) anyway. The feature check should only fail if the server is new enough to support these features and explicitly excludes them, or if the actual connection attempt fails.