A method for automatically embedding public code into Android App

Abstract

The present invention discloses a method for automatically implanting public code into Android App, comprising the following steps: S100, extracting public code to main APP, and packaging to form public APP; S200, decompiling the public APP and third-party APP respectively; S300, modifying and correcting the third-party APP decompiled file according to the public APP decompiled file. The method for automatically implanting public code into Android App provided by the present invention is reasonably designed, and realizes interactive communication between APPs by means of decompiled packaged implanted code. The whole process can be realized by automated code written in Python, which greatly reduces the labor cost and time cost compared with the traditional method of manually integrating SDK to realize interactive communication between APPs, and has stronger scalability.

Description

Technical Field

[0001] The present invention relates to the technical field of Android systems, and in particular to a method for automatically implanting public codes into Android Apps. Background Art

[0002] Currently in the development process of Android APP, when a large number of third-party apps need to implement common communication logic with the self-made apps (such as channel statistics, background query, App billing, etc.), the method usually adopted is to make SDKs (software development kits) and integrate them into each app one by one. This method is quite time-consuming and troublesome, has poor scalability, and has certain defects. Summary of the invention

[0003] The purpose of the present invention is to provide a method for automatically implanting common code into Android App, which realizes communication between APPs by means of decompiled packaged implanted code, thereby reducing manpower cost and time cost.

[0004] To solve the above technical problems, the present invention provides a method for automatically implanting public code into Android App, comprising the following steps:

[0005] S100, extracting the public code to the main APP and packaging it to form a public APP;

[0006] S200, decompile the public APP and the third-party APP respectively;

[0007] S300. Modify and correct the third-party APP decompiled file according to the public APP decompiled file.

[0008] Furthermore, in step S100, the common code includes a startup page and a logic Services.

[0009] Furthermore, in step S300, the modification and correction specifically includes the following steps:

[0010] S301, copy the resource files and smali files decompiled by the public APP to the corresponding directories of the resource files and smali files decompiled by the third-party APP;

[0011] S302, obtaining the package name and startup page of the androidmanifest.xml file decompiled from the third-party App;

[0012] S303, modify and edit the package name and class name to be started in the smali file decompiled by the public App;

[0013] S304, adding the startup page Activity configuration in the androidmanifest.xml file decompiled from the public APP to the androidmanifest.xml file decompiled from the third-party App;

[0014] S305, modifying the startup page of the androidmanifest.xml file decompiled from the third-party App.

[0015] Furthermore, in step S302, the specific operation of obtaining the package name and the startup page is: parsing the androidmanifest.xml file decompiled from the third-party App to parse out the package name and the startup page.

[0016] Furthermore, in step S305, the specific steps of modifying the startup page and the package name are:

[0017] S315, modifying the startup page of the androidmanifest.xml file decompiled from the third-party App to a normal page;

[0018] S325, repackage and sign the modified androidmanifest.xml file.

[0019] Furthermore, the entire process of steps S100, S200 and S300 is written in Python.

[0020] Furthermore, the androidmanifest.xml file is parsed using SAX.

[0021] Through the above technical solution, the present invention has the following beneficial effects:

[0022] The present invention is reasonably designed. It realizes interactive communication between APPs by means of decompiled packaged implanted codes. The whole process can be realized by automated codes written in Python. Compared with the traditional method of manually integrating SDK to realize interactive communication between APPs, it greatly reduces the labor cost and time cost, and has stronger scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 The present invention is a flowchart of a method for automatically implanting public code into an Android App. DETAILED DESCRIPTION

[0024] The method of automatically implanting common code into Android App of the present invention will be described in more detail below in conjunction with the schematic diagram, wherein the preferred embodiment of the present invention is shown, and it should be understood that those skilled in the art can modify the present invention described herein, while still achieving the advantageous effects of the present invention. Therefore, the following description should be understood as being widely known to those skilled in the art, and not as a limitation of the present invention.

[0025] The present invention is described in more detail in the following paragraphs by way of example with reference to the accompanying drawings. The advantages and features of the present invention will become more apparent from the following description and claims. It should be noted that the drawings are in very simplified form and in non-precise proportions, and are only used to facilitate and clearly assist in illustrating the purpose of the embodiments of the present invention.

[0026] like Figure 1 As shown, the embodiment of the present invention proposes a method for automatically implanting public code into an Android App, comprising the following steps:

[0027] S100, extracting the public code to the main APP and packaging it to form a public APP;

[0028] Specifically, common code is also called general code, also known as general programming, which is a computer programming style in which algorithms are written according to the types to be specified, and then instantiated with specific types provided as parameters when needed. In this step, the common code uses a startup page and writes a logical service in it. The position of the logical service in the architecture is very critical. It is between the data access layer and the presentation layer, and plays a connecting role in data exchange.

[0029] S200, decompile the public APP and the third-party APP respectively;

[0030] Specifically, decompilation refers to the work of "reverse analysis and research" on the target program (such as executable program) of other people's software to deduce the design elements such as ideas, principles, structures, algorithms, processing procedures, and operation methods used by other people's software products. In certain specific cases, the source code may be derived; decompilation can be automatically operated through decompilation software, such as apktool. Apktool is an apk compilation tool provided by Google, which can decompile and back compile apk, and install the framework-res framework required for decompiling system apk, clean up the last decompilation folder, etc. Use apktool to decompile public APP and third-party APP respectively, and you can get the resource files and smali files of public APP and the resource files and smali files of third-party APP. The operation of decompilation software such as apktool is a prior art and will not be elaborated here.

[0031] Specifically, in this step, a decompilation tool is used to decompile the public APP and the third-party APP to obtain the source code of the public APP and the third-party APP, thereby facilitating the subsequent implantation of the public code into the third-party APP.

[0032] S300. Modify and correct the third-party APP decompiled file according to the public APP decompiled file.

[0033] Specifically, because it is necessary to connect to different third-party apps, two strings are reserved in the public app (one represents the package name of the implanted app (i.e., the third-party app), and the other represents the original startup page class name of the implanted app). After parsing the package name and startup page class name of the implanted app, the corresponding smali file directory in the folder decompiled from the public app is copied to the smali directory decompiled from the implanted app, and the two reserved strings in the copied smali file are modified to the parsed package name and startup page class name.

[0034] The implantation mainly requires copying the smali file decompiled from the public App to the smali directory of the decompiled third-party App, modifying the copied smali file, and modifying the AndroidManifest.xml file decompiled from the implanted App.

[0035] Specifically, the modification and correction includes the following steps:

[0036] S301, copy the resource files and smali files decompiled by the public APP to the corresponding directories of the resource files and smali files decompiled by the third-party APP.

[0037] S302, obtaining the package name and startup page of the androidmanifest.xml file decompiled from the third-party App.

[0038] Specifically, each application must contain an AndroidManifest.xml file in the root directory. The AndroidManifest.xml file is an information description file of the entire application, which defines the Activity, Service, Contentprovider, and BroadcastReceiver component information contained in the application.

[0039] The androidmanifest.xml file is parsed using SAX, which stands for Simple APIs for XML. The access mode provided by SAX is a sequential mode, which is a fast way to read and write XML data. When using the SAX parser to parse an XML document, a series of events will be triggered and the corresponding event processing functions will be activated. The application accesses the XML document through these event processing functions, so the SAX interface is also called the event-driven interface SAX. However, as an interface, SAX is a standard interface for event-driven XML parsing and will not change. The working principle of SAX is simply to scan the document sequentially, and notify the event processing function when scanning to the beginning and end of the document, the beginning and end of the element, the end of the document, etc. The event processing function takes corresponding actions and then continues the same scan until the end of the document.

[0040] By using SAX to parse the androidmanifest.xml file decompiled from the third-party App, its package name and startup page can be parsed, and the package name and startup page of the androidmanifest.xml file decompiled from the third-party App can be obtained.

[0041] Specifically, the xml file is parsed through Python's xml.dom.minidom package, the package name is found through package character comparison, and the startup page is found through the "android.intent.category.LAUNCHER" startup page attribute.

[0042] S303, modify and edit the package name and class name that need to be started in the smali file decompiled by the public App.

[0043] Specifically, no matter it is a common class, abstract class, interface class or inner class, they are all stored in separate smali files in the decompiled code. The smali file consists of three parts: the first part is the class-related information, the second part is the class description, and the third part is the method information. The complete class includes the package name and class name.

[0044] S304, adding the startup page Activity configuration in the androidmanifest.xml file decompiled from the public APP to the androidmanifest.xml file decompiled from the third-party App.

[0045] Specifically, the smali copied to the third-party APP is the implanted code. We modify the startup page of the implanted App to the startup page of the public App, start the implanted code in it, and then immediately jump to the original startup page of the implanted App, so that the user is unaware.

[0046] S305, modifying the startup page of the androidmanifest.xml file decompiled from the third-party App.

[0047] Specifically, the specific steps for modifying the startup page of the androidmanifest.xml file decompiled from the third-party App are as follows: first, modify the original startup page of the androidmanifest.xml file decompiled from the third-party App to a normal page, and then repackage and sign the modified androidmanifest.xml file. Packaging is to generate an installation package based on signatures and other identifiers. The Android system requires that each Android application must be digitally signed before it can be installed in the system; the signature is some data attached to the data unit, or a cryptographic transformation of the data unit; this data or transformation allows the recipient of the data unit to confirm the source and integrity of the data unit and protect the data to prevent it from being forged by others (such as the recipient). It is a method of signing electronic messages. A signed message can be transmitted in a communication network, and digital signatures can be obtained based on both public key cryptography and private key cryptography. Currently, the digital signature based on the public key cryptography system is mainly used. The digital signature of the public key cryptography system includes ordinary digital signatures and special digital signatures. Ordinary digital signature algorithms include RSA, ElGamal, Fiat-Shamir, Guillou-Quisquarter, Schnorr, Ong-Schnorr-Shamir digital signature algorithm, Des / DSA elliptic curve digital signature algorithm and finite automaton digital signature algorithm; special digital signatures include blind signature, proxy signature, group signature, non-repudiation signature, fair blind signature, threshold signature, signature with message recovery function, etc. The specific operation of repackaging and signing the APP is existing technology and will not be described here. By repackaging and signing the third-party APP that has undergone the above processing, the third-party APP will be opened with the implanted startup page, and the public code service will be started to communicate with the main APP through AIDL and other logic.

[0048] Specifically, the entire process above is written in Python, which is a substitute for a language called ABC. The Python interpreter is easy to expand, and new functions and data types can be expanded using C or C++ (or other languages ​​that can be called through C). Python can also be used as an extension language in customizable software, because of its rich standard library, it provides source code or machine code suitable for various major system platforms. Therefore, the entire process is written in Python, which ensures good scalability.

[0049] In summary, the present invention has the following advantages over the prior art:

[0050] The present invention is reasonably designed. It realizes interactive communication between APPs by means of decompiled packaged implanted codes. The whole process can be realized by automated codes written in Python. Compared with the traditional method of manually integrating SDK to realize interactive communication between APPs, it greatly reduces the labor cost and time cost, and has stronger scalability.

[0051] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A method for automatically embedding public code into an Android App, characterized in that: The steps include: S100, extracting the public code to the main APP, and packaging it to form a public APP, wherein the public code includes a startup page and a logical Service, and the logical Service is located between the data access layer and the presentation layer; the public APP reserves a string representing the package name of the third-party APP and the original startup page class name of the third-party APP; S200, decompile the public APP and the third-party APP respectively; S300, modifying and correcting the third-party APP decompiled file according to the public APP decompiled file; The modification and correction specifically includes the following steps: S301, copy the resource files and smali files decompiled by the public APP to the corresponding directories of the resource files and smali files decompiled by the third-party APP; S302, obtaining the package name and startup page of the androidmanifest.xml file decompiled from the third-party App; S303, modify and edit the package name and class name to be started in the smali file decompiled by the public App; S304, adding the startup page Activity configuration in the androidmanifest.xml file decompiled from the public APP to the androidmanifest.xml file decompiled from the third-party App; S305, modifying the startup page of the androidmanifest.xml file decompiled from the third-party App.

2. The method for automatically embedding public code into Android App as claimed in claim 1, characterized in that: In step S302, the specific operation of obtaining the package name and the startup page is: parsing the androidmanifest.xml file decompiled from the third-party App to parse out the package name and the startup page.

3. The method for automatically embedding public code into Android App as claimed in claim 1, characterized in that: In step S305, the specific steps of modifying the startup page and package name are: S315, modifying the startup page of the androidmanifest.xml file decompiled from the third-party App to a normal page; S325, repackage and sign the modified androidmanifest.xml file.

4. The method for automatically embedding public code into Android App as claimed in claim 1, characterized in that: The entire process of steps S100, S200 and S300 is written in Python.

5. The method for automatically embedding public code into Android App as claimed in claim 2, characterized in that: The androidmanifest.xml file is parsed using SAX.

Images