Android cloud mobile phone ADB connection authority control method and device

Abstract

The invention provides an Android cloud mobile phone ADB connection authority control method and device, and the method comprises the steps: registering an account through a management server, and configuring adb authority information needed by the account through the management server after qualification information authentication is passed; after the cloud mobile phone is started, an adbd service in the cloud mobile phone is started at the client; reading adb permission information, and sending an IP (Internet Protocol), a port and an authentication token required by connection to the client by the authentication server; the adb in the client establishes connection with the adbd service according to the IP and the port; the adb sends an adb control instruction to the adbd service, the adb control instruction is compared with the adb permission information, whether the adb control instruction is legal or not is judged, and if the adb control instruction is illegal, an adb client error is returned; and if the adbd service is legal, the adbd service executes the adb control instruction, so that the safety and authority problems of the cloud mobile phone ADB are effectively solved.

Description

Technical Field

[0001] The present invention relates to the field of cloud phone security technology, and in particular to an Android cloud phone ADB connection authority control method and device. Background Art

[0002] Android ADB is a multi-functional command line tool for communication and debugging between computers and Android devices. It provides many functions, including connecting devices, file transfer, Shell access, application management, debugging, permission control, etc. It is widely used in development and debugging, testing, RPC automation and other projects. Because ADB itself has a large number of permissions, there are great potential security risks, such as data privacy leakage, remote tools, malicious application installation, etc.

[0003] In the native Android system, ADB connection permission control is achieved by users manually opening ADB related options in the developer options in the settings. When ADB is used to connect to the mobile phone for the first time, the Android system will save the ssh authentication related information on the user's device. Later, you can directly log in through the ssh authentication information saved by the computer without going through the ANDROID system permission authentication link. This ADB security authentication method is not suitable for cloud phones.

[0004] Cloud phones are cloud computing resources. The same cloud phone will be used by different users at different times. The native ADB method does not meet the usage scenarios of cloud phones. If other users connect to the cloud phone through ADB, they will see the data of another customer, resulting in data leakage and security issues. At the same time, the granularity of native ADB permission control is too large to meet the different user scenarios of cloud phones, and it is impossible to accurately control ADB-related functions and instructions. Summary of the invention

[0005] The technical problem to be solved by the present invention is to provide an Android cloud phone ADB connection permission control method and device, which effectively solves the cloud phone ADB security and flexible permission problems.

[0006] In a first aspect, the present invention provides an Android cloud phone ADB connection authority control method, comprising a client, a cloud phone, an authentication server and a management server, wherein the cloud phone is provided with an adbd service and a control service, and specifically comprises the following steps:

[0007] Step 1: Register an account through the management server and perform the corresponding qualification information authentication. When the qualification information authentication is passed, the management service configures the adb permission information required by the account and writes it into the database of the management server; when the qualification information authentication fails, the user is rejected and the step ends;

[0008] Step 2: After the cloud phone is turned on, the client initiates a request to turn on the adbd service in the cloud phone;

[0009] Step 3: After the adbd service is started, read the adb permission information and configure the permission;

[0010] Step 4: The client requests the authentication server to connect to ADB, and the authentication server sends the IP, port, and authentication token required for the connection to the client.

[0011] Step 5, adb in the client establishes a connection with the adbd service according to the IP and port, adb sends the authentication token to the adbd service of the cloud phone, the adbd service sends the authentication token to the authentication server through the control service, the authentication server verifies the authentication token, if the verification is successful, it sends the verification success to the control service, and the adbd service establishes a connection with adb; if the verification fails, it sends the verification failure to the control service, the adbd service does not establish a connection with adb, and the step ends;

[0012] Step 6: adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, and determines whether the adb control instruction is legal. If not, an error is returned; if legal, the adbd service executes the adb control instruction.

[0013] In a second aspect, the present invention provides

[0014] An Android cloud phone ADB connection authority control device includes: a client, a cloud phone, an authentication server and a management server, wherein the cloud phone is provided with an adbd service and a control service, specifically including the following modules:

[0015] The account registration module registers an account through the management server and performs the corresponding qualification information authentication. When the qualification information authentication passes, the management service configures the adb permission information required by the account and writes it into the database of the backend management server; when the qualification information authentication fails, the user is rejected and the process ends;

[0016] Start the service module. After the cloud phone is turned on, the client initiates a request to start the adbd service in the cloud phone.

[0017] Configure the permission module. After the adbd service is started, read the adb permission information and perform permission configuration;

[0018] In the information acquisition module, the client requests the authentication server to make an adb connection, and the authentication server sends the IP, port and authentication token required for the connection to the client;

[0019] Establish a connection module. The adb in the client establishes a connection with the adbd service according to the IP and port. The adb sends the authentication token to the adbd service of the cloud phone. The adbd service sends the authentication token to the authentication server through the control service. The authentication server verifies the authentication token. If the verification is successful, the verification is sent to the control service, and the adbd service establishes a connection with the adb; if the verification fails, the verification is sent to the control service, and the adbd service does not establish a connection with the adb, and the process ends.

[0020] In the instruction execution module, adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, determines whether the adb control instruction is legal, and returns an error if it is illegal; if it is legal, the adbd service executes the adb control instruction.

[0021] One or more technical solutions provided by the present invention have at least the following technical effects or advantages:

[0022] The technical solution of the present invention enables the cloud phone to flexibly configure ADB permissions according to different project requirements;

[0023] By adding an authentication server to authenticate the network connection of adb connection, the security of authentication is guaranteed;

[0024] Through relevant configurations, such as whether to allow debugging, command blacklist and whitelist control, etc., adb-related permissions are configured with maximum flexibility, ensuring the security of the cloud phone system and meeting user needs.

[0025] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The present invention will be further described below in conjunction with embodiments with reference to the accompanying drawings.

[0027] Figure 1 is a flow chart of the method in Embodiment 1 of the present invention;

[0028] Figure 2 It is a schematic diagram of the structure of the device in the second embodiment of the present invention. DETAILED DESCRIPTION

[0029] The embodiments of the present application provide an Android cloud phone ADB connection permission control method and device to solve the problem that the existing technology does not meet the usage scenarios of cloud phones, so that the cloud phone can flexibly configure ADB permissions according to different project requirements.

[0030] The technical solution in the embodiment of the present application has the following general idea:

[0031] The method includes: an adb client and a cloud phone running on the user device, an adbd service and a control service running inside the cloud phone system, and an authentication server and a management server already running on the backend. The specific implementation steps of the secure connection method are as follows:

[0032] Step 1: The user registers with the management server and authenticates the relevant qualification information. After the user qualification authentication is passed, the management service assigns the user the relevant adb permissions according to the user project requirements and writes them into the database of the management server.

[0033] Step 2: After purchasing and activating the cloud phone, the user can actively activate the cloud phone service on the cloud phone. The specific method is as follows: the cloud phone sends an adb activation command to the management server, and the management server sends the adb activation command and the adb permissions that the user can obtain to the control service inside the cloud phone. The control service activates the adbd service inside the cloud phone and passes the relevant permission information to the adbd service.

[0034] Step 3: After the adbd service inside the cloud phone is started, read the relevant permission configuration, configure the relevant permissions, and wait for the user to connect.

[0035] Step 4: The cloud phone requests an adb connection from the backend authentication server, and the authentication server returns the IP, port, and authentication token required for the connection to the user.

[0036] Step 5: The user uses the IP and port returned in step 4 to execute "adb connect IP:port" (IP and port returned in step 4) in the terminal to establish a connection with the adbd service inside the cloud phone. After receiving the connection, the adbd service inside the cloud phone creates a connection object and marks it as unauthenticated.

[0037] Step 6: The user runs the special command "adb shell logintoken" (where token is the token returned in step 4) in the terminal to verify the user's legitimacy. After receiving the command, the adbd service inside the cloud phone uses the authentication token sent by the user to send the user's legitimacy verification to the authentication server. If the verification passes, the connection object is marked as authenticated. If not, the command is converted into a shell echo command "echo Authentication failed" and executed, and returned to the client.

[0038] Step 7: When the user executes other adb commands, the user-side adb client transmits the command to the adbd service inside the cloud phone. After receiving the request command, the adbd service inside the cloud phone determines whether the connection has been authenticated. If not, the command is replaced with the shell echo command "echo you should run adb shell login yourtokenfirst" and executed and returned. If it has been authenticated, it is necessary to determine whether the command is legal again. If it is not legal, a client error is returned, and the adb connection with the client is disconnected. At the same time, the authentication server is informed to record the relevant behavior. When the authentication server receives that the user has illegal behavior, the user's adb connection token is invalidated and adb is disabled from connecting again. If it is legal, execute the adb command.

[0039] Step 8: When the adb client is connected to the adbd service port inside the cloud phone, the cloud phone internal service sends a disconnection command to the cloud phone authentication server. The cloud phone authentication server sets the authentication token to invalid.

[0040] Step 9: When the user closes the adb client on the cloud phone, a command to close adb is sent to the backend control service. The backend control server sends a command to close adb to the control service inside the cloud phone. The control service inside the cloud phone terminates the operation of the adbd service.

[0041] The adbd service in the cloud phone rewrites the adbd service authentication method of the native Android system to achieve a secure connection of adb. At the same time, by modifying the adbd permission control method, a more detailed and controllable permission control is achieved. The controllable permissions include: adb user permissions, adb debugging permissions, adb file transfer permissions, adb directory access permissions, adb command blacklist, etc.

[0042] The specific implementation method and process are as follows:

[0043] 1. The adb user authority control method is as follows:

[0044] Minijail is a tool for creating and managing sandboxes, usually used to enhance the security and isolation of applications. When the adbd service is started, it obtains the backend service configuration and calls the minijail_change_gid and minijail_change_uid interfaces to dynamically change the user group ID and user ID of the adbd service, thereby controlling the execution user permissions of the instructions sent by the adb client.

[0045] 2. The adb debugging permission control method is as follows:

[0046] JDWP is a protocol for communication between the Java Virtual Machine (JVM) and the debugger. JDWP allows the debugger to interact with the Java program running on the JVM to perform debugging operations, such as setting breakpoints, viewing variable values, and single-step execution. Therefore, to control whether adb has debugging capabilities, you can increase whether the JDWP channel is enabled. When the current backend configuration allows debugging, the built-in adbd service in Android calls the init_jdwp interface to enable JDWP debugging, otherwise it is not enabled.

[0047] 3. adb file transfer permissions:

[0048] In the adbd service of the Android system, file transfer is implemented by the file_sync_service module. When the adbd service is started, it determines whether there is file transfer permission. If not, the service is not enabled. At the same time, when the adbd service receives an instruction and determines that the instruction is a file transfer instruction, it replaces the instruction with "echo illegal instruction" and executes and returns.

[0049] 4. adb disk remount permissions:

[0050] Similar to adb file transfer permissions, the remount permission is implemented by the remount_service module. If adbd does not have this permission when it starts, the module will not be initialized. At the same time, when the adbd service receives an instruction, if it is a remount instruction, it replaces the instruction with "echo illegal instruction" and executes and returns.

[0051] 5. adb directory access permissions:

[0052] When the adbd service inside Android receives the instruction sent by adb, it determines whether the instruction contains a directory path that is not allowed to be accessed. If so, the instruction is replaced with the "echo illegal instruction" instruction, executed and returned.

[0053] 6.adb command blacklist:

[0054] The adb command blacklist is when the internal adbd service of Android receives an adb command and determines whether the adb command is in the blacklist. If it is in the blacklist, it returns. The adb blacklist can be used to restrict whether to allow applications or certain applications to be installed or started, and to restrict adb from executing commands such as reboot.

[0055] Embodiment 1

[0056] like Figure 1 As shown, this embodiment provides an Android cloud phone ADB connection authority control method, including a client, a cloud phone, an authentication server and a management server, wherein the cloud phone is provided with an adbd service and a control service, specifically including the following steps:

[0057] Step 1: Register an account through the management server and perform the corresponding qualification information authentication. When the qualification information authentication is passed, the management service configures the adb permission information required by the account and writes it into the database of the management server; when the qualification information authentication fails, the user is rejected and the step ends;

[0058] Step 2: After the cloud phone is turned on, the client initiates a request to turn on the adbd service in the cloud phone;

[0059] Step 3: After the adbd service is started, read the adb permission information and configure the permission;

[0060] Step 4: The client requests the authentication server to connect to ADB, and the authentication server sends the IP, port, and authentication token required for the connection to the client.

[0061] Step 5, adb in the client establishes a connection with the adbd service according to the IP and port, adb sends the authentication token to the adbd service of the cloud phone, the adbd service sends the authentication token to the authentication server through the control service, the authentication server verifies the authentication token, if the verification is successful, it sends the verification success to the control service, and the adbd service establishes a connection with adb; if the verification fails, it sends the verification failure to the control service, the adbd service does not establish a connection with adb, and the step ends;

[0062] Step 6: adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, and determines whether the adb control instruction is legal. If not, an error is returned; if legal, the adbd service executes the adb control instruction.

[0063] In this embodiment, preferably, the method further includes step 7: when adb is disconnected from the adbd service, the control service sends a disconnection instruction to the authentication server, and the authentication server sets the corresponding authentication token to be invalid;

[0064] When adb is closed, an adb close command is sent to the management server, and the management server sends an adb close command to the control service. The control service terminates the operation of the adbd service, and the control service sends a connection disconnection command to the authentication server, and the authentication server sets the corresponding authentication token to invalid.

[0065] In this embodiment, preferably, step 2 is specifically as follows: after turning on the cloud phone, the client sends an adb start instruction to the back-end management server, and the back-end management server sends the adb start instruction and the adb permission information corresponding to the account to the control service of the cloud phone. The control service starts the adbd service inside the cloud phone and passes the adb permission information to the adbd service.

[0066] In this embodiment, preferably, step 6 is specifically as follows: adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, determines whether the adb control instruction is legal, and if not, returns an error, disconnects the adbd service from adb, sends the control behavior to the authentication server through the control service for recording, and the authentication server sets the corresponding authentication token to invalid; if legal, the adbd service executes the adb control instruction.

[0067] In this embodiment, preferably, the adbd service includes: adb user rights, adb debugging rights, adb file transfer rights, adb directory access rights and adb command blacklist;

[0068] The specific adb user permissions are: when the adbd service is started, the user group ID and user ID of the adbd service are dynamically changed by calling the minijail_change_gid and minijail_change_uid interfaces to control the execution user permissions of the instructions sent by the set user's adb;

[0069] The specific adb debugging permissions are: when adb is allowed to debug, the jdwp debugging is enabled by calling the init_jdwp interface through the adbd service, otherwise it is not enabled;

[0070] The specific adb file transfer permissions are: when the adbd service is started, it is determined whether the corresponding adb has file transfer permissions. If not, file_sync_service is not enabled;

[0071] The specific permissions for adb disk remount are: when adbd is started, it is determined whether the corresponding adb has the remount permission. If not, remount_service will not be started;

[0072] The specific access rights of adb directory are as follows: when adbd service receives the command sent by adb, it determines whether the command contains a directory path that is not allowed to be accessed. If it exists, it is denied; if not, access is allowed;

[0073] The adb command blacklist is specifically as follows: after the adbd service receives the adb command, it determines whether the adb command is in the adb command blacklist. If it is in the blacklist, the adb command is refused to be executed; the adb blacklist restriction is to set the execution of the adb command.

[0074] Based on the same inventive concept, the present application also provides a device corresponding to the method in Example 1, see Example 2 for details.

[0075] Embodiment 2

[0076] like Figure 2 As shown, in this embodiment, an Android cloud phone ADB connection authority control device is provided, including: a client, a cloud phone, an authentication server and a management server, wherein the cloud phone is provided with an adbd service and a control service, specifically including the following modules:

[0077] The account registration module registers an account through the management server and performs the corresponding qualification information authentication. When the qualification information authentication passes, the management service configures the adb permission information required by the account and writes it into the database of the backend management server; when the qualification information authentication fails, the user is rejected and the process ends;

[0078] Start the service module. After the cloud phone is turned on, the client initiates a request to start the adbd service in the cloud phone.

[0079] Configure the permission module. After the adbd service is started, read the adb permission information and perform permission configuration;

[0080] In the information acquisition module, the client requests the authentication server to make an adb connection, and the authentication server sends the IP, port and authentication token required for the connection to the client;

[0081] Establish a connection module. The adb in the client establishes a connection with the adbd service according to the IP and port. The adb sends the authentication token to the adbd service of the cloud phone. The adbd service sends the authentication token to the authentication server through the control service. The authentication server verifies the authentication token. If the verification is successful, the verification is sent to the control service, and the adbd service establishes a connection with the adb; if the verification fails, the verification is sent to the control service, and the adbd service does not establish a connection with the adb, and the process ends.

[0082] In the instruction execution module, adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, determines whether the adb control instruction is legal, and returns an error if it is illegal; if it is legal, the adbd service executes the adb control instruction.

[0083] In this embodiment, preferably, it further comprises a disconnection module, when adb is disconnected from the adbd service, the control service sends a disconnection instruction to the authentication server, and the authentication server sets the corresponding authentication token to be invalid;

[0084] When adb is closed, an adb close command is sent to the management server, and the management server sends an adb close command to the control service. The control service terminates the operation of the adbd service, and the control service sends a connection disconnection command to the authentication server, and the authentication server sets the corresponding authentication token to invalid.

[0085] In this embodiment, preferably, the startup service module is specifically as follows: after turning on the cloud phone, the client sends an adb startup instruction to the back-end management server, the management server sends the adb startup instruction and the adb permission information corresponding to the account to the control service of the cloud phone, the control service starts the adbd service inside the cloud phone, and passes the adb permission information to the adbd service.

[0086] In this embodiment, preferably, the execution instruction module is specifically: adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, determines whether the adb control instruction is legal, and if not, returns an error, disconnects the adbd service from adb, sends the control behavior to the authentication server through the control service for recording, and the authentication server sets the corresponding authentication token to invalid; if legal, the adbd service executes the adb control instruction.

[0087] In this embodiment, preferably, the adbd service includes: adb user rights, adb debugging rights, adb file transfer rights, adb directory access rights and adb command blacklist;

[0088] The specific adb user permissions are: when the adbd service is started, the user group ID and user ID of the adbd service are dynamically changed by calling the minijail_change_gid and minijail_change_uid interfaces to control the execution user permissions of the instructions sent by the set user's adb;

[0089] The specific adb debugging permissions are: when adb is allowed to debug, the jdwp debugging is enabled by calling the init_jdwp interface through the adbd service, otherwise it is not enabled;

[0090] The specific adb file transfer permissions are: when the adbd service is started, it is determined whether the corresponding adb has file transfer permissions. If not, file_sync_service is not enabled;

[0091] The specific permissions for adb disk remount are: when adbd is started, it is determined whether the corresponding adb has the remount permission. If not, remount_service will not be started;

[0092] The specific access rights of adb directory are as follows: when adbd service receives the command sent by adb, it determines whether the command contains a directory path that is not allowed to be accessed. If it exists, it is denied; if not, access is allowed;

[0093] The adb command blacklist is specifically as follows: after the adbd service receives the adb command, it determines whether the adb command is in the adb command blacklist. If it is in the blacklist, the adb command is refused to be executed; the adb blacklist restriction is to set the execution of the adb command.

[0094] Since the device introduced in the second embodiment of the present invention is a device used to implement the method of the first embodiment of the present invention, those skilled in the art can understand the specific structure and deformation of the device based on the method introduced in the first embodiment of the present invention, so it is not described here in detail. All devices used in the method of the first embodiment of the present invention belong to the scope of protection of the present invention.

[0095] Although the specific implementation modes of the present invention are described above, those skilled in the art should understand that the specific implementation modes described are only illustrative and are not intended to limit the scope of the present invention. Equivalent modifications and changes made by those skilled in the art in accordance with the spirit of the present invention should be included in the scope of protection of the claims of the present invention.

Claims

1. A method for controlling ADB connection permissions for an Android cloud phone, characterized in that: It includes a client, a cloud phone, an authentication server and a management server. The cloud phone is provided with an adbd service and a control service, and specifically includes the following steps: Step 1: Register an account through the management server and perform the corresponding qualification information authentication. When the qualification information authentication is passed, the management service configures the adb permission information required by the account and writes it into the database of the management server; when the qualification information authentication fails, the user is rejected and the step ends; Step 2: After the cloud phone is turned on, the client initiates a request to turn on the adbd service in the cloud phone; Step 3: After the adbd service is started, read the adb permission information and configure the permission; Step 4: The client requests the authentication server to connect to ADB, and the authentication server sends the IP, port, and authentication token required for the connection to the client. Step 5, adb in the client establishes a connection with the adbd service according to the IP and port, adb sends the authentication token to the adbd service of the cloud phone, the adbd service sends the authentication token to the authentication server through the control service, the authentication server verifies the authentication token, if the verification is successful, it sends the verification success to the control service, and the adbd service establishes a connection with adb; if the verification fails, it sends the verification failure to the control service, the adbd service does not establish a connection with adb, and the step ends; Step 6: adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, and determines whether the adb control instruction is legal. If not, an error is returned; if legal, the adbd service executes the adb control instruction.

2. According to claim 1, an Android cloud phone ADB connection authority control method is characterized in that: The method further includes step 7, when adb is disconnected from the adbd service, the control service sends a disconnection instruction to the authentication server, and the authentication server sets the corresponding authentication token to be invalid; When adb is closed, an adb close command is sent to the management server, and the management server sends an adb close command to the control service. The control service terminates the operation of the adbd service, and the control service sends a connection disconnection command to the authentication server, and the authentication server sets the corresponding authentication token to invalid.

3. According to claim 1, an Android cloud phone ADB connection authority control method is characterized in that: The step 2 is specifically as follows: after turning on the cloud phone, the client sends an adb start instruction to the backend management server, and the backend management server sends the adb start instruction and the adb permission information corresponding to the account to the control service of the cloud phone. The control service starts the adbd service inside the cloud phone and passes the adb permission information to the adbd service.

4. According to claim 1, an Android cloud phone ADB connection authority control method is characterized in that: The step 6 is specifically as follows: adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, determines whether the adb control instruction is legal, and if not, returns an error, disconnects the adbd service from adb, sends the control behavior to the authentication server through the control service for recording, and the authentication server sets the corresponding authentication token to invalid; if legal, the adbd service executes the adb control instruction.

5. According to claim 1, an Android cloud phone ADB connection authority control method is characterized in that: The adbd service includes: adb user rights, adb debugging rights, adb file transfer rights, adb directory access rights and adb command blacklist; The specific adb user permissions are: when the adbd service is started, the user group ID and user ID of the adbd service are dynamically changed by calling the minijail_change_gid and minijail_change_uid interfaces to control the execution user permissions of the instructions sent by the set user's adb; The specific adb debugging permissions are: when adb is allowed to debug, the jdwp debugging is enabled by calling the init_jdwp interface through the adbd service, otherwise it is not enabled; The specific adb file transfer permissions are: when the adbd service is started, it is determined whether the corresponding adb has file transfer permissions. If not, file_sync_service is not enabled; The specific permissions for adb disk remount are: when adbd is started, it is determined whether the corresponding adb has the remount permission. If not, remount_service will not be started; The specific access rights of adb directory are as follows: when adbd service receives the command sent by adb, it determines whether the command contains a directory path that is not allowed to be accessed. If it exists, it is denied; if not, access is allowed; The adb command blacklist is specifically as follows: after the adbd service receives the adb command, it determines whether the adb command is in the adb command blacklist. If it is in the blacklist, the adb command is refused to be executed; the adb blacklist restriction is to set the execution of the adb command.

6. An Android cloud phone ADB connection authority control device, characterized in that: include: It includes a client, a cloud phone, an authentication server and a management server. The cloud phone is equipped with an adbd service and a control service, which specifically include the following modules: The account registration module registers an account through the management server and performs the corresponding qualification information authentication. When the qualification information authentication passes, the management service configures the adb permission information required by the account and writes it into the database of the backend management server; when the qualification information authentication fails, the user is rejected and the process ends; Start the service module. After the cloud phone is turned on, the client initiates a request to start the adbd service in the cloud phone. Configure the permission module. After the adbd service is started, read the adb permission information and perform permission configuration; In the information acquisition module, the client requests the authentication server to make an adb connection, and the authentication server sends the IP, port and authentication token required for the connection to the client; Establish a connection module. The adb in the client establishes a connection with the adbd service according to the IP and port. The adb sends the authentication token to the adbd service of the cloud phone. The adbd service sends the authentication token to the authentication server through the control service. The authentication server verifies the authentication token. If the verification is successful, the verification is sent to the control service, and the adbd service establishes a connection with the adb; if the verification fails, the verification is sent to the control service, and the adbd service does not establish a connection with the adb, and the process ends. In the instruction execution module, adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, determines whether the adb control instruction is legal, and returns an error if it is illegal; if it is legal, the adbd service executes the adb control instruction.

7. The device for controlling ADB connection authority of an Android cloud phone according to claim 6, characterized in that: It also includes a disconnection module. When adb is disconnected from the adbd service, the control service sends a disconnection instruction to the authentication server, and the authentication server sets the corresponding authentication token to be invalid; When adb is closed, an adb close command is sent to the management server, and the management server sends an adb close command to the control service. The control service terminates the operation of the adbd service, and the control service sends a connection disconnection command to the authentication server, and the authentication server sets the corresponding authentication token to invalid.

8. The device for controlling ADB connection authority of an Android cloud phone according to claim 6, characterized in that: The startup service module is specifically as follows: after the cloud phone is turned on, the client sends an adb startup instruction to the backend management server, and the management server sends the adb startup instruction and the adb permission information corresponding to the account to the control service of the cloud phone. The control service starts the adbd service inside the cloud phone and passes the adb permission information to the adbd service.

9. The device for controlling ADB connection authority of an Android cloud phone according to claim 6, characterized in that: The execution instruction module is specifically as follows: adb sends an adb control instruction to the adbd service, compares the adb control instruction with the adb permission information, determines whether the adb control instruction is legal, and if not, returns an error, disconnects the adbd service from adb, sends the control behavior to the authentication server through the control service for recording, and the authentication server sets the corresponding authentication token to invalid; if legal, the adbd service executes the adb control instruction.

10. The device for controlling ADB connection authority of an Android cloud phone according to claim 6, characterized in that: The adbd service includes: adb user rights, adb debugging rights, adb file transfer rights, adb directory access rights and adb command blacklist; The specific adb user permissions are: when the adbd service is started, the user group ID and user ID of the adbd service are dynamically changed by calling the minijail_change_gid and minijail_change_uid interfaces to control the execution user permissions of the instructions sent by the set user's adb; The specific adb debugging permissions are: when adb is allowed to debug, the jdwp debugging is enabled by calling the init_jdwp interface through the adbd service, otherwise it is not enabled; The specific adb file transfer permissions are: when the adbd service is started, it is determined whether the corresponding adb has file transfer permissions. If not, file_sync_service is not enabled; The specific permissions for adb disk remount are: when adbd is started, it is determined whether the corresponding adb has the remount permission. If not, remount_service will not be started; The specific access rights of adb directory are as follows: when adbd service receives the command sent by adb, it determines whether the command contains a directory path that is not allowed to be accessed. If it exists, it is denied; if not, access is allowed; The adb command blacklist is specifically as follows: after the adbd service receives the adb command, it determines whether the adb command is in the adb command blacklist. If it is in the blacklist, the adb command is refused to be executed; the adb blacklist restriction is to set the execution of the adb command.

Images