CN116149714A - 操作系统数据配置方法、设备、存储介质及程序产品 - Google Patents
操作系统数据配置方法、设备、存储介质及程序产品 Download PDFInfo
- Publication number
- CN116149714A CN116149714A CN202310144834.9A CN202310144834A CN116149714A CN 116149714 A CN116149714 A CN 116149714A CN 202310144834 A CN202310144834 A CN 202310144834A CN 116149714 A CN116149714 A CN 116149714A
- Authority
- CN
- China
- Prior art keywords
- partition
- data
- static
- upgrade
- dynamic
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/658—Incremental updates; Differential updates
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请实施例提供的一种操作系统数据配置方法、设备、存储介质及计算机程序产品,方法应用于电子设备,电子设备启动后加载基础分区、第一静态分区以及动态分区的数据以启动第一操作系统;第一操作系统启动之后,方法包括:将第二静态分区的状态标记设置为不可启动;升级第二静态分区的数据;当第二静态分区的数据升级失败时,将第二静态分区的状态标记设置为可启动,并且,将第一静态分区的数据同步到第二静态分区。根据本申请实施例的方法,可以大大提高操作系统启动的成功率,确保设备稳定运行,提高用户的设备使用体验。
Description
技术领域
本申请涉及计算机技术领域,具体地涉及一种操作系统数据配置方法、设备、存储介质及计算机程序产品。
背景技术
在现有技术的应用场景中,用户终端需要安装操作系统才可以被用户使用。例如,手机上需要安装手机操作系统(例如:IOS系统、安卓系统)才可以被用户使用。
在终端设备安装操作系统后,当操作系统出现版本升级时,需要升级终端设备上所安装的操作系统。在升级过程中,存在升级错误的情况。例如,读取升级数据时读取操作失败;又例如,写入升级数据时写入操作失败。因此,需要一种针对操作系统升级失败的操作系统数据配置方法。
发明内容
有鉴于此,本申请提供一种操作系统数据配置方法、设备、存储介质及计算机程序产品,以利于解决现有技术中操作系统升级失败时静态分区不可用的问题。
第一方面,本申请实施例提供了一种操作系统数据配置方法,应用于电子设备,所述电子设备包括处理器以及存储器,所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区;所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以启动第一操作系统;所述第一操作系统启动之后,所述方法包括:
获取操作系统升级包;
将所述第二静态分区的状态标记设置为不可启动;
根据所述操作系统升级包升级所述第二静态分区的数据;
当所述第二静态分区的数据升级失败时,将所述第二静态分区的状态标记设置为可启动,并且,将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中,所述方法还包括:
当所述第二静态分区的数据升级失败时,输出升级失败提示信息。
在第一方面的一种实现方式中,当所述第二静态分区的数据升级失败时,后台执行所述将所述第二静态分区的状态标记设置为可启动的步骤,以及,后台执行所述将所述第一静态分区的数据同步到所述第二静态分区的步骤。
在第一方面的一种实现方式中,所述操作系统升级包包含用于升级所述动态分区的动态分区升级数据,所述方法还包括:
当所述第二静态分区的数据升级成功时,根据所述操作系统升级包在所述用户数据分区中写入动态分区升级数据;
当所述动态分区升级数据写入失败时,将所述第二静态分区的状态标记设置为可启动,并且,将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中,所述方法还包括:
当所述动态分区升级数据写入失败时,输出升级失败提示信息。
在第一方面的一种实现方式中,当所述动态分区升级数据写入失败时,后台执行所述将所述第二静态分区的状态标记设置为可启动的步骤。
在第一方面的一种实现方式中,所述方法还包括:
当所述动态分区升级数据写入失败时,删除所述用户数据分区中已写入的动态分区升级数据。
在第一方面的一种实现方式中,所述操作系统升级包还包含用于更新所述动态分区的分区配置的第一分区配置信息,所述方法还包括:
当所述第二静态分区的数据升级成功时,将所述动态分区的元数据中的分区信息备份为分区备份信息;
分区信息备份完成后,根据所述第一分区配置信息刷新所述动态分区的元数据中的分区信息;
当所述动态分区升级数据写入失败时,使用所述分区备份信息恢复所述动态分区的元数据中的分区信息。
在第一方面的一种实现方式中,所述方法还包括:
当所述动态分区升级数据写入成功时,将所述第二静态分区的状态标记设置为可启动,修改所述电子设备的启动顺序为从所述第二静态分区启动;
重启所述电子设备,确认所述电子设备的启动顺序为从所述第二静态分区启动;
加载所述基础分区以及所述静态分区的数据;
加载所述动态分区的数据以及所述动态分区升级数据,启动所述第二操作系统;
将所述动态分区升级数据落盘到所述动态分区。
在第一方面的一种实现方式中,所述方法还包括:
当所述第二静态分区的数据升级成功时,将所述第二静态分区的状态标记设置为可启动,修改所述电子设备的启动顺序为从所述第二静态分区启动。
第二方面,本申请实施例提供了一种电子设备,所述电子设备包括处理器以及存储器,所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区,所述处理器用于执行所述存储器上存储的软件代码,以使得所述电子设备启动后加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统;
并且,在所述第一操作系统运行之后,使得所述电子设备执行如第一方面所述的方法流程。
第三方面,本申请实施例提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机程序,当其在计算机上运行时,使得计算机执行如第一方面所述的方法。
第四方面,本申请实施例提供了一种计算机程序产品,所述计算机程序产品包括计算机程序,当其在计算机上运行时,使得计算机执行如第一方面所述的方法。
根据本申请实施例所提出的上述技术方案,至少可以实现下述技术效果:
根据本申请实施例的方法,可以在第二静态分区升级失败时确保设备后续可以从第二静态分区顺利启动操作系统,从而大大提高操作系统启动的成功率,确保设备稳定运行,提高用户的设备使用体验。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
图1所示为根据本申请一实施例的数据存储结构示意图;
图2a所示为根据本申请一实施例的操作系统升级的流程图;
图2b为根据本申请一实施例的手机运行界面示意图;
图2c为根据本申请一实施例的手机运行界面示意图;
图3a所示为根据本申请一实施例的操作系统数据调配流程图;
图3b所示为根据本申请一实施例进行操作系统升级的部分流程图;
图4所示为一应用场景下设备出厂前进行系统烧录的烧录系统框架结构示意图;
图5所示为根据本申请一实施例的操作系统数据调配流程图。
具体实施方式
为了更好的理解本申请的技术方案,下面结合附图对本申请实施例进行详细描述。
应当明确,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。
应当理解,本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,甲和/或乙,可以表示:单独存在甲,同时存在甲和乙,单独存在乙这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
在实际应用场景中,针对操作系统升级失败,一种可行的解决方案是回滚操作系统,将操作系统恢复为升级前状态,在顺利启动操作系统后重新进行操作系统升级操作。
以采用虚拟A/B升级方式的安卓系统为例,图1所示为根据本申请一实施例的数据存储结构示意图。如图4所示,安卓系统数据存储区包含基础分区(Common)、静态分区(A)(第一静态分区)、静态分区(B)(第二静态分区)、动态分区(Super)、用户数据分区(Userdata)。
用户数据分区(Userdata)用于保存用户的个人数据,例如,用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础部分中保存的数据为不参与操作系统升级的系统数据。静态分区(A)与静态分区(B)的结构相互对应,子分区命名通过后缀_a以及_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。动态分区(Super)包含多个子分区(System、system_ext、vendor、product、Cust、Odm)。
在设备启动时,从一个静态分区启动。例如,设备从静态分区(A)启动:依次加载基础分区(Common)、静态分区(A)以及动态分区(Super);设备从静态分区(B)启动:依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
以采用主引导记录(Master Boot Record,MBR)格式的通用闪存(UniversalFlash Storage,UFS)为例。在UFS的MBR(主引导扇区,UFS的第一个扇区,即C/H/S地址的0柱面0磁头1扇区)中,保存有设备启动顺序描述,例如,从静态分区(A)启动(启动顺序标志为A)或从静态分区(B)启动(启动顺序标志为A)。设备启动后首先从UFS的MBR中读取设备启动顺序。
图2a所示为针对图1所示实施例的操作系统数据存储结构进行操作系统升级的流程图,当设备当前是从静态分区(A)启动时,设备按照如图2a所示的流程实现操作系统的升级。
S200,设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super),从静态分区(A)启动。
S210,设备获取操作系统升级安装包。
示例的,在一种可行的实现方案中,设备定期向搜包服务器发起搜包请求,搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1);搜包服务器根据搜包请求中的操作系统版本号,检索当前是否存在更新版本号的操作系统安装包(例如版本1.2);当存在更新版本号的操作系统安装包时,搜包服务器向设备反馈操作系统升级安装包(例如,由版本1.1升级到版本1.2的系统增量升级安装包)的下载地址;设备根据操作系统升级安装包的下载地址下载操作系统升级安装包。
S220,设备根据操作系统升级安装包针对静态分区(B)进行数据写入操作以升级静态分区。
S230,设备根据操作系统升级安装包在用户数据分区(Userdata)创建虚拟动态分区,在虚拟动态分区写入动态分区(Super)的升级数据。例如,在操作系统升级安装包中包含动态分区升级数据,例如,版本1.2的动态分区的数据,设备在虚拟动态分区中写入版本1.2的动态分区(Super)的数据。
进一步的,在虚拟A/B升级方案中,针对动态分区(Super),采用增量升级方式。在升级过程中,用户数据分区(Userdata)的虚拟动态分区中保存的并不是升级后新版本的动态分区(Super)的全部文件,而是旧版本的动态分区(Super)中需要升级的数据在升级后的升级结果。即,用户数据分区(Userdata)的虚拟动态分区中保存的是动态分区的更新数据。
以system子分区为例,假设在版本1.1中,system子分区中的数据可以分为system1、system2两部分。从版本1.1升级到版本1.2,数据system2没有发生变化,数据syetem1被升级为system3。那么,在S230中,设备在用户数据分区(Userdata)创建虚拟动态分区,在虚拟动态分区中写入数据system3。
例如,版本1.1升级到版本1.2的系统增量升级安装包包含版本1.1升级到版本1.2的动态分区(Super)更新数据,该动态分区(Super)更新数据包含数据system3。
进一步的,在虚拟A/B升级方案中,基于快照技术(snapshot)实现动态分区(Super)的增量升级。具体的,用户数据分区(Userdata)的虚拟动态分区中,采用写时拷贝(Copy-On-Write,COW)文件保存动态分区(Super)的升级数据。
具体的,用户数据分区(Userdata)中保存的动态分区(Super)的升级数据包含多个COW文件,每个COW文件对应一个动态分区(Super)的子分区,COW文件的命名与其所针对的动态分区(Super)子分区相对应。
在S210所获取的操作系统升级安装包中,动态分区(Super)的升级数据的COW文件以二进制代码形式压缩保存。在操作系统升级安装包中,每个COW文件根据其所针对的动态分区(Super)子分区所命名。例如,针对system子分区的COW文件被命名为system-cow-img.img.0000。
在S230中,设备解包操作系统升级安装包以获取所有的COW文件,为每个COW文件附加A/B分区标记。具体的,当设备当前从静态分区(A)启动时,可以理解为设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时,用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。因此,为COW文件附加对应动态分区(B)的名称标记_b。例如,为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
进一步的,在S230中,在用户数据分区(Userdata)中创建Update文件夹,将重命名的COW文件保存到Update文件夹下。例如,在一应用场景中,在向用户数据分区(Userdata)写入COW文件后,用户数据分区(Userdata)的Update文件夹中包含下述文件:
system_b-cow-img.img.0000;
system_ext_b-cow-img.img.0000;
vendor_b-cow-img.img.0000;
product_b-cow-img.img.0000;
cust_b-cow-img.img.0000;
odm_b-cow-img.img.0000。
具体的,COW文件中包含COW文件自身的COW文件地图(快照map)以及升级数据。COW文件地图(快照)与COW文件所针对的动态分区(Super)的子分区的文件地图相对应。动态分区(Super)的子分区的文件地图用于描述当前版本的操作系统(本次升级之前的版本,例如,版本1.1)动态分区(Super)的子分区中的所有文件以及各个文件的保存地址。
COW文件中的升级数据为相较于当前版本的子分区数据,新版本的子分区数据中被更新的文件;COW文件自身的COW文件地图则用于描述被更新的文件与当前版本的子分区中的文件间的对应关系以及被更新的文件的保存地址。
基于动态分区(Super)的子分区的文件地图以及COW文件中的COW文件地图,就可以使用COW文件中的升级数据替换动态分区(Super)的子分区中的对应文件,从而实现动态分区(Super)数据的升级。具体的,在需要获取动态分区(Super)的子分区的文件地图时,可以基于snapshot对动态分区(Super)的子分区的数据进行快照操作以生成动态分区(Super)的子分区的文件地图。也可以在制作操作系统升级安装包时,预先生成动态分区(Super)的子分区的文件地图,将该文件地图加入到COW文件中。
以system子分区为例,假设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/app/A0.XXX:024010~024013中的024010~024013)为该文件在动态分区(Super)的system子分区的物理保存地址(块地址)。
假设当前操作系统升级需要更新数据/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。升级目标是使用system3更新掉system1。
COW文件(system_b-cow-img.img.0000)自身的COW文件地图可以为:
/system/app/A2.XXX:
Map1(原super分区中待更新数据的地址):起始地址address start:024018(相对于system起始地址的偏移量);偏移量大小size:2(即024018~024020地址段的数据)
Map2(cow文件中存储的更新数据的地址):起始地址address start:045033(相对于cow文件存储的起始地址的偏移量);偏移量大小size:2(即045033~045035地址段的数据);
/system/user/C2.XXX:
Map1(原super分区中待更新数据的地址):起始地址address start:024036(相对于system起始地址的偏移量);偏移量大小size:4(即024036~024040地址段的数据)
Map2(cow文件中存储的更新数据的地址):起始地址address start:045036(相对于cow文件存储的起始地址的偏移量);偏移量大小size:4(即045036~045040地址段的数据);
文件名后的数值(045033~045035以及045036~045040)分别为COW文件(system_b-cow-img.img.0000)中最新版的/system/app/A2.XXX以及/system/user/C2.XXX在用户数据分区(Userdata)的物理保存地址(块地址)。
这样,如果使用地址045033~045035上的A2.XXX替换掉地址024018~024020上的A2.XXX,并且,使用地址045036~045040上的C2.XXX替换掉地址024036~024040上的C2.XXX,就可以完成动态分区(Super)的system子分区的数据升级。
进一步的,在S230中,在将COW文件写入用户数据分区(Userdata)后,还需要对动态分区(Super)+COW文件进行整体校验,校验动态分区(Super)+COW文件的有效性,验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super)数据。
具体的,以从1.1版本升级到1.3版本为例,计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.2未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.2需要升级的数据)的合成结果的哈希值,判断该哈希值与1.3版本中动态分区(Super)的完整数据的哈希值是否一致,如果一致,则说明COW文件有效;如果不一致,则说明COW文件无效,升级失败,中断升级进程并报错;其中,1.3版本中动态分区(Super)的完整数据的哈希值被保存在操作系统升级安装包中。
具体的,在校验过程中,基于snapshot合并动态分区(Super)+COW文件。在snapshot的实现过程中,动态分区(Super)与COW文件的合并并不是物理意义上的合并,而是将动态分区(Super)中子分区的文件地图与COW文件自身的COW文件地图进行合并,生成新版本的子分区数据的文件地图。
例如,将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:045033~045035;
/system/user/C2.XXX:045036~045040。
合并。则得到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下的B0.XXX)
/system/B1.XXX:024027~024028;
(指向动态分区(Super)中/system下的B1.XXX)
/system/user/C0.XXX:024029~024032;
(指向动态分区(Super)中/system/user下的C0.XXX)
/system/user/C1.XXX:024033~024035;
(指向动态分区(Super)中/system/user下的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/user下的C3.XXX)
在新版本的system子分区的文件地图中,/system/app/A2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/app/A2.XXX,而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的A2.XXX;/system/user/C2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/user/C2.XXX,而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的C2.XXX。
在校验过程中,按照上述合成方式,获取动态分区(Super)的所有子分区的新版本的文件地图(如果用户数据分区(Userdata)中并未写入某个子分区的对应COW文件,则直接以该子分区的文件地图为新版本的文件地图)。将所有子分区的新版本的文件地图组合生成动态分区(Super)的新版本的文件系统。
基于动态分区(Super)的新版本的文件系统读取数据,读取动态分区(Super)的新版本的文件系统所包含的所有文件并计算哈希值。
在COW文件成功写入到用户数据分区(Userdata)后,将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait formerge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的COW文件。具体的,落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时,代表动态分区(Super)的所有子分区均不需要进行落盘操作;当整体标识为“未落盘(wait for merge)”时,代表动态分区(Super)的一个或多个子分区需要进行落盘操作;当子分区标识为“已落盘(merged)”时,代表该子分区不需要进行落盘操作;当子分区标识为“未落盘(wait for merge)”时,代表该子分区需要进行落盘操作。
S231,将设备的启动顺序由可从静态分区(A)启动变更为可从静态分区(B)启动。
例如,改写主引导记录(Master Boot Record,MBR)的启动顺序标识,将启动顺序标识由A改写为B。在设备上电后,当设备读取到启动顺序标识为A,设备从静态分区(A)启动,启动过程中加载静态分区(A);当设备读取到启动顺序标识为B,设备从静态分区(B)启动,启动过程中加载静态分区(B)。
S232,设备重启。退出当前的操作系统,切断设备电源,再次开启设备电源。
S240,设备依次加载基础分区(Common)、静态分区(B)。
S241,设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。
具体的,设备读取元数据(/metadata)中的落盘状态信息,基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索COW文件,并采用snapshot合并加载动态分区(Super)以及COW文件。
进一步的,在S241中,设备并不加载动态分区(Super)以及用户数据分区(Userdata)中的全部COW文件,而是根据操作系统运行需求加载对应的文件。具体的,在S241中,设备根据操作系统运行需求确定需要加载的文件,基于snapshot从动态分区(Super)或虚拟动态分区中的COW文件中提取对应的文件进行加载。
具体的,在S241中,当动态分区(Super)的子分区首存在对应的COW文件时,先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照S230。设备根据操作系统运行需求确定需要加载的文件,基于动态分区(Super)子分区的新版本的文件地图进行文件加载。
例如,操作系统运行需求加载system子分区下目录user(/system/user)中的所有数据。设备读取元数据(/metadata)中的落盘状态信息,落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”,因此,设备在用户数据分区(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子分区的子分区标识为“已落盘(merged)”时,设备就不会在用户数据分区(Userdata)中/Update下搜索COW文件,而是直接加载system子分区下目录user(/system/user)中的所有数据。
进一步的,在加载system子分区下目录user(/system/user)中的所有数据时,当落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”时,如果设备在用户数据分区(Userdata)中/Update下未搜索到对应system子分区的COW文件时,则说明升级过程中数据写入错误(COW文件写入错误或者落盘状态信息写入错误),此时设备回滚系统并报错。
进一步的,在S241中,在加载文件之前,设备还需要对加载文件进行校验。不同于S230,在S241中,不对动态分区(Super)+COW文件进行整体验证,而是仅对需要加载的文件进行验证。例如,基于dmverity进行校验(dm-verity是dm(device mapper)的一个目标(target),是一个虚拟块设备,专门用于文件系统的校验)。校验成功则加载文件,校验失败则重启设备,回滚系统或者尝试再次加载文件。
S250,设备成功启动,进入用户交互界面。
S251,设备将虚拟动态分区的数据落盘到动态分区(Super)。
在本申请说明书的描述中,落盘操作指的是,在操作系统升级过程中,将用户数据分区(Userdata)上虚拟动态分区中保存的动态分区(Super)升级文件(COW文件)写入到动态分区(Super)中,使得动态分区(Super)的文件完成数据升级,以便设备在下次启动时不需要加载动态分区(Super)和虚拟动态分区,只需加载动态分区(Super)就可以完成设备启动。
具体的,设备在启动成功后进行开机广播,开机广播后开启升级进程。升级进程读取基础分区(Common)的元数据(/metadata)中的落盘状态信息,如果落盘状态信息为“已落盘(merged)”,则设备进入正常运行模式。
如果落盘状态信息为“未落盘(wait for merge)”,升级进程将用户数据分区(Userdata)中的COW文件落盘到动态分区(Super)中。
具体的,升级进程将用户数据分区(Userdata)中的COW文件中的升级数据写入到动态分区(Super)中的对应地址上,使得动态分区(Super)中的全部数据均为升级后的新版本的数据。
例如,基于system子分区的文件地图中的/system/app/A2.XXX:024018~024020以及COW文件地图中的/system/app/A2.XXX:045033~045035,将地址045033~045035上的数据写入到地址024014~024017上;基于system子分区的文件地图中的/system/user/C2.XXX:024036~024040以及COW文件地图中的/system/user/C2.XXX:045036~045040,将地址045036~045040上的数据写入到地址024036~024040上。
在此之后升级进程删除用户数据分区(Userdata)中的COW文件,将存储空间归还给用户数据分区(Userdata);并且,将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。
在S220中,静态分区升级的数据操作是针对静态分区(B)中的操作系统数据的,其并不会影响到当前启动的静态分区(A)的操作系统数据;并且,在S230中,动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的,其并不会影响到当前挂载的动态分区(Super)。因此,在整个操作系统升级的过程中,用户可以正常使用设备;并且,在S231完成后,设备并不需要立即重启,可以由用户自行选择重启时机;这样,操作系统的升级过程并不会对用户的正常手机操作产生影响,从而大大提高了用户体验。进一步的,针对动态分区(Super),仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区,因此有效提高了数据存储空间利用率。
具体的,图2b为根据本申请一实施例的手机运行界面示意图。当手机顺利启动操作系统后,进入如图2b中201所示的系统界面。手机执行S200~S231,手机的显示界面可以为图2b中202所示的界面,从而向用户展示操作系统升级进度。S200~S231可以在系统后台运行,用户在手机运行S200~S231是可以切换至201所示的系统界面,打开其他应用;或者,用户在手机运行S200~S231是可以切换至系统正在运行的其他应用的应用界面,例如,204所示的聊天应用界面。
在S232中,当手机需要重启时,手机向用户输出重启提示,由用户确认是否立即重启。例如,手机当前展示如图2b中202所示的界面,向用户展示操作系统升级进度。当需要重启时,手机展示如图2b中203所示的界面,由用户确认立即重启或是稍后重启。又例如,手机当前展示如图2b中204所示的界面,用户使用聊天应用。当需要重启时,手机展示如图2b中205所示的界面,弹出提示通知。用户点击提示通知,进入如图2b中203所示的界面,由用户确认立即重启或是稍后重启。或者,用户打开下拉通知栏,手机展示如图2b中206所示的界面。在下拉通知栏中,用户点击提示通知,进入如图2b中203所示的界面,由用户确认立即重启或是稍后重启。
在实际应用场景中,在S220的执行过程中,存在S220执行失败(静态分区(B)的数据升级失败)的情况。针对该情况,设备会中断整个操作系统升级操作,向用户输出升级失败提示信息(例如,显示升级失败的对话框),自动重新升级或者由用户确定是否重新升级或放弃升级。
具体的,图2c为根据本申请一实施例的手机运行界面示意图。例如,在S220的执行过程中,如果S220执行失败,手机展示如图2c中206或207所示的界面,由用户确认放弃本次升级(更新)或是重新升级(更新)。
例如,手机当前展示如图2b中202所示的界面,向用户展示操作系统升级进度。如果S220执行失败,手机展示如图2c中209所示的界面,由用户确认放弃本次升级(更新)或是重新升级(更新)。又例如,手机当前展示如图2b中204所示的界面,用户使用聊天应用。如果S220执行失败,手机展示如图2c中207所示的界面,弹出提示通知“本次系统安装失败”。用户点击提示通知,进入如图2c中209所示的界面,由用户确认放弃安装(升级)或是重新安装(升级)升级。或者,用户打开下拉通知栏,手机展示如图2c中208所示的界面。在下拉通知栏中,用户点击提示通知,进入如图2c中209所示的界面,由用户确认放弃安装(升级)或是重新安装(升级)升级。
为检测S220中是否存在静态分区升级失败的情况,在S220中,会对数据写入后的静态分区(B)进行数据校验以确认静态分区数据是否成功写入。
例如,在一应用场景中,版本1.1升级到版本1.2的系统升级安装包包含版本1.2的静态分区的全量数据以及版本1.2的静态分区的全量数据的哈希值。设备将版本1.2的静态分区的全量数据覆写到静态分区(B)中。数据写入之后,设备计算静态分区(B)中数据的哈希值,校验静态分区(B)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.2的静态分区的全量数据的哈希值是否一致。如果一致,则说明数据写入成功,可以进行后续的操作系统升级操作;如果不一致,则说明数据写入失败,升级失败。
又例如,在一应用场景中,版本1.1升级到版本1.2的系统升级安装包包含版本1.1升级到版本1.2的静态分区的差分数据、版本1.1的静态分区的全量数据的哈希值以及版本1.2的静态分区的全量数据的哈希值。
设备在向静态分区(B)写入数据之前,首先计算静态分区(A)中数据的哈希值,校验静态分区(A)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.1的静态分区的全量数据的哈希值是否一致,如果一致,则说明当前静态分区(A)中数据为版本1.1的静态分区数据,版本1.1升级到版本1.2的静态分区的差分数据可用;如果不一致,则版本1.1升级到版本1.2的静态分区的差分数据不可用,升级失败。
在设备确定版本1.1升级到版本1.2的静态分区的差分数据可用后,读取静态分区(A)中数据,使用版本1.1升级到版本1.2的静态分区的差分数据以及静态分区(A)中数据执行还原得到版本1.2的静态分区的全量数据,将版本1.2的静态分区的全量数据覆写到静态分区(B)中。数据写入之后,设备计算静态分区(B)中数据的哈希值,校验静态分区(B)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.2的静态分区的全量数据的哈希值是否一致。如果一致,则说明数据写入成功,可以进行后续的操作系统升级操作;如果不一致,则说明数据写入失败,升级失败。
以一个静态分区的子分区boot为例,在一应用场景中,版本1.1升级到版本1.2的系统升级安装包包含下述数据:
Name:boot(分区名称,表示当前数据为指向静态分区的子分区boot的升级数据)
Start:12222(相对于升级包数据块的数据块起始地址,表示静态分区的子分区boot的升级数据(差分数据DELTA1)的起始位置为12222)
size:2410(数据大小,表示静态分区的子分区boot的升级数据(差分数据DELTA1)的大小为2410)
原hash值:HASH11(版本1.1的静态分区的子分区boot的数据的哈希值)
镜像目标hash值:HASH12(版本1.2的静态分区的子分区boot的数据的哈希值)
差分数据delta:DELTA1(版本1.1升级到版本1.2的静态分区的差分数据)
在S220中,设备通过common分区中的misc分区读取设备的固定挂载路径,如/dev/block/by-name/misc。从UFS器件中读取卡槽位(slot-b),替换得到个子分区路径,如/dev/block/by-name/boot_b。
继续以子分区boot为例,设备首先计算/dev/block/by-name/boot_a下数据的哈希值,校验/dev/block/by-name/boot_a下数据的哈希值与哈希值HASH11是否一致,如果一致,则DELTA1可用,如果不一致,则升级操作失败。
当/dev/block/by-name/boot_a下数据的哈希值与哈希值HASH11一致时,设备基于Start:12222以及size:2410读取DELTA1,使用DELTA1与/dev/block/by-name/boot_a下数据执行还原得到版本1.2的静态分区的子分区boot的全量数据。设备将版本1.2的静态分区的子分区boot的全量数据写到/dev/block/by-name/boot_b下。
数据写入后,设备计算/dev/block/by-name/boot_b下数据的哈希值,校验/dev/block/by-name/boot_b下数据的哈希值与哈希值HASH12是否一致,如果一致,则静态分区的子分区boot升级成功,可以针对下一个静态分区子分区进行升级;如果不一致,则升级操作失败。
在一应用场景中,设备根据系统升级安装包所包含的静态分区子分区升级数据对静态分区的子分区进行升级,具体的,如果系统升级安装包包含某个静态分区子分区升级数据,则按照上述boot子分区的升级流程对该静态分区(B)中的该子分区进行升级,如果系统升级安装包不包含某个静态分区子分区升级数据,则将静态分区(A)中该子分区的数据直接同步到静态分区(B)中该子分区中。在升级过程中,当一个子分区出现升级错误,哈希校验失败,则中断升级操作,升级失败;当所有子分区升级成功,则静态分区升级成功,可以执行后续步骤。
一般的,当某个静态分区(静态分区(A)或静态分区(B))升级失败时,静态分区的数据无法用于顺利启动操作系统,为了避免在操作系统启动过程中加载升级失败的静态分区而导致操作系统启动错误,在一应用场景中,静态分区具备对应的状态标记(可启动或不可启动)。设备在加载静态分区数据之前首先读取静态分区状态标记,仅当静态分区的状态标记为可启动时才加载静态分区的数据。在升级静态分区的数据之前,会将静态分区标记为不可启动,在静态分区的数据升级成功后再将静态分区标记为可启动,这样,如果静态分区升级失败,则静态分区的状态会保持在不可启动。设备就不会加载升级失败的静态分区的数据。
例如,在一应用场景中,在S220中,在升级静态分区(B)的数据之前,标记静态分区(B)为不可启动。具体的,静态分区的状态标记可以保存在Common分区。在S220中,在升级静态分区(B)的数据之前,将Common分区中静态分区的状态标记中slot-b标记为不可启动(unbootable)。
当S220成功执行(所有的哈希校验均成功时)后,在设备重启(S232)之前,标记静态分区(B)为可启动。例如,在S220之后,在S230之前,将Common分区中静态分区的状态标记中slot-b标记为可启动(bootable);或者,在S231中,将Common分区中静态分区的状态标记中slot-b标记为bootable。
在一个静态分区被标记为不可启动后,设备在启动操作系统的过程中不会加载该静态分区的数据。然而,在一个静态分区被标记为不可启动后,存在另一个静态分区出现数据错误无法启动操作系统的情况,此时两个静态分区均无法启动操作系统,设备无法顺利启动。
例如,在S220中,在升级静态分区(B)的数据之前,Common分区中静态分区的状态标记中slot-b被标记为unbootable。在之后的针对静态分区(B)的数据写入过程中,出现数据写入错误,哈希校验失败,操作系统升级失败,Common分区中静态分区的状态标记中slot-b保持在unbootable。假如此时静态分区(A)中的数据出现错误(例如,硬件存储物理损坏、存储位bit跳变),设备重启后无法通过加载静态分区(A)来顺利启动操作系统;并且,由于Common分区中静态分区的状态标记中slot-b为unbootable,设备也无法加载静态分区(B)启动操作系统,这就使得设备无法顺利启动。
针对上述问题,本申请一实施例提出了一种操作系统数据调配方法,在某个静态分区升级失败后,重置该静态分区的状态标记并回滚该静态分区的数据,以使得设备可以通过加载该静态分区的数据顺利启动操作系统。
图3a所示为根据本申请一实施例的操作系统数据调配流程图。当S220执行失败(静态分区(B)的数据升级失败)时,例如,静态分区数据写入失败(出现哈希校验失败),在S220后,设备执行如图3a所示的下述流程:
S310,将静态分区(B)的状态标记设置为bootable;
具体的,将Common分区中静态分区的状态标记中slot-b标记为bootable。
S320,将静态分区(A)的数据同步到静态分区(B)。
根据图3a所示实施例的方法,可以在静态分区(B)升级失败时确保设备后续可以从静态分区(B)顺利启动操作系统,从而大大提高操作系统启动的成功率,确保设备稳定运行,提高用户的设备使用体验。
进一步的,S310以及S320的执行并不会影响到当前启动的静态分区(A)的操作系统数据。因此,S310以及S320的执行过程中,用户可以正常使用设备;S310以及S320可以后台执行,并不会对用户的正常手机操作产生影响,从而大大提高了用户体验。
进一步的,本申请对S320的具体实现方式不做具体限制,本领域的技术人员可以采用多种可行的实现方式实现S320。
例如,图3b所示为根据本申请一实施例进行操作系统升级的部分流程图。设备执行如图3b所示的下述流程以实现S320。
S1800,读取设备存储器上与分区表相关的描述数据(该参数在设备出厂时预存在设备中),合成存储器的总分区表。
例如,以采用主引导记录(Master Boot Record,MBR)格式的通用闪存(UniversalFlash Storage,UFS)。从UFS的MBR(主引导扇区,UFS的第一个扇区,即C/H/S地址的0柱面0磁头1扇区)中读取UFS上各个分区的大小及位置信息,获取分区表(Dpt)。
S1810,从总分区表中读取后缀名为_b的所有静态子分区,生成用于描述静态分区(B)各个子分区的列表1,列表1包括静态分区(B)中各个子分区的名称以及地址。例如:
编号 | 子分区名称 | 子分区地址(文件路径) | 被选定状态 |
1 | bootloader_b | /dev/block/by-name/bootloader_b | 0 |
2 | boot_b | /dev/block/by-name/boot_b | 0 |
3 | vendor_boot_b | /dev/block/by-name/vendor_boot_b | 0 |
4 | dtbo_b | /dev/block/by-name/dtbo_b | 0 |
5 | vbmeta_b | /dev/block/by-name/vbmeta_b | 0 |
表1
S1820,从总分区表中读取后缀名为_a的所有静态子分区,生成用于描述静态分区(A)各个子分区的列表2,列表2包括静态分区(A)中各个子分区的名称以及地址。
例如:
编号 | 子分区名称 | 子分区地址(文件路径) |
1 | bootloader_a | /dev/block/by-name/bootloader_a |
2 | boot_a | /dev/block/by-name/boot_a |
3 | vendor_boot_a | /dev/block/by-name/vendor_boot_a |
4 | dtbo_a | /dev/block/by-name/dtbo_a |
5 | vbmeta_a | /dev/block/by-name/vbmeta_a |
表2
这里需要说明的是,在表1以及表2中,以文件路径的方式指代该子分区的地址,在实际应用场景中,本领域的技术人员可以使用多种不同的方式描述子分区的地址。例如,采用线性地址描述。
S1830,在列表1中选定一个未被选定过的子分区(第一子分区),获取该子分区的名称(第一子分区名称)以及地址(第一文件路径)。
具体的,在S1830之前,列表1中的子分区均未被选定。在S1830中,可以按照列表1中子分区的排列顺序(编号顺序)依次选定子分区,也可以从所有未被选定过的子分区中随机选定。
进一步的,在选定一个子分区后,标记该子分区以便在后续确认该子分区是否被选定过。例如,如表1所示,在表1中增加被选定状态列,被选定状态的初始值为0,如子分区被选定,则被选定状态修改为1。
S1840,将S1830中选定的子分区与列表2中的各个子分区做去后缀匹配;确定列表2中,去掉后缀后,与S1830中选定的子分区名称一致的子分区(第二子分区名称)以及在列表2中,该第二子分区名称对应的子分区地址(第二文件路径);
S1841,读取第一文件路径下的数据;
S1842,将读取到的数据覆写到第二文件路径下。
S1850,判断列表1中是否还存在未被选定过的子分区;
如果存在,返回步骤S1830,重新选定第一子分区;
如果不存在,静态分区同步结束。
以表1以及表2为例,在一应用场景中,设备执行下述流程:
选定表1中被选定状态为0的第一个子分区(编号1的bootloader_b子分区),将编号1DD211798I的被选定状态修改为1;
使用bootloader_b在表2中的所有子分区名称中做去后缀匹配,bootloader_a与bootloader_b在分别去掉_a以及_b后一致,因此,根据bootloader_b匹配到bootloader_a(第二子分区);
从表1中读取到bootloader_b对应的文件路径/dev/block/by-name/bootloader_b(第一文件路径);
从表2中读取到bootloader_a对应的文件路径/dev/block/by-name/bootloader_a(第二文件路径);
读取/dev/block/by-name/bootloader_b下的数据,将读取到的数据覆写到/dev/block/by-name/bootloader_a;
表1中仍存在被选定状态为0的子分区,选定表1中被选定状态为0的第一个子分区(编号2的boot_b子分区),将编号2的被选定状态修改为1;
使用boot_b在表2中的所有子分区名称中做去后缀匹配,boot_a与boot_b在分别去掉_a以及_b后一致,因此,根据boot_b匹配到boot_a;
从表1中读取到boot_b对应的文件路径/dev/block/by-name/boot_b;
从表2中读取到boot_a对应的文件路径/dev/block/by-name/boot_a;
读取/dev/block/by-name/boot_b下的数据,将读取到的数据覆写到/dev/block/by-name/boot_a;
表1中仍存在被选定状态为0的子分区,选定表1中被选定状态为0的第一个子分区(编号3的vendor_boot_b子分区),将编号3的被选定状态修改为1;
使用vendor_boot_b在表2中的所有子分区名称中做去后缀匹配,vendor_boot_a与vendor_boot_b在分别去掉_a以及_b后一致,因此,根据vendor_boot_b匹配到vendor_boot_a;
从表1中读取到vendor_boot_b对应的文件路径/dev/block/by-name/vendor_boot_b;
从表2中读取到vendor_boot_a对应的文件路径/dev/block/by-name/vendor_boot_a;
读取/dev/block/by-name/vendor_boot_b下的数据,将读取到的数据覆写到/dev/block/by-name/vendor_boot_a;
表1中仍存在被选定状态为0的子分区,选定表1中被选定状态为0的第一个子分区(编号4的dtbo_b子分区),将编号4的被选定状态修改为1;
使用dtbo_b在表2中的所有子分区名称中做去后缀匹配,dtbo_a与dtbo_b在分别去掉_a以及_b后一致,因此,根据dtbo_b匹配到dtbo_a;
从表1中读取到dtbo_b对应的文件路径/dev/block/by-name/dtbo_b;
从表2中读取到vendor_boot_a对应的文件路径/dev/block/by-name/dtbo_a;
读取/dev/block/by-name/dtbo_b下的数据,将读取到的数据覆写到/dev/block/by-name/dtbo_a;
表1中仍存在被选定状态为0的子分区,选定表1中被选定状态为0的第一个子分区(编号5的vbmeta_b子分区),将编号5的被选定状态修改为1;
使用vbmeta_b在表2中的所有子分区名称中做去后缀匹配,vbmeta_a与vbmeta_b在分别去掉_a以及_b后一致,因此,根据vbmeta_b匹配到vbmeta_a;
从表1中读取到vbmeta_b对应的文件路径/dev/block/by-name/vbmeta_b;
从表2中读取到vendor_boot_a对应的文件路径/dev/block/by-name/vbmeta_a;
读取/dev/block/by-name/vbmeta_b下的数据,将读取到的数据覆写到/dev/block/by-name/vbmeta_a;
表1中不存在被选定状态为0的子分区,静态分区同步完成。
进一步的,S310以及S320可以在S220之后执行,本申请对S310以及S320的具体执行时机并不做具体限制。
例如,在一应用场景中,在S220执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框,如图2c的206或207所示)。在设备中断整个操作系统升级操作后,设备执行S310以及S320;在S310以及S320之后,设备向用户输出升级失败提示。
又例如,在一应用场景中,在S220执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框),之后设备自动重新升级或者由用户确定是否重新升级或放弃升级。在设备向用户输出升级失败提示之后,设备执行S310以及S320;在S310以及S320之后,设备自动重新升级或者由用户确定是否重新升级或放弃升级。
进一步的,S310以及S320在S220之后执行,并不意味着S310以及S320必须被执行。本申请对S310以及S320的触发条件并不做具体限制。
例如,在一应用场景中,在S220执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框),之后设备自动重新升级。由于设备的重新升级会将静态分区(B)的状态标记由unbootable并向静态分区(B)写入数据,S310以及S320的执行结果会被设备的重新升级操作刷新,因此,在此状态下设备不执行S310以及S320。
又例如,在一应用场景中,在S220执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框),之后设备放弃升级。在设备放弃升级后,静态分区(B)的状态标记以及静态分区(B)中的数据会维持。因此,在此状态下,设备在中断整个操作系统升级操作后执行S310以及S320;在S310以及S320之后,设备向用户输出升级失败提示。或者,设备在向用户输出升级失败提示后执行S310以及S320。
又例如,在一应用场景中,在S220执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框),之后设备向用户请求确认是否重新升级或放弃升级。当用户确认重新升级时,设备不执行S310以及S320,重新执行升级;当用户确认放弃升级时,设备执行S310以及S320。
在实际应用场景中,在S230的执行过程中,存在S230执行失败的情况(动态分区升级数据写入失败)。针对该情况,设备会中断整个操作系统升级操作,向用户输出升级失败提示信息(升级失败提示信息的输出方式可以参照图2c所示),自动重新升级或者由用户确定是否重新升级或放弃升级。
具体的,当用户数据分区(Userdata)的存储空间不足时会导致S230执行失败。在S230中,在设备根据操作系统升级安装包在用户数据分区(Userdata)创建虚拟动态分区的过程中,虚拟动态分区的大小是由操作系统升级安装包中版本1.2的动态分区的数据的大小决定的。当用户数据分区(Userdata)上的空余空间不足以创建虚拟动态分区时,S230执行失败。
例如,在一应用场景中,设备从操作系统升级安装包中提取COW文件并将COW文件写入用户数据分区(Userdata)的Update文件夹中。操作系统升级安装包中包含COW文件内容以及COW文件大小。在S230中,设备首先根据操作系统升级安装包中的cow文件名称以及COW文件大小在用户数据分区(Userdata)的Update文件夹下创建空COW文件,然后从操作系统升级安装包中提取COW文件数据写入空COW文件。
以system子分区为例,在操作系统升级安装包中,针对system子分区的COW文件被命名为system-cow-img.img.0000,system-cow-img.img.0000的大小为XXXX。设备在用户数据分区(Userdata)的Update文件夹下创建system_b-cow文件,system_b-cow文件的大小为XXXX,内容为空。在system_b-cow文件创建完成后,设备就可以从系统升级安装包中提取system-cow-img.img.0000,写入system_b-cow并改名为system_b-cow-img.img.0000。
设备在用户数据分区(Userdata)的Update文件夹下依次创建空COW文件system_b-cow、system_ext_b-cow、vendor_b-cow、product_b-cow、cust_b-cow、odm_b-cow。当所有的空COW文件创建完成后,设备就可以从系统升级安装包中提取COW文件数据,写入空COW文件并改名。
最终用户数据分区(Userdata)的Update文件夹中包含下述文件:
system_b-cow-img.img.0000;
system_ext_b-cow-img.img.0000;
vendor_b-cow-img.img.0000;
product_b-cow-img.img.0000;
cust_b-cow-img.img.0000;
odm_b-cow-img.img.0000。
在创建空COW文件的过程中,设备每次创建一个空COW文件,在一个空COW文件创建成功后创建下一个。在此过程中,当一个空COW文件创建失败,则说明用户数据分区(Userdata)的存储空间不足,S230执行失败,操作系统升级失败。
进一步的,在S230中,COW文件的提取失败也会导致S230执行失败。具体的,在操作系统升级安装包中,以二进制代码形式保存COW文件,在将COW文件写入用户数据分区(Userdata)时,首先需要从操作系统升级安装包中提取COW文件,将COW文件打开,将COW文件数据写入到用户数据分区(Userdata)。在上述过程中,如果操作系统升级安装包存在数据错误,COW文件无法提取或打开,则S230执行失败,操作系统升级失败。
进一步的,在S230中,COW文件的写入失败也会导致S230执行失败。为检测COW文件写入是否成功,在S230中,在将COW文件写入用户数据分区(Userdata)后,还需要对动态分区(Super)+COW文件进行整体校验,校验动态分区(Super)+COW文件的有效性,验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super)数据。
具体的,以从1.1版本升级到1.3版本为例,计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.2未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.2需要升级的数据)的合成结果的哈希值,判断该哈希值与1.3版本中动态分区(Super)的完整数据的哈希值是否一致,如果一致,则说明COW文件有效;如果不一致,则说明COW文件无效,升级失败,中断升级进程并报错;其中,1.3版本中动态分区(Super)的完整数据的哈希值被保存在操作系统升级安装包中。
具体的,在校验过程中,基于snapshot合并动态分区(Super)+COW文件。在snapshot的实现过程中,动态分区(Super)与COW文件的合并并不是物理意义上的合并,而是将system子分区的整体文件地图与COW文件自身的COW文件地图进行合并,生成新版本的子分区数据的文件地图。
例如,将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:045033~045035;
/system/user/C2.XXX:045036~045040。
合并。则得到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下的B0.XXX)
/system/B1.XXX:024027~024028;
(指向动态分区(Super)中/system下的B1.XXX)
/system/user/C0.XXX:024029~024032;
(指向动态分区(Super)中/system/user下的C0.XXX)
/system/user/C1.XXX:024033~024035;
(指向动态分区(Super)中/system/user下的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/user下的C3.XXX)
在新版本的system子分区的文件地图中,/system/app/A2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/app/A2.XXX,而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的A2.XXX;/system/user/C2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/user/C2.XXX,而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的C2.XXX。
在校验过程中,按照上述合成方式,获取动态分区(Super)的所有子分区的新版本的文件地图(如果用户数据分区(Userdata)中并未写入某个子分区的对应COW文件,则直接以该子分区的文件地图为新版本的文件地图)。将所有子分区的新版本的文件地图组合生成动态分区(Super)的新版本的文件系统。
基于动态分区(Super)的新版本的文件系统读取数据,读取动态分区(Super)的新版本的文件系统所包含的所有文件并计算哈希值。
一般的,由于在升级动态分区(Super)时,采用的是将COW文件写入用户数据分区(Userdata)的方式,在落盘前,动态分区(Super)的各个子分区的数据并未被改写。并且,S230是在S220成功执行(静态分区(B)升级成功)后执行的,S220成功执行(静态分区(B)升级成功)后,静态分区(B)上的数据是可以顺利加载的。因此,理论上,在S230执行失败时,如果静态分区(B)的状态标记被设置为bootable(执行S310),设备就可以从静态分区(B)启动操作系统。
例如,设备在S220成功执行(静态分区(B)升级成功)后,在S230前执行S310;之后执行S230,当S230执行失败(动态分区升级失败)后,设备中断整个操作系统升级操作。设备向用户输出升级失败提示信息。
又例如,设备在S220成功执行(静态分区(B)升级成功)后,执行S230,当S230执行失败(动态分区升级失败)后,设备中断整个操作系统升级操作。设备执行S310,并且,向用户输出升级失败提示信息。
进一步的,在S220成功执行(静态分区(B)升级成功)后,存在升级成功的静态分区(B)与未升级的动态分区(Super)不匹配的情况。即,在S230执行失败时,设备加载S220成功执行后的静态分区(B)无法顺利启动操作系统。因此,在S230执行失败后,需要将静态分区(B)的数据回滚到升级前的状态(执行S320),才可以使得设备可以从静态分区(B)启动操作系统。
例如,设备在S220成功执行(静态分区(B)升级成功)后,在S230前执行S310;当S230执行失败(动态分区升级失败)后,设备中断整个操作系统升级操作。在设备中断整个操作系统升级操作后,执行S320;在S320之后,设备向用户输出升级失败提示信息。或者,设备在S220成功执行(静态分区(B)升级成功)后,执行S230;当S230执行失败(动态分区升级失败)后,设备中断整个操作系统升级操作。在设备中断整个操作系统升级操作后,执行S310以及S320;在S310以及S320之后,设备向用户输出升级失败提示信息。
又例如,设备在S220成功执行(静态分区(B)升级成功)后,在S230前执行S310;当S230执行失败(动态分区升级失败)后,设备中断整个操作系统升级操作。在设备中断整个操作系统升级操作后,设备向用户输出升级失败提示,在设备向用户输出升级失败提示后,执行S320。或者,设备在S220成功执行(静态分区(B)升级成功)后,执行S230;当S230执行失败(动态分区升级失败)后,设备中断整个操作系统升级操作。在设备中断整个操作系统升级操作后,设备向用户输出升级失败提示;在设备向用户输出升级失败提示后,执行S310以及S320。
又例如,在一应用场景中,在S230执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框),之后设备自动重新升级。在此状态下设备不执行S310以及S320。
又例如,在一应用场景中,在S230执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框),之后设备放弃升级。在此状态下,设备在中断整个操作系统升级操作后执行S310以及S320;在S310以及S320之后,设备向用户输出升级失败提示信息。或者,设备在向用户输出升级失败提示信息后执行S310以及S320。
又例如,在一应用场景中,在S230执行失败后,设备中断整个操作系统升级操作,向用户输出升级失败提示(例如,显示升级失败的对话框),之后设备向用户请求确认是否重新升级或放弃升级。当用户确认重新升级时,设备不执行S310以及S320,重新执行升级;当用户确认放弃升级时,设备执行S310以及S320。
进一步的,在S230执行失败后,还恢复用户数据分区(Userdata),删除用户数据分区(Userdata)中已写入的动态分区升级数据。例如,删除用户数据分区(Userdata)上创建的空COW文件以及删除已写入的COW文件。
进一步的,在某些应用场景中,在S230中,设备不仅仅向用户数据分区(Userdata)写入COW文件,还会刷新动态分区(Super)的metadata中的分区信息。
具体的,图4所示为一应用场景下设备出厂前进行系统烧录的烧录系统框架结构示意图。在采用虚拟A/B升级方式的安卓系统中,由于只有静态分区采用A/B方案,而动态分区采用升级时构造虚拟动态分区的方案。因此,为了静态分区与动态分区的匹配,如图4所示,在动态分区(Super)的头部的元数据(/supermetadata)中,包含对应静态分区(A)的Slot0(插槽一数据)以及静态分区(B)的Slot1(插槽二数据)。Slot0以及Slot1用于保存Super分区的分区表。
例如,在UFS的MBR中,设备启动顺序描述中,配置Slot0对应从静态分区(A)启动,配置Slot1对应从静态分区(B)启动。在设备启动时,根据启动的静态分区的不同,选择从Slot0或Slot1中的一个中获取Super分区的分区信息。例如,在设备由静态分区A启动时,在加载Super分区时,设备首先读取Slot0,以获取Super分区的子分区地址;在设备由静态分区B启动时,在加载Super分区时,设备首先读取Slot1,以获取Super分区的子分区地址。
具体的,Slot0以及Slot1中包含多个子分区描述组,每个子分区描述组对应Super分区的一个子分区。每个子分区描述组包含:
名称(Name)项,其值为子分区的名称;
组(Group)项,其值为子分区类型;
属性(Attributes)项,其值为分区读写属性,例如,只读属性(readonly);
地址(Extents)项,其值为子分区的地址(例如,分区大小、偏移量)。
在Name项以及Group项中,值的后缀为_a,则对应静态分区(A);值的后缀为_b,则对应静态分区(B)。
在由静态分区A启动,加载Super分区时,首先读取Slot0。在读取Slot0时,由于后缀为_a对应静态分区(A),设备读取Slot0中Name项和/或Group项后缀为_a的分区描述组中Extents项的值,以获取Super分区的子分区地址。
在由静态分区B启动,加载Super分区时,首先读取Slot1。在读取Slot1时,由于后缀为_b对应静态分区(B),设备读取Slot0中Name项和/或Group项后缀为_b的分区描述组中Extents项的值,以获取Super分区的子分区地址。
在S210所获取的操作系统升级安装包中,包含1.2版本的动态分区(Super)的分区信息,在S230中,设备从操作系统升级安装包中提取1.2版本的动态分区(Super)的分区信息,使用1.2版本的动态分区(Super)的分区信息刷新静态分区(B)所对应的Slot1中的分区信息。
以System子分区为例,假设在S230之前,动态分区(Super)的/supermetadata的Slot 1中包含如下内容:
Metadata version:10.2(元数据版本)
Metadata size:1300bytes(元数据数据量)
Metadata max size:65536bytes(元数据最大数据量)
Metadata slot count:3(元数据插槽数量)
Header flags:virtual_ab_device(标题标志:虚拟A/B设备)
Partition table:------------------------(分区表)
Name:system_b
Group:ry_dynamic_partitions_b
Attributes:readonly,updated
Extents:0..6995967linear super 2048
在S210所获取的操作系统升级安装包中,1.2版本的动态分区(Super)的分区信息包含如下内容:
Name:system
Group:ry_dynamic_partitions
Extents:0..699XXXX linear super 2048
在S230中,设备通过当前需要升级的静态分区为静态分区(B)定位到对应静态分区(B)的动态分区(Super)的/supermetadata的Slot 1,使用1.2版本的动态分区(Super)的分区信息刷新Slot 1中的内容。在S230之后,动态分区(Super)的/supermetadata的Slot 1中包含如下内容:
Metadata version:10.2
Metadata size:1300bytes
Metadata max size:65536bytes
Metadata slot count:3
Header flags:virtual_ab_device
Partition table:------------------------
Name:system_b
Group:ry_dynamic_partitions_b
Attributes:readonly,updated
Extents:0..699XXXX linear super 2048
假设S230执行失败,但是,在S230执行失败之前已完成了Slot 1的内容刷新,那么,S230执行失败时Slot 1版本就是1.2。这样,如果在S230执行失败后将静态分区(B)的内容回滚到版本1.1,静态分区(B)就与Slot 1的版本不匹配,设备很有可能无法从静态分区(B)顺利启动操作系统。
针对上述问题,在本申请一实施例中,在升级动态分区(Super)的过程中,在使用操作系统升级安装包中新版本的动态分区(Super)的分区信息刷新动态分区(Super)的/supermetadata的Slot信息之前,备份动态分区(Super)的/supermetadata的Slot信息。当动态分区(Super)升级成功(COW文件写入成功)时,丢弃备份的Slot信息;当动态分区(Super)升级失败(COW文件写入失败)时,使用备份的Slot信息恢复动态分区(Super)的/supermetadata的Slot信息。
图5所示为根据本申请一实施例的操作系统数据调配流程图。在S210所获取的操作系统升级安装包中,包含1.2版本的动态分区(Super)的分区信息,在S220成功执行之后,设备还执行如下步骤:
S501,读取动态分区(Super)的/supermetadata的Slot1信息,备份保存到common分区的metadata中(保存分区备份信息)。例如,保存到/metadata/ota/metadata_backup。
S502,从操作系统升级安装包中提取1.2版本的动态分区(Super)的分区信息(第一分区配置信息);
S503,使用1.2版本的动态分区(Super)的分区信息刷新动态分区(Super)的/supermetadata的Slot1信息;
在S503之后,执行S504,在用户数据分区(Userdata)写入动态分区(Super)的升级数据;S503以及S504的执行参照S230;
当S504执行成功时,执行S510,丢弃保存在common分区的metadata中的Slot1的备份信息(分区备份信息);在S510之后,执行S230之后的后续步骤;
当S504执行失败时,执行S520,使用保存在common分区的metadata中的Slot1的备份信息,恢复动态分区(Super)的/supermetadata的Slot1;例如,使用保存在common分区的metadata中的Slot1的备份信息,覆写动态分区(Super)的/supermetadata的Slot1中的数据;
S530,将静态分区(B)的状态标记设置为bootable;
S540,将静态分区(A)的数据同步到静态分区(B)。
S530以及S540的执行可以参照S310以及S320。
根据图5所示实施例的方法,可以在动态分区(Super)升级失败时确保设备后续可以从静态分区(B)顺利启动操作系统,从而大大提高操作系统启动的成功率,确保设备稳定运行,提高用户的设备使用体验。
进一步的,图5所示各个步骤的执行并不会影响到当前加载的静态分区(A)以及动态分区(Super)的操作系统数据。因此,图5所示各个步骤的执行过程中,用户可以正常使用设备;图5所示各个步骤可以后台执行,并不会对用户的正常手机操作产生影响,从而大大提高了用户体验。
可以理解的是,上述实施例中的部分或全部步骤或操作仅是示例,本申请实施例还可以执行其它操作或者各种操作的变形。此外,各个步骤可以按照上述实施例呈现的不同的顺序来执行,并且有可能并非要执行上述实施例中的全部操作。
进一步的,一般的,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field ProgrammableGate Array,FPGA))就是这样一种集成电路,其逻辑功能由访问方对器件编程来确定。由设计人员自行编程来把一个数字装置“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
因此,本申请实施例所提出的方法流程可以以硬件方式实现,例如,使用控制器,控制器控制触摸屏以实现本申请实施例所提出的方法流程。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
与上述实施例对应,本申请还提供了一种电子设备。电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发电子设备执行如本申请实施例所述的方法步骤。
本申请还提供一种计算机程序产品,计算机程序产品包括计算机程序,当其在计算机上运行时,使得计算机执行本申请实施例提供的部分或全部步骤。
本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
本说明书中各个实施例之间相同相似的部分互相参见即可。尤其,对于装置实施例和终端实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例中的说明即可。
Claims (14)
1.一种操作系统数据配置方法,其特征在于,应用于电子设备,所述电子设备包括处理器以及存储器,所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区;所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以启动第一操作系统;所述第一操作系统启动之后,所述方法包括:
将所述第二静态分区的状态标记设置为不可启动;
升级所述第二静态分区的数据;
当所述第二静态分区的数据升级失败时,将所述第二静态分区的状态标记设置为可启动,并且,将所述第一静态分区的数据同步到所述第二静态分区。
2.根据权利要求1所述的方法,其特征在于,当所述第二静态分区的数据升级失败时,将所述第一静态分区的数据同步到所述第二静态分区;
在将所述第一静态分区的数据同步到所述第二静态分区之后,将所述第二静态分区的状态标记设置为可启动。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
当所述第二静态分区的数据升级失败时,输出升级失败提示信息。
4.根据权利要求1所述的方法,其特征在于,当所述第二静态分区的数据升级失败时,后台执行所述将所述第二静态分区的状态标记设置为可启动的步骤,以及,后台执行所述将所述第一静态分区的数据同步到所述第二静态分区的步骤。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括,获取操作系统升级包;
所述升级所述第二静态分区的数据,包括,根据所述操作系统升级包升级所述第二静态分区的数据。
6.根据权利要求5所述的方法,其特征在于,所述操作系统升级包包含用于升级所述动态分区的动态分区升级数据,所述方法还包括:
当所述第二静态分区的数据升级成功时,根据所述操作系统升级包在所述用户数据分区中写入动态分区升级数据;
当所述动态分区升级数据写入失败时,将所述第二静态分区的状态标记设置为可启动,并且,将所述第一静态分区的数据同步到所述第二静态分区。
7.根据权利要求6所述的方法,其特征在于,所述方法还包括:
当所述动态分区升级数据写入失败时,输出升级失败提示信息。
8.根据权利要求6所述的方法,其特征在于,当所述动态分区升级数据写入失败时,后台执行所述将所述第二静态分区的状态标记设置为可启动的步骤。
9.根据权利要求6所述的方法,其特征在于,所述方法还包括:
当所述动态分区升级数据写入失败时,删除所述用户数据分区中已写入的动态分区升级数据。
10.根据权利要求6~9中任一项所述的方法,其特征在于,所述操作系统升级包还包含用于更新所述动态分区的分区配置的第一分区配置信息,所述方法还包括:
当所述第二静态分区的数据升级成功时,将所述动态分区的元数据中的分区信息备份为分区备份信息;
分区信息备份完成后,根据所述第一分区配置信息刷新所述动态分区的元数据中的分区信息;
当所述动态分区升级数据写入失败时,使用所述分区备份信息恢复所述动态分区的元数据中的分区信息。
11.根据权利要求6所述的方法,其特征在于,所述方法还包括:
当所述动态分区升级数据写入成功时,将所述第二静态分区的状态标记设置为可启动,修改所述电子设备的启动顺序为从所述第二静态分区启动;
重启所述电子设备,确认所述电子设备的启动顺序为从所述第二静态分区启动;
加载所述基础分区以及所述静态分区的数据;
加载所述动态分区的数据以及所述动态分区升级数据,启动所述第二操作系统;
将所述动态分区升级数据落盘到所述动态分区。
12.根据权利要求1所述的方法,其特征在于,所述方法还包括:
当所述第二静态分区的数据升级成功时,将所述第二静态分区的状态标记设置为可启动,修改所述电子设备的启动顺序为从所述第二静态分区启动。
13.一种电子设备,其特征在于,所述电子设备包括处理器以及存储器,所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区,所述处理器用于执行所述存储器上存储的软件代码,以使得所述电子设备启动后加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统;
并且,在所述第一操作系统运行之后,使得所述电子设备执行如权利要求1~12中任一项所述的方法流程。
14.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机程序,当其在计算机上运行时,使得计算机执行如权利要求1~12中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310144834.9A CN116149714A (zh) | 2021-07-29 | 2021-07-29 | 操作系统数据配置方法、设备、存储介质及程序产品 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110864145.6A CN114461257B (zh) | 2021-07-29 | 2021-07-29 | 操作系统数据配置方法、设备、存储介质及程序产品 |
CN202310144834.9A CN116149714A (zh) | 2021-07-29 | 2021-07-29 | 操作系统数据配置方法、设备、存储介质及程序产品 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110864145.6A Division CN114461257B (zh) | 2021-07-29 | 2021-07-29 | 操作系统数据配置方法、设备、存储介质及程序产品 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116149714A true CN116149714A (zh) | 2023-05-23 |
Family
ID=81406501
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110864145.6A Active CN114461257B (zh) | 2021-07-29 | 2021-07-29 | 操作系统数据配置方法、设备、存储介质及程序产品 |
CN202310144834.9A Pending CN116149714A (zh) | 2021-07-29 | 2021-07-29 | 操作系统数据配置方法、设备、存储介质及程序产品 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110864145.6A Active CN114461257B (zh) | 2021-07-29 | 2021-07-29 | 操作系统数据配置方法、设备、存储介质及程序产品 |
Country Status (1)
Country | Link |
---|---|
CN (2) | CN114461257B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116661812B (zh) * | 2022-11-25 | 2024-04-02 | 荣耀终端有限公司 | 设备升级方法、电子设备及系统 |
CN118151833A (zh) * | 2022-12-05 | 2024-06-07 | 荣耀终端有限公司 | 操作系统升级方法、设备和存储介质 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7117334B2 (en) * | 2004-05-14 | 2006-10-03 | International Business Machines Corporation | Dynamic node partitioning utilizing sleep state |
US9361122B2 (en) * | 2013-02-08 | 2016-06-07 | Htc Corporation | Method and electronic device of file system prefetching and boot-up method |
CN106293848A (zh) * | 2013-03-15 | 2017-01-04 | 青岛海信移动通信技术股份有限公司 | 一种系统升级的方法及装置 |
FR3031822B1 (fr) * | 2015-01-16 | 2018-04-13 | Airbus Operations | Telechargement de donnees sur un equipement distant |
US10521213B2 (en) * | 2015-12-17 | 2019-12-31 | Time Warner Cable Enterprises Llc | Technique for efficiently upgrading software in a video content network |
CN105511928B (zh) * | 2015-12-28 | 2019-07-26 | 努比亚技术有限公司 | 系统升级装置和方法 |
CN109408153B (zh) * | 2018-11-01 | 2022-03-01 | 百度在线网络技术(北京)有限公司 | 软件启动方法和软件升级方法 |
CN110543321A (zh) * | 2019-09-06 | 2019-12-06 | 深圳市英博超算科技有限公司 | Ota升级方法、装置、终端以及计算机可读存储介质 |
CN111694589B (zh) * | 2020-06-15 | 2023-09-29 | Oppo(重庆)智能科技有限公司 | 升级包生成方法、装置、服务器及计算机可读存储介质 |
CN112416359A (zh) * | 2020-11-23 | 2021-02-26 | 捷开通讯(深圳)有限公司 | 动态分区定制方法、装置、设备和计算机可读存储介质 |
CN112783537B (zh) * | 2020-12-31 | 2023-03-03 | 浙江万胜智能科技股份有限公司 | 基于MTD存储设备的嵌入式linux操作系统升级方法及系统 |
-
2021
- 2021-07-29 CN CN202110864145.6A patent/CN114461257B/zh active Active
- 2021-07-29 CN CN202310144834.9A patent/CN116149714A/zh active Pending
Also Published As
Publication number | Publication date |
---|---|
CN114461257B (zh) | 2023-03-24 |
CN114461257A (zh) | 2022-05-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2022262751A1 (zh) | 操作系统升级方法、设备、存储介质及计算机程序产品 | |
CN113821233B (zh) | 操作系统升级方法、设备、存储介质及计算机程序产品 | |
CN113821235B (zh) | 操作系统数据更新方法、设备、存储介质及程序产品 | |
US20230229424A1 (en) | Operating System Upgrade Method and Device, Storage Medium, and Computer Program Product | |
CN114116023B (zh) | 操作系统启动方法、设备、存储介质及计算机程序产品 | |
CN114461257B (zh) | 操作系统数据配置方法、设备、存储介质及程序产品 | |
US12093678B2 (en) | Operating system management method, device, storage medium, and computer program product | |
CN114489813B (zh) | 配置操作系统制式的方法、设备及存储介质 | |
CN113806139B (zh) | 操作系统恢复方法、设备、存储介质及计算机程序产品 | |
CN113821221A (zh) | 安装操作系统的方法、设备、存储介质及计算机程序产品 | |
CN113805956B (zh) | 操作系统的配置方法、设备及存储介质 | |
CN113900673B (zh) | 系统安装包的管理方法、设备、存储介质及程序产品 | |
CN115686644B (zh) | 配置操作系统制式的方法、设备及存储介质 | |
CN113821234A (zh) | 操作系统升级方法、设备、存储介质及计算机程序产品 | |
CN115562695A (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 |