Detailed Description
The present application is further described with reference to the following figures and specific examples. The described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person skilled in the art without making any inventive step are within the scope of protection of the present application.
In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.
Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.
1) The breakpoint is a position at which the application is suspended and the operation is interrupted. When an application is suspended from running to a breakpoint, the state of the application at that time may be referred to as being in an interruption mode. The application program in the interruption mode does not terminate or end running, and when the normal running of the application program is resumed, the application program continues to execute subsequent running logic from the breakpoint.
2) Activity component (Activity), is one of the four most basic components in Android components. The activity component can provide a user interface primarily for interacting with a user. The activity component can display some controls for the user to operate, and in addition, the activity component can also monitor events triggered by the user on a terminal screen and respond to the events.
3) An Application Programming Interface (API) is a convention for linking different components of a software system. The primary purpose of an API is to be able to call a set of routine functions without regard to the underlying source code of the routine or understanding the details of the internal working mechanisms of the routine. An API is a set of thousands of extremely complex functions and subroutines with which tasks such as "reading a file," "displaying a menu," "displaying a web page in a window," and the like can be implemented. The API of the operating system may be used to allocate memory or read files, etc. Many system level applications can be implemented via APIs, such as graphics systems, databases, web services, online games, and the like.
4) A dynamic library file is a method for realizing a shared function library, and can enable a process to call a function which does not belong to an executable code. Dynamic library files contain one or more functions that have been compiled, linked, and stored separately from the process in which they are used.
5) A class is a collection of interrelated properties and behaviors, for example, java is an object-oriented language, and all Java code is composed of individual classes.
6) The class loader is a tool (e.g., classloader and its subclasses) responsible for loading, verifying, preparing, parsing, initializing the compiled bytecode product, and finally providing the class to the program. Classes in a Java program, from the writing of source code (e.g., java text file) to the final running, need to go through the processes of compiling (i.e., outputting bytecode), loading, verifying, preparing, parsing, initializing, and finally using, and in order to implement these processes, the participation of a class loader is required.
7) The Java Native Interface (JNI) refers to a Native method of Java, and allows Java code to interact with code written in other languages. By writing the program by using the JNI, the program code can be transplanted on different platforms, so that the flexible writing of the program code is facilitated.
8) The JNI reflection technology is a method for calling functions by using JNI. For example, a function written in another language (e.g., C language or C + + language) is called by Java code, and then return values of some functions written in Java code are obtained in reverse through the function.
At present, because the development threshold of apps is low, each large App is in a state of wild growth, and therefore, the exposed problem is more and more serious. In order to detect problems of apps, a common processing scheme at present generally detects problems of apps through a sandbox technology. The problem detection scheme is that an App is operated in a single isolation environment, and when the App calls a target API, a call request is actually sent to a sandbox, so that call information of the target API can be acquired through the sandbox technology, and whether the operation of the App has a problem can be judged through the call information. However, the security component for the sandbox technology is arranged in the current partial App, and when the security component detects that the App is operated in the isolation environment provided by the sandbox technology, the security component can enable the App to flash back, so that the App cannot be operated, and therefore problem detection cannot be performed on the App. In order to solve the problem that problem detection cannot be performed on the App through a sandbox technology, a feasible method is to modify a code of the App, obtain a relevant code logic of program running information of the App by writing, then compile the modified code of the App, and further obtain the program running information in the running process of the App to perform problem detection on the App. However, this method needs to acquire the source code of App first, and in general, the source code of App is difficult to acquire, so this method is more suitable for problem detection for App developed autonomously, and therefore, this method has a problem of insufficient applicability.
In order to obtain program running information of a target App to judge whether the target App has a problem without modifying or compiling the target App, embodiments of the present application provide a data processing method, a data processing apparatus, and a computer-readable storage medium, where a debug connection between the target App and a client is established according to a first operation instruction, a breakpoint is set in the target App for a function that initializes a movable component according to a second operation instruction sent by the client, and then, in a case where the target App runs to the breakpoint, a target function is injected into the target App according to a third operation instruction sent by the client, so that the target function can obtain target call information that the target App calls the target API, and then the target call information is sent to the client, so that the client can display a processing result corresponding to the target call information, and a user can judge whether the target App has a problem according to the processing result. Because the breakpoint setting and the target function injection are executed according to the operation instruction after the debugging connection is established, and the target App does not need to be modified and compiled, the scheme provided by the embodiment of the application can acquire the program running information of the target App without modifying and compiling the target App, so that the applicability of problem detection of the target App can be improved.
Fig. 1 is a schematic diagram of an implementation environment provided by an embodiment of the present application. Referring to fig. 1, the implementation environment includes adebugging apparatus 101 and a terminal 102.
Thedebugging apparatus 101 may be a terminal device such as a tablet computer, a notebook computer, and a desktop computer, which are deployed with a Windows operating system, or may be a terminal device such as a tablet computer, a notebook computer, and a desktop computer, which are deployed with a macOS operating system, but is not limited thereto. Optionally, an Android Debug Bridge (Android Debug Bridge, ADB)tool 1011 and aclient 1012 for implementing remote debugging are installed on thedebugging apparatus 101, a Java Debug Wire Protocol (Java Debug Wire Protocol, JDWP) may be adopted to implement remote debugging of the target App installed on the terminal 102 based on theADB tool 1011, and theclient 1012 may provide a Graphical User Interface (GUI) so that a User may perform related control operations. The ADB tool is an auxiliary tool kit of an android mobile phone, mainly plays a role of debugging a bridge, and can realize interaction between a computer end and a simulator or real equipment through a command line window.
The terminal 102 may be a terminal device such as a tablet computer, a smart phone, a smart watch, and a smart band, which are deployed with an android system or a hongmeng system, but is not limited thereto. The terminal 102 and thedebugging apparatus 101 may be directly or indirectly connected through wired or wireless communication, which is not specifically limited in this embodiment of the present application.
Thedebugging apparatus 101 has at least functions of remotely debugging, setting a breakpoint, copying a file, and the like a target App installed in the terminal 102, and for example, can send various operation instructions to the terminal 102 in response to an operation of a user in a GUI of theclient 1012, so that the terminal 102 can perform operations such as setting a breakpoint, copying a file, and the like on the target App, and can inject a target function into the target App and acquire target call information of the target App calling the target API through the target function. In addition, thedebugging apparatus 101 also has a function of displaying the processing result through the GUI of theclient 1012, for example, when the processing result is target call information, thedebugging apparatus 101 may display the target call information through the GUI of theclient 1012 after receiving the target call information transmitted by the terminal 102; when the processing result is a processing report generated from the target call information, thedebugging apparatus 101 may generate a corresponding processing report from the target call information after receiving the target call information transmitted by the terminal 102, and then display the processing report through the GUI of theclient 1012.
The terminal 102 has at least a function of performing breakpoint setting, file copying, and the like on the target App according to the operation instruction sent by thedebugging apparatus 101, and for example, can perform operations such as breakpoint setting, file copying, and the like on the target App in response to the operation instruction sent by thedebugging apparatus 101, thereby injecting a target function into the target App, and acquiring target call information of the target App for calling the target API through the target function. In addition, after acquiring the target call information, the terminal 102 can also transmit the target call information to thedebugging apparatus 101, so that thedebugging apparatus 101 can display a processing result corresponding to the target call information.
Thedebugging apparatus 101 and the terminal 102 may be nodes in a Blockchain (Blockchain). The blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism and an encryption algorithm. The blockchain is essentially a decentralized database, which is a string of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, which is used for verifying the validity (anti-counterfeiting) of the information and generating the next block. The blockchain may include a blockchain underlying platform, a platform product service layer, and an application service layer. The block chain underlying platform can comprise processing modules such as user management, basic service, intelligent contract and operation monitoring. The user management module is responsible for identity information management of all blockchain participants, and comprises public and private key generation maintenance (account management), key management, user real identity and blockchain address corresponding relation maintenance (authority management) and the like, and under the authorization condition, the user management module supervises and audits the transaction condition of certain real identities and provides rule configuration (wind control audit) of risk control; the basic service module is deployed on all block chain node equipment and used for verifying the validity of the service request, recording the service request to storage after consensus on the valid request is completed, for a new service request, the basic service firstly performs interface adaptation analysis and authentication processing (interface adaptation), then encrypts service information (consensus management) through a consensus algorithm, transmits the service information to a shared account (network communication) completely and consistently after encryption, and performs recording and storage; the intelligent contract module is responsible for registering and issuing contracts, triggering the contracts and executing the contracts, developers can define contract logics through a certain programming language, issue the contract logics to a block chain (contract registration), call keys or other event triggering and executing according to the logics of contract clauses, complete the contract logics and simultaneously provide the function of upgrading and canceling the contracts; the operation monitoring module is mainly responsible for deployment, configuration modification, contract setting, cloud adaptation in the product release process and visual output of real-time states in product operation, such as: alarm, monitoring network conditions, monitoring node equipment health status, and the like. The platform product service layer provides basic capability and an implementation framework of typical application, and developers can complete block chain implementation of business logic based on the basic capability and the characteristics of the superposed business. The application service layer provides the application service based on the block chain scheme for the business participants to use.
In an optional implementation manner, thedebugging apparatus 101 is a desktop computer equipped with anADB tool 1011 and aclient 1012, and the terminal 102 is a smartphone with an android system deployed, where a target App is installed in theterminal 102. In response to a debugging connection operation of a user in aclient 1012, adebugging device 101 initiates a remote debugging connection to a terminal 102, and after thedebugging device 101 establishes the remote debugging connection with the terminal 102, in response to the user clicking a start button in theclient 1012, thedebugging device 101 sends an operation instruction to the terminal 102, so that the terminal 102 performs operations such as breakpoint setting, file copying and the like on a target App, thereby injecting a target function into the target App, and acquiring target calling information of the target App for calling the target API through the target function; after the terminal 102 acquires the target call information, the terminal 102 transmits the target call information to thedebugging apparatus 101, so that thedebugging apparatus 101 displays the target call information through theclient 1012. In response to the user clicking a stop button in theclient 1012, thedebugging apparatus 101 stops receiving the target call information transmitted by the terminal 102, then generates a processing report from these target call information, and then displays the processing report or displays download guidance information of the processing report.
Fig. 2 is a flowchart of a data processing method according to an embodiment of the present application. In the present embodiment, a terminal is taken as an example of an execution subject. Referring to fig. 2, the data processing method includes, but is not limited to, steps 110 to 170.
Step 110: and responding to the first operation instruction, and triggering debugging connection between the target App and the client.
In this step, when the terminal receives the first operation instruction sent by the debugging device, the terminal triggers the debugging connection between the target App and the client, so that the subsequent step can perform related processing (for example, processing such as setting a breakpoint, injecting a target function, and the like) on the target App according to other operation instructions from the debugging device.
It should be noted that, when a user operates in a client of the debugging apparatus and starts the target App in the terminal through the ADB tool, the target App in the terminal is pulled up and runs and is in a state of waiting for a debugging connection. When the client detects that the target App is normally pulled up to run, the client sends a first operation instruction to the terminal to request to establish debugging connection with the target App. When the terminal receives a first operating instruction sent by the debugging device, the terminal can respond to the first operating instruction to acquire the ID number of the target process of the target App, and then sends the ID number of the target process to the client, so that the client can map the remote debugging port to the local debugging device, connect to the remote debugging port according to the ID number of the target process, and establish debugging connection between the client and the target App.
Step 120: and receiving a second operation instruction sent by the client.
In this step, after the debugging connection between the target App and the client is successfully established, the client sends a second operation instruction to the terminal, so that the terminal can receive the second operation instruction sent by the client, and a breakpoint can be set in the target App in the subsequent step according to the second operation instruction.
For example, the client may construct a first debug request packet (i.e., a second operation instruction) according to a break point instruction provided by the JDWP protocol, and send the first debug request packet to the terminal, so that the terminal can perform, after receiving the first debug request packet, an operation of setting a BREAKPOINT in the target App according to the first debug request packet through a debug framework of the target App.
Step 130: and setting a breakpoint in the target App according to the second operation instruction, wherein the setting position of the breakpoint is the position of a function called by the target App to initialize the movable component.
In this step, since the second operation instruction sent by the client is received in step 120, a breakpoint can be set in the target App according to the second operation instruction, so that a target function for acquiring the target call information can be injected in the target App according to the breakpoint in the subsequent step.
It should be noted that the set position of the breakpoint is a position where the target App calls a function for initializing the active component, for example, the breakpoint may be set at the android. It should be noted that the android.app.activity.oncreate function is automatically called when the target App starts to run, and therefore, setting a breakpoint at the android.app.activity.oncreate function is equivalent to setting a remote debugging entry at the position where the target App starts to run, so that the target App can be conveniently injected with the target function in subsequent steps.
It should be noted that if the time for injecting the target function is too late, the problem that the target call information of the target API called by the target App cannot be completely and accurately obtained may occur, and in order to avoid this problem, in this step, a breakpoint is set at a position where the target App starts to run, so that the target App can be injected with the target function in the subsequent step before the target App formally runs its main function, and thus the target call information of the target API called by the target App can be obtained through the target function in the whole running process of the target App.
It should be noted that the android.app.activity.oncreate function is called when the active component is initialized, and in general, a SetContentView (int) function needs to be called in the android.app.activity.oncreate function to fill the user interface of the terminal screen. When the active component is started, an android.app.Activity.OnCreate function is called first, and the android.app.Activity.OnCreate function mainly executes some necessary initialization work of the active component during starting.
Step 140: and when the target App runs to the breakpoint, receiving a third operation instruction sent by the client.
In this step, since the breakpoint is set in the target App in step 130, when the target App runs to the breakpoint, the breakpoint is hit, so that the target App is suspended and runs in a suspended state. At this time, the client sends a third operation instruction to the terminal, so that the terminal can receive the third operation instruction sent by the client, so as to inject the target function into the target App according to the third operation instruction in the subsequent steps.
For example, after the target App runs to the breakpoint, the client may reconstruct a second debug request data packet (i.e., a third operation instruction) according to an invoke message command provided by the JDWP protocol, and send the second debug request data packet to the terminal, so that the terminal can inject a target function into the target App according to the second debug request data packet after receiving the second debug request data packet.
It should be noted that the second debug request packet in this step and the first debug request packet in step 120 have the same packet structure, and the difference between the two is that the carried control instruction information is different, where the control instruction information carried by the first debug request packet in step 120 is break point instruction information, and the control instruction information carried by the second debug request packet in this step is invoke message instruction information. In an optional embodiment, the second debug request packet in this step and the first debug request packet in step 120 may be normal Transmission Control Protocol (TCP) packets, where the first debug request packet carries break key instruction information, and the second debug request packet carries invoke instruction information.
Step 150: and injecting a target function in the target App according to the third operation instruction.
In this step, since the third operation instruction sent by the client is received in step 140, the target function may be injected into the target App according to the third operation instruction, so that the target function can obtain the target call information of the target API called by the target App.
It should be noted that, since the operation of injecting the target function is performed according to the third operation instruction, and the target App does not need to be modified and compiled, the target function for acquiring the target call information can be injected into the target App without modifying and compiling the target App, so that the target call information when the target App calls the target API can be acquired through the target function in the subsequent step.
Step 160: and acquiring target calling information through the target function, wherein the target calling information is calling information of calling a target API (application program interface) by the target App.
In this step, since the target function is already injected into the target App in step 150, in the running process of the target App, the target call information when the target App calls the target API can be obtained through the target function, so that the target call information can be sent to the client in the subsequent step, and the client can perform relevant processing according to the target call information (for example, display the target call information, or display a processing report obtained according to the target call information).
It should be noted that, after step 150 is executed to inject a target function into the target App, the target App may resume running of a logic program thereof, and when the target App calls the target API in the running process, the target App may obtain target call information when the target App calls the target API through the target function, so that the client may display a corresponding processing result according to the target call information in subsequent steps.
It should be noted that the target call information includes, but is not limited to, a stack, parameters, a return value, and the like when the target API is called, and by performing relevant analysis processing on the target call information, a conclusion that whether the target App has a problem can be obtained, so that the user can optimize and improve the target App when the target App has a problem.
Step 170: and sending the target calling information to the client so that the client displays a processing result corresponding to the target calling information.
In this step, since the target call information is obtained through the target function in step 160, the target call information may be sent to the client, so that the client may display a corresponding processing result according to the target call information, thereby facilitating a user to determine whether the target App has a problem according to the processing result.
It should be noted that the processing result may be the target call information, or may be a processing report generated by the client according to the target call information, and may be appropriately selected according to the actual application, which is not specifically limited in this embodiment.
In this embodiment, by using the data processing method including the foregoing steps 110 to 170, a debug connection between the target App and the client is established according to the first operation instruction, then a breakpoint is set in the target App for a function that initializes the active component according to the second operation instruction sent by the client, and then the target function is injected into the target App according to the third operation instruction sent by the client when the target App runs to the breakpoint, so that the target function can obtain target call information that the target App calls the target API, and then the target call information is sent to the client, so that the client can display a corresponding processing result according to the target call information, thereby facilitating a user to determine whether the target App has a problem according to the processing result. Because the breakpoint is set and the target function is injected according to the operation instruction after the debugging connection is established, and the target App does not need to be modified and compiled, the embodiment can acquire the program running information of the target App under the condition that the target App does not need to be modified and compiled, so that the applicability of problem detection of the target App can be improved.
Referring to fig. 3, an embodiment of the present application further describes step 170, and in the case that the processing result includes the target call information and the screen display content of the terminal, step 170 may include, but is not limited to, the following steps:
step 171: intercepting screen display content of a terminal;
step 172: and sending the target calling information and the screen display content of the terminal to the client, so that the client displays the target calling information and the screen display content of the terminal.
In this embodiment, the screen display content of the terminal is the content displayed on the screen of the terminal when the target App calls the target API. After the terminal executes step 160 to obtain the target calling information, the terminal may further intercept the screen display content when the target App calls the target API, and then the terminal sends the target calling information and the screen display content to the client, so that the client can display the target calling information and the screen display content, thereby facilitating a user to determine whether the target App has a problem according to the target calling information and the screen display content. It should be noted that, after the client displays the target calling information and the screen display content, it may also determine whether the target App has a problem by analyzing the target calling information and the screen display content.
It should be noted that, because the screen display content is the content displayed on the screen of the terminal when the target API is called by the target App, the user can clearly know the state of the target App when the target API is called by sending the screen display content to the client and displaying the screen display content on the client; in addition, for research and development personnel, whether the target App has a problem can be determined by looking at the target calling information and the screen display content, so that the target App can be optimized and improved under the condition that the target App has the problem.
Referring to fig. 4, in an embodiment of the present application, step 170 is further described, where the processing result includes a download prompting message of the processing report, step 170 may further include, but is not limited to, the following steps:
step 173: intercepting screen display content of a terminal;
step 174: and sending the target calling information and the screen display content of the terminal to the client, so that the client generates a processing report according to the target calling information and the screen display content of the terminal, and displays the downloading prompt information of the processing report.
It should be noted that step 173 and step 174 in this embodiment are parallel to step 171 and step 172 in the embodiment shown in fig. 3.
In this embodiment, the screen display content of the terminal is the content displayed on the screen of the terminal when the target App calls the target API. After the terminal executes step 160 to obtain the target calling information, the terminal may further intercept the screen display content when the target App calls the target API, and then the terminal sends the target calling information and the screen display content to the client, so that the client can generate a processing report according to the target calling information and the screen display content, and display a download prompt message of the processing report. It should be noted that, after the client displays the download prompting information of the processing report, the user may determine whether the target App has a problem by downloading the processing report and analyzing the content in the processing report.
It should be noted that before the client displays the download prompt information of the processing report, the client may also display the processing report, so that the user can check the processing report in the client, and thus can determine whether the target App has a problem, and further can perform optimization and improvement on the target App when the target App has a problem.
The content of the processing report may be a report content obtained by integrating the target call information and the screen display content, or may be a problem summary result obtained by analyzing the problem of the target call information and the screen display content, which is not limited in this embodiment.
In addition, in an embodiment of the present application, the data processing method is further described, and before performing step 110, the data processing method may further include, but is not limited to, the following steps:
receiving a dynamic library file sent by a client;
and setting the starting mode of the target App to be a debugging mode.
It should be noted that, after the terminal and the debugging apparatus are connected, for example, after the terminal and the debugging apparatus are connected through a Universal Serial Bus (USB) connection mode or a bluetooth connection mode, the terminal may first receive a dynamic library file sent by the debugging apparatus through a client, and store the dynamic library file in a temporary directory of the terminal, and then, the terminal may respond to a debugging instruction sent by the debugging apparatus through an ADB tool, and set the starting mode of the target App to a debugging mode, so that the subsequent steps can be facilitated to perform operations of setting a breakpoint in the target App and injecting a target function in the target App.
It should be noted that the dynamic library file sent by the client is a dynamic library file that can be supported by the target App, and may be a 32-bit dynamic library file or a 64-bit dynamic library file, and the dynamic library file may be selected correspondingly according to the number of bits that can be supported by the target App.
Referring to FIG. 5, an embodiment of the present application, further describing step 150, in the case that the dynamic library file includes a candidate executable file and the candidate executable file includes an objective function, step 150 may include, but is not limited to, step 151 and step 152.
Step 151: and copying the dynamic library file to an installation directory of the target App according to the third operation instruction, so that the target App loads the dynamic library file.
In this step, since the temporary directory of the terminal stores the dynamic library file sent by the client, and the third operation instruction for instructing the target App to inject the target function is received in step 140, the terminal may copy the dynamic library file to the installation directory of the target App according to the third operation instruction, so that the target App can load the dynamic library file, thereby completing the process of injecting the target function in the target App.
For example, the dynamic library file can be copied to the installation directory of the target App through a java. In addition, after the terminal copies the dynamic library file to the installation directory of the target App, the operation of the main thread of the target App can be restored firstly, so that the target App can load the dynamic library file, and after the target App finishes the operation of loading the dynamic library file, the target App is restored to operate from the breakpoint.
Step 152: and in the process of loading the dynamic library file by the target App, calling a class loader to load the candidate executable file, and setting a target function in the target App.
In this step, since the dynamic library file is copied to the installation directory of the target App in step 151 so that the target App can load the dynamic library file, the target App may call a class loader to load a candidate executable file in the dynamic library file in the process of loading the dynamic library file by the target App, thereby setting a target function in the target App.
It should be noted that, when the target App loads the dynamic library file, the target App triggers a JNI _ onLoad function set in the dynamic library file by using a loading mechanism of the JNI. In the JNI _ onLoad function, a dalvik.system.dexdasloadloader.loadclass function is called through a JNI reflection technology, and the candidate executable file is loaded by using the dalvik.system.dexdasloadloader.loadclass function, so that the candidate executable file can be executed in the running process of the target App.
It should be noted that, since operations such as copying the dynamic library file and loading the candidate executable file by the calling class loader are executed according to the third operation instruction, and the target App does not need to be modified and compiled, the target App can load the dynamic library file to set a target function in the target App without modifying and compiling the target App, which is further beneficial for subsequent steps to obtain target calling information when the target App calls the target API through the target function.
In an optional embodiment, after the target App calls the class loader to load the candidate executable file, the candidate executable file can perform the following operations along with the running of the target App:
(1) Collecting basic information of a terminal and a target App;
(2) Setting a target function in a target App;
(3) Collecting existing authority information of the target App in operation;
(4) Applying screen recording permission to the terminal to intercept screen display content of the terminal when the target App calls the target API;
(5) And establishing a TCP connection between the target App and the client to transmit data.
In addition, for an embodiment of the present application, the step 152 is further described, and the step 152 may include, but is not limited to, the following steps:
in the process of loading the dynamic library file by the target App, recovering the operation of a main thread of the target App;
and calling the class loader through the main thread to load the candidate executable file, and setting a target function in the target App.
In this embodiment, in the process of loading the dynamic library file by the target App, the terminal may restore the operation of the main thread of the target App first, and after the operation of the main thread of the target App is restored, the candidate executable file may be loaded by calling the class loader through the main thread, thereby achieving the purpose of setting the target function in the target App.
It should be noted that, since the operation of calling the class loader to load the candidate executable file through the main thread is executed according to the third operation instruction, and the target App does not need to be modified and compiled, the target App can call the class loader to load the candidate executable file without modifying and compiling the target App, so that the processing of setting a target function in the target App can be completed, and further, the target calling information when the target App calls the target API can be conveniently obtained through the target function in the subsequent step.
Referring to fig. 6, fig. 6 is a flowchart of a data processing method according to another embodiment of the present application. In this embodiment, a debugging apparatus is described as an example of an execution subject. Referring to fig. 6, the data processing method includes, but is not limited to, steps 210 to 250.
Step 210: and sending a first operation instruction to the terminal, and triggering debugging connection between the client and a target App in the terminal.
In this step, when the program running information of the target App in the terminal needs to be acquired to determine whether the target App has a problem, the debugging device may first send a first operation instruction to the terminal through the client, and trigger the debugging connection between the client and the target App in the terminal, so that the target App may be subjected to related processing (for example, processing such as setting a breakpoint, injecting a target function, and the like) through other operation instructions in subsequent steps.
It should be noted that, after the user connects the debugging apparatus and the terminal in the USB connection manner or the bluetooth connection manner, the user may operate in the client of the debugging apparatus, and start the target App in the terminal through the ADB tool, so that the target App can be pulled up to run and is in a state of waiting for debugging connection. When the client detects that the target App is normally pulled up to run, the client sends a first operation instruction to the terminal to request to establish debugging connection with the target App. And after the client receives the ID number of the target process, the client maps the remote debugging port to the local and is connected to the remote debugging port according to the ID number of the target process, so that debugging connection with the target App is established.
Step 220: and sending a second operation instruction to the terminal, so that the terminal sets a breakpoint in the target App according to the second operation instruction, wherein the set position of the breakpoint is the position of the target App calling a function for initializing the movable assembly.
In this step, after the debugging connection between the client and the target App is established in the executing step 210, a second operation instruction may be sent to the terminal, so that the terminal can set a breakpoint in the target App according to the second operation instruction, so that the subsequent step can trigger the terminal to inject a target function for acquiring the target call information into the target App according to the breakpoint.
For example, the client may construct a first debug request data packet (i.e., a second operation instruction) according to a break point instruction provided by the JDWP protocol, and send the first debug request data packet to the terminal, so that the terminal can, after receiving the first debug request data packet, perform an operation of setting a BREAKPOINT in the target App according to the first debug request data packet through a debug framework of the target App.
It should be noted that the setting position of the breakpoint is a position where the target App calls a function for initializing the active component, for example, the target App may set the breakpoint at the android. It should be noted that the android.app.activity.oncreate function is automatically called when the target App starts to run, so that the target App sets a breakpoint at the android.app.activity.oncreate function, which is equivalent to setting a remote debugging entry at the position where the target App starts to run, thereby facilitating the injection processing of the target function for the target App in the subsequent steps.
It should be noted that if the time for injecting the target function is too late, the problem that the target call information of the target API called by the target App cannot be completely and accurately obtained may occur, and in order to avoid this problem, in this step, a breakpoint is set at a position where the target App starts to run, so that the target App can be injected with the target function in the subsequent step before the target App formally runs its main function, and thus the target call information of the target API called by the target App can be obtained through the target function in the whole running process of the target App.
Step 230: and when the target App runs to a breakpoint, sending a third operation instruction to the terminal, enabling the terminal to inject a target function into the target App according to the third operation instruction, and acquiring target calling information through the target function, wherein the target calling information is calling information of calling a target API by the target App.
In this step, since the second operation instruction is sent to the terminal in step 220 so that the terminal sets a breakpoint in the target App, when the target App runs to the breakpoint, a third operation instruction may be sent to the terminal, so that the terminal can inject a target function into the target App according to the third operation instruction, and obtain target call information through the target function.
For example, when the target App runs to the breakpoint, the breakpoint may be hit, so that the target App is suspended and is suspended from running, at this time, the client may reconstruct a second debug request data packet (i.e., a third operation instruction) according to an invoke message command provided by the JDWP protocol, and send the second debug request data packet to the terminal, so that the terminal can inject a target function into the target App according to the second debug request data packet after receiving the second debug request data packet, so as to obtain call information of the target API called by the target App through the target function.
It should be noted that the second debug request packet in this step and the first debug request packet in step 220 have the same packet structure, and the difference between the two is that the carried control instruction information is different, where the control instruction information carried by the first debug request packet in step 220 is break point instruction information, and the control instruction information carried by the second debug request packet in this step is invoke message instruction information. In an optional embodiment, the second debug request packet in this step and the first debug request packet in step 220 may be ordinary TCP packets, where the first debug request packet carries break key instruction information, and the second debug request packet carries invoke instruction information.
It should be noted that, after the terminal injects the target function into the target App, the target App restores the operation of the logic program of the target App, and when the target App calls the target API in the operation process, the target App acquires target call information when the target App calls the target API through the target function, so that the client can display a corresponding processing result according to the target call information in subsequent steps.
Since the operation of injecting the target function in the target App is performed according to the third operation instruction and the target App does not need to be modified and compiled, the target function can be injected in the target App without modifying and compiling the target App, and the target call information when the target App calls the target API can be acquired by the target function.
Step 240: and receiving the target calling information sent by the terminal.
In this step, since the third operation instruction is sent to the terminal in step 230, and the terminal injects the target function into the target App according to the third operation instruction and obtains the target call information through the target function, the target call information sent by the terminal can be received, so that the subsequent steps can display the corresponding processing result according to the target call information, and thus, the user can conveniently judge whether the target App has a problem according to the processing result.
It should be noted that the target call information includes, but is not limited to, stack, parameters, return values, etc. when the target API is called.
Step 250: and displaying a processing result corresponding to the target calling information.
In this step, since the target call information sent by the terminal is received in step 240, a corresponding processing result may be displayed according to the target call information, so that the user may perform relevant problem analysis according to the processing result, and thus may determine whether the target App has a problem.
It should be noted that the processing result may be the target call information, or may be a processing report generated by the client according to the target call information, and may be appropriately selected according to the actual application, which is not specifically limited in this embodiment.
In this embodiment, by using the data processing method including the foregoing steps 210 to 250, a first operation instruction is sent to the terminal to establish a debugging connection between the client and the target App, a second operation instruction is sent to the terminal so that the terminal sets a breakpoint in the target App, and then a third operation instruction is sent to the terminal when the target App runs to the breakpoint, so that the terminal can inject a target function into the target App according to the third operation instruction, obtain target call information of the target App for calling the target API through the target function, receive the target call information sent by the terminal, and display a corresponding processing result according to the target call information, so that a user can determine whether the target App has a problem according to the processing result. Because the operations of setting the breakpoint in the target App and injecting the target function into the target App are executed according to the operation instruction after the debugging connection is established, and the target App does not need to be modified and compiled, the embodiment can acquire the program running information of the target App without modifying and compiling the target App, so that the applicability of problem detection on the target App can be improved.
Referring to fig. 7, an embodiment of the present application further describes step 250, and in the case that the processing result includes the target call information and the screen display content of the terminal, step 250 may include, but is not limited to, the following steps:
step 251: receiving screen display content of a terminal sent by the terminal;
step 252: and displaying the target calling information and the screen display content of the terminal.
In this embodiment, the screen display content of the terminal is the content displayed on the screen of the terminal when the target App calls the target API. When the terminal sends the target calling information to the client, the terminal can send the screen display content when the target App calls the target API to the client, so that the client can receive the target calling information sent by the terminal and the screen display content when the target API calls the target API, and then display the target calling information and the screen display content, and a user can judge whether the target App has problems according to the target calling information and the screen display content. It should be noted that, after the client displays the target calling information and the screen display content, the target calling information and the screen display content may be analyzed, so as to determine whether the target App has a problem.
It should be noted that, because the screen display content is the content displayed on the screen of the terminal when the target API is called by the target App, the target calling information and the screen display content are displayed, so that the user can clearly know the state of the target App when the target API is called; in addition, for research and development personnel, whether the target App has a problem can be determined by looking at the target calling information and the screen display content, so that the target App can be optimized and improved under the condition that the target App has the problem.
Referring to fig. 8, for an embodiment of the present application, further describing the data processing method, after performing step 252, the data processing method may further include, but is not limited to, the following steps:
step 260: responding to the operation stopping instruction, and generating a processing report according to the target calling information and the screen display content of the terminal;
step 270: and displaying the processing report or displaying the download prompt information of the processing report.
After the debugging means displays the target call information and the screen display content of the terminal to the user in step 252, it indicates that the debugging means is already acquiring the program running information of the target App. When the debugging device detects a stop operation instruction triggered by a user through a client, the debugging device indicates that the user currently finishes processing the target App, therefore, the debugging device can respond to the stop operation instruction, stop obtaining program running information of the target App, generate a processing report according to the target calling information and the screen display content, and then display the processing report or display download prompting information of the processing report, so that the user can judge whether the target App has problems more intuitively according to the processing report displayed in the client, or the user can download the processing report according to the download prompting information, so that subsequent more detailed report analysis processing can be performed.
In this embodiment, the content of the processing report may be a report content obtained by integrating the target call information and the screen display content, or may be a problem summary result obtained by analyzing the problem of the target call information and the screen display content, which is not limited in this embodiment.
Referring to fig. 9, an embodiment of the present application further describes step 250, where the processing result includes a download prompting message of the processing report, step 250 may include, but is not limited to, the following steps:
step 253: receiving screen display content of a terminal sent by the terminal;
step 254: generating a processing report according to the target calling information and the screen display content of the terminal;
step 255: and displaying the download prompt information of the processing report.
It should be noted that steps 253 to 255 in this embodiment are parallel to steps 251 and 252 in the embodiment shown in fig. 7.
In this embodiment, after the client receives the target call information sent by the terminal and the screen display content when the target App calls the target API, the debugging device does not display the target call information and the screen display content through the client, but generates a corresponding processing report according to the target call information and the screen display content through the background module, and after the debugging device generates the processing report, the debugging device displays the download prompt information of the processing report to the user, so that the user can download the processing report according to the download prompt information of the processing report, so as to perform subsequent more detailed report analysis processing.
It should be noted that before the client displays the download prompt information of the processing report, the client may also display the processing report, so that the user can check the processing report in the client, and thus can determine whether the target App has a problem, and further can perform optimization and improvement on the target App when the target App has a problem.
It should be noted that, in the process of generating the processing report by the background module according to the target call information and the screen display content, a certain time needs to be consumed, and in order to inform the user that the processing report needs to be obtained after waiting for a certain time, the debugging apparatus may display related prompt information to the user through the client, so that the user may wait for the generation of the processing report, for example, prompt information such as "during processing, please wait for patience", or "during analysis, please wait for patience" may be displayed through the client.
In this embodiment, the content of the processing report may be a report content obtained by integrating the target call information and the screen display content, or may be a problem summary result obtained by analyzing the problem of the target call information and the screen display content, which is not limited in this embodiment.
In addition, in an embodiment of the present application, the data processing method is further described, before performing step 210, the data processing method may further include, but is not limited to, the following steps:
sending the dynamic library file to a terminal;
and sending a debugging instruction to the terminal, so that the terminal sets the starting mode of the target App to be a debugging mode according to the debugging instruction.
It should be noted that, after the debugging device is connected to the terminal, for example, after the debugging device is connected to the terminal in a USB connection manner or a bluetooth connection manner, the debugging device may first send a dynamic library file to the terminal through the client, so that the terminal stores the dynamic library file in a temporary directory of the terminal, and then the debugging device may send a debugging instruction to the terminal through the ADB tool, so that the terminal sets the starting manner of the target App to the debugging mode, thereby facilitating the terminal to perform operations of setting a breakpoint in the target App and injecting a target function in the target App in subsequent steps.
It should be noted that the dynamic library file sent by the debugging device to the terminal through the client is a dynamic library file that can be supported by the target App, and may be a 32-bit dynamic library file, or a 64-bit dynamic library file, and the corresponding selection may be performed according to the number of bits that can be supported by the target App.
In order to more clearly describe the processing flow of the data processing method provided in the embodiment of the present application, a specific example is described below.
The first example is as follows:
as shown in fig. 10, fig. 10 is a flowchart of a data processing method according to a specific example of the present application. In fig. 10, the data processing method includes steps 301 to 312.
Step 301: and opening a client in the debugging device, and connecting the debugging device with the terminal in a USB connection mode or a Bluetooth connection mode.
When the client is opened, the client presents a user interface as shown in fig. 11, where the user interface includes a terminalinformation display area 401, anitem selection area 402, a to-be-processedApp selection area 403, a terminalscreen mirror area 404, anoperation button 405, ascreenshot display area 406, and a target API callrecord display area 407. After the debugging device and the terminal are connected, relevant information of the terminal, such as information of a terminal name, a system version, whether the terminal is a root device, and the like, is displayed in the terminal information display area 401; items to be processed can be selected in the item selection area 402, for example, program running information of App can be selected and acquired; a target App to be processed can be selected in the App to be processed selection area 403; a screen image of the terminal is displayed in the terminal screen image area 404; the operation button 405 is used to start or stop performing operations, for example, when the client is in a standby state, the operation button 405 may be displayed as "start operation", when the user clicks the operation button 405, the client may acquire program running information of the App, and the operation button 405 may be displayed as "stop operation", and when the user clicks the operation button 405 again, the client may stop acquiring the program running information of the App; the screen display content of the terminal when the target App calls the target API is displayed in the screen capture display area 406; target call information when the target App calls the target API is displayed in the target API call record display area 407.
Step 302: and selecting a target App to be processed, and clicking an operation button.
It should be noted that in this step, after theoperation button 405 in fig. 11 is clicked, the client may pop up an operation notification interface shown in fig. 12, for example, and when the user finishes reading the content in the operation notification interface and clicks thestart button 408 in the operation notification interface, the client initiates the process of acquiring the program running information of the target App.
Step 303: and the client initiates acquisition processing of program running information of the target App through the ADB tool.
In this step, since the user clicks thestart button 408 in the operation awareness interface of fig. 12, the client initiates acquisition processing of the program running information of the target App through the ADB tool, and pops up a connection progress bar shown in fig. 13, for example, to prompt the user to wait for a debugging connection between the client and the target App.
Step 304: the client copies the required 32-bit dynamic library file to a temporary directory of the terminal through an ADB tool, marks a target App through the ADB tool, sets the starting mode of the target App to be a debugging mode, and then starts the target App through the ADB tool.
In this step, after the client starts the target App through the ADB tool, the target App appears as an interface waiting for debugging connection in the terminal as shown in fig. 14.
Step 305: and after the client confirms that the target App is normally started, the ID number of the target process in the target App is acquired, and debugging connection is carried out on the target App according to the ID number of the target process.
Step 306: the client constructs a first debugging request data packet according to a BREAKPOINT instruction provided by a JDWP protocol, and sends the first debugging request data packet to the terminal, so that the terminal sets a BREAKPOINT at an android.
Step 307: when the target App runs to a breakpoint and is suspended, the client constructs a second debugging request data packet according to an InvokeMethod instruction provided by a JDWP protocol, and sends the second debugging request data packet to the terminal, so that the target App loads a dynamic library file stored in a temporary directory, and a target function is injected into the target App.
In this step, the target App may run a java.
It should be noted that, in the process of loading the dynamic library file by the target App, the target App triggers the JNI _ onLoad function set in the dynamic library file through a loading mechanism of the JNI, so that in the process of calling the JNI _ onLoad function, the dalvik.
Step 308: when the step 307 is not executed normally, the 32-bit dynamic library file in the step 304 is replaced with a 64-bit dynamic library file, and the steps 304 to 307 are repeated according to the 64-bit dynamic library file.
Step 309: in the running process of the target App, when the target API is called by the target App, the terminal acquires target calling information such as stack, parameters and return values when the target API is called through a target function, intercepts screen display content of the terminal when the target API is called, and then sends the target calling information and the screen display content to the client for display.
In this step, after the client receives the target call information such as the stack, the parameter, and the return value when the target API is called, which is sent by the terminal, the client hides the connection progress bar shown in fig. 13 and displays the target call information and the screen display content of the terminal when the target API call occurs. For example, as shown in fig. 15, thescreenshot display area 406 may display the screen display content of the terminal when the target App calls the target API, and the target API callrecord display area 407 may display the target call information when the target App calls the target API.
Step 310: and after the user finishes the test and clicks the operation button, the client stops acquiring the program running information of the target App.
In this step, after the user finishes the test and clicks theoperation button 405 in fig. 15, the client pops up the operation stop prompt information interface shown in fig. 16, and when the user clicks theconfirmation button 409 in the operation stop prompt information interface, the client stops obtaining the program running information of the target App.
Step 311: and the client sends the target calling information and the screen display content to the background module, so that the background module generates a processing report according to the target calling information and the screen display content.
In this step, when the client sends the target call information and the screen display content to the background module, an upload progress box shown in fig. 17 pops up to prompt the user to wait for uploading of the information. After the information is uploaded, the client pops up a processing report prompting interface shown in fig. 18, so that the user can be guided to open a processing report for viewing.
Step 312: and responding to the triggering operation of the user, and displaying a processing report by the client.
In this step, when the user clicks theview report button 410 in the processing report prompting interface shown in fig. 18, the client displays the processing report shown in fig. 19, so that the user can perform related analysis processing according to the processing report, and thus can determine whether the target App has a problem.
Example two:
as shown in fig. 20, fig. 20 is a flowchart of a data processing method according to another specific example of the present application. Fig. 20 is a flowchart illustrating a data processing method for a game class App, and in fig. 20, the data processing method includes steps 801 to 812.
Step 801: and opening a client in the debugging device, and connecting the debugging device with the terminal in a USB connection mode or a Bluetooth connection mode.
After the client is opened, the client may present a user interface as shown in fig. 11, at this time, the user may perform corresponding operations in the user interface, for example, may select a processing item for acquiring program running information of an App in anitem selection area 402 of the user interface, select a target game App in a to-be-processedApp selection area 403 of the user interface, click anoperation button 405 in the user interface to trigger the client to acquire the program running information of the target game App, and the like.
Step 802: select the target game App, and then click the operation button.
It should be noted that, in this step, after theoperation button 405 in fig. 11 is clicked, the client may pop up the operation notification interface shown in fig. 12, for example, and when the user finishes reading the content in the operation notification interface and clicks thestart button 408 in the operation notification interface, the client initiates the process of acquiring the program running information of the target game App.
Step 803: and the client initiates acquisition processing of program running information of the target game App through the ADB tool.
In this step, since the user clicks thestart button 408 in the operation awareness interface in fig. 12, the client initiates acquisition processing of the program running information of the target game App through the ADB tool, and pops up a connection progress bar shown in fig. 13, for example, to prompt the user to wait for a debugging connection between the client and the target game App.
Step 804: the client copies the required 32-bit dynamic library file to a temporary directory of the terminal through an ADB tool, marks a target game App through the ADB tool, sets the starting mode of the target game App to a debugging mode, and then starts the target game App through the ADB tool.
In this step, after the client starts the target game App through the ADB tool, the target game App appears as an interface waiting for debugging connection in the terminal as shown in fig. 14.
Step 805: and after the client confirms that the target game App is normally started, acquiring the ID number of the target process in the target game App, and debugging and connecting the target game App according to the ID number of the target process.
Step 806: the client constructs a first debugging request data packet according to a BREAKPOINT instruction provided by a JDWP protocol, and sends the first debugging request data packet to the terminal, so that the terminal sets a BREAKPOINT at an android.
Step 807: when the target game App runs to a breakpoint and is suspended, the client constructs a second debugging request data packet according to an InvokeMethod instruction provided by the JDWP protocol, and sends the second debugging request data packet to the terminal, so that the target game App loads a dynamic library file stored in a temporary directory, and a target function is injected into the target game App.
In this step, the target game App may run a java.
Step 808: when the step 807 is not normally executed, the 32-bit dynamic library file in the step 804 is replaced by a 64-bit dynamic library file, and the steps 804 to 807 are repeatedly executed according to the 64-bit dynamic library file.
Step 809: in the running process of the target game App, when the target game App is detected to call the target API, the terminal acquires target calling information such as stack, parameters and return values when the target API is called through a target function, the terminal intercepts screen display content of the terminal when the target API is called, and then the terminal sends the target calling information and the screen display content to the client for display.
In this step, after the client receives the target call information such as the stack, the parameter, and the return value when the target API is called, which is sent by the terminal, the client hides the connection progress bar shown in fig. 13, and displays the target call information and the screen display content of the terminal when the target API call occurs. For example, as shown in fig. 21, thescreenshot display area 406 displays the screen display content (for example, a game login interface, a game interface, and the like) of the terminal when the target game App calls the target API, and the target API callrecord display area 407 displays the target call information when the target game App calls the target API.
Step 810: and after the user finishes the test and clicks the operation button, the client stops acquiring the program running information of the target game App.
In this step, after the user has clicked theoperation button 405 in fig. 21 after the test is completed, the client pops up the operation stop prompt information interface shown in fig. 16, and when the user has clicked theconfirmation button 409 in the operation stop prompt information interface, the client stops obtaining the program running information of the target game App.
Step 811: and the client sends the target calling information and the screen display content to the background module, so that the background module generates a processing report according to the target calling information and the screen display content.
In this step, when the client sends the target call information and the screen display content to the background module, an upload progress box shown in fig. 17 pops up to prompt the user to wait for the upload of the information. After the information is uploaded, the client pops up a processing report prompting interface shown in fig. 18, so that the user can be guided to open a processing report for viewing.
Step 812: and responding to the triggering operation of the user, and displaying a processing report by the client.
In this step, when the user clicks theview report button 410 in the processing report prompt interface shown in fig. 18, the client displays the processing report shown in fig. 22, so that the user can perform related analysis processing according to the processing report, and can determine whether the target game App has a problem.
Referring to fig. 23, an embodiment of the present application further discloses a data processing apparatus, where thedata processing apparatus 500 can serve as the terminal 102 in the embodiment shown in fig. 1 to implement the data processing method according to the foregoing embodiment, and thedata processing apparatus 500 includes:
thefirst connection unit 501 is configured to trigger a debugging connection between the target App and the client in response to a first operation instruction;
afirst receiving unit 502, configured to receive a second operation instruction sent by the client;
abreakpoint setting unit 503, configured to set a breakpoint in the target App according to the second operation instruction, where a set position of the breakpoint is a position where the target App calls a function that initializes the active component;
asecond receiving unit 504, configured to receive a third operation instruction sent by the client when the target App runs to the breakpoint;
afunction setting unit 505, configured to inject a target function in the target App according to the third operation instruction;
aninformation obtaining unit 506, configured to obtain target call information through a target function, where the target call information is call information of a target API called by a target App;
aninformation sending unit 507, configured to send the target invocation information to the client, so that the client displays a processing result corresponding to the target invocation information.
In one embodiment, in a case where the processing result includes the target call information and the screen display content of the terminal, and the screen display content of the terminal is the content of the screen display of the terminal when the target App calls the target API, theinformation transmitting unit 507 includes:
the first content intercepting unit is used for intercepting the screen display content of the terminal;
and the first information sending subunit is used for sending the target calling information and the screen display content of the terminal to the client so that the client displays the target calling information and the screen display content of the terminal.
In an embodiment, in the case that the processing result includes the download prompting information of the processing report, theinformation sending unit 507 includes:
the second content intercepting unit is used for intercepting the screen display content of the terminal, wherein the screen display content of the terminal is the content displayed on the screen of the terminal when the target App calls the target API;
and the second information sending subunit is used for sending the target calling information and the screen display content of the terminal to the client, so that the client generates a processing report according to the target calling information and the screen display content of the terminal, and displays the download prompt information of the processing report.
In one embodiment, thedata processing apparatus 500 further comprises:
the third receiving unit is used for receiving the dynamic library file sent by the client;
and the mode setting unit is used for setting the starting mode of the target App to be a debugging mode.
In an embodiment, in a case where the dynamic library file includes a candidate executable file and the candidate executable file includes an objective function, thefunction setting unit 505 includes:
the copying unit is used for copying the dynamic library file to an installation directory of the target App according to the third operation instruction, so that the target App loads the dynamic library file;
and the calling unit is used for calling the class loader to load the candidate executable file and setting a target function in the target App in the process of loading the dynamic library file by the target App.
In one embodiment, the call unit comprises:
the recovery operation unit is used for recovering the operation of the main thread of the target App in the process of loading the dynamic library file by the target App;
and the calling subunit is used for calling the class loader through the main thread to load the candidate executable file and setting a target function in the target App.
It should be noted that, since thedata processing apparatus 500 of the present embodiment can implement the data processing method using the terminal as the execution subject as in the foregoing embodiment, thedata processing apparatus 500 of the present embodiment has the same technical principles and the same beneficial effects as the data processing method using the terminal as the execution subject in the foregoing embodiment, and therefore, in order to avoid the repetition, the details are not repeated here.
Referring to fig. 24, an embodiment of the present application further discloses a data processing apparatus, where thedata processing apparatus 600 can be used as thedebugging apparatus 101 in the embodiment shown in fig. 1 to implement the data processing method according to the foregoing embodiment, where thedata processing apparatus 600 includes:
thesecond connection unit 601 is configured to send a first operation instruction to the terminal, and trigger a debugging connection between the client and a target App in the terminal;
afirst sending unit 602, configured to send a second operation instruction to the terminal, so that the terminal sets a breakpoint in the target App according to the second operation instruction, where a setting position of the breakpoint is a position where the target App calls a function for initializing the active component;
asecond sending unit 603, configured to send a third operation instruction to the terminal when the target App runs to the breakpoint, so that the terminal injects a target function into the target App according to the third operation instruction, and obtains target call information through the target function, where the target call information is call information of the target App calling the target API;
aninformation receiving unit 604, configured to receive target call information sent by a terminal;
aninformation display unit 605 configured to display a processing result corresponding to the target call information.
In one embodiment, in a case where the processing result includes the target call information and the screen display content of the terminal, and the screen display content of the terminal is the content of the screen display of the terminal when the target App calls the target API, theinformation display unit 605 includes:
the fourth receiving unit is used for receiving the screen display content of the terminal sent by the terminal;
and the first information display subunit is used for displaying the target calling information and the screen display content of the terminal.
In one embodiment, thedata processing apparatus 600 further comprises:
a first report generating unit, which is used for responding to the operation stopping instruction and generating a processing report according to the target calling information and the screen display content of the terminal;
and the second information display subunit is used for displaying the processing report or displaying the download prompt information of the processing report.
In an embodiment, in the case where the processing result includes the download prompting information of the processing report, theinformation display unit 605 includes:
the fifth receiving unit is used for receiving the screen display content of the terminal sent by the terminal, wherein the screen display content of the terminal is the content displayed on the screen of the terminal when the target App calls the target API;
the second report generating unit is used for generating a processing report according to the target calling information and the screen display content of the terminal;
and the third information display subunit is used for displaying the download prompt information of the processing report.
In one embodiment, thedata processing apparatus 600 further comprises:
a third sending unit, configured to send the dynamic library file to the terminal;
and the fourth sending unit is used for sending the debugging instruction to the terminal, so that the terminal sets the starting mode of the target App into a debugging mode according to the debugging instruction.
It should be noted that, since thedata processing apparatus 600 of the present embodiment can implement the data processing method using the debugging apparatus as the execution subject as in the foregoing embodiment, thedata processing apparatus 600 of the present embodiment has the same technical principle and the same beneficial effects as the data processing method using the debugging apparatus as the execution subject in the foregoing embodiment, and therefore, in order to avoid repetition, the details are not repeated here.
The above-described embodiments of the apparatus are merely illustrative, wherein the units illustrated as separate components may or may not be physically separate, i.e. may be located in one place, or may also be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
Referring to fig. 25, an embodiment of the present application further discloses a data processing apparatus, where thedata processing apparatus 700 includes:
at least oneprocessor 701;
at least onememory 702 for storing at least one program;
when at least one of the programs is executed by at least one of theprocessors 701, a data processing method according to any of the preceding embodiments is implemented.
The embodiment of the present application further discloses a computer-readable storage medium, in which a program executable by a processor is stored, and when the program executable by the processor is executed by the processor, the program is used for implementing the data processing method according to any of the foregoing embodiments.
Embodiments of the present application also disclose a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the data processing method of any of the preceding embodiments.
The terms "first," "second," "third," "fourth," and the like in the description of the application and the above-described figures, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
It should be understood that in the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" for describing an association relationship of associated objects, indicating that there may be three relationships, e.g., "a and/or B" may indicate: only A, only B and both A and B are present, wherein A and B may be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" or similar expressions refer to any combination of these items, including any combination of single item(s) or plural items. For example, at least one (one) of a, b, or c, may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
For the step numbers in the above method embodiments, they are set for convenience of illustration only, the order between the steps is not limited at all, and the execution order of each step in the embodiments can be adapted according to the understanding of those skilled in the art.