Analysis and Detection Method for Defects in Android Application Interface Data Loss
By preprocessing and building and saving-recovering binary graphs of Android applications, combined with stain analysis methods, the inefficiency and accuracy of interface data loss defect detection is solved, and the rapid and fully automatic detection effect is achieved.
Patent Information
- Application Number
- CN202211582050.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-09
- Publication Date
- 2025-07-29
- Estimated Expiration
- 2042-12-09
AI Technical Summary
The existing technology is difficult to effectively detect interface data loss defects in Android applications, resulting in a decline in user experience, and the detection effect of existing tools is poor and time-consuming.
Apktool and Soot tools are used to preprocess APK files, build, save-recover binary graphs, use FlowDroid tools to perform stain analysis, generate data flow summary, and detect interface data loss defects.
It realizes efficient and fully automatic static analysis, avoids irrelevant variables, faster detection, wider coverage, and accurately identify interface data loss defects.
Smart Images
Figure CN115827465B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of program static analysis and software defect detection, and particularly relates to a method for analyzing and detecting defects of Android application interface data loss. Background Art
[0002] Nowadays, smart phones have become an indispensable part of modern people's lives. Among them, the Android operating system occupies the highest share of the current global smart phone operating systems. Therefore, Android applications are an important category of today's Internet applications, accounting for about 40-50% of mobile Web and application traffic. Google's open market offers more than 1.4 million Android applications, and tens of thousands of applications are added every month. However, with the continuous development of Android applications, developers not only need to provide users with more functions, but also need to consider the user-friendliness of the applications. And data loss defects are an important aspect affecting the user-friendliness of applications.
[0003] As an event-driven program, an Android application will experience a series of life cycle changes during operation. And the life cycle changes in some usage scenarios will cause the application to be destroyed without being closed, resulting in data loss defects. Specifically, this type of life cycle change will force the running application instance to be destroyed and then re-instantiated. Typical cases include answering a phone call, switching between applications, and rotating the phone to change the layout, etc. However, the application instance contains many variables related to interface display. The destruction of the instance will cause these variables to be recycled by the system. Therefore, the developer is responsible for restoring the values of these variables during the re-instantiation process. However, there are many applications that cannot handle this life cycle change well, resulting in the inconsistency between the interface of the re-instantiated application and the state before destruction, such as the disappearance of the original dialog box, the disappearance of the entered text, the reappearance of the closed menu, etc. This will force the user to repeat some previously completed interactions with the application, seriously affecting the user experience.
[0004] There are studies on the detection of Android application interface data loss defects in the existing work, but there are still many deficiencies. Because there is no accurate identification and modeling of interface data, the detection effects of a small number of existing static analysis tools for such defects are poor, and a large number of false positives will be generated in the results; and the existing dynamic testing tools also have poor effects due to factors such as code coverage and limited data loss defect triggering events, and the detection process is very time-consuming. Summary of the Invention
[0005] The object of the present invention is to provide a static detection method for defects in Android application interface data loss, which is used to effectively and efficiently detect defects in interface data loss in Android applications.
[0006] The technical solution for achieving the object of the present invention is: a static detection method for defects in Android application interface data loss, which takes the APK file of the Android application as the input and the detailed information of the detected defects in the application interface data loss as the output result. The specific steps are as follows:
[0007] Step 1: Use the Apktool tool and the Soot tool to preprocess the APK file to obtain a static resource file and a Jimple file representing the intermediate layer of the code, and analyze the Jimple file in combination with the resource file to obtain the interface data that needs to be saved and restored.
[0008] Step 2: According to the identified interface data that needs to be saved and restored, analyze the Jimple file to determine the corresponding variables and the relationships between the variables, and construct a save-restore bipartite graph.
[0009] Step 3: Use the taint analysis method of the FlowDroid tool to construct a data flow related to the save or restore operation of the variables in the save-restore bipartite graph, and generate a corresponding data flow summary.
[0010] Step 4: Based on the constructed save-restore bipartite graph and the data flow summary, analyze to obtain the detailed information of the data loss defect, and output the detection result to obtain a report file containing the detailed information of the data loss defect.
[0011] In the second aspect, the present invention provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the steps of the method described in the first aspect.
[0012] In the third aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, it implements the steps of the method described in the first aspect.
[0013] In the fourth aspect, the present invention provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the steps of the method described in the first aspect.
[0014] Compared with the prior art, the present invention has the following remarkable advantages: (1) For the detection of the problem of interface data loss in Android applications, it is the first to propose to model the interface data by using a save - restore bipartite graph, avoiding a large number of irrelevant variables and control attributes, and the method is more effective; (2) It is a fully automatic static analysis method that does not require running the app. Compared with dynamic testing, it has the remarkable advantages of faster detection and wider code coverage. Description of the Drawings
[0015] Figure 1 It is an overview diagram of the Android application interface data loss defect tool provided by the present invention.
[0016] Figure 2 It is an example of the output result of the APK file pre - processing.
[0017] Figure 3 It is an example of the generated Jimple file.
[0018] Figure 4 It is an example of a data loss defect and its repair code for applying BeeCount.
[0019] Figure 5 It is an example of common classes related to data storage and reading.
[0020] Figure 6 It is an example of the data flow summary constructed by data flow analysis.
[0021] Figure 7 It is an example of a data loss defect report for applying BeeCount.
[0022] Figure 8 It is an example of the data loss defect detection result report file. Detailed Implementation Manner
[0023] The present invention proposes an automatic detection method for Android application interface data loss defects, taking the APK file of the Android application as the input and the detected interface data loss defect categories and detailed information as the output results. The specific steps are as follows:
[0024] Step 1: Use the Apktool tool and the Soot tool to pre - process the APK file to obtain the static resource file and the Jimple file representing the intermediate layer of the code, and analyze the Jimple file in combination with the resource file to obtain the interface data that needs to be saved and restored;
[0025] Step 2: According to the identified interface data that needs to be saved and restored, analyze the Jimple file to determine the corresponding variables and the relationships between the variables, and construct a save - restore bipartite graph;
[0026] Step 3: Use the taint analysis method of the FlowDroid tool to construct the data flow related to the save or restore operations of variables in the save-restore bipartite graph, and generate the corresponding data flow summary;
[0027] Step 4: Based on the constructed save-restore bipartite graph and data flow summary, detect the data with missing save or restore operations or incorrect save or restore operations, and output the detection result to obtain a report file containing detailed information on data loss defects.
[0028] As a specific example, as described in Step 1, use the Apktool tool and Soot tool to preprocess the APK file to obtain the static resource file and the Jimple file representing the intermediate layer of the code, and analyze the Jimple file in combination with the resource file to obtain the interface data that needs to be saved and restored. The specific steps are as follows:
[0029] Step 1-1: Use the Apktool tool to decode the APK file to obtain the.xml resource file therein, and analyze the resource file to obtain the application package name, registered activity classes, and statically bound user interaction callbacks;
[0030] Step 1-2: Use the Soot tool to parse the APK file, decompile the.dex file therein to obtain the intermediate form code of the Jimple type of the application, and filter and analyze the objects according to the application package name and class inheritance relationship;
[0031] Step 1-3: Traverse the Jimple files of all analyzed objects, search for API calls related to control setting in different callback functions, and identify the interface data that needs to be saved and restored.
[0032] As a specific example, as described in Step 2, according to the identified interface data that needs to be saved and restored, analyze the Jimple file to determine the corresponding variables and the relationships between the variables, and construct a save-restore bipartite graph. The specific steps are as follows:
[0033] Step 2-1: Based on the call of the control setting API identified in Step 1, extract the parameters of the call statement or the conditional variables in the conditional statement that controls the execution of the call statement as the variables corresponding to the interface data;
[0034] Step 2-2: Based on the callback of the variables corresponding to the extracted interface data, put the identified variables into the two sets of the save-restore bipartite graph respectively; specifically, the variables identified from the interface initialization callback are put into the restore variable set, and the variables identified from the user interaction callback are put into the save variable set;
[0035] Step 2-3: Determine the relationship between the saved variable set and the restored variable set based on whether the carrier controls used by the variables for interface display are the same, and complete the construction of the save-restore bipartite graph.
[0036] As a specific example, as described in Step 3, use the taint analysis method of the FlowDroid tool to construct the data flow related to the save or restore operation of variables in the save-restore bipartite graph, and generate the corresponding data flow summary. The specific steps are as follows:
[0037] Step 3-1: Collect all classes and their related APIs in Android that can be used for data storage and reading;
[0038] Step 3-2: From the code context of the variables in the extracted saved variable set, identify the relevant assignment statements of the variables, and use the variables and assignment statements as save information pairs to store them in the saved variable information set; similarly, from the code context of the variables in the extracted restored variable set, identify the relevant assignment statements of the variables, and use the variables and assignment statements as restore information pairs to store them in the restored variable information set.
[0039] Step 3-3: Define source based on the saved variable information set, define the API method signature of data storage as sink, and use FlowDroid to construct the data flow of the save operation that connects source and sink; define the API method signature of data reading as source, define sink based on the restored variable information set, and use FlowDroid to construct the data flow of the restore operation that connects source and sink.
[0040] As a specific example, as described in Step 4, based on the constructed save-restore bipartite graph and data flow summary, detect the data with missing save or restore operations, incorrect save or restore operations, and output the detection results to obtain a report file containing detailed information on data loss defects. The specific steps are as follows:
[0041] Step 4-1: Analyze the relationship between the saved variable set and the restored variable set in the save-restore bipartite graph. There must be a corresponding relationship between the variables in one set and the variables in the other set; for variables that do not meet this condition, the corresponding data is determined to have a missing save or restore operation and there is a data loss defect.
[0042] Step 4-2: For all variables that satisfy the corresponding relationship in Step 4-1, analyze whether the generated data flow contains their relevant source or sink definitions, so as to determine whether the corresponding save or restore operations are correct; if the source or sink defined based on a certain variable and its corresponding assignment statement does not exist in any connected data flow, it is determined that the save or restore operation of the data corresponding to the variable is incorrect, and there is a data loss defect.
[0043] Step 4-3: For variables that do not report data loss defects in the previous two steps and whose save and restore operations are implemented only based on the ViewModel, further analyze whether the domain variables associated with them in the ViewModel instance are used by the call statements of the data storage and reading APIs related to external storage to implement the save and restore of variable values; if not, it is determined to be a data loss defect;
[0044] Step 4-4: Output the data determined not to have data loss defects and their related affected interface controls in all the above three steps to the detection report file and dump them as a local table file.
[0045] The present invention will be described in detail below with reference to embodiments and drawings.
[0046] Embodiment
[0047] This embodiment is an automated detection method for data loss defects in Android application interfaces. By detecting an Android application, the detection results of data loss defects in the application are generated. The specific work composition is as Figure 1 shown. First, preprocess the APK file of a specific application to be detected, extract the resource file and Jimple file, and then analyze to obtain the interface data that needs to be saved and restored in the application; then, analyze the Jimple file to determine the program variables corresponding to the interface data and the relationships between the variables, and construct a save-restore bipartite graph; then, use data flow analysis methods such as taint analysis to construct the data flow related to the save or restore operations of variables; finally, analyze the obtained save-restore bipartite graph and data flow summary to obtain the data loss defect detection results.
[0048] In this embodiment, the method includes the following steps:
[0049] Step 1: For a to-be-detected Android application, identify the interface data therein through static analysis. The specific steps are as follows:
[0050] Step 1-1: Use the Apktool tool to decode the APK file to obtain the.xml resource file, and analyze the resource file to obtain the application package name, registered activity classes, and statically bound user interaction callbacks, such asFigure 2 as shown;
[0051] Step 1-2: Use the Soot tool to parse the.dex file of the APK file, decompile it to obtain the Jimple-type intermediate form code of the application, and screen and analyze the objects according to the application package name and class inheritance relationship, such as Figure 3 as shown;
[0052] Step 1-3: Traverse the Jimple files of all analyzed objects, and search for API calls related to control setting in the interface initialization lifecycle callbacks such as onCreate(), onStart(), onResume(), onRestoreInstanceState(), and callback functions for handling user interactions such as onClick(), onLongClick(), onOptionsItemSelected(), etc., to identify the interface data that needs to be saved and restored.
[0053] Step 2: Analyze the Jimple file to determine the program variables corresponding to the interface data and the relationships between the variables, and construct a save-restore bipartite graph, specifically as follows:
[0054] Step 2-1: Based on the API calls of the control settings identified in Step 1, extract the parameters of the call statement or the conditional variables in the conditional statement that controls the execution of the call statement as the variables corresponding to the interface data. For example, Figure 4 as shown, the call statement of setProjectName() on line 26 will complete the interface display of the control project_name, and extract the parameter name as the variable corresponding to the input text of the interface data "Notes";
[0055] Step 2-2: Put the variables identified from the interface initialization callbacks into the restore variable set, and put the variables identified from the user interaction callbacks into the save variable set; therefore, the variable name extracted from the function call chain of the onCreate() callback is put into the restore variable set, and the return value on line 43 extracted from the function call chain of the onSaveInstanceState() callback will be put into the save variable set;
[0056] Step 2-3: Determine the relationship between the save variable set and the restore variable set according to whether the carrier controls used by the variables for interface display are the same, and complete the construction of the save-restore bipartite graph; the above variables name and the return value on line 43 both correspond to the interface control enw.project_name, so there is an association between them;
[0057] Step 3, construct the data flow related to the save or restore operations of variables using data flow analysis methods such as taint analysis, as follows:
[0058] Step 3-1, collect all classes in Android that can be used for data storage and reading and their related APIs, as Figure 5 shown;
[0059] Step 3-2, extract the code context of the variables from the set of saved variables, identify the relevant assignment statements of the variables, and store the variables and assignment statements as a save information tuple in the set of saved variable information; similarly, extract the code context of the variables from the set of restored variables, identify the relevant assignment statements of the variables, and store the variables and assignment statements as a restore information tuple in the set of restored variable information;
[0060] Step 3-3, define source based on the set of saved variable information, define the API method signature for data storage as sink, and use FlowDroid to construct the data flow of the save operation that connects source and sink; define the API method signature for data reading as source, define sink based on the set of restored variable information, and use FlowDroid to construct the data flow of the restore operation that connects source and sink; and generate the corresponding data flow summary, as Figure 6 shown;
[0061] Step 4, based on the constructed save-restore bipartite graph and data flow summary, detect data that lacks save or restore operations or has incorrect save or restore operations, and output the detection result to obtain a report file containing detailed information about the data loss defect, as follows:
[0062] Step 4-1, analyze the relationship between the set of saved variables and the set of restored variables in the save-restore bipartite graph. Variables in one set must have a corresponding relationship with variables in the other set; for variables that do not meet this condition, the corresponding data is determined to lack save or restore operations, and the defect details are as Figure 7 shown;
[0063] Step 4-2, for all variables that meet the corresponding relationship in Step 4-1, analyze whether the generated data flow contains their related source or sink definitions, so as to judge whether the corresponding save or restore operation is correct; if the source or sink defined based on a certain variable and its corresponding assignment statement does not exist in any connected data flow, it is determined that the save or restore operation of the data corresponding to the variable is incorrect.
[0064] Step 4-3: For variables that report data loss defects in the previous two steps and whose save and restore operations are implemented only based on the ViewModel, further analyze whether the domain variables associated with them in the ViewModel instance are used by the call statements of the data storage and reading APIs related to external storage to implement the saving and restoration of variable values; if not, it is determined as a data loss defect.
[0065] Step 4-4: Output the data determined not to have data loss defects and their related affected interface controls in all the above three steps to the detection report file and dump them as a local table file, as Figure 8 shown.
[0066] In summary, it can be seen that the present invention can effectively and efficiently detect whether there are interface data loss defects in Android applications.
Claims
1. A method for analyzing and detecting defects in Android application interface data loss, characterized in that, Taking the APK file of an Android application as input and the detailed information of the detected defects in the application interface data loss as the output result, the specific steps are as follows: Step 1, use the Apktool tool and the Soot tool to preprocess the APK file to obtain the static resource file and the Jimple file representing the intermediate layer of the code, and analyze the Jimple file in combination with the resource file to obtain the interface data that needs to be saved and restored; Step 2, according to the identified interface data that needs to be saved and restored, analyze the Jimple file to determine the corresponding variables and the relationships between the variables, and construct a save-restore bipartite graph; Step 3, use the taint analysis method of the FlowDroid tool to construct the data flow related to the save or restore operation of the variables in the save-restore bipartite graph, and generate the corresponding data flow summary; Step 4, based on the constructed save-restore bipartite graph and the data flow summary, analyze to obtain the detailed information of the data loss defect, and output the detection result to obtain a report file containing the detailed information of the data loss defect.
2. The automated detection method for Android application interface data loss defects according to claim 1, characterized in that: After using the Apktool tool and the Soot tool to preprocess the APK file to obtain the static resource file and the Jimple file representing the intermediate layer of the code in Step 1, analyze the Jimple file in combination with the resource file to obtain the interface data that needs to be saved and restored. The specific steps are as follows: Step 1-1, use the Apktool tool to decode the APK file to obtain the.xml resource file therein, and analyze the resource file to obtain the application package name, the registered activity class, and the statically bound user interaction callbacks; Step 1-2, use the Soot tool to parse the APK file, decompile the.dex file therein to obtain the intermediate form code of the Jimple type of the application, and screen and analyze the objects according to the application package name and the class inheritance relationship; Step 1-3, traverse the Jimple files of all analyzed objects, search for whether there are API calls related to control setting in different callback functions, and identify the interface data that needs to be saved and restored.
3. The automated testing method for the Android application interface data loss defect according to claim 1, characterized in that According to the identified interface data that needs to be saved and restored in Step 2, analyze the Jimple file to determine the corresponding variables and the relationships between the variables, and construct a save-restore bipartite graph. The specific steps are as follows: Step 2-1, based on the call of the control setting API identified in Step 1, extract the parameters of the call statement or the conditional variables in the conditional statement that controls the execution of the call statement as the variables corresponding to the interface data; Step 2-2, based on the callback of the variables corresponding to the extracted interface data, put the identified variables into the two sets of the save-restore bipartite graph respectively; the variables identified from the interface initialization callback are put into the restore variable set, and the variables identified from the user interaction callback are put into the save variable set; Step 2-3, according to whether the carrier controls used by the variables for interface display are the same, determine the relationship between the save variable set and the restore variable set, and complete the construction of the save-restore bipartite graph.
4. The automated static detection method for the Android application interface data loss defect according to claim 1, wherein As described in step 3, use the taint analysis method of the FlowDroid tool to construct the data flow related to the save or restore operation of variables in the save-restore bipartite graph, and generate the corresponding data flow summary. The specific steps are as follows: Step 3-1: Collect all classes in Android that can be used for data storage and reading and their related APIs; Step 3-2: Extract the code context of the variables in the save variable set, identify the relevant assignment statements of the variables, and store the variables and assignment statements as save information pairs in the save variable information set; Extract the code context of the variables in the restore variable set, identify the relevant assignment statements of the variables, and store the variables and assignment statements as restore information pairs in the restore variable information set; Step 3-3: Define source based on the save variable information set, define the API method signature of data storage as sink, and use FlowDroid to construct the connected data flow between source and sink for the save operation; define the API method signature of data reading as source, define sink based on the restore variable information set, and use FlowDroid to construct the connected data flow between source and sink for the restore operation.
5. The automated static detection method for the Android application interface data loss defect according to claim 1, characterized in that As described in step 4, based on the constructed save-restore bipartite graph and data flow summary, analyze to obtain the detailed information of the data loss defect, and output the detection result to obtain a report file containing the detailed information of the data loss defect. The specific steps are as follows: Step 4-1: Analyze the relationship between the save variable set and the restore variable set in the save-restore bipartite graph. There must be a corresponding relationship between the variables in one set and the variables in the other set; for variables that do not meet this condition, the corresponding data is determined to lack save or restore operations; Step 4-2: For all variables that meet the corresponding relationship described in step 4-1, analyze whether the generated data flow contains their relevant source or sink definitions, so as to judge whether the corresponding save or restore operation is correct; if the source or sink defined based on a certain variable and its corresponding assignment statement does not exist in any connected data flow, it is determined that the save or restore operation of the data corresponding to the variable is incorrect; Step 4-3: For variables that do not report data loss defects in the first two steps and whose save and restore operations are only implemented based on ViewModel, analyze whether the domain variables associated with them in the ViewModel instance are used by the call statements of the data storage and reading APIs related to external storage to implement the save and restore of variable values; if not, it is determined to be a data loss defect; Step 4-4: Output the data determined to have data loss defects in all the above three steps and the related interface controls affected by the data loss defects to the detection result file.
6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, it implements the steps of the method described in any one of claims 1-5.
7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method described in any one of claims 1-5.
8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-5.