升级包的生成方法及装置与流程

本发明涉及计算机领域，具体而言，涉及一种升级包的生成方法及装置。

背景技术：

随着android版本不断的更新，移动终端的软件版本一般也需要随之更新，这样能满足用户的使用需求，提高用户体验等。一般android移动设备都有空中升级的应用软件，这个应用软件会跟对应的服务器交互，搜索到服务器上面存放的升级包，下载此升级包并且通过移动终端的recovery模式升级到新的版本，从而达到更新系统版本的目的。据我们所知，google的升级方案是把升级包通过gota(google自己的空中下载软件升级)服务器下载到移动终端的cache分区中(如果cache分区不够会下载到data分区中)，现在google的l和m平台都是基于块设备进行制作升级包的，所做出来的升级包比较大，尤其是跨平台的升级，比如androidl升级到m，做出来的升级包都达到1g左右。即使在同平台上面制作的升级包，一般也都在20m以上，大都是在20m到250m之间，这样问题就来了，要是需要制作3m左右的升级包难度会比较大，实际上为了解决某些特定的问题，或者满足用户的特定需求，升级包大小只能为特定的大小(比如说美国运行商at&t需要3m，50m，500m大小的升级包)。为了解决这个问题比较容易想到的方法就是一直编译特定需求的版本，然后再次去做升级包，这样反复尝试去做版本，再做包，也许可能可以做出符合容量大小的升级包，这样会浪费很多时间，50m和500m大小的升级包可以做出来，但3m大小的升级包几乎是不能制作出来，原因是重新编译的一个版本，其中的system镜像是一个ext4的文件系统，即便内容完全相同，从二进制的角度来看是完全不相同的，比如一个文件/system/build.prop存放块的绝对地址是不一样，甚至一个文件可能存放在不同的物理地址上面，所以前后两个版本基于块设备做包差异一般都是非常大的，这就是很难做出3m大小包的原因。有关制作特定大小升级包方面的方案还没有出现。

针对相关技术中存在的上述问题，目前尚未发现有效的解决方案。

技术实现要素：

本发明实施例提供了一种升级包的生成方法及装置，以至少解决相关技术中在基于块制作升级包时不能生成特定大小的升级包的问题。

根据本发明的一个实施例，提供了一种升级包的生成方法，包括：判断根目录下是否存在签名目标文件；在存在所述签名目标文件时，解压所述签名目标文件，删除其中的images目录，并修改待升级的文件内容；使用指定脚本重新生成系统镜像，并生成升级包。

可选地，所述方法还包括：在根目录下不存在所述签名目标文件时，把系统镜像转换为ext4格式，并通过system.map查找待修改文件的绝对地址；使用winhex工具修改system目录中的文件内容，生成新的系统镜像后转换为sparse格式，并生成升级包。

可选地，修改升级的文件内容包括以下至少之一：修改system文件；修改build.prop文件；修改system文件的外部版本号信息；修改build.prop文件的外部版本号信息。

可选地，在生成升级包之后，所述方法还包括：在所述升级包中加入预定容量的二进制数据得到指定升级包；使用签名脚本给所述指定升级包签名。

可选地，在解压所述签名目标文件之前，所述方法还包括：拷贝一份所述签名目标文件到指定存储设备，并重新命名拷贝版本的签名目标文件；将所述拷贝版本的签名目标文件确定为待解压的签名目标文件。

根据本发明的另一个实施例，提供了一种升级包的生成装置，包括：判断模块，用于判断根目录下是否存在签名目标文件；第一处理模块，用于在存在所述签名目标文件时，解压所述签名目标文件，删除其中的images目录，并修改待升级的文件内容；第一生成模块，用于使用指定脚本重新生成系统镜像，并生成升级包。

可选地，所述装置还包括：第二处理模块，用于在根目录下不存在所述签名目标文件时，把系统镜像转换为ext4格式，并通过system.map查找待修改文件的绝对地址；第二生成模块，用于使用winhex工具修改system目录中的文件内容，生成新的系统镜像后转换为sparse格式，并生成升级包。

可选地，所述装置还包括：添加模块，用于在生成升级包之后，在所述升级包中加入预定容量的二进制数据得到指定升级包；签名模块，用于使用签名脚本给所述指定升级包签名。

根据本发明的又一个实施例，还提供了一种存储介质。该存储介质设置为存储用于执行以下步骤的程序代码：

判断根目录下是否存在签名目标文件；

在存在所述签名目标文件时，解压所述签名目标文件，删除其中的images目录，并修改待升级的文件内容；

使用指定脚本重新生成系统镜像，并生成升级包。

通过本发明，在存在签名目标文件时，解压签名目标文件，删除其中的images目录，并修改待升级的文件内容，使用指定脚本重新生成系统镜像，并生成升级包。解决了相关技术中在基于块制作升级包时不能生成特定大小的升级包的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的升级包的生成方法的流程图；

图2是根据本发明实施例的升级包的生成装置的结构框图；

图3是本发明实施例的数据流程示意图；

图4是本发明本实施例提供的方法的流程示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

实施例1

在本实施例中提供了一种升级包的生成方法，图1是根据本发明实施例的升级包的生成方法的流程图，如图1所示，该流程包括如下步骤：

步骤s102，判断根目录下是否存在签名目标文件；

步骤s104，在存在签名目标文件时，解压签名目标文件，删除其中的images目录，并修改待升级的文件内容；

步骤s106，使用指定脚本重新生成系统镜像，并生成升级包。

通过上述步骤，在存在签名目标文件时，解压签名目标文件，删除其中的images目录，并修改待升级的文件内容，使用指定脚本重新生成系统镜像，并生成升级包。解决了相关技术中在基于块制作升级包时不能生成特定大小的升级包的问题。

可选地，上述步骤的执行主体可以为终端，升级工具等，但不限于此。

本实施例中的指定脚本可以是img_from_target_files脚本。

可选地，本实施例中，作为另外一个实施场景，包括：

s11，在根目录下不存在签名目标文件时，把系统镜像转换为ext4格式，并通过system.map查找待修改文件的绝对地址；

s12，使用winhex工具修改system目录中的文件内容，生成新的系统镜像后转换为sparse格式，并生成升级包。

在本实施例中，修改升级的文件内容包括以下至少之一：修改system文件；修改build.prop文件；修改system文件的外部版本号信息；修改build.prop文件的外部版本号信息。

在本实施例中，在生成升级包之后，在前一次生成的升级包没有符合特定大小的要求时，还包括：

s21，在升级包中加入预定容量的二进制数据得到指定升级包；加进去的二进制数据可以是无用的数据，在使用升级包升级时终端可以自动识别并删除；

s22，使用签名脚本给指定升级包签名。

可选的，在解压签名目标文件之前，还包括：

s31，拷贝一份签名目标文件到指定存储设备，并重新命名拷贝版本的签名目标文件；

s32，将拷贝版本的签名目标文件确定为待解压的签名目标文件。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

在本实施例中还提供了一种升级包的生成装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图2是根据本发明实施例的升级包的生成装置的结构框图，如图2所示，该装置包括：

判断模块20，用于判断根目录下是否存在签名目标文件；

第一处理模块22，用于在存在签名目标文件时，解压签名目标文件，删除其中的images目录，并修改待升级的文件内容；

第一生成模块24，用于使用指定脚本重新生成系统镜像，并生成升级包。

可选的，装置还包括：第二处理模块，用于在根目录下不存在签名目标文件时，把系统镜像转换为ext4格式，并通过system.map查找待修改文件的绝对地址；第二生成模块，用于使用winhex工具修改system目录中的文件内容，生成新的系统镜像后转换为sparse格式，并生成升级包。

可选的，装置还包括：添加模块，用于在生成升级包之后，在升级包中加入预定容量的二进制数据得到指定升级包；签名模块，用于使用签名脚本给指定升级包签名。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

实施例3

本实施例是根据本发明的可选实施例，用于对本申请进行补充和详细说明：

本实施例中制作特定升级包可以是user版本，其他版本也可以，图3是本发明实施例的数据流程示意图，编译版本的时候会生成一个集合boot，recovery和system目录的后者为a.zip格式的文件(叫做签名目标文件(signed-target-files.zip文件))，如果没有删除这个文件，并且其中的内容没有发生过修改，先解压a.zip这个文件，解压后删除其中的images目录，要是不删除掉就会使用其中已经生成的bootimage，recoveryimage和systemimage镜像，任何修改都不会生效；然后去修改需要改的文件内容，比如说修改system/build.prop这个文件中的外部版本号信息等，重新压缩刚才那个解压后文件目录，注意使用zip命令的时候一定需要加-ry参数，不然system镜像中的软连接都会丢失的，使用google的img_from_target_files.py这个脚本重新生成新的systemimage等镜像。

把这个新的镜像打包到原先的版本中，替换原先的systemimage镜像，再把此版本改个名称，这两者之间制作基于块设备的升级包，因为前后版本的systemimage镜像出自于一个system目录，形成的system镜像中的文件顺序和大小是一样的，修改其中不多的文件，且每个文件大小没有超过原先4k大小，所以基于块设备方式制作的升级包会比较小。

有时候由于各种原因a.zip这个文件会被删除掉，就不能基于上面这种方法了，可以使用原先的system镜像以及对应的system.map来生成新的镜像了。system.map是一个存放所有文件的地址表，比如/system/build.prop851944-851946，是指存放在以4k为单位从头开始的第851944和851945这两个块(不包括851946)，这样就可以用winhex工具打开system.img.ext4镜像(需要先从sparse格式转化为ext4)，找到对应的地址修改相应的数值，但是这种方法只能替换原先值，比如ro.build.display.id＝z831v1.0.0b24改变为ro.build.display.id＝z831v1.0.0b2*，不能增加或者延长新的字符，因为新添加字符会导致数据溢出和结束符丢失等问题，设备升级后会导致没法开机。

本实施用例提供了一种android设备从加密外置t卡读取升级包的升级方案。请参考图4，图4是本发明本实施例提供的方法的流程示意图，包括：

步骤s101：按照android编译一个完整的user版本，在根目录下面会生成a.zip(一般是signed-target-files.zip这个文件)文件，拷贝一份将其改名为fota-target-files.zip；其中，fota(firmwareover-the-air)为移动终端的空中下载软件升级。

步骤s102：每次在出user版本的时候都会在根目录下生成signed-target-files.zip，判断是否存在文件signed-target-files.zip，若不存在走s103步骤，若存在走步骤s106；

步骤s103：先使用simg2img把system镜像转换为ext4格式，通过system.map找到需要修改文件的绝对地址，system.map是一个存放所有文件的地址表，比如/system/build.prop851944-851946，是指存放在以4k为单位从头开始的第851944和851945这两个块(不包括851946)；

步骤s104：使用winhex工具打开ext4格式的system镜像，修改的system镜像其中的文件内容，不能改变原有字符长度，比如ro.build.display.id＝z831v1.0.0b24改变为ro.build.display.id＝z831v1.0.0b2*，不能增加或者延长新的字符，因为新添加字符会导致数据溢出和结束符丢失等问题，设备升级后会导致没法开机；

步骤s105：生成新的system镜像后，再次使用img2simg命令将ext4格式转换为sparse格式，把此system镜像打包为一个新的版本，此版本与之前的版本之间只有system镜像不同；

步骤s106：既然存在a.zip，就拷贝一份并重命名为fota-target-files.zip；

步骤s107：解压fota-target-files.zip并删除掉images文件夹及里面的内容，要是不删除掉就会使用其中已经生成的bootimage，recoveryimage和systemimage镜像，任何修改不会生效。

步骤s108：修改fota-target-files目录中下面需要修改的文件，比如说system/build.prop文件，修改其中的外部版本号，注意修改前后文件属性必须与之前一致；

步骤s109：打包fota-target-files目录里面的所有文件，注意一定需要在fota-target-files目录下使用zip-ry

fota-target-files_new.zip./命令，其中的r是指各级子目录有效，y参数的意思是指保留原有的所有软连接；

步骤s110：在android编译环境的根目录下调用如下命令，

sudo./build/tools/releasetools/img_from_target_files

fota-target-files_new.zipfota_img.zip，在新生成的fota_img.zip中有新生成的system.img和system.map，拷贝出来替换原先的版本中对应的镜像，从而生成新的目标版本；

步骤s111：使用做包脚本重新制作升级包，让android设备升级此版本，升级后看看是否达到预期效果；

步骤s112：如果需要更大的升级包，可以向其中塞入合适容量大小的二进制数据，然后使用签名脚本重新给此升级包签名一下，让android设备去升级此版本，升级过程中塞入的数据并不会写入android设备中；

先按照上面的方法制作特定大小的升级包，再将一张普通的外置t卡插入到移动终端中，然后通过mtp拷贝方式等，将此升级包拷贝到这张t卡上，将升级包改名为update.zip，升级之前先看下设备的版本号。需要升级的移动android设备可以通过设置模块下系统更新按钮检测到此升级包，系统上层会调用系统重启进入recovery模式进行升级，会看到小机器人不断转动，进度条会显示从0％升级到100％，升级后外置t卡中的升级包会被删除掉，不影响用户使用t卡数据区，升级后开机再看下设备的版本号是否发生变化。

实施例4

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：

s1，判断根目录下是否存在签名目标文件；

s2，在存在签名目标文件时，解压签名目标文件，删除其中的images目录，并修改待升级的文件内容；

s3，使用指定脚本重新生成系统镜像，并生成升级包。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行判断根目录下是否存在签名目标文件；

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行在存在签名目标文件时，解压签名目标文件，删除其中的images目录，并修改待升级的文件内容；

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行使用指定脚本重新生成系统镜像，并生成升级包。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。