Detection method and electronic device

Abstract

Embodiments of the present application are applicable to the technical field of computer technology, and provide a detection method and electronic equipment, which can determine the calling paths of multiple Binders only by checking program code, thereby reducing the detection cost of detecting frequently called Binders. The method comprises the following steps: determining Binder calling handles in the program code, identifying Binder calling source points based on the Binder calling handles, and finally obtaining a target Binder calling path set based on the Binder calling source points, wherein the Binder calling source points are nodes triggering Binder calling, and the target Binder calling path set comprises at least one target Binder calling path, and the target Binder calling path comprises multiple functions calling the Binder calling source points.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and more particularly, to a detection method and an electronic device. BACKGROUND

[0002] With the increasing richness of functions of electronic devices, in some possible cases, data interaction is needed between different application programs running in the electronic devices. It should be noted that the data interaction between different application programs can be referred to as data interaction between different processes. Generally, the data interaction between different application programs needs to be realized through an Inter-Process Communication (IPC) mechanism. Binder is an efficient IPC mechanism in an Android system, and through Binder, the interaction and communication between processes can be realized. Binder calling involves the switching of contexts in the code and system calls, and these operations take a long time. If Binder calling is too frequent, it will cause a large consumption of system resources, affecting the response speed and overall performance of the electronic device.

[0003] At the present stage, the electronic device can perform real-time monitoring when the electronic device is running to determine whether there is frequent Binder calling, or obtain system logs of the electronic device and read Binder calling records from the system logs to determine whether there is frequent Binder calling. However, through these two methods to determine whether there is frequent Binder calling, the program code of each application program in the electronic device needs to be run, and the detection cost is high.

[0004] Therefore, how to reduce the detection cost of detecting whether Binder is called frequently has become a problem to be solved. SUMMARY

[0005] The present application provides a detection method, which can reduce the detection cost of detecting frequent Binder calling.

[0006] In a first aspect, a detection method is provided, which includes:

[0007] determining a Binder calling handle in the program code, the Binder calling handle including an identifier for cross-process communication;

[0008] identifying a Binder calling source point based on the Binder calling handle, the Binder calling source point being a node triggering Binder calling;

[0009] The target Binder call path set includes at least one target Binder call path, and the target Binder call path includes a plurality of functions that call the Binder call source point.

[0010] The Binder can refer to an inter-process communication mechanism in an Android system. The Binder call allows one process to request the service of another process, and realizes the interaction and communication between processes. The Binder call handle can refer to an identifier for cross-process reference and call of a remote object (such as a service or a method). The Binder call source point usually refers to a starting point of triggering the Binder call, that is, which component or process initiates the call to the Binder service.

[0011] The detection method provided in the embodiments of the present application determines the Binder call handle in the program code, identifies the Binder call source point based on the Binder call handle, and then the Binder call handle includes an identifier for cross-process communication, finally obtains a target Binder call path set based on the Binder call source point, wherein the Binder call source point is a node triggering the Binder call, and the target Binder call path set includes at least one target Binder call path, and the target Binder call path includes a plurality of functions that call the Binder call source point. In this way, the multiple Binder call paths can be determined only by checking the program code, and the detection cost of detecting the frequent Binder call is reduced.

[0012] In combination with the first aspect, in some embodiments of the first aspect, the above identifying the Binder call source point based on the Binder call handle includes: determining a target handle based on the Binder call handle, the target handle being an identifier associated with the Binder call handle; and identifying the Binder call source point based on the Binder call handle and the target handle.

[0013] The detection method provided in the embodiments of the present application identifies the Binder call source point based on the Binder call handle, and also identifies the Binder call source point in combination with the target handle of the Binder call handle, so that the identified Binder call source point is more comprehensive, and the comprehensiveness of obtaining the target Binder call path set based on the Binder call source point is improved.

[0014] With reference to the first aspect, in some embodiments of the first aspect, the association between the Binder call handle and the target handle includes assignment, variable declaration, container operation, loop structure, function return value transmission, and function parameter transmission.

[0015] With reference to the first aspect, in some embodiments of the first aspect, the identification of the Binder call source point based on the Binder call handle and the target handle includes: determining whether the Binder call handle and the target handle are service interfaces; if the Binder call handle and the target handle are service interfaces, adding the Binder call handle and the target handle to a service interface set; if the Binder call handle and the target handle are service interfaces, converting the Binder call handle and the target handle into service interfaces and then adding the Binder call handle and the target handle to the service interface set; and obtaining the Binder call source point based on the service interfaces in the service interface set.

[0016] With reference to the first aspect, in some embodiments of the first aspect, the determination of whether the Binder call handle and the target handle are service interfaces includes: converting the Binder call handle and the target handle into intermediate representations (IR); and determining whether the Binder call handle and the target handle are service interfaces based on the intermediate representations (IR) of the Binder call handle and the target handle.

[0017] With reference to the first aspect, in some embodiments of the first aspect, the Binder call handle includes a direct call handle and an indirect call handle.

[0018] With reference to the first aspect, in some embodiments of the first aspect, the obtaining of the target Binder call path set based on the Binder call source point includes: generating an initial Binder call path set based on the Binder call source point; and verifying the Binder call paths in the initial Binder call path set to obtain the target Binder call path set.

[0019] The detection method provided in the embodiments of the present application, in the process of obtaining the target Binder call path set based on the Binder call source point, first generates an initial Binder call path set based on the Binder call source point; verifies the Binder call path in the initial Binder call path set to obtain the target Binder call path set, that is, the target Binder call path set is obtained by verifying the Binder call path in the initial Binder call path set, and the target Binder call path set removes the incorrect Binder call path and the repeated Binder call path from the initial Binder call path set, thereby avoiding the use of incorrect Binder call path in the subsequent verification of Binder call based on the target Binder call path set, and improving the efficiency of verifying Binder call.

[0020] In combination with the first aspect, in some embodiments of the first aspect, the method further includes: generating a detection report of Binder call based on the target Binder call path set, and the detection report of Binder call includes the Binder call path in the target Binder call path set.

[0021] The detection method provided in the embodiments of the present application, after the target Binder call path set is generated, a detection report of Binder call that can be viewed by a user is further generated, so that the user optimizes the program code based on the detection report of Binder call.

[0022] Secondly, a detection device is provided, which includes units for executing any method in the first aspect. The device can be a server, a terminal device, or a chip in a terminal device. The device can include an input unit and a processing unit.

[0023] When the device is a terminal device, the processing unit can be a processor, and the input unit can be a communication interface. The terminal device can further include a memory for storing computer program code, and when the processor executes the computer program code stored in the memory, the terminal device executes any method in the first aspect.

[0024] When the device is a chip in a terminal device, the processing unit can be a processing unit inside the chip, and the input unit can be an output interface, a pin, a circuit, or the like; the chip can further include a memory, which can be a memory (for example, a register, a cache, or the like) inside the chip or a memory (for example, a read-only memory, a random access memory, or the like) outside the chip; the memory is configured to store computer program code, and when the processor executes the computer program code stored in the memory, the chip is caused to execute any one of the methods in the first aspect.

[0025] In a possible implementation, the memory is configured to store computer program code; and the processor is configured to execute the computer program code stored in the memory, and when the computer program code stored in the memory is executed, the processor is configured to perform the following: determining a Binder call handle in the program code, the Binder call handle including an identifier used for cross-process communication; identifying a Binder call source point based on the Binder call handle, the Binder call source point being a node triggering a Binder call; and obtaining a target Binder call path set based on the Binder call source point, the target Binder call path set including at least one target Binder call path, and the target Binder call path including a plurality of functions calling the Binder call source point.

[0026] In a third aspect, a computer readable storage medium is provided, and the computer readable storage medium stores computer program code, and when the computer program code is run on a detection device, the detection device is caused to execute any one of the detection methods in the first aspect.

[0027] In a fourth aspect, a computer program product is provided, and the computer program product includes computer program code, and when the computer program code is run on a detection device, the detection device is caused to execute any one of the device methods in the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 FIG. 1 is a schematic diagram of a hardware system of an electronic device suitable for the present application;

[0029] Figure 2 FIG. 1 is a schematic diagram of a hardware system of an electronic device suitable for the present application;

[0030] Figure 3 FIG. 1 is a schematic diagram of a hardware system of an electronic device suitable for the present application;

[0031] Figure 4 FIG. 1 is a schematic diagram of a hardware system of an electronic device suitable for the present application;

[0032] Figure 5 is a schematic diagram of a direct call handle and an indirect call handle provided by an embodiment of the present application;

[0033] Figure 6 is a schematic diagram of determining a Binder call source point provided by an embodiment of the present application;

[0034] Figure 7 is a schematic diagram of a Binder call path provided by an embodiment of the present application;

[0035] Figure 8 is a schematic diagram of a detection report provided by an embodiment of the present application;

[0036] Figure 9 is a schematic diagram of a detection device provided by the present application;

[0037] Figure 10 is a schematic diagram of an electronic device for detection provided by the present application. DETAILED DESCRIPTION

[0038] The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, “ / ” represents or, for example, A / B can represent A or B; in this document, “and / or” only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which means that there are three cases of A alone, A and B together, and B alone. In addition, in the description of the embodiments of the present application, “multiple” means two or more than two.

[0039] Hereinafter, the terms “first”, “second”, “third” are only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with “first”, “second”, “third” can explicitly or implicitly include one or more of the features.

[0040] For ease of understanding, some examples are given for reference in relation to the description of the concepts related to the embodiments of the present application.

[0041] 1. Inter-Process Communication (IPC) or cross-process communication.

[0042] IPC refers to the process of exchanging data between two or more processes. In a computer operating system, a process is the basic unit of resource allocation and scheduling, and each process has its own independent memory space and system resources. It can be understood that an application can be considered a process, and data exchange between processes can refer to data interaction between applications. However, in some situations, processes need to exchange data or cooperate, which can be achieved through the IPC mechanism.

[0043] 2. Binder.

[0044] Binder refers to an inter-process communication (IPC) mechanism in the Android system. Binder calls allow one process to request services from another process, enabling inter-process interaction and communication. This mechanism provides an efficient, secure, and reliable communication method, allowing seamless data exchange and calls between different components and applications. In the Android system, the Binder mechanism is widely used for communication between various system services (such as sensor services, location services, and network services), as well as for interaction between applications and system services.

[0045] 3. Binder calls the handle.

[0046] In computer science, a handle typically refers to a pointer or index used to identify or reference a resource or object. In the Binder mechanism, a Binder call handle can be an identifier used to reference and invoke remote objects (such as services or methods) across processes. This handle establishes an indirect reference relationship between the client (caller) and the server (callee), allowing the client to invoke server methods or access their data through this handle.

[0047] 4. Binder calls the source point.

[0048] The Binder call source point typically refers to the starting point that triggers a Binder call, i.e., which component or process initiated the call to the Binder service. In the Android system, the Binder call source point can be diverse; for example, it could be:

[0049] Activity or other User Interface (UI) components: When a user interacts with the application's UI, such as clicking a button or typing text, these actions may trigger calls to remote services. In this case, the Activity or other UI component may become the source of the Binder call. In the Android system, an "Activity" can be used to represent a single screen in the user interface.

[0050] Service: In Android, a Service is an application component that can perform long-running operations in the background without providing a user interface. A Service may communicate with other Services or clients through the Binder mechanism, and therefore it may also be the source of Binder calls.

[0051] Content Provider: A content provider is a way to share data in Android. When other applications or components want to access data provided by a content provider, they may initiate a call through the Binder mechanism. Therefore, a content provider can also be the source of a Binder call.

[0052] Broadcast Receiver: A broadcast receiver is used to receive broadcast messages sent by the system or other applications. In some cases, receiving a broadcast message may trigger a call to a remote service, in which case the broadcast receiver may also become the source of the Binder call.

[0053] For example, a piece of program code that might trigger frequent Binder calls is shown in Example Code 1, which includes:

[0054]

[0055]

[0056] When the program executes "getConnectionInfo()", it triggers a Binder call, so "getConnectionInfo()" can be the source point of the Binder call; the computer program can trigger the execution of "getConnectionInfo()" when running "getWifiManager().", so "getWifiManager()." can be a Binder call handle.

[0057] In the above code, the function ExampleNextClass.badCheckWifiActivated(), within the While loop, indirectly and frequently initiates Binder calls to WifiManager.getConnectionInfo() when it calls the function ExampleClientClass.isWifiActivated() in another module.

[0058] The function `ExampleClientClass.isWifiActivated()` first calls `ExampleClientClass.getWifiManager()` to obtain the interface of the system service `WifiManager`. Then, using the function call chain, it directly accesses the remote service `WifiManager.getConnectionInfo()` based on the returned `WifiManager` interface to obtain the current Wi-Fi connection information. Because `ExampleClientClass.isWifiActivated()` is placed in a `While` loop within the `ExampleNextClass.badCheckWifiActivated()` function, the Binder call to access the remote service `WifiManager.getConnectionInfo()` is also repeatedly executed, causing performance issues. The aforementioned function call chain can be interpreted as `ExampleNextClass::badCheckWifiActivated->ExampleClientClass::isWifiActivated->`.

[0059] WifiManager::getConnectionInfo.

[0060] To avoid frequent Binder calls, the line "return getWifiManager().getConnectionInfo()getSupplicantState()==…" in the code above can be modified to "return connectivState.getSupplicantState". This uses a global variable to cache the Binder call result, thus preventing the call to "getConnectionInfo()" through "getWifiManager()." when the Binder call handle is called back, thereby avoiding frequent Binder calls.

[0061] The generated function call chain can be as shown in Example Code 2, which includes:

[0062]

[0063] Among them, "frequent call point" refers to the point that is frequently called directly in the loop, and "sourcebinder call" refers to the source point of the Binder call.

[0064] It should be noted that in actual use, the program code involved in Binder calls is more complex, and the function call chains are also more intricate and lengthy. Generating all Binder call paths comprehensively and accurately from a large amount of program code, and then identifying frequently called Binder call paths within those paths, is even more complex. The Binder call path described above is merely an example.

[0065] To identify frequently invoked Binder call paths from a large amount of program code, electronic devices can use the following three methods.

[0066] Method 1: Real-time monitoring test.

[0067] Electronic devices can monitor the frequency and duration of Binder calls in real time during actual use to determine if frequently invoked Binder call paths exist. However, determining the existence of frequently invoked Binder call paths through real-time monitoring requires the electronic device to run a large amount of program code, impacting its performance. Furthermore, due to the complexity of the program code's invocation process, in some cases, although potentially frequently invoked Binder call paths may exist, these paths may not be executed, making it impossible for the electronic device to detect them.

[0068] Method 2: Log analysis.

[0069] Electronic devices can also identify frequently invoked Binder call paths by analyzing Binder calls in system logs. However, identifying frequently invoked Binder call paths through log analysis relies on detailed and accurate log records, and the analysis process is relatively cumbersome.

[0070] Method 3: Static code analysis.

[0071] Some testing tools support static code analysis, which identifies frequently invoked Binder call paths from large amounts of code. However, these tools typically only perform searches based on simple keywords, making them less effective at detecting complex scenarios like Binder calls.

[0072] In view of this, embodiments of this application provide a detection method that can identify the Binder call handle in the program code, identify the Binder call source point based on the Binder call handle, and then identify the Binder call source point, which includes an identifier for cross-process communication. Finally, a set of target Binder call paths is obtained based on the Binder call source point. The Binder call source point is the node that triggers the Binder call, and the set of target Binder call paths includes at least one target Binder call path. The target Binder call path includes multiple functions that call the Binder call source point. In this way, multiple Binder call paths can be determined by checking the program code alone, reducing the detection cost of frequent Binder calls.

[0073] The detection method provided in this application can be applied to electronic devices. Optionally, the electronic device includes a terminal device, which can also be called a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. The terminal device can be a mobile phone, smart TV, wearable device, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. The embodiments of this application do not limit the specific technology or device form used in the terminal device.

[0074] For example, Figure 1A schematic diagram of the structure of electronic device 100 is shown. Electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0075] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0076] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0077] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0078] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0079] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0080] It should be noted that any electronic device mentioned in the embodiments of this application may include more or fewer modules in electronic device 100.

[0081] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.

[0082] Figure 2 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0083] The layered architecture of the electronic device 100 divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0084] The application layer can include a series of application packages.

[0085] like Figure 2 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0086] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0087] like Figure 2 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0088] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0089] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0090] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0091] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0092] The kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, sensor drivers, Wi-Fi drivers, etc.

[0093] It should be noted that the electronic device mentioned in the embodiments of this application may include more or fewer modules of the above-mentioned electronic device.

[0094] The application scenarios provided by the embodiments of this application are described below with reference to the accompanying drawings.

[0095] As electronic devices become increasingly feature-rich, in some cases, different applications running on these devices need to exchange data, which can be achieved through Binder calls.

[0096] For example, the account login display interface 10 of the video player can be as follows: Figure 3 As shown in (a), on the video player display interface 10, users can log in to the video player using their mobile phone number. After the user enters their mobile phone number, they click the "Get Verification Code" button 101, as shown in (a). Figure 3 As shown in (b) above. At this point, the video player process obtains permission to access the SMS application via a Binder call, and then retrieves the verification code from the SMS message received by the SMS application. The video player can then display the verification code above keyboard 102, as shown below. Figure 3 As shown in (c) in the figure.

[0097] For example, if a video player experiences buffering during playback, it needs to determine its network connection. Therefore, the video player can request Wi-Fi connection information from the electronic device's system service. In this case, the video player can use Binder to request access to the system service and then obtain the Wi-Fi connection information from the system service.

[0098] It should be understood that the above are illustrative examples of application scenarios and do not limit the application scenarios of this application in any way.

[0099] The following is combined with Figures 4 to 8 The detection method provided in the embodiments of this application will be described in detail.

[0100] Figure 4 This is a flowchart illustrating a detection method provided in an embodiment of this application, as shown below. Figure 4 As shown, the method includes:

[0101] S101. Determine the Binder call handle in the program code.

[0102] In this context, a Binder call handle refers to an identifier used for cross-process referencing and invoking remote objects (such as services or methods). This handle establishes an indirect reference relationship between the client (caller) and the server (callee), allowing the client to invoke server methods or access their data through this handle. In some cases, such as in Java code within the Android system, initiating a Binder call typically requires first obtaining a Binder call handle and then performing a cross-process call based on that handle.

[0103] Optionally, a Binder call handle (or Binder object) includes a direct call handle and an indirect call handle.

[0104] In this context, "direct call handle" can refer to the ability of a Binder call handle to be directly converted into an access interface for other processes, enabling the current process to interact with other processes for data exchange.

[0105] For example, the communication between a client and a server will be used as an example. The program code in the client used to establish communication with the server can be as shown in Example Code 3, which includes:

[0106]

[0107] In this context, the client can refer to an application installed on an electronic device, while the server can refer to a system service on the electronic device. Communication between the client and server refers to communication between the application installed on the electronic device and the system service of the electronic device.

[0108] When a client requests data from a server, the client can convert the Binder call handle into a server interface, and then obtain the data from the server through the Binder call handle, thus achieving cross-process communication.

[0109] For example, a client can trigger cross-process communication through the onServiceConnected function.

[0110] When a client needs to establish a connection with a server, it can call the function `Context.bindService(Intent, ServiceConnection, int)` to establish the connection. Here, `Intent` specifies the server to be connected as `Service`. As shown in the code above, `ServiceConnection` is a callback interface through which the client receives notifications about the connection status with the server.

[0111] If the connection between the client and the server is successfully established, the function onServiceConnected(ComponentName,IBinder) of "ServiceConnection" in the above program code will be called. The "IBinder" parameter can refer to the handle of the communication channel of the server service.

[0112] Based on the "IBinder" parameter, the client obtains the IMyService interface through IMyService.Stub.asInterface(service) and then calls the getNumber() function to access the server.

[0113] In some cases, for ease of use and management, electronic devices may encapsulate some built-in system services. For example, electronic devices may encapsulate the audio service and notification service built into the Android system. If a client needs to communicate with a server, it can obtain the IBinder object of the server registered in the system services using `android.os.ServiceManager.getService` or `android.content.Context.getSystemService`. In this case, if the client needs to communicate with the audio service or notification service, it will directly obtain the corresponding server interface using `android.os.ServiceManager.getService` or `android.content.Context.getSystemService`, instead of obtaining the server's IBinder object.

[0114] In this scenario, since the client does not directly obtain the IBinder object through `getService`, it does not need to locate the IBinder object before performing interface conversion. The client can directly locate the server interface through `getService`, which encapsulates the underlying IBinder logic. Therefore, the server interface obtained through this method can also be referred to as an indirect call handle.

[0115] For example, the code for cross-process communication between the client and the server can be shown in Example Code 4. The client obtains the current Android system's built-in service interface WindowManager wm through android.content.Context.getSystemService(Context.WINDOW_SERVICE), and then initiates a Binder call through the built-in service interface WindowManager wm to directly access the server; Example Code 4 includes:

[0116]

[0117] In Android, the ContentResolver and ContentProvider mechanism is a cross-process communication method primarily used for data sharing. This mechanism communicates via Binder at the underlying level; therefore, communication between ContentResolver and ContentProvider is also a form of indirect communication.

[0118] ContentProvider is a core component in Android used to manage shared data between applications. Developers can use ContentProvider to provide data externally or access data provided by other applications. ContentProvider exposes data through URIs (Uniform Resource Identifiers), and client applications can use these URIs to request or manipulate data. ContentResolver is the interface used by applications to access data provided by ContentProvider. Applications can perform operations such as querying, inserting, deleting, and updating through ContentResolver. When an application requests access to a ContentProvider through ContentResolver, the system finds a matching ContentProvider and calls the appropriate function to process the request.

[0119] In practical implementation, when two applications need to access each other across processes, one application typically needs to register a ContentProvider through AndroidManifest to provide data to other applications. The other application accesses the data through ContentResolver. In this case, it's necessary to check if the URI in the ContentResolver request is provided by a ContentProvider within the application's process. If the ContentProvider is self-registered within the current process, no binder call is involved; otherwise, an implicit binder call occurs. When the ContentProvider needs to be accessed by other applications (i.e., other processes), the request must be communicated across processes via the Binder mechanism. In this situation, the request initiated by ContentResolver is encapsulated into a Binder event and transmitted across processes to the process where the ContentProvider resides via the Binder mechanism. Within the ContentProvider's process, the Binder mechanism unpacks the request and calls the ContentProvider's corresponding method to handle it. After processing, the result is also returned to the requester via the Binder mechanism. Therefore, ContentResolver, as the request initiator, is identified as an indirect Binder handle.

[0120] The code for registering a ContentProvider via AndroidManifest can be shown in example code 5, which may include:

[0121]

[0122] In example code 5, the application of process 1 statically registers itself as a ContentProvider in the AndroidManifest.xml file. The AndroidManifest.xml file is a core file for Android applications, providing declarations of all application components and required permissions. Located in the root directory of the project, it is a required file for every Android project. It describes basic information about the application to the Android system, including the application's package name, declarations of components (Activities, Services, Broadcast Receivers, Content Providers), required permissions, supported hardware and software features, etc. Specifically, the application of process 1 constructs a ContentProvider that supports access from external processes by setting authorities="com.example.provider" and android:exported="true", and allows external processes (e.g., process 2) to access it via a URI using the unique identifier "android:authorities="com.example.provider".

[0123] Then, another process, such as process 2, acting as the data receiver CntentResolver, can access process 1 based on program code. The program code by which process 2 accesses process 1 can be as shown in example code 6, where example code 6 includes:

[0124] / / Process 2 accesses Content Provide (Process 1) through inter-process communication;

[0125] Uri contentUri=Uri.parse("content: / / com.example.provider / items");

[0126] Cursor cursor=getContentResolver().query(contentUri,null,null,null,null);

[0127] Process 2 can access process 1 via "Uri="content: / / com.example.provider / items"" to achieve cross-process communication.

[0128] It should be noted that the Messenger SMS service and BroadcastReceive broadcast service also involve cross-process communication, but these two services usually only need to send simple messages and do not need to perform frequent message exchanges. Therefore, the probability of frequent Binder calls is small, which in turn makes the probability of problems caused by frequent Binder calls small.

[0129] Table 1 shows some common Binder call handles that are prone to causing frequent Binder calls.

[0130] Table 1

[0131]

[0132] Intermediate Representation (IR) is an abstract representation between source code and target machine code, which can be used to optimize and analyze programs.

[0133] The detection method provided in this application embodiment can model the program code of the data provider and data receiver in IPC communication based on the above-mentioned Binder call handle, and perform mixed analysis by combining the compilation language (e.g., Java, XML) of the program code of the data provider and data receiver in IPC communication. Then, the intermediate representation IP is generated by the parser. Finally, the IR is traversed to locate the above-mentioned Binder call handle and the Binder call source point is determined.

[0134] The Parser can be divided into Java AST Parse and XML Parse. If the program code is compiled in Java, the original program code is converted into IR through Java AST Parse. If the program code is in XML format, the original program code is converted into IR through XML Parse.

[0135] S102. Determine the target handle based on the Binder call handle.

[0136] The target handle can refer to the handle associated with the Binder call handle mentioned above.

[0137] It's understandable that there are inter-process communication (IPC) paths between program code; that is, while a Binder call handle can trigger inter-process communication (IPC), other handles can also trigger IPC by calling the Binder call handle. Therefore, after identifying the Binder call handle, we can determine the handles associated with it—that is, the handles that trigger IPC by calling the Binder call handle. This improves the completeness of finding handles that frequently trigger Binder calls and avoids performance issues caused by frequent Binder calls.

[0138] For example, for the expression a = b, if b is a Binder call handle, then through the expression a = b, the Binder call handle is passed to a, so that a becomes a handle associated with the Binder call handle, that is, a also becomes a Binder call handle.

[0139] Common associations include: assignment, variable declaration, container operations, loop structures, function return value passing, and function parameter passing. These associations are explained below.

[0140] Assignment, variable declaration:

[0141] Assignment and variable declaration refer to assigning the value of one variable to another. In this case, if one variable is a Binder call handle, the other variable will also trigger a Binder call.

[0142] Assignment and variable declaration can be represented by Assign&Declare(v,e). The relationship between the Binder call handle and other handles in assignment and variable declaration can be found in formula (1), which includes:

[0143]

[0144] Where IBE represents the Binder call handle; IBES represents the handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; e represents an expression; v represents a variable; ibE represents the handle association relationship; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0145] As shown in formula (1), if expression e is assigned the Binder call handle before program code l, that is to say, In this scenario, since `e` is assigned to the variable `v`, `v` can also trigger inter-process communication via the Binder call handle. IBES[ l ](v) represents the set of all handles that trigger Binder calls corresponding to the variable v after program code l.

[0146] If expression e is not a Binder call handle, then the association of all Binder call handles pointing to expression e is also assigned to variable v, that is, each Binder call handle pointing to expression e. It is also pointed to the variable v, i.e., IBE→v.

[0147] Container operations:

[0148] Container operations can refer to various management activities performed on objects that store and manage other objects in program code. A container can refer to an object that stores and manages other objects in program code. If an operation is performed on a container, such as inserting an item, a Binder object may be inserted. The relationship between the Binder call handle generated by the insertion operation in a container operation and other handles can be seen in formula (2), which includes:

[0149]

[0150] Where, c represents the container object; e represents the index expression; u represents the item object to be inserted; IBE represents the Binder call handle; IBES represents the handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; ibE represents the handle association relationship; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0151] For example, c[e] represents the e-th object in container c.

[0152] If the item object u to be inserted is a Binder call handle, that is Through the container insertion operation, the object c[e] corresponding to index e is the handle associated with the Binder call handle mentioned above. That is, the Binder call handle can be called through c[e], thereby triggering cross-process communication.

[0153] If the item object u to be inserted is not a Binder call handle, then all Binder call handles pointing to u will be used. It also points to c[e].

[0154] Access operations in container operations can refer to operations that access objects within the container. The relationship between the Binder call handle generated by the access operations in container operations and other handles can be found in formula (3). Formula (3) can include:

[0155]

[0156] Where, c represents the container object; e represents the index expression; v represents the assigned object after access; IBE represents the Binder call handle; IBES represents the handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; ibE represents the handle association relationship; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0157] For example, c[e] represents the e-th object in container c.

[0158] Taking the accessed object c[e] as an example, if c[e] is a Binder call handle, that is... Then, the object variable v assigned after accessing c[e] is also assigned the Binder call handle, that is...

[0159] If c[e] is not a Binder call handle, then all Binder call handles pointing to c[e] are... It also points to the object variable v assigned after accessing c[e].

[0160] Loop structure:

[0161] A loop structure can refer to a code structure that uses loop statements. The relationship between the Binder call handle generated by the loop structure and other handles can be found in formula (4). Formula (4) can include:

[0162]

[0163]

[0164] Where v represents the iteration variable; c represents the iteration range, such as a data structure formed by an array or a set; c i Indicates the i-th child element in the iteration range; IBE represents the Binder call handle; IBES represents the handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; ibE represents the handle association relationship; [ lThe symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0165] If we use an iteration variable V to iteratively access a specific sub-element of an array or set data structure c, for example, the i-th sub-element, if c i At the current location, that is, before the program code 'l', a Binder call handle is assigned, i.e. The iteration variable v is then assigned the Binder call handle.

[0166] If c i At the current position, that is, before the program code 'l', if it has not been assigned a Binder call handle, it points to 'c'. i All Binder call handles are also pointed to the iteration variable v.

[0167] Function return value passing:

[0168] Function return value passing refers to returning the result data to the place that called the function after the function has finished executing. The function return value is the result returned to the caller after the function has finished executing. This return value can be any type of data, such as integers, floating-point numbers, strings, objects, etc. The function specifies the value to be returned using the `return` statement. The association between the Binder call handle generated through function return value passing and other handles can be seen in formula (5), which includes:

[0169]

[0170] Where `return(m,e)` represents a function return statement, where `m` represents a function, `e` represents a return statement, and `m.ret` represents the function's return value; `IBE` represents the Binder call handle; `IBES` represents a handle set, which includes the Binder call handle and the target handle associated with it; `ibE` represents the handle association relationship; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0171] If the return statement 'e' is assigned a Binder call handle at the current position, that is, before the program code 'l', then... The function's return value, m.ret, is also assigned the Binder call handle.

[0172] If the return statement e has not been assigned a Binder call handle at the current position, that is, before the program code l, then all Binder call handles pointing to the return statement e are also pointed to the function return value m.ret.

[0173] Function parameter passing:

[0174] Function parameter passing refers to the process during program execution where actual parameters (or simply arguments) pass their values ​​to corresponding formal parameters (or simply parameters), and then the function processes and returns the data. Formal parameters are the variable names enclosed in parentheses after the function name when defining the function. Formal parameters are not actual variables; they are also called virtual variables and are used in defining the function name and body to receive parameters passed when the function is called. When calling the function, actual parameters can be assigned to formal parameters. Actual parameters can be expressions enclosed in parentheses after the function name when calling the function. Actual parameters can be constants, variables, expressions, functions, etc. When a function is called, the actual parameters must have definite values ​​so that these values ​​can be passed to the formal parameters.

[0175] The relationship between the Binder call handle generated by passing function parameters and other handles can be seen in formula (6), which can include:

[0176]

[0177] Here, Parameter(m,E,P) represents a function parameter passing statement, where m represents the function, E is the set of actual parameter expressions, P is the set of formal parameter variables, and e... a P represents the a-th argument expression in the set of argument expressions. a This represents the a-th formal parameter variable in the set of formal parameters; IBE represents the Binder call handle; IBES represents the handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; ibE represents the handle association relationship; l represents the program code at the current location, that is, the program code in the inspection state; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0178] During each function call with arguments, the passed arguments (e.g., e) will be passed to the function. a Assign the value to the corresponding formal parameter (e.g., P). a ).

[0179] If the actual parameter e aAt the current position or before the current position, that is, at the location of program code l, or before program code l, a Binder call handle is assigned, and the actual parameter e will be passed through the function parameter. a Assigned to formal parameter P a Then the formal parameter P a It is also assigned the Binder call handle.

[0180] If the actual parameter e a If the current position or the position before the current position (i.e., the position of program code l) is not a Binder call handle, then it points to the actual parameter e. a All Binder call handles are also pointed to the parameter P. a That is, ibE→p a .

[0181] It should be noted that the relationships between program code that can pass Binder call handles are not limited to the above five relationships. The above five relationships between program code are only illustrative and are not limited in this application embodiment.

[0182] After determining the handle associated with the Binder call handle (hereinafter referred to as intermediate handle) through the above-mentioned association between the program code that can call the handle, these intermediate handles can be further filtered to remove duplicate handles and obtain the target handle.

[0183] Alternatively, the target handle can be obtained by removing duplicate handles from intermediate handles through constraint aggregation, constraint propagation, and constraint retention.

[0184] Constraint aggregation can refer to the aggregation of handles that reuse the same Binder source.

[0185] It should be noted that in actual use, a statement can include multiple syntactic units. Therefore, if a variable is located at the intersection of multiple syntactic units, for example, variable v in syntactic unit U... i and syntax unit U j In the intersection of, i.e., v∈U i ∩U j If variable v is the Binder source triggered by the Binder call handle, then syntax unit U i and syntax unit U j This could refer to the Binder call handle, which sets the syntax unit U. i and syntax unit U j Aggregation is equivalent to removing duplicate Binder call handles.

[0186] For example, formula (7) can be an example of constrained aggregation, formula (7) includes:

[0187]

[0188] Among them, Aggregate(U i U j ) indicates the syntax unit U i and syntax unit U j Perform constraint aggregation; v can refer to a variable, for example, variable v is the Binder source point triggered by the Binder call handle; syntax unit U i and syntax unit U j This can refer to the Binder call handle; IBE represents the Binder call handle; IBES represents a handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; l represents the program code at the current location, that is, the program code in the inspection state; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0189] Constraint propagation in flow-sensitive dataflow analysis refers to the precision of flow-sensitive constraint analysis. For example, for the same variable, the process of propagating the inference result from the most recent preceding context to its corresponding following context.

[0190] For example, formula (8) can be an example of constraint propagation, formula (8) includes:

[0191]

[0192] Here, `Propagate(l1,l2,v)` represents the propagation principle of program code `l1` and program code `l2`, `v` can refer to a variable, for example, variable `v` is the Binder source point triggered by the Binder call handle; `IBE` represents the Binder call handle; `IBES` represents the handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; `l` represents the program code at the current position, that is, the program code in the inspection state; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0193] Constraint retention can refer to filtering out redundant constraint information from irrelevant syntax units, retaining only the syntax units related to Binder handle propagation, and filtering out data flow information related to other units.

[0194] For example, formula (9) can be an example of constraint propagation, formula (9) includes:

[0195]

[0196] Where Preserve(v) represents the propagation principle of program code l1 and program code l2; v can refer to a variable, for example, variable v is the Binder source point triggered by the Binder call handle; IBE represents the Binder call handle; IBES represents the handle set, which includes the Binder call handle and the target handle associated with the Binder call handle; l represents the program code at the current position, that is, the program code in the inspection state; [ l The symbol ] indicates the preceding text of position l, that is, the code segment before program code l; This indicates the text following position l, that is, the code segment after program code l.

[0197] Thus, embodiments of this application can determine the target handle based on the Binder call handle.

[0198] For example, such as Figure 5 As shown, the Binder call handle can be as follows: Figure 5 The hollow sphere in the middle, the target handle can be like Figure 5 The solid sphere in the image. Merging the Binder call handle and the target handle yields a set of all handles in the program code that can trigger the Binder call source.

[0199] The detection method provided in this application not only identifies the Binder call source point based on the Binder call handle, but also combines the target handle of the Binder call handle to identify the Binder call source point, making the identified Binder call source points more comprehensive, thereby improving the comprehensiveness of the target Binder call path set obtained based on the Binder call source point.

[0200] S103. Identify the Binder call source point based on the Binder call handle and the target handle.

[0201] Having identified the target handle based on the Binder call handle, we can further identify the Binder call source. The Binder call source is typically the location of the code that initiates the Binder call—that is, the place where a Binder handle is created or used to call a remote method. By identifying these source points, we can understand which parts of the code are performing inter-process communication and how this communication is initiated.

[0202] A set of service interfaces can be generated based on the Binder call handle and target handle, so that subsequent remote calls can invoke the Binder call source point through the service interfaces in the service interface set, and then the Binder call source point can be identified from the program code through the call statement, such as the function Caller.

[0203] For details on identifying the Binder call source based on the Binder call handle and target handle, please refer to [link / reference]. Figure 6 .like Figure 6 As shown, the specific process of identifying the Binder call source point based on the Binder call handle and target handle can include:

[0204] S1031. Convert the Binder call handle and target handle into intermediate representations (IR).

[0205] For example, common intermediate representations of Binder call handles and target handles include:

[0206] The intermediate representation (IR) passed as the function return value can be abcmethodReturnBinder();

[0207] The intermediate representation (IR) corresponding to the function parameter passing can be methodPassBinder(binderArg);

[0208] The intermediate IR corresponding to assignment and variable declaration can be binderToken.callRemoteMethod() and binderToken.refers localVar / field / iterator;

[0209] The intermediate representation (IR) for access operations in container operations can be binderTakenList[i].callRemoteMethod().

[0210] S1032. Determine whether the Binder call handle and target handle are service interfaces.

[0211] Understandably, Binder call handles can be categorized into direct call handles and indirect call handles. Direct call handles can serve as service interfaces, while indirect call handles cannot. Therefore, if a Binder call handle is an indirect call handle, it needs to be converted into a service interface before it can be invoked. The intermediate representation (IR) corresponding to the Binder call handle and the target handle can determine whether the Binder call handle and the target handle are service interfaces.

[0212] If the Binder call handle or target handle is a service interface, then the Binder call handle or target handle is added to the service interface set, which is to execute S1033.

[0213] If the Binder call handle or target handle is not a service interface, then the Binder call handle or target handle is converted into a service interface, and the converted service interface is added to the service interface set, that is, it points to S1034 and S1033.

[0214] S1033. Add the Binder call handle or target handle to the service interface set.

[0215] S1034. Convert the Binder call handle or target handle into a service interface.

[0216] For example, the function asInterface converts a Binder call handle or target handle into a service interface.

[0217] S1035. Obtain the Binder call source point based on the service interfaces in the service interface set.

[0218] Since the service interfaces in the service interface set are obtained from Binder call handles or target handles, calling these service interfaces is typically a remote call or a cross-process call, and the calling node is the Binder call node. After determining the service interface set, the Binder call source point can be obtained based on the calling nodes of the service interfaces in the set.

[0219] S104. Generate an initial set of Binder call paths based on the Binder call source.

[0220] In program code, there are often multiple call chains across modules targeting the same function. Therefore, it is necessary to identify the Binder call source point and further locate all functions that directly or indirectly call the Binder call source point, as well as the related function call chains. These functions that directly or indirectly call the Binder call source point, and their related function call chains, can be referred to as the Binder call path.

[0221] For example, in example code 1, the Binder call source is getWifiManager().getConnectionInfo(), and its corresponding Binder call path is: ExampleNextClass::badCheckWifiActivated(frequent call occurpoint)->ExampleClientClass::isWifiActivated->WifiManager::getConnectionInfo(source bindercall).

[0222] The process of generating Binder call paths based on Binder call source points can refer to first generating a Binder call tree based on the Binder call source points and a first algorithm, and then generating an initial set of Binder call paths based on the Binder call tree and a second algorithm.

[0223] The Binder call tree can refer to the call mapping relationship between the Binder call source and the function.

[0224] The first algorithm can refer to a fixed-point iterative algorithm, or it can be other algorithms. This application does not limit the specific algorithms used in this embodiment.

[0225] The fixed-point iterative algorithm is a simple and effective numerical computation method that approximates a fixed point by iterating over a function. Based on this algorithm, we can approximate the source point of the Binder call by iterating over a function, finding the set of functions that directly or indirectly call the source point of the Binder call, and generating a Binder call tree.

[0226] Example code 7 is a piece of program code that generates a Binder call tree based on the Binder call source and the first algorithm. Example code 7 includes:

[0227]

[0228]

[0229] Here, targetNode is the specified target node, such as the Binder call source point; callSet is a collection containing UcallExpressions, representing function calls in the program code; and n is a threshold used to limit the number of iterations of the algorithm to prevent the algorithm from getting stuck in an infinite loop.

[0230] In example code 7, the specific process of obtaining the Binder call tree through the fixed-point iteration algorithm, using targetNode, callSet, and n as inputs to the fixed-point iteration algorithm and the Binder call source point, can include:

[0231] 1. Initialize the fixed-point iteration algorithm.

[0232] The initialization settings may include setting the changed flag to true, setting the iteration counter to 0, and creating a node set targetNodes, which includes the Binder call source node targetNod.

[0233] 2. Check the iteration conditions.

[0234] The iteration continues as long as the changed flag is set to true and the iteration counter count is less than n.

[0235] 3. Determine the status of the changed flag.

[0236] If the changed flag is set to false, the current iteration stops and a check is performed to see if there are any new call mappings.

[0237] 4. Traverse the node collection targetNodes.

[0238] First, locate the wrapper function (e.g., `wrapper`) of the currently calling node. If the current calling node is in the node set `targetNodes`, and its corresponding wrapper function is not in `targetNodes`, then add the mapping between the wrapper function and the current calling node `targetNode` to the Binder call tree `BinderItemMap`, and also add the wrapper function to the node set `targetNodes`. Finally, set the changed flag to `true`, indicating that a new call mapping was found in this iteration.

[0239] 5. Increase the value of the iteration counter count.

[0240] If a new call mapping is discovered during the current iteration, the iteration counter count is incremented.

[0241] 6. Determine whether the iteration should terminate.

[0242] If the iteration does not terminate, the iteration continues based on the updated set of nodes, targetNodes.

[0243] The determination of whether to terminate an iteration can be based on the following conditions: a) If no new call mapping is found in the current iteration, and if the changed flag is set to false, then the iteration terminates; b) If the iteration counter count reaches the set threshold n, then the iteration terminates.

[0244] Based on example code 7 above, iterating over example code 1, the resulting call mapping relationship can be referenced in example code 8, where example code 8 includes:

[0245]

[0246]

[0247] In this case, methodB also calls isWifiActivated, meaning that methodB belongs to the Binder call tree.

[0248] In this way, all functions belonging to the Binder call tree can be identified from the program code, and the final Binder call tree can be generated.

[0249] Then, the Binder call path can be generated based on the Binder call tree and the second algorithm.

[0250] The second algorithm can refer to traversing the Binder call tree through depth-first search (DFS), or it can be other algorithms. This application embodiment does not limit this.

[0251] DFS is an algorithm for traversing or searching trees or graphs. The DFS algorithm searches as deep as possible along each branch of the search tree or graph until it reaches a leaf node (in the case of a tree) or the end of the graph, and then backtracks to the previous node to continue searching for other unvisited branches.

[0252] For example, example code 8 can be used to generate the initial Binder call path based on the Binder call tree and a second algorithm (e.g., DFS), wherein example code 8 includes:

[0253] Step 1: BinderChains = {} currentchain = null / / Initialization;

[0254] Step 2: if currentChain contains startNode then / / If the call chain has formed a loop, then terminate;

[0255] / / If step 2 is executed based on the call to step 9, then the call path has looped back, so backtracking is necessary;

[0256] Step 3if executed by 9, callback to 9; else stop;

[0257] Step 4 currentChain.addPath(StartNode) / / Record the currently called node in the call path;

[0258] Step 5: if StartNode equals the targetBinderNode then / / If the current node is the original Binder calling node;

[0259] Step 6 BinderChains.add(currentChain) / / We have reached the end of a call path;

[0260] Step 7: If executed by 9, callback to 9; else stop;

[0261] Step 8: for method in BinderItemMap.get(startNode) / / Get all child nodes of the current node, perform DFS search on each node, iterate through the depth of the search for each node and record the path, and after the search is completed, search again and record the relevant path of the next node;

[0262] Step 9: startNode = method, execute 2.

[0263] Here, `targetBinderNode` can refer to the target node, which can be the node corresponding to the Binder call node found through DFS. `startNode` can refer to the starting node; for example, `startNode` can be the Binder call node. `BinderItemMap` can refer to the call mapping, such as the Binder call tree mentioned above. The keys in `BinderItemMap` can be nodes, including the target node `targetBinderNode` and the starting node `startNode`, and the values ​​are the set of all nodes reachable from the starting node. `BinderChains` can refer to the set of all paths from the starting node `startNode` to the target node `targetBinderNode`, which is the initial set of Binder call paths.

[0264] In example code 8, the target node `targetBinderNode`, the starting node `startNode`, and `BinderItemMap` are used as inputs to the Depth-First Search (DFS) to obtain the Binder call path set `BinderChains`. The specific process of obtaining the initial Binder call path set through DFS and the Binder call source node can include:

[0265] 1. Initialize the DFS settings.

[0266] The initialization settings for DFS may include creating an empty set of paths, BinderChains, and a current path, currentChain.

[0267] 2. Determine the starting node startNode and begin the search to see if the target node targetBinderNode can be reached.

[0268] If a search from the starting node (startNode) leads to the target node (targetBinderNode), and the target node (targetBinderNode) is the starting node (startNode), then a complete path has been found. If the starting node (startNode) is the source of the Binder call, then this path is a Binder call path.

[0269] If the search was not triggered by step 5 "if StartNode equals the targetBinderNode then", then the current search path currentChain can be added to the Binder call path set as a Binder call path BinderChains.

[0270] If the search is triggered by step 5 "if StartNode equals the targetBinderNode then", it is necessary to backtrack to the parent node in step 5 and continue exploring other possible related paths; otherwise, if no other possible paths exist, the algorithm should be stopped.

[0271] 3. Determine whether the Binder call path has been formed.

[0272] It should be noted that when searching starting from the start node (startNode), if the target node (targetBinderNode) is found, it means that there is a call path between the target node (targetBinderNode) and the start node (startNode). The set of Binder call paths includes each Binder call path, which can be a link loop including the Binder call source node. That is, if the start node (startNode) is the Binder call source node, then the call path obtained by searching starting from the start node (startNode) is a Binder call path in the set of Binder call paths.

[0273] If the current path `currentChain` already contains the starting node `startNode`, it means that the call path has been formed, and the search for the current call path can be terminated. For example, if the found call path is `a()->b()->c(){return a()}->a}`, then a link loop has been formed. At this point, the iterative search for this path can be stopped; otherwise, an endless loop will occur. That is, delete the path that jumps back to `a`, record `a()->b()->c(){return a()}`, and then backtrack the search point from the last `a()` to `c()`. If `c()` subsequently calls other functions, such as `d()`, then after backtracking to `c`, the search iteration can continue.

[0274] In this case, if the trigger condition for checking the call path is based on "startNode = method, execute2", which is the program code in step 9 above, it means that the call path is a path formed by backtracking during the depth-first search process. It is necessary to go back to step 5 above, "ifStartNode equals the targetBinderNode then", to continue exploring other possible child node related paths. If the trigger condition for checking the link loop is not the program code in step 9 above, the search can be stopped directly.

[0275] 4. Add the currently retrieved link ring as a Binder call path to the Binder call path set.

[0276] If it is determined that the link loop already exists, the starting node of the current search is added to the currentChain as a Binder call path.

[0277] 5. Traverse all starting nodes.

[0278] For each child node of each starting node startNode, steps 2 to 5 can be executed recursively. By performing DFS through BinderItemMap.get(startNode), multiple call paths corresponding to each starting node startNode can be obtained, which is the initial set of Binder call paths.

[0279] In one possible scenario, the generated initial set of Binder call paths may include the following two Binder call paths:

[0280] Binder call path 1:

[0281] ExampleNextClass::badCheckWifiActivated->ExampleClientClass::isWifiActivated->WifiManager::getConnectionInfo;

[0282] Binder call path 2:

[0283] ExampleClassB::methodB->ExampleClientClass::isWifiActivated->WifiManager::getConnectionInfo.

[0284] S105. Verify the Binder call paths in the initial Binder call path set to obtain the target Binder call path set.

[0285] It should be noted that the Binder call paths in the initial Binder call path set determined by S104 only determine all paths that return from the Binder call source point to the Binder call source point. In some possible cases, the Binder call source point may only return to the Binder call source point once. This situation will not cause frequent Binder calls. Therefore, the Binder call paths in the initial Binder call path set can be verified, and the Binder call paths that will not cause frequent Binder calls can be removed from the initial Binder call path set to obtain the target Binder call path set.

[0286] For example, each node in each Binder call path in the initial set of Binder call paths is checked to see if the node will cause frequent Binder calls. Figure 7As shown, a Binder call path includes i nodes. Each node is checked to determine whether it will cause frequent Binder calls.

[0287] For example, the function `UCallExpression Nodei` can be used to obtain the function code block containing the current node and check if the parent node of the current node has a loop node. A loop node refers to a node that is called repeatedly. If a loop node exists in the Binder call path, it will cause frequent Binder calls. Common loop nodes include `UForExpression`, `UWhileExpression`, and `UDoWhileExpression`. If a loop node exists in the Binder call path, that Binder call path is added to the target Binder call path set. The target Binder call path set is obtained by traversing each Binder call path in the initial Binder call path set using the above method.

[0288] Furthermore, the function `kill.callNode` can be used to remove Binder call paths that do not have a loop node from the initial Binder call path set, thus obtaining the target Binder call path set.

[0289] The following code demonstrates the specific process of determining the target Binder call path set.

[0290] Example code 9 is a piece of code that retrieves the status of a Wi-Fi network. It involves Binder calls, which carries the risk of frequent Binder calls. Example code 9 may include:

[0291]

[0292]

[0293] Identifying the Binder call handle from example code 9 can be done as shown in example code 10, which includes:

[0294]

[0295] The Binder call handle set can include:

[0296]

[0297] For details on determining the target handle based on the Binder call handle, please refer to Example Code 11, which includes:

[0298]

[0299] The Binder call handle can include:

[0300]

[0301] Example code 12 demonstrates how to identify the Binder call source based on the Binder call handle and target handle. Example code 12 may include:

[0302]

[0303] Binder call source collection: {getWifiManager().getConnectionInfo()}

[0304] The initial set of Binder call paths obtained based on the Binder source point can include:

[0305]

[0306] Based on example code 13, a target set of Binder call paths can be generated from an initial set of Binder call paths. Example code 13 includes:

[0307]

[0308] The target Binder call path set is: {preClient.isWifiActivated()}.

[0309] The detection method provided in this application, in the process of obtaining the target Binder call path set based on the Binder call source point, first generates an initial Binder call path set based on the Binder call source point; then verifies the Binder call paths in the initial Binder call path set to obtain the target Binder call path set. That is to say, the target Binder call path set is obtained by verifying the Binder call paths in the initial Binder call path set, and removes erroneous and duplicate Binder call paths from the initial Binder call path set, thus avoiding the use of incorrect Binder call paths when verifying Binder calls based on the target Binder call path set, thereby improving the efficiency of Binder call verification.

[0310] After obtaining the set of target Binder call paths, a Binder call detection report can be generated and displayed to the user to alert them to the risks of frequent Binder calls. For example, the Binder call detection report can be as follows: Figure 8 As shown. Figure 8 The detection report for Binder calls shown is merely an example and does not constitute a limitation on the detection report for Binder calls.

[0311] by Figure 8 The Binder call detection report shown below serves as an example. The report includes a text message 801 and a code screenshot 802. The text message 801 alerts the user to the risk of frequent Binder calls, while the code screenshot 802 displays the code indicating the risk. Users can modify the code based on the screenshot 802 to avoid frequent Binder calls.

[0312] The detection method provided in this application, after generating the target Binder call path set, further generates a Binder call detection report that can be viewed by the user, so that the user can optimize the program code based on the Binder call detection report.

[0313] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0314] It is understood that, in order to achieve the above functions, the electronic device includes hardware and / or software modules that perform the respective functions. Based on the algorithmic steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0315] This application embodiment can divide an electronic device into functional modules based on the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one module. It should be noted that the module division in this application embodiment is illustrative and represents only one logical functional division; other division methods may be used in actual implementation. It should also be noted that the module names in this application embodiment are illustrative, and the names of the modules are not limited in actual implementation.

[0316] Figure 9 This is a schematic diagram of a detection device provided in an embodiment of this application.

[0317] It should be understood that the detection device 600 can perform... Figures 4 to 8 The detection method shown; the detection device 600 includes: an acquisition unit 610 and a processing unit 620.

[0318] The processing unit 620 is used to determine the Binder call handle in the program code, the Binder call handle includes an identifier for cross-process communication; identify the Binder call source point based on the Binder call handle, the Binder call source point is the node that triggers the Binder call; obtain the target Binder call path set based on the Binder call source point, the target Binder call path set includes at least one target Binder call path, and the target Binder call path includes multiple functions that call the Binder call source point.

[0319] The detection device provided in this embodiment is used to perform the detection method of the above embodiment. The technical principle and technical effect are similar, and will not be described again here.

[0320] It should be noted that the aforementioned detection device 600 is embodied in the form of a functional unit. The term "unit" here can be implemented in software and / or hardware, without specific limitations.

[0321] For example, a "unit" can be a software program, a hardware circuit, or a combination of both that implements the above functions. The hardware circuit may include an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, a proprietary processor, or a group processor) and memory for executing one or more software or firmware programs, integrated logic circuitry, and / or other suitable components that support the described functions.

[0322] Therefore, the units of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0323] Figure 10 A schematic diagram of the structure of an electronic device provided in this application is shown. Figure 10 The dashed lines indicate that the unit or module is optional. The electronic device 700 can be used to implement the detection method described in the above method embodiments.

[0324] The electronic device 700 includes one or more processors 701, which can support the implementation of the detection method in the method embodiments of the electronic device 700. The processor 701 can be a general-purpose processor or a special-purpose processor. For example, the processor 701 can be a central processing unit (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, such as discrete gates, transistor logic devices, or discrete hardware components.

[0325] The processor 701 can be used to control the electronic device 700, execute software programs, and process data from the software programs. The electronic device 700 may also include a communication unit 705 for inputting (receiving) and outputting (transmitting) signals.

[0326] For example, electronic device 700 may be a chip, communication unit 705 may be the input and / or output circuit of the chip, or communication unit 705 may be the communication interface of the chip, and the chip may be a component of terminal device or other electronic device.

[0327] For example, electronic device 700 can be a terminal device, communication unit 705 can be the transceiver of the terminal device, or communication unit 705 can be the transceiver circuit of the terminal device.

[0328] The electronic device 700 may include one or more memories 702, which store a program 704. The program 704 can be executed by the processor 701 to generate instructions 703, causing the processor 701 to execute the impedance matching method described in the above method embodiments according to the instructions 703.

[0329] Optionally, the memory 702 may also store data. Optionally, the processor 701 may also read the data stored in the memory 702, which may be stored at the same memory address as the program 704, or the data may be stored at a different memory address than the program 704.

[0330] The processor 701 and memory 702 can be configured separately or integrated together; for example, integrated on the system on chip (SOC) of the terminal device.

[0331] For example, the memory 702 can be used to store the relevant program 704 of the detection method provided in the embodiments of this application, and the processor 701 can be used to call the relevant program 704 of the detection method stored in the memory 702 when performing detection, and execute the detection method of the embodiments of this application; including: determining the Binder call handle in the program code, the Binder call handle including an identifier for cross-process communication; identifying the Binder call source point based on the Binder call handle, the Binder call source point being the node that triggers the Binder call; obtaining a target Binder call path set based on the Binder call source point, the target Binder call path set including at least one target Binder call path, the target Binder call path including multiple functions that call the Binder call source point.

[0332] This application also provides a computer program product that, when executed by processor 701, implements the detection method described in any of the method embodiments of this application.

[0333] The computer program product can be stored in memory 702, for example, program 704. Program 704 is finally converted into an executable object file that can be executed by processor 701 after processing such as preprocessing, compilation, assembly and linking.

[0334] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer, implements the detection method described in any of the method embodiments of this application. The computer program may be a high-level language program or an executable object program.

[0335] The computer-readable storage medium is, for example, memory 702. Memory 702 can be volatile memory or non-volatile memory, or memory 702 can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0336] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0337] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0338] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0339] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0340] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0341] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0342] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0343] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A detection method, characterized in that, The method includes: Identify the Binder call handle in the program code, the Binder call handle including an identifier for cross-process communication; The Binder call source point is identified based on the Binder call handle, and the Binder call source point is the node that triggers the Binder call; Based on the Binder call source point, a set of target Binder call paths is obtained. The set of target Binder call paths includes at least one target Binder call path, and the target Binder call path includes multiple functions that call the Binder call source point. The step of identifying the Binder call source point based on the Binder call handle includes: The target handle is determined based on the Binder call handle, and the target handle is an identifier associated with the Binder call handle; The source of the Binder call is identified based on the Binder call handle and the target handle; The step of identifying the Binder call source point based on the Binder call handle and the target handle includes: Determine whether the Binder call handle and the target handle are service interfaces; If the Binder call handle and the target handle are the service interfaces, then add the Binder call handle and the target handle to the service interface set; The Binder call source is obtained based on the service interfaces in the set of service interfaces.

2. The method according to claim 1, characterized in that, The association between the Binder call handle and the target handle includes: assignment, variable declaration, container operations, loop structures, function return value passing, and function parameter passing.

3. The method according to claim 1, characterized in that, The step of identifying the Binder call source point based on the Binder call handle and the target handle also includes: If the Binder call handle and the target handle are not the service interface, then after converting the Binder call handle and the target handle into the service interface, they are added to the service interface set.

4. The method according to claim 3, characterized in that, Determining whether the Binder call handle and the target handle are service interfaces includes: Convert the Binder call handle and the target handle into an intermediate representation (IR); Based on the intermediate representation IR of the Binder call handle and the target handle, determine whether the Binder call handle and the target handle are service interfaces.

5. The method according to any one of claims 1 to 4, characterized in that, The Binder call handle includes direct call handles and indirect call handles.

6. The method according to any one of claims 1 to 4, characterized in that, The set of target Binder call paths obtained based on the Binder call source point includes: An initial set of Binder call paths is generated based on the aforementioned Binder call source point; The Binder call paths in the initial Binder call path set are verified to obtain the target Binder call path set.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: A detection report of Binder calls is generated based on the target Binder call path set, and the detection report of Binder calls includes the Binder call paths in the target Binder call path set.

8. An electronic device, characterized in that, The electronic device includes a module for performing the method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: One or more processors; Memory; And one or more computer programs, wherein the one or more computer programs are stored on the memory, and when the computer programs are executed by the one or more processors, cause the electronic device to perform the method as described in any one of claims 1 to 7.

10. A chip system, characterized in that, The chip system includes a processor for calling and running a computer program from memory, causing an electronic device on which the chip system is installed to perform the method as described in any one of claims 1 to 7.

11. A computer-readable storage medium comprising a computer program, characterized in that, When the computer program is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1 to 7.

Images