Android debugging bridge calling method, terminal and computer readable medium

By retaining the preset authentication file locally in the terminal and calling ADB directly based on the local authentication file, the problems of information leakage during ADB use and cumbersome user operations are solved, and safe and efficient ADB management is achieved.

CN119989309APending Publication Date: 2025-05-13ZTE CORP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202311508809.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-11-13
Publication Date
2025-05-13

AI Technical Summary

Technical Problem

When using Android debugging bridge (ADB), the prior art has the risk of information leakage, and the user-side operation is cumbersome, requiring real-time verification permissions.

Method used

The pre-set authentication file is retained locally in the terminal, which contains the terminal's identification information and permission information. In response to the ADB's call instructions, it is called directly based on the local authentication file to avoid every verification.

Benefits of technology

It effectively reduces the complexity of user operations, improves the security of ADB usage, and reduces the cost of manufacturers maintaining authorized servers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119989309A_ABST
    Figure CN119989309A_ABST
Patent Text Reader

Abstract

The invention provides a calling method of an Android debugging bridge ADB, which comprises the following steps: calling the ADB according to a local preset authentication file in response to a calling instruction of the Android debugging bridge; the preset authentication file comprises identification information and authority information of the terminal. The invention further provides a terminal and a computer readable medium.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the field of security technology, and in particular to a calling method, a terminal and a computer-readable medium of an Android debugging bridge. Background Art

[0002] ADB (Android Debug Bridge) is a general command line tool. Due to its powerful functions, when it is used, some private information of the manufacturer's device may be read, which may lead to the risk of information leakage. Therefore, it is necessary to strengthen the authorization control of ADB permissions.

[0003] Currently, ADB is conditionally controlled so that the usage status of ADB can be controlled by the manufacturer. However, this method requires real-time verification of user operations each time, which makes user-side operations more cumbersome. Summary of the invention

[0004] The embodiments of the present disclosure provide a method for calling an Android debugging bridge, a terminal, and a computer-readable medium.

[0005] In a first aspect, an embodiment of the present disclosure provides a method for calling an Android debugging bridge, which includes:

[0006] In response to a call instruction to the ADB, the ADB is called according to a local preset authentication file; the preset authentication file includes identification information and authority information of the terminal.

[0007] In a second aspect, an embodiment of the present disclosure provides a terminal, including:

[0008] one or more processors;

[0009] A memory having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the calling method of the Android debugging bridge described in the first aspect of the embodiment of the present disclosure.

[0010] In a third aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, and when the program is executed by a processor, the method for calling the Android debugging bridge described in the first aspect of the embodiment of the present disclosure is implemented.

[0011] The calling method of the Android Debug Bridge provided by the embodiment of the present disclosure retains a preset authentication file locally in the terminal. The preset authentication file provides permission information related to calling ADB. Therefore, within the corresponding restriction range of the permission information, there is no need to verify the ADB calling instruction each time, which effectively reduces the complexity of user operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A flowchart of a method for calling an Android debugging bridge provided in an embodiment of the present disclosure;

[0013] Figure 2 This is a flowchart of a specific implementation method before step S1 in the embodiment of the present disclosure;

[0014] Figure 3 A structural diagram of a specific implementation method of the calling system of the Android debug bridge in the embodiment of the present disclosure;

[0015] Figure 4 This is a flowchart of a specific implementation method of step S1 in the embodiment of the present disclosure;

[0016] Figure 5 A flowchart of a specific implementation method of step S2 in the embodiment of the present disclosure;

[0017] Figure 6 Schematic diagram of a specific implementation method of step S23 in the embodiment of the present disclosure;

[0018] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure;

[0019] Figure 8 A schematic diagram of the structure of a computer-readable medium provided in an embodiment of the present disclosure;

[0020] Fig. 9 The present invention is a flowchart of a specific implementation method of the calling method of the Android debug bridge in the embodiment of the present disclosure. DETAILED DESCRIPTION

[0021] In order to enable those skilled in the art to better understand the technical solution of the present disclosure, the control method of the control provided by the present disclosure, the electronic device and the computer-readable medium are described in detail below with reference to the accompanying drawings.

[0022] Example embodiments will be described more fully below with reference to the accompanying drawings, but the example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. On the contrary, the purpose of providing these embodiments is to make the present disclosure thorough and complete and to enable those skilled in the art to fully understand the scope of the present disclosure.

[0023] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

[0024] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0025] The terms used herein are only used to describe specific embodiments and are not intended to limit the present disclosure. As used herein, the singular forms "a", "an" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of the features, wholes, steps, operations, elements and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof is not excluded.

[0026] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted as having an idealized or overly formal meaning unless explicitly defined as such herein.

[0027] The ADB involved in the disclosed embodiment is a general command line tool. ADB has powerful functions. It can be used as a bridge between the terminal of the Android operating system and the PC (Personal Computer) end to perform various device operations (for example, install and debug applications) and provide access rights to the Unix shell, where the Unix shell is used to run various commands on the device. However, if ADB is not managed properly, malicious third parties may obtain and abuse these permissions to access sensitive information in the manufacturer's equipment. Therefore, it is necessary to strengthen the authorization control of ADB permissions to avoid information leakage of manufacturer equipment.

[0028] In some related technologies, some manufacturers choose to directly prohibit users from opening ADB, but this results in high costs for obtaining logs and debugging when users actually encounter problems and report them. In other related technologies, some manufacturers choose to conduct conditional management and control. One is to add an authorization server to verify users in real time and deploy an authorization server in the local area network of each office. However, this results in high costs for manufacturers to build and maintain authorization servers. Another method is to verify the verification code or password every time the user opens ADB, which makes the operation on the user side more cumbersome. Therefore, convenient and secure management and control of ADB is an urgent problem to be solved.

[0029] Figure 1 A flowchart of a method for calling an Android debugging bridge provided by an embodiment of the present disclosure. Figure 1 The present disclosure provides a method for calling an Android debugging bridge for a terminal, the method comprising:

[0030] S1. In response to a call instruction to an Android debug bridge ADB, the ADB is called according to a local preset authentication file; the preset authentication file includes identification information and permission information of the terminal.

[0031] In an embodiment of the present disclosure, the preset authentication file includes identification information and permission information of the terminal, that is, the preset authentication file indicates the unique identification information of the terminal that can call ADB and the permission range corresponding to the terminal. In some embodiments, the permission information limits the time or number of times the terminal can use the preset authentication file. When the terminal responds to the user's call instruction and a preset authentication file is set locally in the terminal, the call instruction can be executed on ADB within the corresponding restriction range of the permission information. There is no need for the manufacturer to deploy an authorization server for controlling ADB, nor is there a need to verify the user's call instruction each time, which not only ensures the security of ADB when used, but also reduces the complexity of user operations and optimizes the user's experience of the terminal.

[0032] In some embodiments, each execution of a call instruction to ADB will be recorded by the terminal. In the embodiments of the present disclosure, the recording method is not particularly limited, and can be recording the number of executions or recording the execution time.

[0033] In some embodiments, if the terminal does not have a local pre-installed authentication file or is not within the corresponding restriction range of the permission information, the terminal cannot call ADB according to the call instruction. Accordingly, in other embodiments, the terminal provides corresponding prompt information to the user, for example, prompting the user to apply for an ADB authorization file, prompting the user that the permission information has expired, etc.

[0034] Figure 2 Schematic diagram of a specific implementation method before step S1 in the embodiment of the present disclosure. Figure 2 Accordingly, in some embodiments, before S1, the method further includes:

[0035] S01. Obtain a first ADB authorization file;

[0036] S02. Parse the first ADB authorization file to obtain first authentication information; the first authentication information includes: first identification information and first authority information;

[0037] S03: Verify the first identification information in the first authentication information, and if the verification passes, determine the first authentication information as the preset authentication file.

[0038] In this embodiment, by parsing the first ADB authorization file, the first authentication information including the first identification information and the first authority information is obtained. The terminal verifies the first identification information. If the verification passes, the first authentication information is determined as a preset authentication file. If the verification fails, the preset authentication file is ignored.

[0039] In some embodiments, the identification information in the preset authentication file includes at least one of a terminal unique identification code and a random encryption code. Among them, the terminal unique identification code is used to verify whether the terminal is a terminal that can call ADB as allowed by the manufacturer, and the random encryption code is used to ensure that the ADB authorization file generated each time (such as the first ADB authorization file, the second ADB authorization file) is not repeated, that is, the random encryption code can be used to verify whether the ADB authorization file is repeated. Correspondingly, in one example, the terminal's verification content of the first identification information includes: whether the first authentication information is consistent with the terminal's unique identification code and / or random encryption code, and consistency indicates that the first authentication information can be retained in the terminal as a preset authentication file.

[0040] The first ADB authorization file in the embodiments of the present disclosure is generated by the manufacturer using the ADB authorization tool based on the unique identification information of the terminal. In some embodiments, the first ADB authorization file is an encrypted file to prevent tampering by a malicious third party during transmission to the terminal. It is worth noting that the random generated codes in the multiple ADB authorization files generated by the manufacturer using the ADB authorization tool based on the unique identification information of the terminal are different to prevent the same ADB authorization file from being repeatedly imported and used.

[0041] The following describes how to obtain the first ADB authorization file:

[0042] In some embodiments, S01 includes at least one of the following:

[0043] Importing the first ADB authorization file through an external device of the terminal;

[0044] Receiving the first ADB authorization file sent by the server;

[0045] An ADB authorization request is sent to the server, and the first ADB authorization file fed back by the server is received.

[0046] The embodiments of the present disclosure do not impose any special limitation on the external device, which may be a storage device such as a mobile hard disk or a USB flash drive that can store the first ADB authorization file.

[0047] In this embodiment, the manufacturer generates a first ADB authorization file through the server using the ADB authorization tool. In some embodiments, the server can be a server that adds the ADB authorization tool on the basis of the original server (such as an operation and maintenance server) that the terminal interacts with the manufacturer, or it can be an additional third-party server, and the present disclosure is not limited to this.

[0048] In some embodiments, the server sends the first ADB authorization file to the terminal by first sending the first ADB authorization file to the operation and maintenance system of the terminal, and then the operation and maintenance system responds to the instructions of the operation and maintenance personnel and sends the first ADB authorization file to the terminal.

[0049] In some embodiments, the first ADB authorization file may also be obtained through communication interaction between the terminal and the server, that is, the terminal sends an ADB authorization request to the server, and the server feeds back the first ADB authorization file to the terminal in response to the ADB authorization request.

[0050] In one example, Figure 3 This is a structural diagram of a specific implementation method of the ADB calling system in the embodiment of the present disclosure. Figure 3 The system includes: an ADB authorization tool (not shown in the figure), a terminal device, a network management system and a USB flash drive.

[0051] Among them, the ADB authorization tool is used to generate the first ADB authorization file, including the terminal unique identification code, validity times (i.e. the total number of times the authorized terminal can use ADB), expiration time, random encryption code, etc., and encrypt the first ADB authorization file through an encryption algorithm.

[0052] The terminal device is a device of the Android mobile operating system. After the user obtains the first ADB authorization file on the terminal device, the user can open and call ADB in a general manner. The terminal device includes a security component, which is an internal component of the terminal device, and is used to parse the first ADB authorization file and verify whether the first ADB authorization file is valid. If the verification is passed, the terminal records the first authentication information as a preset authentication file, wherein the ADB available times (i.e., valid times) and expiration time in the preset authentication file are updated according to the first permission information in the first authentication information.

[0053] The network management system, namely the device management platform, is used to receive the first ADB authorization file generated by the server on the manufacturer side, and control the device management platform to import the first ADB authorization file into the terminal device in response to the instruction of the operation and maintenance personnel.

[0054] The U disk is an external device of the terminal device, which can be connected to the terminal device through a communication interface and is used to import the first ADB authorization file into the terminal device.

[0055] Through the above-mentioned ADB calling system, the server on the manufacturer's side uses the ADB authorization tool to generate a first ADB authorization file, and the generated first ADB authorization file is sent to the network management system or stored in a U disk. When the user needs to keep the preset authorization file in the terminal, the user can directly send an ADB authorization request to the server through the terminal, and the server responds to the ADB authorization request to feedback the first ADB authorization file to the terminal. The user can also directly connect a U disk to the terminal device and import the first ADB authorization file stored in the U disk into the terminal device. The operation and maintenance personnel can also import the first ADB authorization file to the terminal device through the network management system.

[0056] In some embodiments, the permission information in the preset authentication file includes at least one of a valid number of times and an expiration time.

[0057] In an embodiment of the present disclosure, the valid number of times can limit the number of times the terminal uses ADB after obtaining the preset authentication file. Each time the terminal calls ADB, the valid number of times will be reduced accordingly until the valid number of times is exhausted and the preset authentication file becomes invalid. After that, the terminal cannot call ADB again according to the current preset authentication file, that is, the terminal needs to update the preset authentication file.

[0058] The expiration time can limit the terminal to use ADB within a certain time range after obtaining the preset authentication file. Before the time point corresponding to the expiration time is reached, the terminal is allowed to call ADB until the time point corresponding to the expiration time is reached. After that, the terminal cannot call ADB again according to the current preset authentication file, that is, the terminal needs to update the preset authentication file. Among them, the time point corresponding to the expiration time can be determined according to the terminal system time, or it can be confirmed by timing after obtaining the preset authentication file, and the present disclosure is not limited to this.

[0059] In some embodiments, the permission information may also include a valid time range, etc., which may be determined based on the actual restriction requirements of the manufacturer on the terminal.

[0060] Figure 4 FIG. 1 is a flow chart of a specific implementation method of step S1 in the embodiment of the present disclosure. Figure 4 In some embodiments, when the permission information includes a valid number of times, S1 includes:

[0061] S11, determining whether the valid times in the preset authentication file is greater than zero, and obtaining a confirmation result;

[0062] S12: When the confirmation result shows that the valid number of times is greater than zero, execute the calling instruction to call the ADB and reduce the valid number of times.

[0063] In this embodiment, if the valid times are greater than zero, it means that the current preset authentication file still has a remaining number of usable times, and the terminal executes the calling instruction and reduces the valid times accordingly.

[0064] In some embodiments, when the permission information also includes an expiration time, it is verified whether the expiration time has expired. If it has not expired, the terminal executes the calling instruction.

[0065] In some embodiments, on the basis that the permission information includes the number of valid times, the permission information further includes an expiration time. After confirming that the number of valid times is greater than zero, it is necessary to further verify whether the expiration time has expired. If it has not expired, the terminal executes the call instruction and reduces the number of valid times accordingly.

[0066] In the embodiments of the present disclosure, there is no special limitation on the method of executing the call instruction to call ADB, and it can be a general method, such as clicking 5 times in a row at the device version number to open or call ADB.

[0067] In some embodiments, the calling method of the Android Debug Bridge further includes:

[0068] S2. Update the local preset authentication file.

[0069] In the embodiment of the present disclosure, updating the local preset authentication file may be initiated by the terminal actively sending an ADB authorization request to the server, or may be initiated by the terminal by receiving an update from the server or an external device, and the present disclosure is not limited thereto.

[0070] Figure 5 FIG. 1 is a flow chart of a specific implementation method of step S2 in the embodiment of the present disclosure. Figure 5 In some embodiments, S2 includes:

[0071] S21, obtaining a second ADB authorization file;

[0072] S22. Parse the second ADB authorization file to obtain second authentication information; the second authentication information includes: second identification information and second authority information;

[0073] S23: Update the local preset authentication file according to the second authentication information.

[0074] In this embodiment, the method of obtaining the second ADB authorization file may be the same as or different from the method of obtaining the first ADB authorization file described above, and the present disclosure is not limited thereto. Before updating the preset authentication file according to the second authentication information, it is necessary to determine whether the second ADB authorization file is the same as the first ADB authorization file. In some embodiments, it can be determined whether the two are the same by comparing the second identification information of the second authentication information with the identification information in the preset authentication file.

[0075] Accordingly, in some embodiments, the identification information in the preset authentication file includes at least one of a terminal unique identification code and a random encryption code; wherein the random encryption code can be used to verify whether the ADB authorization file is a duplicate.

[0076] Figure 6 FIG. 2 is a flow chart of a specific implementation method of step S23 in the embodiment of the present disclosure. Figure 6 , wherein, in the case where the identification information includes a random encryption code, S23 includes:

[0077] S231, comparing the random encryption code in the preset authentication file with the random encryption code in the second authentication information;

[0078] S232: When the random encryption code in the preset authentication file is different from the random encryption code in the second authentication information, update the identification information and the authority information in the local preset authentication file to the second identification information and the second authority information in the second authentication information.

[0079] In an embodiment of the present disclosure, when the second authentication file in the second ADB authorization file is repeated with the preset authentication file (that is, the confirmation identification information and the second identification information are the same), the local preset authentication file will not be updated; when the second authentication file in the second ADB authorization file is not repeated with the preset authentication file (that is, the confirmation identification information and the second identification information are not the same), the local preset authentication file will be updated to the second authentication information.

[0080] The above-mentioned embodiment of the present disclosure retains a preset authentication file locally in the terminal. The preset authentication file is obtained by parsing and verifying an ADB authorization file (i.e., a first ADB authorization file and a second ADB authorization file). The ADB authorization file is generated by the manufacturer according to the terminal unique identification code of the terminal, and specifies the terminal's permission information for ADB, so that the terminal can open and use ADB within the corresponding restriction range of the permission information without verifying the ADB call instruction each time. Each time the terminal uses the preset authentication file, the file will be recorded. Once the permission information expires or exceeds the permission information, the terminal can no longer use the preset authentication file and needs to update the preset authentication file. By adding a mechanism for verifying permission information to the preset authentication file, the security of the terminal is effectively improved. Compared with the method in some related technologies that requires the user to verify each time he calls ADB, the embodiment of the present disclosure effectively reduces the complexity of user operations.

[0081] Second, refer to Figure 7 , an embodiment of the present disclosure provides an electronic device, comprising:

[0082] One or more processors 701;

[0083] A memory 702 having one or more programs stored thereon, which, when executed by one or more processors, enables the one or more processors to implement any one of the above-mentioned methods for calling the Android debug bridge;

[0084] One or more I / O interfaces 703 are connected between the processor and the memory and are configured to implement information exchange between the processor and the memory.

[0085] Among them, the processor 701 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 702 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); the I / O interface (read-write interface) 703 is connected between the processor 701 and the memory 702, and can realize information interaction between the processor 701 and the memory 702, including but not limited to a data bus (Bus), etc.

[0086] Thirdly, refer to Figure 8 The embodiment of the present disclosure provides a computer-readable medium on which a computer program is stored. When the program is executed by a processor, any one of the above-mentioned methods for calling the Android debug bridge is implemented.

[0087] In order to enable those skilled in the art to more clearly understand the technical solutions provided by the embodiments of the present disclosure, the technical solutions provided by the embodiments of the present disclosure are described in detail below through specific embodiments:

[0088] Fig. 9 This is a flowchart of a specific implementation method of the calling method of the Android debug bridge in the embodiment of the present disclosure, referring to Fig. 9 , the calling process of Android Debug Bridge is:

[0089] Step 901, the server on the manufacturer side generates a first ADB authorization file through an ADB authorization tool, including: a terminal unique identification code, a valid number of times (i.e., the number of ADB available times authorized to the terminal), an expiration time, a random encryption code, and encrypts and compresses the file through an encryption algorithm to obtain a ZIP (data compression file format) package. Among them, the first ADB authorization file needs to be encrypted when it is generated, so that the user cannot manually change the first ADB authorization file to crack it, thereby ensuring security.

[0090] In step 902, the ZIP package can be imported into the terminal through an external device, or the terminal can send an authorization file request to the manufacturer's server when the user needs it so that the manufacturer's server can feedback the ZIP package to the terminal, or the operation and maintenance personnel can send the ZIP package to the terminal through the network management system (which has received the ZIP package sent by the manufacturer's server in advance).

[0091] Step 903, the security component decompresses, decrypts and parses the ZIP package to obtain the terminal unique identification code, random encryption code, validity times, and expiration time.

[0092] In step 904, the security component verifies the random encryption code in the first ADB authorization file and the random encryption code stored locally in the preset authentication file. If the two are the same, execute step 906; otherwise, execute step 906.

[0093] Step 905: If the verification result is that the two are different, the random encryption code, the number of valid times and the expiration time are saved or updated in the local preset authentication file.

[0094] Step 906, if the verification result is the same, it means that the first authentication file in the first ADB authorization file in the ZIP package and the local preset authentication file are duplicated, then the random encryption password, validity times and expiration time are not saved or updated, and the original preset authentication file continues to be used. Waiting for receiving the user's call instruction to open ADB, the call instruction is sent by the user to the terminal in a general way, such as clicking 5 times in a row at the device version number to open ADB.

[0095] Step 907, after receiving the user's call instruction to open ADB, determine whether there is a preset authentication file locally in the terminal. If so, execute step 908. If not, ADB cannot be opened, and the user is prompted that the call instruction cannot be executed, and the user needs to apply for ADB authorization, and then the process ends.

[0096] Step 908, when there is a preset authentication file locally in the terminal, the terminal's security component queries whether the number of valid times in the current preset authentication file is greater than 0, and whether the expiration time is later than the current time. If so, execute step 909. If not, prompt the user that the call instruction cannot be executed, and the user needs to reapply for ADB authorization, and then end.

[0097] Step 909, if the valid times in the current preset authentication file are greater than 0 and the expiration time is later than the current time, and ADB is in a closed state, then ADB is opened, the call instruction is executed, and the valid times are reduced by one and saved, and then the process ends. If the valid times in the preset authentication file are equal to or less than 0, or the expiration time is earlier than the current time (i.e., the expiration time expires), a new ADB authorization file generated by the ADB authorization tool needs to be obtained again, and then re-imported into the terminal.

[0098] The above-mentioned embodiment of the present disclosure retains a preset authentication file locally in the terminal, and the preset authentication file provides permission information related to calling ADB, so that the identity authentication of the terminal does not need to be performed within the time range corresponding to the valid number of times and the expiration time, which reduces the operation and maintenance costs and reduces the complexity of user operations. Among them, the import of the preset authentication file needs to be provided by the manufacturer, and external docking developers can facilitate joint debugging. When there is a problem with the user's device, the operation and maintenance personnel can also issue authorization to facilitate problem location. At the same time, for unknown terminals, ADB will be controlled, reducing the system security risk of the device.

[0099] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0100] Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for limiting purposes. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly noted, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, those skilled in the art will appreciate that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A method for calling an Android debug bridge ADB, wherein: For a terminal, the method comprises: In response to a call instruction to the ADB, the ADB is called according to a local preset authentication file; the preset authentication file includes identification information and authority information of the terminal.

2. The calling method of the Android debugging bridge according to claim 1, wherein: In response to the calling instruction of the ADB, before calling the ADB according to the local preset authentication file of the terminal, the method further includes: Get the first ADB authorization file; Parsing the first ADB authorization file to obtain first authentication information; the first authentication information includes: first identification information and first authority information; The first identification information in the first authentication information is verified, and if the verification passes, the first authentication information is determined as the preset authentication file.

3. The calling method of the Android debugging bridge according to claim 2, wherein: The obtaining of the first ADB authorization file includes at least one of the following: Importing the first ADB authorization file through an external device of the terminal; Receiving the first ADB authorization file sent by the server; An ADB authorization request is sent to the server, and the first ADB authorization file fed back by the server is received.

4. The calling method of the Android debugging bridge according to claim 2, wherein: The authority information in the preset authentication file includes at least one of a valid number of times and an expiration time.

5. The calling method of the Android debugging bridge according to claim 4, wherein: In the case where the authority information includes a valid number of times, calling the ADB according to a local preset authentication file includes: Determine whether the valid times in the preset authentication file is greater than zero, and obtain a confirmation result; When the confirmation result shows that the valid number is greater than zero, the calling instruction is executed to call the ADB and reduce the valid number.

6. The calling method of the Android debugging bridge according to claim 1, wherein: Also includes: Update the local preset authentication file.

7. The method for calling the Android debugging bridge according to claim 6, wherein: The updating of the local preset authentication file includes: Get the second ADB authorization file; Parsing the second ADB authorization file to obtain second authentication information; the second authentication information includes: second identification information and second authority information; The local preset authentication file is updated according to the second authentication information.

8. The method for calling the Android debugging bridge according to claim 7, wherein: The identification information in the preset authentication file includes at least one of a terminal unique identification code and a random encryption code; Wherein, in the case where the identification information includes a random encryption code, updating the local preset authentication file according to the second authentication information includes: Comparing the random encryption code in the preset authentication file with the random encryption code in the second authentication information; When the random encryption code in the preset authentication file is different from the random encryption code in the second authentication information, the identification information and the authority information in the local preset authentication file are updated to the second identification information and the second authority information in the second authentication information.

9. A terminal, comprising: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the calling method of the Android debugging bridge according to any one of claims 1 to 8.

10. A computer-readable medium having a computer program stored thereon, wherein when the program is executed by a processor, the method for calling the Android debug bridge according to any one of claims 1 to 8 is implemented.