[发明专利]系统更新方法及非短暂计算机可读介质

说明书

技术领域

本申请涉及电数字数据的处理领域，尤其涉及一种系统更新方法和保存用于实现前述方法的可执行代码的非短暂计算机可读介质。

背景技术

目前Android系统Recovery升级采用的是两层设计架构：Recovery主体程序+Updater脚本执行程序+升级包。执行方式为Recovery主体程序先启动，在完成必要的挂载分区、校验升级包签名后，再fork出一个进程来加载执行Updater程序来执行升级脚本。在这种架构中，Recovery主体程序内部的代码都是根据系统具体的需求固定死的，比如分区名称、签名验证规则、解析升级脚本的规则等等，一旦系统发布到市场后，只能在满足现有代码基础上做适当的修改或者升级，无法对系统进行根本性的改变，也就是无法任意定制系统。例如，发布出去的是一个系统，现在希望通过升级程序变成双系统，甚至改变用户可见存储大小等等，这些需求是现有Android Recovery程序架构无法满足的，因为Android Recovery设计架构的前提条件是不改变分区表的前提下进行升级，因此设计了前述架构。同时，Android的升级包是明文的，也就是说一旦解压后，可以看到明文的升级脚本内容，这不利于系统安全性，会泄露系统相关分区以及升级信息。

发明内容

为了克服现有技术中存在的不足，本发明要解决的技术问题是提供一种系统更新方法，其使能通过更新任意定制和改造系统，而代码改写量远小于传统recovery升级架构的代码改写量。

为解决上述技术问题，本发明系统更新方法，包括：

生成用于执行更新的主程序；

生成一个或多个更新子程序执行体，其中每一更新子程序具有相应的功能，及所述一个或多个更新子程序执行体在成功执行后构成所述系统的至少一部分；

生成更新配置文件，所述更新配置文件包含所述一个或多个更新子程序执行体的路径；

其中所述主程序在启动运行时，加载解析所述更新配置文件，并根据所述更新配置文件中的所述路径逐一加载和执行所述一个或多个更新子程序执行体中的每一更新子程序执行体。

作为本发明所述方法的改进，所述方法还包括：将所述一个或多个更新子程序执行体和所述更新配置文件打包成更新包。

作为本发明所述方法的进一步改进，所述方法还包括：所述主程序在启动运行时，对所述更新包的合法性进行校验。

作为本发明所述方法的另一种改进，所述方法还包括：所述主程序在加载一更新子程序执行体之后对其进行安全性校验。

作为本发明所述方法的又一种改进，所述方法还包括：每一更新子程序执行体在执行后将执行结果回传给所述主程序。

作为本发明所述方法的再一种改进，所述方法还包括：所述主程序在所有更新子程序执行体成功执行后提供更新成功的反馈。

为解决上述技术问题，本发明非短暂计算机可读介质，保存有用于执行系统更新的主程序、一个或多个更新子程序执行体和更新配置文件，其中每一更新子程序具有相应的功能，及所述一个或多个更新子程序执行体在成功执行后构成所述系统的至少一部分，所述更新配置文件包含所述一个或多个更新子程序执行体的路径；其中，所述主程序在启动运行时，加载解析所述更新配置文件，并根据所述更新配置文件中的所述路径逐一加载和执行所述一个或多个更新子程序执行体中的每一更新子程序执行体。

本发明方法提出了一种新的Recovery架构，其采用Recovery主程序+Recovery更新配置文件+子程序执行体的方式。配置文件中保存的是主程序需要启动执行的子程序路径，用户根据需要可以配置任意多个子程序，用户可以定制每一个子程序的功能，而Recovery主程序代码永远不需要改变，仅仅是按照配置文件的内容来加载并执行子程序即可，每一个子程序的执行结果都会回传给主程序，从而可通过更新任意定制系统，满足任意升级的需求。

另外，升级包的内容仅仅包含新的Recovery配置文件和新的子程序执行体两部分内容，这样的升级包即使泄露出去，也无法从中看出系统的相关信息，使系统更加安全。

结合附图阅读本发明实施方式的详细描述后，本发明的其它特点和优点将变得更加清楚。

附图说明

图1为根据本发明方法的一实施例的流程图。

图2为使用本发明方法进行系统更新的一实施例的流程图。

为清晰起见，这些附图均为示意性及简化的图，它们只给出了对于理解本发明所必要的细节，而省略其他细节。

具体实施方式