Mobile Application Camera Resource Preemption Detection Method and System

Abstract

The present invention provides a method and system for detecting camera resource preemption in mobile applications, which relates to software engineering and includes: statically parsing the APK file of the application through the Soot framework; determining the target method, traversing all method definitions in the method list, comparing whether the method signature matches the target method, and marking the matched method as a candidate method; obtaining the control flow graph of the candidate method, traversing all paths in the control flow graph, detecting whether the paths contain API calls related to camera resource management, and detecting whether there are missing logical judgments or logical errors in the logical branches of the conditional statements in the paths; marking the camera APIs that do not conform to the resource management logic, have abnormal thread states, or have abnormal permission check logics as potential problem points. The present invention can accurately detect camera resource preemption problems in a multi-window environment, helps to discover potential risks, and fills the gap in the prior art.

Description

Technical Field

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

[0002] In mobile application development, the multi-window mode has become an important feature of the Android operating system. This mode allows users to run multiple applications simultaneously on the same screen, greatly improving the efficiency of multitasking and the 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, when multiple applications request to use the camera simultaneously in the multi-window mode, resource conflict problems are likely to occur. Common phenomena include the failure to successfully start the camera function, the interruption of the camera function during operation due to resource requests from other applications, and abnormal functions caused by the failure to correctly release or reapply resources during multitasking switching. These problems not only directly affect the user experience but may even render some functions of the application completely unavailable, thus severely weakening the practical usability of the multi-window mode. To further adapt to the multi-window mode, the Android official has adjusted the behavior of application lifecycle methods since Android 10. In the multi-window mode, multiple applications can be in the "Resumed" state simultaneously, but in fact, the focus only belongs to one of them. This means that the onResume() method can no longer accurately reflect whether the application has obtained the focus, and this method will not be re-triggered during focus switching. However, most developers have not noticed this change in the lifecycle behavior. Many developers still bind the initialization and release logic of camera resources to the traditional onResume() and onPause() methods, which fails to meet the focus switching requirements of the multi-window mode and further exacerbates the camera resource management problem. The resource preemption problem brought about by this update has significantly increased the complexity of application development in the multi-window mode and also raised higher requirements for the stability and user experience of applications.

[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 handle the problem of camera resource preemption in the multi-window mode proposed by the present invention. However, some solutions with similar technical directions to 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 judge the usage of sensitive data; dynamic detection tools such as LeakCanary monitor the memory usage at runtime to help developers discover and solve memory leakage problems. Although these technologies have certain reference values in their respective application fields, they cannot be directly applied to the detection scenario of exclusive resource preemption in the multi-window mode. The application scope of the prior art is usually limited to specific problem domains. Taking FlowDroid as an example, this tool focuses on the tracking of privacy data flow and can conduct a detailed analysis of the data flow in the code, but lacks in-depth support for the control flow and logical paths of callback methods 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 certain references in their respective directions, they do not solve the detection requirements for the problem of camera resource preemption in the multi-window mode. These deficiencies are mainly reflected in: 1. Unable to cover complex management scenarios of exclusive resources; 2. Limited ability to analyze the control flow of multitask switching and key callback methods; 3. Lack of targeted support for problems specific to the multi-window mode.

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

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

[0006] The first aspect of the present invention discloses a method for detecting the preemption of camera resources in a mobile application, including: code parsing and preprocessing: statically parsing the APK file of the application through the Soot framework to extract the method list of the application; global method screening: determining the onWindowFocusChanged method as the target method, traversing all method definitions in the method list, and comparing the method signatures one by one with the target method. If no method matching the target method can be detected, it is determined that the application cannot correctly manage the 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 profiling: constructing a complete control flow graph for each candidate method based on the Soot framework; traversing all paths in the control flow graph, detecting whether the paths contain API calls related to camera resource management, and detecting whether there are missing logical judgments or logical errors in the logical branches of the conditional statements in the paths; semantic verification: introducing a semantic verification mechanism, constructing the call point context of the API, tracing the call paths and parameters of each camera API, analyzing whether the call paths and parameters conform to the correct resource management logic, and analyzing whether the thread state and permission check logic where the call is located meet the normal usage requirements of the camera API; marking the camera APIs that do not conform to the resource management logic, have abnormal thread states, or have abnormal permission check logics as potential problem points.

[0007] In this technical solution, the Soot framework is a Java optimization framework mainly used for analyzing and transforming Java bytecode. The APK (Android application package) file is the installation package file of an Android application. The onWindowFocusChanged method is a standard callback method provided by the Android system and 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 market applications that have been obfuscated, with wide applicability and robustness. In the multi-window mode, multiple applications can be in the "resumed" 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, it observes 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 by the present invention, preferably, the steps of code parsing and preprocessing specifically include: using the configuration interface provided by the Soot framework to load and parse the.dex bytecode in the APK file and convert it into Jimple representation; Jimple is a three-address code form that can accurately capture the control flow and data flow of the application program; the parsing process extracts the class structure, method definitions, and call relationships between methods of the application program, generating a method list and a class dependency graph to provide a semantic basis for subsequent path profiling and semantic verification.

[0014] According to the mobile application camera resource preemption detection method disclosed by the present invention, preferably, the steps of global method screening specifically include: method signature matching: checking one by one through static analysis whether the method name of each method is onWindowFocusChanged, and at the same time verifying whether its parameter list contains the only boolean type parameter boolean hasFocus; verification of class inheritance relationship: checking 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 conditions, record the method signature, class name, and specific location to provide input for the subsequent control flow graph analysis stage.

[0015] According to the mobile application camera resource preemption detection method disclosed by 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 by the present invention, preferably, the steps of analyzing whether the call path and parameters conform to the correct resource management logic specifically include: whether the correct camera device ID is passed; whether the call is in the state of hasFocus == true; whether permission verification is performed before the call; if the judgment result of any of the above conditions is negative, it is considered that the camera API does not conform to the correct resource management logic.

[0017] According to the mobile application camera resource preemption detection method disclosed by the present invention, preferably, the steps of analyzing whether the call path and parameters conform to the correct resource management logic further include: if a camera-related API call is detected in the control flow path and the call logic is associated with focus switch management, it is determined that the candidate method can correctly manage camera resources; if a camera-related API call is not detected in the control flow path, or the call logic has nothing to do with focus switch management, it is considered that the candidate method has a resource preemption risk.

[0018] According to the mobile application camera resource preemption detection method disclosed in the present invention, preferably, the step of making a summary determination of the resource management ability of the application program and providing optimization suggestions specifically includes: if a resource contention problem is detected, pointing out its scope of influence and problem type; providing targeted optimization suggestions: adding resource management logic in the onWindowFocusChanged method, or supplementing the permission check mechanism.

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

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

[0021] Prior arts such as FlowDroid and LeakCanary have certain reference values in their respective fields (such as data flow analysis or memory leak detection), but do not focus on solving the problem of camera resource contention in the multi-window mode. Especially in the focus switching scenario, this problem poses higher requirements for the resource management logic. The present invention is the first detection technology that systematically focuses on and solves this problem, filling the gap in the prior art through static analysis means, and providing an innovative solution for camera resource management in the multi-window environment.

[0022] The prior art's parsing of the resource call path mostly stays at data flow tracing or simple dynamic call analysis, lacking comprehensive coverage of key logical branches. The present invention constructs an analysis technology that combines a control flow graph (CFG) and a call graph (CG), finely parses the execution path inside the method, and traces 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 the prior methods.

[0023] The prior art has a strong dependence on the application scenario. For example, LeakCanary requires a runtime environment support and has weak adaptability to obfuscated code. The present invention innovatively realizes consistent detection in obfuscated and non-obfuscated environments by utilizing the non-obfuscated characteristic of the Android system's lifecycle callback method onWindowFocusChanged, ensuring the applicability of the detection technology in a variety of applications released in the actual market. In addition, the system dynamically adapts to the complex resource call logic in the multi-task switching scenario, achieving high adaptability to the actual development environment. Brief Description of the Drawings

[0024] Figure 1The flowchart shows a method for detecting camera resource preemption in a mobile application according to an embodiment of the present invention.

[0025] Figure 2 The schematic block diagram shows a system for detecting camera resource preemption in a mobile application according to an embodiment of the present invention. Detailed implementation manners

[0026] In order to more clearly understand the above objects, features and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation manners. Many specific details are set forth in the following description in order to fully understand the present invention. However, the present invention may also be implemented in other ways different from those described herein. Therefore, the present invention is not limited by the limitations of the specific embodiments disclosed below.

[0027] With the increasing popularity of the Android multi-window mode, the scenario of multiple applications running simultaneously on the same screen has become mainstream. However, as an exclusive resource, the resource contention problem of the camera in the multi-window mode has become increasingly prominent. This contention may lead to abnormal camera functions, such as the camera being unable to start, the use being interrupted, or not being correctly restored when the focus is switched, thus seriously affecting the user experience and the stability of the application function. However, the current technical means have not provided an effective detection and solution for this specific problem. To solve the above problems, the present invention proposes an innovative technical solution (a method for detecting camera resource preemption in a mobile application) based on static analysis. By deeply analyzing the Android application code and comprehensively analyzing the control flow logic, the present invention can detect the potential risks of camera resource preemption problems in a multi-window environment and provide targeted optimization suggestions for developers, thus effectively filling the gap in the existing technology and significantly improving the stability of applications and the user experience in the multi-window mode. The overall architecture of the present invention 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 the full-process automated static analysis from the input APK file to the output detection results.

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

[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 and compare the method signatures with the target method one by one. 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 the detailed information of the candidate method for subsequent analysis;

[0031] Step S3, Path profiling: 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 missing logical judgments or logical errors in the logical branches of conditional statements in the path; Based on the Soot framework, obtain the method call graph of the application, trace the direct and indirect calls of the candidate method to ensure that indirectly called camera-related APIs can also be detected, and include the traced calling methods in the path profiling step (use the traced calling methods as candidate methods for the above detection);

[0032] Step S4, Semantic verification: Introduce a semantic verification mechanism. By constructing the call point context of the API, trace the call path and parameters of each camera API, and analyze whether the call path and parameters conform to the correct resource management logic, and analyze whether the thread state and permission check logic where the call is located meet the normal usage requirements of the camera API; Mark the camera APIs that do not conform to the resource management logic, have abnormal thread states, or have abnormal permission check logics as potential problem points;

[0033] Step S5, Detection report: Output the screening results of global method screening; Output the detection results of path profiling; Output the verification results of semantic verification; Explain whether the resource call logic in each path conforms to the semantic rules of focus switching management; Make a summary determination of the application's resource management ability and provide optimization suggestions.

[0034] In this embodiment, by combining the control flow graph (CFG) with the call graph of the candidate method, in-depth analysis from the code structure to the resource management logic is achieved. For the core lifecycle method onWindowFocusChanged in the multi-window focus switching scenario, the resource call relationships in the control flow path are parsed one by one, and at the same time, the indirect call chain is traced in combination with the call graph to ensure comprehensive coverage of the call paths of the camera-related APIs. The context-sensitive analysis technology is introduced, and a deep semantic verification mechanism for camera API calls is designed. By tracing the context conditions, parameter passing paths, and logical branch states of API calls, it is possible to dynamically verify whether the calls meet the semantic rules of focus switching management. For example, for the openCamera method, verify whether its call is in the logical branch of focus acquisition, whether valid parameters are passed, and check whether the permission verification logic is complete. This mechanism effectively avoids the common misjudgment and missed judgment problems in traditional static analysis. Making full use of the non-confusable feature of the onWindowFocusChanged method as a standard callback method in the Android system, a detection technology applicable to both obfuscated and non-obfuscated environments is designed. Through static semantic verification and method feature matching, this technology can be compatible with detecting 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 the Soot framework:

[0037] First, in the code parsing and preprocessing stage, the present invention performs static parsing on the input APK file through the Soot framework to construct the intermediate representation (IR) of the application. Specifically, using the configuration interface provided by Soot, the.dex bytecode in the APK file is loaded and parsed, and converted into Jimple representation. Jimple is a three-address code form with good readability and structural characteristics, which can accurately capture the control flow and data flow of the application program. The parsing process extracts the class structure, method definitions, and their call relationships of the application program, generates a method list and a class dependency graph, providing a comprehensive semantic basis for subsequent control flow analysis and path detection. Through this efficient static parsing process, the system can deeply semantically understand the code structure of the application program, laying a solid foundation for the subsequent detection process.

[0038] 2. Global method screening:

[0039] After the code parsing is completed, the system enters the method-level key callback screening stage. The goal is to accurately locate the core lifecycle callback method onWindowFocusChanged that is closely related to the multi-window mode. As an important interface in Android application lifecycle management, onWindowFocusChanged plays a crucial 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 cameras). With the widespread application of the Android multi-window mode, the traditional onResume method is no longer reliably triggered in focus switching scenarios. Therefore, onWindowFocusChanged has become a key interface for resource scheduling and focus switching management in the multi-window environment. However, many existing applications fail to correctly implement this method, or there are deficiencies in the implementation logic, resulting in frequent problems such as camera resource contention, function 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 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 market applications that have been obfuscated, with broad applicability and robustness. In the method screening stage, the system screens all methods extracted from the code one by one through static semantic verification and feature matching. The specific process is as follows:

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

[0042] (1)Method signature matching:

[0043] The system checks whether the name of each method is onWindowFocusChanged through static analysis one by one, and at the same time verifies whether its parameter list contains the only boolean type parameter boolean hasFocus. This preliminary screening process can quickly filter out the vast majority of irrelevant methods.

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

[0045] To further confirm the effectiveness of the method, the system checks whether the class to which the onWindowFocusChanged method belongs inherits 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 where the method is located does not meet the inheritance relationship, it is directly excluded.

[0046] (3)Method implementation location:

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

[0048] (4)Result judgment and output:

[0049] If no eligible onWindowFocusChanged method is found in the target application, the system directly determines that the application cannot correctly 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 in this stage, the system can quickly determine whether the target application has implemented the onWindowFocusChanged method, thereby preliminarily evaluating its ability to manage focus switching in a multi-window environment. This design not only ensures the efficiency of the detection process but also provides an accurate directional guidance for the control flow analysis phase. Finally, the results of the global method screening stage are output in the form of structured data, recording the basic information of the target method and its code location, laying a foundation for subsequent in-depth analysis.

[0051] 3. Critical path analysis:

[0052] For the selected target method (candidate method), the system enters the critical path analysis stage to deeply analyze the resource call logic in the onWindowFocusChanged method. 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. To comprehensively capture all resource operations inside the method and related calls, the system sequentially uses various technical means such as control flow graph analysis, path traversal, and call graph expansion for comprehensive parsing.

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

[0054] In the path traversal stage, the system traverses all paths in the control flow graph one by one, with a focus on detecting whether the paths contain 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 the focus switch scenario and can indicate whether the method has executed the correct resource management logic. At the same time, the system pays special attention to the logical branches of conditional statements in the paths, such as whether the correct logical judgment is made on the hasFocus parameter (e.g., if (hasFocus) {...}). If this judgment is missing or logically incorrect, it may lead to the incorrect allocation or release of camera resources during focus switching.

[0055] In addition, the system further expands the analysis scope by combining the call graph (CG). The call graph is a graph structure of inter-method call relationships, where each node represents a method and edges represent the call relationships between methods. In call graph analysis, the system traces 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 utility method manageCamera(), which contains the actual camera resource management logic, the system can include this logic 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. Combining context-sensitive analysis, it deeply verifies the resource calls in the control flow paths. Context-sensitive analysis constructs the call point context, traces the call paths of each camera API and the sources of their parameters, ensuring the accuracy of the analysis results. For example, the system checks whether a valid camera ID parameter is provided when making an openCamera or startCamera call and verifies whether the call is in the logical context related to focus switching. In addition, the system also analyzes the thread state and permission check logic where the call is located to ensure that the call meets the normal usage requirements of the API.

[0058] During the parameter verification process, the system's call to openCamera will focus on detecting:

[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 verification (such as checkCameraPermission()) is performed before the call.

[0062] By combining context-sensitive analysis and the above verification 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 determination phase, the system evaluates the resource management ability of the target method based on the comprehensive results of path traversal and call graph analysis. The specific determination 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 the hasFocus parameter judgment, the system determines that the target method can correctly manage camera resources.

[0065] (2) If a key API call is not detected, or the call logic has nothing to do with focus switching management, it is considered that the target method does not correctly handle resource management and there is a risk of resource preemption.

[0066] 5. Detection Report:

[0067] In the detection report generation stage, the system presents the detection results in the form of structured data. The content of the detection report includes the following core parts:

[0068] (1) Application basic information:

[0069] Record the basic information of the target application, including: APK file name: Used to identify the target file of the current detection. Application package name and version number: Uniquely identify the version and namespace of the application. Detection time: Indicate the specific time when the detection task is executed for developers to track and trace problems.

[0070] (2) Global method screening results:

[0071] List whether the target application has implemented the onWindowFocusChanged method. For the detected target methods, the report provides the following information:

[0072] Method signature and class name where it is located.

[0073] Verification results of the inheritance relationship of methods (such as whether it inherits from android.app.Activity).

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

[0075] (3) Critical path analysis results:

[0076] Analysis results of the control flow graph and call graph expansion for the target method, with detailed reports recorded:

[0077] Summary of the control flow graph: including the number of control flow paths, the number of logical branches, etc.

[0078] Path resource call detection: list the camera-related API calls (such as openCamera) detected in each path, and mark 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 conforms to 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] Whether the resources are correctly released in the logical branch where the focus is lost (such as camera.close).

[0084] Whether permission verification is completed before the call.

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

[0086] Based on the detection results, make a summary judgment on the resource management ability of the target application and provide optimization suggestions:

[0087] If a resource contention problem is detected, point out its scope of influence and problem type (such as missing resource initialization, improper resource release).

[0088] Provide targeted optimization suggestions, such as adding resource management logic in 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 clear technical basis for the functional optimization of the application. In addition, the automated report generation process can ensure the immediate output of high-quality detection results after each detection task is completed, greatly improving the development efficiency and problem-solving ability.

[0090] As Figure 2 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 for storing program instructions; a processor 202 for calling 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, based on static analysis technology, the present invention addresses the problem of camera resource preemption in the Android multi-window mode. It can quickly detect potential conflicts in resource management during the application development stage, avoiding problems such as the camera function being unable to start, running interrupted, or abnormal multitasking switching due to resource preemption. The present invention significantly improves the comprehensiveness and pertinence of resource management, making up for the deficiencies of the prior art. By deeply analyzing the control flow of key callback methods, the present invention detects whether there are camera API calls in their logical paths. 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 running environment and usage scenarios, thus discovering problems in advance during the development stage, reducing the repair costs caused by problem exposure after going online, and ensuring user experience and system stability. Compared with dynamic detection, which requires manual construction of scenarios and is limited by device performance, etc., the present invention adopts an automated static analysis method, greatly improving the detection efficiency and reducing the manual testing cost. At the same time, the automatically generated analysis report provides the location of the problem code, helping developers quickly locate and solve problems, significantly shortening the development cycle and improving the large-scale detection ability of application development.

[0092] All or part of the steps in the various methods of the above embodiments can be completed by controlling related hardware through a program, and the program can be stored in a readable storage medium. The storage medium includes read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), or other optical disc memories, magnetic disk memories, tape memories, or any other readable medium capable of carrying or storing data.

[0093] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, various changes and modifications can be made to the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for detecting preemption of camera resources in a mobile application, characterized in that Including: Code parsing and preprocessing: statically parse the APK file of the application through the Soot framework 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, and compare the method signatures one by one with the target method. If no method matching the target method can be detected, it is determined that the application cannot correctly manage the camera resources. If a method matching the target method is detected, mark the matching method as a candidate method and output the detailed information of the candidate method for subsequent analysis; Path profiling: 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 paths contain API calls related to camera resource management, and detect whether there are missing logical judgments or logical errors in the logical branches of the conditional statements in the paths; Semantic verification: introduce a semantic verification mechanism, build the call point context of the API, trace 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 state and permission check logic where the call is located meet the normal usage requirements of the camera API; mark the camera APIs that do not conform to the resource management logic, have abnormal thread states, or have abnormal permission check logics as potential problem points.

2. The mobile application camera resource preemption detection method according to claim 1, wherein The steps of the path profiling further include: Based on the Soot framework, obtain the method call graph of the application, trace the direct calls and indirect calls of the candidate methods to ensure that the camera-related APIs of the indirect calls can also be detected, and include the traced calling methods as candidate methods in the path profiling step.

3. The mobile application camera resource preemption detection method according to claim 1, wherein Also including: Detection report: output the screening results of the global method screening; Output the detection results of the path profiling; Output the verification results of the semantic verification; Explain whether the resource call logic in each path conforms to the semantic rules of focus switching management; make a summary determination of the resource management ability of the application and provide optimization suggestions.

4. The mobile application camera resource preemption detection method according to claim 1, wherein The steps of the code parsing and preprocessing specifically include: Use the configuration interface provided by the Soot framework to load and parse the.dex bytecode in the APK file and convert 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 definitions, and call relationships between methods of the application, and generates a method list and a class dependency graph to provide a semantic basis for subsequent path profiling and semantic verification.

5. The mobile application camera resource preemption detection method according to claim 1, characterized in that The steps of the global method screening specifically include: Method signature matching: check one by one whether the method name of each method is onWindowFocusChanged through static analysis, and at the same time verify whether its parameter list contains the only boolean type parameter boolean hasFocus; Verification of 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 filtering criteria, record the method signature, class name, and specific location to provide input for the subsequent control flow graph analysis phase.

6. The mobile application camera resource preemption detection method according to claim 1, wherein API calls related to camera resource management, including: openCamera, startCamera, and android.hardware.Camera.open.

7. The method for detecting preemption of mobile application camera resources according to claim 1, wherein The step of analyzing whether the call 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 verification is performed before the call; If the judgment result of any of the above conditions is negative, it is considered that the camera API does not conform to the correct resource management logic.

8. The mobile application camera resource preemption detection method according to claim 3, wherein The step of making a summary determination of the resource management ability of the application and providing optimization suggestions specifically includes: If a resource contention problem is detected, point out its scope of influence and problem type; Provide targeted optimization suggestions: Add resource management logic in the onWindowFocusChanged method or supplement the permission check mechanism.

9. A mobile application camera resource preemption detection system, characterized in that Including: A memory for storing program instructions; A processor for calling the program instructions stored in the memory to implement the mobile application camera resource preemption detection method according to any one of claims 1 to 8.

Images