Mobile application camera resource preemption detection method and system

Abstract

The invention provides a mobile application camera resource preemption detection method and system, and relates to software engineering.The method comprises the steps that static analysis is conducted on an APK file of an application program through a Soot framework; determining a target method, traversing all method definitions in the method list, comparing whether the method names and the parameter signatures are matched with the target method, and marking the matched methods as candidate methods; a control flow diagram of the candidate method is obtained, all paths in the control flow diagram are traversed, whether the paths contain API calling related to camera resource management or not is detected, and whether logic judgment missing or logic errors exist in logic branches of conditional statements in the paths or not is detected; and marking the camera APIs which do not accord with the resource management logic, the thread state abnormity or the authority checking logic abnormity as potential problem points. According to the invention, the camera resource preemption problem in the multi-window environment can be accurately detected, potential risks can be found, and the blank in the prior art is filled.

Description

Technical Field

[0001] The present invention relates to the field of software engineering, and in particular to a method and system for detecting resource preemption of a mobile application camera. Background Art

[0002] In mobile application development, multi-window mode has become an important feature of the Android operating system. This mode allows users to run multiple applications on the same screen at the same time, greatly improving the efficiency of multi-tasking and user experience. However, the introduction of this innovative mode is also accompanied by new technical challenges, especially in the management of exclusive hardware resources. As an exclusive resource, the camera is very likely to cause resource conflicts when multiple applications request to use the camera at the same time in multi-window mode. Common phenomena include the failure of the camera function to start successfully, the interruption of the camera function due to resource requests from other applications in the middle of operation, and the failure to release or re-apply resources correctly during multi-tasking switching, resulting in functional abnormalities. These problems not only directly affect the user experience, but may even cause some functions of the application to be completely unavailable, thus seriously weakening the actual usability of the multi-window mode. To further adapt to the multi-window mode, Android officials have adjusted the behavior of the application lifecycle methods since Android 10. In multi-window mode, multiple applications can be in the "Resumed" state at the same time, but in fact the focus belongs to only one of the applications. This means that the onResume() method can no longer accurately reflect whether the application has gained focus, and the method will not be retriggered when the focus switches. However, this change in lifecycle behavior has not been noticed by most developers. Many developers still bind the initialization and release logic of camera resources to the traditional onResume() and onPause() methods. This processing method fails to adapt to the focus switching requirements of multi-window mode, which further exacerbates the problem of camera resource management. The resource preemption problem brought about by this update significantly increases the complexity of application development in multi-window mode, and also puts higher requirements on application stability and user experience.

[0003] In the process of implementing the present invention, the applicant found that: in the field of Android application detection, there is currently no existing solution that can directly deal with the problem of camera resource preemption in the multi-window mode proposed by the present invention. However, some solutions similar to the technical direction of this patent provide some reference ideas. For example, the static analysis tool FlowDroid can be used to detect privacy data leakage problems, mainly by analyzing the data flow in the code to determine the usage of sensitive data; dynamic detection tools such as LeakCanary monitor memory usage at runtime to help developers discover and solve memory leaks. Although these technologies have certain reference value in their respective application fields, they cannot be directly applied to the preemption detection scenario of exclusive resources in the multi-window mode. The application scope of the existing technology is usually limited to a specific problem domain. Taking FlowDroid as an example, the tool focuses on tracking privacy data flows and can perform detailed analysis of the data flow in the code, but lacks in-depth support for the control flow and logic path of the callback method related to the multi-window mode. On the other hand, LeakCanary relies on dynamic detection methods and needs to construct specific scenarios at runtime to trigger problems, which is not only inefficient, but also difficult to cover all possible code paths. Although these technologies provide some references in their respective directions, they do not solve the problem of camera resource preemption detection in multi-window mode. These deficiencies are mainly reflected in: 1. Inability to cover complex management scenarios of exclusive resources; 2. Limited control flow analysis capabilities for multi-task switching and key callback methods; 3. Lack of targeted support for problems unique to multi-window mode.

[0004] Therefore, how to achieve efficient management of camera resources in multi-window scenarios has become a key technical problem that needs to be urgently solved in the current mobile application development field. Summary of the invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art or related technology, and discloses a mobile application camera resource preemption detection method and system, which can accurately detect the camera resource preemption problem in a multi-window environment, help to discover potential risks, and fill the gap in the prior art.

[0006] The first aspect of the present invention discloses a method for detecting camera resource preemption of a mobile application, comprising: code parsing and preprocessing: statically parsing the APK file of an application through a Soot framework to extract a method list of the application; global method screening: determining the onWindowFocusChanged method as a target method, traversing all method definitions in the method list, comparing the method names and parameter signatures one by one to see if they match the target method; if a method matching the target method cannot be detected, it is determined that the application cannot correctly manage camera resources; if a method matching the target method is detected, the matching method is marked as a candidate method and detailed information of the candidate method is output for subsequent analysis; path profiling Analysis: Build a complete control flow graph for each candidate method based on the Soot framework; traverse all paths in the control flow graph, detect whether the path contains API calls related to camera resource management, and detect whether there are logical judgment omissions or logical errors in the logical branches of conditional statements in the path; Semantic verification: Introduce a semantic verification mechanism to build the API call point context, track the call path and parameters of each camera API, analyze whether the call path and parameters conform to the correct resource management logic, and analyze whether the thread status and permission check logic of the call meet the normal use requirements of the camera API; mark the camera API that does not conform to the resource management logic, has abnormal thread status, or has abnormal permission check logic as potential problem points.

[0007] In this technical solution, the Soot framework is a Java optimization framework, which is mainly used to analyze and convert Java bytecode. The APK (Android application package) file is the installation package file of the Android application. The onWindowFocusChanged method is a standard callback method provided by the Android system, so it will not be renamed or modified by the R8 or ProGuard tools during the application code obfuscation process. This feature ensures that the detection technology of the present invention can be applied to open source applications and obfuscated market applications, and has wide applicability and robustness. In multi-window mode, multiple applications can be in the "restored" state at the same time, but the system focus belongs to only one of the applications, and the focus change is notified through the onWindowFocusChanged method.

[0008] The combined analysis of the control flow graph (CFG) and the call graph can be replaced by the program slicing technique. The program slicing technique simplifies the analysis scope by slicing the static dependencies of the code and only retaining the code paths related to the target variables or methods. This method can significantly reduce unnecessary path traversals when parsing resource call paths, improving the analysis efficiency. However, compared with the traditional CFG and call graph methods, the program slicing technique may miss indirect call paths in scenarios with complex multi-branch logic, and its applicability is slightly limited.

[0009] In addition to the static analysis-based method, an alternative solution combining dynamic verification can be designed. After detecting potential resource management problems in the static analysis phase, this solution verifies the static analysis results by dynamically simulating the multi-window focus switching scenario at runtime. For example, by simulating focus switching and camera resource contention on a virtual device, observe whether the target method correctly triggers the resource allocation and release logic. Although this alternative solution can improve the accuracy of the detection results, it requires additional runtime resources and depends on a highly restored runtime environment.

[0010] Context-sensitive analysis can be replaced by a deep learning model based on the Graph Neural Network (GNN). Through the graph structure embedding of the method call graph and the control flow graph, the GNN model can learn the semantic patterns of the code and predict resource management problems. Compared with traditional context-sensitive analysis, the GNN method can better capture complex call relationships and hidden code semantics. In addition, GNN is more adaptable when dealing with unknown code patterns, but its implementation depends on large-scale high-quality training data, and the computational costs of training and inference are relatively high.

[0011] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, the step of path profiling further includes: obtaining the method call graph of the application program based on the Soot framework, tracking the direct and indirect calls of the candidate methods to ensure that the camera-related APIs of the indirect calls can also be detected, and incorporating the traced calling methods into the path profiling step.

[0012] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, it further includes: detection report: outputting the screening results of the global method screening; outputting the detection results of the path profiling; outputting the verification results of the semantic verification; explaining whether the resource call logic in each path conforms to the semantic rules of the focus switching management; making a summary determination of the resource management ability of the application program and providing optimization suggestions.

[0013] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, the code parsing and preprocessing steps specifically include: using the configuration interface provided by the Soot framework, loading and parsing the .dex bytecode in the APK file, and converting it into Jimple representation; Jimple is a three-address code form that can accurately capture the control flow and data flow of the application; the parsing process extracts the class structure, method definition and calling relationship between methods of the application, generates a method list and a class dependency graph, so as to provide a semantic basis for subsequent path analysis and semantic analysis.

[0014] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, the step of global method screening specifically includes: method signature matching: checking whether the method name of each method is onWindowFocusChanged through static analysis, and verifying whether its parameter list contains the only Boolean type parameter booleanhasFocus; class inheritance relationship verification: checking whether the class to which the onWindowFocusChanged method belongs inherits from android.app.Activity or its derived class; method implementation positioning: for methods that meet the screening conditions, recording the method signature, class name and specific location, and providing input for the subsequent control flow graph analysis stage.

[0015] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, the API calls related to camera resource management include: openCamera, startCamera and android.hardware.Camera.open.

[0016] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, the step of analyzing whether the calling path and parameters comply with the correct resource management logic specifically includes: whether the correct camera device ID is passed; whether the call is in the hasFocus == true state; whether a permission check is performed before the call; if the judgment result of any of the above conditions is no, it is considered that the camera API does not comply with the correct resource management logic.

[0017] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, the step of analyzing whether the thread state and permission check logic of the call meet the normal use requirements of the camera API specifically includes: if a camera-related API call is detected in the control flow path, and the call logic is associated with focus switching management, it is determined that the candidate method can correctly manage camera resources; if no camera-related API call is detected in the control flow path, or the call logic is not related to focus switching management, it is considered that the candidate method has a risk of resource preemption.

[0018] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, a summary judgment is made on the resource management capability of the application program, and optimization suggestions are provided, specifically including: if a resource contention problem is detected, its impact scope and problem type are pointed out; targeted optimization suggestions are provided: adding resource management logic in the onWindowFocusChanged method, or supplementing the permission checking mechanism.

[0019] The second aspect of the present invention discloses a mobile application camera resource preemption detection system, comprising: a memory for storing program instructions; a processor for calling the program instructions stored in the memory to implement a mobile application camera resource preemption detection method such as any of the above technical solutions.

[0020] Compared with the prior art, the beneficial effects of the present invention include at least:

[0021] Existing technologies such as FlowDroid and LeakCanary, although they have certain reference value in their respective fields (such as data flow analysis or memory leak detection), do not focus on solving the problem of camera resource contention in multi-window mode. Especially in the focus switching scenario, this problem puts higher requirements on resource management logic. The present invention is the first detection technology that systematically pays attention to and solves this problem. It fills the gap in the existing technology through static analysis methods and provides an innovative solution for camera resource management in a multi-window environment.

[0022] The existing technology for parsing resource call paths mostly stays at data flow tracking or simple dynamic call analysis, lacking comprehensive coverage of key logical branches. The present invention uses an analysis technology that combines the construction of a control flow graph (CFG) and a call graph (CG) to fine-grainedly parse the execution path inside the method and trace multi-layer call chains to ensure that all operations related to camera resources can be accurately captured. This fine-grained path analysis exceeds the depth and accuracy of existing methods.

[0023] The existing technology is highly dependent on the application scenario. For example, LeakCanary requires runtime environment support and has weak adaptability to obfuscated code. The present invention innovatively implements consistency detection in obfuscated and non-obfuscated environments by utilizing the non-obfuscated characteristics of the Android system's life cycle callback method onWindowFocusChanged, ensuring the applicability of the detection technology in a variety of applications released in the actual market. In addition, the system is dynamically compatible with complex resource call logic in multi-task switching scenarios, achieving high adaptability to the actual development environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1A schematic flow chart of a method for detecting mobile application camera resource preemption according to an embodiment of the present invention is shown.

[0025] Figure 2 A schematic block diagram of a mobile application camera resource preemption detection system according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0026] In order to more clearly understand the above-mentioned purpose, features and advantages of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention can also be implemented in other ways different from those described herein, and therefore, the present invention is not limited to the limitations of the specific embodiments disclosed below.

[0027] With the increasing popularity of Android multi-window mode, the scenario of multiple applications running on the same screen at the same time has become mainstream. However, as an exclusive resource, the resource contention problem of the camera in multi-window mode has become increasingly prominent. This contention may cause abnormal camera functions, such as the camera cannot be started, the use is interrupted, or it fails to recover correctly when the focus is switched, which seriously affects the user experience and the stability of the application function. However, the current technical means have not yet provided effective detection and solutions for this specific problem. In order to solve the above problems, the present invention proposes an innovative technical solution based on static analysis (mobile application camera resource preemption detection method). Through the deep analysis of Android application code and the comprehensive analysis of control flow logic, the present invention can detect the potential risks of camera resource preemption problems in a multi-window environment, and provide developers with targeted optimization suggestions, thereby effectively filling the gap in the prior art and significantly improving the stability and user experience of applications in multi-window mode. The overall architecture of the present invention is shown in the figure, which consists of the following four modules: code parsing and preprocessing, global method screening, critical path control flow analysis, and detection report generation. These modules work together to achieve full-process automated static analysis from input APK files to output detection results.

[0028] like Figure 1 As shown, according to an embodiment of the present invention, a method for detecting resource preemption of a mobile application camera is disclosed, comprising:

[0029] Step S1, code parsing and preprocessing: statically parse the APK file of the application through the Soot framework to extract the method list of the application;

[0030] Step S2, global method screening: determine the onWindowFocusChanged method as the target method, traverse all method definitions in the method list, compare the method name and parameter signature one by one to see if they match the target method. If no method matching the target method can be detected, it is determined that the application cannot correctly manage camera resources. If a method matching the target method is detected, mark the matching method as a candidate method and output detailed information of the candidate method for subsequent analysis.

[0031] Step S3, path analysis: build a complete control flow graph for each candidate method based on the Soot framework; traverse all paths in the control flow graph, detect whether the path contains API calls related to camera resource management, and detect whether there are logical judgment omissions or logical errors in the logical branches of conditional statements in the path; obtain the method call graph of the application based on the Soot framework, track the direct and indirect calls of the candidate methods, ensure that the camera-related APIs that are indirectly called can also be detected, and include the tracked calling methods in the path analysis step (treat the tracked calling methods as candidate methods for the above detection);

[0032] Step S4, semantic verification: introduce semantic verification mechanism, build API call point context, track the call path and parameters of each camera API, analyze whether the call path and parameters conform to the correct resource management logic, analyze whether the thread state and permission check logic of the call meet the normal use requirements of the camera API; mark the camera API that does not conform to the resource management logic, has abnormal thread state or abnormal permission check logic as a potential problem point;

[0033] Step S5, detection report: output the screening results of global method screening; output the detection results of path analysis; output the verification results of semantic verification; explain whether the resource call logic in each path complies with the semantic rules of focus switching management; make a summary judgment on the resource management capabilities of the application and provide optimization suggestions.

[0034] In this embodiment, by combining the control flow graph (CFG) with the call graph of the candidate method, a deep analysis from code structure to resource management logic is achieved. For the core life cycle method onWindowFocusChanged in the multi-window focus switching scenario, the resource call relationship in the control flow path is parsed one by one, and the indirect call chain is tracked in combination with the call graph to ensure that the call path of the camera-related API is fully covered. Context-sensitive analysis technology is introduced, and a deep semantic verification mechanism for camera API calls is designed. By tracking the context conditions, parameter transfer path and logical branch status of API calls, it is possible to dynamically verify whether the call meets the semantic rules of focus switching management. For example, for the openCamera method, it is verified whether its call is in the logical branch of focus acquisition, whether valid parameters are passed, and whether the permission verification logic is complete. This mechanism effectively avoids the common misjudgment and missed judgment problems in traditional static analysis. Taking full advantage of the non-confusing characteristics of the onWindowFocusChanged method as the standard callback method of the Android system, a detection technology suitable for both obfuscated and non-obfuscated environments is designed. Through static semantic analysis and method feature matching, this technology can detect open source applications and market applications obfuscated by R8 or ProGuard, adapt to diverse application release scenarios, and ensure the robustness and wide applicability of the detection results.

[0035] According to another embodiment of the present invention, a specific implementation process and working principle of the mobile application camera resource preemption detection method provided in the above embodiment are also disclosed:

[0036] 1. Code parsing and preprocessing based on soot framework:

[0037] First, in the code parsing and preprocessing stage, the present invention statically parses the input APK file through the Soot framework to build the intermediate representation (IR) of the application. Specifically, the configuration interface provided by Soot is used to load and parse the .dex bytecode in the APK file and convert it into a Jimple representation. Jimple is a three-address code form with good readability and structured characteristics, and can accurately capture the control flow (Control Flow) and data flow (Data Flow) of the application. The parsing process extracts the class structure, method definition and its calling relationship of the application, generates a method list and a class dependency graph, and provides a comprehensive semantic basis for subsequent control flow analysis and path detection. Through this efficient static parsing process, the system can have a deep semantic understanding of the code structure of the application, laying a solid foundation for the subsequent detection process.

[0038] 2. Global method screening:

[0039] After completing the code analysis, the system enters the method-level key callback screening phase, with the goal of accurately locating the core lifecycle callback method onWindowFocusChanged that is closely related to the multi-window mode. As an important interface in the Android application lifecycle management, onWindowFocusChanged plays a vital role in detecting window focus changes. When the application window gains user focus, this method is automatically triggered, allowing developers to execute key resource management logic, such as releasing or reallocating exclusive resources (such as the camera). With the widespread application of Android multi-window mode, the traditional onResume method is no longer reliably triggered in the focus switching scenario, and onWindowFocusChanged has therefore become a key interface for resource scheduling and focus switching management in a multi-window environment. However, many existing applications fail to implement this method correctly, or the implementation logic is missing, resulting in frequent problems such as camera resource contention, functional failure, and even abnormal operation in multi-task interaction scenarios.

[0040] It is worth emphasizing that onWindowFocusChanged is a standard callback method provided by the Android system, so it will not be renamed or modified by R8 or ProGuard tools during the application code obfuscation process. This feature ensures that the detection technology of the present invention can be applied to open source applications and obfuscated market applications, and has wide applicability and robustness. In the method screening stage, the system screens all methods extracted from the code one by one through static semantic analysis and feature matching. The specific process is as follows:

[0041] In the global method screening phase, the system first traverses all method definitions extracted in the code parsing phase, and compares their method names and parameter signatures one by one to see if they match onWindowFocusChanged. Specifically, this phase is divided into the following steps:

[0042] (1) Method signature matching:

[0043] The system uses static analysis to check whether the name of each method is onWindowFocusChanged, and whether its parameter list contains the only Boolean parameter boolean hasFocus. This preliminary screening process can quickly filter out most irrelevant methods.

[0044] (2) Verification of class inheritance relationship:

[0045] To further confirm the validity of the method, the system checks whether the class to which the onWindowFocusChanged method belongs is inherited from android.app.Activity or its derived classes. Since onWindowFocusChanged is a lifecycle callback method, only methods defined in the Activity class and its subclasses have practical significance. If the class to which the method belongs does not satisfy the inheritance relationship, it is directly excluded.

[0046] (3) Method to achieve positioning:

[0047] For methods that meet the screening criteria, the system records their method signatures, class names, and specific locations to provide input for the subsequent control flow graph analysis phase. At the same time, the system deduplicates the results to avoid redundancy caused by overloading or repeated definitions.

[0048] (4) Result judgment and output:

[0049] If no qualifying onWindowFocusChanged method is found in the target application, the system directly determines that the application cannot properly manage camera resources in a multi-window environment and there is a risk of resource preemption; if at least one matching method is found, it is marked as a candidate method and its detailed information is output as the basis for subsequent analysis.

[0050] Through the screening at this stage, the system can quickly determine whether the target application implements the onWindowFocusChanged method, thereby preliminarily evaluating whether it has the ability to manage focus switching in a multi-window environment. This design not only ensures the efficiency of the detection process, but also provides precise directional guidance for the control flow analysis phase. Finally, the results of the global method screening phase are output in the form of structured data, recording the basic information of the target method and its code location, laying the foundation for subsequent in-depth analysis.

[0051] 3. Critical path analysis:

[0052] For the selected target methods (candidate methods), the system enters the critical path analysis phase and conducts an in-depth analysis of the resource call logic in the target method onWindowFocusChanged. As a key callback in the focus switching scenario, the internal resource management logic of the onWindowFocusChanged method directly determines the correctness and stability of camera resources in a multi-window environment. In order to fully capture all resource operations within the method and related calls, the system uses a variety of technical means such as control flow graph analysis, path traversal, and call graph expansion for comprehensive analysis.

[0053] First, the system uses the control flow graph (CFG) generation module provided by Soot to build a complete control flow graph for each target method. The control flow graph is a structured expression of the method logic. The nodes represent the basic blocks of the program, and the edges represent the execution flow relationship between the basic blocks. Through the construction of the control flow graph, the system can clearly express the execution path and conditional branch logic within the method, thus laying the foundation for subsequent path detection.

[0054] In the path traversal phase, the system traverses all paths in the control flow graph one by one, focusing on detecting whether the path contains API calls related to camera resource management, including openCamera, startCamera, and android.hardware.Camera.open, etc. These APIs are the core operations for initializing, releasing, or reallocating camera resources. These calls are crucial in focus switching scenarios and can indicate whether the method executes the correct resource management logic. At the same time, the system pays special attention to the logical branches of conditional statements in the path, such as whether the hasFocus parameter is correctly logically judged (such as if (hasFocus) {...}). If this judgment is missing or logically incorrect, the camera resources may not be correctly allocated or released during focus switching.

[0055] In addition, the system further expands the scope of analysis by combining the method call graph (CG). The method call graph is a graph structure of the calling relationship between methods, in which each node represents a method and the edge represents the calling relationship between methods. In the call graph analysis, the system tracks all direct and indirect calls to onWindowFocusChanged to ensure that indirectly called camera-related APIs can also be detected. For example, if the target method calls the tool method manageCamera(), which contains the actual camera resource management logic, the system can include these logics in the detection scope through call graph analysis.

[0056] 4. Semantic Verification:

[0057] To further improve the accuracy of detection, the system introduces a semantic verification mechanism, combined with context-sensitive analysis, to deeply verify resource calls in the control flow path. Context-sensitive analysis builds a call point context to track the call path and parameter sources of each camera API to ensure the accuracy of the analysis results. For example, the system checks whether a valid camera ID parameter is provided when calling openCamera or startCamera, and verifies whether the call is in a logical context related to focus switching. In addition, the system also analyzes the thread state and permission check logic of the call to ensure that the call meets the normal use requirements of the API.

[0058] During parameter verification, the system will focus on checking the call to openCamera:

[0059] (1) Whether the correct camera device ID is passed;

[0060] (2) Whether the call is in the judgment branch where hasFocus == true;

[0061] (3) Whether permission check (such as checkCameraPermission()) was performed before calling.

[0062] By combining context-sensitive analysis with the above validation rules, the system can ensure that each call complies with the correct resource management logic. For calls that do not meet the conditions, the system will mark them as potential problem points.

[0063] In the detection logic judgment phase, the system evaluates the resource management capabilities of the target method based on the comprehensive results of path traversal and call graph analysis. The specific judgment rules include:

[0064] (1) If a camera-related API call is detected in the control flow path, and the call logic is associated with focus switching scenarios such as hasFocus parameter judgment, the system determines that the target method can correctly manage camera resources.

[0065] (2) If no critical API call is detected, or the call logic is not related to focus switching management, it is considered that the target method does not properly handle resource management and there is a risk of resource preemption.

[0066] 5. Test report:

[0067] During the test report generation phase, the system presents the test results in the form of structured data. The test report content includes the following core parts:

[0068] (1) Basic application information:

[0069] Record the basic information of the target application, including: APK file name: used to identify the target file currently being tested. Application package name and version number: uniquely identify the version and namespace of the application. Detection time: indicates the specific time when the detection task is executed, so that developers can track and trace the problem.

[0070] (2) Global method screening results:

[0071] Lists whether the target application implements the onWindowFocusChanged method. For detected target methods, the report provides the following information:

[0072] Method signature and class name.

[0073] The result of verifying the inheritance relationship of the method (such as whether it is inherited from android.app.Activity).

[0074] The code location of the method (file path and line number).

[0075] (3) Critical path analysis results:

[0076] The control flow graph analysis and call graph extended analysis results of the target method are reported in detail:

[0077] Control flow graph summary: includes the number of control flow paths, number of logic branches, etc.

[0078] Path resource call detection: lists the camera-related API calls (such as openCamera) detected in each path and marks the specific location of the call point.

[0079] Call graph tracing results: record the direct and indirect call relationships of the target method, and indicate the indirectly called camera API and its call chain.

[0080] (4) Semantic verification and logical evaluation:

[0081] The report details whether the resource call logic in each path complies with the semantic rules of focus switching management, including:

[0082] Whether the resource initialization method (such as openCamera) is called in the hasFocus == true branch.

[0083] Are resources released correctly in the focus-lost logic branch (such as camera.close).

[0084] Whether to complete permission verification before calling.

[0085] (5) Final test conclusion and optimization suggestions:

[0086] Based on the test results, a summary judgment is made on the resource management capabilities of the target application, and optimization suggestions are provided:

[0087] If a resource contention problem is detected, indicate its scope and the type of problem (e.g., missing resource initialization, improper resource release).

[0088] Provide targeted optimization suggestions, such as adding resource management logic to the onWindowFocusChanged method, or supplementing the permission check mechanism.

[0089] Through the above structured report output, the system not only helps developers quickly locate problems, but also provides a clear technical basis for optimizing application functions. In addition, the automated report generation process ensures that high-quality test results are output immediately after each test task is completed, greatly improving development efficiency and problem-solving capabilities.

[0090] like Figure 2 As shown, according to another embodiment of the present invention, a mobile application camera resource preemption detection system 200 is also disclosed, including: a memory 201, used to store program instructions; a processor 202, used to call the program instructions stored in the memory to implement the mobile application camera resource preemption detection method as described in the above embodiment.

[0091] In summary, the present invention is based on static analysis technology, and is aimed at the problem of camera resource preemption in Android multi-window mode. It can quickly detect potential conflicts in resource management in the application development stage, and avoid the problems of camera function being unable to start, operation interruption or multi-task switching abnormality due to resource preemption. The present invention significantly improves the comprehensiveness and pertinence of resource management, and makes up for the defects of the prior art. The present invention conducts in-depth analysis of the control flow of the key callback method to detect whether there is a camera API call in its logical path. With the help of control flow analysis technology, the present invention can cover all possible resource call paths in the multi-window mode without relying on the actual operating environment and usage scenarios, so as to discover problems in advance in the development stage, reduce the repair cost caused by the exposure of problems after going online, and ensure user experience and system stability. Compared with the problem that dynamic detection requires manual construction of scenes and is limited by equipment performance, the present invention adopts an automated static analysis method to greatly improve detection efficiency and reduce manual testing costs. At the same time, the automatically generated analysis report provides a clear location of the problem code, helping developers to quickly locate and solve problems, significantly shortening the development cycle and improving the scale detection capability of application development.

[0092] All or part of the steps in the various methods of the above embodiments can be completed by controlling the relevant hardware through a program, and the program can be stored in a readable storage medium, and the storage medium includes a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically erasable programmable read-only memory (EEPROM), a compact disc (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other readable medium that can be used to carry or store data.

[0093] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for detecting mobile application camera resource preemption, characterized in that: include: Code parsing and preprocessing: Use the Soot framework to statically parse the APK file of the application to extract the method list of the application; Global method screening: determine the onWindowFocusChanged method as the target method, traverse all method definitions in the method list, compare the method name and parameter signature one by one to see if they match the target method. If no method matching the target method is detected, it is determined that the application cannot correctly manage camera resources. If a method matching the target method is detected, the matching method is marked as a candidate method and the detailed information of the candidate method is output for subsequent analysis. Path analysis: Build a complete control flow graph for each candidate method based on the Soot framework; traverse all paths in the control flow graph, detect whether the path contains API calls related to camera resource management, and detect whether there are logical judgment missing or logical errors in the logical branches of conditional statements in the path; Semantic verification: Introduce a semantic verification mechanism to build the API call point context, track the call path and parameters of each camera API, analyze whether the call path and parameters comply with the correct resource management logic, and analyze whether the thread status and permission check logic of the call meet the normal use requirements of the camera API; mark the camera API that does not comply with the resource management logic, has abnormal thread status, or has abnormal permission check logic as a potential problem point.

2. The method for detecting mobile application camera resource preemption according to claim 1, characterized in that: The path analysis step further includes: Based on the Soot framework, the method call graph of the application is obtained, and the direct and indirect calls of the candidate methods are tracked to ensure that the indirectly called camera-related APIs can also be detected, and the tracked calling methods are also included in the path analysis step.

3. The method for detecting mobile application camera resource preemption according to claim 1, characterized in that: Also includes: Test report: output the screening results of global method screening; Output the detection results of path analysis; Output the verification result of semantic verification; Explain whether the resource call logic in each path complies with the semantic rules of focus switching management; make a summary judgment on the resource management capabilities of the application and provide optimization suggestions.

4. The method for detecting mobile application camera resource preemption according to claim 1, characterized in that: The steps of code parsing and preprocessing specifically include: Using the configuration interface provided by the Soot framework, the .dex bytecode in the APK file is loaded and parsed and converted into Jimple representation; Jimple is a three-address code form that can accurately capture the control flow and data flow of the application; the parsing process extracts the application's class structure, method definition, and calling relationship between methods, and generates a method list and class dependency graph to provide a semantic basis for subsequent path analysis and semantic analysis.

5. The method for detecting mobile application camera resource preemption according to claim 1, characterized in that: The steps of global method screening specifically include: Method signature matching: Check each method’s name one by one through static analysis to see if it is onWindowFocusChanged, and verify if its parameter list contains the only Boolean parameter booleanhasFocus; Verify the class inheritance relationship: Check whether the class to which the onWindowFocusChanged method belongs inherits from android.app.Activity or its derived classes; Method implementation location: For methods that meet the screening criteria, record the method signature, class name, and specific location to provide input for the subsequent control flow graph analysis phase.

6. The method for detecting mobile application camera resource preemption according to claim 1, characterized in that: API calls related to camera resource management include: openCamera, startCamera, and android.hardware.Camera.open.

7. The method for detecting mobile application camera resource preemption according to claim 1, characterized in that: The step of analyzing whether the calling path and parameters conform to the correct resource management logic specifically includes: Whether the correct camera device ID is passed; Whether the call is in the state of hasFocus == true; Whether permission check is performed before calling; If the result of any of the above conditions is no, it is considered that the camera API does not comply with the correct resource management logic.

8. The method for detecting mobile application camera resource preemption according to claim 1, characterized in that: The step of analyzing whether the thread state and permission check logic of the call meet the normal use requirements of the camera API specifically includes: If a camera-related API call is detected in the control flow path, and the call logic is associated with focus switching management, it is determined that the candidate method can correctly manage camera resources; If no camera-related API calls are detected in the control flow path, or the calling logic is not related to focus switching management, the candidate method is considered to have a resource preemption risk.

9. The method for detecting mobile application camera resource preemption according to claim 2, characterized in that: The steps of summarizing the resource management capability of the application and providing optimization suggestions specifically include: If resource contention issues are detected, indicate the scope and type of issues; Provide targeted optimization suggestions: add resource management logic to the onWindowFocusChanged method, or supplement the permission check mechanism.

10. A mobile application camera resource preemption detection system, characterized in that: include: A memory for storing program instructions; A processor, configured to call the program instructions stored in the memory to implement the mobile application camera resource preemption detection method as described in any one of claims 1 to 9.

Images