An Android application runtime permission error dynamic detection method
By analyzing and dynamically exploring the state transition graph of Android application permission misuse, the problem of difficulty in detecting runtime permission errors in existing technologies is solved, enabling fast and effective error detection and repair, and improving application stability.
Patent Information
- Application Number
- CN202211591311.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-12
- Publication Date
- 2026-02-17
- Estimated Expiration
- 2042-12-12
AI Technical Summary
Existing technologies struggle to efficiently detect runtime permission errors in Android applications, leading to application anomalies or crashes when permissions are granted, and existing automated tools fail to effectively detect ARP errors.
By analyzing APK files for permission misuse, instrumenting and re-signing them, and combining dynamic exploration to generate state transition graphs, the system can automatically explore and output test reports to detect permission errors.
Quickly detect ARP errors in Android applications, improve application robustness, reduce testing costs, and are applicable to different devices and control layouts, thus improving detection efficiency.
Smart Images
Figure CN115934541B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Android application technology, and more specifically to a method for dynamically detecting runtime permission errors in Android applications. Background Technology
[0002] Android's permission mechanism restricts applications' access to limited data (such as user contact information) and the execution of limited operations (such as audio recording) to protect user privacy. With the introduction of Android runtime permissions (ARP) in Android 6.0 (API level 23) and later, applications can request permissions from users at runtime, and users can revoke or grant permissions at any time during application runtime. The introduction of the ARP mechanism has greatly improved data privacy protection and the user experience, but it has also brought new challenges to Android application development and testing. It requires thorough testing of applications during frequent updates to ensure they function correctly under any permission granting conditions.
[0003] The Android platform has many APIs protected by permissions. If an Android application fails to properly check or request the relevant permissions before calling these protected APIs, it may lead to abnormal application behavior or even crashes. This type of Android runtime permission problem is known as an ARP error. ARP errors directly affect application usability, and developers should thoroughly test their applications before release to ensure they function correctly under various permission scenarios, unaffected by users granting or disabling permissions. However, research shows that developers often struggle to detect ARP errors without automated tools. Although extensive research has been conducted on Android automated testing, these tools typically do not consider the ARP mechanism and cannot effectively test permission-related behaviors within Android applications, thus failing to guarantee the robustness of Android applications under different permission granting conditions.
[0004] Static analysis can be used to detect ARP errors in Android applications, but it requires manual verification of the results by developers, which is costly and inefficient. Taking APER as an example, it extracts the call context of permission-protected APIs and combines data flow with its proposed four permission management modes (in-process, inter-process, etc.) to locate errors. However, APER's detection results may contain many false positives, requiring manual verification by developers. Given the numerous complex event-driven GUI behaviors in Android applications, manual verification by developers is costly. If the results of static analysis can be used to guide automated testing, the scope of exploration can be narrowed, allowing testing resources to be focused more on controls that may trigger ARP errors, thus improving detection efficiency.
[0005] Therefore, how to quickly detect ARP errors within Android applications, thereby helping developers quickly fix errors and improve application robustness, is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0006] In view of this, the present invention provides a dynamic detection method for runtime permission errors in Android applications, which takes into account the ARP mechanism and can detect ARP errors in Android applications more efficiently than other automated testing tools.
[0007] To achieve the above objectives, the present invention provides the following technical solution:
[0008] A method for dynamically detecting runtime permission errors in Android applications includes the following steps:
[0009] Perform permission misuse analysis on the APK file of the application under test, obtain the APIs affected by permission misuse, instrument the APIs affected by permission misuse in the APK file, and re-sign the instrumented APK file.
[0010] After instrumentation, the installable and runnable APK file is installed on the Android device. The application under test is dynamically explored to generate a state transition diagram. During the dynamic exploration process, the target control is recorded, which is the control that can call the API affected by permission misuse.
[0011] The system automatically explores the application under test, selects controls to operate based on the state transition diagram and target controls during the exploration process, and outputs a test report after detecting Android runtime permission errors.
[0012] The technical effect achieved by the above technical solution is as follows: by combining permission misuse analysis and dynamic exploration to construct a state transition graph, and using the state transition graph to guide automated testing, the goal of quickly detecting ARP errors in Android applications can be achieved.
[0013] Optionally, the specific method for performing permission misuse analysis on the APK file of the application under test is as follows:
[0014] The static permission misuse analysis tool was used to analyze APIs suspected of being affected by permission misuse, and these APIs were designated as suspicious APIs.
[0015] Static permission misuse analysis tools, including APER, take APK files as input and use the API call context and data stream generated by controls within the tested application to locate and output suspicious APIs.
[0016] Optionally, the specific methods for APIs within the instrumented APK file that are affected by permission misuse are as follows:
[0017] By using tools that support bytecode analysis of Android programs, including Soot, instrumentation can be performed at the locations where suspicious APIs are called. When the application under test calls suspicious APIs during its operation, it can be monitored through logs.
[0018] Optionally, the specific method for re-signing the instrumented APK file is as follows:
[0019] After an APK file is instrumented, the original signature is corrupted and the application cannot be installed or run. Signing tools, including jarsigner, are used to re-sign the instrumented APK file of the application under test.
[0020] Optionally, a state transition diagram is generated, which includes the following steps:
[0021] S21: Starting state, enter an installable and runnable APK file;
[0022] S22: Install the APK file;
[0023] S23: Output a runnable application under test;
[0024] S24: Dynamically explore the application under test and construct a state transition diagram;
[0025] S25: Output state transition diagram;
[0026] S26: Output the target control set.
[0027] Optionally, the specific methods in S24-S26 are as follows:
[0028] Dynamically explore the application under test using automated testing tools, including Droidbot, starting from the current state at each step of the exploration process. i The corresponding set of UI controls W i Select one control w according to its position. i,j ∈W iOperation, analysis of the current set of UI controls W after operation. j If W i ≠W j This indicates that the application under test has entered a new state. j Then the new state s j Add all the corresponding controls within the interface to the state set S and the control set W respectively, and then add the operation control w. i,j The generated logs are added to the log set L, where Result(w i,j )=l m Finally, the control w that triggers the state transition i,j Add to set W tran From(w) i,j ) = s i ∈S, To(w i,j ) = s j ∈S; if W i =W j Then only the operation control w i,j The generated logs are added to the log set L, and no new state nodes or state transition edges are added to the state transition graph; the above steps are repeated until the specified exploration time is reached, and the state transition graph STG = (S, W, W) is constructed. tran ,L);
[0029] Simultaneously, monitor the logs during the exploration process, and when the control w is operated... p,q If instrumentation content is subsequently detected, then control w will be... p,q Add to target control collection W targ .
[0030] Optionally, based on the state transition diagram and the target control, select a control to operate on, specifically including the following steps:
[0031] S31: Input the application to be tested;
[0032] S32: Get current interface information;
[0033] S33: Output the current interface information;
[0034] S34: Control recognition;
[0035] S35: Outputs information about all controls on the current screen;
[0036] S36: Input state transition diagram STG = (S, W, W) tran ,L);
[0037] S37: Input target control set W targ ;
[0038] S38: Select and manipulate controls;
[0039] S39: Determine if an Android runtime permission error is detected; if yes, output a test report; otherwise, execute S32.
[0040] Optionally, the specific methods for selecting and manipulating controls in S38 are as follows:
[0041] For the target control w p,q ∈W targ The operation involves selecting controls using different strategies in stages: In the first stage, the set of controls on the current application interface is analyzed. If the current set of controls matches the state node s in the STG state transition diagram... i The set of UI controls corresponding to ∈S W i If a match is found, the current state is s. i Get state s i To state s p The shortest sequence of controls to be operated on, Path(s) i ,s p )={w i,j ,w j,k ,…,w o,p}, and manipulate the first control w in the sequence. i,j , where s p =From(w p,q ) is the target control w p,q The state corresponding to the current interface; continuously execute the above process until the current state of the application under test is s. p ;
[0042] The second phase involves first analyzing the granting of dangerous permissions required by the suspicious API. If dangerous permissions have been granted, the target control (w) is operated on after the dangerous permissions are revoked. p,q Conversely, directly manipulate the target control w. p,q Subsequently, starting from the current state of the application under test, controls are selected based on a depth-first traversal strategy. That is, each time a control is selected from the current interface of the application under test, an operation is performed. After executing one event sequence, if no more states can be explored, the state s is returned. p Explore other paths;
[0043] In a state transition diagram (STG), state s p After the path starting from W has been fully explored, proceed from the target control set W. targ Select other controls and repeat S38; during the exploration process, stop the exploration after reaching the specified time or discovering a runtime permission error.
[0044] As can be seen from the above technical solution, compared with the prior art, the present invention discloses a method for dynamic detection of runtime permission errors in Android applications, which has the following beneficial effects:
[0045] (1) This invention combines permission misuse analysis and dynamic exploration to construct a state transition graph, and uses the state transition graph to guide automated testing in order to quickly detect ARP errors in Android applications, thereby helping developers to quickly fix errors and improve application robustness. Compared with other methods, this method focuses on controls that may have ARP errors, thereby narrowing the scope of exploration, improving detection efficiency, and enabling more efficient detection of ARP errors in Android applications.
[0046] (2) The error detection method proposed in this invention is applicable to different applications. Based on the state transition diagram, it is independent of the device and control layout and can be adapted to different versions of Android devices. Attached Figure Description
[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0048] Figure 1 A flowchart illustrating a method for dynamically detecting runtime permission errors in Android applications.
[0049] Figure 2 Flowchart for analyzing permission misuse;
[0050] Figure 3 Generate a flowchart for STG;
[0051] Figure 4 Flowchart for STG guidance dynamic exploration. Detailed Implementation
[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0053] With the introduction of Android's runtime permission mechanism, applications can request permissions from users at runtime, and users can revoke or grant permissions at any time during application runtime. This requires developers to conduct thorough testing of Android applications while ensuring frequent updates, to guarantee that the application can function correctly under any permission granting conditions. Without automated tools, developers often struggle to detect ARP errors. Although many automated testing tools exist, they are not designed with Android's runtime permission mechanism in mind and cannot effectively detect runtime permission errors.
[0054] Therefore, this invention discloses a method for dynamically detecting runtime permission errors in Android applications, such as... Figure 1 As shown, it includes the following steps:
[0055] Perform permission misuse analysis on the APK file of the application under test, obtain the APIs affected by permission misuse, instrument the APIs affected by permission misuse in the APK file, and re-sign the instrumented APK file.
[0056] After instrumentation, the installable and runnable APK file is installed on the Android device. The application under test is dynamically explored to generate a state transition graph (STG). During the dynamic exploration process, the target controls, i.e. controls that can call APIs affected by permission misuse, are recorded.
[0057] The system automatically explores the application under test, selects controls to operate based on the state transition diagram and target controls during the exploration process, and outputs a test report after detecting Android runtime permission errors.
[0058] Furthermore, such as Figure 2 As shown, the analysis of permission misuse of the APK file of the tested application includes the following steps:
[0059] S11: Startup state, input the APK file of the application to be tested;
[0060] S12: Analysis of Permission Misuse;
[0061] S13: Output APIs affected by permission misuse;
[0062] S14: APIs within instrumented APK files affected by permission misuse;
[0063] S15: Re-sign the instrumented APK file;
[0064] S16: Outputs an installable and runnable APK file.
[0065] Furthermore, the specific method for analyzing permission misuse in S12 is as follows:
[0066] The static permission misuse analysis tool was used to analyze APIs suspected of being affected by permission misuse, and these APIs were designated as suspicious APIs.
[0067] APER takes the APK file as input and uses the API call context and data stream generated by the controls within the tested application to locate and output suspicious APIs. In this embodiment, static tools such as APER that support permission misuse analysis can be used.
[0068] Furthermore, the specific methods for APIs affected by permission misuse within the instrumented APK file in S14 are as follows:
[0069] By instrumenting suspicious API calls, the system can monitor these calls via logs during the application's runtime. In this embodiment, tools such as Soot, which support bytecode analysis of Android programs, can be used to directly instrument the APK file.
[0070] Furthermore, the specific method for re-signing the instrumented APK file in S15 is as follows:
[0071] After an APK file is instrumented, the original signature is corrupted and the application cannot be installed or run. Then, a signing tool such as jarsigner is used to re-sign the instrumented APK file of the application under test.
[0072] The STG of Android application A is a quadruple (S, W, W). tran In STG, a node is a set of states S in application A, with each state corresponding to a UI element in application A; W is a set of controls in A; and edges in STG are sets of controls W in A that trigger state transitions. tran , L is a log set. For state s i ∈S, s i The corresponding interface consists of a set of controls Composition. For the control w that triggers the state transition. i,j ∈W tran From(w i,j ) = s i ∈S, To(w i,j ) = s j ∈S, indicating that state s in A i It can be done through the control w i,j Transition to state s j The starting point is s i The conversion endpoint is s j ;Result(w i,j )=lm ∈L is the operation control w i,j The log generated afterward. For state s i ∈S, s p ∈S, Path(s) i ,s p )={w i,j ,w j,k ,…,w o,p} represents the state s i To state s p The shortest sequence of controls that needs to be operated on.
[0073] like Figure 3 As shown, generating the state transition diagram specifically includes the following steps:
[0074] S21: Starting state, enter an installable and runnable APK file;
[0075] S22: Install the APK file;
[0076] S23: Output a runnable application under test;
[0077] S24: Dynamically explore the application under test and construct a state transition diagram;
[0078] S25: Output state transition diagram;
[0079] S26: Output the target control set.
[0080] Furthermore, the specific methods in S24-S26 are as follows:
[0081] State transition diagram STG = (S, W, W) tran (,L) is dynamically constructed during the application exploration process. Specifically: in each step of the exploration process, starting from the current state s i The corresponding set of UI controls W i Select one control w according to its position. i,j ∈W i Operation, analysis of the current set of UI controls W after operation. j If W i ≠W j This indicates that the application under test has entered a new state. j Then the new state s j Add all the corresponding controls within the interface to the state set S and the control set W respectively, and then add the operation control w. i,j The generated logs are added to the log set L, where Result(w i,j )=l m Finally, the control w that triggers the state transition i,j Add to set W tranFrom(w) i,j ) = s i ∈S, To(w i,j ) = s j ∈S; if W i =W j Then only the operation control w i,j The generated logs are added to the log set L, and no new state nodes or state transition edges are added to the state transition graph; the above steps are repeated until the specified exploration time is reached, and the state transition graph STG = (S, W, W) is constructed. tran ,L);
[0082] Simultaneously, monitor the logs during the exploration process, and when the control w is operated... p,q If instrumentation content is subsequently detected, then control w will be... p,q Add to target control collection W targ In this embodiment, automated testing tools such as Droidbot can be used to dynamically explore the application under test.
[0083] Furthermore, state transition diagrams and target control set-guided automated testing are used to more efficiently detect ARP errors within the application under test, such as... Figure 4 As shown, the specific steps include:
[0084] S31: Input the application to be tested;
[0085] S32: Get current interface information;
[0086] S33: Output the current interface information;
[0087] S34: Control recognition;
[0088] S35: Outputs information about all controls on the current screen;
[0089] S36: Input state transition diagram STG = (S, W, W) tran ,L);
[0090] S37: Input target control set W targ ;
[0091] S38: Select and manipulate controls;
[0092] S39: Determine if an Android runtime permission error is detected; if yes, output a test report; otherwise, execute S32.
[0093] Furthermore, the specific method for selecting and manipulating controls in S38 is as follows:
[0094] For the target control w p,q ∈W targThe operation involves selecting controls using different strategies in stages: In the first stage, the set of controls on the current application interface is analyzed. If the current set of controls matches the state node s in the STG state transition diagram... i The set of UI controls corresponding to ∈S W i If a match is found, the current state is s. i Get state s i To state s p The shortest sequence of controls to be operated on, Path(s) i ,s p )={w i,j ,w j,k ,…,w o,p}, and manipulate the first control w in the sequence. i,j , where s p =From(w p,q ) is the target control w p,q The state corresponding to the current interface; continuously execute the above process until the current state of the application under test is s. p ;
[0095] The second phase involves first analyzing the granting of dangerous permissions required by the suspicious API. If dangerous permissions have been granted, the target control (w) is operated on after the dangerous permissions are revoked. p,q Conversely, directly manipulate the target control w. p,q Subsequently, starting from the current state of the application under test, controls are selected based on a depth-first traversal strategy. That is, each time a control is selected from the current interface of the application under test, an operation is performed. After executing one event sequence, if no more states can be explored, the state s is returned. p Explore alternative paths; before each operation of the control, check the permissions granted to the suspicious API, and if dangerous permissions have been granted, revoke them to ensure that the control is operated without the necessary permissions.
[0096] In a state transition diagram (STG), state s p After the path starting from W has been fully explored, proceed from the target control set W. targ Select other controls and repeat S38; during the exploration process, stop the exploration after reaching the specified time or discovering a runtime permission error.
[0097] Based on the above information, the runtime permission error detection method proposed in this invention obtains potentially erroneous APIs through static analysis, and then uses dynamically constructed state transition graphs to guide automated testing. Compared with traditional automated testing methods and manual detection methods, it can quickly detect runtime permission errors, reduce testing costs, and improve detection efficiency.
[0098] The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for dynamically detecting runtime permission errors in Android applications, characterized in that, Includes the following steps: Perform permission misuse analysis on the APK file of the application under test, obtain the APIs affected by permission misuse, instrument the APIs affected by permission misuse in the APK file, and re-sign the instrumented APK file. After instrumentation, the installable and runnable APK file is installed on the Android device. The application under test is dynamically explored to generate a state transition diagram. During the dynamic exploration process, the target control is recorded, which is the control that can call the API affected by permission misuse. The system automatically explores the application under test, selects controls to operate based on the state transition diagram and target controls during the exploration process, and outputs a test report after detecting Android runtime permission errors. Generating a state transition diagram involves the following steps: S21: Starting state, enter an installable and runnable APK file; S22: Install the APK file; S23: Output a runnable application under test; S24: Dynamically explore the application under test and construct a state transition diagram; S25: Output state transition diagram; S26: Output the target control set; The specific methods for S24-S26 are as follows: Dynamically explore the application under test using automated testing tools, including Droidbot, starting from the current state at each step of the exploration process. The corresponding set of interface controls Select one control in sequence based on its position. Operations, and analysis of the current set of UI controls after manipulation. ,like This indicates that the application under test has entered a new state. The new state will be Each of these controls within the interface is added to a state set. S and control collection W , will operate the control The generated logs are added to the log collection. L ,in Finally, the control that triggers the state transition. Add to collection ,in ;like Then only the operation controls The generated logs are added to the log collection. L The state transition graph does not add new state nodes or state transition edges; the above steps are repeated until the specified exploration time is reached to construct the state transition graph. ; Simultaneously, monitor logs during the exploration process, and when the control is operated... If instrumentation content is subsequently detected, the control will be... Add to target control collection .
2. The method for dynamic detection of runtime permission errors in Android applications according to claim 1, characterized in that, The specific method for analyzing permission misuse of the APK file of the application under test is as follows: The static permission misuse analysis tool was used to analyze APIs suspected of being affected by permission misuse, and these APIs were designated as suspicious APIs. Static permission misuse analysis tools, including APER, take APK files as input and use the API call context and data stream generated by controls within the tested application to locate and output suspicious APIs.
3. The method for dynamic detection of runtime permission errors in Android applications according to claim 2, characterized in that, The specific methods for fixing APIs within an instrumented APK file that are affected by permission misuse are as follows: By using tools that support bytecode analysis of Android programs, including Soot, instrumentation can be performed at the locations where suspicious APIs are called. When the application under test calls suspicious APIs during its operation, it can be monitored through logs.
4. The method for dynamic detection of runtime permission errors in Android applications according to claim 1, characterized in that, The specific method for re-signing the instrumented APK file is as follows: After an APK file is instrumented, the original signature is corrupted and the application cannot be installed or run. Signing tools, including jarsigner, are used to re-sign the instrumented APK file of the application under test.
5. The method for dynamic detection of runtime permission errors in Android applications according to claim 1, characterized in that, Based on the state transition diagram and the target control, select the control to perform the operation, specifically including the following steps: S31: Input the application to be tested; S32: Get current interface information; S33: Output the current interface information; S34: Control recognition; S35: Outputs information about all controls on the current screen; S36: Input State Transition Diagram ; S37: Input target control set ; S38: Select and manipulate controls; S39: Determine if an Android runtime permission error is detected; if yes, output a test report; otherwise, execute S32.
6. The method for dynamic detection of runtime permission errors in Android applications according to claim 5, characterized in that, The specific method for selecting and manipulating controls in S38 is as follows: For target control The operation involves selecting controls using different strategies in stages: In the first stage, the set of controls on the current application interface is analyzed, and if the current set of controls matches the state transition diagram... STG State nodes in The corresponding set of UI controls If a match is found, the current state is: Get the status To state The shortest sequence of controls to be operated and manipulate the first control in the sequence. ,in To manipulate the target control The state corresponding to the current interface; continuously execute the above process until the current state of the application under test is... ; The second phase involves first analyzing the granting of dangerous permissions required by the suspicious API. If dangerous permissions have been granted, the target control is operated only after the dangerous permissions are revoked. Conversely, you can directly manipulate the target control. ; Subsequently, starting from the current state of the application under test, controls are selected based on a depth-first traversal strategy. That is, each time a control is selected from the current interface of the application under test, an operation is performed. After executing a sequence of events, if no more states can be explored, the state is returned. Explore other paths; In a state transition diagram (STG), states are represented by... After the path starting from the target control set has been fully explored, proceed from the target control set. Select other controls and repeat S38; during the exploration process, stop the exploration after reaching the specified time or discovering a runtime permission error.