CN117707566A - 一种操作系统升级方法及电子设备 - Google Patents

一种操作系统升级方法及电子设备 Download PDF

Info

Publication number
CN117707566A
CN117707566A CN202311071800.8A CN202311071800A CN117707566A CN 117707566 A CN117707566 A CN 117707566A CN 202311071800 A CN202311071800 A CN 202311071800A CN 117707566 A CN117707566 A CN 117707566A
Authority
CN
China
Prior art keywords
partition
sub
electronic device
partitions
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311071800.8A
Other languages
English (en)
Inventor
陈超
王艳召
郝庆涛
郭昊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202311071800.8A priority Critical patent/CN117707566A/zh
Publication of CN117707566A publication Critical patent/CN117707566A/zh
Pending legal-status Critical Current

Links

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提供一种操作系统升级方法及电子设备。方法包括:获取第一分区表;获取第二分区表;基于第一分区表,确定电子设备的内存中的动态分区中的多个第一子分区的起始物理地址;基于第二分区表,确定动态分区中的多个第二子分区的起始物理地址;确定多个第一子分区中的第一目标子分区;将目标区域中的子分区搬移至用户数据分区,将目标区域中的子分区覆盖写入动态分区中的目标偏移地址,将动态分区的第一分区表修改为第二分区表。这样,电子设备可以对操作系统进行远程升级,实现演示机制式到商用机制式的更改,并在更改制式过程中,对分区进行按需搬移,提高分区搬移的可靠性和通用性。

Description

一种操作系统升级方法及电子设备
技术领域
本申请涉及终端设备领域,具体涉及一种操作系统升级方法及电子设备。
背景技术
操作系统(Operating System)是一种控制和管理电子设备的硬件和软件资源的软件系统,电子设备需要安装操作系统才可以被用户使用。示例的,电子设备为手机时,手机上需要安装手机对应的操作系统(例如:IOS操作系统,安卓操作系统)才可以被用户使用。
电子设备的操作系统需要配置对应的制式(vendor_country,VC)。操作系统在不同制式下的系统分区存在差异。例如,演示样机的制式为demo_cn,该制式的系统分区中Version子分区用于存放大量的操作演示样片,占用较大内存,而商用机的制式为all_cn,该制式的系统分区中Version子分区中无需存放操作演示样片,无需较大内存。因此,在电子设备下市后,为了使演示样机也面向用户销售,需要将演示样机的制式更改为商用机的制式。
这样,电子设备需要对操作系统进行远程升级,实现演示机制式到商用机制式的更改,然而,目前的更改制式过程中,涉及到的分区搬移过程存在限制性强,可靠性低的问题。
发明内容
本申请实施例提供一种操作系统升级方法及电子设备,能够解决目前更改制式过程中,涉及到的分区搬移过程存在限制性强、可靠性低的问题,提高分区搬移的可靠性和通用性。
第一方面,本申请实施例提供一种操作系统升级方法,应用于电子设备,方法包括:获取第一分区表;获取第二分区表;基于第一分区表,确定电子设备的内存中的动态分区中的多个第一子分区的起始物理地址;基于第二分区表,确定动态分区中的多个第二子分区的起始物理地址,多个第二子分区是对多个第一子分区的至少一部分进行搬移后得到的子分区;确定多个第一子分区中的第一目标子分区,第一目标子分区是多个第一子分区中与多个第二子分区中名称相同,但是起始物理地址不同的第一个子分区;将目标区域中的子分区搬移至内存中的用户数据分区,目标区域中的子分区是多个第一子分区中位于第一目标子分区至用户数据分区之间的子分区;将目标区域中的子分区覆盖写入动态分区中的目标偏移地址,将动态分区中的第一分区表修改为第二分区表。
本申请实施例提供的操作系统升级方法,能够通过对第一分区表和第二分区表进行解析和比对,得到多个第一子分区和多个第二子分区中名称相同,但是起始物理地址不同的第一目标子分区,从而由第一目标子分区开始进行搬移,使未更改的分区保持原状,仅对更改的分区进行搬移,实现了分区的按需搬移,在操作系统升级过程中,提高了分区搬移过程的可靠性和通用性。
在一种实现方式中,获取第一分区表包括:在第一制式下,依次加载内存中的基础分区、内存中的第一静态分区以及动态分区,加载动态分区之后,获取第一分区表;获取第二分区表包括:获取系统升级包,基于系统升级包,获取第二分区表。采用本实现方式,基于虚拟A/B升级方式启动后,获取到第一分区表和第二分区表,以便于对第一分区表和第二分区表进行解析。
在一种实现方式中,获取系统升级包之后,还包括:基于系统升级包完成系统升级后,第一次进入恢复模式,调用恢复进程将电子设备的操作系统由第一制式更改为第二制式;其中,当电子设备的操作系统由第一制式更改为第二制式时,将动态分区在第一制式下的多个第三子分区更新为第二制式下的多个第一子分区。采用本实现方式,第一次进入恢复模式后可以完成制式更改,将第三子分区更新为第一子分区,以便于进一步在第二次进入恢复模式时对第一子分区进行分区搬移。
在一种实现方式中,第一制式包括演示机制式,第二制式包括商用机制式。采用本实现方式,表明了第一制式和第二制式的具体实现形式。
在一种实现方式中,基于第一分区表,确定电子设备的内存中的动态分区中的多个第一子分区的起始物理地址,包括:第二次进入恢复模式,确定每个第一子分区的连续物理块对应的第一数量,基于第一数量确定每个第一子分区的连续物理块对应的起始物理地址。采用本实现方式,可以得到第一子分区的连续物理块对应的起始物理地址,以便于与第二子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,基于第一分区表,确定电子设备的内存中的动态分区中的多个第一子分区的起始物理地址,包括:第二次进入恢复模式,调用恢复进程遍历第一分区表中的多个第一子分区,确定每个第一子分区的连续物理块对应的第一数量;基于第一数量反向索引至第一分区表中的第一数据结构,从第一数据结构中确定每个第一子分区的连续物理块对应的起始物理地址。采用本实现方式,可以通过恢复进程得到第一子分区的连续物理块对应的起始物理地址,以便于与第二子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,基于第二分区表,确定动态分区中的多个第二子分区的起始物理地址,包括:第二次进入恢复模式,确定每个第二子分区的连续物理块对应的第二数量,基于第二数量确定每个第二子分区的连续物理块对应的起始物理地址。采用本实现方式,可以得到第二子分区的连续物理块对应的起始物理地址,以便于与第一子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,基于第二分区表,确定动态分区中的多个第二子分区的起始物理地址,包括:第二次进入恢复模式,调用恢复进程遍历第二分区表中的多个第二子分区,确定每个第二子分区的连续物理块对应的第二数量;基于第二数量反向索引至第二分区表中的第二数据结构,从第二数据结构中确定每个第二子分区的连续物理块对应的起始物理地址。采用本实现方式,可以通过恢复进程得到第二子分区的连续物理块对应的起始物理地址,以便于与第一子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,第二次进入恢复模式,调用恢复进程遍历第一分区表中的多个第一子分区,确定每个第一子分区的连续物理块对应的第一数量,包括:基于第一分区表对应的第一Lp元数据结构中的第一Lp元数据分区表结构,遍历第一分区表中的多个第一子分区,确定每个第一子分区的索引结构;基于每个第一子分区的索引结构中的第一连续物理块数量结构,确定第一分区表中的每个第一子分区的连续物理块对应的第一数量。采用本实现方式,示出了获取第一数量的具体方式,以便于得到第一子分区的连续物理块对应的起始物理地址,与第二子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,第二次进入恢复模式,调用恢复进程遍历第二分区表中的多个第二子分区,确定每个第二子分区的连续物理块对应的第二数量,包括:基于第二分区表对应的第二Lp元数据结构中的第二Lp元数据分区表结构,遍历第二分区表中的多个第二子分区,确定每个第二子分区的索引结构;基于每个第二子分区的索引结构中的第二连续物理块数量结构,确定第二分区表中的每个第二子分区的连续物理块对应的第二数量。采用本实现方式,示出了获取第二数量的具体方式,以便于得到第二子分区的连续物理块对应的起始物理地址,与第一子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,第一数据结构是第一分区表中的第一Lp元数据连续物理块结构;基于第一数量反向索引至第一分区表中的第一数据结构,从第一数据结构中得到每个第一子分区的连续物理块对应的起始物理地址,包括:基于第一数量反向索引至第一分区表中的第一Lp元数据连续物理块结构;基于第一Lp元数据连续物理块结构中的第一目标数据结构,确定每个第一子分区的连续物理块对应的起始物理地址。采用本实现方式,示出了获取第一子分区的连续物理块对应的起始物理地址的具体方式,以便于与第二子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,第二数据结构是第二分区表中的第二Lp元数据连续物理块结构;基于第二数量反向索引至第二分区表中的第二数据结构,从第二数据结构中得到每个第二子分区的连续物理块对应的起始物理地址,包括:基于第二数量反向索引至第二分区表中的第二Lp元数据连续物理块结构;基于第二Lp元数据连续物理块结构中的第二目标数据结构,确定每个第二子分区的连续物理块对应的起始物理地址。采用本实现方式,示出了获取第二子分区的连续物理块对应的起始物理地址的具体方式,以便于与第一子分区的连续物理块对应的起始物理地址进行比对,进而进行分区搬移。
在一种实现方式中,确定多个第一子分区中的第一目标子分区,包括:获取第一分区表中每个第一子分区的连续物理块对应的第一目标数据结构;获取第二分区表中每个第二子分区的连续物理块对应的第二目标数据结构;将每个第一子分区的连续物理块对应的第一目标数据结构和每个第二子分区的连续物理块对应的第二目标数据结构依次比对;将第一次获取到的多个第一子分区中与多个第二子分区的名称相同,但是第一目标数据结构与第二目标数据结构不同的子分区确定为第一目标子分区。采用本实现方式,示出了第一目标子分区的具体确定方式,这样,可以由第一目标子分区开始进行搬移,使未更改的分区保持原状,实现了分区的按需搬移,在操作系统升级过程中,提高了分区搬移过程的可靠性和通用性。
在一种实现方式中,将目标区域中的子分区搬移至内存中的用户数据分区,包括:基于目标区域中的子分区对应的第一目标数据结构,将目标区域中的子分区由第一目标子分区开始,依次搬移至用户数据分区的尾部。采用本实现方式,示出了分区搬移的具体方式,这样,可以由第一目标子分区开始进行搬移,使未更改的分区保持原状,实现了分区的按需搬移,在操作系统升级过程中,提高了分区搬移过程的可靠性和通用性。
在一种实现方式中,第二次进入恢复模式,调用恢复进程遍历第一分区表中的多个第一子分区,确定每个第一子分区的连续物理块对应的第一数量之后,还包括:基于第一数量反向索引至第一分区表中的第一数据结构,从第一数据结构中确定每个第一子分区的连续物理块对应的连续物理块大小。采用本实现方式,示出了第一子分区的连续物理块的连续物理块大小的具体获取方式,这样,能够根据连续物理块大小进一步获取目标偏移地址,实现分区搬移。
在一种实现方式中,基于第一数量反向索引至第一分区表中的第一数据结构,从第一数据结构中确定每个第一子分区的连续物理块对应的连续物理块大小,包括:基于第一数量反向索引至第一分区表中的第一Lp元数据连续物理块结构;基于第一Lp元数据连续物理块结构中的第一数量结构,确定每个第一子分区的连续物理块对应的连续物理块大小。采用本实现方式,示出了第一子分区的连续物理块的连续物理块大小的具体获取方式,这样,能够根据连续物理块大小进一步获取目标偏移地址,实现分区搬移。
在一种实现方式中,目标偏移地址的获取方式包括:获取第一制式下,动态分区的预设分区大小;获取目标区域的子分区的总分区大小;将预设分区大小与总分区大小的差值确定为目标偏移地址;其中,总分区大小是根据每个第一子分区的连续物理块大小之和确定的,其中,基于每个第一子分区的连续物理块对应的第一目标数据结构和对应的第一数量结构,确定每个第一子分区的连续物理块大小之和。采用本实现方式,示出了目标偏移地址的获取方式,这样,可以将发生更改的一部分子分区由用户数据分区的尾部搬移至动态分区中的目标偏移地址,完成分区搬移,实现了分区的按需搬移,在操作系统升级过程中,提高了分区搬移过程的可靠性和通用性。
在一种实现方式中,将目标区域中的子分区覆盖写入动态分区中的目标偏移地址之后,还包括:获取动态分区中的每个第二子分区对应的第三目标数据结构;根据第二分区表中每个第二子分区对应的第二目标数据结构校验第三目标数据结构;在每个第二子分区对应的第二目标数据结构与对应的第三目标数据结构相同的情况下,将动态分区中的第一分区表修改为第二分区表;在任一第二子分区对应的第二目标数据结构与对应的第三目标数据结构不同的情况下,显示报错信息。采用本实现方式,完成分区搬移之后,需要对搬移的分区进行校验,以确定分区搬移的准确性,提高了分区搬移的可靠性。
第二方面,本申请实施例提供一种电子设备,包括:处理器和存储器,存储器存储有程序指令,当程序指令被处理器执行时,使得电子设备执行如上述第一方面及任一实现方式中的操作系统升级方法。
第三方面,本申请实施例提供一种计算机可读存储介质,计算机可读存储介质中存储有指令,当指令在电子设备上运行时,使得电子设备执行如上述第一方面及任一实现方式中的操作系统升级方法。
第四方面,本申请实施例提供一种计算机程序产品,当计算机程序产品在电子设备上运行时,使得电子设备执行如上述第一方面及任一实现方式中的操作系统升级方法。
可以理解地,上述各个方面所提供的电子设备、计算机可读存储介质以及计算机程序产品均应用于上文所提供的对应方法,因此,其所能达到的有益效果可参考上文所提供的对应方法中的有益效果,此处不再赘述。
附图说明
图1是操作系统的分区架构示意图;
图2是演示样机和商用机对应的操作系统分区架构示意图;
图3是电子设备进行分区搬移的第一种场景示意图;
图4是电子设备进行分区搬移的第二种场景示意图;
图5是本申请实施例提供的电子设备的硬件结构示意图;
图6是本申请实施例提供的电子设备的软件结构框图;
图7是本申请实施例提供的操作系统升级方法流程示意图;
图8是本申请实施例提供的虚拟A/B升级流程示意图;
图9是本申请实施例提供的一种Merge流程示意图;
图10是本申请实施例提供的Merge流程结束后的操作系统分区架构示意图;
图11是本申请实施例提供的分区搬移方法流程图;
图12是本申请实施例提供的分区搬移方法的场景示意图;
图13是本申请实施例提供的第一分区表和第二分区表对应的分区结构示意图;
图14是本申请实施例提供的子分区表数据结构示意图;
图15是本申请实施例提供的一种目标偏移地址计算方式示意图;
图16是本申请实施例提供的一种操作系统升级装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例的技术方案进行清楚地描述。
在本申请的描述中,除非另有说明,“/”表示“或”的意思,例如,A/B可以表示A或B。本文中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。此外,“至少一个”是指一个或多个,“多个”是指两个或两个以上。“第一”、“第二”等字样并不对数量和执行次序进行限定,并且“第一”、“第二”等字样也并不限定一定不同。
需要说明的是,本申请中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
下面首先对本申请实施例的应用场景进行说明。
操作系统是一种控制和管理电子设备的硬件和软件资源的软件系统,操作系统提供了用户与电子设备之间的交互界面,并负责协调和执行各种任务,以实现电子设备的正常运行和资源管理。
电子设备的操作系统可以是Windows操作系统、Mac OS、Linux操作系统、Unix操作系统、DOS操作系统、荣耀操作系统(Magic OS)、安卓(Android)操作系统、iOS或鸿蒙操作系统(Harmony OS)中的任意一种。本申请实施例仅以安卓操作系统进行示例性说明,各操作系统之间互相参见即可。
其中,电子设备实现无线通信功能时,电子设备的操作系统需要配置对应的制式。制式是指移动通信系统中用于无线信号传输的一种标准或者规范,定义了电子设备与移动通信基础设施之间的通信方式和参数。
不同用途的电子设备可能配置有不同的操作系统制式版本。例如,电子设备用于作为样机展示时,所配置的操作系统制式版本与电子设备用于售卖时,所配置的操作系统制式版本不同。
具体而言,电子设备在销售过程中,销售门店通常会向用户提供具有演示功能的演示样机,以使用户体验电子设备的功能。在用户具有购买意愿后,销售门店通常会向用户售卖商用机,以供用户实际使用。
其中,演示样机的操作系统制式版本通常为演示ROM版本,演示ROM版本是指为产品演示或展示目的而制作的特定制式版本,这种制式版本通常经过特殊定制,以在展示、宣传或者销售过程中展示产品的功能和特性。
演示ROM版本可以包含如下特性:
1、展示功能:演示ROM版本可能更强调产品的主要功能和特性,并提供一些预先设置的演示内容,以便用户能够快速了解产品的优势。
2、界面定制:演示ROM版本的界面可能会进行定制,增强产品的展示效果,以便向用户提供更好的视觉体验。
3、限制或禁用部分功能:演示ROM版本可以对部分功能进行限制或禁用,以防止用户的误操作。
4、演示模式:演示ROM版本可以设置有演示模式,演示模式可以包括自动播放演示内容、循环播放等功能,以适应展示活动的需求。
演示ROM版本还可以具有其他特性,本申请在此不予赘述,这里需要说明的是,演示ROM版本不是提供给用户使用的正式版本,而是为了在特定场景下展示产品而定制的临时版本。
示例的,演示样机的演示ROM版本为vendor-country=demo_cn版本,该制式版本是一个示例版本,demo_cn表示一个虚拟的设备制造商和国家/地区。
商用机的版本通常为商用制式版本,商用制式版本是设备制造商为了满足商业环境下对设备可靠性、安全性和灵活性的需求而提供的制式版本。
商用制式版本可以包含如下特性:
1、可靠性和稳定性:商用制式版本通常经过严格的测试和验证,以确定其在各种工作负载和环境条件下的可靠性和稳定性。
2、安全性:商用制式版本的设计考虑到了安全性。设备制造商会密切关注商用制式版本中潜在的安全漏洞,并通过定期的版本更新来修复这些漏洞。
3、兼容性:商用制式版本通常被开发和优化以与其他商用硬件和软件兼容,这确保了商用机可以与其他电子设备和系统进行无缝集成,并提供稳定的性能。
4、功能和性能优化:商用制式版本可能会引入新的功能、改进现有功能或者提升电子设备的性能。这样,通过对商用制式版本进行固件更新可以使用户获得更好的用户体验、增加电子设备的功能性、以及提高电子设备的性能。
商用制式版本还可以具有其他特性,本申请在此不予赘述,这里需要说明的是,商用版本通常是设备制造商提供给用户使用的正式版本,使用户具有可靠、安全、稳定的使用体验。
示例的,商用机的商用制式版本为vendor-country=all_cn版本,该版本是根据特定的设备制造商和国家/地区提供的特定版本。
在经过一段销售周期后,演示样机通常需要将演示ROM版本升级为商用制式版本,以使演示样机可以作为商用机售卖。
第一种方式:将演示样机返厂刷机,以将演示ROM版本升级为商用制式版本。返厂刷机是指将电子设备发回至设备制造商,由专业的技术人员进行制式更新,这样,技术人员可以使用专门的工具和程序来重新刷写电子设备的制式。这种方式耗费人力成本较多,过程较繁琐。
第二种方式:采用空中下载(Over-The-Air,OTA)技术将演示ROM版本升级为商用制式版本。OTA是指通过电子设备的无线网络接口实现对电子设备进行远程版本更新的技术,以达到远程升级终端系统版本的目的。电子设备通过OTA升级以更改制式版本,能够节约成本。
在介绍OTA升级过程之前,首先对操作系统的分区架构进行说明。
图1是操作系统的分区架构示意图。
如图1中A所示,电子设备的操作系统包括基础分区(Common分区)、系统分区以及用户数据分区(Userdata分区)。其中,Common分区用于保存不参与操作系统升级的系统数据。系统分区用于保存操作系统数据。系统分区包括多个子分区,例如,引导加载程序Bootloader分区、启动Boot分区、供应商引导Vendor_boot分区、设备树叠加层Dtbo分区、可信启动元数据Vbmeta分区、超级Super分区。进一步的,Super分区包括多个子分区,例如,系统System子分区、产品Product子分区、版本Version子分区、预加载Preload子分区。Super分区还可以包括其他子分区,本申请对此不予赘述。Userdata分区用于保存用户的个人数据,例如,用户个人安装的应用程序数据、用户个人保存的图片数据、文档数据、以及视频数据等。
其中,操作系统的制式信息通常存储在Common分区中的一个独立的子分区中,例如,存储在Common分区的设备制造商oeminfo子分区或者非易失性存储nv子分区中。示例的,oeminfo子分区中可以存储demo_cn、all_cn、cmcc_cn等。demo_cn用于指示演示样机制式、all_cn用于指示通用中国制式、cmcc_cn用于指示中国移动中国制式。
上述分区架构是电子设备在物理或者逻辑上的分区,这种分区方式是基于管理存储空间、资源隔离、安全性和性能等目的的划分。
如图1中B所示,基于虚拟A/B分区,电子设备的系统分区还可以进行如下划分。
电子设备的系统分区包括静态分区A(slot_a)、静态分区B(slot_b)和动态分区(Super)。
其中,虚拟A/B分区是一种用于进行A/B测试的技术,用于将用户流量动态地分配到不同的分区。该种分区方式通常是在应用程序或者服务层面上实现的,可以通过代码或者配置以控制用户访问任一分区。这种分区方式通常是临时的,仅在测试期间使用,并且不会对底层系统进行任何物理层面的改变。
对于虚拟A/B分区的静态分区A和静态分区B,这两个分区用于展示或测试不同的变体、功能或者设计元素。静态分区A和静态分区B的结构相互对应,可以将系统分区中的子分区进行划分,示例的,静态分区A对应的子分区通过后缀_a区分,静态分区B对应的子分区通过后缀_b区分,静态分区A可以包括Bootloader_a、Boot_a、Vendor_boot_a、Dtbo_a、Vbmeta_a。静态分区B可以包括:Bootloader_b、Boot_b、Vendor_boot_b、Dtbo_b、Vbmeta_b。
在系统分区具有静态分区A和静态分区B的情况下,电子设备可以虚拟出两套操作系统,例如:操作系统A1和操作系统B1。电子设备启动时,需要基于任意一个操作系统运行。示例的,电子设备基于操作系统A1运行时,电子设备从静态分区A启动,依次加载Common分区、静态分区A以及Super分区。电子设备基于操作系统B1运行时,电子设备从静态分区B启动,依次加载Common分区、静态分区B以及Super分区。
其中,以电子设备采用主引导记录(Master Boot Record,MBR)格式的通用闪存(Universal Flash Storage,UFS)为例,在UFS的MBR(主引导扇区,UFS的第一个扇区,即C/H/S地址的0柱面0磁头1扇区)中,存储有电子设备的启动顺序描述,例如,从静态分区A启动(启动顺序标识为A)或者从静态分区B启动(启动顺序标识为B)。电子设备启动后首先从UFS的MBR中读取电子设备的启动顺序,然后,根据读取到的启动顺序,电子设备可以依次加载Common分区、静态分区A以及Super分区,或者,依次加载Common分区、静态分区B以及Super分区。
电子设备加载Super分区时,同款电子设备的Super分区包含的子区间类型相同,但是,同款电子设备在采用不同制式的情况下,Super分区中各子分区的大小存在差异。具体而言,演示样机中,Version子分区需要用于存放大量的操作演示样片,但是,商用机中,Version子分区无需存放大量的操作演示样片,这样,演示样机和商用机的Version子分区、Preload子分区存在差异。
图2是演示样机和商用机对应的操作系统分区架构示意图。
如图2所示,演示样机和商用机的Version子分区的大小不同,Perload子分区的起始地址不同。其中,起始地址又可称为是存储器中的起始物理地址。
这样,OTA升级过程中,电子设备下载并安装的系统升级包能够用于对操作系统的分区架构进行更改,以使操作系统的分区架构由演示样机的制式更改为商用机的制式。
OTA升级过程涉及以下过程:
1、下载并安装系统升级包:如果有可用的系统升级包,电子设备会对新系统升级包进行下载。系统升级包通常以压缩文件的形式提供,其中包含了需要更新的文件和数据。
2、验证系统升级包:在下载完成后,电子设备会对系统升级包进行验证以确定其完整性,这样,有助于防止下载的文件被损坏或者被篡改。
3、根据系统升级包进行升级更新:如果系统升级包通过验证,电子设备开始根据系统升级包进行升级更新,这一过程可能涉及将新的文件复制到适当的位置。
4、更新完成和重启:电子设备升级更新完成后,会重启以应用新的软件版本。其中,OTA更新完成后,电子设备会进行两次重启,进入恢复Recovery模式,以执行系统更新。
以电子设备初始状态下由静态分区A启动为例,由于电子设备在OTA升级过程中已将静态分区A中的数据写入静态分区B中,并且,已在Userdata分区中创建虚拟动态分区,并在虚拟动态分区中写入Super分区的升级数据(此过程后续进行详述),因此,电子设备第一次进入Recovery模式时,执行合并(Merge)操作,将虚拟动态分区中写入的Super分区的升级数据写入至Super分区内,以及,执行复制(Copy)操作,将写入静态分区B中的数据写入至静态分区A中。这样,电子设备完成更改制式。电子设备更改制式之后,还需要进一步解决各子分区空间利用率较低的问题。
电子设备第二次进入Recovery模式时,执行分区搬移操作。
图3是电子设备进行分区搬移的第一种场景示意图。
如图3所示,以Super分区包括System、Product、Version、Preload等子分区为例,电子设备在分区搬移过程中,可以缩小Version子分区的大小(Size),将Preload子分区整体向上搬移,并扩大Userdata分区的Size。
然而,如果Preload子分区是动态可变分区,例如包括Preload1和Preload2,则会存在数据异常、改制失败的情况。
也就是说,电子设备更改制式的第一种场景仅能在子分区均为独立整体分区时进行分区搬移。
图4是电子设备进行分区搬移的第二种场景示意图。
如图4所示,以Super分区包括System1、Product、Version、Preload、System2等子分区为例,电子设备在分区搬移过程中,可以将Super分区的所有子分区先搬移到Userdata分区,再从Userdata分区将Super分区的所有子分区搬移并整合至Super分区,这样,部分Super中的子分区即使未发生数据更改也需要进行数据的搬移和重新写入,会导致数据的可靠性降低。
也就是说,目前电子设备进行OTA升级的过程中,涉及到分区搬移时,存在一定限制,针对操作系统中的动态分区无法实现按需搬移。
为了解决上述问题,本申请实施例提供了一种操作系统升级方法。
本申请实施例提供的操作系统升级方法可以应用于电子设备。其中,电子设备包括但不限于手机、平板电脑、个人电脑、工作站设备、大屏设备(例如:智慧屏、智能电视等)、可穿戴设备(例如:智能手环、智能手表)掌上游戏机、家用游戏机、虚拟现实设备、增强现实设备、混合现实设备等、车载智能终端等。
图5是本申请实施例提供的电子设备的硬件结构示意图。
如图5所示,电子设备100可以包括处理器110,存储器120,通用串行总线(Universal Serial Bus,USB)接口130,充电管理模块140,电源管理模块141,电池142,天线01,天线02,移动通信模块150,无线通信模块160,音频模块170,传感器模块180,按键190,马达191,摄像头192,显示屏193,以及用户标识模块(Subscriber IdentificationModule,SIM)卡接口194等。
可以理解的是,本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中,电子设备100可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元,例如:处理器110可以包括应用处理器(Application Processor,AP),调制解调处理器,图形处理器(Graphics ProcessingUnit,GPU),图像信号处理器(Image Signal Processor,ISP),控制器,视频编解码器,数字信号处理器(Digital Signal Processor,DSP),基带处理器,和/或神经网络处理器(Neural-Network Processing Unit,NPU)等。其中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。
存储器120可以用于存储计算机可执行程序代码,可执行程序代码包括指令。存储器120可以包括存储程序区和存储数据区。其中,存储程序区可存储操作系统,至少一个功能所需的应用程序(比如声音播放功能,图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据,电话本等)等。此外,存储器120可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件,闪存器件,通用闪存存储器(Universal Flash Storage,UFS)等。处理器110通过运行存储在存储器120的指令,和/或存储在设置于处理器中的存储器的指令,执行电子设备100的各种功能应用以及数据处理。本申请实施例中存储器120中可以包括Cmmon分区120A、系统分区120B以及Userdate分区120C,其中,Common分区120A用于保存不参与操作系统升级的系统数据,系统分区120B用于保存操作系统数据,Userdata分区用于保存用户的个人数据。
USB接口130是符合USB标准规范的接口,具体可以是Mini USB接口,Micro USB接口,USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电,也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机,通过耳机播放音频。该接口还可以用于连接其他电子设备,例如AR设备等。
可以理解的是,本申请实施例示意的各模块间的接口连接关系,只是示意性说明,并不构成对电子设备100的结构限定。在本申请另一些实施例中,电子设备100也可以采用上述实施例中不同的接口连接方式,或多种接口连接方式的组合。
充电管理模块140用于从充电器接收充电输入。
电源管理模块141用于连接电池142,充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入,为处理器110,存储器120,显示屏193,摄像头192,和无线通信模块160等供电。
电子设备100的无线通信功能可以通过天线01,天线02,移动通信模块150,无线通信模块160,调制解调处理器以及基带处理器等实现。
天线01和天线02用于发射和接收电磁波信号。
移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。
调制解调处理器可以包括调制器和解调器。
无线通信模块160可以提供应用在电子设备100上的包括无线局域网(WirelessLocal Area Networks,WLAN)(如无线保真(Wireless Fidelity,Wi-Fi)网络),蓝牙(Bluetooth,BT),全球导航卫星系统(Global Navigation Satellite System,GNSS),调频(Frequency Modulation,FM),近距离无线通信技术(Near Field Communication,NFC),红外技术(Infrared,IR)等无线通信的解决方案。
电子设备100通过GPU,显示屏193,以及应用处理器等实现显示功能。GPU为图像处理的微处理器,连接显示屏193和应用处理器。
显示屏193用于显示图像,视频等。
电子设备100可以通过ISP,摄像头192,视频编解码器,GPU,显示屏193以及应用处理器等实现拍摄功能。
ISP用于处理摄像头192反馈的数据。
摄像头192用于捕获静态图像或视频。
电子设备100可以通过音频模块170,扬声器170A,受话器170B,麦克风170C,耳机接口170D,以及应用处理器等实现音频功能。例如音乐播放,录音等。
触摸传感器180A,也称“触控器件”。触摸传感器180A可以设置于显示屏193,由触摸传感器180A与显示屏193组成触摸屏,也称“触控屏”。触摸传感器180A用于检测作用于其上或附近的触摸操作。
陀螺仪传感器180B可以用于确定电子设备100的运动姿态。
气压传感器180C用于测量气压。
地磁传感器180D包括霍尔传感器。
加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。
距离传感器180F,用于测量距离。
接近光传感器180G用于确定电子设备100附近是否有物体。
指纹传感器180H用于采集指纹。
温度传感器180J用于检测温度。
按键190包括开机键,音量键等。
马达191可以产生振动提示。
SIM卡接口194用于连接SIM卡。
电子设备100的软件系统可以采用分层架构,事件驱动架构,微核架构,微服务架构,或云架构。本申请实施例以分层架构的Android系统为例,示例性说明电子设备100的软件结构。
图6是本申请实施例提供的电子设备的软件结构框图。
分层架构将软件分成若干个层,每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中,将Android系统分为四层,从上至下分别为应用程序层,应用程序框架层,安卓运行时(Android runtime)和系统库,以及内核层。
应用程序层可以包括一系列应用程序包。
如图6所示,应用程序包可以包括电池管理、相机,图库,日历,通话,地图,导航,音乐,视频,短信息,游戏等应用程序。
应用程序框架层为应用程序层的应用程序提供应用程序接口(ApplicationProgramming Interface,API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图6所示,应用程序框架层可以包括窗口管理器,输入管理器InputManager,传感器管理器SensorManager,电话管理器,资源管理器,通知管理器等。
输入管理器可以用来监听用户的输入事件,例如用户手指在电子设备100的显示屏193执行的点击事件、滑动事件等。通过监听输入事件,电子设备100可以判断是否正在使用电子设备。
传感器管理器用于监听电子设备中的各个传感器返回的数据,例如运动传感器数据、接近光传感器数据、温度传感器数据等。利用各个传感器返回的数据,电子设备可以判断其是否有抖动,或者显示屏193是否被遮挡等。
Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。
核心库包含两部分:一部分是java语言需要调用的功能函数,另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理,堆栈管理,线程管理,安全和异常的管理,以及垃圾回收等功能。
系统库可以包括多个功能模块。例如:表面管理器(Surface Manager),媒体库(Media Libraries),三维图形处理库(例如:OpenGL ES),2D图形引擎(例如:SGL)等。
表面管理器用于对显示子系统进行管理,并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频,视频格式回放和录制,以及静态图像文件等。媒体库可以支持多种音视频编码格式,例如:MPEG4,H.264,MP3,AAC,AMR,JPG,PNG等。
三维图形处理库用于实现三维图形绘图,图像渲染,合成,和图层处理等。
2D图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含显示驱动,摄像头驱动,音频驱动,传感器驱动。
可以理解的是,本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中,电子设备可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和硬件组合实现。
本申请实施例以电子设备采用虚拟A/B操作系统进行示例性说明。其中,该操作系统升级方法可以由电子设备上安装的操作系统更新程序执行。其中,操作系统更新程序可以包括在线更新客户端工具(online update client apk,ouc apk)以及升级引擎(UpdateEngine)。ouc apk用于获取操作系统的系统升级包,升级引擎用于驱动执行操作系统的升级。
示例的,本申请实施例的操作系统升级过程以电子设备从静态分区A启动,基于操作系统A1运行时进行说明。
这里需要说明的是,本申请实施例仅以电子设备从静态分区A启动,基于操作系统A1运行进行示例性说明,实际上,电子设备也可以从静态分区B启动,基于操作系统B1运行,本申请实施例对此不予限制。
图7是本申请实施例提供的操作系统升级方法流程示意图。
如图7所示,OTA升级过程包括以下步骤S101-S120。
步骤S101,基于拍包服务器制作系统升级包。
其中,系统升级包可以是全量升级包,全量升级包是指完整的软件升级包或者固件升级包,包含了对应软件或固件的全部更新内容,全量升级包可以将软件或者固件的任一版本直接升级至最新版本,无需中间多次升级。
系统升级包包括指示将电子设备的操作系统由当前运行的系统制式升级至目标制式的数据。目标制式与电子设备中当前运行的系统制式不同。其中,当前运行的系统制式可以为第一制式,例如,第一制式为demo_cn,目标制式可以为第二制式,例如,第二制式为all_cn。
具体而言,系统升级包包括改制小包,改制小包用于指示电子设备的操作系统由第一制式更改为第二制式,该改制小包可以在电子设备进入Recovery模式的情况下被使用。其中,Recovery模式是指电子设备进入一种特殊的状态,以便修复系统故障或者恢复设备到出厂设置,Recovery模式下,用户可以执行一些高级操作来解决问题,例如,清除缓存、重置设备、安装系统更新等。
示例的,系统升级包的数据结构如下:
demochange.tag;
META-INF;
payload.bin;
payload_properties.txt;
SOFTWARE_VER.mbn;
update_base_demochange.zip;
vendor_country.mbn;
VERSION.mbn;
其中,demochange.tag是改制标签,用于指示系统升级包可以将演示样机改制为商用机。META-INF是签名信息,用于对系统升级包进行签名校验。payload.bin包括能够将操作系统由当前的系统制式升级至目标制式的数据。payload_properties.txt是携带文件哈希值FILE_HASH、文件大小FILE_SIZE、元数据哈希值METADATA_HASH等参数的文件,这些参数用于确保文件的完整性和唯一性。SOFTWARE_VER.mbn是一种软件版本文件,用于存储操作系统的制式信息。第二制式可以以vendor_country.mbn文件的形式保存在系统升级包的根目录中。update_base_demochange.zip是改制小包。
示例的,update_base_demochange.zip的数据结构如下:
Ptable;
Image;
super_metadata.img;
META-INF;
OTA_update.tag;
PTABLE_SUPER.mbn;
skipauth_pkg.tag;
vendor_country.mbn;
其中,Ptable是目标制式对应的总分区表。分区表是指电子设备的存储过程中用于管理磁盘分区的数据结构或者表格,用于定义每个分区的起始地址和大小。这样,Ptable可以描述升级到目标制式后,存储器件(ROM)中的分区部署。示例的,Ptable包括Common分区、系统分区和Userdata分区存储空间中的起始地址和结束地址。
示例的,总分区表如下表1所示。
Image可以包括super_metadata.img,该super_metadata.img是第二制式对应的Super分区的子分区表,用于描述电子设备升级到第二制式后,Super分区中各子分区的起始地址和结束地址。子分区表的设置方式可以参阅上述总分区表。
改制小包中的META-INF可以起到与系统升级包中的META-INF同样的校验作用。
第二制式可以以vendor_country.mbn文件的形式保存在改制小包的根目录中。
改制小包中还可以包括userdata.img,metadata.img等空镜像。空镜像(EmptyImage)通常指的是一个不包含任何实际数据的镜像文件,其大小取决于所需的容量或者预留的空间。由于空镜像不包含任何实际数据,因此在使用空镜像之前,需要将所需数据写入或者复制到镜像中。
这里需要说明的是,步骤S101可以在电子设备从静态分区A启动之前执行,也可以在电子设备从静态分区A启动之后执行,本申请实施例对此不予限制。
步骤S102,拍包服务器将系统升级包上传至云端服务器。
步骤S103,电子设备从云端服务器下载并安装系统升级包。
在一种实现方式中,电子设备通过ouc apk下载系统升级包。电子设备可以通过ouc apk定期向云端服务器发起搜包请求,搜包请求包含电子设备当前运行的操作系统的版本号(例如版本1.1),云端服务器根据搜包请求中的操作系统的版本号,检索当前是否存在更新版本号的系统升级包(例如版本1.2)。当存在更新版本的系统升级包时,云端服务器向电子设备反馈系统升级包(例如,版本1.2的全量系统升级包)的下载地址,电子设备根据系统升级包的下载地址进行下载,以获取系统升级包。
在一种实现方式中,云端服务器可以在获取到系统升级包之后,主动向电子设备推送该系统升级包,电子设备根据推送下载系统升级包。
电子设备下载系统升级包后,对系统升级包进行安装。
以电子设备通过ouc apk下载系统升级包为例,电子设备获取系统升级包后,通过ouc apk将系统升级包保存到Userdata分区。
步骤S104,电子设备校验系统升级包。
电子设备完成系统升级包的下载安装后,启动升级引擎,由升级引擎根据系统升级包进行操作系统的升级。
在一种实现方式中,ouc apk获取到系统升级包后,ouc apk设置升级引擎的启动属性,将启动属性设置为true。这样,常驻于电子设备的操作系统后台的服务servicemanger会监控升级引擎的启动属性,当servicemanger检测到升级引擎的启动属性为true时,servicemanger启动升级引擎。
ouc apk通过信使binder通信获取升级引擎的状态,当ouc apk确认升级引擎成功启动时,ouc apk向升级引擎传递升级参数,进而触发升级引擎进入升级流程。其中,升级参数可以用于指示当前的升级操作是文件更新操作还是文件落盘操作。文件更新是在软件或者系统升级时将旧版本的文件替换为新版本的文件的过程,文件更新能够确保新版本的代码和数据能够在电子设备上正常运行。文件落盘是在文件更新完成后,新版本的文件暂存在内存中的过程,为了保证升级的稳定性和数据的完整性,需要将这些文件写入到电子设备的持久存储中,即为文件落盘。文件落盘能够确保数据的安全性和一致性。
升级引擎成功启动后,对系统升级包进行校验。
在一种实现方式中,升级引擎可以校验系统升级包中的META-INF是否合法,确定系统升级包是否为合法的升级包。本申请对校验的具体过程不予赘述。
步骤S105,电子设备根据系统升级包进行升级更新。
升级引擎对系统升级包校验成功后,电子设备可以启动执行虚拟A/B升级流程。其中,虚拟A/B升级流程包括电子设备在运行操作系统A1时,基于系统升级包,启动针对操作系统B1的升级过程。
上述步骤S105的具体升级更新过程可以如图8所示。
图8是本申请实施例提供的虚拟A/B升级流程示意图。
如图8所示,虚拟A/B升级流程包括以下步骤S1051-S1056。
步骤S1051,电子设备从Userdata分区读取已保存的系统升级包,根据系统升级包对静态分区B进行数据写入操作以升级静态分区。
也就是说,电子设备是将静态镜像写入静态分区B。静态镜像是指根据系统升级包创建的一个静态的、不可更改的映像,该映像包含了原始系统或者文件的完整内容和状态,并且通常以只读的形式存在。例如,版本为1.2的系统升级包中包含静态分区的数据(即静态镜像),升级引擎将该静态镜像覆写到静态分区B中。
这里需要说明的是,静态分区升级的数据操作仅针对于静态分区B,并不会影响到当前启动的静态分区A中的数据操作。
步骤S1052,电子设备根据系统升级包在Userdata分区创建虚拟动态分区,在虚拟动态分区写入Super分区的升级数据。
也就是说,电子设备是将系统升级包中的动态镜像写入虚拟动态分区。动态镜像是指根据系统升级包创建的一个可修改、更新和扩展的映像或者图像,与静态镜像不同,动态镜像允许对其内容进行更改,并且可以根据需要进行动态调整和管理。例如,版本为1.2的系统升级包中包含Super分区的数据,电子设备在虚拟动态分区中写入Super分区的数据。
在一种实现方式中,针对Super分区,采用增量升级方式。在升级过程中,Userdata的虚拟动态分区中保存的并不是升级后新版本的Super分区的全部文件,而是旧版本的Super分区中需要升级的数据在升级后的升级结果。即Userdata的虚拟动态分区中保存的是Super分区的更新数据。
以Super分区中的System子分区为例,如果在版本1.1的操作系统中,System子分区中的数据可以分为System1、System2两部分,且从版本1.1升级到版本1.2,System2没有发生变化,则System1可以升级为System3。那么,电子设备在Userdata分区创建虚拟动态分区时,在虚拟动态分区中写入System3的数据。
这里需要说明的是,在虚拟A/B升级方式中,Super分区的增量升级可以是基于快照技术(Snapshot)实现的。
具体而言,Userdata分区中的虚拟动态分区中,采用写时拷贝(Copy-On-Write,COW)文件保存Super分区的升级数据。
在系统升级包中,包含Super分区的升级数据的COW文件是以二进制代码形式压缩保存的,每个COW文件对应于一个Super分区的子分区,COW文件的命名与Super分区的子分区相对应,例如,COW文件命名为system-cow-img.img.0000。
电子设备对系统升级包进行解包,以获取全部的COW文件,并为每个COW文件附加虚拟A/B分区标记。示例的,当电子设备从静态分区A启动时,可以理解为电子设备当前运行操作系统所加载的Super分区为动态分区A,即Super_a。在升级操作系统的过程中,Userdata分区中创建的虚拟动态分区是针对动态分区B,即Super_b,此时,可以为COW文件附加对应的动态分区B的名称标记_b。例如,为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
进一步的,在Userdata分区中创建Update文件夹,将重命名的COW文件保存在Update文件夹下,这样,实现了虚拟动态分区中COW文件的写入。
示例的,Userdata分区的Update文件夹中包含以下COW文件:
system_b-cow-img.img.0000;
product_b-cow-img.img.0000;
Version_b-cow-img.img.0000;
preload_b-cow-img.img.0000。
其中,COW文件中包含COW文件自身的COW文件地图(快照map)以及升级数据。
COW文件地图对应于Super分区的子分区中的文件地图,Super分区的子分区中的文件地图用于描述当前版本的操作系统中Super分区的子分区中的各个文件及对应的保存地址。其中,当前版本的操作系统是指本次升级之前版本的操作系统,例如为版本1.1的操作系统。
COW文件中的升级数据是新版本的Super分区的子分区的更新文件,COW文件中的COW文件地图用于描述新版本的Super分区的子分区的更新文件与当前版本的子分区的文件之间的对应关系,以及更新文件的保存地址。
基于Super分区的子分区中的文件地图和COW文件中的COW文件地图,即可以使用COW文件中的升级数据替换Super分区的子分区中的对应文件,从而实现Super分区的数据升级。
在一种实现方式中,当需要获取Super分区的子分区的文件地图时,电子设备可以基于Snapshot对Super分区的子分区的数据进行快照操作以生成Super分区的子分区的文件地图。
在一种实现方式中,在制作系统升级包的过程中,预先生成Super分区的子分区的文件地图,并将该文件地图存储在COW文件中。
以下以Super分区中的System子分区为例具体介绍Super分区的数据升级过程。
示例的,System子分区根据以下路径保存数据:
/system/app/A0.XXX;
/system/app/A1.XXX;
/system/app/A2.XXX;
/system/B0.XXX;
/system/B1.XXX;
/system/user/C0.XXX;
/system/user/C1.XXX;
/system/user/C2.XXX;
/system/user/C3.XXX。
针对于上述保存路径,System子分区的文件地图可以是:
/system/app/A0.XXX:024010~024013;
/system/app/A1.XXX:024014~024017;
/system/app/A2.XXX:024018~024020;
/system/B0.XXX:024021~024026;
/system/B1.XXX:024027~024028;
/system/user/C0.XXX:024029~024032;
/system/user/C1.XXX:024033~024035;
/system/user/C2.XXX:024036~024040;
/system/user/C3.XXX:024041~024044。
其中,文件名之后的数值是该文件在System子分区的物理保存地址(也被称为块地址)。
示例的,“/system/app/A0.XXX:024010~024013”中,024010~024013是物理保存地址。
如果当前操作系统升级需要更新数据/system/app/A2.XXX,以及,/system/user/C2.XXX,那么,可以视为/system/app/A2.XXX,以及,/system/user/C2.XXX为System子分区中的System1部分,相应的,/system/app/A0.XXX、/system/app/A1.XXX、/system/B0.XXX、/system/B1.XXX、/system/user/C0.XXX、/system/user/C1.XXX以及/system/user/C3.XXX为System子分区中的System2部分。
因此,System子分区的COW文件system_b-cow-img.img.0000包含新版本的/system/app/A2.XXX,以及,/system/user/C2.XXX。这样,新版本的/system/app/A2.XXX,以及,/system/user/C2.XXX可以视为System3,从版本1.1升级到版本1.2,System1可以升级为System3。
当COW文件中的更新数据的大小与其所要更新的原始数据的大小一致,并且,COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时,COW文件的文件地图可以为以下形式:
以COW文件为system_b-cow-img.img.0000为例,其中:
/system/app/A2.XXX:
Map1:起始地址address start:024018;偏移量大小size:2。
其中,Map1是原始Super分区中待更新数据的地址,起始地址024018是相对于System起始地址的偏移量,偏移量大小2是024018~024020地址段的数据。
Map2:起始地址address start:045033;偏移量大小size:2。
其中,Map2是COW文件中存储的更新数据的地址,起始地址045033是相对于COW文件存储的起始地址的偏移量,偏移量大小2是045033~045035地址段的数据。
/system/user/C2.XXX:
Map1:起始地址address start:024036;偏移量大小size:4。
其中,Map1是原始Super分区中待更新数据的地址,起始地址024036是相对于System起始地址的偏移量,偏移量大小4是024036~024040地址段的数据。
Map2:起始地址address start:045036;偏移量大小size:4。
其中,Map2是COW文件中存储的更新数据的地址,起始地址045036是相对于COW文件存储的起始地址的偏移量,偏移量大小2是045036~045040地址段的数据。
当COW文件中的更新数据的大小与其所要更新的原始数据的大小不一致时,COW文件的文件地图可以为以下形式:
以COW文件为system_b-cow-img.img.0000为例,其中:
/system/app/A2.XXX:
Map1.1:起始地址address start:024018;偏移量大小size:2。
其中,Map1是原始Super分区中待更新数据的地址,起始地址024018是相对于System起始地址的偏移量,偏移量大小2是024018~024020地址段的数据。
Map2.1:起始地址address start:045033;偏移量大小size:2。
其中,Map2.1是COW文件中存储的更新数据的地址,起始地址045033是相对于COW文件存储的起始地址的偏移量,偏移量大小2是045033~045035地址段的数据。
Map1.2:起始地址address start:025018;偏移量大小size:1。
其中,Map1.2是COW文件中更新数据超出待更新数据的部分在原始Super分区中的待写入地址,起始地址025018是相对于System起始地址的偏移量,偏移量大小1是025018~025020地址段的数据。
Map2.2:起始地址address start:046033;偏移量大小size:2。
其中,Map2.2是COW文件中存储的用于覆盖Map1.2的更新数据地址,起始地址046033是相对于COW文件存储的起始地址的偏移量,偏移量大小2是046033~046035地址段的数据。
以下实施例中,仅以COW文件中更新数据的大小与其所要更新的原始数据的大小一致,并且,COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时进行示例性说明。
上述实施例中,地址段045033~045035是COW文件中/system/app/A2.XXX在Userdata分区中的物理保存地址,地址段045036~045040是COW文件中/system/user/C2.XXX在Userdata分区中的物理保存地址。这样,如果使用地址045033~045035上的A2.XXX替换掉地址024018~024020上的A2.XXX,并且,使用地址045036~045040上的C2.XXX替换掉地址024036~024040上的C2.XXX,就可以完成Super分区中System子分区的数据升级。
进一步的,将COW文件写入Userdata分区后,需要对Super分区和COW文件进行整体校验,这样,可以校验Super分区和COW文件的有效性,并验证当前版本的Super分区的数据和COW文件的合成结果是否是新版本的Super分区的数据。
示例的,以从版本1.1升级到版本1.2为例,电子设备计算Super分区中不需要升级的数据,以及COW文件中升级数据的合成结果的哈希值,判断该哈希值与版本1.2中Super分区的完整数据的哈希值是否一致,如果一致,则COW文件有效,如果不一致,则COW文件无效,操作系统升级失败,升级引擎的进程中断并报错。其中,Super分区的完整数据的哈希值是存储于系统升级包中的。
其中,校验Super分区和COW文件的有效性时,需要基于Snapshot合并Super分区和COW文件,这里需要说明的是,基于Snapshot对Super分区和COW文件的合并并非是物理意义上的合并,而是将System子分区的整体文件地图与COW文件的COW文件地图进行合并,生成新版本的System子分区数据的文件地图。
示例的,System子分区的文件地图为:
/system/app/A0.XXX:024010~024013;
/system/app/A1.XXX:024014~024017;
/system/app/A2.XXX:024018~024020;
/system/B0.XXX:024021~024026;
/system/B1.XXX:024027~024028;
/system/user/C0.XXX:024029~024032;
/system/user/C1.XXX:024033~024035;
/system/user/C2.XXX:024036~024040;
/system/user/C3.XXX:024041~024044。
COW文件地图为:
/system/app/A2.XXX:
Map1:address start:024018;size:2(即024018~024020地址段的数据);
Map2:address start:045033;size:2(即045033~045035地址段的数据)。
/system/user/C2.XXX:
Map1:address start:024036;size:4(即024036~024040地址段的数据);
Map2:address start:045036;size:4(即045036~045040地址段的数据)。
将上述System子分区的文件地图和COW文件地图合并,则得到新版本的System子分区的文件地图:
/system/app/A0.XXX:024010~024013(指向Super分区中/system/app下的A0.XXX);
/system/app/A1.XXX:024014~024017(指向Super分区中/system/app下的A1.XXX);
/system/app/A2.XXX:045033~045035;
(指向Userdata分区中/Update/system_b-cow-img.img.0000中的A2.XXX);
/system/B0.XXX:024021~024026(指向Super分区中/system/app下的B0.XXX);
/system/B1.XXX:024027~024028(指向Super分区中/system/app下的B1.XXX);
/system/user/C0.XXX:024029~024032(指向Super分区中/system/app下的C0.XXX);
/system/user/C1.XXX:024033~024035(指向Super分区中/system/app下的C1.XXX);
/system/user/C2.XXX:045036~045040;
(指向Userdata分区中/Update/system_b-cow-img.img.0000中的C2.XXX);
/system/user/C3.XXX:024041~024044(指向Super分区中/system/app下的C3.XXX)。
可见,在新版本的System子分区的文件地图中,/system/app/A2.XXX的保存地址并不是指向存储器上的Super分区中system/app下的A2.XXX,而是指向Userdata分区中/Update/system_b-cow-img.img.0000中的A2.XXX。/system/user/C2.XXX的保存地址并不是指向存储器上的Super分区中system/app下的C2.XXX,而是指向Userdata分区中/Update/system_b-cow-img.img.0000中的C2.XXX。这样,在校验过程中,根据上述合成方式,获取Super分区中所有子分区的新版本的文件地图,并将所有子分区的新版本的文件地图组合生成Super分区的新版本的文件系统。其中,如果Userdata分区中并未写入某个子分区对应的COW文件,那么可以直接以该子分区的文件地图作为新版本的文件地图。
电子设备获取到Super分区的新版本的文件系统后,基于该文件系统读取数据,得到该文件系统包含的所有文件并计算哈希值。
当确定COW文件有效时,电子设备将Common分区的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”更改为“未落盘(wait for merge)”。落盘状态信息用于表示当前是否存在需要落盘到Super分区的COW文件。其中,落盘状态信息包含针对Super的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘”时,表示Super分区的所有子分区均不需要进行落盘操作,当整体标识为“未落盘”时,表示Super分区的一个或者多个子分区需要进行落盘操作。当子分区标识为“已落盘”时,表示该子分区不需要进行落盘操作,当子分区标识为“未落盘”时,表示该子分区需要进行落盘操作。
这样,虚拟动态分区写入的Super分区的升级数据能够用于进行有效升级。
这里需要说明的是,Super分区升级的数据操作是在Userdata分区中的虚拟动态分区上完成的,并不会影响当前挂载的Super分区,因此,整个操作系统生升级的过程中,用户可以正常使用电子设备。针对Super分区,仅需要在进行升级时才会在Userdata分区上创建虚拟动态分区,有效提高了数据存储空间利用率。
在一种实现方式中,步骤S1052之后,电子设备还可以进行卡槽切换操作。其中,电子设备的卡槽切换操作不会立即改变当前运行的操作系统,也就是说,电子设备不会立即将运行的操作系统A1切换为操作系统B1,而是在电子设备下一次启动时,加载操作系统B1所对应的系统数据,以操作系统B1运行。
这里需要说明的是,电子设备可以在步骤S1052之后执行步骤S1053,也可以在进行卡槽切换操作之后执行步骤S1053,本申请实施例对此不予限制。
步骤S1053,电子设备通过升级引擎检测系统升级包中的改制小包。
在一种实现方式中,升级引擎从系统升级包中检测出改制小包的包名,例如:包名为update_base_demochange.zip。这样,可以确定升级引擎检测到改制小包。
在一种实现方式中,升级引擎从系统升级包中检测到改制标签,例如,改制标签为:demochange.tag。这样,可以确定系统升级包中存在改制小包。
步骤S1054,电子设备通过升级引擎从系统升级包中读取第二制式。
在一种实现方式中,系统升级包中包括第二制式文件,该第二制式文件例如为:vendor_country.mbn。电子设备解析系统升级包后,可以从vendor_country.mbn文件中读取第二制式all_cn。
步骤S1055,电子设备通过升级引擎将第二制式写入第一临时文件中。
示例的,第一临时文件为oeminfo_vc_tmp文件。oeminfo_vc_tmp文件是Common分区中oeminfo子分区中的临时文件,占据oeminfo子分区中的临时存储空间。oeminfo_vc_tmp与oeminfo子分区中的oeminfo_vc文件不同。这是由于oeminfo_vc文件中包括操作系统升级前的制式信息(例如,版本1.1的制式信息)。因此,oeminfo_vc_tmp文件与oeminfo_vc文件,在oeminfo子分区中实际占据的物理地址不同,并且,oeminfo_vc文件所对应的存储地址,是电子设备加载制式信息的地址。这样,电子设备加载系统数据时,会加载oeminfo_vc文件而不会加载oeminfo_vc_tmp。
这里需要说明的是,步骤S1055仅对临时存放在系统升级包中的第二制式进行示例性说明,第二制式也可以写入能够被读取的其他临时存储区,本申请实施例对此不予限制。
步骤S1056,电子设备通过升级引擎将改制小包解压到第一更新目录。
示例的,第一更新目录为cache/update目录。cache/update目录是Common分区中Cache子分区下的目录,Cache子分区是电子设备在Recovery模式下能够访问的存储分区。由于改制小包中包括Ptable和super_metadata.img,因此,电子设备将改制小包解压到cache/update目录之后,该目录下包括Ptable和super_metadata.img。
具体而言,电子设备将super_metadata.img存储到/cache/recovery路径,电子设备将指示改制升级数据的命令写入/cache/recovery/command文件中。
这里需要说明的是,在电子设备基于操作系统A1运行的过程中,操作系统A1依次启动Common分区、静态分区A以及Super分区后,由于Super分区中已经预存储了第一制式对应的super_metadata.img,即第一分区表,则电子设备可以在加载Super分区后对第一分区表进行读取,而上述步骤中,电子设备将改制小包中的super_metadata.img,即第二分区表,存储到/cache/recovery路径后,可以实现对第二分区表的读取。
步骤S106,电子设备第一次重启,进入Recovery模式。
电子设备退出当前的操作系统,切断电子设备的电源,并再次开启电子设备的电源。
这里需要说明的是,电子设备完成步骤S101-步骤S105之后,无需立即重启,可以根据用户意愿选择重启时机,这样,操作系统的升级过程并不会对用户的正常操作产生影响,从而能够大大提高用户体验。
步骤S107,电子设备依次加载Common分区和静态分区B。
其中,电子设备的Common分区中包括MBR,该MBR中配置有启动顺序标识。电子设备启动操作系统时,可以从MBR中读取启动顺序标识,并根据启动顺序标识,确定所需加载的静态分区,这样,电子设备可以确定启动操作系统A1或者启动操作系统B1。
在一种实现方式中,电子设备执行卡槽切换操作后,电子设备可以改写MBR的启动顺序标识,例如,将启动顺序标识由A改写为B。
这样,电子设备上电后,如果读取到启动顺序标识为A,则电子设备从静态分区A启动,并在启动过程中加载静态分区A,如果读取到启动顺序标识为B,则电子设备从静态分区B启动,并在启动过程中加载静态分区B。
具体实现中,电子设备首先加载Common分区,在加载Common分区的过程中,电子设备读取到Common分区中的启动标记,当启动顺序标识为B时,电子设备在加载Common分区后加载静态分区B,由静态分区B启动。这是由于本申请实施例初始状态下是从静态分区A启动,基于操作系统A1运行进行示例性说明的。
步骤S108,电子设备加载Super分区以及Userdata分区的虚拟动态分区。
在一种实现方式中,电子设备读取元数据分区中的落盘状态信息,基于落盘状态信息确定是否需要从Userdata分区的指定路径中检索COW文件,并采用Snapshot合并加载Super分区和COW文件。
其中,电子设备并不加载Super分区以及Userdata分区中的全部COW文件,而是根据操作系统运行需求确定需要加载的文件,基于Super分区的子分区的新版本的文件地图进行文件加载。
示例的,操作系统运行需求为加载System子分区下目录user(/system/user)中的所有数据,则电子设备读取元数据分区中的落盘状态信息,当落盘状态信息中System子分区的子分区标识为“未落盘”时,电子设备在Userdata分区中/Update下搜索COW文件。
当电子设备在/Update下搜索到COW文件system_b-cow-img.img.0000后,基于Snapshot,电子设备根据system_b-cow-img.img.0000中的COW文件的文件地图生成System子分区的新版本的文件地图,并按照System子分区的新版本的文件地图中/system/user下所有文件的保存地址进行数据加载。
例如,针对于System子分区的新版本的文件地图:
/system/user/C0.XXX:024029~024032;
/system/user/C1.XXX:024033~024035;
/system/user/C2.XXX:045036~045040;
/system/user/C3.XXX:024041~024044。
电子设备可以加载地址024029~024032处的C0.XXX、地址024033~024035处的C1.XXX、地址045036~045040处的C2.XXX以及地址024041~024044处的C3.XXX。
在一种实现方式中,当电子设备加载System子分区下目录user(/system/user)中的所有数据时,当落盘状态信息中System子分区的子分区标识为“已落盘”时,电子设备不会在Userdata分区中/Update下搜索COW文件,而是直接加载System子分区下目录user(/system/user)中的所有数据。
在一种实现方式中,当电子设备加载System子分区下目录user(/system/user)中的所有数据时,当落盘状态信息中System子分区的子分区标识为“未落盘”时,如果电子设备在Userdata分区中/Update下未搜索到对应于System子分区的COW文件,则说明升级过程中电子设备存在数据写入错误的情况,例如:COW文件写入错误或者落盘状态信息写入错误,此时,电子设备回滚系统并报错。
在一种实现方式中,在电子设备加载文件之前,电子设备还需要对加载文件进行校验。不同于步骤S1052中的校验过程,本步骤中,不对Super分区和COW文件进行整体验证,仅对需要加载的文件进行验证。
示例的,电子设备可以基于dm-verity对加载文件进行校验。其中,dm-verity是设备映射器(Device mapper,Dm)的一个目标(Target),是一个虚拟块设备,用于文件系统的校验。这样,如果电子设备校验成功,则加载文件,如果电子设备校验失败,则重启电子设备,回滚系统或者尝试再次加载文件。
步骤S109,电子设备通过升级引擎触发合并Merge流程。
在一种实现方式中,电子设备第一次重启后,新系统生效,也就是说,更新后的操作系统B1生效时,启动Merge流程。
图9是本申请实施例提供的一种Merge流程示意图。
如图9所示,Merge流程包括步骤S1091-步骤S1092。
步骤S1091,电子设备第一次重启后,进入用户交互界面。
步骤S1092,电子设备在后台将虚拟动态分区的数据合并到Super分区。
也就是说,电子设备在后台将虚拟动态分区的数据落盘到Super分区。其中,落盘操作是指在操作系统的升级过程中,电子设备将Userdata上虚拟动态分区中保存的Super分区的COW文件写入到Super分区中,使得Super分区的文件完成数据升级,以便电子设备在下次启动时不需要加载Super分区和虚拟动态分区,只需要加载Super分区就可以完成电子设备启动。
在一种实现方式中,电子设备启动成功后进行开机广播,开机广播后开启升级引擎对应的进程。升级引擎对应的进程读取Common分区的元数据分区中的落盘状态信息,如果落盘状态信息为“已落盘”,则电子设备进入正常运行模式。如果落盘状态信息为“未落盘”,升级引擎对应的进程将Userdata分区中的COW文件落盘到Super分区中。具体而言,升级引擎对应的进程将Userdata分区中的COW文件中的升级数据写入到Super中的对应地址上,使得Super分区中的全部数据均为升级后的新版本的数据。
示例的,基于System子分区的文件地图中的/system/app/A2.XXX:024018~024020以及COW文件地图中的/system/app/A2.XXX:045033~045035,将地址045033~045035上的数据写入到地址024018~024020。基于System子分区的文件地图中的/system/user/C2.XXX:024036~024040以及COW文件地图中的/system/user/C2.XXX:045036~045040,将地址045036~045040上的数据写入到地址024036~024040上。
进一步的,升级引擎对应的进程删除Userdata分区中的COW文件,将存储空间归还给Userdata分区,并且,将Common分区中的元数据分区中的落盘状态信息由“未落盘”更改为“已落盘”。
Merge流程结束后,Super分区的Version子分区内数据所占空间变小,同时,Preload预装子分区的位置不变,此时,Version子分区和Preload子分区之间会形成空闲Free空间,该Free空间是无法实际利用的存储空间。
图10是本申请实施例提供的Merge流程结束后的操作系统分区架构示意图。
如图10所示,Merge流程结束后,Version子分区的起始地址不变,结束地址变小,这样,Version子分区所占的物理存储空间缩小。示例的,Version子分区的大小由8GB缩小为2GB。
Preload子分区的起始地址和结束地址不变,这样,Version子分区和Preload子分区之间,出现闲置的物理存储区域,即Free空间。
其中,Merge流程之前,Super分区中的子分区为第一制式下的第三子分区,Merge流程结束后,Super分区中的子分区更新为第二制式下的第一子分区。
步骤S110,电子设备通过升级引擎将操作系统B1的静态分区B复制到操作系统A1的静态分区A中。
这里需要说明的是,本申请实施例包括但不限于通过步骤S110实现对静态分区A的更新,升级引擎还可以利用系统升级包更新静态分区A中的数据,本申请实施例对静态分区A的更新方式不做具体限定。
步骤S111,电子设备通过升级引擎将将第一临时文件中的第二制式写入第一存储子分区中的第一存储文件。
在一种实现方式中,第一临时文件为oeminfo_vc_tmp文件,第一存储子分区为oeminfo子分区,第一存储文件为oeminfo_vc文件。由于oeminfo_vc_tmp中写入的第二制式是从系统升级包中读取到的,例如为:all_cn,该第二制式与电子设备在操作系统升级前具有的第一制式demo_cn不同,也就是说,oeminfo_vc_tmp中的第二制式与oeminfo_vc文件中的第一制式不同,这样,将oeminfo_vc_tmp中的第二制式写入oeminfo_vc文件后,可以覆盖oeminfo_vc文件原有的第一制式,从而实现制式的变更,将demo_cn变更为all_cn。
由于oeminfo子分区属于Common分区,因此,在操作系统由Common分区启动的过程中,从oeminfo子分区的oeminfo_vc文件中读取第二制式all_cn,即实现了对电子设备的制式的更改。
电子设备完成制式更改后,还需要进一步改善存储空间利用率较低的问题。
步骤S112,电子设备通过升级引擎检测到第一更新目录中包括改制小包时,在第一路径文件中写入指示改制升级的数据。
在一种实现方式中,第一更新目录为cache/update,第一路径文件为cache/recovery/command文件。示例的,指示改制升级的数据可以是制式改制小包存储路径的信息,例如,在改制小包存储于cache/update目录的情况下,指示改制小包存储的路径信息可以为“update_package=/cache/update/update_base_demochange.zip”。这样,电子设备进入Recovery模式后,可以依据该存储路径查找到改制小包。
这里需要说明的是,电子设备进入Recovery模式后,还可以通过其他的方式获取到改制小包,例如,电子设备可以在检测到cache/update目录中包括改制小包时,将改制小包作为指示改制升级的数据。具体而言,电子设备检测到cache/update目录中包括改制小包后,将改制小包移动至cache/recovery目录下。
步骤S113,电子设备第二次重启,进入Recovery模式。
电子设备通过升级引擎触发重启,并在指示进入Recovery模式后,启动Recovery进程。
步骤S114,电子设备通过Recovery进程校验系统升级包的完整性。
其中,该步骤的具体实现方式可以参考相关技术中验证升级包的完整性的实现方式,本申请实施例对此不予赘述。
步骤S115,电子设备的Recovery进程依据第一路径文件,确定当前为改制升级场景时,配置全局变量。
在一种实现方式中,第一路径文件为cache/recovery/command文件,全局变量为vcdemo,电子设备的Recovery进程可以解析cache/recovery/目录中的command文件,得到存储路径,此时,Recovery进程依据该存储路径,访问对应的存储空间,在该存储空间中存在数据包的情况下,如果确定数据包的包名与预定义的改制小包包名相同,确定当前为改制升级场景,或者,如果确定数据包中存在指示改制标识的情况下,也可以确定当前为改制升级场景。
在一种实现方式中,电子设备确定当前为改制升级场景时,通过Recovery进程在指定的存储位置中写入全局变量vcdemo。其中,指定的存储位置可以是Recovery进程可访问的缓存。
这里需要说明的是,电子设备可以通过配置全局变量vcdemo指示本次升级为改制升级,也可以通过其他方式指示改制升级,例如,电子设备主动查询cache/update目录中是否有改制小包,以在查询到改制小包后提醒Recovery进程执行改制升级的后续流程。
步骤S116,电子设备识别到全局变量时,通过Recovery进程执行分区搬移。
图11是本申请实施例提供的分区搬移方法流程图。
图12是本申请实施例提供的分区搬移方法的场景示意图。如图11和图12所示,该步骤S116包括步骤S1161-S1168。
步骤S1161,电子设备获取第一分区表。
图13是本申请实施例提供的第一分区表和第二分区表对应的分区结构示意图。
如图13所示,电子设备通过Recovery进程从Super分区中获取第一分区表。
在一种实现方式中,Super分区中具有Super头信息,Super头信息可以存储于Super分区的顶部1M的存储空间中,Super分区包括第一分区表,即当前操作系统中Super分区对应的super_metadata.img。
这里需要说明的是,电子设备在第一制式下由静态分区A启动时,在依次加载Common分区、静态分区A以及Super分区后,即可以从Super分区中读取到第一分区表,且前述步骤S109的Merge流程中,还涉及对第一分区表的更新,因此,步骤S1161中,Recovery进程获取到的第一分区表实际上是更新后的第一分区表,该更新后的第一分区表对应的是如图13中A所示的第一子分区的分区结构。
步骤S1162,电子设备获取第二分区表。
电子设备通过Recovery进程从改制小包中获取第二分区表。改制小包中包括第二分区表,第二分区表是改制小包中存储的super_metadata.img的数据结构。第二分区表对应的是如图13中B所示的第二子分区的分区结构。多个第二子分区是对多个第一子分区的至少一部分进行搬移后得到的子分区。
这里需要说明的是,第一分区表和第二分区表实际上都是Super分区中的子分区表,而不是对应于操作系统分区架构的总分区表。
需要注意的是,步骤S1161可以和步骤S1162同时执行,也可以在步骤S1162之前或者之后执行,本申请实施例对此不予限制。
步骤S1163,基于第一分区表,电子设备确定Super分区中的多个第一子分区的起始物理地址。
步骤S1164,基于第二分区表,电子设备确定Super分区中的多个第二子分区的起始物理地址。
需要注意的是,步骤S1163可以和步骤S1164同时执行,也可以在步骤S1163之前或者之后执行,本申请实施例对此不予限制。
图14是本申请实施例提供的子分区表数据结构示意图。
如图14所示,子分区表可以指示在内存地址0x0-0x100000之间存放的数据。其中,内存地址0x0-0x1000之间可以包括预留Reserved分区,预留分区可以具有4千字节的存储容量,内存地址0x1000-0x2000之间可以包括初始几何Primary Geometry分区,PrimaryGeometry分区可以仅使用52字节的存储容量,用于指示存储设备的容量大小、分区数量和每个分区的大小、每个分区在存储设备上的起始地址,以及每个分区中数据的文件系统类型。内存地址0x2000-0x3000之间可以包括备份Backup Geometry分区,可以作为PrimaryGeometry分区的备份分区,存储与Primary Geometry分区中相同的内容,并同样使用52字节的存储容量。内存地址0x3000-0x13000之间可以包括初始数据Primary Metadata分区,Primary Metadata分区可以具有64千字节的存储容量,用于存储静态分区A中的数据。内存地址0x13000-0x23000之间可以包括备份数据Backup Metadata分区,备份数据分区可以具有64千字节的存储容量,用于存储静态分区B中的数据。内存地址0x23000之后可以包括其他Backup Metadata分区,每个Backup Metadata分区的内存地址依次可以为0x23000-0x33000、0x33000-0x43000、0x43000-0x53000等。每个Backup Metadata分区都可以具有64千字节的存储容量,用于进行静态分区A或者静态分区B或者其他数据的备份。
由于上述各分区内有部分分区存放内容相同,因此,以当前操作系统为A1时的Primary Metadata分区进行示例,介绍该分区中的数据存储结构。
其中,Primary Metadata分区中的数据是以Lp元数据(Linux PartitionMetadata,LpMetadata)结构进行数据存放的。该Lp元数据结构中,具有Lp元数据分区表(LpMetadataTableDescriptor partitions)(简称为partitions)结构,该partitions结构用于表示子分区表中的分区数量。
这里需要说明的是,本申请实施例中涉及的简称的数据结构仅为了便于表述,并非实际数据结构的相应缩写形式。
示例的,当前操作系统中Super分区中包括System子分区、Product子分区、Version子分区、Preload子分区等4个子分区,则partitions结构用于描述第一分区表中具有4个子分区。
进一步的,该partition结构中具有对每个子分区的描述。
以partitions结构中对System子分区的描述为例,该partitions结构中,具有索引(first_extents_index)(简称为extents)结构,该extents结构中,具有连续物理块数量(Number of extents in the partition)(简称为Number)结构,该Number结构用于表示System子分区中连续物理块的数量。
如图13中A所示,由于Super分区中System子分区是一个独立完整的子分区,则System子分区中具有连续物理块,且连续物理块的数量为1。
相应的,partitions结构中还包括对其他子分区的描述,每个子分区的描述都具有对应的Number结构。因此,由于Product子分区、Version子分区均是独立完整的子分区,则Product子分区和Version子分区对应的连续物理块的数量均为1,而由于Preload子分区具有Preload1和Preload2,则Preload子分区对应的连续物理块的数量为2。
进一步的,该Lp元数据结构中,还具有Lp元数据连续物理块(LpMetadataTableDescriptor extents)(简称为Lp extents)结构。其中,extents结构能够对Lp extents结构进行反向索引,以根据extents结构确定Lp extents结构对应的具体数据信息。
以System子分区对应的Lp extents结构为例,该Lp extents结构包括24字节,具体包括:
unit64_t num_sectors;system,0x6ac000×512;
上述数量结构用于表示System子分区的连续物理块的逻辑分区大小。
该Lp extents结构还包括:
unit64_t target_data;
上述目标数据结构用于表示System子分区的连续物理块的起始物理地址,示例的,System子分区的起始物理地址可以为0x800×512。
这样,电子设备可以得到System子分区的连续物理块的起始物理地址以及逻辑分区大小。
相应的,电子设备可以得到其他子分区中每个连续物理块的起始物理地址以及逻辑分区大小。示例的,由于Preload子分区具有Preload1和Preload2,那么基于extents结构中的数量,可以反向索引到Lp extents结构中的两个连续物理块分别对应的起始物理地址以及逻辑分区大小,即Preload1的起始物理地址和逻辑分区大小,以及Preload2的起始物理地址和逻辑分区大小。
也就是说,步骤S1163的具体实现过程如下:
电子设备调用Recovery进程,基于第一分区表对应的第一Lp元数据(LpMetadata)结构中的第一Lp元数据分区表(LpMetadataTableDescriptor partitions)结构,遍历第一分区表中的多个第一子分区,确定每个第一子分区的索引(first_extent_index)结构。
电子设备基于每个第一子分区的索引(first_extent_index)结构中的第一连续物理块数量(Number of extents in the partition)结构,确定第一分区表中的每个第一子分区的连续物理块的第一数量。
电子设备基于第一数量反向索引至第一分区表中的第一Lp元数据连续物理块(LpMetadataTableDescriptor extents)结构。
电子设备基于第一Lp元数据连续物理块中的第一目标数据(target_data)结构,得到每个第一子分区的连续物理块对应的起始物理的地址。
在一种实现方式中,还包括:
电子设备基于第一Lp元数据连续物理块中的第一数量(num_sectors)结构确定每个子分区中的连续物理块对应的连续物理块大小。
相应的,步骤S1164的具体实现过程如下:
电子设备调用Recovery进程,基于第二分区表对应的第二Lp元数据(LpMetadata)结构中的第二Lp元数据分区表(LpMetadataTableDescriptor partitions)结构,遍历第二分区表中的多个第二子分区,得到每个第二子分区的索引(first_extent_index)结构。
电子设备基于每个第二子分区的索引(first_extent_index)结构中的第二连续物理块数量(Number of extents in the partition)结构,确定第二分区表中的每个第二子分区的连续物理块的第二数量。
电子设备基于第二数量反向索引至第二分区表中的第二Lp元数据连续物理块(LpMetadataTableDescriptor extents)结构。
电子设备基于第二Lp元数据连续物理块中的第二目标数据(target_data)结构,得到每个第一子分区的连续物理块对应的起始物理的地址。
在一种实现方式中,还包括:
电子设备基于第二Lp元数据连续物理块中的第二数量(num_sectors)结构确定每个子分区中的连续物理块对应的连续物理块大小。步骤S1165,电子设备确定多个第一子分区中的第一目标子分区。
其中,第一目标子分区是多个第一子分区中与多个第二子分区名称相同,但是起始物理地址不同的第一个子分区。
进一步如图13所示,示例的,电子设备可以依次得到第一分区表中每个子分区的起始物理地址,以及得到第二分区表中每个子分区的起始物理地址,其中,电子设备可以首先获取到第一分区表中System子分区的起始物理地址为0x800×512,以及,获取到第二分区表中System子分区的起始物理地址为0x800×512,则System子分区的起始物理地址相同,System子分区不是第一目标子分区。
进一步的,电子设备在第一分区表中可以得到Preload2的起始物理地址,以及得到第二分区表中Product子分区的起始物理地址,此时,由于Preload2与Product子分区的名称不同,因此无法确定第一目标子分区。
进一步的,电子设备在第一分区表中可以得到Product子分区的起始物理地址,此时,由于电子设备已经在第二分区表中得到Product子分区的起始物理地址,且Product子分区在第一分区表和第二分区表中的起始物理地址不同,因此,Product子分区是多个第一子分区中与多个第二子分区名称相同,但是起始物理地址不同的第一个子分区,这样,可以将Product子分区确定为第一目标子分区。
也就是说,步骤S1165的具体实现过程如下:
电子设备获取第一分区表中每个第一子分区的连续物理块对应的第一目标数据结构。
电子设备获取第二分区表中每个子分区的连续物理块对应的第二目标数据结构。
电子设备将每个第一子分区的连续物理块对应的第一目标数据结构和每个第二子分区的连续物理块对应的第二目标数据结构依次比对。
将第一次获取到多个第一子分区中与多个第二子分区中名称相同,但是第一目标数据结构与第二目标数据结构不同的子分区确定为第一目标子分区。
这里需要说明的是,上述实施例中,电子设备可以同时对第一子分区中的连续物理块对应的第一目标数据结构和第二子分区中的连续物理块对应的第二目标数据结构进行比对,例如,获取第一子分区中System子分区的第一目标数据结构,以及获取第二子分区中的System子分区的第二目标数据结构进行比对。也可以先获取第一子分区中的所有连续物理块对应的第一目标数据结构,例如,依次获取到System子分区、Preload2物理块、Product子分区、Version子分区、以及Preload1物理块,再获取第二子分区的第二目标数据进行比对,例如,先获取到System子分区的第二目标数据结构,确定System不是第一目标子分区后,再获取到Product子分区的第二目标数据结构,此时,可以确定Product子分区为第一目标子分区。本申请实施例对获取第一目标数据和第二目标数据结构的具体方式不进行限制。
步骤S1166,电子设备将目标区域中的子分区搬移至Userdata分区。其中,Userdata分区的起始物理地址是Super分区的终止物理地址。目标区域中的子分区是多个第一子分区中位于第一目标子分区至Userdata分区之间的子分区。
具体而言,电子设备依次获取第一目标子分区与Userdata分区之间的所有子分区的连续物理块对应的第一target_data结构,基于第一target_data结构将目标区域中的子分区由第一目标子分区开始,依次搬移至Userdata分区的尾部。
进一步如图13所示,第一目标子分区为Product子分区时,目标区域中的子分区包括:Product子分区、Version子分区以及Preload子分区,其中,Preload子分区对应于Preload1和Preload2两个连续物理块,因此,尽管Preload2连续物理块并不在Product子分区与Userdata分区对应的起始物理地址之间,也需要对Preload2连续物理块进行搬移。
进一步如图12所示,电子设备依次根据Product子分区对应的第一target_data结构将Product子分区搬移至Userdata分区尾部,根据Version子分区对应的第一target_data结构将Version子分区子分区搬移到Userdata分区尾部,根据Preload1对应的第一target_data结构将Preload1搬移到Userdata分区尾部,以及根据Preload2对应的第一target_data结构将Preload2搬移到Userdata分区尾部,此时,Preload1和Preload2生成Preload子分区。
在一种实现方式中,搬移过程中或者搬移完成后,电子设备需要确定目标区域中的子分区的总分区大小。总分区大小是根据每个第一子分区的连续物理块大小之和确定的。其中,基于每个第一子分区的连续物理块对应的第一target_data结构和第一num_sectors结构确定每个第一子分区的连续物理块大小之和。
示例的,Product子分区、Version子分区以及Preload子分区搬移到Userdata分区尾部后,Product子分区、Version子分区以及Preload子分区具有总分区大小Total_size。
步骤S1167,电子设备将目标区域中的子分区覆盖写入Super分区中的目标偏移地址。
图15是本申请实施例提供的一种目标偏移地址计算方式示意图。
如图15所示,目标偏移地址是电子设备获取到第一制式下,Super分区的预设分区大小后,基于预设分区大小与总分区大小的差值确定的。
为便于说明计算方式,该实施例中示例数值与前述实施例不具有衔接关系。
示例的,System子分区的起始物理地址为0x100000,System子分区的Size为4GB;Preload2的起始物理地址为0x100000+4GB,Preload2的Size为2GB;Product子分区的起始物理地址为0x100000+6GB,Product子分区的Size为2GB;Version子分区的起始物理地址为0x100000+8GB,Version子分区的Size为8GB,Preload1的起始物理地址为0x100000+16GB,Preload1的Size为2GB,Userdata分区的起始物理地址为0x100000+18GB。
因此,Total_size为Product子分区、Version子分区以及Preload子分区的Size之和,为14GB。
Super分区的预设分区大小Super_size可以是System子分区的起始物理地址至Userdata分区的起始物理地址之间的大小,示例的,为0x100000至0x100000+18GB之间的大小,等于18GB,Super_size可以是从Ptable中获取到的,也可以是根据第一分区表获取到的,本申请实施例对此不予限制。
这样,电子设备可以确定目标偏移地址dstOffset,dstOffset可以根据Super_size减去Total_size的差值确定,示例的,该差值为4GB,因此,dstOffset可以是0x100000+4GB。
电子设备将Userdata分区尾部的Product子分区、Version子分区以及Preload子分区进行拷贝(Copy),拷贝至Super分区的dstOffset中,则实现了分区的搬移。
这里需要说明的是,由于Version子分区的Size在改制后是缩小的,Version子分区之后具有一段空闲空间,那么,实际搬移的Version子分区是缩小后的子分区,且未对该空闲空间进行操作,因此,Preload1的起始物理地址并未改变,Total_size将该空闲空间占据的存储空间大小计算在内。
步骤S1168,电子设备将Userdata分区的起始物理地址上移。
完成分区搬移后,Super分区会产生空闲空间,此时,电子设备将Userdata分区的起始物理地址上移,可以使Userdata分区具有更多区域以供用户支配。
步骤S117,电子设备完成分区搬移后,对已搬移分区进行校验。
该步骤S117包括步骤S1171-S1172。
步骤S1171,电子设备获取Super分区中每个子分区对应的第三target_data结构。
步骤S1172,电子设备根据第二分区表中每个子分区对应的第二target_data结构校验第三target_data结构。
在每个子分区对应的第二target_data结构与对应的第三target_data结构相同的情况下,电子设备将Super分区中中的第一分区表修改为第二分区表,即执行步骤S118。
在任一子分区对应的第二target_data结构与对应的第三target_data结构不相同的情况下,电子设备显示报错信息。
示例的,电子设备完成分区搬移后,System子分区对应的第三target_data结构可以是0x100000,Product子分区对应的第三target_data结构可以是0x100000+2GB,Version子分区对应的第三target_data结构可以是0x100000+4GB,Preload子分区对应的第三target_data结构可以是0x100000+8GB。
如果第二分区表中System子分区对应的第二target_data结构是0x100000,Product子分区对应的第二target_data结构是0x100000+2GB,Version子分区对应的第二target_data结构是0x100000+4GB,Preload子分区对应的第二target_data结构是0x100000+8GB,那么,表明分区搬移成功,反之,任一第二target_data结构与第三target_data结构无法对应,表明分区搬移失败,电子设备显示报错信息。
步骤S118,电子设备在Super分区中将第一分区表修改为第二分区表。
具体而言,电子设备通过Recovery进程将第二分区表更新到Super头信息中,覆盖第一分区表。
步骤S119,电子设备通过Recovery进程确定第一存储子分区中的制式信息已变更。
在一种实现方式中,第一存储子分区为oeminfo子分区。电子设备通过Recovery进程检测oeminfo子分区中的制式信息是否变更,也就是说,电子设备确定当前制式不再是demo_cn。在确定制式信息已经变更的情况下,电子设备执行步骤S120。在确定制式信息未变更的情况下,则重新执行上述制式信息变更流程。例如,重新执行步骤S1055。
步骤S120,电子设备格式化Userdata分区并重启。
在一种实现方式中,Userdata分区需要重置,电子设备格式化Userdata分区并重启后完成整个操作系统升级流程。
本申请实施例提供的操作系统升级方法,能够通过对第一分区表和第二分区表进行解析和比对,得到第一分区表和第二分区表中的差异子分区,从而仅对差异子分区进行搬移,使未更改的分区保持原状,实现了分区的按需搬移,提高分区搬移的可靠性和通用性。
在一种实现方式中,以对运行操作系统A1的电子设备进行操作系统升级为例,上述操作系统升级方法的实现过程,包括以下步骤S201-S220。
步骤S201,Recovery进程获取第一分区表和第二分区表。
其中,步骤S201的具体实现细节可以参阅步骤S1161,本申请实施例对此不予赘述。
步骤S202,Recovery进程解析第一分区表对应的第一Lp元数据结构,以及,第二分区表对应的第二Lp元数据结构。
步骤S203,Recovery进程根据第一Lp元数据结构中的第一Lp元数据分区表结构遍历第一分区表中的每个子分区,得到每个子分区中的第一索引结构,并根据第一索引结构中的第一连续物理块数量结构确定第一分区表中每个子分区对应的连续物理块的第一数量;以及,根据第二Lp元数据结构中的第二元数据分区表结构遍历第二分区表中的每个子分区,得到每个子分区中的第二索引结构,并根据第二索引结构中的第二连续物理块数量结构确定第二分区表中每个子分区对应的连续物理块的第二数量。
步骤S204,Recovery进程基于第一数量在第一分区表中反向索引至第一Lp元数据连续物理块结构,基于第一Lp元数据连续物理块结构中的第一目标数据结构确定每个子分区中的连续物理块对应的第一起始物理地址,并基于第一Lp元数据连续物理块结构中的第一数量结构确定每个子分区中的连续物理块对应的第一分区大小;以及,基于第二数量在第二分区表中反向索引至第二Lp元数据连续物理块结构,基于第二Lp元数据连续物理块结构中的第二目标数据结构确定每个子分区中的连续物理块对应的第二起始物理地址。
其中,步骤S202-S204的具体细节可以参阅步骤S1162,本申请实施例对此不予赘述。
步骤S205,Recovery进程依次获取第一分区表中每个子分区对应的第一目标数据结构,以及,依次获取第二分区表中每个子分区对应的第二目标数据结构。
步骤S206,Recovery进程将第一分区表中每个子分区对应的第一目标数据结构与第二分区表中每个子分区对应的第二目标数据结构依次比对,确定第一差异子分区。
其中,步骤S205-S206的具体细节可以参阅步骤S1163,本申请实施例对此不予赘述。
步骤S207,Recovery进程依次获取第一差异子分区与Userdata分区之间的所有子分区的连续物理块对应的第一目标数据结构,根据第一目标数据结构将第一目标子分区由第一差异子分区开始依次搬移至Userdata分区的尾部。
其中,步骤S207的具体细节可以参阅步骤S1164,本申请实施例对此不予赘述。
步骤S208,Recovery进程将第一目标子分区通过覆盖的方式写入Super分区中的目标偏移地址。其中,步骤S208的具体细节可以参阅步骤S1165,本申请实施例对此不予赘述。
步骤S209,Recovery进程将Userdata分区的起始物理地址上移。
其中,步骤S209的具体细节可以参阅步骤S1166,本申请实施例对此不予赘述。
步骤S210,Recovery进程完成分区搬移后,获取Super分区中每个子分区对应的第三目标数据结构,根据第二分区表中每个子分区对应的第二目标数据结构校验第三目标数据结构。
其中,步骤S210的具体细节可以参阅步骤S117,本申请实施例对此不予赘述。
步骤S211,Recovery进程在Super分区中将第一分区表修改为第二分区表。
其中,步骤S211的具体细节可以参阅步骤S118,本申请实施例对此不予赘述。
步骤S212,Recovery进程确定oeminfo子分区中的制式信息已变更。
其中,步骤S212的具体细节可以参阅步骤S119,本申请实施例对此不予赘述。
步骤S213,Recovery进程格式化Userdata分区并重启。
其中,步骤S213的具体细节可以参阅步骤S120,本申请实施例对此不予赘述。
图16是本申请实施例提供的一种操作系统升级装置的结构示意图。
如图16所示,在一个实施例中,电子设备可以通过图16所示的硬件装置实现相应的功能。该装置可以包括:触控屏701、存储器702、处理器703和通信模块704。上述各器件可以通过一个或多个通信总线705连接。上述各器件可以通过一个或多个通信总线705连接。触控屏701可以包括显示面板7011和触摸传感器7012,其中,显示面板7011用于显示图像,触摸传感器7012可以将检测到的触摸操作传递给应用处理器,以确定触摸事件类型,通过显示面板7011提供与触摸操作相关的视觉输出。处理器703可以包括一个或多个处理单元,例如:处理器703可以包括应用处理器,调制解调处理器,图形处理器,图像信号处理器,控制器,视频编解码器,数字信号处理器,基带处理器,和/或神经网络处理器等。其中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。存储器702与处理器703耦合,用于存储各种软件程序和/或计算机指令,存储器702可包括易失性存储器和/或非易失性存储器。当处理器执行计算机指令时,电子设备可执行上述方法实施例的各个功能或者步骤。
当存储器702中的软件程序和/或多组指令被处理器703执行时,使得电子设备实现如下方法步骤:获取第一分区表和第二分区表,第一分区表用于存储第一制式下Super分区中的每个子分区对应的第一数据结构,第二分区表用于存储第二制式下Super分区中的每个子分区对应的第二数据结构,Super分区位于电子设备的存储器中;解析第一分区表和第二分区表,从第一数据结构中得到每个子分区对应的第一起始物理地址,以及,从第二数据结构中得到每个子分区对应的第二起始物理地址;确定第一差异子分区,第一差异子分区是第一分区表和第二分区表中,名称相同,但对应的第一起始物理地址和第二起始物理地址不同的第一个子分区;将第一差异子分区与Userdata分区之间的所有子分区确定为第一目标子分区,将第一目标子分区由第一差异子分区开始,依次搬移至Userdata分区的尾部,其中,Userdata分区的起始物理地址是Super分区的终止物理地址;将第一目标子分区通过覆盖的方式写入Super分区中的目标偏移地址;在Super分区中将第一分区表修改为第二分区表。
本申请还提供了一种电子设备,包括:处理器、存储器和触摸屏;存储器存储有程序指令,当程序指令被处理器执行时,使得电子设备执行上述实施例中任一实现方式中的操作系统升级方法。
本申请实施例还提供一种芯片系统,该芯片系统包括至少一个处理器和至少一个接口电路。处理器和接口电路可通过线路互联。例如,接口电路可用于从其它装置(例如电子设备的存储器)接收信号。又例如,接口电路可用于向其它装置发送信号。示例性的,接口电路可读取存储器中存储的指令,并将该指令发送给处理器。当指令被处理器执行时,可使得电子设备执行上述实施例中的各个步骤。当然,该芯片系统还可以包含其他分立器件,本申请实施例对此不作具体限定。
本申请实施例还提供一种计算机可读存储介质,该计算机可读存储介质包括计算机指令,当计算机指令在上述电子设备上运行时,使得该电子设备执行上述方法实施例中执行的各个功能或者步骤。
本申请实施例还提供一种计算机程序产品,当计算机程序产品在计算机上运行时,使得计算机执行上述方法实施例中执行的各个功能或者步骤。
通过以上实施方式的描述,所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是一个物理单元或多个物理单元,即可以位于一个地方,或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该软件产品存储在一个存储介质中,包括若干指令用以使得一个设备(可以是单片机,芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上内容,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何在本申请揭露的技术范围内的变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。

Claims (19)

1.一种操作系统升级方法,其特征在于,应用于电子设备,所述方法包括:
获取第一分区表;
获取第二分区表;
基于所述第一分区表,确定所述电子设备的内存中的动态分区中的多个第一子分区的起始物理地址;
基于所述第二分区表,确定所述动态分区中的多个第二子分区的起始物理地址,所述多个第二子分区是对所述多个第一子分区的至少一部分进行搬移后得到的子分区;
确定所述多个第一子分区中的第一目标子分区,所述第一目标子分区是所述多个第一子分区中与所述多个第二子分区名称相同,但是起始物理地址不同的第一个子分区;
将目标区域中的子分区搬移至所述内存中的用户数据分区,所述目标区域中的子分区是所述多个第一子分区中位于所述第一目标子分区至所述用户数据分区之间的子分区;
将所述目标区域中的子分区覆盖写入所述动态分区中的目标偏移地址;
将所述动态分区中的所述第一分区表修改为所述第二分区表。
2.根据权利要求1所述的方法,其特征在于,所述获取第一分区表包括:
在第一制式下,依次加载所述内存中的基础分区、所述内存中的第一静态分区以及所述动态分区;
加载所述动态分区之后,获取所述第一分区表;
所述获取第二分区表包括:
获取系统升级包;
基于所述系统升级包,获取所述第二分区表。
3.根据权利要求2所述的方法,其特征在于,所述获取系统升级包之后,还包括:
基于所述系统升级包完成系统升级后,第一次进入恢复模式,调用恢复进程将所述电子设备的操作系统由所述第一制式更改为第二制式;
其中,当所述电子设备的操作系统由所述第一制式更改为所述第二制式时,将所述动态分区在所述第一制式下的多个第三子分区更新为所述第二制式下的所述多个第一子分区。
4.根据权利要求3所述的方法,其特征在于,
所述第一制式包括演示机制式,所述第二制式包括商用机制式。
5.根据权利要求3所述的方法,其特征在于,所述基于所述第一分区表,确定所述电子设备的内存中的动态分区中的多个第一子分区的起始物理地址,包括:
第二次进入所述恢复模式,调用所述恢复进程遍历所述第一分区表中的所述多个第一子分区,确定每个第一子分区的连续物理块对应的第一数量;
基于所述第一数量反向索引至所述第一分区表中的第一数据结构,从所述第一数据结构中确定所述每个第一子分区的连续物理块对应的起始物理地址。
6.根据权利要求5所述的方法,其特征在于,所述基于所述第二分区表,确定所述动态分区中的多个第二子分区的起始物理地址,包括:
第二次进入所述恢复模式,调用所述恢复进程遍历所述第二分区表中的所述多个第二子分区,确定每个第二子分区的连续物理块对应的第二数量;
基于所述第二数量反向索引至所述第二分区表中的第二数据结构,从所述第二数据结构中确定所述每个第二子分区的连续物理块对应的起始物理地址。
7.根据权利要求6所述的方法,其特征在于,所述第二次进入所述恢复模式,调用所述恢复进程遍历所述第一分区表中的所述多个第一子分区,确定每个第一子分区的连续物理块对应的第一数量,包括:
基于所述第一分区表对应的第一Lp元数据结构中的第一Lp元数据分区表结构,遍历所述第一分区表中的所述多个第一子分区,确定每个第一子分区的索引结构;
基于所述每个第一子分区的索引结构中的第一连续物理块数量结构,确定所述第一分区表中的所述每个第一子分区的连续物理块对应的第一数量。
8.根据权利要求7所述的方法,其特征在于,所述第二次进入所述恢复模式,调用所述恢复进程遍历所述第二分区表中的所述多个第二子分区,确定每个第二子分区的连续物理块对应的第二数量,包括:
基于所述第二分区表对应的第二Lp元数据结构中的第二Lp元数据分区表结构,遍历所述第二分区表中的所述多个第二子分区,确定每个第二子分区的索引结构;
基于所述每个第二子分区的索引结构中的第二连续物理块数量结构,确定所述第二分区表中的所述每个第二子分区的连续物理块对应的第二数量。
9.根据权利要求8所述的方法,其特征在于,所述第一数据结构是所述第一分区表中的第一Lp元数据连续物理块结构;
所述基于所述第一数量反向索引至所述第一分区表中的第一数据结构,从所述第一数据结构中得到所述每个第一子分区的连续物理块对应的起始物理地址,包括:基于所述第一数量反向索引至所述第一分区表中的所述第一Lp元数据连续物理块结构;
基于所述第一Lp元数据连续物理块结构中的第一目标数据结构,确定所述每个第一子分区的连续物理块对应的起始物理地址。
10.根据权利要求9所述的方法,其特征在于,所述第二数据结构是所述第二分区表中的第二Lp元数据连续物理块结构;
所述基于所述第二数量反向索引至所述第二分区表中的第二数据结构,从所述第二数据结构中得到所述每个第二子分区的连续物理块对应的起始物理地址,包括:
基于所述第二数量反向索引至所述第二分区表中的所述第二Lp元数据连续物理块结构;
基于所述第二Lp元数据连续物理块结构中的第二目标数据结构,确定所述每个第二子分区的连续物理块对应的起始物理地址。
11.根据权利要求10所述的方法,其特征在于,所述确定所述多个第一子分区中的第一目标子分区,包括:
获取所述第一分区表中所述每个第一子分区的连续物理块对应的所述第一目标数据结构;
获取所述第二分区表中所述每个第二子分区的连续物理块对应的所述第二目标数据结构;
将所述每个第一子分区的连续物理块对应的所述第一目标数据结构和所述每个第二子分区的连续物理块对应的所述第二目标数据结构依次比对;
将第一次获取到的所述多个第一子分区中与所述多个第二子分区中名称相同,但是所述第一目标数据结构与所述第二目标数据结构不同的子分区确定为所述第一目标子分区。
12.根据权利要求11所述的方法,其特征在于,所述将目标区域中的子分区搬移至所述内存中的用户数据分区,包括:
基于所述目标区域中的子分区对应的所述第一目标数据结构,将所述目标区域中的子分区由所述第一目标子分区开始,依次搬移至所述用户数据分区的尾部。
13.根据权利要求9所述的方法,其特征在于,所述第二次进入所述恢复模式,调用所述恢复进程遍历所述第一分区表中的所述多个第一子分区,确定每个第一子分区的连续物理块对应的第一数量之后,还包括:
基于所述第一数量反向索引至所述第一分区表中的第一数据结构,从所述第一数据结构中确定所述每个第一子分区的连续物理块对应的连续物理块大小。
14.根据权利要求13所述的方法,其特征在于,所述基于所述第一数量反向索引至所述第一分区表中的第一数据结构,从所述第一数据结构中确定所述每个第一子分区的连续物理块对应的连续物理块大小,包括:
基于所述第一数量反向索引至所述第一分区表中的所述第一Lp元数据连续物理块结构;
基于所述第一Lp元数据连续物理块结构中的第一数量结构,确定所述每个第一子分区的连续物理块对应的连续物理块大小。
15.根据权利要求14所述的方法,其特征在于,所述目标偏移地址的获取方式包括:
获取所述第一制式下,所述动态分区的预设分区大小;
获取所述目标区域的子分区的总分区大小;
将所述预设分区大小与所述总分区大小的差值确定为所述目标偏移地址;
其中,所述总分区大小是根据每个第一子分区的连续物理块大小之和确定的,其中,基于每个第一子分区的连续物理块对应的所述第一目标数据结构和对应的所述第一数量结构,确定所述每个第一子分区的连续物理块大小之和。
16.根据权利要求11所述的方法,其特征在于,所述将所述目标区域中的子分区覆盖写入所述动态分区中的目标偏移地址之后,还包括:
获取所述动态分区中的每个第二子分区对应的第三目标数据结构;
根据所述第二分区表中所述每个第二子分区对应的所述第二目标数据结构校验所述第三目标数据结构;
在所述每个第二子分区对应的所述第二目标数据结构与对应的所述第三目标数据结构相同的情况下,将所述动态分区中的所述第一分区表修改为所述第二分区表;
在任一所述第二子分区对应的所述第二目标数据结构与对应的所述第三目标数据结构不同的情况下,显示报错信息。
17.一种电子设备,其特征在于,包括:处理器和存储器,所述存储器存储有程序指令,当所述程序指令被所述处理器执行时,使得所述电子设备执行权利要求1-16中任一项所述的方法。
18.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有指令,当所述指令在电子设备上运行时,使得电子设备执行权利要求1-16中任一项所述的方法。
19.一种计算机程序产品,其特征在于,当所述计算机程序产品在电子设备上运行时,使得电子设备执行权利要求1-16中任一项所述的方法。
CN202311071800.8A 2023-08-23 2023-08-23 一种操作系统升级方法及电子设备 Pending CN117707566A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311071800.8A CN117707566A (zh) 2023-08-23 2023-08-23 一种操作系统升级方法及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311071800.8A CN117707566A (zh) 2023-08-23 2023-08-23 一种操作系统升级方法及电子设备

Publications (1)

Publication Number Publication Date
CN117707566A true CN117707566A (zh) 2024-03-15

Family

ID=90153999

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311071800.8A Pending CN117707566A (zh) 2023-08-23 2023-08-23 一种操作系统升级方法及电子设备

Country Status (1)

Country Link
CN (1) CN117707566A (zh)

Similar Documents

Publication Publication Date Title
US20120265792A1 (en) Data storage access device
US20080141018A1 (en) Game apparatus and information processing apparatus
WO2022262744A1 (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
CN113805914B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
US20120221609A1 (en) Data Storage System and Method
CN114265616B (zh) 操作系统的升级方法、电子设备及存储介质
EP4202649A1 (en) Method for upgrading operating system, device, storage medium, and computer program product
WO2011003463A1 (en) Data storage system and method
WO2022262754A1 (zh) 操作系统数据更新方法、设备、存储介质及程序产品
JP5250645B2 (ja) 情報処理装置
KR20200090010A (ko) 펌웨어 업데이트 방법, 이를 위한 전자 장치 및 저장 매체
CN113821221B (zh) 安装操作系统的方法、设备及存储介质
CN115543368A (zh) 一种操作系统升级方法及电子设备
WO2023169035A1 (zh) 操作系统的升级方法、电子设备及存储介质
CN113868156B (zh) 系统升级掉电保护方法、电子设备及存储介质
CN116400938B (zh) 操作系统的升级方法、设备及存储介质
US9367550B2 (en) Information processing apparatus and file system
EP4242835A1 (en) Operating system upgrade method, electronic device, storage medium, and chip system
CN117707566A (zh) 一种操作系统升级方法及电子设备
EP3992783A1 (en) Patch releasing method, server and terminal device
CN115562695B (zh) 操作系统升级方法、电子设备、存储介质及芯片系统
CN116028100B (zh) 软件版本升级方法和电子设备
CN116450169A (zh) 操作系统升级方法、电子设备、存储介质及芯片系统
CN116069370A (zh) 冷补丁的升级方法、设备、存储介质及计算机程序产品
CN117785221A (zh) 一种应用程序安装方法及电子设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination