Introduction

In cloud computing scenarios, Android terminals serve as more than just display and input interfaces. Users often connect USB peripherals such as flash drives, printers, barcode scanners, and serial devices to their phones, tablets, or cloud laptops, expecting these local devices to function seamlessly within remote cloud desktops.

This capability is commonly referred to as USB redirection. At its core, USB redirection involves the local terminal discovering and accessing physical USB devices, while the remote desktop loads drivers and utilizes the devices, with USB requests and responses forwarded over a network protocol.

While USB redirection has established solutions for Linux or Windows cloud desktops, the Android platform presents unique challenges. Android's application sandbox, user authorization, system broadcasts, and storage permission policies significantly impact whether USB devices can be discovered, opened, have their complete information retrieved, and reliably forwarded to the underlying protocol layer.

This article addresses the fundamental challenges of Android USB redirection: why Android cannot simply reuse Linux-based solutions, and why practical engineering often necessitates preparing both a "high-privilege" and a "standard-privilege" implementation path.

This discussion will focus on publicly available technical approaches, avoiding internal project details such as module names, functon names, thread names, business interfaces, and specific code.

USB Redirection's Role in Cloud Computing

From a user's perspective, USB redirection appears straightforward: plug a USB device into the local terminal, and the same device appears in the remote cloud desktop.

From a system perspective, it involves at least four stages:

1. The local terminal discovers the USB device.
2. The local terminal collects device descriptor information.
3. The local terminal establishes a redirection connection with the remote desktop.
4. Remote requests are translated into local USB operations, and the results are returned.

A more detailed breakdown of the common workflow is as follows:

USB device inserted into Android terminal
    -> Terminal system detects plug/unplug event
    -> Client retrieves device information
    -> UI displays redirectable devices
    -> User selects device and initiates redirection
    -> Client establishes connection with cloud desktop
    -> Remote side loads or matches device driver
    -> USB requests and responses traverse the network

The most critical step is "terminal system detection of plug/unplug events and retrieval of device information." On Linux, this is typically achieved through device files, udev rules, and libraries like libusb. However, standard Android applications cannot directly adopt this model.

Differences in USB Access: Android vs. Linux

Although Android is based on the Linux kernel, application access to USB devices differs significantly from traditional Linux.

Linux Device File Model

In Linux, USB devices are typically exposed under the /dev/bus/usb/ directory. User-space programs can interact with USB devices via these device files, provided they have the necessary permissions.

Common methods include:

• Using udev rules to control device file permissions.
• Enumerating USB devices with libusb.
• Reading device descriptors, configuration descriptors, interfaces, and endpoint information.
• Opening devices and submitting control, bulk, and interrupt transfer requests.

This model offers flexibility. With proper permission handling, user-space programs can build complete USB/IP server capabilities, directly managing device access and forwarding low-level requests.

Android Application Sandbox Model

Despite its Linux foundation, standard Android applications run within a sandbox. They cannot by default access device files under /dev/bus/usb/ or bypass the system to directly control the USB host controller.

Standard Android applications typically access USB devices only through the system-provided UsbManager API, which requires:

• Declaring USB Host capability in the manifest.
• Listening for system USB plug/unplug broadcasts.
• Obtaining the system-provided UsbDevice object.
• Requesting user permission to access the device.
• Opening the device after permission is granted.

This model emphasizes user awareness and system security, preventing applications from silently manipulating peripherals but also limiting the control capabilities required for USB redirection systems.

Core Conflict in Android USB Redirection

Protocols like USB/IP or similar peripheral redirection solutions require strong low-level control capabilities on the local side.

They typically need to:

• Enumerate devices.
• Retrieve complete descriptors.
• Open devices.
• Claim interfaces.
• Submit low-level USB requests.
• Handle device disconnection, timeouts, cancellations, and error recovery.

Conversely, the Android standard permission model restricts applications to accessing devices only within the system framework.

This creates a conflict: USB redirection demands comprehensive USB control, while standard Android applications provide only a controlled access gateway.

This conflict manifests in several engineering challenges:

• Plug/unplug events cannot be actively monitored at a low level; reliance on system broadcasts is necessary.
• Device information may be incomplete, with some descriptors or string information potentially missing.
• Device opening requires user authorization, preventing fully transparent operation.
• Device handle lifecycle is influenced by Android system management.
• For storage devices like USB drives, the association between device identity and mount paths may be unstable.
• Behavior may vary across different Android versions and manufacturer ROMs.

Consequently, Android USB redirection typically cannot rely on a single implementation strategy.

The Need for Dual Technical Paths

In real-world projects, Android device environments vary widely.

Some devices are enterprise-customized terminals, cloud laptops, or specialized tablets where applications can obtain system privileges or even run as pre-installed components. Others are standard smartphones or tablets where applications must adhere to standard Android rules.

These two device categories have different capability boundaries, necessitating different technical approaches.

High-Privilege Path

The high-privilege path is suitable for system-controllable devices, such as:

• Enterprise-customized Android terminals.
• Cloud laptops or specialized tablets.
• System-signed applications.
• Custom ROM or pre-installed service scenarios.

In these environments, the client application has the opportunity to gain USB access capabilities closer to Linux, potentially using low-level USB access libraries or system service capabilities directly in the Native layer.

Key characteristics of the high-privilege path include:

• Ability to actively monitor USB hot-plug events.
• Capability to read more complete device descriptors.
• Direct device opening and submission of low-level requests.
• More natural reuse of USB/IP protocol stacks.
• Performance and compatibility closer to Linux-based solutions.

This path is ideal for terminal forms requiring high compatibility, low latency, and stability for peripherals.

Standard-Privilege Path

The standard-privilege path is designed for ordinary Android smartphones and tablets.

In these environments, applications cannot depend on Root access, system signatures, or custom ROMs. They must utilize official Android APIs for device discovery and access.

Key characteristics of the standard-privilege path include:

• Device plug/unplug detection via system broadcasts.
• Device object acquisition via UsbManager.
• Device opening requiring user authorization.
• Java layer assuming greater responsibility for device management.
• Native layer needing to obtain device information and access handles via Java callbacks.

Its advantages are compliance, distributability, and broad applicability. The trade-off is limited low-level capability, potentially poorer compatibility with certain device types, and the need to handle more Android framework variations in engineering.

Data Flow Differences Between the Two Paths

The most significant difference between the two paths lies not in remote protocol handling, but in the local device discovery and opening mechanisms.

High-Privilege Path: Bottom-Up Active Discovery

The high-privilege path more closely resembles Linux.

Physical USB device inserted
    -> USB controller generates hardware event
    -> Kernel USB subsystem processes event
    -> Native layer USB event loop captures change
    -> Reads device descriptors and interface info
    -> Reports device list to business layer
    -> User selects device
    -> Native layer opens device and handles protocol forwarding

The key to this chain is the Native layer's direct access to lower-level USB events and device access points.

Therefore, the high-privilege path can treat the Android terminal largely as a Linux device. Device discovery, information collection, opening, and protocol processing can be centralized in the Native layer, with the Java layer primarily responsible for UI, configuration, and task triggering.

Standard-Privilege Path: Top-Down Passive Response

The standard-privilege path relies on the Android framework.

Physical USB device inserted
    -> Android system services handle device event
    -> System sends USB insertion broadcast
    -> Application BroadcastReceiver receives broadcast
    -> Java layer obtains device object via UsbManager
    -> Requests user authorization if necessary
    -> Java layer notifies Native layer of device change
    -> Native layer queries Java layer via callback when information is needed

The key to this chain is the Java layer becoming the gateway for device access.

The Native layer can still handle protocol processing, network communication, and task scheduling, but it cannot assume direct enumeration and opening of all USB devices. Often, it must query the Java layer, which returns device lists, details, or opened handles via Android APIs.

Overall Architecture Design

From a public architecture perspective, the Android USB redirection client can be divided in to three layers:

Android Adaptation Layer
    -> UI display, system broadcasts, permission requests, UsbManager calls

JNI / Native Bridge Layer
    -> Java-Native call translation, callback registration, data structure conversion

Peripheral Function Layer
    -> USB/IP protocol processing, device request forwarding, network communication, task scheduling

The responsibility distribution among these layers differs between the two paths.

In the high-privilege path:

• The Android Adaptation Layer is lighter.
• The Native layer handles device discovery, opening, and protocol processing.
• The Peripheral Function Layer can more closely resemble Linux implementations.

In the standard-privilege path:

• The Android Adaptation Layer carries more weight.
• The Java layer must handle broadcasts, authorization, device objects, and handle acquisition.
• The Native layer must support callback-based device queries.
• The Peripheral Function Layer must adapt to the reality of "limited device access capability."

Engineering Characteristics of the High-Privilege Path

The core objective of the high-privilege path is to replicate Linux-like USB/IP capabilities on customized Android devices.

Initialization

Initialization typically involves:

• Setting up the Native layer USB access environment.
• Creating USB event listening tasks.
• Establishing network connection and protocol processing tasks.
• Setting up result callbacks between Java and Native layers.
• Initializing device state tables and task queues.

The Java layer primarily handles configuration and UI, while the Native layer manages the actual USB lifecycle.

Device Discovery

Upon device insertion, the Native layer can receive hot-plug notifications via low-level event mechanisms and read comprehensive device information.

Common information includes:

• VID/PID.
• Device class.
• Configuration descriptors.
• Interface descriptors.
• Endpoint descriptors.
• String descriptors.
• Device connection location or port-related information.

This information is organized into data presentable to the business layer for user selection.

Redirection Process

After the user initiates redirection, the high-privilege path typically completes the process in the Native layer:

1. Validate device status.
2. Open the target USB device.
3. Claim interfaces or switch device access states if necessary.
4. Establish connection with the remote cloud desktop.
5. Complete protocol handshakes like device listing and import.
6. Create data send/receive loops.
7. Continuously process remote requests and local USB responses.
8. Release handles, restore state, and clean up tasks upon disconnection.

The high-privilege path offers advantages like a shorter chain, strong control, and complete device information. Its limitations are clear: deployment depends on the system environment and is unsuitable for distribution via standard app stores.

Engineering Characteristics of the Standard-Privilege Path

The core objective of the standard-privilege path is to enable basic USB redirection capabilities on ordinary Android devices without violating the Android security model.

Its challenge extends beyond merely "calling UsbManager"; it involves adapting the originally low-level peripheral redirection protocol layer to Android's permission-based device access model.

Increased Java Layer Responsibility

In the standard-privilege path, the Java layer typically must handle:

• Registering for USB plug/unplug broadcasts.
• Receiving device insertion and removal events.
• Maintaining Android-side device objects.
• Initiating user permission requests.
• Opening devices and obtaining usable access handles.
• Passing device information to the Native layer.
• Notifying the Native layer to clean up state upon device removal.

This means the Java layer is no longer just a UI shell but a critical component in the device access chain.

Native Layer Requires Callback-Based Query Support

In Linux or the high-privilege path, the Native layer can actively anumerate devices.

In the standard-privilege path, the Native layer often needs to request information from the Java layer, such as:

• The current list of devices.
• Basic information for a specific device.
• Whether a device has been authorized.
• The access handle available for Native layer use after a device is opened.

Therefore, the Native layer must establish a mechanism for "reverse-calling Java." This can be understood as: the Java layer first registers a set of callback capabilities with the Native layer, which then invokes these callbacks when device information is needed.

While this increases implementation complexity, it allows maximum reuse of the existing peripheral function layer, adapting only the device access gateway to the Android framework.

Comparison of the Two Paths

Dimension	High-Privilege Path	Standard-Privilege Path
Target Devices	Custom terminals, system-signed apps, pre-installed services	Ordinary smartphones, tablets
USB Access Point	Low-level USB access capabilities	Android UsbManager API
Plug/Unplug Events	Low-level hot-plug events	System broadcasts
Device Information	More complete	Limited by Android API
User Authorization	Can be handled by system capabiliteis	Typically requires user dialog
Protocol Reuse	Closer to Linux solutions	Requires Java/Native adaptation
Compatibility	More friendly to USB/IP	Subject to OS version and ROM variations
Distribution	Suitable for customized devices	Suitable for standard app distribution
Engineering Risks	System permission and deployment risks	Authorization, compatibility, handle lifecycle risks

Path Selection Recommendations

If the target devices are controllable enterprise terminals where system images, signature permissions, and pre-installed services can be uniformly managed, the high-privilege path is better suited for delivering full USB/IP capabilities.

If the target devices are ordinary consumer Android devices, the standard-privilege path should be prioritized. Its low-level capabilities are limited, but it complies with the Android security model and is easier to distribute and maintain.

A more practical product strategy is to support both paths concurrently:

• Enable the high-privilege path on customized terminals for full capability and better compatibility.
• Enable the standard-privilege path on ordinary phones and tablets for compliance and distributability.
• Implement specialized strategies for different device types like cameras, audio, keyboards/mice, printers, and disks.
• Provide clear UI endications of capability differences based on the permission environment.

Summary

The primary challenge in Android USB redirection lies not in the USB/IP protocol itself, but in Android's permission model.

Linux-style USB redirection relies on strong low-level device control, while standard Android applications emphasize sandbox isolation and user authorization. This creates a natural tension.

Therefore, a mature Android cloud computing USB redirection solution often needs to support both a high-privilege path and a standard-privilege path. The former is suitable for customized devices, offering strong capabilities but higher deployment barriers. The latter is suitable for ordinary terminals, offering better compliance but limited capabilities.

The next article will delve into the implementation details of the standard-privilege path: how to integrate USB access capabilities within the Android framework—via system broadcasts, UsbManager, Java/Native callbacks, and device handle passing—into the peripheral redirection chain.