CN106775842B - Customizable dex subpackaging method - Google Patents

Customizable dex subpackaging method Download PDF

Info

Publication number
CN106775842B
CN106775842B CN201611079969.8A CN201611079969A CN106775842B CN 106775842 B CN106775842 B CN 106775842B CN 201611079969 A CN201611079969 A CN 201611079969A CN 106775842 B CN106775842 B CN 106775842B
Authority
CN
China
Prior art keywords
class
dex
file
reserved
main
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201611079969.8A
Other languages
Chinese (zh)
Other versions
CN106775842A (en
Inventor
李天成
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Kuwo Technology Co Ltd
Original Assignee
Beijing Kuwo Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Kuwo Technology Co Ltd filed Critical Beijing Kuwo Technology Co Ltd
Priority to CN201611079969.8A priority Critical patent/CN106775842B/en
Publication of CN106775842A publication Critical patent/CN106775842A/en
Application granted granted Critical
Publication of CN106775842B publication Critical patent/CN106775842B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G06F9/4451—User profiles; Roaming

Abstract

The invention relates to a customizable dex subcontracting method, which is characterized in that rule files are configured according to classes required by the first starting and loading of app, wherein the files comprise custom configured main _ dex reserved class rule files; in the compiling process, when a dex preposition task is executed, searching the dependency relationship of the self-defined configured main _ dex reserved class according to the rule file in the step 101, and outputting the full path names of all the found dependency classes of the self-defined configured main _ dex reserved class to a specified file; the full pathname list of dependent classes described in the specified file is merged with the default main _ dex reserved class file list that the system generates at build time. According to the invention, in the process of generating the dex file, dependency analysis is carried out on the Class file, the main dex file is dynamically specified, an error INSTALL FAILED DEXOPT is avoided when the application is installed, and the phenomenon that the application is crashed and cannot be used due to the occurrence of Class Not Found Exception during operation is avoided.

Description

Customizable dex subpackaging method
Technical Field
The invention relates to the technical field of dex file conversion, in particular to a customizable dex subpackaging method.
Background
In the android system, as the business scale develops, new codes and new class libraries are continuously added in the development of the app, and when the number of methods in the engineering exceeds 65535, the following error INSTALL FAILEDDEXOPT is encountered, so that the app cannot be installed and the development cannot be carried out.
The reasons why the above problems occur are: since the Android system uses the Dalvik virtual machine, it is necessary to convert the class file after being compiled using Java Compiler into a dex file that Dalvik can execute. dexOpt (a tool within the system to optimize the dex file and view details of the source file) optimizes the dex file when the Android system launches an application (app). DexOpt will retrieve the method id of each class, and store the method id in a linked list structure, but the length of the linked list is stored by a short type, so that the number of the method id cannot exceed 65535.
The Dexopt uses a fixed-size buffer LinearAlloc to store the application's method information. The LinearAlloc of Android2.2 and 2.3 is only 5MB, and Android 4.x is improved to 8MB or 16 MB. When the number of methods is too large, the size of the buffer area LinearAloc is exceeded, which also causes the Dexopt to crash.
Prior art solutions to this are typically: this problem is solved using google official multitex Support Library, which is implemented by compiling class into different classes. This method has the following technical drawbacks:
the method has the advantages that the method cannot automatically and intelligently specify which classes must be contained in the main dex according to the actual requirements of a project, manual analysis is needed, and the manual specification of which classes should be placed in the main dex.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a method for self-defining dex subcontracting, which is used for performing dependency analysis on Class files in the process of generating dex files, dynamically appointing a main dex file, avoiding an error INSTALL FAILED DEXOPT during application installation and avoiding that the application is crashed and can Not be used due to the occurrence of Class Not Found Exception during operation.
In order to achieve the above purposes, the technical scheme adopted by the invention is as follows:
a method for self-defining dex sub-packets is characterized by comprising the following steps:
step 101, configuring rule files according to classes required by the first startup and loading of the app, wherein the rule files comprise main _ dex reserved class rule files configured in a user-defined mode;
102, in the compiling process, when a dex preposition task is executed, searching the dependency relationship of the self-defined configured main _ dex reserved class according to the rule file in the step 101, and outputting the full path names of all the found dependency classes of the self-defined configured main _ dex reserved class to a specified file;
step 103, merging the full path name list of the dependent classes recorded in the specified file in step 102 with the default main _ dex reserved class file list generated by the system during construction.
Based on the above technical solution, in step 101, the class required for the first startup and loading of the app, particularly, the class required for the startup page and the program initialization.
On the basis of the above technical solution, in step 101, the rule file records classes that are desired to be retained in main _ dex;
the specific format of the rule is as follows:
a single class is reserved, with class: at the beginning, the full path name of the class file is one line;
the entire class library is retained, in jar: starting, taking the full path name of the class library as a line;
and represents wildcard characters.
On the basis of the above technical solution, the specific steps of step 102 are as follows:
step 201, inserting a custom Task into a generated main _ dex Task queue in the compiling process of an Android Gradle script;
step 202, in the custom Task, calling an analysis tool to perform loop analysis on the main _ dex reserved class configured by the custom in step 101 and the class depended by the reserved class.
On the basis of the above technical solution, in step 201, the Task queue refers to a Task queue that needs to be experienced when compiling and constructing an application by using an Android Gradle script, and a main _ dex file list is generated.
On the basis of the technical scheme, in the user-defined Task, a Class dependency Analyzer analysis tool is called, and the generation of a mail _ dex file list is intervened dynamically.
On the basis of the above technical solution, the specific steps of step 202 are as follows:
step 301, reading the rule file in step 101, and storing all reserved class file name lists in the rule file in a memory;
step 302, reading a mapping file generated after system confusion, and searching for all confused class names corresponding to the reserved class file name list in step 301 according to a corresponding relation between the confused file and the unapproved file, wherein the confused class names are the confused class file names;
step 303, calling a Class Dependency Analyzer analysis tool, using the obfuscated Class file name read in step 302 as an index, finding out the Dependency relationship of the Class through the constant pool of Class file byte codes, and outputting the found Dependency Class of the reserved Class to a temporary file, and then using the found Dependency Class of the reserved Class as an index, and continuing to call the Class Dependency Analyzer analysis tool until the Dependency relationship of the Class cannot be found.
On the basis of the above technical solution, in step 103, the full path name list of all the inter-dependent classes described in the temporary file in step 303 is merged with the default main _ dex reserved class file list generated during the system building, so as to complete the purpose of generating the main _ dex reserved class file list by the intervention system.
The customizable dex subpackaging method is embedded in the packaging process, dependency analysis is carried out on a main dex file list of a system, necessary Class files are packaged into the main dex when a program is started while missing, the dependence on artificial analysis on the main dex file is not relied on, incomplete artificial factor analysis is avoided, the occurrence of Class NotFound exclusion caused by incorrect analysis is avoided, the application collapse cannot be used, and the stability and the reliability are good.
The method for the customizable dex subpackage has good applicability to all other android project projects.
Drawings
The invention has the following drawings:
FIG. 1 is a flow chart of the method of the present invention.
FIG. 2 is a flow chart of a loop analysis performed by the analysis tool.
Detailed Description
The present invention will be described in further detail with reference to the accompanying drawings.
As shown in fig. 1, the method for customizable dex packetization described in the present invention includes the following steps:
step 101, configuring rule files according to classes necessary for the first startup and loading of the app (particularly, classes necessary for startup pages and program initialization), wherein the rule files comprise user-defined configured main _ dex reserved class rule files;
102, in the compiling process, when a dex preposition task is executed, searching the dependency relationship of the self-defined configured main _ dex reserved class according to the rule file in the step 101, and outputting the full path names of all the found dependency classes of the self-defined configured main _ dex reserved class to a specified file;
step 103, merging the full path name list of the dependent classes recorded in the specified file in step 102 with the default main _ dex reserved class file list generated by the system during construction.
On the basis of the above technical solution, in step 101, the rule file records classes that are desired to be retained in main _ dex;
the specific format of the rule is as follows:
a single class is reserved, with class: at the beginning, the full path name of the class file is one line;
the entire class library is retained, in jar: starting, taking the full path name of the class library as a line;
and represents wildcard characters.
On the basis of the above technical solution, the specific steps of step 102 are as follows:
step 201, inserting a custom Task into a generated main _ dex Task queue in a compiling process (referring to compiling and constructing an application) of an Android Gradle script;
step 202, in the custom Task, calling an analysis tool to perform loop analysis on the main _ dex reserved class configured by the custom in step 101 and the class depended by the reserved class.
On the basis of the above technical solution, in step 201, the Task queue refers to a Task queue that needs to be experienced when an application is built by compiling an Android Gradle script (i.e., a default main _ dex reserved class file list), and the Task queue specifically includes the following Task queues:
Task1：collectReleaseMultiDexComponents
the Task1 keeps Activity, Service, broadcast, ContentProvider, Instrumentation, application, according to android manifest, and outputs to:
build\intermediates\multi-dex\release\manifest_keep.txt
Task2：PackageAllReleaseClassesForMultiDex
the Task2 packs all the jars, outputs to: build \ intermedia \ multi-dex \ release \ classes
Task3：ShrinkReleaseMultiDexComponents
The Task3 generates obfuscated jar according to manifest _ keep.txt generated by Task1 and allclasses.jar generated by Task2, and adds the proguard obfuscated file, and outputs the obfuscated jar to:
build\intermediates\multi-dex\release\componentClasses.jar
Task4：createReleaseMainDexClassList
the Task4 finally generates main dex list, class file containing all main _ dex, according to components classes, jar generated by Task3 and classes, jar generated by Task2 above, and outputs to:
build\intermediates\multi-dex\release\maindexlist.txt
. And inserting custom Task tasks into Task queues of Task 1-4.
On the basis of the technical scheme, in the user-defined Task, a Class dependency Analyzer analysis tool is called, and the generation of a mail _ dex file list is intervened dynamically.
On the basis of the above technical solution, as shown in fig. 2, the specific steps of step 202 are as follows:
step 301, reading the rule file in step 101, and storing all reserved class file name lists in the rule file in a memory;
step 302, reading a mapping file generated after system confusion, and searching for all confused class names corresponding to the reserved class file name list in step 301 according to a corresponding relation between the confused file and the unapproved file, wherein the confused class names are the confused class file names;
the correspondence can be accurately found by the format of the class generated after obfuscation, which is followed by the class name ": "as a notation, the following is an example:
the class name "android.
The obfuscated class name "android.a.a.a:",
step 303, calling a Class Dependency Analyzer analysis tool, using the obfuscated Class filename read in step 302 as an index, finding out the Dependency relationship of the Class through a constant pool of Class file bytecode, where the dependencies include dependencies of classes appearing in super classes, fields, methods, and interfaces, outputting the found Dependency Class of the reserved Class to a temporary file, and then using the found Dependency Class of the reserved Class as an index, and continuing to call the Class Dependency Analyzer analysis tool until the Dependency relationship of the Class cannot be found.
On the basis of the above technical solution, in step 103, the full path name list of all the inter-dependent classes described in the temporary file in step 303 is merged with the default main _ dex reserved class file list generated during the system building, so as to complete the purpose of generating the main _ dex reserved class file list by the intervention system.
Those not described in detail in this specification are within the skill of the art.

Claims (8)

1. A method for self-defining dex sub-packets is characterized by comprising the following steps:
step 101, configuring rule files according to classes required by the first startup and loading of the app, wherein the rule files comprise main _ dex reserved class rule files configured in a user-defined mode;
102, in the compiling process, when a dex preposition task is executed, searching the dependency relationship of the self-defined configured main _ dex reserved class according to the self-defined configured main _ dex reserved class rule file in the step 101, and outputting the found full path names of all the dependency classes of the self-defined configured main _ dex reserved class to a specified file;
step 103, merging the full path name list of the dependent classes recorded in the specified file in step 102 with the default main _ dex reserved class file list generated by the system during construction.
2. The method of customizable dex packetization according to claim 1, characterized in that: in step 101, the class required for the first boot loading of the app refers to a class required for booting a page and initializing a program.
3. The method of customizable dex packetization according to claim 1, characterized in that: in step 101, the user-defined configured main _ dex reserved class rule file records classes which are expected to be reserved in main _ dex;
the specific format of the rule is as follows:
a single class is reserved, with class: at the beginning, the full path name of the class file is one line;
the entire class library is retained, in jar: starting, taking the full path name of the class library as a line;
and represents wildcard characters.
4. The method of customizable dex packetization according to claim 1, characterized in that: the specific steps of step 102 are as follows:
step 201, inserting a custom Task into a generated main _ dex Task queue in the compiling process of an Android Gradle script;
step 202, in the custom Task, calling an analysis tool to perform loop analysis on the main _ dex reserved class configured by the custom in step 101 and the class depended by the reserved class.
5. The method of customizable dex packetization according to claim 4, characterized in that: in step 201, the Task queue refers to a Task queue that needs to be experienced when the Android Gradle script compiles and constructs an application and generates a main _ dex file list.
6. The method of customizable dex packetization according to claim 4, characterized in that: in the custom Task, a Class Dependency Analyzer analysis tool is called to dynamically intervene in the generation of the main _ dex file list.
7. The method of customizable dex packetization according to claim 4, characterized in that: the specific steps of step 202 are as follows:
step 301, reading the custom configured main _ dex reserved rule file in step 101, and storing all the reserved class file name lists in the custom configured main _ dex reserved rule file in a memory;
step 302, reading a mapping file generated after system confusion, and searching for all confused class names corresponding to the reserved class file name list in step 301 according to a corresponding relation between the confused file and the unapproved file, wherein the confused class names are the confused class file names;
step 303, calling a Class Dependency Analyzer analysis tool, using the obfuscated Class file name read in step 302 as an index, finding out the Dependency relationship of the Class through the constant pool of Class file byte codes, and outputting the found Dependency Class of the reserved Class to a temporary file, and then using the found Dependency Class of the reserved Class as an index, and continuing to call the Class Dependency Analyzer analysis tool until the Dependency relationship of the Class cannot be found.
8. The method of customizable dex packetization according to claim 7, characterized in that: in step 103, the full path name list of all the interdependent classes recorded in the temporary file in step 303 is merged with the default main _ dex reserved class file list generated by the system during construction, so as to fulfill the purpose of generating the main _ dex reserved class file list by the intervention system.
CN201611079969.8A 2016-11-30 2016-11-30 Customizable dex subpackaging method Active CN106775842B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611079969.8A CN106775842B (en) 2016-11-30 2016-11-30 Customizable dex subpackaging method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611079969.8A CN106775842B (en) 2016-11-30 2016-11-30 Customizable dex subpackaging method

Publications (2)

Publication Number Publication Date
CN106775842A CN106775842A (en) 2017-05-31
CN106775842B true CN106775842B (en) 2020-02-11

Family

ID=58901215

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611079969.8A Active CN106775842B (en) 2016-11-30 2016-11-30 Customizable dex subpackaging method

Country Status (1)

Country Link
CN (1) CN106775842B (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107315593A (en) * 2017-06-29 2017-11-03 广州优视网络科技有限公司 application program packaging method, device and terminal device
CN107609394A (en) * 2017-08-28 2018-01-19 上海移卓网络科技有限公司 Tamper resistant method, storage device and the device of Android installation kits
CN109947493A (en) * 2017-12-19 2019-06-28 珠海市君天电子科技有限公司 Application program launching method, device, electronic equipment and storage medium
CN111552518B (en) * 2019-01-24 2023-04-07 阿里巴巴集团控股有限公司 Method and device for loading control for starting application
CN110502222B (en) * 2019-07-23 2023-03-21 北京字节跳动网络技术有限公司 AAR method, apparatus, medium, and device for outbound dependency on internal base repository
CN110806906B (en) * 2019-10-30 2022-04-12 腾讯科技（深圳）有限公司 Dex subpackage method, device, equipment and medium
CN111352631B (en) * 2020-02-21 2024-03-19 腾讯音乐娱乐科技（深圳）有限公司 Interface compatibility detection method and device

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015154612A1 (en) * 2014-10-08 2015-10-15 中兴通讯股份有限公司 Method and device for extending apk file application

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104426658B (en) * 2013-09-02 2017-12-01 中国移动通信集团公司 The method and device of authentication is carried out to the application on mobile terminal
CN104866504B (en) * 2014-02-25 2018-07-06 北京娜迦信息科技发展有限公司 A kind of method and device that Function Extension is carried out to Android software
CN105577720B (en) * 2014-10-15 2020-04-10 中兴通讯股份有限公司 Method and system for packaging mobile application

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015154612A1 (en) * 2014-10-08 2015-10-15 中兴通讯股份有限公司 Method and device for extending apk file application

Also Published As

Publication number Publication date
CN106775842A (en) 2017-05-31

Similar Documents

Publication Publication Date Title
CN106775842B (en) Customizable dex subpackaging method
KR101143112B1 (en) Applying custom software image updates to non-volatile storage in a failsafe manner
CN109491695B (en) Incremental updating method for integrated android application
US8375382B2 (en) Enabling parallel websphere runtime versions
JP5957084B2 (en) Generate compiled code indicating register survival
US8185889B2 (en) Methods and systems for porting software packages from one format to another
CN109791483B (en) Shared software library for computing devices
KR101636870B1 (en) Method and apparatus for generating minimal boot image
US20040088694A1 (en) Systems and methods for updating software
US20120005445A1 (en) Memory allocation with identification of requesting loadable kernel module
US8762967B2 (en) Program compiler, program installer, and program install method
US20120317349A1 (en) Processing device and writing method for writing a file to a storage medium
CN114398145A (en) Method for operating non-root Linux by Jailhouse based on X86 platform
CN114651233A (en) Instant container
US20070180433A1 (en) Method to enable accurate application packaging and deployment with optimized disk space usage
CN112099880B (en) Method and system for reducing application program driven by scene
US20130007439A1 (en) Multicore processor system, computer product, and notification method
CN114281597A (en) Adaptive thermal reload for class change
CN113867768A (en) Operating system processing method and device, electronic equipment and storage medium
US10552135B1 (en) Reducing a size of an application package
US20170357558A1 (en) Apparatus and method to enable a corrected program to take over data used before correction thereof
CN112540799A (en) Management method, system, terminal device and storage medium of startup data
CN106201546B (en) Full-scale formatting method and system for large disks in linux system installation processes
US20180032564A1 (en) Techniques of automatically generating dependencies for applications in embedded systems
CN116680013B (en) Compiling and developing method and device for separating system foundation bag from application program

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant