WO2019169721A1 - 应用多渠道打包方法、装置、计算机设备及存储介质 - Google Patents

应用多渠道打包方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
WO2019169721A1
WO2019169721A1 PCT/CN2018/085253 CN2018085253W WO2019169721A1 WO 2019169721 A1 WO2019169721 A1 WO 2019169721A1 CN 2018085253 W CN2018085253 W CN 2018085253W WO 2019169721 A1 WO2019169721 A1 WO 2019169721A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
plaintext
channel
link variable
sub
Prior art date
Application number
PCT/CN2018/085253
Other languages
English (en)
French (fr)
Inventor
杨文�
Original Assignee
平安科技（深圳）有限公司
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 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019169721A1 publication Critical patent/WO2019169721A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Definitions

  • the present application relates to the field of Android application development technologies, and in particular, to an application multi-channel packaging method, device, computer device, and storage medium.
  • Android applications that is, applications in Android
  • OS generally adopt the following schemes when multi-channel packaging:
  • the present application provides an application multi-channel packaging method, device, computer device and storage medium, which is intended to solve the problem of multi-channel packaging in the prior art, and each time a channel package is added, the build.gradle needs to be modified, and productFlavors defines the channel number, and the code cannot be modified during the packaging process, resulting in inefficient packaging and error-prone problems.
  • the present application provides an application multi-channel packaging method, which includes: obtaining an apk installation package, adjusting a suffix name of an apk installation package to a preset suffix name by using a first script, and decompressing and decompressing.
  • File obtain multiple sub-files included in the decompressed file, perform sub-files for SHA1 operations, and obtain one-to-one corresponding file digests; respectively, the file digests corresponding to the sub-files are respectively Base64-encoded, and one-to-one with the file digest Corresponding hash value, storing the hash value corresponding to the file summary one by one into the directory of the subfile; creating a channel label file by using the second script in the subfile directory, corresponding to the channel identifier according to the channel number to be configured
  • the file is named, and the decompressed file including the channel data is obtained; the decompressed file is compressed by the third script to obtain the channel package.
  • an application multi-channel packaging device including:
  • the decompression unit is configured to obtain an apk installation package, and adjust a suffix name of the apk installation package to a preset suffix name set by a first script, and decompress the decompressed file to obtain a decompressed file;
  • the file summary obtaining unit is configured to obtain a plurality of sub-files included in the decompressed file, and perform sub-files respectively to perform SHA1 operations to obtain one-to-one corresponding file digests;
  • a coding unit configured to perform Base64 encoding on the file digest corresponding to the sub-files, respectively, to obtain a hash value corresponding to the file digest, and store the hash value corresponding to the file digest one-to-one into the directory of the sub-file.
  • the channel name adding unit is configured to create a channel labeling file by using a second script in the directory of the subfile, correspondingly naming the channel labeling file according to the channel number to be configured, and obtaining a decompressing file including the channel data;
  • the channel package packing unit is configured to compress the decompressed file by using a third script to obtain a channel package.
  • the present application further provides a computer device comprising a memory, a processor, and a computer program stored on the memory and operable on the processor, the processor implementing the computer program
  • a computer device comprising a memory, a processor, and a computer program stored on the memory and operable on the processor, the processor implementing the computer program
  • the present application also provides a storage medium, wherein the storage medium stores a computer program, the computer program comprising program instructions, the program instructions, when executed by a processor, causing the processor to execute the application Any of the applications described in the multi-channel packaging method.
  • the application provides a multi-channel packaging method, device, computer device and storage medium.
  • the method realizes the automation of the channel package packaging, simplifies the process of playing the channel package, and improves the packaging efficiency and success rate.
  • FIG. 1 is a schematic flowchart of a method for applying multi-channel packing according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of a sub-flow of an application multi-channel packaging method according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of another sub-flow of an application multi-channel packaging method according to an embodiment of the present application.
  • FIG. 4 is a schematic diagram of another sub-flow of an application multi-channel packaging method according to an embodiment of the present disclosure
  • FIG. 5 is a schematic block diagram of an application multi-channel packing apparatus according to an embodiment of the present application.
  • FIG. 6 is a schematic block diagram of a subunit of an application multi-channel packing apparatus according to an embodiment of the present application.
  • FIG. 7 is a schematic block diagram of another subunit of an application multi-channel packing apparatus according to an embodiment of the present disclosure.
  • FIG. 8 is a schematic block diagram of another subunit of an application multi-channel packing apparatus according to an embodiment of the present disclosure.
  • FIG. 9 is a schematic block diagram of a computer device according to an embodiment of the present application.
  • FIG. 1 is a schematic flowchart of an application multi-channel packaging method according to an embodiment of the present application. The method is applied to terminals such as desktop computers, laptop computers, and tablet computers. As shown in FIG. 1, the method includes steps S101 to S105.
  • the suffix name of the apk installation package is adjusted to .zip by using the first script (that is, the preset suffix name is .zip). Since the Android installation package is an apk file (because it is a .apk suffix, it is often called an apk installation package), it is a zip file itself, just modify the .zip suffix to .apk.
  • the first script can be used to modify the .apk file suffix to the suffix name of .zip, and then extract it with zip decompression software. After decompression, it generally includes META-INF, res, AndroidManifest.xml, classes.dex , resources.arsc these 5 files or directories.
  • META-INF META-INF
  • res AndroidManifest.xml
  • classes.dex classes.dex
  • resources.arsc these 5 files or directories.
  • each apk installation package will be apk installation package through the first script.
  • the suffix name is changed from .apk to .zip, and the decompressed file is extracted.
  • the modified suffix name in the present application is automatically performed by the first script script, and the user does not need to manually modify it, thereby improving the efficiency of suffix name modification.
  • the decompressed file includes five subfiles, namely an AndroidManifest.xml file, a classes.dex file, a res file, a META-INF file, and a resources.arsc file; wherein the AndroidManifest.xml file is a global program.
  • the configuration file, the classes.dex file is the Dalvik bytecode file, the res file is the resource storage file, the META-INF file is the signature information file, and the resources.arsc file is the compiled binary resource file.
  • step S102 the sub-files are respectively subjected to SHA1 operations, and the one-to-one corresponding file digest includes the following sub-steps:
  • S1021 Obtain a plaintext of the res file, and obtain a first file digest by using a SHA1 hash algorithm to operate the plaintext of the res file;
  • S1023 Obtain the plaintext of the classes.dex file, and obtain the third file summary by using the SHA1 hash algorithm operation in the plaintext of the classes.dex file;
  • S1024 Obtain the plaintext of the resources.arsc file, and obtain the fourth file summary by using the SHA1 hash algorithm to operate the plaintext of the resources.arsc file.
  • the SHA1 operation and the subsequent Base64 encoding are performed on the plaintexts of the four subfiles of the res file, the AndroidManifest.xml file, the classes.dex file, and the resources.arsc file in the decompressed file, respectively, for the decompressed file.
  • Digitally sign to ensure the security of the application package.
  • the res file, the AndroidManifest.xml file, the classes.dex file, and the resources.arsc file are selected for digital signature, and the META-INF file is not digitally signed because the META-INF file is a file for storing signature information. There is no need to digitally sign it.
  • step S1021 As shown in FIG. 3, the following sub-steps are included in the step S1021:
  • S10212 Divide the first plaintext packet into 16 32-bit sub-plain packets
  • S10214 Expand each of the 16 plaintext packets included in the first plaintext packet into 5 sub-plaintext packets, and obtain 80 sub-plaintext packets corresponding to the first plaintext packet.
  • S10215 Perform SHA1 operation on 80 sub-plain packets corresponding to the first plaintext packet, to obtain a current link variable.
  • the link variable of the first plaintext packet is used as an initial link variable of the second plaintext packet, and the calculation is repeated until the link variable of the second plaintext packet, the link variable of the third plaintext packet, and the link variable of the fourth plaintext packet are respectively obtained.
  • a link variable of five clear text groups
  • S10218 Serially connect the link variables of the fifth plaintext packet to obtain a 160-bit first file digest.
  • the number of total characters in the plaintext is divided by 512 for grouping. If there are less than 512 characters in the group corresponding to the remainder, the character is complemented by 512 characters (for example, 4800 in the plaintext). Characters, 4800 divided by 512 quotient of 9 remainder is 192, then their plaintext is grouped into 10 groups, of which only one of the 192 characters in the plaintext group is supplemented with 320 0 characters).
  • the SHA1 operation includes 4 rounds of operations, each round consists of 20 steps, a total of 80 steps. When the first step of the first round of operations begins processing, the values of the five link variables A, B, C, D, and E are first. Assigned to the other five recording units A', B', C', D', E'. These five values will be retained for summing with the link variables A, B, C, D, E after the last step of the fourth round is completed.
  • W t M t (When 0 ⁇ t ⁇ 15), (When 16 ⁇ t ⁇ 79).
  • the link variable B initial value is cyclically shifted left by 30 bits to the link variable C;
  • the initial value of the link variable D is assigned to the link variable E.
  • K i 0, 1, 2, ... 79
  • the link variable of the first plaintext packet is obtained by the SHA1 prescribed four rounds operation, and so on, the link variable of the first plaintext packet is used as the initial link variable of the second plaintext packet, and the calculation is repeated until the link variable of the second plaintext packet is respectively obtained.
  • the link variable of the third plaintext packet, the link variable of the fourth plaintext packet, and the link variable of the fifth plaintext packet is obtained.
  • the plaintext of the AndroidManifest.xml file is obtained by the SHA1 hash algorithm to obtain the second file summary
  • the plaintext of the classes.dex file is obtained by the SHA1 hash algorithm to obtain the third file summary
  • the plaintext of the resources.arsc file is passed through the SHA1.
  • the process of obtaining the fourth file digest by the hash algorithm operation refers to the calculation process of obtaining the first file digest by using the SHA1 hash algorithm to operate the plaintext of the res file.
  • S103 Perform a Base64 encoding on the file digest corresponding to the sub-files respectively, obtain a hash value corresponding to the file digest, and store the hash value corresponding to the file digest one-to-one into the directory of the sub-file.
  • the first file digest performs a Base64 encoded first hash value
  • the second file digest performs a Base64 encoded second hash value
  • the third file digest performs a Base64 encoded third hash value
  • the fourth hash of the fourth file summary for Base64 encoding is stored in the directory of the META-INF file.
  • BASE64 is an encoding method commonly used to encode binary data into data in the form of writable characters. This is a reversible coding method.
  • step S104 As shown in FIG. 4, the following sub-steps are included in the step S104:
  • S1042 Obtain a channel number to be configured, and modify an empty file name to a channel number to be configured by using a second script, where the channel number includes a channel label character header and a channel name.
  • the channel label file is an empty file and the name of the empty file is automatically changed to the channel number to be configured by the second script. For example, starting with ssj, the channel name is connected by an underscore, so that ssj_baidu can know the Android application. The channel is called baidu. And the empty file of the channel identification file is included in the META-INF directory of the decompressed file, indicating that the decompressed file is a decompressed file including the channel data.
  • the N script to write N corresponding channel data to the N apk installation package, create an empty file in the META-INF directory after decompressing each apk installation package, and then the name of the empty file is based on The channel number to be configured is modified accordingly; for example, the first channel label file of the sjj_baidu name is created in the META-INF directory after the first apk installation package is decompressed (the first channel label file is an empty file named only by sjj_baidu), the second apk Create the second channel label file of sjj_tencent under the META-INF directory after decompression of the installation package (same reason, the second channel label file is an empty file named only by sjj_tencent).
  • the channel package identification is realized through a simple process, and the packaging efficiency of the channel package is improved.
  • compressing the decompressed file by the third script is also an automatic compression process, and does not require manual operation by the user.
  • the method realizes the packaging automation of the Android application, and does not need to manually configure the parameters of the packaging tool, and does not need to deploy a separate server, thereby improving the packaging efficiency and success rate.
  • FIG. 5 is a schematic block diagram of an application multi-channel packing apparatus according to an embodiment of the present application.
  • the application multi-channel packaging device 100 can be installed in a desktop computer, a tablet computer, a laptop computer, and the like.
  • the application multi-channel packaging apparatus 100 includes a decompression unit 101, a file digest obtaining unit 102, an encoding unit 103, a channel name adding unit 104, and a channel packet packing unit 105.
  • the decompression unit 101 is configured to obtain an apk installation package, adjust a suffix name of the apk installation package to a preset suffix name set by a first script, and decompress the decompressed file to obtain a decompressed file.
  • the suffix name of the apk installation package is adjusted to .zip by using the first script (that is, the preset suffix name is .zip). Since the Android installation package is an apk file (because it is a .apk suffix, it is often called an apk installation package), it is a zip file itself, but the .zip suffix is modified to .apk.
  • the first script can be used to modify the .apk file suffix to the suffix name of .zip, and then extract it with zip decompression software. After decompression, it generally includes META-INF, res, AndroidManifest.xml, classes.dex , resources.arsc these 5 files or directories.
  • META-INF META-INF
  • res AndroidManifest.xml
  • classes.dex classes.dex
  • resources.arsc these 5 files or directories.
  • each apk installation package will be apk installation package through the first script.
  • the suffix name is changed from .apk to .zip, and the decompressed file is extracted.
  • the modified suffix name in the present application is automatically performed by the first script script, and the user does not need to manually modify it, thereby improving the efficiency of suffix name modification.
  • the file summary obtaining unit 102 is configured to obtain a plurality of sub-files included in the decompressed file, and perform sub-files on the SHA1 operation to obtain a one-to-one corresponding file digest.
  • the decompressed file includes five subfiles, namely an AndroidManifest.xml file, a classes.dex file, a res file, a META-INF file, and a resources.arsc file; wherein the AndroidManifest.xml file is a global program.
  • the configuration file, the classes.dex file is the Dalvik bytecode file, the res file is the resource storage file, the META-INF file is the signature information file, and the resources.arsc file is the compiled binary resource file.
  • the file summary obtaining unit 102 includes the following subunits:
  • the first file summary obtaining unit 1021 is configured to obtain the plaintext of the res file, and obtain the first file digest by using the SHA1 hash algorithm to calculate the plaintext of the res file;
  • the second file summary obtaining unit 1022 is configured to obtain the plaintext of the AndroidManifest.xml file, and obtain the second file summary by using the SHA1 hash algorithm operation of the plaintext of the AndroidManifest.xml file;
  • the third file summary obtaining unit 1023 is configured to obtain the plaintext of the classes.dex file, and obtain the third file summary by using the SHA1 hash algorithm operation in the plaintext of the classes.dex file;
  • the fourth file summary obtaining unit 1024 is configured to obtain the plaintext of the resources.arsc file, and obtain the fourth file summary by using the SHA1 hash algorithm operation of the plaintext of the resources.arsc file.
  • the SHA1 operation and the subsequent Base64 encoding are performed on the plaintexts of the four subfiles of the res file, the AndroidManifest.xml file, the classes.dex file, and the resources.arsc file in the decompressed file, respectively, for the decompressed file.
  • Digitally sign to ensure the security of the application package.
  • the res file, the AndroidManifest.xml file, the classes.dex file, and the resources.arsc file are selected for digital signature, and the META-INF file is not digitally signed because the META-INF file is a file for storing signature information. There is no need to digitally sign it.
  • the first file digest obtaining unit 1021 includes the following subunits:
  • the first grouping unit 10211 is configured to divide the plaintext of the res file into a plurality of 512-bit plaintext packets, which are respectively recorded as the first plaintext packet to the Nth plaintext packet; wherein N is a positive integer;
  • a second grouping unit 10212 configured to divide the first plaintext packet into 16 32-bit sub-plain packets
  • the link variable creation unit 10213 is configured to create five 32-bit link variables, which are respectively recorded as an A link variable, a B link variable, a C link variable, a D link variable, and an E link variable;
  • the packet extension unit 10214 is configured to expand each of the 16 plaintext packets included in the first plaintext packet into 5 sub-plaintext packets, to obtain 80 sub-plain packets corresponding to the first plaintext packet;
  • the SHA1 operation unit 10215 is configured to perform SHA1 operation on the 80 sub-plain packets corresponding to the first plaintext packet to obtain a current link variable.
  • variable summation unit 10216 is configured to sum the current link variable of the first plaintext packet with the initial link variable to obtain a link variable of the first plaintext packet;
  • the repetition calculation unit 10217 is configured to use the link variable of the first plaintext packet as an initial link variable of the second plaintext packet, and repeat the calculation until the link variable of the second plaintext packet, the link variable of the third plaintext packet, and the fourth plaintext packet are respectively acquired.
  • variable concatenation unit 10218 is configured to serially link the link variables of the fifth plaintext packet to obtain a 160-bit first file digest.
  • the SHA1 operation includes four rounds of operations, each round includes 20 steps, a total of 80 steps, and when the first step of the first round of operations begins processing, five, A, B, C, D, and E
  • the value in the link variable is first assigned to the other five record units A', B', C', D', E'. These five values will be retained for summing with the link variables A, B, C, D, E after the last step of the fourth round is completed.
  • the link variable of the first plaintext packet is obtained by the SHA1 prescribed four rounds operation, and so on, the link variable of the first plaintext packet is used as the initial link variable of the second plaintext packet, and the calculation is repeated until the link variable of the second plaintext packet is respectively obtained.
  • the link variable of the third plaintext packet, the link variable of the fourth plaintext packet, and the link variable of the fifth plaintext packet is obtained.
  • the plaintext of the AndroidManifest.xml file is obtained by the SHA1 hash algorithm to obtain the second file summary
  • the plaintext of the classes.dex file is obtained by the SHA1 hash algorithm to obtain the third file summary
  • the plaintext of the resources.arsc file is passed through the SHA1.
  • the process of obtaining the fourth file digest by the hash algorithm operation refers to the calculation process of obtaining the first file digest by using the SHA1 hash algorithm to operate the plaintext of the res file.
  • the encoding unit 103 is configured to perform Base64 encoding on the file digest corresponding to the sub-files, respectively, to obtain a hash value corresponding to the file digest, and store the hash value corresponding to the file digest one-to-one to the sub-file directory. in.
  • the first file digest performs a Base64 encoded first hash value
  • the second file digest performs a Base64 encoded second hash value
  • the third file digest performs a Base64 encoded third hash value
  • the fourth hash of the fourth file summary for Base64 encoding is stored in the directory of the META-INF file.
  • BASE64 is an encoding method commonly used to encode binary data into data in the form of writable characters. This is a reversible coding method.
  • the channel name adding unit 104 is configured to create a channel labeling file by using a second script in the directory of the subfile, correspondingly naming the channel labeling file according to the channel number to be configured, and obtaining a decompressing file including the channel data.
  • the channel name adding unit 104 includes the following subunits:
  • An empty file creating unit 1041 configured to create an empty file in a directory of the subfile by using the second script
  • the name modification unit 1042 is configured to obtain the channel number to be configured, and modify the empty file name to the channel number to be configured by using the second script.
  • the channel number includes a channel identifier character header and a channel name.
  • the channel label file is an empty file and the name of the empty file is automatically changed to the channel number to be configured by the second script. For example, starting with ssj, the channel name is connected by an underscore, so that ssj_baidu can know the Android application. The channel is called baidu. And the empty file of the channel identification file is included in the META-INF directory of the decompressed file, indicating that the decompressed file is a decompressed file including the channel data.
  • the N script to write N corresponding channel data to the N apk installation package, create an empty file in the META-INF directory after decompressing each apk installation package, and then the name of the empty file is based on The channel number to be configured is modified accordingly; for example, the first channel label file of the sjj_baidu name is created in the META-INF directory after the first apk installation package is decompressed (the first channel label file is an empty file named only by sjj_baidu), the second apk Create the second channel label file of sjj_tencent under the META-INF directory after decompression of the installation package (same reason, the second channel label file is an empty file named only by sjj_tencent).
  • the channel package identifier is realized through a simple process, and the packaging efficiency of the channel package is improved.
  • the channel package packing unit 105 is configured to compress the decompressed file by using a third script to obtain a channel package.
  • compressing the decompressed file by the third script is also an automatic compression process, and does not require manual operation by the user.
  • the device realizes the packaging automation of the Android application, and does not need to manually configure the parameters of the packaging tool, and does not need to deploy a separate server, thereby improving the packaging efficiency and success rate.
  • the above-described application multi-channel packaging device can be implemented in the form of a computer program that can be run on a computer device as shown in FIG.
  • FIG. 9 is a schematic block diagram of a computer device according to an embodiment of the present application.
  • the computer device 500 device can be a terminal.
  • the terminal can be an electronic device such as a tablet computer, a notebook computer, a desktop computer, or a personal digital assistant.
  • the computer device 500 includes a processor 502, a memory, and a network interface 505 connected by a system bus 501, wherein the memory can include a non-volatile storage medium 503 and an internal memory 504.
  • the non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032.
  • the computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform an application multi-channel packaging method.
  • the processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.
  • the internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503, which when executed by the processor 502, may cause the processor 502 to perform an application multi-channel packaging method.
  • the network interface 505 is used for network communication, such as sending assigned tasks and the like. It will be understood by those skilled in the art that the structure shown in FIG. 9 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation of the computer device 500 to which the solution of the present application is applied, and a specific computer device. 500 may include more or fewer components than shown, or some components may be combined, or have different component arrangements.
  • the processor 502 is configured to run a computer program 5032 stored in the memory to implement the following functions: acquiring an apk installation package, and adjusting a suffix name of the apk installation package to a preset suffix name set by a first script, and Decompressing and decompressing the file; obtaining a plurality of sub-files included in the decompressed file, performing sub-files on the SHA1 operation to obtain one-to-one correspondence; and extracting the file digests corresponding to the sub-files by Base64 coding respectively a hash value corresponding to the file summary, storing the hash value corresponding to the file summary one by one into the directory of the subfile; creating a channel label file by using the second script in the subfile directory, corresponding to the to-be-configured The channel number names the channel label file, and obtains the decompressed file including the channel data; the third file is used to compress the decompressed file to obtain the channel package.
  • the processor 502 further performs the following operations: acquiring the plaintext of the res file, obtaining the first file digest by using the SHA1 hash algorithm of the res file; obtaining the plaintext of the AndroidManifest.xml file, and the AndroidManifest.xml file
  • the clear text is obtained by the SHA1 hash algorithm to obtain the second file digest; the plaintext of the classes.dex file is obtained, and the plaintext of the classes.dex file is obtained by the SHA1 hash algorithm to obtain the third file digest; obtaining the plaintext of the resources.arsc file,
  • the plaintext of the resources.arsc file is obtained by the SHA1 hash algorithm to obtain a fourth file digest; wherein the decompressed file includes five subfiles, namely an AndroidManifest.xml file, a classes.dex file, a res file, and a META-INF file.
  • resources.arsc file is the program global configuration file
  • the classes.dex file is the Dalvik bytecode file
  • the res file is the resource storage file
  • the META-INF file is the signature information file
  • the resources.arsc file is compiled. After the binary resource file.
  • the processor 502 further performs the following operations: dividing the plaintext of the res file into a plurality of 512-bit plaintext packets, respectively, as the first plaintext packet to the Nth plaintext packet; wherein N is a positive integer; A plaintext group is divided into 16 32-bit sub-plain text groups; five 32-bit link variables are created, which are respectively recorded as A link variable, B link variable, C link variable, D link variable, E link variable; Each of the 16 plaintext packets included in the plaintext packet is expanded into 5 sub-plaintext packets to obtain 80 sub-plaintext packets corresponding to the first plaintext packet; and the SHA1 operation is performed on 80 sub-texture packets corresponding to the first plaintext packet.
  • the processor 502 further performs the following operations: performing a Base64 encoded first hash value on the first file digest, a Base64 encoded second hash value in the second file digest, and a third file digest on the Base64 encoding.
  • the third hash value, and the fourth hash of the fourth file summary for Base64 encoding are stored in the directory of the META-INF file.
  • the processor 502 further performs the following operations: creating an empty file in the directory of the subfile by using the second script; obtaining the channel number to be configured, and modifying the empty file name to the channel number to be configured by using the second script
  • the channel number includes a channel label character header and a channel name.
  • the embodiment of the computer device shown in FIG. 9 does not constitute a limitation on the specific configuration of the computer device.
  • the computer device may include more or fewer components than illustrated. Or combine some parts, or different parts.
  • the computer device may include only a memory and a processor. In such an embodiment, the structure and functions of the memory and the processor are the same as those of the embodiment shown in FIG. 9, and details are not described herein.
  • the processor 502 may be a central processing unit (CPU), and the processor 502 may also be another general-purpose processor, a digital signal processor (DSP), Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc.
  • the general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • a storage medium in another embodiment, can be a non-transitory computer readable storage medium.
  • the storage medium stores a computer program, wherein the computer program includes program instructions.
  • the program instruction is executed by the processor, the multi-channel packaging method is applied to the embodiment of the present application.
  • the storage medium may be an internal storage unit of the aforementioned device, such as a hard disk or a memory of the device.
  • the storage medium may also be an external storage device of the device, such as a plug-in hard disk equipped on the device, a smart memory card (SMC), a secure digital (SD) card, and a flash memory card. (Flash Card), etc.
  • the storage medium may also include both an internal storage unit of the device and an external storage device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了一种应用多渠道打包方法、装置、计算机设备及存储介质。该方法包括：获取apk安装包，通过第一脚本将apk安装包的后缀名调整至指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件并分别进行SHA1运算，得到一一对应的文件摘要；将文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值并存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。该方法实现了渠道包打包自动化，简化了打渠道包的过程，提高了打包效率和成功率。

Description

应用多渠道打包方法、装置、计算机设备及存储介质
本申请要求于2018年3月8日提交中国专利局、申请号为201810191443.1、申请名称为“应用多渠道打包方法、装置、计算机设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及安卓应用开发技术领域，尤其涉及一种应用多渠道打包方法、装置、计算机设备及存储介质。
背景技术
目前，Android应用(即安卓系统中的应用程序)在进行多渠道打包时，一般采用如下方案：
1)在AndroidManifest.xml文件中定义mate-data标签，设置渠道占位符；
2)在工程build.gradle文件下的productFlavors定义渠道号(其中，gradle文件是一个项目自动化构建工具；productFlavors用于定义产品的特性)；
采取上述方式进行多渠道打包时，每次增加一个渠道包时，需要修改build.gradle，还需在productFlavors定义渠道号，也即当需要配置多个渠道包就会执行相同次数的打包签名的操作，导致操作复杂。具体的，当每次开始打包都会修改AndroidManifest.xml文件，将渠道占位符替换为真实地渠道名称，然后在执行编译，开始一次完整的打包流程。所以多个渠道编译打包耗时＝每个渠道包编译的耗时总和＝(或者近似等于)N*一个渠道的编译打包时间，其中N为渠道总数目。而且在打包的过程中不能修改代码，以避免出错。通过这种方式实现多渠道打包非常耗时，生产效率很低。
发明内容
本申请提供了一种应用多渠道打包方法、装置、计算机设备及存储介质，旨在解决现有技术中进行多渠道打包时，每次增加一个渠道包时，需要修改build.gradle，还需在productFlavors定义渠道号，而且打包的过程中不能修改代 码，导致打包效率低下，且容易出错的问题。
第一方面，本申请提供了一种应用多渠道打包方法，其包括：获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。
第二方面，本申请提供了一种应用多渠道打包装置，其包括：
解压单元，用于获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
文件摘要获取单元，用于获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
编码单元，用于将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
渠道名增加单元，用于在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
渠道包打包单元，用于通过第三脚本将解压文件进行压缩，得到渠道包。
第三方面，本申请又提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本申请提供的任一项所述的应用多渠道打包方法。
第四方面，本申请还提供了一种存储介质，其中所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行本申请提供的任一项所述的应用多渠道打包方法。
本申请提供一种应用多渠道打包方法、装置、计算机设备及存储介质。该方法实现了渠道包打包自动化，简化了打渠道包的过程，提高了打包效率和成功率。
附图说明
为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种应用多渠道打包方法的示意流程图；
图2是本申请实施例提供的一种应用多渠道打包方法的子流程示意图；
图3是本申请实施例提供的一种应用多渠道打包方法的另一子流程示意图；
图4为本申请实施例提供的一种应用多渠道打包方法的另一子流程示意图；
图5为本申请实施例提供的一种应用多渠道打包装置的示意性框图；
图6为本申请实施例提供的一种应用多渠道打包装置的子单元示意性框图；
图7为本申请实施例提供的一种应用多渠道打包装置的另一子单元示意性框图；
图8为本申请实施例提供的一种应用多渠道打包装置的另一子单元示意性框图；
图9为本申请实施例提供的一种计算机设备的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参阅图1，图1是本申请实施例提供的一种应用多渠道打包方法的示意流程图。该方法应用于台式电脑、手提电脑、平板电脑等终端中。如图1所示，该方法包括步骤S101～S105。
S101、获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件。
在本实施例中，在获取apk安装包后，通过第一脚本将apk安装包的后缀名调整至.zip(即预先设置的指定后缀名为.zip)。由于Android安装包是一个apk 文件(因为是以.apk为后缀，所以也常称之为apk安装包)，其本身就是一个zip压缩文件，只是将.zip后缀修改为了.apk。
本申请中先通过第一脚本可以将.apk文件后缀修改为.zip的后缀名，然后用zip解压缩软件将其解压出来，解压之后一般包括META-INF、res、AndroidManifest.xml、classes.dex、resources.arsc这5个文件或目录。若要实现对apk安装包写入N个不同的渠道数据，此时获取了apk安装包后，是将其复制为N个apk安装包，每一apk安装包都通过第一脚本将apk安装包的后缀名由.apk修改为.zip，并解压得到解压后文件。本申请中修改后缀名是通过第一脚本脚本自动进行，无需用户手动修改，提高了后缀名修改的效率。
S102、获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要。
在一实施例中，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件。
如图2所示，所述步骤S102中将子文件分别进行SHA1运算，得到一一对应的文件摘要包括以下子步骤：
S1021、获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
S1022、获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
S1023、获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
S1024、获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
在本实施例中，对解压后文件中res文件、AndroidManifest.xml文件、classes.dex文件及resources.arsc文件这4个子文件的明文分别进行SHA1运算和后续的Base64编码，是为了对解压后文件进行数字签名，以确保应用程序包的安全性。本申请中选取res文件、AndroidManifest.xml文件、classes.dex文件及 resources.arsc文件进行数字签名，并不对META-INF文件进行数字签名，是因为META-INF文件是用于存储签名信息的文件，无需对其进行数字签名。
如图3所示，所述步骤S1021中包括以下子步骤：
S10211、将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
S10212、将第一明文分组均分为16个32位的子明文分组；
S10213、创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
S10214、将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
S10215、对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
S10216、将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
S10217、将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
S10218、将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
在本实施例中，按明文中总字符的个数除以512进行分组，若有余数所对应的分组中不足512个字符，则通过补充字符0将其补足至512字符(例如明文中有4800字符，4800除512的商为9余数为192，则将其明文分组为10组，其中只有192个字符中的一组明文分组中则补充320个0字符即可)。SHA1运算包括4轮运算，每一轮包括20个步骤，一共80步，当第1轮运算中的第1步骤开始处理时，A、B、C、D、E五个链接变量中的值先赋值到另外5个记录单元A′，B′，C′，D′，E′中。这5个值将保留，用于在第4轮的最后一个步骤完成之后与链接变量A，B，C，D，E进行求和操作。
SHA1的4轮运算，共80个步骤使用同一个操作程序，如下：
A，B，C，D，E←[(A＜＜＜5)+f t(B，C，D)+E+W t+K t]，A，(B＜＜＜30)，C，D
其中f t(B，C，D)为逻辑函数，W t为子明文分组W[t](t＝0，1，2，……，79)， K t为固定常数，W t＝M t(当0≤t≤15)，
Figure PCTCN2018085253-appb-000001
(当16≤t≤79)。这个操作程序的意义为：
将[(A＜＜＜5)+ft(B，C，D)+E+W t+K t]的结果赋值给链接变量A；
将链接变量A初始值赋值给链接变量B；
将链接变量B初始值循环左移30位赋值给链接变量C；
将链接变量C初始值赋值给链接变量D；
将链接变量D初始值赋值给链接变量E。
SHA1规定4轮运算的逻辑函数如表1所示：
Figure PCTCN2018085253-appb-000002
表1
在操作程序中需要使用固定常数K i(i＝0，1，2，......79)，K i的取值如表2所示：
轮数 步骤数(t) 函数定义
第一轮 0≤t≤19 K t＝5A827999
第二轮 20≤t≤39 K t＝6ED9EBA1
第三轮 40≤t≤59 K t＝8F188CDC
第四轮 60≤t≤79 K t＝CA62C1D6
表2
通过SHA1规定4轮运算得到第一明文分组的链接变量，以此类推，将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量。同样的，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要、将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要、将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要的过程均是参考将res文件的明文通过SHA1哈希算法运算得到第一文件摘要的计算过程。通过上述过程，能快速计算四个文 件摘要。
S103、将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中。
在一实施例中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
BASE64是一种编码方式，通常用于把二进制数据编码为可写的字符形式的数据。这是一种可逆的编码方式。编码后的数据是一个字符串，其中包含的字符为A-Z、a-z、0-9、+、/共64个字符(26+26+10+1+1＝64)。完成上述四个文件摘要的SHA1运算和Base64编码，就实现了对安卓应用的数字签名，提高了其数据安全性。
S104、在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件。
如图4所示，该步骤S104中包括以下子步骤：
S1041、通过第二脚本在子文件的目录中创建空文件；
S1042、获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
在本实施例中，渠道标示文件就是空文件并通过第二脚本自动将该空文件的名称修改为待配置的渠道号，如以ssj开头，通过下划线连接渠道名，这样ssj_baidu就可以知道安卓应用的渠道名为baidu。且在解压文件的META-INF目录下包括了渠道标示文件这一空文件，则表示该解压文件就是一个包括了渠道数据的解压文件。若要实现通过第二脚本对N个apk安装包写入N个相对应的渠道数据，则是在每一个apk安装包解压后的META-INF目录下创建空文件，然后将空文件的名称根据待配置的渠道号相应修改；例如第一apk安装包解压后的META-INF目录下创建sjj_baidu名称的第一渠道标示文件(第一渠道标示文件是只以sjj_baidu命名的空文件)，第二apk安装包解压后的META-INF目录下创建sjj_tencent的第二渠道标示文件(同理，第二渠道标示文件是只以sjj_tencent命名的空文件)等。本申请中，通过在META-INF目录下创建空文件， 并将空文件的名称修改为待配置的渠道号，通过简单的过程就实现了渠道包标识，提高了渠道包的打包效率。
S105、通过第三脚本将解压文件进行压缩，得到渠道包。
在本实施例中，通过第三脚本将解压文件进行压缩，也是一自动压缩的过程，无需用户手动操作。
可见，该方法实现了安卓应用打包自动化，无需手动配置打包工具的参数，也无需部署独立服务器，提高了打包效率和成功率。
本申请实施例还提供一种应用多渠道打包装置，该应用多渠道打包装置用于执行前述任一项应用多渠道打包方法。具体地，请参阅图5，图5是本申请实施例提供的一种应用多渠道打包装置的示意性框图。应用多渠道打包装置100可以安装于台式电脑、平板电脑、手提电脑、等终端中。
如图5所示，应用多渠道打包装置100包括解压单元101、文件摘要获取单元102、编码单元103、渠道名增加单元104、及渠道包打包单元105。
解压单元101，用于获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件。
在本实施例中，在获取apk安装包后，通过第一脚本将apk安装包的后缀名调整至.zip(即预先设置的指定后缀名为.zip)。由于Android安装包是一个apk文件(因为是以.apk为后缀，所以也常称之为apk安装包)，其本身就是一个zip压缩文件，只是将.zip后缀修改为了.apk。
本申请中先通过第一脚本可以将.apk文件后缀修改为.zip的后缀名，然后用zip解压缩软件将其解压出来，解压之后一般包括META-INF、res、AndroidManifest.xml、classes.dex、resources.arsc这5个文件或目录。若要实现对apk安装包写入N个不同的渠道数据，此时获取了apk安装包后，是将其复制为N个apk安装包，每一apk安装包都通过第一脚本将apk安装包的后缀名由.apk修改为.zip，并解压得到解压后文件。本申请中修改后缀名是通过第一脚本脚本自动进行，无需用户手动修改，提高了后缀名修改的效率。
文件摘要获取单元102，用于获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要。
在一实施例中，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、 resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件。
如图6所示，所述文件摘要获取单元102包括以下子单元：
第一文件摘要获取单元1021，用于获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
第二文件摘要获取单元1022，用于获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
第三文件摘要获取单元1023，用于获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
第四文件摘要获取单元1024，用于获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
在本实施例中，对解压后文件中res文件、AndroidManifest.xml文件、classes.dex文件及resources.arsc文件这4个子文件的明文分别进行SHA1运算和后续的Base64编码，是为了对解压后文件进行数字签名，以确保应用程序包的安全性。本申请中选取res文件、AndroidManifest.xml文件、classes.dex文件及resources.arsc文件进行数字签名，并不对META-INF文件进行数字签名，是因为META-INF文件是用于存储签名信息的文件，无需对其进行数字签名。
如图7所示，所述第一文件摘要获取单元1021包括以下子单元：
第一分组单元10211，用于将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
第二分组单元10212，用于将第一明文分组均分为16个32位的子明文分组；
链接变量创建单元10213，用于创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
分组扩展单元10214，用于将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
SHA1运算单元10215，用于对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
变量求和单元10216，用于将第一明文分组的当前链接变量与初始链接变量 求和，得到第一明文分组的链接变量；
重复计算单元10217，用于将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
变量串接单元10218，用于将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
在本实施例中，SHA1运算包括4轮运算，每一轮包括20个步骤，一共80步，当第1轮运算中的第1步骤开始处理时，A、B、C、D、E五个链接变量中的值先赋值到另外5个记录单元A′，B′，C′，D′，E′中。这5个值将保留，用于在第4轮的最后一个步骤完成之后与链接变量A，B，C，D，E进行求和操作。
通过SHA1规定4轮运算得到第一明文分组的链接变量，以此类推，将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量。同样的，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要、将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要、将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要的过程均是参考将res文件的明文通过SHA1哈希算法运算得到第一文件摘要的计算过程。通过上述过程，能快速计算四个文件摘要。
编码单元103，用于将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中。
在一实施例中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
BASE64是一种编码方式，通常用于把二进制数据编码为可写的字符形式的数据。这是一种可逆的编码方式。编码后的数据是一个字符串，其中包含的字符为A-Z、a-z、0-9、+、/共64个字符(26+26+10+1+1＝64)。完成上述 四个文件摘要的SHA1运算和Base64编码，就实现了对安卓应用的数字签名，提高了其数据安全性。
渠道名增加单元104，用于在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件。
如图8所示，所述渠道名增加单元104包括以下子单元：
空文件创建单元1041，用于通过第二脚本在子文件的目录中创建空文件；
名称修改单元1042，用于获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
在本实施例中，渠道标示文件就是空文件并通过第二脚本自动将该空文件的名称修改为待配置的渠道号，如以ssj开头，通过下划线连接渠道名，这样ssj_baidu就可以知道安卓应用的渠道名为baidu。且在解压文件的META-INF目录下包括了渠道标示文件这一空文件，则表示该解压文件就是一个包括了渠道数据的解压文件。若要实现通过第二脚本对N个apk安装包写入N个相对应的渠道数据，则是在每一个apk安装包解压后的META-INF目录下创建空文件，然后将空文件的名称根据待配置的渠道号相应修改；例如第一apk安装包解压后的META-INF目录下创建sjj_baidu名称的第一渠道标示文件(第一渠道标示文件是只以sjj_baidu命名的空文件)，第二apk安装包解压后的META-INF目录下创建sjj_tencent的第二渠道标示文件(同理，第二渠道标示文件是只以sjj_tencent命名的空文件)等。本申请中，通过在META-INF目录下创建空文件，并将空文件的名称修改为待配置的渠道号，通过简单的过程就实现了渠道包标识，提高了渠道包的打包效率。
渠道包打包单元105，用于通过第三脚本将解压文件进行压缩，得到渠道包。
在本实施例中，通过第三脚本将解压文件进行压缩，也是一自动压缩的过程，无需用户手动操作。
可见，该装置实现了安卓应用打包自动化，无需手动配置打包工具的参数，也无需部署独立服务器，提高了打包效率和成功率。
上述应用多渠道打包装置可以实现为一种计算机程序的形式，该计算机程序可以在如图9所示的计算机设备上运行。
请参阅图9，图9是本申请实施例提供的一种计算机设备的示意性框图。该 计算机设备500设备可以是终端。该终端可以是平板电脑、笔记本电脑、台式电脑、个人数字助理等电子设备。
参阅图9，该计算机设备500包括通过系统总线501连接的处理器502、存储器和网络接口505，其中，存储器可以包括非易失性存储介质503和内存储器504。该非易失性存储介质503可存储操作系统5031和计算机程序5032。该计算机程序5032包括程序指令，该程序指令被执行时，可使得处理器502执行一种应用多渠道打包方法。该处理器502用于提供计算和控制能力，支撑整个计算机设备500的运行。该内存储器504为非易失性存储介质503中的计算机程序5032的运行提供环境，该计算机程序5032被处理器502执行时，可使得处理器502执行一种应用多渠道打包方法。该网络接口505用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图9中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备500的限定，具体的计算机设备500可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
其中，所述处理器502用于运行存储在存储器中的计算机程序5032，以实现如下功能：获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。
在一实施例中，处理器502还执行如下操作：获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要；其中，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml 文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件。
在一实施例中，处理器502还执行如下操作：将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；将第一明文分组均分为16个32位的子明文分组；创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
在一实施例中，处理器502还执行如下操作：将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
在一实施例中，处理器502还执行如下操作：通过第二脚本在子文件的目录中创建空文件；获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
本领域技术人员可以理解，图9中示出的计算机设备的实施例并不构成对计算机设备具体构成的限定，在其他实施例中，计算机设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。例如，在一些实施例中，计算机设备可以仅包括存储器及处理器，在这样的实施例中，存储器及处理器的结构及功能与图9所示实施例一致，在此不再赘述。
应当理解，在本申请实施例中，处理器502可以是中央处理单元(Central Processing Unit，CPU)，该处理器502还可以是其他通用处理器、数字信号处理 器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
在本申请的另一实施例中提供一种存储介质。该存储介质可以为非易失性的计算机可读存储介质。该存储介质存储有计算机程序，其中计算机程序包括程序指令。该程序指令被处理器执行时实现本申请实施例应用多渠道打包方法。
所述存储介质可以是前述设备的内部存储单元，例如设备的硬盘或内存。所述存储介质也可以是所述设备的外部存储设备，例如所述设备上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储介质还可以既包括所述设备的内部存储单元也包括外部存储设备。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的设备、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (20)

  1. 一种应用多渠道打包方法，其特征在于，包括：
    获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
    获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
    将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
    在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
    通过第三脚本将解压文件进行压缩，得到渠道包。
  2. 根据权利要求1所述的应用多渠道打包方法，其特征在于，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件；
    所述将子文件分别进行SHA1运算，得到一一对应的文件摘要，包括：
    获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
    获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
    获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
    获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
  3. 根据权利要求2所述的应用多渠道打包方法，其特征在于，所述获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要，包括：
    将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
    将第一明文分组均分为16个32位的子明文分组；
    创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
    将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
    对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
    将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
    将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
    将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
  4. 根据权利要求2所述的应用多渠道打包方法，其特征在于，所述将与文件摘要一一对应的哈希值存储至子文件的目录中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
  5. 根据权利要求1所述的应用多渠道打包方法，其特征在于，所述在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，包括：
    通过第二脚本在子文件的目录中创建空文件；
    获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
  6. 一种应用多渠道打包装置，其特征在于，包括：
    解压单元，用于获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
    文件摘要获取单元，用于获取解压后文件中包括的多个子文件，将子文件 分别进行SHA1运算，得到一一对应的文件摘要；
    编码单元，用于将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
    渠道名增加单元，用于在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
    渠道包打包单元，用于通过第三脚本将解压文件进行压缩，得到渠道包。
  7. 根据权利要求6所述的应用多渠道打包装置，其特征在于，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件；
    所述文件摘要获取单元，包括：
    第一文件摘要获取单元，用于获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
    第二文件摘要获取单元，用于获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
    第三文件摘要获取单元，用于获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
    第四文件摘要获取单元，用于获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
  8. 根据权利要求7所述的应用多渠道打包装置，其特征在于，所述第一文件摘要获取单元，包括：
    第一分组单元，用于将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
    第二分组单元，用于将第一明文分组均分为16个32位的子明文分组；
    链接变量创建单元，用于创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
    分组扩展单元，用于将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
    SHA1运算单元，用于对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
    变量求和单元，用于将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
    重复计算单元，用于将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
    变量串接单元，用于将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
  9. 根据权利要求7所述的应用多渠道打包装置，其特征在于，所述编码单元还用于将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中中。
  10. 根据权利要求6所述的应用多渠道打包装置，其特征在于，所述渠道名增加单元，包括：
    空文件创建单元，用于通过第二脚本在子文件的目录中创建空文件；
    名称修改单元，用于获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
  11. 一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：
    获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
    获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
    将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
    在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠 道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
    通过第三脚本将解压文件进行压缩，得到渠道包。
  12. 根据权利要求11所述的计算机设备，其特征在于，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件，META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件；
    所述将子文件分别进行SHA1运算，得到一一对应的文件摘要，包括：
    获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
    获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
    获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
    获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
  13. 根据权利要求12所述的计算机设备，其特征在于，所述获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要，包括：
    将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
    将第一明文分组均分为16个32位的子明文分组；
    创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
    将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
    对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
    将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
    将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算 直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
    将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
  14. 根据权利要求12所述的计算机设备，其特征在于，所述将与文件摘要一一对应的哈希值存储至子文件的目录中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
  15. 根据权利要求11所述的计算机设备，其特征在于，所述在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，包括：
    通过第二脚本在子文件的目录中创建空文件；
    获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
  16. 一种存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行以下操作：
    获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；
    获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；
    将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；
    在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；
    通过第三脚本将解压文件进行压缩，得到渠道包。
  17. 根据权利要求16所述的存储介质，其特征在于，所述解压后文件中包括5个子文件，分别为AndroidManifest.xml文件、classes.dex文件、res文件、META-INF文件、resources.arsc文件；其中AndroidManifest.xml文件为程序全局配置文件，classes.dex文件为Dalvik字节码文件，res文件为资源存放文件， META-INF文件为签名信息文件，resources.arsc文件为编译后的二进制资源文件；
    所述将子文件分别进行SHA1运算，得到一一对应的文件摘要，包括：
    获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要；
    获取AndroidManifest.xml文件的明文，将AndroidManifest.xml文件的明文通过SHA1哈希算法运算得到第二文件摘要；
    获取classes.dex文件的明文，将classes.dex文件的明文通过SHA1哈希算法运算得到第三文件摘要；
    获取resources.arsc文件的明文，将resources.arsc文件的明文通过SHA1哈希算法运算得到第四文件摘要。
  18. 根据权利要求17所述的存储介质，其特征在于，所述获取res文件的明文，将res文件的明文通过SHA1哈希算法运算得到第一文件摘要，包括：
    将res文件的明文分成多个512位的明文分组，分别记为第一明文分组至第N明文分组；其中，N为正整数；
    将第一明文分组均分为16个32位的子明文分组；
    创建5个32位的链接变量，分别记为A链接变量、B链接变量、C链接变量、D链接变量、E链接变量；
    将第一明文分组所包括16个子明文分组中的每一子明文分组均扩展为5份子明文分组，得到与第一明文分组对应的80份子明文分组；
    对第一明文分组对应的80份子明文分组进行SHA1运算，得到当前链接变量；
    将第一明文分组的当前链接变量与初始链接变量求和，得到第一明文分组的链接变量；
    将第一明文分组的链接变量作为第二明文分组的初始链接变量，重复计算直至分别获取第二明文分组的链接变量、第三明文分组的链接变量、第四明文分组的链接变量、第五明文分组的链接变量；
    将第五明文分组的链接变量依序串接，得到160位的第一文件摘要。
  19. 根据权利要求17所述的存储介质，其特征在于，所述将与文件摘要一一对应的哈希值存储至子文件的目录中，将第一文件摘要进行Base64编码的第一哈希值、第二文件摘要进行Base64编码的第二哈希值、第三文件摘要进行Base64 编码的第三哈希值、及第四文件摘要进行Base64编码的第四哈希值均存储至META-INF文件的目录中。
  20. 根据权利要求16所述的存储介质，其特征在于，所述在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，包括：
    通过第二脚本在子文件的目录中创建空文件；
    获取待配置的渠道号，通过第二脚本将空文件名称修改为待配置的渠道号；其中所述渠道号包括渠道标示字符头和渠道名。
PCT/CN2018/085253 2018-03-08 2018-05-02 应用多渠道打包方法、装置、计算机设备及存储介质 WO2019169721A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810191443.1A CN108459872B (zh) 2018-03-08 2018-03-08 应用多渠道打包方法、装置、计算机设备及存储介质
CN201810191443.1 2018-03-08

Publications (1)

Publication Number Publication Date
WO2019169721A1 true WO2019169721A1 (zh) 2019-09-12

Family

ID=63216763

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/085253 WO2019169721A1 (zh) 2018-03-08 2018-05-02 应用多渠道打包方法、装置、计算机设备及存储介质

Country Status (2)

Country Link
CN (1) CN108459872B (zh)
WO (1) WO2019169721A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109388918B (zh) * 2018-11-02 2020-07-28 深圳市小牛普惠投资管理有限公司 一种资源包加密方法、装置、计算机设备及存储介质
CN109656572A (zh) * 2018-11-14 2019-04-19 深圳壹账通智能科技有限公司 安装包的打包方法及装置、计算机设备、存储介质
CN111596931A (zh) * 2020-05-27 2020-08-28 北京学之途网络科技有限公司 应用程序封装方法、装置、电子设备及可读存储介质
CN112860646B (zh) * 2021-02-24 2022-12-02 上海泰宇信息技术股份有限公司 一种海量文件档案分布式聚合压缩与单一式抽取的方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104317625A (zh) * 2014-11-09 2015-01-28 刘鹏 一种apk文件的动态加载方法
CN105893860A (zh) * 2016-05-05 2016-08-24 百度在线网络技术（北京）有限公司 关键代码保护方法以及代码生成装置和代码运行装置
US9762385B1 (en) * 2015-07-20 2017-09-12 Trend Micro Incorporated Protection of program code of apps of mobile computing devices
CN107169370A (zh) * 2017-04-21 2017-09-15 广州优视网络科技有限公司 可执行文件的加密方法及加密装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104317625A (zh) * 2014-11-09 2015-01-28 刘鹏 一种apk文件的动态加载方法
US9762385B1 (en) * 2015-07-20 2017-09-12 Trend Micro Incorporated Protection of program code of apps of mobile computing devices
CN105893860A (zh) * 2016-05-05 2016-08-24 百度在线网络技术（北京）有限公司 关键代码保护方法以及代码生成装置和代码运行装置
CN107169370A (zh) * 2017-04-21 2017-09-15 广州优视网络科技有限公司 可执行文件的加密方法及加密装置

Also Published As

Publication number Publication date
CN108459872B (zh) 2019-12-24
CN108459872A (zh) 2018-08-28

Similar Documents

Publication Publication Date Title
WO2019169721A1 (zh) 应用多渠道打包方法、装置、计算机设备及存储介质
CN103384884B (zh) 一种文件压缩方法、文件解压缩方法、装置及服务器
US9465692B2 (en) High reliability erasure code distribution
US10965732B2 (en) Streaming zip
CN105531713A (zh) 从单个数据缓冲器生成多个安全散列
CN108717461B (zh) 海量数据结构化方法、装置、计算机设备及存储介质
US10164772B2 (en) Permutation composition based hash function
US20210019418A1 (en) Technique for authentication and prerequisite checks for software updates
US20210165766A1 (en) System and method for random-access manipulation of compacted data files
WO2020000486A1 (zh) 数据处理方法及装置
CN114595466A (zh) 实现对经加密的数据的机会认证
JP6545932B2 (ja) エンタープライズ・システムにおけるソフトウェアの展開
CN113468118B (zh) 一种基于区块链的文件增量存储方法、装置及存储介质
US10884643B2 (en) Variable length deduplication of stored data
US20100115230A1 (en) Hash functions using recurrency and arithmetic
CN116185512B (zh) 用于ptc驱动器的驱动加载方法、装置、设备及介质
CN116318660B (zh) 一种消息扩展与压缩方法及相关装置
CN110874221A (zh) 基于命令行的ssd固件打包方法、装置及计算机设备
US20230153468A1 (en) Content distribution integrity control
CN103226673A (zh) 批量处理swf打散加密方法及装置
CN113609215A (zh) 数据处理方法、装置、设备与计算机可读存储介质
CN109672536B (zh) 一种批量pdf文件数字签名方法及系统
CN111949738A (zh) 基于区块链的数据存储去重方法、终端设备和存储介质
CN113810198A (zh) Ssd固件数字签名的方法、装置、计算机设备及存储介质
CN115686380B (zh) 一种文件存储的方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18908828

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 09.12.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18908828

Country of ref document: EP

Kind code of ref document: A1