CN111240735A

CN111240735A - Application packaging method, application packaging device and storage medium

Info

Publication number: CN111240735A
Application number: CN202010054431.1A
Authority: CN
Inventors: 饶福贵
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2020-01-17
Filing date: 2020-01-17
Publication date: 2020-06-05
Anticipated expiration: 2040-01-17
Also published as: CN111240735B

Abstract

The present disclosure relates to an application packaging method, an application packaging device, and a storage medium. The application packaging method comprises the following steps: determining an APK signature block; adding an identification value in the APK signature block, wherein the identification value comprises information to be added into the APK file; and generating an APK file containing the information. The method and the device have the advantages that the information is added into the APK file on the basis of not changing the structure of the APK file, and further signature verification failure caused by the change of the structure of the APK file can be avoided.

Description

Application packaging method, application packaging device and storage medium

Technical Field

The present disclosure relates to the field of application development technologies, and in particular, to an application packaging method, an application packaging apparatus, and a storage medium.

Background

Before an Application (APP) is released and used, an Android Application Package (APK) needs to be signed and verified.

The signature verification process occurs in the process of packaging and installing the application into the APK package, and some auxiliary information, such as channel information, needs to be added in the process of packaging the application into the APK package. When the auxiliary information is added into the APK file in the related technology, the auxiliary information is added into the directory of the APK file, and the structure of the APK file is changed. However, a V3 signature scheme is introduced into the Android signature scheme, and in the V3 signature verification process, the signature verification fails due to the change of the APK file structure added with the auxiliary information, and further the APK package installation fails.

Disclosure of Invention

To overcome the problems in the related art, the present disclosure provides an application packaging method, an application packaging apparatus, and a storage medium.

According to a first aspect of an embodiment of the present disclosure, there is provided an application packaging method, including:

determining an APK signature block; adding an identification value in the APK signature block, wherein the identification value comprises information to be added into the APK file; and generating an APK file containing the information.

In one embodiment, generating an APK file containing the information comprises:

determining the existing identification value in the APK signature block; generating a new APK signature block based on the existing identification value and the identification value containing the information; and generating the APK file containing the information based on the new APK signature block.

In another implementation, the application packaging method according to the embodiment of the present disclosure further includes:

modifying a central directory offset of the EOCD block based on the new APK signature block.

In yet another embodiment, the information includes one or more of channel information, compile time stamp information, version information, and the like.

In yet another embodiment, the determining the APK signature block includes:

determining an APK data summary according to a plurality of signature algorithms; assembling the APK data abstract, a digital certificate chain and additional attributes to form an MF file; determining a digital signature of the MF file to form an SF file; and assembling the MF file, the SF file and a developer public key to form a V3 signature block.

According to a second aspect of the embodiments of the present disclosure, there is provided an application packaging apparatus including:

a determination unit for determining an APK signature block; the adding unit is used for adding an identification value in the APK signature block, wherein the identification value comprises information to be added into the APK file; and the generating unit is used for generating the APK file containing the information.

In one embodiment, the generating unit generates the APK file containing the information as follows:

In another embodiment, the generating unit is further configured to: modifying a central directory offset of the EOCD block based on the new APK signature block.

In another embodiment, the determining unit determines the APK signature block as follows:

According to a third aspect of the embodiments of the present disclosure, there is provided an application packaging apparatus including:

a processor; a memory for storing processor-executable instructions;

wherein the processor is configured to: the method for packaging the application as described in the first aspect or any one of the embodiments of the first aspect is performed.

According to a fourth aspect of the embodiments of the present disclosure, there is provided a non-transitory computer-readable storage medium, wherein instructions of the storage medium, when executed by a processor of a mobile terminal, enable the mobile terminal to perform the application packaging method of the first aspect or any one of the implementation manners of the first aspect.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects: the APK signature block is added with an identification value containing information to be added, the identification value containing the added information is generated, and then the information is added into the APK file on the basis of not changing the structure of the APK file, so that the signature verification failure caused by the change of the structure of the APK file can be avoided.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.

Fig. 1 is a flowchart illustrating an APK file installation method according to an exemplary embodiment.

Fig. 2 is a block diagram illustrating the structure of an APK signature block according to an example embodiment.

FIG. 3 is a flow diagram illustrating a method of application packaging in accordance with an exemplary embodiment.

Fig. 4 is a schematic diagram illustrating a V3 signature block determination process according to an example embodiment.

Fig. 5 is a block diagram illustrating the structure of a V3 signature block in accordance with an exemplary embodiment.

Fig. 6 is a flowchart illustrating a method for generating an APK file using package according to an exemplary embodiment.

Fig. 7 is a diagram illustrating an APK after adding channel information according to an exemplary embodiment.

Fig. 8 is a flow diagram illustrating V3 signature verification, according to an example embodiment.

Fig. 9 is a block diagram illustrating an application packaging apparatus according to an example embodiment.

Fig. 10 is a block diagram illustrating an apparatus for application packaging in accordance with an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

The application packaging method provided by the embodiment of the disclosure can be applied to an APK file installation scene. There are mainly four ways for APK file installation:

and (3) system application installation: and the startup is completed without an installation interface.

Installation of the application downloaded through the network: finished through market application without installation interface.

ADB tool installation: there is no mounting interface.

And (3) third-party application installation: apk application installation through package install.

But the method for installing the APK file in any way needs to complete the main work of installation through the Package Manager Service.

Signature verification is required when the APK file installation is performed, for example, verification of an APK V3 signature block in Android 9.0 and higher. Fig. 1 is a schematic flow chart of an APK file installation method. Referring to fig. 1, after opening the APK file, it is determined whether there is a V3 signature block in the APK file. If the APK file has a V3 signature block, signature verification is carried out by adopting a V3 signature block verification mode. And if the verification is passed by adopting the verification mode of the V3 signature block, the APK file is installed, and if the verification is failed by adopting the verification mode of the V3 signature block, the installation of the APK file is cancelled. If the APK file does not have the V3 signature block, whether the APK file has the V2 signature block is judged. If the APK file has a V2 signature block, signature verification is carried out by adopting a V2 signature block verification mode. And if the verification is passed by adopting the verification mode of the V2 signature block, the APK file is installed, and if the verification is failed by adopting the verification mode of the V2 signature block, the installation of the APK file is cancelled. If the APK file does not have the V2 signature block, the signature verification is carried out by adopting a V1 signature block verification mode. And if the verification is passed by adopting the verification mode of the V1 signature block, the APK file is installed, and if the verification is failed by adopting the verification mode of the V1 signature block, the installation of the APK file is cancelled.

After the APK V3 signature verification scheme is introduced, in the Android 9.0 and higher versions, signature verification can be performed according to the APK signature scheme by adopting the method shown in fig. 1. Referring to fig. 1, verification of APK is attempted in the order of V3 → V2 → V1. In some scenarios, the V3 signature verification is ignored, the V2 signature verification is directly attempted, and finally the V1 signature verification is performed.

The APK V3 signature verification process occurs in the process of packaging and installing the application into an APK package, and auxiliary information such as channel information needs to be added in the process of packaging the application into the APK package. When the auxiliary information is added into the APK file in the related technology, the auxiliary information is added into the directory of the APK file, and the structure of the APK file is changed. However, a V3 signature scheme is introduced into the Android signature scheme, and in the V3 signature verification process, the signature verification fails due to the change of the APK file structure added with the auxiliary information, and further the APK package installation fails. In the APK V3 signature verification scheme, a signature key is required to be taken for V3 signature, and the signature is difficult to re-sign without the signature key.

In the embodiment of the disclosure, an APK file packaging method is provided, so that an APK file is signed in a V3 signature manner without an original signature key, and auxiliary information such as channel information is written into the signed APK file. The method realizes normal verification and installation of the APK file on the terminal above the Android9 on the basis of not changing the signature verification mode of the original APK.

Fig. 2 is a schematic diagram illustrating the structure of an APK signature block according to an example embodiment. Referring to fig. 2, the APK signature block includes a plurality of identification values (ID-Value). Each ID-Value includes a 4-byte ID and corresponding data. The V3 signature block may be understood to be a byte stream. For example, in FIG. 2, the first is the signature block size of 8 bytes, which does not contain the 8 bytes of the field itself. Secondly, a sequence formed by a plurality of ID-values, wherein each ID-Value comprises a 4-byte ID and corresponding data; then again an 8 byte signature block size, equal to the first 8 bytes. Finally, a 16 byte signature block modulus. Wherein, Value corresponding to ID 0xf05368c0 is V3 signature block data.

Referring to fig. 2, since the APK signature block includes a plurality of ID-values, if an ID-Value is newly added, the structure of the APK signature block is not affected. In view of this, in the embodiment of the present disclosure, an ID-Value containing information to be added is added to the original APK signature block, and then a new APK signature block is regenerated. And generating the APK file based on the new APK signature block, and adding information into the APK file on the basis of not changing the structure of the APK file, so that signature verification failure caused by the change of the structure of the APK file can be avoided.

Fig. 3 is a flowchart illustrating an application packaging method according to an exemplary embodiment, where as shown in fig. 3, the application packaging method is used in a terminal, and an operating system of the terminal is an android system. Referring to fig. 3, the following steps are included.

In step S11, an APK signature block is determined.

In the embodiment of the disclosure, an EOCD block of an APK file can be found, and then an APK signature block is found according to the EOCD block central directory offset. The EOCD block can be understood as the real data storage area in the APK file. The signature block can be understood as a remark area in the APK file.

In step S12, an ID-Value is added to the APK signature block.

In the embodiment of the disclosure, a new ID-Value is additionally added in the APK signature block, and the additionally added new ID-Value includes information to be added into the APK file. For example, the information to be added to the APK file may be auxiliary information such as channel information. The information to be added to the APK file in the embodiment of the present disclosure may also be one or more items such as compilation time stamp information, version information, and the like.

In step S13, an APK file containing joining information is generated.

The APK signature block is added with an identification value containing information to be added, the identification value containing the added information is generated, and then the information is added into the APK file on the basis of not changing the structure of the APK file, so that the signature verification failure caused by the change of the structure of the APK file can be avoided.

The embodiment of the present disclosure will be described below with reference to practical applications, where the process of generating an APK file by packaging an application related to the above embodiment is described.

The embodiment of the disclosure can be applied to a scene that an APK file is signed by adopting a V3 signature mode and auxiliary information such as channel information and the like is added to the signed APK file, so that the APK file can be normally verified and installed on a terminal above Android9 on the basis of not changing the original APK signature verification mode.

The APK signature block determined in the embodiments of the present disclosure may be a V3 signature block. The determination process of the V3 signature block will be explained below.

Fig. 4 is a schematic diagram illustrating a V3 signature block determination process according to an example embodiment. First, according to a plurality of signature algorithms, a data digest of the entire APK is calculated to form an APK data digest set, which is the first row in the first column in fig. 4. The APK data digest, digital certificate and additional attributes are then assembled to form an MF file similar to the V1 signature, e.g., the second column, first row in fig. 4. Second, the MF file digital signature similar to the V1 signature is computed using the same private key that generated the MF file, a different signature algorithm, to form an SF file similar to the V1 signature, e.g., the second column, second row in fig. 4, and then the second column of the similar MF file, the similar SF file, and the developer public key are assembled together into a V3 signature block, e.g., the third column, first row in fig. 4. Wherein, the V3 signature block is formed by a single keystore signature. In Android, a plurality of keystores are allowed to be used for signing APK files, so that the signature blocks signed by the keystores are assembled to form a complete V3 signature block.

In summary, the V3 signature block determined in the embodiment of the present disclosure mainly consists of three parts, which are respectively three data blocks in the second column in fig. 4: like MF files, like SF files, and developer public keys, the structure of which is shown in fig. 5.

After the APK signature block is determined in the embodiment of the disclosure, an ID-Value may be newly added to the APK signature block, where the newly added ID-Value includes information to be added to the APK file. Such as channel information, etc. Wherein, the channel information may be a channel number. The structure of the APK signature block to which the ID-Value containing the information to be added is newly added is shown in fig. 2.

After the ID-Value containing the information to be added is newly added, the existing ID-Value in the APK signature block can be determined. And then generating a new APK signature block by all the ID-Value in the APK signature block, the existing ID-Value and the ID-Value containing the information to be added. And generating an APK file containing the adding information based on the new APK signature block.

In the embodiment of the present disclosure, an EOCD block of an APK may be acquired, and an APK file including addition information is generated based on the EOCD block and a new APK signature block.

Furthermore, since the ID-Value is newly added to the APK signature block in the embodiment of the present disclosure, the byte number of the new APK signature block changes, that is, the central directory offset of the EOCD block changes. To align the bytecodes in the disclosed embodiments, the central directory offset of the EOCD block may be modified with the new APK signature block to determine the new APK signature block based on the modified central directory offset.

Fig. 6 is a flowchart illustrating a method for generating an APK file using package according to an exemplary embodiment. Referring to fig. 6, the method includes: find EOCD block of APK. Find APK signature block. And acquiring the existing ID-Value Pair.

Add ID-Value containing channel information. A new signature block is generated based on all ID-values. Modifying the offset of the central directory of the EOCD (wherein modifying the central directory offset of the EOCD does not result in a data digest check failure). And replacing the old signature block with the new signature block to generate the APK with the channel information.

The channel information added to the APK file in the embodiment of the present disclosure may be a fixed ID value, for example, the ID is 0x4D 494859.

In the embodiment of the present disclosure, the APK (small-end mode) after adding the channel information can be viewed through the 16-system editor, as shown in fig. 7. In fig. 7, "6C 656F 6E" is channel information leon. The first 4 bytes "FF 551188" are the newly added ID, and the second 8 bytes "0800000000000000" are the length of the ID-Value, which is exactly 8.

The APK file generated by the packaging method provided by the embodiment of the present disclosure supports verification of a V3 signature newly added above 9.0.

In the embodiment of the present disclosure, for the APK signature block to which information is added, signature verification may be performed in a manner as shown in fig. 8. Referring to fig. 8, when performing APK signature verification, it is possible to first find an EOCD block, and find a signature block according to the EOCD block central directory offset, and verify whether the size fields of the two signature blocks are the same. In the embodiment of the present disclosure, if the V3 signature block cannot be found, the verification may be performed by using a degraded signature verification, such as the method shown in fig. 1, and a V2 signature verification or a V1 signature verification is performed. After the V3 signature block is found in the embodiment of the present disclosure, the signature block with the ID of 0xf05368c0 can be found from the V3 signature block, and then the V3 signature block is found, and the signature blocks of other ID-Value Pair are ignored. And when checking, selecting the strongest signature algorithm ID supported by the system from the SF digital signature list, and decrypting the digital signature in the SF signature block through the public key in the signature block. And comparing the digital signature obtained by decryption with the data digest in the MF file, and checking whether the digest is modified. And comparing whether the signature algorithm ID in the MF file is consistent with the signature algorithm ID in the SF file. And comparing whether the public key in the digital certificate of the developer in the MF is consistent with the public key in the signature block. The data digest of the calculated APK is compared with the data digest in the MF.

By the above-mentioned manner of adding information to the APK file and the above-mentioned manner of verifying the signature of V3, the V3 signature block of the APK is stored as an ID-Value Pair (ID-Value Pair), where the ID is 0xf05368c0, and channel number information with the ID-Value Pair of 0x4D494859 is added to the APK signed by V3, so that information such as a channel number can be added to the APK file signed by V3 when there is no signature key. And information such as channel numbers and the like is added into the ID-Value, so that the information such as the channel numbers and the like can be quickly added, the development cost is saved, and the resource occupation is reduced

Further, in the embodiment of the present disclosure, when Andoid9 verifies the APK file package signed by V3, two APK files without a channel and with a channel number can be installed in a mutually overlapping manner.

Based on the same conception, the embodiment of the disclosure also provides an application packaging device.

It is understood that, in order to implement the above functions, the application packaging apparatus provided in the embodiments of the present disclosure includes a hardware structure and/or a software module corresponding to the execution of each function. The disclosed embodiments can be implemented in hardware or a combination of hardware and computer software, in combination with the exemplary elements and algorithm steps disclosed in the disclosed embodiments. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

Fig. 9 is a block diagram illustrating an application packaging apparatus according to an example embodiment. Referring to fig. 9, the application packaging apparatus 100 includes a determination unit 101, an addition unit 102, and a generation unit 103.

And the determining unit 101 is used for determining the APK signature block. An adding unit 102, configured to add an ID-Value in the APK signature block, where the ID-Value includes information to be added to the APK file. A generating unit 103, configured to generate an APK file containing the information.

In one embodiment, the generation unit 103 generates an APK file containing information as follows:

the existing ID-Value in the APK signature block is determined. And generating a new APK signature block based on the existing ID-Value and the ID-Value containing the information. And generating an APK file containing information based on the new APK signature block.

In another embodiment, the generating unit 103 generates the APK file containing information based on the new APK signature block in the following manner:

determining EOCD blocks of APK. The central directory offset of the EOCD block is modified based on the new APK signature block. And generating the APK file containing the information based on the EOCD block and the new APK signature block which modify the central directory offset.

the APK data digest is determined according to a plurality of signature algorithms. And assembling the APK data abstract, the digital certificate chain and the additional attributes to form the MF file. And determining the digital signature of the MF file to form an SF file. The MF file, the SF file and the public key of the developer are assembled to form a V3 signature block.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Fig. 10 is a block diagram illustrating an apparatus 200 for application packaging according to an example embodiment. For example, the apparatus 200 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, an exercise device, a personal digital assistant, and the like.

Referring to fig. 10, the apparatus 200 may include one or more of the following components: a processing component 202, a memory 204, a power component 206, a multimedia component 208, an audio component 210, an input/output (I/O) interface 212, a sensor component 214, and a communication component 216.

The processing component 202 generally controls overall operation of the device 200, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing components 202 may include one or more processors 220 to execute instructions to perform all or a portion of the steps of the methods described above. Further, the processing component 202 can include one or more modules that facilitate interaction between the processing component 202 and other components. For example, the processing component 202 can include a multimedia module to facilitate interaction between the multimedia component 208 and the processing component 202.

Memory 204 is configured to store various types of data to support operation at device 200. Examples of such data include instructions for any application or method operating on the device 200, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 204 may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

Power components 206 provide power to the various components of device 200. Power components 206 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for device 200.

The multimedia component 208 includes a screen that provides an output interface between the device 200 and the user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 208 includes a front facing camera and/or a rear facing camera. The front camera and/or the rear camera may receive external multimedia data when the device 200 is in an operating mode, such as a shooting mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

The audio component 210 is configured to output and/or input audio signals. For example, audio component 210 includes a Microphone (MIC) configured to receive external audio signals when apparatus 200 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may further be stored in the memory 204 or transmitted via the communication component 216. In some embodiments, audio component 210 also includes a speaker for outputting audio signals.

The I/O interface 212 provides an interface between the processing component 202 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

The sensor component 214 includes one or more sensors for providing various aspects of status assessment for the device 200. For example, the sensor component 214 may detect an open/closed state of the device 200, the relative positioning of components, such as a display and keypad of the apparatus 200, the sensor component 214 may also detect a change in position of the apparatus 200 or a component of the apparatus 200, the presence or absence of user contact with the apparatus 200, orientation or acceleration/deceleration of the apparatus 200, and a change in temperature of the apparatus 200. The sensor assembly 214 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 214 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 214 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 216 is configured to facilitate wired or wireless communication between the apparatus 200 and other devices. The device 200 may access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 216 receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 216 further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the apparatus 200 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components for performing the above-described methods.

In an exemplary embodiment, a non-transitory computer readable storage medium comprising instructions, such as memory 204, comprising instructions executable by processor 220 of device 200 to perform the above-described method is also provided. For example, the non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

It is further understood that the use of "a plurality" in this disclosure means two or more, as other terms are analogous. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. The singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It will be further understood that the terms "first," "second," and the like are used to describe various information and that such information should not be limited by these terms. These terms are only used to distinguish one type of information from another and do not denote a particular order or importance. Indeed, the terms "first," "second," and the like are fully interchangeable. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present disclosure.

It is further to be understood that while operations are depicted in the drawings in a particular order, this is not to be understood as requiring that such operations be performed in the particular order shown or in serial order, or that all illustrated operations be performed, to achieve desirable results. In certain environments, multitasking and parallel processing may be advantageous.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. An application packaging method, comprising:

determining an APK signature block;

adding an identification value in the APK signature block, wherein the identification value comprises information to be added into the APK file;

and generating an APK file containing the information.

2. The application packaging method of claim 1, wherein generating the APK file containing the information comprises:

determining the existing identification value in the APK signature block;

generating a new APK signature block based on the existing identification value and the identification value containing the information;

and generating the APK file containing the information based on the new APK signature block.

3. The application packaging method of claim 2, further comprising:

4. The application packaging method according to any one of claims 1 to 3, wherein the information comprises one or more of channel information, compilation time stamp information, version information, and the like.

5. The application packaging method of claim 1, wherein the determining the APK signature block comprises:

determining an APK data summary according to a plurality of signature algorithms;

assembling the APK data abstract, a digital certificate chain and additional attributes to form an MF file;

determining a digital signature of the MF file to form an SF file;

and assembling the MF file, the SF file and a developer public key to form a V3 signature block.

6. An application packaging apparatus, comprising:

a determination unit for determining an APK signature block;

the adding unit is used for adding an identification value in the APK signature block, wherein the identification value comprises information to be added into the APK file;

and the generating unit is used for generating the APK file containing the information.

7. The application packaging apparatus according to claim 6, wherein the generating unit generates the APK file containing the information in the following manner:

determining the existing identification value in the APK signature block;

8. The application packaging apparatus of claim 7, wherein the generating unit is further configured to:

9. The application packaging apparatus according to any one of claims 6 to 8, wherein the information comprises one or more of channel information, compilation time stamp information, version information, and the like.

10. The application packaging apparatus according to claim 6, wherein the determining unit determines the APK signature block by:

determining a digital signature of the MF file to form an SF file;

11. An application packaging apparatus, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to: executing the application packaging method of any of claims 1 to 5.

12. A non-transitory computer readable storage medium having instructions therein which, when executed by a processor of a mobile terminal, enable the mobile terminal to perform the application packaging method of any of claims 1 to 5.