WO2019041891A1

WO2019041891A1 - Method and device for generating upgrade package

Info

Publication number: WO2019041891A1
Application number: PCT/CN2018/087148
Authority: WO
Inventors: 刘路
Original assignee: 中兴通讯股份有限公司
Priority date: 2017-09-04
Filing date: 2018-05-16
Publication date: 2019-03-07
Also published as: CN109426515A

Abstract

Provided are a method and device for generating an upgrade package. The method comprises: determining whether a signed target file exists under a root directory (S102); if so, decompressing the signed target file, deleting an IMAGES directory therein, and modifying a content of a file to be upgraded (S104); and using a specified script to regenerate a system mirror, and generating an upgrade package (S106).

Description

Method and device for generating upgrade package

Technical field

This document relates to, but is not limited to, the field of computers, and in particular, to a method and apparatus for generating an upgrade package.

Background technique

As the Android version is continuously updated, the software version of the mobile terminal generally needs to be updated accordingly, which can satisfy the user's use requirements and improve the user experience. Generally, the Android mobile device has an application software that is upgraded in the air. The application software interacts with the corresponding server, searches for the upgrade package stored on the server, downloads the upgrade package, and upgrades to the new version through the recovery recovery mode of the mobile terminal, thereby Reach the purpose of updating the system version.

Summary of invention

The following is an overview of the topics detailed in this document. This Summary is not intended to limit the scope of the claims.

According to an embodiment of the present invention, a method for generating an upgrade package includes: determining whether a signature object file exists in a root directory; and deactivating the signature object file and deleting an IMAGES thereof when the signature object file exists Directory, and modify the contents of the file to be upgraded; use the specified script to regenerate the system image and generate an upgrade package.

According to another embodiment of the present invention, there is provided an apparatus for generating an upgrade package, comprising: a determining module, configured to determine whether a signature object file exists in a root directory; and a first processing module configured to present the signature object file Decompressing the signature object file, deleting the IMAGES directory, and modifying the content of the file to be upgraded; the first generation module is configured to regenerate the system image using the specified script and generate an upgrade package.

According to still another embodiment of the present invention, a storage medium is also provided. The storage medium is arranged to store program code for performing the following steps:

Determine whether a signature object file exists in the root directory;

When the signature object file exists, decompress the signature object file, delete the IMAGES directory therein, and modify the file content to be upgraded;

Regenerate the system image with the specified script and generate an upgrade package.

Other aspects will be apparent upon reading and understanding the drawings and detailed description.

BRIEF abstract

1 is a flowchart of a method for generating an upgrade package according to an embodiment of the present invention;

2 is a structural block diagram of an apparatus for generating an upgrade package according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of a data flow according to an embodiment of the present invention.

Detailed

The invention will be described in detail below with reference to the drawings in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.

It is to be understood that the terms "first", "second", and the like in the specification and claims of the present invention are used to distinguish similar objects, and are not necessarily used to describe a particular order or order.

At present, Google's upgrade plan is to download the upgrade package to the cache cache partition of the mobile terminal through Gota (Google's own over-the-air software upgrade) server (if the cache partition is insufficient, it will be downloaded to the data data partition), now Google's L and M platform is based on block devices to make upgrade packages, the upgrade package is relatively large, especially cross-platform upgrades, such as Android L upgrade to M, the upgrade package made to reach about 1G. Even the upgrade packages made on the same platform are generally above 20M, mostly between 20M and 250M. This problem will come. If you need to make an upgrade package of about 3M, it will be more difficult. In fact, in order to solve some For specific problems, or to meet the specific needs of users, the upgrade package size can only be a specific size (for example, the US operator AT&T needs 3M, 50M, 500M size upgrade package). The current easy way to think of is to always compile the version of the specific requirements, and then go to the upgrade package again, so repeatedly try to do the version, and then do the package, maybe make an upgrade package that meets the capacity size, which will waste a lot of time, 50M and A 500M upgrade can be made, but a 3M upgrade can hardly be made. A recompiled version, where the system system image is an ext4 file system, even if the content is identical, from a binary point of view is completely different, such as a file / system / build.prop storage block absolute address is not Similarly, even a file may be stored on a different physical address, so the difference between the two versions based on the block device is generally very large, which is why it is difficult to make a 3M package.

In this embodiment, a method for generating an upgrade package is provided. FIG. 1 is a flowchart of a method for generating an upgrade package according to an embodiment of the present invention. As shown in FIG. 1, the process includes the following steps:

Step S102, determining whether a signature object file exists in the root directory;

Step S104, when the signature object file exists, decompress the signature object file, delete the mirror IMAGES directory therein, and modify the file content to be upgraded;

In step S106, the system image is regenerated using the specified script, and an upgrade package is generated.

Through the above steps, when the signature object file exists, the signature target file is decompressed, the IMAGES directory is deleted, the content of the file to be upgraded is modified, the system image is regenerated using the specified script, and an upgrade package is generated. It is implemented to generate a specific size upgrade package when building an upgrade package based on a block.

The execution body of the above steps may be a terminal, an upgrade tool, or the like, but is not limited thereto.

The specified script in this embodiment may be an img_from_target_files script.

In this embodiment, as another implementation scenario, the method includes:

S11: When the signature object file does not exist in the root directory, the system image is converted to the ext4 format, and the absolute address of the file to be modified is searched through the system.map;

S12, use the winhex tool to modify the contents of the file in the system directory, generate a new system image, convert to the sparse format, and generate an upgrade package.

In this embodiment, the modified file content includes at least one of the following: modifying the SYSTEM file; modifying the build.prop file; modifying the external version number information of the SYSTEM file; and modifying the external version number information of the build.prop file.

In this embodiment, after the upgrade package is generated, when the previously generated upgrade package does not meet the requirements of a specific size, the method further includes:

S21, adding a predetermined amount of binary data to the upgrade package to obtain a specified upgrade package; the added binary data may be useless data, and the terminal may automatically identify and delete the binary data when using the upgrade package upgrade;

S22, using a signature script to sign the specified upgrade package.

Before decompressing the signature object file, the method further includes:

S31, copying a signature object file to the specified storage device, and renaming the copy version of the signature object file;

S32. Determine a copy target signature target file as the signature target file to be decompressed.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method of the foregoing embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is more Good implementation. Based on such understanding, the technical solution of the present invention, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present invention.

The embodiment of the present invention further provides an apparatus for generating an upgrade package, which is configured to implement the foregoing embodiments, and details are not described herein. As used below, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.

2 is a structural block diagram of an apparatus for generating an upgrade package according to an embodiment of the present invention. As shown in FIG. 2, the apparatus includes:

The determining module 20 is configured to determine whether a signature object file exists in the root directory;

The first processing module 22 is configured to: when the signature object file exists, decompress the signature object file, delete the IMAGES directory therein, and modify the file content to be upgraded;

The first generation module 24 is configured to regenerate the system image using the specified script and generate an upgrade package.

The device further includes: a second processing module, configured to convert the system image to the ext4 format when the signature object file does not exist in the root directory, and find the absolute address of the file to be modified through the system.map; the second generation module is set to Use the winhex tool to modify the contents of the file in the system directory, generate a new system image, convert to the sparse format, and generate an upgrade package.

The device may further include: adding a module, configured to add a predetermined capacity binary data to the upgrade package to obtain a specified upgrade package after generating the upgrade package; and the signature module is configured to use the signature script to sign the specified upgrade package.

It should be noted that each of the above modules may be implemented by software or hardware. For the latter, the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or, the above modules are in any combination. The forms are located in different processors.

The above embodiment will be described below with an application example.

The specific upgrade package in this application example may be the USER version, and other versions may be used. FIG. 3 is a schematic diagram of the data flow of the embodiment of the present invention. When the version is compiled, a set boot, a recovery and a system directory suffix are A.zip. The format file (called the signature object file (signed-target-files.zip file)), if the file is not deleted, and the content has not been modified, first extract the A.zip file, extract the IMAGES directory after decompression If you do not delete the IMAGES directory, you will use the bootimage, recoveryimage and systemimage images that have been generated. Any changes will not take effect; then modify the contents of the file to be modified, for example, modify the SYSTEM/build.prop file. External version number information, etc., recompress the decompressed file directory. Note that the ry command is used to add the -ry parameter to avoid loss of the soft connection in the system image. Use Google's img_from_target_files.py script to regenerate the new systemimage and other images.

Package the generated new image into the original version, replace the original systemimage image, and rename the version name. Create a block-based upgrade package between the two, because the systemimage image of the previous and subsequent versions comes from a system directory. The file order and size in the system image are the same. Modifying a few files, and each file size does not exceed the original 4K size, so the upgrade package based on the block device mode will be smaller.

When the A.zip file is deleted for some reason, it cannot be based on the above method. You can use the original system image and the corresponding system.map to generate a new image. System.map is an address table for storing all files, such as /system/build.prop851944-851946, which means that the two blocks 851944 and 851945 (excluding 851946) are stored from the beginning in 4K, so that Open the system.img.ext4 image with the winhex tool (you need to convert from the sparse format to ext4), find the corresponding address and modify the corresponding value, but this method can only replace the original value, such as ro.build.display.id=Z831V1 .0.0B24 changed to ro.build.display.id=Z831V1.0.0B2*, you can't add or extend new characters, because newly added characters will cause data overflow and terminator loss, etc., the device will not boot after upgrading. .

The embodiment of the invention further provides an upgrade scheme for an Android device to read an upgrade package from an encrypted external T card. The method flow of the upgrade program includes:

Step S101: Compile a complete USER version according to Android, generate an A.zip (generally signed-target-files.zip file) file under the root directory, and copy one copy to fota-target-files.zip; Among them, fota (Firmware Over-The-Air) is an over-the-air software upgrade for mobile terminals.

Step S102: Each time the user version is output, the signed-target-files.zip is generated in the root directory to determine whether the file signed-target-files.zip exists. If not, step S103 is performed, and if yes, the steps are executed. S106;

Step S103: First, use simg2img to convert the system image to ext4 format, and find the absolute address of the file to be modified through system.map. System.map is an address table for storing all files, such as /system/build.prop 851944-851946, Means the two blocks 851944 and 851945 (excluding 851946) that are stored from the beginning in 4K;

Step S104: Use the winhex tool to open the system image in the ext4 format, and modify the file contents in the system image, and the original character length cannot be changed. For example, ro.build.display.id=Z831V1.0.0B24 is changed to ro.build.display. Id=Z831V1.0.0B2*, can't add or extend new characters, because newly added characters will cause data overflow and terminator loss, etc., the device will not boot when upgraded;

Step S105: After generating a new system image, use the img2simg command to convert the ext4 format to the sparse format, and package the system image into a new version. Only the system image is different between the previous version and the previous version, and step S111 is performed;

Step S106: copy and rename to fota-target-files.zip;

Step S107: Decompress fota-target-files.zip and delete the IMAGES folder and the contents therein. If it is not deleted, the bootimage, recoveryimage and systemimage images that have been generated will be used, so that subsequent modifications will not take effect.

Step S108: Modify the following files to be modified in the fota-target-files directory, for example, the SYSTEM/build.prop file, modify the external version number, and note that the file attributes before and after the modification are consistent with the previous ones;

Step S109: Pack all the files in the fota-target-files directory, and note that the zip-ry fota-target-files_new.zip./ command is used in the fota-target-files directory, where r means that the subdirectories of each level are valid. The y parameter means to retain all existing soft links;

Step S110: In the root directory of the android compiler environment, call the following command, sudo./build/tools/releasetools/img_from_target_files fota-target-files_new.zip fota_img.zip, and the newly generated system in the newly generated fota_img.zip. Img and system.map, copy out to replace the corresponding image in the original version, thus generating a new target version;

Step S111: Re-create the upgrade package by using the package script, and let the Android device upgrade the version, and then check whether the expected effect is achieved after the upgrade;

Step S112: If a larger upgrade package is needed, you can insert binary data of the appropriate capacity into it, and then use the signature script to re-sign the upgrade package, let the Android device upgrade the version, and insert the data during the upgrade process. Will not be written to the Android device;

First, create a specific size upgrade package according to the above method, then insert a normal external T card into the mobile terminal, and then copy the upgrade package to this T card through MTP copy mode, etc., and upgrade the package. Renamed update.zip, look at the version number of the device before upgrading. The mobile Android device that needs to be upgraded can detect the upgrade package by setting the system update button under the module. The upper layer of the system will call the system to reboot into the recovery mode for upgrade. The small robot will continue to rotate and the progress bar will display the upgrade from 0% to 100. %, after the upgrade, the upgrade package in the external T card will be deleted, it will not affect the user to use the T card data area. After the upgrade, the device will change the version number of the device.

The embodiment of the invention further provides a storage medium. In this embodiment, the above storage medium may be configured to store program code for performing the following steps:

S1, determining whether a signature object file exists in the root directory;

S2, when the signature object file exists, decompress the signature object file, delete the IMAGES directory therein, and modify the content of the file to be upgraded;

S3, regenerate the system image using the specified script and generate an upgrade package.

In this embodiment, the storage medium may include: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk. The medium in which the program code is stored.

In this embodiment, the processor may perform determining whether the signature object file exists in the root directory according to the stored program code in the storage medium;

In this embodiment, the processor may execute, according to the stored program code in the storage medium, when the signature object file exists, decompress the signature object file, delete the IMAGES directory therein, and modify the file content to be upgraded;

In this embodiment, the processor may regenerate the system image using the specified script according to the stored program code in the storage medium, and generate an upgrade package.

For specific examples in this embodiment, reference may be made to the examples described in the foregoing embodiments and the optional embodiments, and details are not described herein again.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, and functional blocks/units of the methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical units; for example, one physical component may have multiple functions, or one function or step may be composed of several physical The components work together. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on a computer readable medium, which may include computer storage media (or non-transitory media) and communication media (or transitory media). As is well known to those of ordinary skill in the art, the term computer storage medium includes volatile and nonvolatile, implemented in any method or technology for storing information, such as computer readable instructions, data structures, program modules, or other data. , removable and non-removable media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridge, magnetic tape, magnetic disk storage or other magnetic storage device, or may Any other medium used to store the desired information and that can be accessed by the computer. Moreover, it is well known to those skilled in the art that communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and can include any information delivery media. The above description is only an alternative embodiment of the present invention, and is not intended to limit the present invention, and the present invention may be modified and changed by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

A method for generating an upgrade package, including:

Determine whether a signature object file exists in the root directory;

When the signature object file exists, decompress the signature object file, delete the mirror IMAGES directory, and modify the file content to be upgraded;

Regenerate the system image with the specified script and generate an upgrade package.
The method of claim 1 further comprising:

When the signature object file does not exist in the root directory, the system image is converted to the ext4 format, and the absolute address of the file to be modified is searched through system.map;

Use the winhex tool to modify the contents of the system system directory, generate a new system image, convert to the sparse format, and generate an upgrade package.
The method of claim 1, wherein modifying the content of the file to be upgrade comprises at least one of the following:

Modify the SYSTEM file;

Modify the build.prop file;

Modify the external version number information of the SYSTEM file;

Modify the external version number information of the build.prop file.
The method according to claim 1 or 2, further comprising: after generating the upgrade package,

Adding binary data of a predetermined capacity to the upgrade package to obtain a specified upgrade package;

Sign the specified upgrade package with a signature script.
The method of claim 1 further comprising: prior to decompressing the signature object file,

Copying one copy of the signature object file to the specified storage device and renaming the copy version of the signature object file;

The signature version of the signature target file is determined as the signature target file to be decompressed.
An apparatus for generating an upgrade package, comprising:

The judging module is set to determine whether a signature object file exists in the root directory;

The first processing module is configured to: when the signature object file exists, decompress the signature object file, delete the mirror IMAGES directory, and modify the file content to be upgraded;

The first generation module is configured to regenerate the system image using the specified script and generate an upgrade package.
The apparatus of claim 6 further comprising:

The second processing module is configured to convert the system image into the ext4 format when the signature object file does not exist in the root directory, and find the absolute address of the file to be modified through the system.map;

The second generation module is configured to modify the file content in the system system directory by using the winhex tool, generate a new system image, convert to the sparse format, and generate an upgrade package.
The device according to claim 6 or 7, further comprising:

Adding a module, and setting, after generating the upgrade package, adding binary data of a predetermined capacity to the upgrade package to obtain a specified upgrade package;

A signature module configured to sign the specified upgrade package using a signature script.
A storage medium, the storage medium comprising a stored program, wherein the program is executed to perform the method of any one of claims 1 to 5.
A processor, the processor being arranged to run a program, wherein the program is executed to perform the method of any one of claims 1 to 5.