CN107391356B

CN107391356B - Method and device for acquiring stuck information and computer readable storage medium

Info

Publication number: CN107391356B
Application number: CN201710619453.6A
Authority: CN
Inventors: 刘文龙; 闫昊; 刘斌
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2017-07-26
Filing date: 2017-07-26
Publication date: 2020-09-25
Anticipated expiration: 2037-07-26
Also published as: CN107391356A

Abstract

The disclosure relates to a method and a device for acquiring stuck information and a computer readable storage medium, and belongs to the technical field of testing. The method comprises the following steps: sending a binary executable file to the mobile terminal, wherein the binary executable file is used for acquiring the stuck information based on the native process; sending a starting test instruction to the mobile terminal, wherein the starting test instruction is used for indicating the mobile terminal to operate the binary executable file; and acquiring the card pause information counted by the mobile terminal. The binary executable file for counting the stuck information in the disclosure runs in the native process in the operating system, can not be cleared by the operating system, and can always exist and run in the operating system, so that the stuck information occurring in the operating system during the running period can be completely counted, and the counting is more comprehensive. And the process of counting the card pause information is decoupled from the debugging tool daemon, so that the defect of counting failure caused by the conditions of blockage, suspension and the like of the debugging tool daemon in the counting process is avoided.

Description

Method and device for acquiring stuck information and computer readable storage medium

Technical Field

The present disclosure relates to the field of testing technologies, and in particular, to a method and an apparatus for acquiring stuck information, and a computer-readable storage medium.

Background

The blocking refers to the situation that the mobile terminal runs unsmoothly, such as picture stagnation, sound interruption and the like. In order to measure the blocking condition of the terminal when the application runs, the blocking information of the mobile terminal when the application runs needs to be acquired, and the blocking condition is measured through the blocking information.

The process of acquiring the morton information is generally realized by mutual communication between a control terminal and a mobile terminal: specifically, the control terminal can install a debugging tool, a debugging tool daemon is pre-established in an operating system of the mobile terminal, when the jam information of the mobile terminal in the application running process is to be acquired, the mobile terminal needs to establish connection with the debugging tool based on the debugging tool daemon, when the control terminal acquires a jam information acquisition instruction, the debugging tool daemon is instructed to acquire the jam information, the mobile terminal can run the debugging tool daemon, the jam condition in the application running process is counted, the counted jam information is output to the debugging tool through the connection, and the jam information is displayed by the control terminal.

Disclosure of Invention

In order to solve the problems in the related art, the present disclosure provides a morton information acquisition method, apparatus, and computer-readable storage medium. The technical scheme is as follows:

according to a first aspect of the embodiments of the present disclosure, a method for acquiring morton information is provided, where the method includes:

sending a binary executable file to the mobile terminal, wherein the binary executable file is used for acquiring stuck information based on a native process;

sending a starting test instruction to the mobile terminal, wherein the starting test instruction is used for indicating the mobile terminal to run the binary executable file;

and acquiring the card pause information counted by the mobile terminal.

In a possible implementation manner, before the sending the binary executable file to the mobile terminal, the method further includes:

obtaining a source file to be compiled;

compiling the source file into a binary executable file that needs to run based on a native process.

In another possible implementation manner, the sending the binary executable file to the mobile terminal includes:

executing a storage instruction for sending a file to the mobile terminal, wherein the storage instruction comprises the name of the binary executable file and a specified address for storing the binary executable file in the mobile terminal, and the specified address is a/data/local/tmp folder.

In another possible implementation manner, the obtaining the stuck information counted by the mobile terminal includes:

and executing a pulling instruction for pulling the file from the mobile terminal, wherein the pulling instruction is used for indicating the katon information obtained by reading and counting from a preset target file in the mobile terminal.

In another possible implementation manner, the start test instruction carries a preset period and/or preset times, the preset period is used for instructing the mobile terminal to execute the step of running the binary executable file once every other preset period, and the preset times are used for instructing the mobile terminal to obtain the times of the morton information.

In another possible implementation manner, before sending the binary executable file to the mobile terminal, the method further includes:

and acquiring a test instruction, wherein the test instruction is used for indicating to test the mobile terminal.

According to a second aspect of the embodiments of the present disclosure, there is provided a method for acquiring stuck information, the method including:

receiving a binary executable file sent by a control terminal, wherein the binary executable file is used for acquiring stuck information based on a native process;

receiving a starting test instruction sent by the control terminal, wherein the starting test instruction is used for indicating the mobile terminal to run the binary executable file;

and operating the binary executable file to acquire the morton information.

In a possible implementation manner, the receiving the binary executable file sent by the control terminal includes:

and receiving the binary executable file and storing the binary executable file at a specified address, wherein the specified address is a/data/local/tmp folder.

In another possible implementation manner, after receiving the binary executable file sent by the control terminal, the method further includes:

and when the debugging tool daemon is determined to have the authority of creating the file in the specified address, executing the step of receiving the binary executable file and storing the binary executable file in the specified address through the debugging tool daemon.

In another possible implementation manner, the running the binary executable file to obtain morton information includes:

when determining that a designated process has the authority to start the file in the designated address, starting the binary executable file through the designated process;

creating a native process running the binary executable;

and acquiring the morton information through the native process.

In another possible implementation manner, after the running the binary executable file and obtaining the morton information, the method further includes:

storing the morton information in a preset target file in the mobile terminal;

and sending the pause information in the preset target file to the control terminal based on the pulling request of the control terminal.

In another possible implementation manner, the starting the test instruction carries a preset period, and the running the binary executable file to obtain the morton information includes:

executing the step of operating the binary executable file once every other preset period to acquire the pause information; and/or the presence of a gas in the gas,

the starting test instruction carries preset times, the binary executable file is operated, and the morton information is obtained, and the method comprises the following steps:

and running the binary executable file to acquire the pause information until the number of acquiring the pause information reaches the preset number.

and running the binary executable file based on the native process, and calling an output method of a drawing statistical service to acquire and output the morton information.

According to a third aspect of the embodiments of the present disclosure, there is provided a stuck information acquiring apparatus, the apparatus including:

the sending module is used for sending a binary executable file to the mobile terminal, wherein the binary executable file is used for acquiring the morton information based on the native process;

the sending module is further configured to send a start test instruction to the mobile terminal, where the start test instruction is used to instruct the mobile terminal to run the binary executable file;

and the acquisition module is also used for acquiring the card pause information counted by the mobile terminal.

In a possible implementation manner, the obtaining module is further configured to obtain a source file to be compiled;

the device further comprises: and the compiling module is used for compiling the source file into a binary executable file, and the binary executable file needs to run based on a native process.

In another possible implementation manner, the sending module is further configured to execute a storage instruction for sending a file to the mobile terminal, where the storage instruction includes a name of the binary executable file and a specified address for storing the binary executable file in the mobile terminal, and the specified address is a/data/local/tmp folder.

In another possible implementation manner, the obtaining module is configured to execute a pull instruction for pulling a file from the mobile terminal, where the pull instruction is used to instruct to read statistical stuck information from a preset target file in the mobile terminal.

In another possible implementation manner, the obtaining module is further configured to obtain a test instruction, where the test instruction is used to instruct to test the mobile terminal.

According to a fourth aspect of the embodiments of the present disclosure, there is provided a stuck information acquiring apparatus, the apparatus including:

the system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving a binary executable file sent by a control terminal, and the binary executable file is used for acquiring the morton information based on a native process;

the receiving module is further configured to receive a start test instruction sent by the control terminal, where the start test instruction is used to instruct the mobile terminal to run the binary executable file;

and the acquisition module is used for operating the binary executable file to acquire the morton information.

In a possible implementation manner, the receiving module is further configured to receive the binary executable file and store the binary executable file at a specified address, where the specified address is a/data/local/tmp folder.

In another possible implementation manner, the receiving module is further configured to, when it is determined that the debugging tool daemon has the right to create a file in the specified address, execute, by the debugging tool daemon, the step of receiving the binary executable file and storing the binary executable file in the specified address.

In another possible implementation manner, the obtaining module includes:

the starting module is used for starting the binary executable file through the specified process when the specified process is determined to have the right of starting the file in the specified address;

a creating submodule for creating a native process for running the binary executable file;

and the obtaining submodule is used for obtaining the morton information through the native process.

In another possible implementation manner, the apparatus further includes: the storage module is used for storing the pause information into a preset target file in the mobile terminal;

and the sending module is used for sending the pause information in the preset target file to the control terminal based on the pulling request of the control terminal.

In another possible implementation manner, the start test instruction carries a preset period, and the obtaining module is configured to execute the step of running the binary executable file once every other preset period to obtain morton information; and/or the presence of a gas in the gas,

the starting test instruction carries preset times, and the obtaining module is used for operating the binary executable file to obtain the morton information until the times of obtaining the morton information reach the preset times.

In another possible implementation manner, the obtaining module is configured to run the binary executable file based on the native process, and call an output method of a graph statistics service to obtain and output the morton information.

According to a fifth aspect of the embodiments of the present disclosure, there is provided a stuck information acquiring apparatus, the apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

and acquiring the card pause information counted by the mobile terminal.

According to a sixth aspect of the embodiments of the present disclosure, there is provided a stuck information acquiring apparatus, the apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

and operating the binary executable file to acquire the morton information.

According to a seventh aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium on which a computer program is stored, wherein the program, when executed by a processor, implements the steps of the method of the first aspect.

According to an eighth aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the method of the second aspect.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects:

according to the method, the device and the computer readable storage medium provided by the embodiment, the control terminal sends the binary executable file to the mobile terminal, and the mobile terminal can run the binary executable file through the native process and execute the process of counting the stuck information. And the process of counting the stuck information is decoupled from the debugging tool daemon, namely the debugging tool daemon is not needed to be relied on, so that the defect of failure in counting caused by the conditions of blockage of the debugging tool daemon, hanging of the debugging tool daemon and the like in the counting process is avoided, and the efficiency of obtaining the stuck information is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.

FIG. 1 is a schematic diagram of an implementation environment shown in accordance with an exemplary embodiment;

FIG. 2 is a flow diagram illustrating a method of Cartesian information acquisition in accordance with an illustrative embodiment;

FIG. 3 is a flow diagram illustrating a method of Cartesian information acquisition in accordance with an illustrative embodiment;

FIG. 4A is a flow diagram illustrating a method of Cartesian information acquisition in accordance with an illustrative embodiment;

FIG. 4B is a flow diagram illustrating a method of Cartesian information acquisition in accordance with an illustrative embodiment;

FIG. 5A is a block diagram illustrating a Cartesian information acquisition apparatus in accordance with an illustrative embodiment;

FIG. 5B is a block diagram illustrating a Cartesian information acquisition apparatus in accordance with an illustrative embodiment;

FIG. 6A is a block diagram illustrating a Cartesian information acquisition apparatus in accordance with an illustrative embodiment;

FIG. 6B is a block diagram illustrating a Cartesian information acquisition apparatus in accordance with an illustrative embodiment;

FIG. 6C is a block diagram illustrating a Cartesian information acquisition apparatus in accordance with an illustrative embodiment;

fig. 7 is a block diagram illustrating a morton information acquiring apparatus according to an exemplary embodiment.

Detailed Description

To make the objects, technical solutions and advantages of the present disclosure more apparent, the present disclosure is described in further detail below with reference to the embodiments and the accompanying drawings. The exemplary embodiments and descriptions of the present disclosure are provided herein for illustration of the present disclosure, but not for limitation of the present disclosure.

Fig. 1 is a schematic diagram illustrating an implementation environment according to an exemplary embodiment, and as shown in fig. 1, the implementation environment includes a control terminal 101 and a mobile terminal 102, and the control terminal 101 and the mobile terminal 102 may communicate by establishing a connection.

The connection may be a wired connection, which may be a USB (universal serial bus) connection, or a Wireless connection, which may be a Wireless Fidelity (WI-FI) connection, bluetooth, data network connection, etc.

The control terminal 101 is used for testing the mobile terminal 102 to obtain the stuck information of the operating system of the mobile terminal 102 during the running process. Further, the mobile terminal 102 may be a mobile terminal installed with an open operating system, and accordingly, the obtained morton information is the morton information of the application executed by the mobile terminal 102 under the control of the open operating system, which may be an Android operating system.

The control terminal 101 may be a desktop computer, a notebook computer, etc., and the mobile terminal 102 may be a mobile phone, a tablet computer, etc.

Fig. 2 is a flow chart illustrating a method of acquiring stuck information according to an example embodiment. The execution subject of this embodiment is a control terminal, and referring to fig. 2, the method includes:

in step 201, a binary executable file is sent to the mobile terminal, and the binary executable file is used for performing morton information acquisition based on a native process.

In step 202, a start test instruction is sent to the mobile terminal, where the start test instruction is used to instruct the mobile terminal to run the binary executable file.

In step 203, the card-ton information counted by the mobile terminal is acquired.

According to the method provided by the embodiment of the disclosure, the control terminal sends the binary executable file to the mobile terminal, and the mobile terminal can run the binary executable file through the native process to execute the process of counting the stuck information. And the process of counting the stuck information is decoupled from the debugging tool daemon, namely the debugging tool daemon is not needed to be relied on, so that the defect of failure in counting caused by the conditions of blockage of the debugging tool daemon, hanging of the debugging tool daemon and the like in the counting process is avoided, and the efficiency of obtaining the stuck information is improved.

obtaining a source file to be compiled;

the source file is compiled into a binary executable file that needs to run based on the native process.

and executing a storage instruction for sending a file to the mobile terminal, wherein the storage instruction comprises the name of the binary executable file and a specified address for storing the binary executable file in the mobile terminal, and the specified address is a/data/local/tmp folder.

In another possible implementation manner, the start test instruction carries a preset period and/or a preset number of times, where the preset period is used to instruct the mobile terminal to execute the step of running the binary executable file once every other preset period, and the preset number of times is used to instruct the mobile terminal to obtain the number of times of acquiring the morton information.

In another possible implementation manner, before the sending the binary executable file to the mobile terminal, the method further includes:

Fig. 3 is a flow chart illustrating a method of acquiring stuck information according to an example embodiment. The execution subject of the embodiment is a mobile terminal, and referring to fig. 3, the method includes:

in step 301, a binary executable file sent by the control terminal is received, where the binary executable file is used for performing morton information acquisition based on a native process.

In step 302, a start test instruction sent by the control terminal is received, where the start test instruction is used to instruct the mobile terminal to run the binary executable file.

In step 303, the binary executable file is run to obtain the morton information.

the binary executable file is received and stored at a specified address, which is the/data/local/tmp folder.

when it is determined that the debugging tool daemon has the authority to create a file in the specified address, the step of receiving the binary executable file and storing the binary executable file in the specified address is performed by the debugging tool daemon.

In another possible implementation manner, the running the binary executable file to obtain the morton information includes:

when determining that the designated process has the right to start the file in the designated address, starting the binary executable file through the designated process;

creating a native process running the binary executable file;

through the native process, the morton information is acquired.

storing the morton information in a preset target file in the mobile terminal;

and sending the card pause information in the preset target file to the control terminal based on the pulling request of the control terminal.

In another possible implementation manner, the starting test instruction carries a preset period, and the running the binary executable file to obtain the morton information includes:

executing the step of running the binary executable file once every other preset period to acquire the pause information; and/or the presence of a gas in the gas,

the starting test instruction carries preset times, the binary executable file is operated, and the morton information is obtained, and the starting test instruction comprises the following steps:

and running the binary executable file based on the native process, and calling an output method of the drawing statistical service to acquire and output the pause information.

In the scheme for acquiring the morton information provided by the related art, the mobile terminal operates the debugging tool daemon to count the morton information and outputs the morton information to the debugging tool of the control terminal through the debugging tool daemon, and the efficiency of acquiring the morton information in the scheme is very low.

On the one hand, due to the inherent defects of the codes of the debugging tool daemon process, various unpredictable problems often occur in the statistical process, such as process blockage, process suspension and the like, so that the statistics is interrupted or the data is inaccurate. On the other hand, with diversification of the mobile terminal operating system, a situation that compatibility between a debugging tool daemon in the mobile terminal operating system and a debugging tool of the control terminal is poor often occurs, so that the mobile terminal and the control terminal cannot communicate for a long time. In the process of counting the stuck information by the mobile terminal, the debugging tool daemon does not store the counted stuck information at the home terminal of the mobile terminal, but directly outputs the stuck information to the control terminal, and once the communication with the test tool is lost, the counted stuck information is lost. Particularly, in the process of acquiring the morton information once, when the mobile terminal needs to count the morton information for many times regularly, the counting time is usually longer, which is more likely to cause the failure of the process of counting the morton information due to the interruption of the communication between the debugging tool daemon and the debugging tool.

In the scheme, each instruction required in the process of acquiring the morton information is packaged into a binary executable file, and the mobile terminal runs the binary executable file through a native process to finish the process of acquiring the morton information. The instructions included in the binary executable file can be compiled by a tester, and can be compatible with various operating systems, the process of running the binary executable file is stable, and the situations of process blocking and process suspension are not easy to occur. In addition, in the counting process, the mobile terminal can be directly stored in the local terminal after the card pause information is obtained, the card pause information does not need to be sent to the control terminal in real time, the connection with the control terminal does not need to be kept in real time, and the counted card pause information is not lost due to the fact that the connection with the control terminal is disconnected in the counting process.

The embodiment of the disclosure can be applied to a scene of calculating the stuck information when the mobile terminal runs the application, in the scene, the control terminal instructs the mobile terminal to obtain the stuck information when the application runs and obtain the stuck information counted by the mobile terminal. The card pause information can reflect the card pause condition of a certain third-party application installed on the mobile terminal, and then a tester can analyze the performance of the third-party application according to the card pause information so as to improve the third-party application. In addition, the stuck information can also reflect the stuck condition of the system application of the mobile terminal, and a tester can analyze the performance of the system application according to the stuck information so as to improve the operating system of the mobile terminal.

Fig. 4A is a flow chart illustrating a method of acquiring stuck information according to an example embodiment. The interaction subject of the embodiment includes a control terminal and a mobile terminal, and referring to fig. 4A, the method includes:

in step 401, the control terminal compiles a binary executable file.

In the subsequent process, the mobile terminal needs to run the binary executable file to count the morton information, and in order to obtain the binary executable file, the control terminal is adopted to compile the source file in the step so as to obtain the binary executable file. Wherein, the step can include the following steps 4011 and 4012:

4011. and acquiring a source file to be compiled.

The control terminal may install a development tool for writing a source file. In the process of running the development tool, a tester can perform writing operation on the control terminal, and the development tool can detect the writing operation to obtain a written source file. The development tools may be C + +, C, java, Visual Basic, etc. Of course, the control terminal may directly obtain a source file that has been written in advance, for example, obtain a source file sent by another terminal, download a source file from a server, obtain a source file imported by a user, and the like.

4012. The source file is compiled into a binary executable file by a compilation tool.

In practical applications, from the viewpoint of file type, the file includes a binary executable file, an apk file, a jar file, and the like, and from the viewpoint of process type, the process includes a native (native) process, an android process, and the like. Different types of files can be run through different types of processes, for example, a binary executable file needs to be run through a native process, and an apk file needs to be run through an android process after being installed. The android process is low in priority, the android process is easy to kill (kill) to release the system memory when the system memory of the mobile terminal is insufficient, the native process is high in priority, and the native process cannot be killed even when the system memory is insufficient.

In view of this situation, in order to ensure that when the subsequent mobile terminal counts the morton information, the failure of the statistical process due to the fact that the running process is killed does not occur, in this step, the source file is compiled into the binary executable file, and then the subsequent mobile terminal acquires the morton information through the native process.

The compiling tool is used for compiling a source file, and may be gcc (GNU Compiler Collection). The process of compiling a binary executable file may actually be implemented by setting an include $ (BUILD _ E7 available) instruction in the compilation tool. Taking the name of the source file as main. The android.mk file is configured in the compiling tool, and the following code blocks are set in the android.mk file, so that the compiling tool compiles the source file main.cpp into a binary executable file graphicDump.

LOCAL_SRC_FILES:＝main.cpp；

LOCAL_MODULE:＝graphicDum；

include$(BUILD_E7ECUTABLE)；

It should be noted that this step 401 is only an optional step, and in practical applications, the control terminal may also directly obtain the compiled binary executable file, for example, obtain a binary executable file sent by another terminal, download the binary executable file from the server, obtain a binary executable file imported by the user, and the like.

In step 402, the control terminal obtains a test instruction.

After the control terminal obtains the binary executable file, when a tester wants to test the mobile terminal, a test instruction may be triggered on the control terminal, and the control terminal may obtain the test instruction, for example, the control terminal may detect the input test instruction, or display a test interface, and obtain the test instruction when a confirmation operation of a start option in the test interface is detected. The test instruction is used for indicating the mobile terminal to be tested.

It should be noted that this step 402 is only an optional step, and in practical applications, the control terminal may directly execute the following step 403 without acquiring a test instruction.

In step 403, the control terminal transmits the binary executable file to the mobile terminal.

The control terminal and the mobile terminal may establish a connection in advance, and the control terminal may transmit the binary executable file to the mobile terminal through the connection. Further, the control terminal may execute a storage instruction for sending a file to the mobile terminal, where the storage instruction carries a name of the binary executable file and a designated address for storing the binary executable file in the mobile terminal, so that the mobile terminal stores the binary executable file in the designated address. In addition, the storage instruction may also carry a path and a designated address of the binary executable file, where the path refers to an address of the control terminal storing the binary executable file, and the path may include a name of the binary executable file.

Wherein the designated address is a/data/local/tmp folder, or other address in the mobile terminal, or a default address. The store instruction may be an adb push instruction. Taking the name of the binary executable file as graphicDump as an example, the control terminal may execute the following storage instructions:

adb push graphicDump/data/local/tmp/graphicDump；

the first point to be described is that, in a process of triggering the control terminal to send the binary executable file, the control terminal may determine to send the binary executable file to the mobile terminal when a storage instruction is to be executed in a process of running a script file, where the script file includes each instruction required by the control terminal to complete a process of testing the mobile terminal, and the control terminal may sequentially read each instruction and automatically execute a corresponding operation. Alternatively, the control terminal may determine to transmit the binary executable file to the mobile terminal when a storage instruction input by a user is detected. Alternatively, the control terminal may display a test interface, and when a confirmation operation for a sending option in the test interface is detected, determine to send the binary executable file to the mobile terminal.

The second point to be noted is that the control terminal may store the binary executable file in a default storage address, copy the binary executable file in the default storage address when the binary executable file is to be transmitted to the mobile terminal, and transmit the copied binary executable file to the mobile terminal.

In step 404, after the mobile terminal receives the binary executable file sent by the control terminal, the binary executable file is stored in the designated address.

This step 404 corresponds to the step 403 described above. Wherein, if the control terminal executes a storage instruction including a designated address, the mobile terminal stores the binary executable file in the designated address. Further, the mobile terminal may start a debugging tool daemon, and store the file in the designated address through the debugging tool daemon.

Regarding the designated address, in consideration of practical applications, the operating system of the mobile terminal generally strictly controls various permissions of the process, that is, when it is determined that a process has a permission to perform a certain operation, the process is allowed to perform the operation, otherwise, the process is rejected to perform the operation. And the/data/local/tmp folder is a special folder for the operating system, and the folder is a folder reserved for a debugging channel by google for facilitating the debugging of the mobile terminal by developers, and is endowed with more rights.

In combination with the concept, in order to ensure that the debugging tool daemon can successfully store the binary executable file in the specified address and cannot reject the binary executable file by the operating system because the debugging tool daemon does not have the authority to create the file at the specified address, in the embodiment, the/data/local/tmp folder is used as the specified address of the mobile terminal for storing the binary executable file, and because the debugging tool daemon has the authority to create the file at the/data/local/tmp folder, the debugging tool daemon can store the binary executable file in the/data/local/tmp folder. That is, when the mobile terminal determines that the debugging tool daemon has the right to create a file in the specified address, the binary executable file is stored in the specified address by the debugging tool daemon.

Regarding the process in which the mobile terminal determines that the debugging tool daemon has the authority to create the file in the specified address, the mobile terminal may store the security policies of various processes, which indicate various operations that the corresponding processes are allowed to perform. When the debugging tool daemon is to store a file in a specified address, the mobile terminal may check a security policy of the debugging tool daemon, and when the security policy indicates that the debugging tool daemon is allowed to create the file in the specified address, determine that the debugging tool daemon has a right to create the file in the specified address. The security policy of the daemon process of the debugging tool may be a TE (Type implementation) file, and may be stored in a system/policy directory of the mobile terminal.

Taking the debugging tool daemon as the adbd process and the security policy of the debugging tool daemon as the adbd.te as an example, when the adbd process is to store a binary executable file in the/data/local/tmp folder, the operating system of the mobile terminal may read the adbd.te, and when the following codes are read in the adbd.te, it is determined that the adbd process has the authority to store the binary executable file in the/data/local/tmp folder.

#adb push/pull/data/local/tmp；

allow adbd shell_data_file:file create_file_perm；

It should be noted that, the above steps 403 and 404 may be actually implemented by a debugging tool installed on the control terminal and a debugging tool daemon run by the mobile terminal, that is, the control terminal sends the binary executable file to the mobile terminal through the debugging tool, and the mobile terminal may start the debugging tool daemon and receive the binary executable file in the process of running the debugging tool daemon. The debugging tool may be an adb (Android Debug Bridge), and the debugging tool daemon may be an adbd (adbdaemon ).

In step 405, the control terminal sends a start test instruction to the mobile terminal.

The start test instruction is used for instructing the mobile terminal to run the binary executable file through a native process, and the control terminal can obtain the start test instruction and send the start test instruction to the mobile terminal. For example, the control terminal may obtain a start test instruction when a start test instruction input by a user or a confirmation operation of a displayed test interface is detected. The start test instruction may be an adb shell instruction.

In a possible implementation manner, the start test instruction may carry a preset period, where the preset period is used to instruct the mobile terminal to execute the step of running the binary executable file through the native process once every other preset period. The preset period may be a default value set by the tester, for example, half an hour. Alternatively, the preset period may be set manually by the user.

In the process of setting the preset period by the user, the user can carry the preset period in the test instruction when inputting the test instruction, and the control terminal can acquire the preset period from the test instruction and carry the preset period in the start-up test instruction. Or, when the user inputs the start test instruction, the start test instruction carries the preset period, and the control terminal may directly send the start test instruction carrying the preset period to the mobile terminal.

In addition, the start test instruction may also carry a preset number of times, where the preset number of times is used to indicate the number of times that the mobile terminal acquires the morton information. The preset number of times may be a default value set by the tester, for example, 3 times. Alternatively, the preset times may be manually set by the user, and the process of setting the preset times is similar to the process of setting the preset period, which is not described herein again.

Taking the launch test instruction as an adb shell instruction as an example, the code for launching the test instruction may be as follows:

adb shell"./data/local/tmp/graphicDump-t$TIME-n$N"&；

wherein, TIME is a preset period, and N is a preset number.

In step 406, the mobile terminal receives a start test instruction sent by the control terminal, and runs the binary executable file through the native process to obtain the morton information.

In practical application, when the mobile terminal receives a start test instruction, the binary executable file is started through a designated process, a native process is created, and the binary executable file is run through the native process.

The designated process is used to start a binary executable file, for example, a shell process, the native process is used to run the binary executable file, and the identifier of the binary executable file may be used as the identifier of the native process. Taking the starting test instruction as an adb shell instruction and the binary executable file as the graphicDump as an example, when the mobile terminal receives the adbsshell instruction, a shell process (a designated process) is started, the shell process is run to start the graphicDump, then the graphicDump process is created, and the graphicDump is run through the graphicDump process. Wherein the type of the created graphicDump process is a native process.

Further, the mobile terminal may start the binary executable file through the designated process when it is determined that the designated process has the authority to start the file in the designated address. For example, the mobile terminal may check the security policy of the designated process, determine whether the designated process has the authority to start the file in the designated address, and allow the designated process to start the binary executable file in the designated address when it is determined that the designated process has the authority to start the file in the designated address. The designated address can be a/data/local/tmp folder, the security policy of the designated process can be a TE file, and the security policy can be stored in a system/policy directory of the mobile terminal.

Taking an example that a designated process is a shell process and a security policy of the designated process is a shell.te, when the shell process needs to start a binary executable file in a/data/local/tmp folder, an operating system of the mobile terminal may read the shell.te, and when the following codes are read in the shell.te, it is determined that the shell process has a right to start a file in the/data/local/tmp folder.

#Access/data/local/tmp；

allow shell shell_data_file:file r7_file_perms；

Aiming at the process of acquiring and outputting the stuck information by the mobile terminal, the mobile terminal can call a dump method of a graphic statistics (graphics) service to acquire and output the stuck information. For example, the mobile terminal may count a total frame number, a total number of stuck frames, and a total length of stuck time, which are drawn during the process of running a certain application, between the current time point and the current time point, as the stuck information. The application may be a system application or a third party application.

When the starting test instruction carries a preset period, the mobile terminal runs the binary executable file through the native process every other preset period to obtain the morton information. For example, if the preset period is half an hour, the native process may read the binary executable file every half an hour, so as to obtain the morton information by running the binary executable file.

When the start test instruction carries a preset number of times, the mobile terminal runs the binary executable file through the native process to acquire the morton information until the number of times of acquiring the morton information reaches the preset number of times. For example, if the preset number of times is N, the native process counts the number of times of reading the binary executable file, and each time the binary executable file is read once, the number of times is added by 1 until the binary executable file is read N times, that is, N times of calton information is counted.

It should be noted that the mobile terminal may store the morton information in a preset target file, and the preset target file may be used for recording the morton information. For example, the binary executable file may include an output instruction, where the output instruction indicates a preset target file storing the card pause information, for example, a name or a path of the preset target file is carried, so that the mobile terminal stores the counted card pause information at the local terminal.

The method includes the steps that a certain file which is pre-established in the mobile terminal can be directly used as a preset target file, an output instruction can indicate that card pause information is stored in the preset target file, and after the native process obtains the output instruction, when the card pause information is counted, the card pause information can be directly output to the preset target file. Or the output instruction may instruct the mobile terminal to create a file for the morton information, the created file is used as a preset target file and the morton information is stored, the native process creates the preset target file after obtaining the output instruction, and outputs the morton information to the preset target file after counting the morton information. The preset target file may be a text file, and the path of the preset target file may be/sdcard/graphic.

In step 407, the control terminal acquires the stuck information counted by the mobile terminal.

The control terminal can execute a pull instruction, and the morton information is pulled from the mobile terminal, wherein the pull instruction is used for indicating the morton information obtained by reading and counting from a preset target file in the mobile terminal. The control terminal may send a pull request to the mobile terminal, and the mobile terminal may send the stuck information in the preset target file to the control terminal based on the pull request, or the control terminal may read the stuck information from the preset target file of the mobile terminal in other manners. In addition, the process of executing the pull instruction can be realized by the control terminal through a debugging tool.

The pull instruction may carry a name or a path of a preset target file, and for example, the pull instruction is an adb pull instruction, and the path of the preset target file is/sdcard/graphic, the pull instruction may be as follows:

adb-s$ANDROID_SERIAL pull/sdcard/graphic；

the first point to be described is that, in the process of counting the card-pause information by the mobile terminal, if the current system Memory is smaller than the Memory threshold, a Low Memory management mechanism (Low Memory Killer) is triggered, and the Low Memory management mechanism is used to kill the currently running process and release the system Memory, so as to ensure that the current system Memory reaches the Memory threshold again. The low memory management mechanism can not kill the original process, and the process of calculating the stuck information can not be influenced.

This is because the low memory management mechanism determines the process to be killed according to oom _ adj of each currently running process, and the higher the value of a process oom _ adj is, the lower the priority of the process is, and the easier the low memory management mechanism is to kill the process. The value range of oom _ adj can be [ -17,15], and when the process is a visible process, oom _ adj is 0, and when the process is a background process, oom _ adj is 2. The native process oom _ adj is-17, which is extremely small, so low memory management mechanisms do not kill the native process.

The second point to be described is that the steps executed by the control terminal in the embodiment of the present disclosure may actually be implemented by the control terminal running a script file, where the script file includes a test instruction, a start test instruction, a storage instruction, and a pull instruction, and the control terminal may sequentially obtain the test instruction, the start test instruction, and the pull instruction in the process of reading the script file, and automatically execute the corresponding steps.

The third point to be described is that after the control terminal acquires the stuck information, the stuck information can be displayed, so that the tester can timely acquire the stuck information and perform development and analysis according to the stuck information.

It should be noted that, in the present embodiment, the control terminal executes the pull command and reads the morton information from the preset target file in the mobile terminal as an example. In another embodiment, the mobile terminal may upload the preset target file to the designated server after storing the morton information in the preset target file, and the control terminal may download the preset target file from the designated server and read the morton information.

Referring to fig. 4B, which shows a flowchart of a method according to an embodiment of the present disclosure, in an exemplary scenario, taking a control terminal as a computer and a mobile terminal as a mobile phone as an example, the embodiment of the present disclosure may actually include the following steps:

(1) and compiling the source file of the statistical morton information by the tester on the computer by using the development tool, and compiling the binary executable file in the android source code environment by using the compiling tool.

(2) And the computer executes the adb push instruction, and the mobile phone stores the binary executable file in the data/loca/tmp.

(3) And the computer executes the adb shell instruction, and the mobile phone starts the binary executable file.

(4) And the mobile phone starts a native process corresponding to the binary executable file, acquires the pause information at regular time and outputs the pause information to a preset target file in the mobile phone.

(5) And the computer executes the adb pull instruction and pulls the morton information from the preset target file for development and analysis.

Furthermore, the mobile terminal stores the counted jam-pause information at the local terminal in the counting process, the situation that the counted jam-pause information is lost due to communication interruption with the control terminal can be avoided, and the efficiency of acquiring the jam-pause information is improved.

Furthermore, the instructions required by the process of counting the stuck information are compiled into a binary executable file, so that the mobile terminal runs the binary executable file through the native process, and due to the higher priority of the native process, even if the memory of the mobile terminal is insufficient, the native process cannot be killed, the process of counting the stuck information cannot be influenced, and the process of counting the stuck information is more reliable.

Furthermore, the/data/local/tmp folder can be used as a designated address for storing the binary executable file, and since the debugging tool daemon has the right to create the file in the data/local/tmp folder, the debugging tool daemon can be ensured to successfully store the binary executable file. In addition, the appointed process has the authority of starting the file in the data/local/tmp folder, so that the appointed process can be ensured to successfully start the binary executable file, and the condition that the process does not have the corresponding authority so as to cause that the corresponding operation cannot be executed is avoided.

Further, the mobile terminal can acquire the stuck information every preset period, and the preset period can be set by a user, so that the requirement of the user for acquiring the stuck information at regular time is met. In addition, the mobile terminal can acquire the stuck information according to the preset times, the preset times can be set by the user, the requirement of the user for quantitatively acquiring the stuck information can be met, the method for acquiring the stuck information is expanded, and the flexibility for acquiring the stuck information is improved.

Fig. 5A is a block diagram illustrating a morton information acquiring apparatus according to an example embodiment. Referring to fig. 5A, the apparatus includes a sending module 501 and an obtaining module 502.

A sending module 501, configured to send a binary executable file to a mobile terminal, where the binary executable file is used for performing morton information acquisition based on a native process;

the sending module 501 is further configured to send a start test instruction to the mobile terminal, where the start test instruction is used to instruct the mobile terminal to run the binary executable file;

the obtaining module 502 is further configured to obtain the card pause information counted by the mobile terminal.

According to the device provided by the embodiment of the disclosure, the control terminal sends the binary executable file to the mobile terminal, and the mobile terminal can run the binary executable file through the native process to execute the process of counting the stuck information. And the process of counting the stuck information is decoupled from the debugging tool daemon, namely the debugging tool daemon is not needed to be relied on, so that the defect of failure in counting caused by the conditions of blockage of the debugging tool daemon, hanging of the debugging tool daemon and the like in the counting process is avoided, and the efficiency of obtaining the stuck information is improved.

In a possible implementation manner, the obtaining module 502 is further configured to obtain a source file to be compiled;

referring to fig. 5B, the apparatus further comprises: a compiling module 503 for compiling the source file into a binary executable file that needs to run based on a native process

In another possible implementation manner, the sending module 501 is further configured to execute a storage instruction for sending a file to the mobile terminal, where the storage instruction includes a name of the binary executable file and a specified address for storing the binary executable file in the mobile terminal, and the specified address is a/data/local/tmp folder.

In another possible implementation manner, the obtaining module 502 is configured to execute a pull instruction for pulling a file from the mobile terminal, where the pull instruction is used to instruct to read statistically obtained morton information from a preset target file in the mobile terminal.

In another possible implementation manner, the obtaining module 502 is further configured to obtain a test instruction, where the test instruction is used to instruct to test the mobile terminal.

Fig. 6A is a block diagram illustrating a morton information acquisition apparatus according to an example embodiment. Referring to fig. 6A, the apparatus includes a receiving module 601 and an obtaining module 602.

A receiving module 601, configured to receive a binary executable file sent by a control terminal, where the binary executable file is used for performing morton information acquisition based on a native process;

the receiving module 601 is further configured to receive a start test instruction sent by the control terminal, where the start test instruction is used to instruct the mobile terminal to run the binary executable file;

the obtaining module 602 is configured to run the binary executable file to obtain the morton information.

In a possible implementation manner, the receiving module 601 is further configured to receive the binary executable file and store the binary executable file at a specified address, where the specified address is a/data/local/tmp folder.

In another possible implementation manner, the receiving module 601 is further configured to, when it is determined that the debugging tool daemon has the right to create a file in the specified address, execute the step of receiving the binary executable file and storing the binary executable file in the specified address by the debugging tool daemon.

In another possible implementation manner, referring to fig. 6B, the obtaining module 602 includes:

and the obtaining submodule is used for obtaining the stuck information through the native process.

In another possible implementation, referring to fig. 6C, the apparatus further includes: a storage module 603, configured to store the mortgage information in a preset target file in the mobile terminal;

a sending module 604, configured to send the morton information in the preset target file to the control terminal based on the pull request of the control terminal.

In another possible implementation manner, the start test instruction carries a preset period, and the obtaining module 602 is configured to execute the step of running the binary executable file once every other preset period to obtain the morton information; and/or the presence of a gas in the gas,

the start test instruction carries a preset number of times, and the obtaining module 602 is configured to run the binary executable file to obtain the morton information until the number of times of obtaining the morton information reaches the preset number of times.

In another possible implementation manner, the obtaining module 602 is configured to execute the binary executable file based on the native process, and call an output method of the graph statistics service to obtain and output the morton information.

All the above optional technical solutions may be combined arbitrarily to form the optional embodiments of the present disclosure, and are not described herein again.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

It should be noted that: in the embodiment, when acquiring the morton information, the morton information acquiring apparatus is exemplified by only the division of the functional modules, and in practical applications, the function distribution may be completed by different functional modules according to needs, that is, the internal structures of the control terminal and the mobile terminal are divided into different functional modules to complete all or part of the functions described above. In addition, the morton information obtaining apparatus and the morton information obtaining method provided by the above embodiment belong to the same concept, and the specific implementation process thereof is detailed in the method embodiment and is not described herein again.

Fig. 7 is a block diagram illustrating a morton information acquisition device 700 according to an example embodiment. For example, the apparatus 700 may be a mobile phone, a computer, a digital broadcaster, a messaging device, a game console, a tablet device, a medical device, an exercise device, a personal digital assistant, and the like.

Referring to fig. 7, apparatus 700 may include one or more of the following components: a processing component 702, a memory 704, a power component 706, a multimedia component 708, an audio component 710, an input/output (I/O) interface 712, a sensor component 714, and a communication component 716.

The processing component 702 generally controls overall operation of the device 700, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing components 702 may include one or more processors 720 to execute instructions to perform all or a portion of the steps of the methods described above. Further, the processing component 702 may include one or more modules that facilitate interaction between the processing component 702 and other components. For example, the processing component 702 may include a multimedia module to facilitate interaction between the multimedia component 708 and the processing component 702.

The memory 704 is configured to store various types of data to support operations at the apparatus 700. Examples of such data include instructions for any application or method operating on device 700, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 704 may be implemented by any type or combination of volatile or non-volatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

The power supply component 706 provides power to the various components of the device 700. The power components 706 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the apparatus 700.

The multimedia component 708 includes a screen that provides an output interface between the device 700 and a user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 708 includes a front facing camera and/or a rear facing camera. The front camera and/or the rear camera may receive external multimedia data when the device 700 is in an operation mode, such as a photographing mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

The audio component 710 is configured to output and/or input audio signals. For example, audio component 710 includes a Microphone (MIC) configured to receive external audio signals when apparatus 700 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal may further be stored in the memory 704 or transmitted via the communication component 716. In some embodiments, audio component 710 also includes a speaker for outputting audio signals.

The I/O interface 712 provides an interface between the processing component 702 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

The sensor assembly 714 includes one or more sensors for providing status assessment of various aspects of the apparatus 700. For example, sensor assembly 714 may detect an open/closed state of device 700, the relative positioning of components, such as a display and keypad of device 700, sensor assembly 714 may also detect a change in position of device 700 or a component of device 700, the presence or absence of user contact with device 700, orientation or acceleration/deceleration of device 700, and a change in temperature of device 700. The sensor assembly 714 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 714 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 714 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 716 is configured to facilitate wired or wireless communication between the apparatus 700 and other devices. The apparatus 700 may access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 716 receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 716 further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the apparatus 700 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components for performing the above-described stuck information acquisition method performed by the control terminal or the mobile terminal.

In an exemplary embodiment, a computer-readable storage medium comprising instructions, such as the memory 704 comprising instructions, executable by the processor 720 of the apparatus 700 to perform the above-described method is also provided. For example, the computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

The embodiment of the present disclosure also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method for acquiring morton information executed by the control terminal in the above-mentioned embodiment is implemented.

The embodiment of the present disclosure also provides another computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the morton information obtaining method executed by the mobile terminal in the above-mentioned embodiment.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for acquiring Canton information, the method comprising:

and acquiring the card pause information counted by the mobile terminal.

2. The method of claim 1, wherein prior to sending the binary executable file to the mobile terminal, the method further comprises:

obtaining a source file to be compiled;

3. The method of claim 1, wherein sending the binary executable file to the mobile terminal comprises:

4. The method according to claim 1, wherein the obtaining of the stuck information counted by the mobile terminal comprises:

5. The method according to claim 1, wherein the start test instruction carries a preset period and/or a preset number of times, the preset period is used for instructing the mobile terminal to execute the step of running the binary executable file once every other preset period, and the preset number of times is used for instructing the mobile terminal to obtain the number of times of morton information.

6. The method of claim 1, wherein prior to sending the binary executable file to the mobile terminal, the method further comprises:

7. A method for acquiring Canton information, the method comprising:

receiving a starting test instruction sent by the control terminal, wherein the starting test instruction is used for indicating the mobile terminal to operate the binary executable file;

and operating the binary executable file to acquire the morton information.

8. The method of claim 7, wherein the receiving the binary executable file sent by the control terminal comprises:

9. The method of claim 8, wherein after receiving the binary executable file sent by the control terminal, the method further comprises:

10. The method of claim 8, wherein the running the binary executable file, obtaining katon information, comprises:

creating a native process running the binary executable;

and acquiring the morton information through the native process.

11. The method of claim 8, wherein after the executing the binary executable file obtains the morton information, the method further comprises:

storing the morton information in a preset target file in the mobile terminal;

12. The method of claim 7, wherein the initiating test instruction carries a preset period, and the running the binary executable file to obtain the morton information comprises:

13. The method of claim 7, wherein the running the binary executable file, obtaining katon information, comprises:

and operating the binary executable file, calling an output method of the drawing statistical service, and acquiring and outputting the pause information.

14. A morton information acquisition apparatus, characterized in that the apparatus comprises:

15. The apparatus of claim 14,

the obtaining module is also used for obtaining a source file to be compiled;

16. The apparatus according to claim 14, wherein the sending module is further configured to execute a storage instruction for sending a file to the mobile terminal, the storage instruction including a name of the binary executable file and a designated address for storing the binary executable file in the mobile terminal, the designated address being a/data/local/tmp folder.

17. The apparatus according to claim 14, wherein the obtaining module is configured to execute a pull instruction for pulling a file from the mobile terminal, and the pull instruction is configured to instruct to read statistical stuck information from a preset target file in the mobile terminal.

18. The apparatus according to claim 14, wherein the start test instruction carries a preset period and/or a preset number of times, the preset period is used to instruct the mobile terminal to execute the step of running the binary executable file once every other preset period, and the preset number of times is used to instruct the mobile terminal to obtain the number of times of morton information.

19. The apparatus of claim 14, wherein the obtaining module is further configured to obtain a test instruction, and the test instruction is used to instruct to test the mobile terminal.

20. A morton information acquisition apparatus, characterized in that the apparatus comprises:

21. The apparatus of claim 20, wherein the receiving module is further configured to receive the binary executable file and store the binary executable file at a specified address, and the specified address is a/data/local/tmp folder.

22. The apparatus of claim 21, wherein the receiving module is further configured to perform the step of receiving the binary executable file and storing the binary executable file at a specified address by a debugging tool daemon when the debugging tool daemon is determined to have the right to create the file at the specified address.

23. The apparatus of claim 21, wherein the obtaining module comprises:

24. The apparatus of claim 21, further comprising: the storage module is used for storing the pause information into a preset target file in the mobile terminal;

25. The apparatus according to claim 20, wherein the start test instruction carries a preset period, and the obtaining module is further configured to execute the step of running the binary executable file once every other preset period to obtain the morton information; and/or the presence of a gas in the gas,

the starting test instruction carries preset times, and the obtaining module is further used for operating the binary executable file to obtain the morton information until the times of obtaining the morton information reach the preset times.

26. The apparatus of claim 20, wherein the obtaining module is further configured to execute the binary executable file based on the native process, call an output method of a graph statistics service, and obtain and output the morton information.

27. A kind of stuck information acquisition device, characterized by comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

and acquiring the card pause information counted by the mobile terminal.

28. A kind of stuck information acquisition device, characterized by comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

and operating the binary executable file to acquire the morton information.

29. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the katon information acquisition method of any one of claims 1 to 6.

30. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the katon information acquisition method of any one of claims 7 to 13.