CN109614105B - Starting mode sensitive Android application return stack state static simulation method - Google Patents

Abstract

A starting mode sensitive Android application return stack state static simulation method. The method comprises the following steps: extracting part of return stack state related configuration from Android application Android manifest.xml files, and constructing an auxiliary main function for Android application by constructing a heap memory allocation point of an object for each Activity class and organizing a callback function calling sequence in which each Activity object is rewritten according to a control flow; the target Activity class in the Activity startup relation and the relevant configuration of the return stack state are extracted through the pointing analysis of the auxiliary main function, and thus the startup graph of the Activity object is constructed; and constructing a return stack state transition diagram based on the Activity initiation diagram. The return stack state transition diagram can support various upper-layer applications, such as GUI model construction, GUI testing, vulnerability mining, defect detection and the like, and avoids the problem of illegal paths caused by Activity jump analysis insensitive to the current starting mode.

Description

Starting mode sensitive Android application return stack state static simulation method

Technical Field

The invention belongs to the technical field of Android mobile application software static analysis, and particularly relates to a starting mode sensitive return stack static simulation method.

Background

Android has become the most popular operating system on mobile devices. The Android applications are abundant in variety and large in quantity, and are widely applied to various aspects of life of people. Activity is one of the most important components of Android applications, and is responsible for providing interactive interfaces to users. The Android system organizes the Activity instances generated by the software running process in a return stack in a stack form so that the user can return to the previous layer of interface (previous layer Activity instance) correctly. The Activity instance at the top layer of the return stack is a current interface, and interaction with the current interface can trigger jump among activities and change the state of the return stack. Jump relations among Activities form an integral framework of Android application, and modeling of the Android application can support various upper-layer researches and applications, such as: GUI model construction, GUI test, vulnerability mining, defect detection and the like. Activity jumps are triggered by Activity launch and return actions, and the target Activity of a return action needs to be decided depending on the current return stack state. Therefore, accurately simulating the state change of the return stack is important for constructing an Activity jump model.

The Android application development engineer can control the change of the state of the return stack caused by the Activity initiation by configuring the attribute related to the state of the return stack. For Activity initiation, the default configuration requires the system to create a new Activity instance and push it onto the return stack. Special configurations may have special effects on the return stack, such as: if the property of 'launchMode' of the target Activity in a starting relationship is set as 'singleTask' and the property value of 'tasKaffinity' is the same as the name of the application package, when the target Activity is started, the system firstly searches whether an instance of the target Activity already exists in a return stack, if so, all the Activity instances above the instance in the return stack are destroyed, otherwise, a new instance of the target Activity is created and pressed into the return stack.

The current Activity jump static analysis does not extract the relevant properties that affect the return stack state and assumes that all Activities are launched in the default configuration. Obviously, for the Android application using special configuration, the current method cannot correctly simulate the state change of the return stack, so that the target Activity of the return action is positioned incorrectly, and an illegal Activity jump is generated. Illegal paths containing illegal Activity jumps seriously affect upper-level applications based on Activity jump analysis, such as: in the model-based GUI test, the test case is dynamically executed in the form of an action path, and when an illegal path is executed, the test fails due to the wrong execution of the illegal action, thereby affecting the test efficiency and accuracy.

Inter-component communication in the Android system uses the intent object to communicate information to launch the target component. To determine the target Activity and extract the property configuration associated with the return stack state, the field contents of the intent object need to be parsed by point analysis. Unlike a typical Java program which has only one entry, an Android application includes a large number of callback functions, and both user and system actions trigger corresponding callbacks, that is, the Android application includes a plurality of entries. Therefore, how to effectively handle the event-driven complex control flow of the Android program is a challenge to be overcome by pointing to analysis.

Disclosure of Invention

The invention aims to solve the problem that the simulation of the return stack state is incorrect due to the fact that the current Activity jump analysis is insensitive to the starting mode, and provides a static simulation method of the return stack state of the Android application, which is sensitive to the starting mode.

Technical scheme of the invention

A starting mode sensitive Android application return stack state static simulation method comprises the following steps:

1, the basic concept involved in the method:

1) defining 1, an Activity starting mode;

2) an Activity launching graph (ALG for short);

3) returning a stack state transition diagram (BSTG for short);

2, the method for the starting mode sensitive Android application return stack state static simulation specifically comprises the following steps:

step 1, Android application preprocessing;

step 2, generating an Activity startup graph through the sensitive Activity jump analysis of the startup mode;

and 3, generating a return stack state transition diagram based on the Activity startup diagram.

The method of the invention is realized by the following specific steps:

1, basic concepts related to the method of the invention;

1, defining an Activity starting mode;

when the Android system starts Activity, the configuration of relevant attributes influencing the state of a return stack is defined as an Activity starting mode; android related attributes that affect the launch mode are defined as return stack state related attributes.

The method summarizes 4 return stack state related attributes and 7 starting modes; the 4 return stack state related attributes are respectively: starting the 'launchMode' and 'tasKaffinity' of the target Activity in the relationship, wherein the mark of the Intent object transferred by the API call of the communication between Activities when the Activities are started is whether the API finish () is called. In an Activity launching relationship, the configuration of the four properties determines the launching mode of the four properties.

The 7 starting modes are respectively standard, single Top, standard-clear Top, single Top-clear Top, reorderToFront, single Task and standard | finish. Efficient launch mode and its impact on the return stack, as in Table 1, where Activity class c_nStarting up in a start-up mode lt_xIs recorded as

Setting the current return stack state to<a_c1,a_c2,…,a_cx-1,a_cx,a_cx+1,…,a_cn>Wherein a is_cxRepresenting Activity class c_xAn example of (a)_c1As an example of the bottom of the stack, a_cnIs a stack top example; a'_cxIs distinguished from a_cxC of_xA new example of (a).

Table 1 initiates the return stack change brought by Activity in different ways of initiation.

Defining an Activity Launching Graph (ALG for short);

the Activity Start graph is a quadruplet: ALG ═ (LT, N, E, s). LT is a set of startup modes; n is a nodeA collection, i.e., a collection of Activity classes; e is a directed edge set, E ═ tone<n_s,n_t,lt>|n_s∈N,n_tE N, LT e LT, where N is_sIs the starting point of the edge, n_tIs the end point of the edge, LT is an element in the start-up style set LT, representing the source Activity class n_sStarting target Activity class n in lt mode_t(ii) a s is the starting node of the ALG and is the Main Activity of the Android application.

3. Returning to the definition of a Stack state Transition Graph (BSTG);

the return stack state transition diagram is a quadruplet: BSTG ═ s (LT, BS, ST, BS_init). The BS is the return stack state set: BS ═ tone<c₁,c₂,…,c_i,…,c_n>|c_iE.n }, wherein c is₁Type of bottom of stack Activity instance to return stack, c_nThe type of the top of stack instance of the return stack. ST is a set of directed edges, representing return stack state transitions: and ST is L and F, wherein L is a return stack state transition set triggered by Activity starting, and F is a return stack state transition set triggered by a return action. L ═ tone<bs_s,bs_t,lt>|bs_s∈BS,bs_tE BS, LT e LT, where BS_sReturning stack state for source, bs_tIs the target Activity state. bs_initThe return stack state represented by the node contains only one instance of the Main Activity for the originating node.

2, the starting mode sensitive Android application return stack state static simulation method specifically comprises the following steps:

4. step 1, preprocessing Android application;

the Android application preprocessing comprises two parts: xml file parsing, wherein key information extracted from the file comprises: 1) android application package name; 2) a registered Activity class name set ACT; 3) an intent filter for each Activity class; 4) the attribute values of "taskAffinity" and "launchMode" of each Activity class; the second part is to construct auxiliary main () for pointing analysis to support the subsequent step 2 of launching manner sensitive Activity jump analysis. The auxiliary main () contains a heap memory allocation statement of an object of each Activity class and a callback function call statement of each Activity object organized according to control flow.

Unlike the traditional Java program which only has one program entry (main function), the Android application is event-driven and is composed of a large number of callback functions. These callback functions include lifecycle callbacks and non-lifecycle callbacks. The non-lifecycle callbacks, in turn, include system callbacks and GUI callbacks. In order to perform the directional analysis, a secondary main function needs to be constructed to organize the callback functions according to the control flow. Fig. 1 shows the structure of auxiliary main (). For Activity lifecycle callback functions: onCreate () and onDestroy () indicate the beginning and end of the Activity lifecycle, respectively; onStart () and onStop () are automatically called when Activity is visible and invisible, respectively; onResume () and onPause () indicate the operational period during which the user can operate Activity, such as clicking a button. Both system callbacks triggered by the system itself (such as onLocationChanged ()) and GUI callbacks triggered by user behavior (such as onClick ()) are called within the interactable period. And only the rewritten callback function is considered when the auxiliary main function is constructed for the Android application.

5. Step 2, generating an Activity startup graph through the sensitive Activity jump analysis of the startup mode;

the Activity jump analysis sensitive to the starting mode comprises 10 object-oriented field sensitive pointing analysis rules and 8 Activity starting edge generation rules; the 10 directional analysis rules are respectively for: class instantiation statements, instantiation statements of Activity classes, copy statements, field reading statements, field writing statements, method calling statements, intent flag setting statements, intent analysis display, implicit intent analysis and Activity starting statements; the 8 Activity launch edge generation rules are respectively directed to: an invalid return stack state related configuration decision, singleTask launch edge generation, singleTop-clearTop launch edge generation, stand-clearTop launch edge generation, reordertoont launch edge generation, singleTop launch edge generation, stand | finish launch edge, and stand launch edge generation.

5.1 symbol definition

TABLE 2 symbolic definitions for ALG construction methods

Table 2 lists the symbolic definitions used by the ALG construction method. The first part is an abstraction of the Java program. C represents a collection of classes and interfaces, and ACT represents a collection of all Activity classes. Each method body can be represented as a sentence s. The method body can be composed of five atomic statements of object instantiation, assignment, field reading, field writing and method calling. Object instantiation implies allocation of heap memory. The second section defines the correlation methods used in the pointing analysis process. Pt (r) represents the set of objects pointed to by the pointer r. FPt (r, f) gives the set of objects pointed to by the field f of the pointer r. The third section gives the symbols used to determine the manner of activation. The launchMode, taskAffinity of the activated Activity class, the mark of the intent object transferred by the communication method between the components during the activation and the calling of the finish () method influence the state of the return stack together, and determine the activation mode. The optional values for the launchMode attribute are: "standard", "singleTop", "singleTask", "singleinstant". The effect of the Intent flag on the return stack is classified into invalid flag (IVFLAG), Valid Flag (VFLAG), and Others (OFLAG). Alternative values for VFLAG are: "FLAG _ ACTIVITY _ CLEAR _ TOP", "FLAG _ ACTIVITY _ REORDER _ TO _ FRONT". The present invention refers to the intent flag that causes interaction of multiple return stacks as an invalid flag. The fourth part gives ALG related symbols. Each node in the Activity startup graph constructed by the pointing analysis is an object of an Activity class.

5.2 object-oriented field-sensitive pointing analysis rules

And (4) performing directional analysis on the auxiliary main function, wherein the node set N and the edge set E of the ALG are empty initially. [ RULE-1)]-[RULE-6]Corresponding to the directional rules corresponding to the five atomic sentences. [ RULE-1)]Corresponding to the class instantiation statement. [ RULE-2 ]]Specific to the instantiation of an Activity class. Each Activity object is created with a new node for ALG. [ RULE-3 ]]-[RULE-5]And respectively corresponding to assignment, field reading and field writing statements. [ RULE-6 ]]Corresponding to the invocation statement of the method. Each method m contains its name, Ginseng this_mAnd p_mReturn value r_m. Directional analysis of method m can be disassembled into method body s of m_mAnd the auxiliary sentence x: ═ r_mAnalysis of (2).

The Android system initiates a new Activity through an inter-component communication API, such as startActivity (intent). The Intent object determines the target Activity. Intent can be divided into two types, explicit and implicit. Explicit intent records an explicit target Activity type. The implicit intent records the actions that the target Activity needs to perform, and only the activities that have the ability to perform the actions may be launched. Actions that Activity can perform are registered in the intent filter of android Mainfest. The Android platform provides APIs to help the intent object record target Activity related information, such as setComponent (), setAction (). For explicit intent, the target Activity type is stored in the field intent. For implicit intent, the actions that the target Activity needs to perform are stored in the field intent. Setting a FLAG field for intent can achieve a special effect when the Activity is started, for example, a FLAG _ Activity _ CLEAR _ TOP FLAG requires that the system first searches for an instance of the same type as the target Activity in the return stack, and if the instance exists, all the instances above the instance in the return stack are destroyed.

[RULE-7]-[RULE-10]It is the inter-component communication related statement that points to the rule. [ RULE-7 ]]And analyzing the intent mark. The Intent flag is an integer type. Intent object oⁱStoring the flag value in the mFlags field by calling method addFlags (); the added new flag and the existing flag may be bitwise or operated by calling the method setFlags (), and the new flag and the existing flag may be stored in the mFlags field. [ RULE-8 ]]And [ RULE-9]]Explicit and implicit intent are analyzed separately. For the intent object oⁱAn auxiliary field targetClassName of the string type is constructed to store the target Activity class name. [ RULE-9]]The FindTarget () method in (1) returns the ability to execute o^jA target Activity set of actions. [ RULE-10]All Activity initiation-related APIs were analyzed, including: startActivity (), startActivityForResult (), startActivityIfneedle (), and menuItem. In this rule, this represents an Activity instance; initiating Activity passed intent object o^jThe field targetClassName of (1) records the name o of the target Activity class^k(ii) a GetActObj () gets its unique instance o in heap memory from class name^l(ii) a GetFlags () holds the intent object o^jConverting the integer stored in the field mFlags into a mark set and returning; GetLM () and GetTA () respectively obtain launchMode and tasKaffinity of the target Activity object; GetFIN () gets whether the method body of method m being analyzed calls finish ();

represents oⁱStarting up o under configuration relevant to starting up mode^l。

5.3Activity launch edge Generation rules

[ RULE-11] - [ RULE-18] gives the RULE for generating ALG startup edge according to the startup relation and configuration information between Activities. [ RULE-11] corresponds to the determination of invalid configuration, where pkName is the package name of the current Android application. When taf is not the same as the current package name, if the system has the same application installed taf, then the target Activity will be launched in the application's return stack. Invalid configurations may cause multiple return stack interactions without generating a launch edge for the invalid configured Activity launch. [ RULE-12] - [ RULE-18] respectively corresponds to the generation of effective edges of single task, single Top-clear Top, standard-clear Top, reorderToFront, single Top, standard | finish and standard, wherein the method ConfigVali () judges whether the configuration information is effective according to [ RULE-11], and if the configuration information is effective, the value is returned to true.

6. Step 3, generating a return stack state transition diagram based on the Activity startup diagram;

the return stack state transition diagram construction method takes an Activity initiation diagram ALG (LT, N, E, s) and the number k of Activity instances which can contain the same type at most in one return stack state as input, outputs a return stack state transition diagram BSTG (LT, BS, ST, BS)_init) The method comprises the following steps:

(1) setting a set BS, wherein ST is empty, and a queue stateQueue of a node to be processed is empty;

(2) constructing initial return stack state node bs_initThe initial state has only one instance of s;

(3) b is to mix_initJoin the set BS and add BS_initPushing a queue stateQueue of nodes to be processed, and then adding an edge for each return stack state node in the queue in sequence, namely, the return stack state change caused by Activity starting and the return stack state change caused by return action;

(4) popping up a queue head state node currentState in the stateQueue; the type of currentState Stack Top Activity instance is c_s；

(5) Traversing the current Activity class c in the Activity startup Ring_sTo the edge. For each outgoing edge, c is simulated according to Table 1_sLaunching target Activity c in lt-mode_tBack return stack state newState_launching；

(6) If newState_launchingThe number of Activity repeated instances in (1) does not exceed k, and the structure is from currentState to newState_launchingAnd add l to ST.

(7) If newState_launchingThe number of Activity repeat instances in (1) does not exceed k and

then newState will be_launchingPressing in stateQueue and adding in the set BS;

(8) if there are more than 1 instance in currentState, the state newState of the stack is returned after the top element of the currentState is simulated to be popped_backFrom currentState to newState_backAnd f is added to ST; if newState_backNot in the BS set, then newState will be_backPressing in stateQueue;

(9) and (4) if the stateQueue is not empty, jumping to the step (4).

The invention has the advantages and positive effects that:

the method firstly generates an Activity startup graph through the sensitive Activity jump analysis of the startup mode, and then generates a return stack state transition graph based on the Activity startup graph. The Activity startup graph shows the startup relation among the Activity classes of the Android application and focuses on the extraction of the startup mode. The return stack state transition diagram simulates the change of the return stack state caused by Activity starting and return actions, and can directly represent the return stack state which may appear when a user dynamically runs an Android application.

The advantages and positive effects of the invention are as follows:

(1) the startup mode is extracted, and 7 return stack state changes caused by starting Activity in different startup modes are simulated. The launch mode insensitive Activity jump analysis assumes that all Activities are launched in a standard mode. Therefore, for the Android application using a special starting mode, the Activity jump analysis which is insensitive to the starting mode cannot correctly simulate the change of the return stack state, so that an illegal Activity transition path is generated, and the upper-layer application based on the illegal Activity transition path is influenced. The return stack state transition diagram sensitive to the starting mode can support various upper-layer applications (such as GUI model construction, GUI testing, vulnerability mining, defect detection and the like) and meanwhile avoid illegal paths so as to achieve positive effects. For example, in an Android test based on a GUI model, the BSTG can be used for effectively avoiding illegal test cases, so that the test efficiency is improved, and manual operation is reduced.

(2) Through the return stack state transition diagram, whether multiple instances of the same Activity exist in one return stack state in the using process of the Android application can be found. In Android applications, multiple instances of the same type may be generated in the return stack after the Activity startup loop is executed multiple times. Too many Activity instances of the same type occupy a large amount of system resources, causing the user to use the card pause and influencing the user experience. The return stack state transition diagram can provide effective information for an Android application development engineer to help adjust the Activity starting mode in the Activity starting loop and reasonably manage the return stack, so that the software quality is improved, and the user experience is optimized.

[ description of the drawings ]

Fig. 1 is a structure of auxiliary main ().

Fig. 2 is a partial code fragment of the Android application program connectictbot.

FIG. 3 is an overall framework of a startup-mode sensitive return stack state static simulation approach.

FIG. 4 is a partial Activity Start diagram for the Android application ConnectBot.

Fig. 5 is a partial return stack state transition diagram of the Android application software connectictbot.

[ detailed description ] embodiments

Now, the method of the present invention is combined to implement a stack state transition diagram for returning part of the Android application software ConnectBot in fig. 1. The method of the invention relates to the basic concept: the detailed contents of the Activity initiation mode, the Activity initiation graph and the return stack state transition graph are detailed in the summary of the invention (not shown here). The static simulation method of the return stack state sensitive to the starting mode constructs an overall framework of BSTG for ConnectBot as shown in FIG. 3. The method comprises the following concrete steps:

(1) firstly, after an Android installation package is decompiled, preprocessing generated intermediate codes, extracting application package names, Activity class sets, Main activities, part return stack state related configurations (launchMode and taskAffinity) of each Activity and actions capable of being received by each Activity from Android Manifest xml files, and then constructing an auxiliary Main () to support the pointing analysis of a behavior-driven Android application program; (2) carrying out object-oriented pointing analysis on the auxiliary main () and constructing an Activity starting graph; (3) a return stack state transition map is generated based on the ALG. 1. Pretreatment of

Preprocessing, firstly, analyzing an android main email file of the code fragment in the figure 2: the connectictbot application package name is org.connectictbot (line 26); lines 29-30 determine that the Main Activity is HostListActivity; the code snippet contains 3 registrations of Activity classes in total, where the Activity class set ACT ═ hostlist Activity, consoletity, settingactivity } ( lines 27, 32, and 37); the launchMode attribute of HostListActivity and SettingsActive is null, so its launchMode is the default value standard, and the launchMode attribute value of ConsoleActivity is singleTop (line 33); the taskAffinity attribute values of the three activities are all null, so the same default value of "org.connecticbot" as the application entry is adopted; only the Console Activity registers the ability to receive action View actions (line 35), and can respond to an implicit action View action.

Auxiliary main () constructed for ConnectBot according to fig. 1 has the following structure:

1 void main(){

2 r₁∶＝new HostListActivity()；

3 r₂∶＝new ConsoleActivity()；

4 r₃∶＝new SettingsActivity()；

5 …

6 INVOKECALLBACK(r₁)；

7 INVOKECALLBACK(r₂)；

8 INVOKECALLBACK(r₃)；

9 …}

auxiliary main () contains only the call statements of the rewritten callback functions.

2. Generating ALG

For auxiliary main () foundation [ RULE-1 ]]-[RULE-18]Performs object-oriented pointing analysis and generates an Activity initiation graph ALG ═ (LT, N, E, s). Lines 2-4 of the auxiliary main () are instantiations of three Activity classes, respectively, and the Android system allocates heap memory space for respective objects. According to [ RULE-2 ]]，N＝{o²，o³，o⁴I.e. objects of HostListActivity, ConsoleActivity, SettingsActity, respectively.

Lines 8, 21, 11-12 of the code fragment of FIG. 2 call the inter-component communication API, respectively. According to [ RULE-10], the code segment has three startup relations, and the startup relations corresponding to the code lines 8, 21, 11-12 are e1, e2, e 3. The details of these three actuation relationships are shown in table 3. e1 starts the target Activity through the implicit intent object, which provides the action "intent. action _ VIEW" that the target Activity needs to receive (fig. 2, line 7), and according to [ run-9 ] and the actions that each Activity can receive after preprocessing, the target Activity of e1 can be determined to be the facility Activity. The launchMode and taskAffinity values of the target Activity of e1 are 'singleTop' and 'org.connectbot', no calling of finish () is carried out when the target Activity is started, an intent mark is not set, the relevant configuration of the starting mode of e1 is determined to be effective configuration according to [ RULE-11], and the starting mode of e1 is determined to be singleTop according to [ RULE-16 ]. e2 and e3 both launch target Activities through the explicit intent object, HostListActivity (line 19 of FIG. 2) and SettingsActity (line 12 of FIG. 2), respectively. launchMode for target Activity of e2 and e3 is "standard", taskaffactivity is "org. The intent object received at e2 has the FLAG "FLAG _ ACTIVITY _ CLEAR _ TOP" set (line 20 of fig. 2), and e3 has no FLAG set. Determining the starting mode related configuration of e2 and e3 according to [ RULE-11], and determining the starting mode of e2 and e3 respectively as standard-clear Top and standard according to [ RULE-16 ].

TABLE 3 Start relationship details

After the Activity jump analysis sensitive to the starting mode is finished, the generated Activity starting graph ALG is shown in FIG. 4, n₁、n₂、n₃Respectively represent three Activity classes of HostListActivity, Console Activity and SettingsActivity, e₁、e₂、e₃Three actuation relationships are shown, respectively. ALG ═ (LT, N, E, s), where:

LT＝{standard,standard-clearTop,singleTop}；

N＝{n₁,n₂,n₃}；

E＝{e₁,e₂,e₃}；

s＝n₁。

3. generation of BSTG

Generating a return stack transition diagram for the code fragment of FIG. 2 As shown in FIG. 5, the BSTG generation process is now described based on the ALG of FIG. 4.

Taking the Activity initiation graph ALG ═ (LT, N, E, s) as input, setting k ═ 2, and the output return stack state transition graph BSTG ═ (LT, BS, ST, BS)_init) The steps are as follows:

1) setting BS { }, ST { }, stateQueue [ ], and the left side of the stateQueue is the head of the queue and the right side is the tail of the queue;

2) initializing the Start Stack State bs with Main Activity_init＝<n1>；

3) B is to mix_initJoin return stack state set BS ═ { BS_initAnd pushing the result into a queue of nodes to be processed, namely, stateQueue ═ bs_init]；

4) Pop-up head state node currentState ═ bs in stateQueue_init，bs_initThe type of the stack top Activity instance is n₁At this time, stateQueue [ ] [, ]]；

5) Traversing n in ALG₁To the edge. n is₁With two discharge edges e₁And e₃. For the

a) The current return stack state is bs_initReturn to stack state newState after launching target Activity n2 in singleTop mode according to line 2 simulation n1 of Table 1_launching＝<n₁,n₂>；

b)newState_launchingThere is no Activity instance of the same type, construct currentState to newState_launchingSide l of₁And adds it to the set of return stack state transitions ST ═ l₁}；

c)newState_launchingThere is no Activity instance of the same type and

then bs will be₂＝newState_launchingStateQueue is pushed in and the set BS is added, at which point BS ═ BS_init,bs₂}，stateQueue＝[bs₂]。

For the

a) The current return stack state is bs_initLaunching target Activity n in a standard fashion according to line 1 simulation n1 of Table 1₃Back return stack state newState_launching＝<n₁,n₃>；

b)newState_launchingThere is no Activity instance of the same type, construct currentState to newState_launchingSide l of₂And adds it to the set of return stack state transitions ST ═ l₁,l₂}。

c)newState_launchingThere is no Activity instance of the same type and

then bs will be₃＝newState_launchingStateQueue is pushed in and the set BS is added, at which point BS ═ BS_init,bs₂,bs₃}，stateQueue＝[bs₂,bs₃]；

6) Due to the current return stack state bs_initOnly one instance of (a), then the change in state of the return stack caused by the return action is no longer simulated.

7) At the moment, the stateQueue is not empty, and a queue head state node currentState ═ bs in the stateQueue is popped₂，bs₂The type of the stack top Activity instance is n₂When stateQueue ═ bs₃]；

8) Traversing n in ALG₂To the edge. n is₂With 1 projecting edge e₂. For the

a) The current return stack state is bs₂Simulating n according to line 3 of Table 1₂Launching target Activity n in a Standard-ClearTop manner₁Back return stack state newState_launching＝<n₁>；

b)newState_launchingThere is no Activity instance of the same type, construct currentState to newState_launchingSide l of₃And adds it to the set of return stack state transitions ST ═ l₁,l₂,l₃}；

c) Because of newState_launching＝bs_initE.g., BS, so BS need not be assigned₂Push stateQueue.

9) Due to the current return stack state bs₂If there are more than 1 Activity instance, then bs is simulated₂Return stack state newState after top element is popped_back＝bs₁Constructed from bs₂To newState_backSide f of₁And add it to ST, where ST ═ l₁,l₂,l₃,f₁}，stateQueue＝[bs₃]；

10) At the moment, the stateQueue is not empty, and a queue head state node currentState ═ bs in the stateQueue is popped₃，bs₃Top Activity realExample type is n₃At this time, stateQueue [ ] [, ]]；

11) N in ALG₃No edge is exposed.

12) Due to the current return stack state bs₃If there are more than 1 Activity instance, then bs is simulated₂Return stack state newState after top element is popped_back＝bs₁Constructed from bs₃To newState_backSide f of₂And add it to ST, where ST ═ l₁,l₂,l₃,f₁,f₂}，stateQueue＝[]；

13) The BSTG construction ends.

The final output result of generating the return stack state transition diagram based on the ALG is (LT, BS, ST, BS)_init) Wherein:

LT＝{standard,standard-clearTop,singleTop}；

BS＝{bs_init,bs₂,bs₃}，bs_init＝<n1>，bs₂＝<n₁,n₂>，bs₃＝<n₁,n₃>；

ST＝{l₁,l₂,l₃,f₁,f₂}；

bs_init＝<n₁>。

Claims (1)

1.a static simulation method for a return stack state sensitive to a starting mode is characterized in that:

1) the following concepts are defined:

defining 1, an Activity starting mode;

define 2, Activity Start map;

defining 3, returning a stack state transition diagram;

defining 1 that the Activity starting mode is that when the Android system starts Activity, the configuration of relevant attributes of a return stack state is influenced; the properties comprise taskAffinity of an Activity class, launchMode of the Activity class, a mark for calling an intent object transmitted by an API (application program interface) for communication between components when the Activity is started, and whether finish () is called after the Activity is started;

definition 2 the Activity launching graph (ALG for short) is a quadruplet:ALG=( LT, N, E, s)；LTis a set of startup modes;Nis a node set, i.e. a set of Activity classes;Eis a set of directed edges that are,E={<n _s ,n _t , lt>| n _s ∈ N,n _t ∈ N, lt∈ LTtherein ofn _s Is the starting point of the edge or edges,n _t is the end point of the edge and,ltis a set of start-up modesLTElement of (1) representing a Source Activity classn _s To be provided withltThe manner of starting the target Activity classn _t ；sIs composed ofALGThe starting node of the Android application is the Main Activity of the Android application;

the return stack state transition diagram (BSTG) defined in definition 3 is a quadruplet:BSTG = (LT, BS, ST, bs _init )；BSis the return stack state set:BS = {<c ₁ , c ₂ , …, c _i , …, c _n >| c _i ∈Ntherein ofc ₁ To return the type of bottom-of-stack Activity instance of the stack,c _n type of top of stack instance for return stack;STis a set of directed edges, representing a return stack state transition:ST = L

FwhereinLThe set of return stack state transitions triggered for Activity initiation,Fa return stack state transition set triggered for a return action;L = {<bs _s , bs _t , lt>| bs _s ∈BS, bs _t ∈BS, lt∈LTtherein ofbs _s The source returns the state of the stack,bs _t is a target Activity state;bs _init the node is a starting node, and the return stack state represented by the node only contains one instance of the Main Activity;

2) comprises the following steps:

step 1, preprocessing Android application;

step 2, generating an Activity startup graph through the sensitive Activity jump analysis of the startup mode;

step 3, generating a return stack state transition diagram based on the Activity startup diagram; wherein the content of the first and second substances,

in step 1, the Android application preprocessing comprises two parts: the first part is android manifest.xml file analysis, and key information extraction from the file analysis comprises the following steps: 1) android application package name; 2) registered activity class name setACT(ii) a 3) An intent filter for each activity class; 4) the attribute values of "taskAffinity" and "launchMode" of each activity class; the second part is to construct auxiliary main () for pointing analysis, so as to support the launching mode sensitive Activity jump analysis described in step 2; the auxiliary main () contains a heap memory allocation statement of an object of each Activity class and a callback function call statement of each Activity object organized according to a control flow;

in step 2, the rules for generating the Activity jump analysis based on the sensitive start mode to generate the Activity start map comprise 10 object-oriented direction analysis rules and 8 Activity start edge generation rules; the 10 directional analysis rules are respectively for: class instantiation statements, instantiation statements of Activity classes, copy statements, field reading statements, field writing statements, method calling statements, setting intent mark statements, displaying intent analysis, implicit intent analysis and Activity starting statements; the 8 Activity launch edge generation rules are respectively directed to: an invalid start-up mode-related configuration decision,

the start-up of the edge is carried out,

the start-up of the edge is carried out,

the start-up of the edge is carried out,

the start-up of the edge is carried out,

the start-up of the edge is carried out,

the start-up of the edge is carried out,

starting an edge;

in step 3, the method for generating the return stack state transition diagram based on the Activity startup diagram is to use the Activity startup diagramALGNumber of Activity instances capable of containing the same type at most in return stack statekAs input, a start node is first generatedbs _init Add the node to the setBSAnd pushing the node into a queue of nodes to be processedstatequeueThen adding an outgoing edge for each return stack state node in the queue in sequence; for current return stack statecurrentstateThe process of adding out edges for the return stack state is as follows: traversing the current Activity class in ALCc _s For each outgoing edge, simulatingc _s To be provided withltMeans to launch a target Activityc _t Back-to-stack statenewState _launing If, ifnewState _launing The number of Activity repeat instances in (A) does not exceed the number of Activity repeat instances in (B)kAnd isnewState _launing

BSThen press it instatequeueAnd join the collectionBSConstructed fromcurrentstateTonewState _launing And adding it toST(ii) a Simulation ofcurrentstateReturning stack state after top element unstackingnewState _back If, ifnewState _back Is out of positionBSIn the set, press it intostatequeueConstructed fromcurrentstateTonewState _back And adding it toST(ii) a Finally outputting return stack state transition diagramBSTG=(LT, BS, ST, bs _init )。

Images