Cloud phone-based ADB local debugging method
By initiating an ADB debugging request in the cloud phone management console and establishing a WebSocket connection with the edge proxy service using the local proxy client, the complexity and security issues of cloud phone ADB debugging methods are resolved, achieving an efficient, secure, and transparent ADB connection experience.
Patent Information
- Application Number
- CN202610175787.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-02-06
- Publication Date
- 2026-05-29
AI Technical Summary
Existing cloud phone ADB debugging methods rely on dedicated intermediate servers, which increases system complexity and maintenance costs, poses security risks, has cumbersome and opaque connection links, fragments user experience, and browser solutions have limited functionality and poor compatibility.
By accessing the cloud phone management console through a browser and initiating an ADB debugging request, a secure WebSocket connection is established between the local proxy client program and the edge proxy service, forming a data transmission tunnel from the local TCP listening port to the target cloud phone instance's ADB service port, thus achieving one-stop integration operation.
It simplifies the architecture, improves security, provides a one-stop integrated experience, lowers the barrier to entry, enhances transmission efficiency and interactivity, supports multiplexing, and is compatible with all ADB commands.
Smart Images

Figure CN122120369A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of data processing technology, and in particular to a local ADB debugging method based on a cloud phone. Background Technology
[0002] Currently, in cloud phone usage scenarios, developers or testers typically need to connect to ADB when performing operations such as application installation, log viewing, and command-line interaction. A common remote ADB connection solution uses the SSH protocol as a proxy tunnel. Specifically, an SSH service is deployed on a public-network intermediate server, and an ADB client tool is installed. Users connect to this intermediate server via an SSH client and manually execute commands such as `adb connect [cloud phone internal IP]:port` in the SSH session, thereby establishing a connection between the intermediate server and the backend cloud phone instance's ADB service. Afterward, the user's debugging operations are completed through the SSH session on the intermediate server's ADB client, or by mapping the ADB port on the intermediate server to the local machine via SSH port forwarding (such as the `-L` parameter). Another simplified solution attempts to perform protocol conversion through a browser plugin, but this cannot provide a stable experience for direct connection with a local ADB client. However, existing technical solutions have the following drawbacks: 1. Reliance on a dedicated intermediate server and complex environment: A dedicated intermediate server with a public IP address needs to be deployed and maintained on the public network, and SSH service and ADB tools need to be installed and configured on the server, which increases the system complexity and operation and maintenance costs.
[0003] 2. High security risks: The SSH service port is directly exposed to the public network, becoming a potential attack surface; the management of SSH session keys or passwords also poses security risks.
[0004] 3. The connection process is cumbersome and opaque: Users need to log in to SSH first and then execute ADB commands. Debugging data streams requires SSH protocol encapsulation and decapsulation. The process is not intuitive, and the ADB connection status is strongly bound to the SSH session. Disconnection of SSH may cause ADB connection abnormalities.
[0005] 4. Fragmented user experience: Users need to switch between multiple interfaces such as SSH terminal, local command line, and browser console, and cannot complete device selection, session management and ADB tunnel establishment in one integrated interface (such as cloud phone console) in one stop.
[0006] 5. Limitations of browser-based solutions: Browser-plugin-based solutions are limited by the browser sandbox environment, making it difficult to achieve stable and high-performance direct communication with local ADB clients. They are usually limited in functionality or have poor compatibility.
[0007] It is evident that there is an urgent need for a secure, efficient, and transparent ADB local debugging method based on cloud phones. Summary of the Invention
[0008] In view of this, the present disclosure provides a local ADB debugging method based on cloud phones, which at least partially solves some of the problems existing in the prior art.
[0009] This disclosure provides an ADB local debugging method based on a cloud phone, including: Step 1: Access the cloud phone management console through a browser and select the target cloud phone instance to initiate an ADB debugging request; Step 2: The browser generates a startup command based on the ADB debugging request and sends it to the local proxy client program installed on the user's computer. Step 3: The local proxy client program parses the startup command and opens a TCP listening port locally; Step 4: The local proxy client program establishes a secure WebSocket connection with the edge proxy service deployed on the edge node based on the connection information in the startup command; Step 5: The local agent client program sends a binding request to the edge agent service via a WebSocket connection to establish a connection between the edge agent service and the ADB service port of the target cloud phone instance, forming a data transmission tunnel from the local TCP listening port to the ADB service port of the target cloud phone instance. Step 6: The local proxy client program responds to the connection initiated by the local ADB client to the local TCP listening port, and transparently forwards the data stream of the local ADB client to the ADB service port of the target cloud phone instance through the data transmission tunnel.
[0010] According to a specific implementation of an embodiment of this disclosure, in step 2, the browser sends a startup command to the local proxy client program through a custom URIScheme or a local application programming interface.
[0011] According to a specific implementation of an embodiment of this disclosure, step 4 specifically includes: The local proxy client program uses the security token contained in the startup command to initiate a WebSocket connection upgrade request to the edge proxy service via HTTPS protocol, establishing a TLS-encrypted WebSocket long connection.
[0012] According to one specific implementation of this disclosure, the binding request includes the identification information of the target cloud phone instance; After verifying the binding request, the edge proxy service connects to the ADB service port of the corresponding target cloud phone instance through the internal network.
[0013] According to a specific implementation of an embodiment of this disclosure, step 6 specifically includes: The local proxy client program encapsulates the raw ADB protocol data transmitted between the local ADB client and the local TCP listening port into WebSocket binary frames without parsing, and sends them through the data transmission tunnel; The edge proxy service decapsulates the received WebSocket binary frames and forwards them to the ADB service port of the target cloud phone instance; The reverse data stream is processed symmetrically.
[0014] According to a specific implementation of an embodiment of this disclosure, the method further includes: The browser console communicates with the local proxy client program, displays the connection status of the data transmission tunnel in real time, and receives disconnect commands issued by the user through the browser console to control the local proxy client program to close the WebSocket connection and the local TCP listening port.
[0015] The ADB local debugging scheme based on cloud phones in this embodiment includes: Step 1, accessing the cloud phone management console through a browser and selecting the target cloud phone instance to initiate an ADB debugging request; Step 2, the browser generates a startup command based on the ADB debugging request and sends it to the local agent client program installed on the user's computer; Step 3, the local agent client program parses the startup command and opens a TCP listening port locally; Step 4, the local agent client program establishes a secure WebSocket connection with the edge agent service deployed on the edge node based on the connection information in the startup command; Step 5, the local agent client program sends a binding request to the edge agent service through the WebSocket connection to establish a connection between the edge agent service and the ADB service port of the target cloud phone instance, forming a data transmission tunnel from the local TCP listening port to the ADB service port of the target cloud phone instance; Step 6, the local agent client program responds to the connection initiated by the local ADB client to the local TCP listening port and transparently forwards the data stream of the local ADB client to the ADB service port of the target cloud phone instance through the data transmission tunnel.
[0016] The beneficial effects of the embodiments disclosed herein are as follows: 1. No dedicated SSH jump host, simplified and secure architecture: It abandons the intermediate server that requires independent operation and maintenance and exposes the SSH port, adopts the standard HTTPS / WebSocket edge proxy, and uses TLS encryption, which is more secure and has a lighter architecture.
[0017] 2. One-stop integrated experience: The cloud mobile device management, session control and ADB tunnel establishment process are deeply integrated into the web console and local client. Users do not need to switch between multiple tools and interfaces, the operation path is greatly shortened and the experience is smooth.
[0018] 3. One-click connection, lowering the barrier to entry: With a single click through the browser, the local proxy can be automatically started, a secure tunnel can be established, and the ADB connection address can be prepared, greatly simplifying the operation steps for developers and testers.
[0019] 4. High-performance transparent proxy: Based on WebSocket binary frame transmission of ADB raw TCP stream, it has low protocol overhead, supports multiplexing, has high transmission efficiency, and is completely transparent to ADB clients, and is compatible with all ADB commands.
[0020] 5. Enhanced interactivity and manageability: The browser console can perceive and manage the ADB tunnel status in real time, providing intuitive interaction and centralized management capabilities that traditional SSH tunneling solutions do not have. Attached Figure Description
[0021] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 A flowchart illustrating a cloud phone-based ADB local debugging method provided in this embodiment of the disclosure; Figure 2 This is an overall system architecture diagram corresponding to an ADB local debugging method based on a cloud phone provided in this embodiment of the disclosure. Detailed Implementation
[0023] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.
[0024] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0025] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.
[0026] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.
[0027] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.
[0028] This disclosure provides an ADB local debugging method based on a cloud phone, which can be applied to the debugging process in cloud phone usage scenarios.
[0029] See Figure 1 This is a flowchart illustrating a cloud-based ADB local debugging method provided in an embodiment of this disclosure. Figure 1 and Figure 2 As shown, the method mainly includes the following steps: Step 1: Access the cloud phone management console through a browser and select the target cloud phone instance to initiate an ADB debugging request; In practice, before this step, the server and client can be deployed first: Deploy a stateless HTTP / WebSocket proxy service on the edge nodes of the cloud service provider. This service does not install ADB; it is only responsible for WebSocket connection management, authentication, and TCP forwarding to the backend cloud phone's ADB port.
[0030] Provides a self-developed local proxy client program. This program has two core modules: one is a local TCP proxy server module, which listens on the port and forwards ADB data; the other is an integrated user interface module (optional), or at least provides a local API / URI Scheme interface for interaction with a web browser.
[0031] Users can then log in to the cloud phone management console via a web browser. The console displays a list of cloud phone instances owned by the user and their status.
[0032] Users select the target cloud phone instance and click the "Start ADB Debugging" or similar button.
[0033] Step 2: The browser generates a startup command based on the ADB debugging request and sends it to the local proxy client program installed on the user's computer. In practice, the browser can generate an instruction containing information such as the target instance ID, temporary security token, and edge proxy service address based on the ADB debugging request.
[0034] The web browser then sends the above instructions to the local proxy client program installed on the user's computer via a custom URI scheme (such as cloudphone-adb: / / ) or the local WebSocket / HTTP API. If the client is not running, the system protocol will start it automatically.
[0035] Step 3: The local proxy client program parses the startup command and opens a TCP listening port locally; In practice, after receiving the instruction, the local proxy client parses the target information. First, a TCP listening port is opened locally (e.g., 127.0.0.1:5039).
[0036] Step 4: The local proxy client program establishes a secure WebSocket connection with the edge proxy service deployed on the edge node based on the connection information in the startup command; In practice, the client can use the security token in the instruction to initiate a WebSocket connection upgrade request to the designated edge proxy service via HTTPS, establishing an encrypted long connection.
[0037] Step 5: The local agent client program sends a binding request to the edge agent service via a WebSocket connection to establish a connection between the edge agent service and the ADB service port of the target cloud phone instance, forming a data transmission tunnel from the local TCP listening port to the ADB service port of the target cloud phone instance. In practice, after the WebSocket connection is established, the local proxy client sends a JSON-formatted control message through the connection, which includes the target cloud phone instance ID and requests binding.
[0038] After the edge proxy service verifies the request, it connects to the ADB daemon port (such as TCP 5555) of the cloud phone instance through the internal secure network.
[0039] The edge proxy service replies with a control message indicating successful binding. At this point, a complete "TCP over WebSocket" tunnel has been established.
[0040] Step 6: The local proxy client program responds to the connection initiated by the local ADB client to the local TCP listening port, and transparently forwards the data stream of the local ADB client to the ADB service port of the target cloud phone instance through the data transmission tunnel.
[0041] In practice, the local proxy client will provide the user with the prepared local TCP port number (such as localhost:5039) through the browser API or interface.
[0042] The user executes `adb connect 127.0.0.1:5039` in the local command line. The local ADB client connects to this port.
[0043] Subsequently, all raw ADB protocol byte streams sent and received over this TCP connection are encapsulated into WebSocket binary frames by the local proxy client without parsing, sent through the tunnel to the edge proxy service, and then forwarded to the cloud phone ADB. The reverse data stream processing is symmetrical.
[0044] Based on the above embodiments, the method further includes: The browser console communicates with the local proxy client program, displays the connection status of the data transmission tunnel in real time, and receives disconnect commands issued by the user through the browser console to control the local proxy client program to close the WebSocket connection and the local TCP listening port.
[0045] In practice, throughout the entire process, the web browser console maintains communication with the local proxy client (via the local API), and can display information such as the ADB tunnel connection status and transmission statistics in real time.
[0046] Users can send commands by clicking "Disconnect ADB" directly in the browser console. Upon receiving the command, the local proxy client will close the WebSocket tunnel and the local listening port, enabling one-stop management.
[0047] The ADB local debugging method based on cloud phones provided in this embodiment eliminates the need for a separate, exposed SSH port intermediate server. It adopts a standard HTTPS / WebSocket edge proxy with TLS encryption, resulting in higher security and a lighter architecture. The cloud phone device management, session control, and ADB tunnel establishment process are deeply integrated into the web console and local client, eliminating the need for users to switch between multiple tools and interfaces, significantly shortening the operation path and providing a smooth experience. A single click in the browser automatically starts the local proxy, establishes a secure tunnel, and prepares the ADB connection address, greatly simplifying the operation steps for developers and testers. The ADB raw TCP stream is transmitted via WebSocket binary frames, resulting in low protocol overhead, support for multiplexing, high transmission efficiency, and complete transparency to the ADB client, compatible with all ADB commands. The browser console can monitor and manage the ADB tunnel status in real time, providing intuitive interaction and centralized management capabilities not available in traditional SSH tunnel solutions.
[0048] In one specific embodiment, the method disclosed herein has been functionally and performance-verified using a prototype system. An edge proxy service based on the Go language and a client program integrating a local web management interface were developed. Tests show that users can successfully browse the device list in the cloud phone web console. After clicking the "ADB Debug" button, the local client automatically starts and establishes a WebSocket connection with the edge proxy. Subsequently, using standard ADB tools to connect to the local proxy port, a series of commands such as `adb devices`, `adb install`, `adb logcat`, and `adb shell` were successfully executed with rapid response and complete functionality. Compared to traditional SSH tunneling solutions, this solution significantly improves connection establishment speed, avoids the steps of SSH login and manual command execution, and significantly improves the user experience. The system performs stably when multiple ADB sessions are running concurrently, verifying the effectiveness of WebSocket multiplexing.
[0049] It should be understood that the various parts of this disclosure can be implemented in hardware, software, firmware, or a combination thereof.
[0050] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.
Claims
1. A local ADB debugging method based on cloud phones, characterized in that, include: Step 1: Access the cloud phone management console through a browser and select the target cloud phone instance to initiate an ADB debugging request; Step 2: The browser generates a startup command based on the ADB debugging request and sends it to the local proxy client program installed on the user's computer. Step 3: The local proxy client program parses the startup command and opens a TCP listening port locally; Step 4: The local proxy client program establishes a secure WebSocket connection with the edge proxy service deployed on the edge node based on the connection information in the startup command; Step 5: The local agent client program sends a binding request to the edge agent service via a WebSocket connection to establish a connection between the edge agent service and the ADB service port of the target cloud phone instance, forming a data transmission tunnel from the local TCP listening port to the ADB service port of the target cloud phone instance. Step 6: The local proxy client program responds to the connection initiated by the local ADB client to the local TCP listening port, and transparently forwards the data stream of the local ADB client to the ADB service port of the target cloud phone instance through the data transmission tunnel.
2. The method according to claim 1, characterized in that, In step 2, the browser sends the startup command to the local proxy client program through a custom URIScheme or a local application programming interface.
3. The method according to claim 1, characterized in that, Step 4 specifically includes: The local proxy client program uses the security token contained in the startup command to initiate a WebSocket connection upgrade request to the edge proxy service via HTTPS protocol, establishing a TLS-encrypted WebSocket long connection.
4. The method according to claim 1, characterized in that, The binding request includes the identification information of the target cloud phone instance; After verifying the binding request, the edge proxy service connects to the ADB service port of the corresponding target cloud phone instance through the internal network.
5. The method according to claim 1, characterized in that, Step 6 specifically includes: The local proxy client program encapsulates the raw ADB protocol data transmitted between the local ADB client and the local TCP listening port into WebSocket binary frames without parsing, and sends them through the data transmission tunnel; The edge proxy service decapsulates the received WebSocket binary frames and forwards them to the ADB service port of the target cloud phone instance; The reverse data stream is processed symmetrically.
6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The browser console communicates with the local proxy client program, displays the connection status of the data transmission tunnel in real time, and receives disconnect commands issued by the user through the browser console to control the local proxy client program to close the WebSocket connection and the local TCP listening port.
