一种安卓系统中固件的补丁管理方法及系统
技术领域
本发明涉及一种补丁管理方法,尤其涉及一种安卓系统中固件的补丁管理方法,并涉及采用了该安卓系统中固件的补丁管理方法的补丁管理系统。
背景技术
对于方案公司,安卓系统的固件(Android固件)针对不同的客户,其固件会不同,处理软件的人员也是不同,已经解决问题的补丁更新到输出固件中光靠工程师自己是很难确保,而且对于测试人员他们也很难检出几率性问题,也不会每版软件都去做这个测试。
有时客户拿问题机器过来分析,对于一些几率性问题我们需要拿更多的机器进行复现分析,但是客户有可能只提供一台机器,这时我们要从现有的调试机器中去找,分析时可能需要知道其对应的固件。
因为固件很多,当客户要求基于某个固件基础上修改他们的需求,这时可能因为时间长或之前维护的人员离职等原因导致找不到代码环境,如果更新最新的代码,就有可能会引起新的异常问题以及漏掉客制化需求。
发明内容
本发明所要解决的技术问题是需要提供一种能够快速获取设备的代码环境,及时检测出未更新的补丁,对固件升级等问题提供帮助的安卓系统中固件的补丁管理方法,并涉及采用了该安卓系统中固件的补丁管理方法的补丁管理系统。
对此,本发明提供一种安卓系统中固件的补丁管理方法,包括以下步骤:
步骤S1,在安卓系统的编译脚本中收集包括了软件配置信息的代码环境信息;
步骤S2,在软件编译过程中,执行信息收集脚本,并写入到输出固件中;
步骤S3,将输出固件刷机到设备中,从设备的App查看包括了软件配置信息的代码环境信息;
步骤S4,通过安卓安装包检测未更新的补丁。
本发明的进一步改进在于,所述步骤S1中,所述软件配置信息包括内存信息、频率信息、摄像机信息、显示模组信息、TP信息、电池信息和传感信息中的任意一种或几种。
本发明的进一步改进在于,所述步骤S1中,所述代码环境信息包括编译主机信息、代码路径信息、软件配置信息、代码分支信息以及查看提交记录信息中的任意一种或几种。
本发明的进一步改进在于,当出现新补丁时,将新补丁提交到安卓系统的的标准分支中,并通过标准分支的查看提交记录信息记录其提交记录,以此提交记录作为所述步骤S4检测未更新的补丁的标准参照物。
本发明的进一步改进在于,所述步骤S2包括以下子步骤:
步骤S201,在设备目录文件中引用信息收集脚本;
步骤S202,编译时会调用设备目录文件,同时执行信息收集脚本;
步骤S203,信息收集脚本通过命令收集信息,并将收集信息的结果按照预定格式记录到编译的输出固件目录中。
本发明的进一步改进在于,所述步骤S4包括以下子步骤:
步骤S401,安装安卓安装包,并拷贝一个标准补丁集到设备的内部存储中;
步骤S402,解读并记录标准补丁集,同时解读设备中的历史文件,获取其中的查看提交记录信息;
步骤S403,将所述步骤S402获得的查看提交记录信息和标准补丁集进行逐条对比,将存在于标准补丁集中且不存在于查看提交记录信息中的补丁记录下来,以此作为当前设备所对应的未更新的补丁集合。
本发明的进一步改进在于,所述步骤S402中,获取所述查看提交记录信息后,将其转换为xml格式。
本发明的进一步改进在于,所述步骤S403中,设备的固件在编译时收集了当时的代码环境信息,该代码环境信息包括了当时代码环境的查看提交记录信息,将预定格式的查看提交记录信息解读出来后,再实现和标准补丁集的逐条对比。
本发明的进一步改进在于,所述查看提交记录信息和标准补丁集之间采用关键字比较实现逐条对比。
本发明还提供一种安卓系统中固件的补丁管理系统,采用了如上所述的安卓系统中固件的补丁管理方法。
与现有技术相比,本发明的有益效果在于:通过步骤S1至步骤S3,能够从已有的设备中快速得到该设备中固件所对应的代码环境,并从设备的已有固件获得该固件所对应的硬件配置,加之,结合步骤S4就能检测现有的固件是否存在未更新的补丁,避免补丁更新不及时,防止已知问题的再次发生,减少客户投诉,对固件升级等问题的调试提供了很大的帮助。
附图说明
图1是本发明一种实施例的工作流程示意图;
图2是本发明一种实施例的代码环境信息的信息结构图;
图3是本发明一种实施例的代码环境信息的信息预览示例截图;
图4是本发明一种实施例的工作关系示意图。
具体实施方式
下面结合附图,对本发明的较优的实施例作进一步的详细说明:
如图1所示,本例提供一种安卓系统中固件的补丁管理方法,包括以下步骤:
步骤S1,在安卓系统的编译脚本中收集包括了软件配置信息的代码环境信息;
步骤S2,在软件编译过程中,执行信息收集脚本,并写入到输出固件中;
步骤S3,将输出固件刷机到设备中,从设备的App查看包括了软件配置信息的代码环境信息;
步骤S4,通过安卓安装包检测未更新的补丁。
本例所述步骤S1中,所述软件配置信息包括内存信息(DDR)、频率信息(eMMCCLK)、摄像机信息(Camera)、显示模组信息(LCM)、TP信息(TP,该TP指的是TP-LINK)、电池信息(Battery)和传感信息(Sensors)中的任意一种或几种。所述代码环境信息包括编译主机信息、代码路径信息、软件配置信息、代码分支信息以及查看提交记录信息(git log信息)中的任意一种或几种。在安卓系统(Android系统)的编译脚本中添加收集当前的软件配置信息以及编译软件的代码环境信息,详见图2所示的信息结构图以及如图3所示的信息预览示例截图。
本例所述步骤S2包括以下子步骤:
步骤S201,在项目的设备目录文件(device.mk文件)中引用信息收集脚本;
步骤S202,编译时会调用项目的设备目录文件(device.mk文件),同时执行信息收集脚本;
步骤S203,信息收集脚本通过命令收集信息,并将收集信息的结果按照预定格式记录到编译的输出固件目录中,如out/target/product/xxx/system/etc/.history)。
这个信息收集脚本是在Android编译一开始就执行的,所以历史文件(history)在Android编译过程中会自动打包到系统文件(system.img)中,该系统文件(system.img)是Android固件的其中一个文件。
本例所述软件配置信息以及代码环境信息收集的信息会被写入到输出固件中,接下来输出的固件被刷机到设备中,设备开机后通过App来读取这部分信息,详见图4。
本例所述步骤S4包括以下子步骤:
步骤S401,安装安卓安装包(APK),该安装可以通过CommitChecker实现,并拷贝一个标准补丁集到设备的内部存储中,该标准补丁集是xml文件,由公版代码环境下执行查看提交记录(git log)转xml的脚本生成;
步骤S402,解读并记录标准补丁集(集合A),该解读可以通过CommitChecker实现,同时解读设备中的历史文件(/system/etc/.history),获取其中的查看提交记录信息(集合B);
步骤S403,将所述步骤S402获得的查看提交记录信息(集合B)和标准补丁集(集合A)进行逐条对比,将存在于标准补丁集(集合A)中且不存在于查看提交记录信息(集合B)中的补丁记录下来,得到集合C,以此集合C作为当前设备所对应的未更新的补丁集合。该未更新的补丁集合用于实现对设备的固件升级。本例中,CommitChecker为步骤S4中用于实现未更新的补丁集合检测的安卓安装包。
值得一提的是,所述步骤S4中如何实现未更新的补丁检测呢?首先要进行检测必须要有一个标准参照物,这个参照物如何获取采取什么样的形式来做是一个很关键的因素。本例当出现新补丁时,将新补丁提交到安卓系统的的标准分支(master分支)中,并通过标准分支(master分支)的查看提交记录信息记录其提交记录,以此提交记录作为所述步骤S4检测未更新的补丁的标准参照物。
接下来需要解决的问题是如何将查看提交记录(git log)的信息转变为App易读的格式;本例所述步骤S402中,获取所述查看提交记录信息后,将其转换为xml格式。
标准参照物的xml格式生成后,还需要解决如何与设备(如平板)的本地信息进行比较。设备(如平板)的固件在编译时收集了当时的代码环境信息,其中就包含当时代码环境的查看提交记录(git log)的信息,这也是本例的亮点。
也就是说,本例所述步骤S403中,设备的固件在编译时收集了当时的代码环境信息,该代码环境信息包括了当时代码环境的查看提交记录信息,将预定格式的查看提交记录信息解读出来后,再实现和标准补丁集的逐条对比。预定格式是用户事先自定义的,或是采用默认格式,所以这个解读过程会比较容易实现。
当前平板的补丁集合信息和标准补丁集合信息都得到了之后,本例所述查看提交记录信息和标准补丁集之间采用关键字比较实现逐条对比,就能够得出最终的未更新的补丁集合。
综上,首先在安卓系统的代码环境中的编译过程添加记录代码环境,比如主机ip、分支和更新git log记录等信息的脚本,这个脚本将收集的信息会打包到固件中,并最后执行发布固件脚本,将固件以及部分收集的信息压缩到一个zip文档实现固件输出。然后在输出固件刷机后,使用步骤S4(CommitChecker APK)来进行检查是否有漏掉补丁。
对于这点,本例是将查看提交记录(git log)通过脚本转变为xml文档,然后步骤S4(CommitChecker APK)来读取这个xml做为标准,与固件中的查看提交记录(git log)部分的信息来比较。
本例还提供一种安卓系统中固件的补丁管理系统,采用了如上所述的安卓系统中固件的补丁管理方法。
因此,本例通过步骤S1至步骤S3,能够从已有的设备中快速得到该设备中固件所对应的代码环境,并从设备的已有固件获得该固件所对应的硬件配置,加之,结合步骤S4就能检测现有的固件是否存在未更新的补丁,避免补丁更新不及时,防止已知问题的再次发生,减少客户投诉,对固件升级等问题的调试提供了很大的帮助。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。