CN107562429B

CN107562429B - Android system static partitioning method based on compiling rules

Info

Publication number: CN107562429B
Application number: CN201710741450.XA
Authority: CN
Inventors: 赵红; 郝佳亮; 张艳艳; 周启明
Original assignee: Institute of Software of CAS
Current assignee: Institute of Software of CAS
Priority date: 2017-08-25
Filing date: 2017-08-25
Publication date: 2021-04-20
Anticipated expiration: 2037-08-25
Also published as: CN107562429A

Abstract

The invention relates to a compiling rule-based Android system static partitioning method. The method comprises the following steps: s1, analyzing git projects in the Android source codes, and acquiring names and paths of the git projects, wherein each independent git project is used as a module; s2, analyzing and extracting each module compiled into binary files in the make database; s3, extracting a file set which is depended on by each binary file in the make database during compiling; and S4, dividing the inclusion relation of the modules according to the git engineering path and the inclusion relation of the dependent files in the file set, and dividing the Android system source code into a tree structure containing a plurality of modules. According to the method, the Android system can be reasonably divided into the tree structure comprising the modules, so that the Android system framework is clearly displayed, and the analysis efficiency of developers on the Android system is improved.

Description

Android system static partitioning method based on compiling rules

Technical Field

The invention relates to the technical field of software engineering, mainly relates to Android system analysis, and more particularly relates to a compiling rule-based Android system static partitioning method.

Background

Android is a Linux-based operating system with free and open source codes, which is mainly used in mobile devices such as smart phones and tablet computers, and is led and developed by Google corporation and the open mobile alliance.

In recent years, Android smart phones have a high occupancy rate in the mobile terminal market, more and more people begin to research the Android system, and many researchers hope to optimize the performance, the security, the power consumption and the like of the Android system in a source code changing manner, so that the source code of the Android system needs to be analyzed. However, the Android system has a huge source code amount, and the workload is very large by only depending on manual analysis.

Disclosure of Invention

The technical problems solved by the invention are as follows: aiming at the problems that the Android system source code is large in size and difficult to analyze, the method for statically dividing the Android system based on the compiling rule is provided, the Android system source code is divided into a tree structure comprising a plurality of modules, and the code analysis efficiency is effectively improved.

The technical solution of the invention is as follows:

a static Android system partitioning method based on compiling rules divides an Android system into a tree structure comprising a plurality of modules, and comprises the following steps:

s1, analyzing git projects in the Android source codes, and acquiring names and paths of git projects in the Android source codes, wherein each independent git project serves as a module;

s2, analyzing the make database, and extracting each module compiled into binary files in the make database;

s3, extracting a file set which is depended on by each binary file in the make database during compiling;

and S4, dividing the Android system source code into a tree structure comprising a plurality of modules according to the inclusion relationship of the dependent files in the file set which is dependent during compiling of the git engineering path obtained in the step S1 and the binary file obtained in the step S3 and the inclusion relationship of the modules.

Further, the step S1 is to obtain a concrete implementation of the git project as follows: the method comprises the steps of downloading Android system source codes to be analyzed by using a repo command in a Linux system, executing a repo init-u URL (OPTIONS) command, analyzing names and path information of all git projects contained in a set of source codes from a manifest.

Further, the step S2 is implemented by analyzing the make database to obtain the module-related information as follows:

s21, designing a Mysql database table for storing module information;

s22, executing the make-n-p command, and storing the information of the printout into a txt file;

s23, analyzing the txt file stored in S22 and extracting the module name. The Android construction system inserts global variables named by the following rules when generating the rule of each package: android model $ ATTR. Where $ MODEL is the packet name and $ ATTR is one of BUILT, CHECKED, INSTALLED, PATH, REQUERD, STUBS, below. The invention concerns PATH, BUILT and INSTALLED. The rows containing these keys are parsed out and stored in the designed database table of S21.

Further, the specific method for extracting the file dependent on compiling of each module in step S3 is as follows: compiling rule information in the make database is extracted, the compiling rule information comprises a generating rule of each module, the format is 'target: dependency1dependency 2' (wherein target represents a compiling target, and dependency1 and dependency2 represent files and instructions and the like which are dependent during compiling), and dependent source code files are filtered out. And after the analysis is completed, storing the data into a designed database table S21.

Further, the specific implementation of dividing the module hierarchy in step S4 is as follows:

s41, dividing the system into APP layer, FRAMEWORKS layer, library and operation layer, HAL layer, wherein FRAMEWORKS layer is subdivided into API layer, SERVICE layer, JNI layer, SERVICE support layer. Each module carries out hierarchical division according to the path of the mk file depended on by the compiling module and the file type generated by compiling;

and S42, preliminarily generating module parent-child relations. Taking git as a primary module, taking the path of the primary module as a cardinal number, and positioning parent-child relationship of other modules according to the inclusion relationship of path characters on the basis of the path; preliminarily forming an inclusion relation among the modules;

and S43, adjusting the parent-child relationship generated in the S42 according to the file inclusion relationship depended by the modules to form the final inclusion relationship between the modules.

The invention also provides a compiling rule-based Android system static partitioning device which comprises a memory and a processor, wherein the memory stores a computer program, the computer program is configured to be executed by the processor, and the computer program comprises instructions for executing the steps of the method.

The present invention also provides a computer readable storage medium storing a computer program which, when executed by a computer, performs the steps of the method described above.

Compared with the prior art, the invention has the beneficial effects that:

according to the compiling rule-based Android system static partitioning method, the Android system source code can be partitioned into a tree structure comprising a plurality of modules, the Android system source code analysis difficulty is simplified, the code analysis efficiency is effectively improved, and the working efficiency of developers can be greatly improved.

Drawings

FIG. 1 is a general flow diagram of the present invention.

FIG. 2 is a flow chart of basic information extraction of the module according to the present invention.

FIG. 3 is a flow chart of module dependent file extraction according to the present invention.

FIG. 4 is a block level diagram of the present invention.

Fig. 5 is a screenshot of the relevant experimental data after step S3 is executed in the embodiment.

Fig. 6 is a schematic diagram of the relationship of the

rows

960 and 961 in the embodiment.

FIG. 7 is a diagram illustrating the relationship between rows 91-93 in the exemplary embodiment.

FIG. 8 is a diagram illustrating the relationship of column 664-674 in the embodiment.

FIG. 9 is a diagram illustrating the relationship between rows 52-56 in the exemplary embodiment.

Detailed Description

The invention is described in further detail below with reference to the figures and specific embodiments.

Fig. 1 is a general flowchart of a compilation rule-based Android system static partitioning method, which includes the following steps:

and S1, analyzing git engineering in the Android source code to obtain a git engineering set in the Android source code. When downloading the Android source code, the Android source code is found to be synchronized by a plurality of git sources, each git source is an independent project, and a git project list is obtained from a manifest.

Android uses git as a code management tool, a repo command line tool is developed, git partial commands are packaged, a git library is effectively organized, when Android source codes are downloaded, a repo init-u URL [ OPTIONS ] command is executed, a list in the manifest is cloned to the local in a repo/manifest xml file, wherein the address is from a-u parameter, and the link is a symbolic link and points to the repo/manifests/default xml file. Xml the contents of:

xml contains the address (remote fetch tag) of the acquired project, the version (default review tag) of the acquired project, and the name (projec/name tag) and path (project/path tag) of all projects contained in the version. From this list, we can obtain all the engineering and name path information contained in a set of source codes to be analyzed.

And S2, acquiring module related information by analyzing the make database.

S21, designing a module information storage table field containing the name of the module, the path where the mk file is located, the file and path generated by compiling, the source code file dependent on compiling and the like;

the Android construction system is based on a Make database, and simultaneously uses some GNU Make extensions. Each project (for a git source) in the Android has a plurality of android.mk, each android.mk can define a plurality of target files, and the types of the target files mainly include C/C + + related STATIC LIBRARY, EXECUTABLE file, SHARED LIBRARY, Java related STATIC JAVA LIBRARY, and PACKAGE PACKAGE.

The GNU Make program provides a command line parameter-p allows the print Make database. The-n command line option is used herein when actually acquiring the database, and specifies a non-existent target. Thus, Make does not really perform building the object, nor does Make it place too much extraneous data in the dump file. The output of Make-n-p is two parts, the first is the output of executing Make command, and the second is the dump of Make database.

S23, analyzing the txt file stored in S22, extracting module information, and outputting a make-n-p command, wherein the output structure is as follows:

the open header is the version information of the GNU Make, followed by the output of the Make command, which is empty due to the use of the-n option. Following a row of '# Make data base, printd on $ DATE' indicating the beginning of the Make database, followed by the portion of the database, each type of data beginning with a row of annotations, '# Variables' including all global Variables as well as the macro function definition; '# Implicit Rules' general Rules, e.g., Rules for.c files through.o files; '# Files' includes a generation rule for each file in the format "target: dependency1dependency 2", after which the definition of all local variables is given by notation, and finally the command executed by the build target.

In this step, the information in '# Variables' needs to be analyzed. The Android construction system inserts global variables named by the following rules when generating the rule of each package: android model $ ATTR. Where $ MODEL is the packet name and $ ATTR is one of BUILT, CHECKED, INSTALLED, PATH, REQUERD, STUBS, below. The invention concerns PATH, BUILT and INSTALLED. Analyzing the rows containing the keywords and storing the analyzed rows into a database table designed by S21; this step is shown in fig. 2, and specifically includes the following steps:

a) establishing a module information storage table in a Mysql database, wherein the table comprises a module name, a module type and a path;

b) reading the txt file according to lines, and extracting lines starting with ALL _ MODULES;

c) analyzing the content of $ ATTR in the line extracted in b), judging which one of PATH, BUILT and INSTALLED is, and correspondingly storing the module information into a table designed in S21; when a new line is extracted every time, judging whether the information exists in a module information storage table according to the module name, if not, storing the information into a data record, and if so, updating the record and storing the information of $ ATTR into a corresponding field;

d) in the data stored in c, one piece of information may contain a plurality of BUILT information, the invention takes each module with the same name and different BUILTs as an independent module, separates each record containing a plurality of BUILT information in c, and leads each record to only store one piece of module information;

e) and extracting git engineering information and storing the git engineering information into a module information storage table.

S3, after obtaining the make database through S2 and storing the make database in txt, extracting a file set which is depended on when each binary file is compiled from the txt; extracting information of '# Files' and storing the information into a database table designed in S21 as described in S23; this step is shown in fig. 3, and specifically includes the following steps:

a) establishing a dependency relationship storage table in a database;

b) reading the txt file according to lines, extracting out, namely the initial line, and storing the data of the file dependency relationship of all modules into the table established in a);

c) sequentially reading BUILT information of the module from the module information table, searching the dependent data of the module from the dependent relationship table, and establishing a tuple for storing the dependent data;

d) sequentially judging the dependent data, adding the dependent data to the tuple when the data is a source code file, judging whether the data is a module in the module information table if the data is not the source code file, and if the data is not the source code file, not operating; if not, recursively searching data depended by the file in the dependency relationship table;

e) and updating the src field in the module information table according to the acquired result.

After S3 is executed, the screenshot of the relevant experimental data is shown in fig. 5, which only intercepts part of the content as an illustration, where each of the lines 1 to 28 is the basic information of a module, including the name, type, path, BUILT, insert, and dependent file information.

And S4, dividing the module inclusion relation according to the inclusion relation of the dependency file. After the file on which each module is compiled is acquired in S3, the modules are divided into inclusion relationships by relying on the inclusion relationships of the files.

And S41, dividing the layer into an APP layer, a FRAMEWORKS layer, a library and runtime layer and a HAL layer by taking the Android basic architecture diagram as reference, wherein the FRAMEWORKS layer is further divided into an API layer, a SERVICE layer, a JNI layer and a SERVICE support layer. Each module carries out hierarchical division according to the path of the mk file depended on by the compiling module and the file type generated by compiling, and the implementation mode is as follows:

1) compiling to generate an APPS type, and dividing the APPS type into an APP layer;

2) in particular, APIs are ultimately used in the form of andorid. jar, which is not available in the module generated by compilation, so all APIs in the system can be crawled from the official website;

3) compiling to generate JAVA _ LIBRARIES type, and dividing the JAVA _ LIBRARIES type into a SERVICE layer;

4) the module name contains JNI/JNI and is compiled to generate STATIC _ LIABARIES or SHARED _ LIBRARIES, and the JNI layer is divided into the module name;

5) the PATH starts with FRAMEWORK and is compiled to generate STATIC _ LIABARIES or SHARED _ LIBRARIES, and the PATH is divided into service support layers;

6) PATH starts with DALVIK or ART and is divided into running time layers;

7) PATH begins with EXTERNAL/BIONIC and is compiled to generate STATIC _ LIABARIES or SHARED _ LIBRARIES, which is divided into library layers;

8) PATH starts with hardway, which is divided into HAL layers.

And S42, generating module parent-child relations. Git is taken as a primary module, the PATH (namely the extracted PATH information) where mk of the primary module is located is taken as a base number, other modules take the PATH as the basis, the parent-child relationship is positioned according to the inclusion relationship of PATH characters, and the inclusion relationship among the modules is formed preliminarily; such as: if the PATH of module A is a and the PATH of module B is a/B, then B is defined as the sub-module of A.

S43, adjusting the parent-child relationship generated in S42 according to the file containing relationship depended by the module, the specific implementation method is as follows: processing parent-child relationships to each set (one primary module as one set); judging the number of 2 levels in the set, namely the number of lines, finding leaf nodes of each line, and processing line by line: taking a221 and a222 in fig. 4 as an example, their upper level is a22, and their SRC _ filters is determined:

1) if it is

The SRC _ FILES relationship between the A22 and the sub-module is judged successively, the sub-module which has intersection or the same with the A22 moves to the upper level, and the sub-module which is taken as the peer module of A22, contains the A22 and becomes the parent module of A22;

e.g.,

lines

960 and 961 in fig. 6, it is determined by the path that 960 is the parent of 961, but their actual src _ files are the same, changing their parent-child relationship to a sibling relationship.

2) If it is

Maintaining existing parent-child relationships;

as in fig. 7,

parent modules

92 and 93 are along path 91, and src _ files contained in 91 is greater than the aggregate of 92 and 93, the relationship of

parent modules

92 and 93 is maintained 91.

3) If A22 and A221+ A222 have intersection, the SRC _ FILES relationship between A22 and the sub-module is judged successively, and the sub-module having intersection or the same with A22 is moved to the previous stage to be used as the peer module of A22.

For example,

lines

664, 666, 667, 670, 672, 674 in fig. 8, are parents of 666, 667, 670, 672, 674 by path 664, except 670, the src _ files other submodules of 664 do not intersect, so they are changed to peer modules;

4) if A22 and A221+ A222 do not have any intersection and inclusion relationship, A221 and A222 are moved up as sibling modules of A22.

As in fig. 9, by

path

53, 54, 55, 56 are all children of 52, but there is no cross relationship between src _ files of parent and child, their parent-child relationship is changed to sibling.

And at this point, the division of the parent-child relationship of the modules is finished.

Another embodiment of the present invention provides a compilation rule-based Android system static partitioning apparatus, which includes a memory and a processor, wherein the memory stores a computer program configured to be executed by the processor, and the computer program includes instructions for executing the steps of the method described above.

Another embodiment of the invention provides a computer-readable storage medium storing a computer program which, when executed by a computer, performs the steps of the method described above.

The invention has not been described in detail and is part of the common general knowledge of a person skilled in the art.

After the make-n-p command is executed, the module information in the make database is printed and output and extracted, and the module information can be analyzed and acquired in all makefiles in the android source code or extracted in the log information actually compiled and output, so that the data acquisition is not influenced.

The above description is only an embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can understand that the modifications or substitutions within the technical scope of the present invention are included in the scope of the present invention, and therefore, the scope of the present invention should be subject to the protection scope of the claims.

Claims

1. A compiling rule based Android system static partitioning method is characterized by comprising the following steps:

s4, dividing the inclusion relation of the modules according to the inclusion relation of the dependent files in the file set, which is depended on during the compilation of the git engineering path and the binary file, and dividing the Android system source code into a tree structure comprising a plurality of modules;

the method for dividing the inclusion relationship of the modules in step S4 includes:

s41, dividing the system into APP layer, FRAMEWORKS layer, library and operation layer, HAL layer, wherein FRAMEWORKS layer is further divided into API layer, SERVICE layer, JNI layer, SERVICE support layer; each module carries out hierarchical division according to the path of the mk file depended on by the compiling module and the file type generated by compiling;

s42, taking git engineering as a primary module, taking the path of the primary module as a base number, and based on the path, positioning parent-child relationship of other modules according to the inclusion relationship of path characters to preliminarily form the inclusion relationship among the modules;

and S43, adjusting the parent-child relationship generated in S42 according to the inclusion relationship of the dependent files in the file set which is dependent during the compilation of the binary files extracted in S3, and forming the final inclusion relationship among the modules.

2. The compilation rule-based Android system static partitioning method of claim 1, wherein: the method for acquiring git engineering in the Android source code in the step S1 comprises the following steps: the Android system source code to be analyzed is downloaded by using a repo in a Linux system, after the repo init-u URL [ OPTIONS ] is executed, the names and paths of all git projects contained in the source code are analyzed from manifest.

3. The compilation rule-based Android system static partitioning method of claim 1, wherein step S2 comprises:

s21, designing a database table for storing module information;

s22, executing make-n-p, and storing the information of printout into a txt file;

s23, analyzing the txt file stored in S22, and extracting basic information including module names, paths and construction targets.

4. The compilation rule-based Android system static partitioning method of claim 3, wherein: step S23 obtains basic information of the MODULE by analyzing a global variable, where the global variable is Android $ MODULE $ ATTR, where $ MODULE is a name of the package, and $ ATTR is one of BUILT, CHECKED, INSTALLED, PATH, REQUIRED, and STUBS.

5. The compilation rule-based Android system static partitioning method of claim 4, wherein: and S23, analyzing the lines containing the PATH, BUILT and INSTALLED keywords, and storing the lines into a designed database table S21.

6. The compilation rule-based Android system static partitioning method according to claim 3, wherein: the method for extracting the file set dependent on each binary file during compiling in step S3 includes: and extracting compiling rule information in the make database, including the generation rule of each module, filtering out source code files depending on the modules, and storing the source code files into a database table designed in S21 after the source code files are analyzed.

7. The compiling rule-based Android system static partitioning method of claim 1, wherein the hierarchical partitioning method in step S41 is as follows:

2) all APIs crawl from the official web;

6) PATH starts with DALVIK or ART and is divided into running time layers;

8) PATH starts with hardway, which is divided into HAL layers.

8. An apparatus for static partitioning of Android system based on compilation rules, comprising a memory and a processor, the memory storing a computer program configured to be executed by the processor, the computer program comprising instructions for carrying out the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer, performs the steps of the method of any one of claims 1 to 7.