CN113805914A - 操作系统升级方法、设备、存储介质及计算机程序产品 - Google Patents

操作系统升级方法、设备、存储介质及计算机程序产品 Download PDF

Info

Publication number
CN113805914A
CN113805914A CN202110661865.2A CN202110661865A CN113805914A CN 113805914 A CN113805914 A CN 113805914A CN 202110661865 A CN202110661865 A CN 202110661865A CN 113805914 A CN113805914 A CN 113805914A
Authority
CN
China
Prior art keywords
partition
data
static
operating system
version
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.)
Granted
Application number
CN202110661865.2A
Other languages
English (en)
Other versions
CN113805914B (zh
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 CN202110661865.2A priority Critical patent/CN113805914B/zh
Priority to CN202211229081.3A priority patent/CN115729586B/zh
Publication of CN113805914A publication Critical patent/CN113805914A/zh
Priority to US18/029,527 priority patent/US20240012652A1/en
Priority to EP22824228.5A priority patent/EP4202647A4/en
Priority to PCT/CN2022/098854 priority patent/WO2022262751A1/zh
Application granted granted Critical
Publication of CN113805914B publication Critical patent/CN113805914B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1417—Boot up procedures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例提供的一种操作系统升级方法、设备、存储介质及计算机程序产品，方法包括：运行第一操作系统；获取包括第一更新数据的第一系统升级安装包以及包括第二更新数据的第二系统升级安装包；在用户数据分区中保存第一更新数据以及第二更新数据；重启电子设备；加载基础分区、第二静态分区的数据；加载第一动态分区数据以运行第三操作系统，第二动态分区数据对应于第三动态分区数据与第二更新数据的叠加结果，第三动态分区数据对应于动态分区的数据与第一更新数据的叠加结果；将第一更新数据、第二更新数据落盘到动态分区。根据本申请的方法，可以满足操作系统升级场景中不同版本的操作系统的升级需求。

Description

操作系统升级方法、设备、存储介质及计算机程序产品
技术领域
本申请涉及计算机技术领域，具体地涉及一种操作系统升级方法、设备、存储介质及计算机程序产品。
背景技术
在现有技术的应用场景中，用户终端需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。
在终端设备安装操作系统后，当操作系统出现版本升级时，需要升级终端设备上所安装的操作系统。一般的，操作系统的版本会定期或不定期的多次升级。例如，从版本1.1升级到版本1.2；从版本1.2升级到版本1.3；从版本1.3升级到版本1.4。
为了使设备的操作系统为最新的版本，因此，就需要在发布新版本的操作系统时，更新终端设备上所安装的操作系统，使得终端设备上的操作系统升级到最新的版本。
然而，在实际应用场景中，并不是所有的用户都将自身的设备的操作系统与操作系统的版本发布进行同步升级的，这就会导致在某一版本的操作系统被发布后，同时存在多种不同的版本升级需求。例如，在版本1.2的操作系统被发布后，某些用户并未将自身设备上版本1.1的操作系统升级到版本1.2；在此之后，版本1.3的操作系统被发布，此时就存在由版本1.1的操作系统升级到版本1.2的升级需求以及由版本1.2的操作系统升级到版本1.3的升级需求。因此，就需要一种针对不同版本升级需求的操作系统升级方法。
发明内容
有鉴于此，本申请提供一种操作系统升级方法、设备、存储介质及计算机程序产品，以利于解决现有技术中不同版本的旧版本操作系统升级到最新版本的操作系统的问题。
第一方面，本申请实施例提供了一种操作系统升级方法，应用于电子设备，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述方法包括：
加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统；
获取第一系统升级安装包以及第二系统升级安装包，其中，所述第一系统升级安装包包括用于更新所述动态分区的数据的第一更新数据，所述第一系统升级安装包用于将所述第一操作系统升级到第二操作系统，所述第二系统升级安装包包括用于更新所述动态分区的数据的第二更新数据，所述第二系统升级安装包用于将所述第二操作系统升级到第三操作系统；
在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述第一更新数据以及所述第二更新数据；
将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动；
加载所述基础分区的数据；
加载所述第二静态分区的数据；
加载第一动态分区数据以运行所述第三操作系统，其中，所述第一动态分区数据为第二动态分区数据的全部或一部分，所述第二动态分区数据对应于第三动态分区数据与所述第二更新数据的叠加结果，所述第三动态分区数据对应于所述动态分区的数据与所述第一更新数据的叠加结果；
将所述第一更新数据落盘到所述动态分区；
将所述第二更新数据落盘到所述动态分区。
在第一方面的一种实现方式中：
所述在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述第一更新数据以及所述第二更新数据，包括：将所述第一更新数据以及所述第二更新数据以COW文件的形式保存在所述用户数据分区中；
所述加载第一动态分区数据以运行所述第三操作系统，包括，基于快照技术加载所述动态分区的数据、所述第一更新数据的COW文件以及所述第二更新数据的COW文件。
在第一方面的一种实现方式中，所述第一系统升级安装包还包括第一静态分区全量数据，所述第二系统升级安装包还包括第二静态分区全量数据；
所述重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动之前，所述方法还包括：将所述第二静态分区全量数据覆写到所述第二静态分区。
在第一方面的一种实现方式中，所述加载所述第二静态分区的数据之前，所述方法还包括，将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，所述第一系统升级安装包还包括第一静态分区更新数据，所述第二系统升级安装包还包括第二静态分区更新数据；
所述重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动之前，所述方法还包括：基于所述第一静态分区更新数据，将所述第二静态分区的数据由所述第一操作系统的静态分区数据升级为所述第二操作系统的静态分区数据；基于所述第二静态分区更新数据，将所述第二静态分区的数据由所述第二操作系统的静态分区数据升级为所述第三操作系统的静态分区数据；
在所述基于所述第一静态分区更新数据，将所述第二静态分区的数据由所述第一操作系统的静态分区数据升级为所述第二操作系统的静态分区数据之前，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
读取所述第一静态分区的各个子分区中的数据；
将所述第一静态分区的各个子分区中的数据覆写到所述第二静态分区对应的子分区中。
在第一方面的一种实现方式中，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
计算第三子分区的数据的哈希值，其中，所述第三子分区为所述第一静态分区的一个子分区；
计算第四子分区的数据的哈希值，其中，所述第四子分区为所述第二静态分区的一个子分区，并且，所述第四子分区与所述第三子分区相对应；
当所述第三子分区的数据的哈希值与所述第四子分区的数据的哈希值不一致时，将所述第三子分区中的数据覆写到所述第四子分区中。
在第一方面的一种实现方式中，所述获取第一系统升级安装包以及第二系统升级安装包之前，所述方法还包括：
加载所述基础分区、所述第二静态分区以及所述动态分区的数据以运行第四操作系统；
获取第三系统升级安装包，其中，所述第三系统升级安装包包括静态分区升级数据，所述第三系统升级安装包用于将所述第四操作系统升级到第一操作系统；
根据所述第三系统升级安装包的静态分区升级数据，升级所述第一静态分区的数据；
将所述电子设备的启动顺序由从所述第二静态分区启动，修改为从所述第一静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动；
加载所述基础分区的数据；
加载所述所述第一静态分区的数据；
加载第四动态分区数据以运行所述第一操作系统；
其中，在所述重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
第二方面，本申请提供一种操作系统升级方法，应用于电子设备，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述方法包括：
加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统；
获取第一系统升级安装包以及第二系统升级安装包，其中，所述第一系统升级安装包包括用于更新所述动态分区的数据的第一更新数据，所述第一系统升级安装包用于将所述第一操作系统升级到第二操作系统，所述第二系统升级安装包包括用于更新所述动态分区的数据的第二更新数据，所述第二系统升级安装包用于将所述第二操作系统升级到第三操作系统；
在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存第三更新数据，其中，所述第三更新数据为所述第一更新数据与所述第二更新数据的合成数据；针对所述第一更新数据与所述第二更新数据中指向同一文件的数据，在所述第三更新数据中保留其中的所述第二更新数据的数据；
将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动；
加载所述基础分区的数据；
加载所述第二静态分区的数据；
加载第一动态分区数据以运行所述第三操作系统，其中，所述第一动态分区数据为第二动态分区数据的全部或一部分，所述第二动态分区数据对应于所述动态分区的数据与所述第三更新数据的叠加结果；
将所述第三更新数据落盘到所述动态分区。
第三方面，本申请提供一种电子设备，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如第一方面所述的方法流程。
第四方面，本申请提供一种电子设备，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如第二方面所述的方法流程。
第五方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第一方面或第二方面所述的方法。
第六方面，本申请提供一种计算机程序产品，所述计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如第一方面或第二方面所述的方法。
根据本申请实施例所提出的上述技术方案，至少可以实现下述技术效果：
根据本申请实施例的方法，可以实现跨版本的操作系统升级，从而解决操作系统升级场景中，不同版本的旧版本系统升级到最新版本的操作系统的问题。根据本申请实施例的方法，可以有效降低新版本操作系统发布时，所需发布的操作系统升级包的版本数，大大降低发布的操作系统升级包的工作量。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
图1所示为根据本申请一实施例的操作系统升级流程图；
图2所示为根据本申请一实施例的数据存储结构示意图；
图3所示为根据本申请一实施例的操作系统升级的流程图；
图4所示为根据本申请一实施例的数据存储结构示意图；
图5所示为根据本申请一实施例进行操作系统升级的流程图；
图6所示为根据本申请一实施例进行操作系统升级的数据结构变化示意图；
图7a所示为根据本申请一实施例进行操作系统升级的流程图；
图7b所示为根据本申请一实施例的数据存储结构示意图；
图7c所示为根据本申请一实施例的数据存储结构示意图；
图7d所示为根据本申请一实施例的数据存储结构示意图
图7e所示为根据本申请一实施例的数据存储结构示意图；
图8a所示为根据本申请一实施例进行操作系统升级的流程图；
图8b所示为根据本申请一实施例的数据存储结构示意图；
图9所示为根据本申请一实施例的静态分区数据变化示意图；
图10a所示为根据本申请一实施例的数据存储变化示意图；
图10b所示为根据本申请一实施例的数据存储变化示意图；
图11所示为根据本申请一实施例的操作系统升级的流程图；
图12a所示为根据本申请一实施例的数据存储变化示意图；
图12b所示为根据本申请一实施例的数据存储变化示意图；
图12c所示为根据本申请一实施例的数据存储变化示意图；
图13所示为根据本申请一实施例的静态分区同步流程图；
图14所示为根据本申请一实施例的静态分区同步流程图；
图15所示为根据本申请一实施例的静态分区同步流程图；
图16所示为根据本申请一实施例的操作系统升级的流程图；
图17所示为根据本申请一实施例的操作系统升级的流程图。
具体实施方式
为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。
应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
针对操作系统升级，一种可行的方案是采用全量升级方案，更新所有的操作系统数据，重新安装操作系统，这样，无需考虑原有的操作系统版本，只需要将所有的操作系统数据替换为最新版本的操作系统数据即可。
例如，在获取到最新版本的操作系统安装包后，退出当前操作系统的运行状态，进入恢复(Recovery)模式，在恢复(Recover)模式下对设备上的操作系统数据进行全体覆写，重新安装操作系统。
图1所示为根据本申请一实施例的操作系统升级流程图。假设终端设备当前运行的操作系统版本是1.1，需要升级到版本1.3。终端设备按照如图1所示的流程实现操作系统的升级。
S100，终端设备正常运行在版本1.1的操作系统下，获取版本1.3的操作系统的升级安装包；
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否存在更新版本号的操作系统安装包(例如版本1.3)；当存在更新版本的操作系统安装包时，搜包服务器向设备反馈最新版本的操作系统安装包(例如，版本1.3的操作系统安装包)的下载地址；设备根据操作系统升级安装包的下载地址下载操作系统安装包。
S110，终端设备重启；
S120，重启后的终端设备并不通过版本1.1操作系统启动，而是进入Recovery模式；
S130，在Recovery模式下，终端设备使用版本1.3的操作系统安装包在终端设备上重新安装操作系统；
具体的，终端设备从版本1.3的操作系统安装包中提取版本1.3的操作系统数据，使用版本1.3的操作系统数据覆写终端设备上原有的操作系统数据(版本1.3的操作系统数据)；在S130中，终端设备使用版本1.3的操作系统数据覆写终端设备上原有的操作系统数据时，不需要考虑终端设备上原有的操作系统数据的版本，例如，终端设备上原有的操作系统数据的版本可以为1.0、1.1或者1.2，在使用版本1.3的操作系统数据进行数据覆写后，终端设备上操作系统数据均为版本1.3的操作系统数据；
S140，系统升级完毕后，终端设备重启；
S150，重启后的终端设备通过版本1.3的操作系统启动。
在图1所示方案中，终端设备必须重启并进入Recovery模式才可以进行系统升级，在进入Recovery模式后，终端设备的大部分功能是无法使用的，也就是说，在终端设备的操作系统升级的过程中，用户只能等待终端设备进行系统文件的更新升级，而无法正常使用终端设备，这会大大降低用户体验。因此，在一种可行的操作系统升级方案中，不进入Recovery模式升级操作系统，采用A/B升级方案在终端设备正常运行时进行无感知升级。
图2所示为根据本申请一实施例的数据存储结构示意图。如图2所示，终端设备上的数据存储区分为基础分区(Common)、系统分区(A)、系统分区(B)以及用户数据分区(Userdata)四个部分。其中，用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础部分中保存的数据为不参与操作系统升级的系统数据，例如，安卓系统数据中的基础(Common)分区。系统分区(A)与系统分区(B)相互独立，其上分别保存有完整的操作系统数据。例如，系统分区(A)以及系统分区(B)均包括静态分区(bootloader、boot、vendor_boot、dtbo、vbmeta)以及动态分区(super)super。如图2所示，系统分区(A)包括静态分区(A)以及动态分区(Super)(A)，系统分区(B)包括静态分区(B)以及动态分区(Super)(B)
图3所示为针对图2所示实施例的终端设备存储结构进行操作系统升级的流程图。假设系统分区(A)保存的操作系统数据对应的操作系统版本为1.1。终端设备从系统分区(A)启动从而运行版本1.1的操作系统。如果当前需要升级到版本1.3的操作系统。终端设备按照如图3所示的流程实现操作系统的升级。
S300，终端设备加载基础分区(Common)、系统分区(A)，从系统分区(A)启动，从而运行版本1.1的操作系统；
S310，终端设备获取版本1.3操作系统的操作系统安装包；
S320，终端设备将版本1.3的操作系统安装包中的操作系统数据覆写到系统分区(B)，将版本1.3的操作系统安装到系统分区(B)；
在S320中，由于操作系统数据的写入操作是针对系统分区(B)进行的，其并不会影响到系统分区(A)的数据，因此，在整个操作系统升级的过程中，用户可以正常使用终端设备。
S330，终端设备重启；
在S320之后，由于系统分区(A)的数据并未发生变化，因此，终端设备并不需要立即重启(不需要立刻执行S330)，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户使用终端设备产生影响，从而大大提高了用户体验。
S340，重启后的终端设备加载基础分区(Common)、系统分区(B)，从系统分区(B)启动，从而运行版本1.3的操作系统，完成操作系统升级。
基于图2、图3所示方案，虽然可以实现在终端设备正常运行时进行无感知升级，但是，在终端设备正常使用时，在非升级状态下，系统分区(A)以及系统分区(B)中只有一个分区被使用，另一分区被闲置，这就导致了数据存储空间利用率不高，大大压缩了用户可自由使用的数据存储空间。因此，在一种可行的操作系统升级方案中，采用基于虚拟分区的A/B升级方案。
以安卓系统为例，图4所示为根据本申请一实施例的数据存储结构示意图。如图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)。
图5所示为针对图4所示实施例的操作系统数据存储结构进行操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图5所示的流程实现操作系统的升级。
S500，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
S510，设备获取操作系统升级安装包。
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否存在更新版本号的操作系统安装包(例如版本1.3)；当存在更新版本的操作系统安装包时，搜包服务器向设备反馈操作系统升级安装包(例如，由版本1.1升级到版本1.3的系统增量升级安装包)的下载地址；设备根据操作系统升级安装包的下载地址下载操作系统升级安装包。
S520，设备根据操作系统升级安装包针对静态分区(B)进行数据写入操作以升级静态分区。
例如，版本1.1升级到版本1.3的系统增量升级安装包包含版本1.3的静态分区的全量数据，设备将版本1.3的静态分区的数据覆写到静态分区(B)中。
S530，设备根据操作系统升级安装包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。例如，在操作系统升级安装包中包含版本1.3的动态分区的数据，设备在虚拟动态分区中写入版本1.3的动态分区(Super)的数据。
进一步的，在虚拟A/B升级方案中，针对动态分区(Super)，采用增量升级方式。在升级过程中，用户数据分区(Userdata)的虚拟动态分区中保存的并不是升级后新版本的动态分区(Super)的全部文件，而是旧版本的动态分区(Super)中需要升级的数据在升级后的升级结果。即，用户数据分区(Userdata)的虚拟动态分区中保存的是动态分区的更新数据。
以system子分区为例，假设在版本1.1中，system子分区中的数据可以分为system1、system2两部分。从版本1.1升级到版本1.3，数据system2没有发生变化，数据syetem1被升级为system3。那么，在S530中，设备在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中写入数据system3。
例如，版本1.1升级到版本1.3的系统增量升级安装包包含版本1.1升级到版本1.3的动态分区(Super)更新数据，该动态分区(Super)更新数据包含数据system3。
进一步的，在虚拟A/B升级方案中，基于快照技术(snapshot)实现动态分区(Super)的增量升级。具体的，用户数据分区(Userdata)的虚拟动态分区中，采用写时拷贝(Copy-On-Write，COW)文件保存动态分区(Super)的升级数据。
具体的，用户数据分区(Userdata)中保存的动态分区(Super)的升级数据包含多个COW文件，每个COW文件对应一个动态分区(Super)的子分区，COW文件的命名与其所针对的动态分区(Super)子分区相对应。
在S510所获取的操作系统升级安装包中，动态分区(Super)的升级数据的COW文件以二进制代码形式压缩保存。在操作系统升级安装包中，每个COW文件根据其所针对的动态分区(Super)子分区所命名。例如，针对system子分区的COW文件被命名为system-cow-img.img.0000。
在S530中，设备解包操作系统升级安装包以获取所有的COW文件，为每个COW文件附加A/B分区标记。具体的，当设备当前从静态分区(A)启动时，可以理解为设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时，用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。因此，为COW文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
进一步的，在S530中，在用户数据分区(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文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时，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地址段的数据)。
当COW文件中的更新数据的大小与其所要更新的原始数据的大小不一致时，COW文件(system_b-cow-img.img.0000)自身的COW文件地图可以为：
/system/app/A2.XXX：
Map1.1(原super分区中待更新数据的地址)：起始地址address start：024018(相对于system起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)
Map2.1(cow文件中存储的，需要覆盖Map1.1地址的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；
Map1.2(cow文件中更新数据超出待更新数据大小的那一部分在原super分区中的待写入地址)：起始地址address start：025018(相对于system起始地址的偏移量)；偏移量大小size：1(即025018～025020地址段的数据)
Map2.2(cow文件中存储的，需要覆盖Map1.2地址的更新数据的地址)：起始地址address start：046033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即046033～046035地址段的数据)。
在接下来的说明书描述中，为便于描述，仅以当COW文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致的应用场景进行举例说明。
在上述例子中，地址段(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子分区的数据升级。
进一步的，在S530中，在将COW文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+COW文件进行整体校验，校验动态分区(Super)+COW文件的有效性，验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super)数据。
具体的，以从1.1版本升级到1.3版本为例，计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.3未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.3需要升级的数据)的合成结果的哈希值，判断该哈希值与1.3版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明COW文件有效；如果不一致，则说明COW文件无效，升级失败，中断升级进程并报错；其中，1.3版本中动态分区(Super)的完整数据的哈希值被保存在操作系统升级安装包中。
具体的，在校验过程中，基于snapshot合并动态分区(Super)+COW文件。在snapshot的实现过程中，动态分区(Super)与COW文件的合并并不是物理意义上的合并，而是将COW文件中子分区的整体文件地图与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：
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子分区的新版本的文件地图：
/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文件有效时，将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的COW文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for merge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for merge)”时，代表该子分区需要进行落盘操作。
S531，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。
例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B。在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)。
S532，设备重启。退出当前的操作系统，切断设备电源，再次开启设备电源。
S540，设备依次加载基础分区(Common)、静态分区(B)。
S541，设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。
具体的，设备读取元数据(/metadata)中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索COW文件，并采用snapshot合并加载动态分区(Super)以及COW文件。
进一步的，在S541中，设备并不加载动态分区(Super)以及用户数据分区(Userdata)中的全部COW文件，而是根据操作系统运行需求加载对应的文件。具体的，在S541中，设备根据操作系统运行需求确定需要加载的文件，基于snapshot从动态分区(Super)或虚拟动态分区中的COW文件中提取对应的文件进行加载。
具体的，在S541中，当动态分区(Super)的子分区首存在对应的COW文件时，先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照S530。设备根据操作系统运行需求确定需要加载的文件，基于动态分区(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文件写入错误或者落盘状态信息写入错误)，此时设备回滚系统并报错。
进一步的，在S541中，在加载文件之前，设备还需要对加载文件进行校验。不同于S530，在S541中，不对动态分区(Super)+COW文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验(dm-verity是dm(device mapper)的一个目标(target)，是一个虚拟块设备，专门用于文件系统的校验)。校验成功则加载文件，校验失败则重启设备，回滚系统或者尝试再次加载文件。
S550，设备成功启动，进入用户交互界面。
S551，设备将虚拟动态分区的数据落盘到动态分区(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)”。
在S520中，静态分区升级的数据操作是针对静态分区(B)中的操作系统数据的，其并不会影响到当前启动的静态分区(A)的操作系统数据；并且，在S530中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前挂载的动态分区(Super)。因此，在整个操作系统升级的过程中，用户可以正常使用设备；并且，在S531完成后，设备并不需要立即重启，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。进一步的，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。
进一步的，在图5所示升级流程中，针对静态分区，采用全量升级的方式，即，操作系统升级安装包中包含静态分区的完整数据，在S520中，将操作系统升级安装包中的静态分区的完整数据覆写到静态分区(B)(更新静态分区(B)中的所有数据)。
而针对动态分区(Super)，采用了增量升级的方式。
在本申请实施例中，增量升级指的是，在旧版本数据的基础上，更新旧版本数据中的一部分数据以得到新版本的操作系统。例如，旧版本数据包含S1、S2、S3、S4四个部分，升级到新版本后，旧版本数据包含S1、S5、S3、S6四个部分。相较于旧版本数据，新版本数据中，将S2更新为S5，将S4更新为S6，S1以及S4并未变化。因此，在增量升级时，升级包只需包含S5、S6以及S5、S6与S2、S4的对应关系，而不需要包括完整的新版本数据，这就有效控制了升级包的数据量。
由于不同版本间的操作系统数据之间的差异是不同的，因此，基于增量升级的实现逻辑，采用增量升级的升级包只能针对固定版本的操作系统进行升级。具体的，假设将版本1.1的操作系统升级到版本1.3，那么在S510中，设备所获取操作系统升级安装包是对应由版本1.1升级到版本1.3的。具体的，操作系统升级安装包中包含版本1.1升级到版本1.3的动态分区(Super)的更新数据。而假设将版本1.2的操作系统升级到版本1.3，那么在S510中，设备所获取操作系统升级安装包是对应由版本1.2升级到版本1.3的。具体的，操作系统升级安装包中包含版本1.2升级到版本1.3的动态分区(Super)的更新数据。如果操作系统在版本1.1升级到版本1.2时，动态分区(Super)的数据也被更新，那么，版本1.1升级到版本1.3的动态分区(Super)的更新数据，与版本1.2升级到版本1.3的动态分区(Super)的更新数据，就是不同的数据。
例如，以system子分区为例，图6所示为根据本申请一实施例进行操作系统升级的数据结构变化示意图。如图6所示，假设在版本1.1中，system子分区中的数据可以分为system11、system21、system31三部分。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem11被升级为system12，数据syetem31被升级为system32。那么，在版本1.2中，system子分区中的数据可以分为system12、system21、system32三部分。在版本1.1升级到版本1.2的操作系统升级安装包中，就包含动态分区(Super)更新数据system12以及system32。从版本1.2升级到版本1.3，数据system12没有发生变化，数据syetem21被升级为system23，数据syetem32被升级为system33。那么，在版本1.3中，system子分区中的数据可以分为system12、system23、system33三部分。在版本1.2升级到版本1.3的操作系统升级安装包中，就包含动态分区(Super)更新数据system23以及system33。而如果跳过版本1.2，从版本1.1直接升级到版本1.3，则版本system11、system21、system31三部分均需要升级，在版本1.1升级到版本1.3的操作系统升级安装包中，就包含动态分区(Super)更新数据system12、system23以及system33。
这样，假设操作系统的初始版本为1.1，在版本1.2的操作系统被发布时，为了应对所有的版本升级需求，就需要发布版本1.1到版本1.2的系统增量升级安装包。在版本1.3的操作系统被发布时，为了应对所有的版本升级需求，就需要发布版本1.1到版本1.3、版本1.2到版本1.3的系统增量升级安装包。在版本1.4的操作系统被发布时，为了应对所有的版本升级需求，就需要发布版本1.1到版本1.4、版本1.2到版本1.4、版本1.3到版本1.4的系统增量升级安装包。随着版本的更新，每次版本更新时需要发布的系统增量升级安装包的个数也不断增加，这就会不断增加升级包发布的工作量以及升级包服务器的数据存储压力。
针对上述问题，本申请一实施例提供了一种升级操作系统的方法。基于本申请实施例升级操作系统的方法，在发布新版本的操作系统时，不需要针对之前的每一个操作系统版本分别发布系统增量升级安装包，而只需针对上一个操作系统版本发布系统增量升级安装包。系统增量升级安装包中包含静态分区的全量数据以及动态分区的更新数据。
根据本申请实施例的方法，可以实现跨版本的操作系统升级，从而解决操作系统升级场景中，不同版本的旧版本系统升级到最新版本的操作系统的问题。根据本申请实施例的方法，可以有效降低新本本操作系统发布时，所需发布的操作系统升级包的版本数，大大降低发布的操作系统升级包的工作量。
图7a所示为针对图4所示实施例的操作系统数据存储结构进行操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图7a所示的流程实现操作系统的升级。
S700，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
以图6所示的system子分区为例，启动后的操作系统数据存储结构中的数据如图7b中左图所示。
S710，设备获取当前版本的操作系统到最新版本的操作系统的所有系统增量升级安装包。
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否已发布更新版本号的操作系统安装包(例如版本1.3)；当存在更新版本的操作系统时，搜包服务器向设备反馈设备当前运行的操作系统的版本号到最新版本号之间的所有系统增量升级安装包(例如，由版本1.1升级到版本1.2以及由版本1.2升级到版本1.3的系统增量升级安装包)的下载地址；设备根据操作系统升级安装包的下载地址下载系统增量升级安装包并保存到用户数据分区(Userdata)。版本1.1为第一操作系统，版本1.2为第二操作系统，版本1.3为第三操作系统。
具体的，以system子分区为例，版本1.1升级到版本1.2的系统增量升级安装包(第一系统升级安装包)包含版本1.2的静态分区全量数据以及版本1.1升级到版本1.2的动态分区(Super)更新数据(第一更新数据)(例如，图6所示的system12以及system32)；版本1.2升级到版本1.3的系统增量升级安装包(第二系统升级安装包)包含版本1.3的静态分区全量数据以及版本1.2升级到版本1.3的动态分区(Super)更新数据(第二更新数据)(例如，图6所示的system23以及system33)。
在S710之后，操作系统数据存储结构中的数据如图7b中右图所示。
S720，设备从针对最新版本的操作系统升级安装包中提取最新版本的静态分区全量数据，根据提取出的静态分区全量数据针对静态分区(B)进行数据写入操作以升级静态分区。
例如，设备从版本1.2升级到版本1.3的系统增量升级安装包中提取版本1.3的静态分区全量数据，设备将版本1.3的静态分区全量数据覆写到静态分区(B)中。
S730，设备在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中写入当前版本的操作系统到最新版本的操作系统的所有系统增量升级安装包中的动态分区(Super)更新数据。
例如，设备在虚拟动态分区中写入版本1.1升级到版本1.2的动态分区(Super)更新数据，以及，版本1.2升级到版本1.3的动态分区(Super)更新数据。
具体的，在S730中，在用户数据分区(Userdata)下创建文件目录Update1以及Update2。将版本1.1升级到版本1.2的系统增量升级安装包中的COW文件system-cow-img.img.0012改名为system_b-cow-img.img.0012(0012代表1.2版本)，保存到/Update1下；将版本1.2升级到版本1.3的系统增量升级安装包中的COW文件system-cow-img.img.0013改名为system_b-cow-img.img.0013(0013代表1.2版本)，保存到/Update2下。COW文件的命名以及COW文件的文件结构可以参照S530中的描述。
对动态分区(Super)+COW1+COW2文件进行整体校验，校验动态分区(Super)+COW1+COW2文件的有效性，验证当前版本的动态分区(Super)数据+COW1+COW2文件的合成结果是否为新版本的动态分区(Super)数据；具体的，根据COW1文件中版本1.1升级到版本1.2的动态分区(Super)更新数据，将设备当前动态分区(Super)的数据中升级到1.2版本未发生变化的数据与版本1.1升级到版本1.2的动态分区(Super)更新数据进行合并，构成1.2版本的动态分区(Super)数据；根据COW2文件中版本1.2升级到版本1.3的动态分区(Super)更新数据，将1.2版本的动态分区(Super)数据中升级到1.3版本未发生变化的数据与版本1.2升级到版本1.3的动态分区(Super)更新数据进行合并，构成1.3版本的动态分区(Super)数据；计算1.3版本的动态分区(Super)数据的哈希值，判断该哈希值与系统增量升级安装包中的1.3版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明COW文件有效；如果不一致，则说明COW文件无效，升级失败，中断升级进程并报错；其中，1.3版本中动态分区(Super)的完整数据的哈希值被保存在版本1.2升级到版本1.3的系统增量升级安装包中；1.2版本中动态分区(Super)的完整数据的哈希值被保存在版本1.1升级到版本1.2的系统增量升级安装包中。
例如，基于snapshot合并动态分区(Super)和/Update1下的COW文件，生成1.2版本的动态分区(Super)的文件系统；根据1.2版本的动态分区(Super)的文件系统和/Update2下的COW文件，生成1.3版本的动态分区(Super)的文件系统。根据1.3版本的动态分区(Super)的文件系统进行文件读取并计算哈希值。具体的，文件系统的生成可以参照S530。
例如，假设1.1版本的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/A2.XXX：024018～024020指向的文件为图6所示的system31；
/system/user/C1.XXX：024033～024035指向的文件为图6所示的system11；
/system/user/C2.XXX：024036～024040指向的文件为图6所示的system21。
/Update1下1.1升级到1.2版本的COW文件(system_b-cow-img.img.0012)的COW文件地图为：
/system/app/A2.XXX：
Map1：address start：024018；size：2(即024018～024020地址段的数据)
Map2：address start：045033；size：2(即045003～045005地址段的数据)；
/system/user/C1.XXX：
Map1：address start：024033；size：2(即024033～024035地址段的数据)
Map2：address start：045006；size：2(即045006～045008地址段的数据)。
可以视为：
/system/app/A2.XXX：045003～045005指向的文件为图6所示的system32；
/system/user/C1.XXX：045006～045008指向的文件为图6所示的system12。
/Update2下1.2升级到1.3版本的COW文件(system_b-cow-img.img.0013)的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/app/A2.XXX：045033～045035指向的文件为图6所示的system33；
/system/user/C2.XXX：045036～045040指向的文件为图6所示的system23。
基于snapshot合并1.1版本的system子分区的文件地图与system_b-cow-img.img.0012，得到1.2版本的system子分区的文件地图为：
/system/app/A0.XXX：024010～024013；
/system/app/A1.XXX：024014～024017；
/system/app/A2.XXX：045003～045005；
(指向用户数据分区(Userdata)中/Update1/system_b-cow-img.img.0012中的A2.XXX)
/system/B0.XXX：024021～024026；
/system/B1.XXX：024027～024028；
/system/user/C0.XXX：024029～024032；
/system/user/C1.XXX：045006～045008；
(指向用户数据分区(Userdata)中/Update1/system_b-cow-img.img.0012中的C1.XXX)
/system/user/C2.XXX：024036～024040；
/system/user/C3.XXX：024041～024044。
基于snapshot合并1.1版本的system子分区的文件地图与system_b-cow-img.img.0012，得到1.2版本的system子分区的文件地图为：
/system/app/A0.XXX：024010～024013；
/system/app/A1.XXX：024014～024017；
/system/app/A2.XXX：045033～045035；
(指向用户数据分区(Userdata)中/Update2/system_b-cow-img.img.0013中的A2.XXX)
/system/B0.XXX：024021～024026；
/system/B1.XXX：024027～024028；
/system/user/C0.XXX：024029～024032；
/system/user/C1.XXX：045006～045008；
(指向用户数据分区(Userdata)中/Update1/system_b-cow-img.img.0012中的C1.XXX)
/system/user/C2.XXX：045036～045040；
(指向用户数据分区(Userdata)中/Update2/system_b-cow-img.img.0013中的C2.XXX)
/system/user/C3.XXX：024041～024044。
当COW文件有效时，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)(Update1、Update2)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的COW文件，以及，未落盘的COW文件对应的版本。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for merge)(Update1、Update2)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作，并且，落盘操作为两个版本，分别对应用户数据分区(Userdata)的文件目录Update1以及Update2；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(waitfor merge)(Update1)”时，代表该子分区在对应Update1目录的落盘操作中需要进行落盘操作；当子分区标识为“未落盘(wait for merge)(Update2)”时，代表该子分区在对应Update2目录的落盘操作中需要进行落盘操作；当子分区标识为“未落盘(wait for merge)(Update1、Update2)”时，代表该子分区在对应Update1、Update2目录的落盘操作中需要进行落盘操作。
进一步的，在S730之后，删除用户数据分区(Userdata)中的所有系统增量升级安装包。或者，在后续的某个步骤之后删除用户数据分区(Userdata)中的所有系统增量升级安装包。
在S730之后，操作系统数据存储结构中的数据如图7c中所示。
S731，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。
例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B。在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)。
S732，设备重启。退出当前的操作系统，切断设备电源，再次开启设备电源。
S740，设备依次加载基础分区(Common)、静态分区(B)。
S741，设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。具体的，设备基于snapshot合并加载动态分区(Super)以及虚拟动态分区中的COW文件。合并加载过程可以参照S541，区别在于，在S741中，基于版本由低到高的顺序多次合并COW文件，每次合并1个COW文件。
例如，在一种实现方式中，首先在设备动态分区(Super)当前数据(版本1.1)的基础上，叠加版本1.1升级到版本1.2的COW文件，生成版本1.2动态分区(Super)数据的文件系统；然后在版本1.2动态分区(Super)数据的文件系统的基础上，叠加版本1.2升级到版本1.3COW文件，生成版本1.3动态分区(Super)数据的文件系统；最后根据操作系统运行需求确定需要加载的文件，基于基于版本1.3动态分区(Super)数据的文件系统提取对应的文件进行加载。
例如，操作系统运行需求加载system子分区下目录user(/system/user)中的所有数据。设备读取元数据(/metadata)中的落盘状态信息，落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)(Update1，Update2)”，因此，设备首先在用户数据分区(Userdata)中/Update1下搜索COW文件，在Update1下搜索到COW文件system_b-cow-img.img.0012(第一更新数据)后，基于snapshot，根据system_b-cow-img.img.0012中的COW文件的文件地图生成system子分区的1.2版本(第三动态分区数据)的文件地图。
设备然后在用户数据分区(Userdata)中/Update2下搜索COW文件，在Update2下搜索到COW文件system_b-cow-img.img.0013(第二更新数据)后，基于snapshot，根据system_b-cow-img.img.0013中的COW文件的文件地图生成system子分区的1.3版本(第二动态分区数据)的文件地图。
按照system子分区的1.3版本的文件地图中/system/user下所有文件(第一动态分区数据)的保存地址进行数据加载。
进一步的，在S741中，在加载文件之前，设备还需要对加载文件进行校验。校验方案可以参照S541。
S750，设备成功运行操作系统，进入用户交互界面。
S751，设备将虚拟动态分区的数据落盘到动态分区(Super)。参照S551。
具体的，设备在启动成功后进行开机广播，开机广播后开启升级进程。升级进程读取基础分区(Common)的元数据(/metadata)中的落盘状态信息，如果落盘状态信息为“已落盘(merged)”，则设备进入正常运行模式。
如果落盘状态信息为“未落盘(wait for merge)”，升级进程读取动态分区(Super)的元数据(/supermetadata)中的COW块信息，将用户数据分区(Userdata)中的COW文件落盘到动态分区(Super)中。
具体的，升级进程将用户数据分区(Userdata)中的COW文件按照版本号由旧到新的次序，依次将COW文件落盘到动态分区(Super)。
例如，以system子分区为例，首先将/Update1下system_b-cow-img.img.0012落盘到动态分区(Super)的system子分区，使用system12以及system32覆写system11以及system31。如图7d中左图所示。落盘执行流程可以参照S551。
然后将/Update2下system_b-cow-img.img.0013落盘到动态分区(Super)的system子分区，使用system23以及system33覆写system21以及system32。如图7d中右图所示。落盘执行流程可以参照S551。
在此之后升级进程删除用户数据分区(Userdata)中的COW文件，删除用户数据分区(Userdata)中的系统增量升级安装包，将存储空间归还给用户数据分区(Userdata)；并且，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait formerge)”改为“已落盘(merged)”。
在S751之后，操作系统数据存储结构中的数据如图7e中所示。
图8a所示为针对图4所示实施例的操作系统数据存储结构进行操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图8a所示的流程实现操作系统的升级。
S800，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
以图6所示的system子分区为例，启动后的操作系统数据存储结构中的数据如图8b中左图所示。
S810，参照S710。
S820，参照S720。
S830，设备在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中写入当前版本的操作系统到最新版本的操作系统的所有系统增量升级安装包中的动态分区(Super)更新数据的合成数据。
例如，设备将版本1.1升级到版本1.2的COW文件与版本1.2升级到版本1.3的COW文件合成，生成版本1.1升级到版本1.3的COW文件。在虚拟动态分区中写入版本1.1升级到版本1.3的动态分区(Super)更新数据。具体的，在COW文件合成的过程中，对于不同COW文件中对应同一原始数据的更新数据，保留最新版本的更新数据。
例如，以system子分区为例，在用户数据分区(Userdata)下创建文件目录Update1以及Update2。将版本1.1升级到版本1.2的系统增量升级安装包中的COW文件system-cow-img.img.0012改名为system_b-cow-img.img.0012(0012代表1.2版本)，保存到/Update1下；将版本1.2升级到版本1.3的系统增量升级安装包中的COW文件system-cow-img.img.0013改名为system_b-cow-img.img.0013(0013代表1.2版本)，保存到/Update2下。COW文件的命名以及COW文件的文件结构可以参照S530中的描述。
假设system_b-cow-img.img.0012的COW文件地图为：
/system/app/A2.XXX：045003～045005；
/system/user/C1.XXX：045006～045008。
system_b-cow-img.img.0013的COW文件地图为：
/system/app/A2.XXX：045033～045035；
/system/user/C2.XXX：045036～045040。
合并system_b-cow-img.img.0012以及system_b-cow-img.img.0013，在/system/app/A2.XXX：045003～045005与/system/app/A2.XXX：045033～045035中，保留最新版本的system_b-cow-img.img.0013中的/system/app/A2.XXX：045033～045035。合并后生成COW文件system_b-cow-img.img.0000(0000代表不存在多版本COW文件)，将system_b-cow-img.img.0000保存到用户数据分区(Userdata)下的目录Update，删除/Update1以及/Update2。例如，COW文件合并后，如图8b所示。
具体的，在合并过程中，可以维持COW文件中更新数据的保存位置不变，即，在system_b-cow-img.img.0000中的各个更新文件的保存位置与system_b-cow-img.img.0012以及system_b-cow-img.img.0013是一致的，区别在于，system_b-cow-img.img.0000的COW文件地图被更新，并且，低版本的更新文件被删除。
例如，system_b-cow-img.img.0000的COW文件地图为：
/system/app/A2.XXX：045033～045035；
(指向原始的system_b-cow-img.img.0013中的A2.XXX)
/system/user/C1.XXX：045006～045008；
(指向原始的system_b-cow-img.img.0012中的C1.XXX)
/system/user/C2.XXX：045036～045040。
(指向原始的system_b-cow-img.img.0013中的C2.XXX)
地址045003～045005上的数据被删除。
在合并过程中，还可以重构COW文件中更新数据的保存位置。
例如，system_b-cow-img.img.0000的COW文件地图为：
/system/app/A2.XXX：045073～045075；
/system/user/C1.XXX：045076～045078；
/system/user/C2.XXX：045079～045043。
地址045003～045005、045006～045008、045033～045035、045036～045040上的数据被删除。在合并COW文件后，S830～S851的执行可以参照S530～S551。
进一步的，在图7a以及图8a所示升级流程中，静态分区采用全量升级方式。在本申请另一实施例中，针对静态分区也采用增量升级方式。例如，如图9所示，假设在版本1.1的操作系统中，静态分区的各个子分区(bootloader、boot、vendor_boot、dtbo、vbmeta)的版本均为0.1；当操作系统由版本1.1升级到版本1.2时，bootloader、boot、vendor_boot中的数据未发生变化，dtbo、vbmeta的数据升级到了版本0.2；那么，版本1.1到版本1.2的静态分区的更新数据就包括版本0.2的dtbo、vbmeta数据。当操作系统由版本1.2升级到版本1.3时，bootloader、boot、vbmeta中的数据未发生变化，vendor_boot的数据由版本0.1升级到了版本0.2，dtbo的数据由版本0.2升级到了版本0.3；那么，版本1.2到版本1.3的静态分区的更新数据就包括版本0.2的vendor_boot数据以及版本0.3的dtbo数据。
进一步的，在虚拟A/B升级方案中，在静态分区的数据升级后，静态分区(A)与静态分区(B)的数据是不同的。在当前加载静态分区(B)时，如果是静态分区数据全量升级，则可以直接将最新版本的静态分区全量数据覆写到静态分区(A)，而如果是增量升级，由于静态分区(A)与静态分区(B)的数据不同，针对静态分区(B)上数据的增量数据覆写到静态分区(B)之后，可能会导致数据混乱。
如图10a所示，设备加载(静态分区(A)+动态分区(Super))运行版本1.1的操作系统。此后设备的操作系统需要升级到版本1.2，设备基于静态分区全量升级在静态分区(B)中写入版本1.2的静态分区数据，完成版本1.1到版本1.2的操作系统升级。
如图10b所示，设备加载(静态分区(B)+动态分区(Super))运行版本1.2的操作系统。此后设备的操作系统需要升级到版本1.3，设备基于当前的操作系统版本(版本1.2)，获取版本1.2到版本1.3的系统增量升级安装包，版本1.2到版本1.3的系统增量升级安装包中包含版本1.2到版本1.3的静态分区更新数据。然后，之后设备在升级静态分区时，写入数据的操作对象是静态分区(A)，静态分区(A)上的数据并不是版本1.2，这就导致版本1.2到版本1.3的静态分区增量升级静态分区(A)后，得到静态分区数据(bootloader_a数据版本0.1、boot_a数据版本0.1、vendor_boot_a数据版本0.2、dtbo_a数据版本0.3、vbmeta_a数据版本0.1)并不是版本1.3的静态分区数据(bootloader_a数据版本0.1、boot_a数据版本0.1、vendor_boot_a数据版本0.2、dtbo_a数据版本0.3、vbmeta_a数据版本0.2)。
针对上述问题，在本申请一实施例中，在对静态分区的数据进行升级前，还执行静态分区数据同步操作，以使得两个静态分区的数据一致。
图11所示为针对图4所示实施例的操作系统数据存储结构进行操作系统升级的流程图。假设设备的初始操作系统版本为1.0，设备初始从静态分区(A)启动。基于图5所示的流程，设备的操作系统版本从1.0升级到了1.1，设备从静态分区(B)启动。在此之后，设备按照如图11所示的流程实现操作系统的升级。
S1100，设备依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。
以图9所示实施例为例，启动后的操作系统数据存储结构中静态分区、动态分区(Super)的数据如图12a中左图所示。
S1110，设备获取当前版本的操作系统到最新版本的操作系统的所有系统增量升级安装包。
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否已发布更新版本号的操作系统安装包(例如版本1.3)；当存在更新版本的操作系统时，搜包服务器向设备反馈设备当前运行的操作系统的版本号到最新版本号之间的所有系统增量升级安装包(例如，由版本1.1升级到版本1.2以及由版本1.2升级到版本1.3的系统增量升级安装包)的下载地址；设备根据操作系统升级安装包的下载地址下载系统增量升级安装包并保存到用户数据分区(Userdata)。
具体的，版本1.1升级到版本1.2的系统增量升级安装包包含版本1.1升级到版本1.2的静态分区更新数据(例如，图9所示的版本0.2的dtbo、vbmeta数据)以及版本1.1升级到版本1.2的动态分区(Super)更新数据；版本1.2升级到版本1.3的系统增量升级安装包包含版本1.2升级到版本1.3的静态分区更新数据(例如，图9所示的版本0.2的vendor_boot数据以及版本0.3的dtbo数据)以及版本1.2升级到版本1.3的动态分区(Super)更新数据。
在S1110之后，操作系统数据存储结构中的数据如图12a中间图所示。
S1111，设备将静态分区(B)的数据同步到静态分区(A)。
在S1111之后，操作系统数据存储结构中的数据如图12a中右图所示。
S1120，设备按照版本号从旧到新的次序，依次从操作系统升级安装包中提取静态分区更新数据，并将静态分区更新数据依次写入到静态分区(A)。
具体的，设备首先从版本1.1升级到版本1.2的系统增量升级安装包中提取版本1.1升级到版本1.2的静态分区更新数据；
将版本1.1升级到版本1.2的静态分区更新数据写入到静态分区(A)。例如，将版本0.2的dtbo、vbmeta数据覆写到静态分区(A)的dtbo_a、vbmeta_a子分区中。如图12b所示。
然后，设备从版本1.2升级到版本1.3的系统增量升级安装包中提取版本1.2升级到版本1.3的静态分区更新数据，将版本1.2升级到版本1.3的静态分区更新数据写入到静态分区(A)。例如，将版本0.2的vendor_boot数据覆写到静态分区(A)的vendor_boot_a子分区中，将版本0.3的dtbo数据覆写到静态分区(A)的dtbo_a子分区中。如图12c所示。
S1130，参照S730。
S1131，将设备的启动顺序由从静态分区(B)启动变更为从静态分区(A)启动。具体的，改写common分区中的启动标识，将启动标识由B改写为A。
S1132，设备重启。退出当前的操作系统，切断设备电源，再次开启设备电源。
S1140，设备依次加载基础分区(Common)、静态分区(A)。
S1141～S1151，参照S741～S751。
进一步的，本申请对S1111的具体实现方式不做具体限制，本领域的技术人员可以采用多种可行的实现方式实现S1111。以下通过具体实施例举例说明S1111的具体实现流程。
在S520中，设备将操作系统升级安装包中的静态分区的数据写入到静态分区(B)。因此，如果使用同样的操作系统升级安装包，将操作系统升级安装包中的静态分区的数据写入到静态分区(A)中，就会使得静态分区(A)中的数据与静态分区(B)中的数据一致。
因此，在一应用场景中，S1111包括：获取从用户数据分区(Userdata)中读取S510中所保存的操作系统升级安装包，将操作系统升级安装包中的静态分区的数据写入到静态分区(A)中。
静态分区(A)与静态分区(B)在分区结构以及分区大小上是完全一致的。因此，可以直接将静态分区(A)的数据镜像到静态分区(B)，或者，将静态分区(B)的数据镜像到静态分区(A)。
图13所示为S1111的一种实现方式的流程图。终端设备执行如图13所示的下述流程以实现S1111。
S1400，将静态分区(B)中的所有数据读出，打包压缩后制作为镜像文件B；
S1410，将镜像文件B解包后恢复到静态分区(A)，从而实现将静态分区(B)的数据覆写到静态分区(A)。
静态分区(A)与静态分区(B)在分区结构上是一致的，其包含相同的子分区。因此，将静态分区(B)中每个子分区的文件覆写到静态分区(A)中对应子分区中，就可以实现将静态分区(B)中的数据同步到静态分区(A)。
图14所示为S1111的一种实现方式的流程图。终端设备执行如图14所示的下述流程以实现S1111。
S1500，读取设备存储器上与分区表相关的参数(该参数在设备出厂时预存在设备中)，合成存储器的总分区表。
例如，读取/dev/block/by-name/下各个分区的地址映射描述，将所有分区的地址映射整合为一个总分区表。
S1510，从总分区表中读取后缀名为_b的所有静态子分区，生成用于描述静态分区(B)各个子分区的列表1，列表1包括静态分区(B)中各个子分区的名称以及地址。例如：
Figure BDA0003115690900000241
Figure BDA0003115690900000251
表1
S1520，从总分区表中读取后缀名为_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中，以文件路径的方式指代该子分区的地址，在实际应用场景中，本领域的技术人员可以使用多种不同的方式描述子分区的地址。例如，采用线性地址描述。
S1530，在列表1中选定一个未被选定过的子分区(第一子分区)，获取该子分区的名称(第一子分区名称)以及地址(第一文件路径)。
具体的，在S1530之前，列表1中的子分区均未被选定。在S1530中，可以按照列表1中子分区的排列顺序(编号顺序)依次选定子分区，也可以从所有未被选定过的子分区中随机选定。
进一步的，在选定一个子分区后，标记该子分区以便在后续确认该子分区是否被选定过。例如，如表1所示，在表1中增加被选定状态列，被选定状态的初始值为0，如子分区被选定，则被选定状态修改为1。
S1540，将S1530中选定的子分区与列表2中的各个子分区做去后缀匹配；确定列表2中，去掉后缀后，与S1530中选定的子分区名称一致的子分区(第二子分区名称)以及在列表2中，该第二子分区名称对应的子分区地址(第二文件路径)；
S1541，读取第一文件路径下的数据；
S1542，将读取到的数据覆写到第二文件路径下。
S1550，判断列表1中是否还存在未被选定过的子分区；
如果存在，返回步骤S1530，重新选定第一子分区；
如果不存在，静态分区同步结束。
以表1以及表2为例，在一应用场景中，设备执行下述流程：
选定表1中被选定状态为0的第一个子分区(编号1的bootloader_b子分区)，将编号1的被选定状态修改为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的子分区，静态分区同步完成。
进一步的，在上述方案中，表1以及表2为过渡数据，在静态分区同步完成后删除表1以及表2。
在操作系统升级的过程中，在S520，根据操作系统升级安装包针对静态分区(B)部分的数据进行读写操作时，并不一定会对静态分区(B)中所有的子分区进行改写。即，如果操作系统升级前静态分区(A)与静态分区(B)中的数据完全一致，那么，在采用图5所示流程升级操作系统后，静态分区(A)与静态分区(B)中某些子分区的数据有可能仍然保持一致。因此，在将静态分区(B)的数据同步到静态分区(A)的过程中，如果首先识别静态分区(B)与静态分区(A)数据不一致的子分区，仅同步数据不一致的子分区，就可以在实现数据一致的基础上，大大降低数据读写量。
图15所示为S1111的一种实现方式的流程图。终端设备执行如图15所示的下述流程以实现S1111。
S1610～S1640，参照S1510～S1540。
S1641，对第一路径下的数据做哈希计算，获得第一哈希值；
S1642，对第二子路径下的数据做哈希计算，获得第二哈希值；
S1643，验证第一哈希值与第二哈希值是否一致；
如果一致，跳转到S1650；
如果不一致，S1645，读取第一路径下的数据；
S1646，将读取到的数据覆写到第二路径下。
S1650，参照S1550；
如果存在，返回步骤S1630，重新选定第一子分区；
如果不存在，静态分区同步结束。
进一步的，在本申请的方案中，静态分区(A)与静态分区(B)间进行数据同步的执行节点为静态分区(A)与静态分区(B)中任意一个被写入升级数据后，S1111的执行时间节点并不仅限于S1310之后。
具体的，在S520之后，静态分区(B)中被写入升级数据，但是，由于此时操作系统运行加载静态分区(A)，此时，静态分区(B)的数据无法同步到静态分区(A)。而在S531后，在S540执行过程中，设备加载静态分区(B)以运行操作系统，操作系统的运行无需加载静态分区(A)，此时静态分区(B)的数据可以同步到静态分区(A)。因此，在本申请的实施例中，可以在S531之后的任意时刻执行S1111。本申请对S1111的执行时序不做具体限制，本领域的技术人员可以根据实际需求设定静态分区的同步时刻或者触发静态分区同步的触发条件。以下通过具体实施例举例描述S1111的其他执行时序。
图16所示为根据本申请一实施例的操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图16所示的流程实现操作系统的升级以及静态分区的同步。
S1700～S1732，参照S500～S532；
S1740，设备加载基础分区(Common)；
S1750，设备加载静态分区(B)；
S1751，判断静态分区(B)是否加载成功；
如静态分区(B)加载失败，S1752，重启设备并从静态分区(A)启动；
如静态分区(B)加载成功，S1753，将静态分区(B)的数据同步到静态分区(A)；S1753的执行参照S1111。
S1760，加载动态分区(Super)+虚拟动态分区；参照S541。
S1770，设备成功启动，进入用户交互界面；参照S550。
S1771，设备将虚拟动态分区的数据落盘到动态分区(Super)；参照S551。
在虚拟A/B升级方案中，在设备重启并从升级后的静态分区启动后，设备会对动态分区+虚拟动态分区中当前系统运行所需要加载的文件进行验证，验证成功后才会加载动态分区+虚拟动态分区中当前系统运行所需要加载的文件。验证失败则会重启并回滚系统，此时系统升级失败。
因此，为避免在升级失败下进行静态分区同步，在本申请一实施例中，在动态分区+虚拟动态分区所需要加载的文件被成功验证，或者，动态分区+虚拟动态分区所需要加载的文件被成功加载后，才进行静态分区的同步。
图17所示为根据本申请一实施例的操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图17所示的流程实现操作系统的升级以及静态分区的同步。
S1800～S1852，参照S1700～S1752；
如果静态分区(B)加载成功，S1853，对动态分区+虚拟动态分区中需要加载的文件进行校验；例如，使用dmverity。
S1854，判断校验是否成功。
如校验失败，S1860，重启设备并回滚系统，例如，从静态分区(A)启动。
如校验成功，执行S1855；
S1855，将静态分区(B)的数据同步到静态分区(A)；S1855的执行参照S1111；
S1856～S1858，参照S1760～S1771。
可以理解的是，上述实施例中的部分或全部步骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照上述实施例呈现的不同的顺序来执行，并且有可能并非要执行上述实施例中的全部操作。
进一步的，一般的，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(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 (13)

1.一种操作系统升级方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述方法包括：
加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统；
获取第一系统升级安装包以及第二系统升级安装包，其中，所述第一系统升级安装包包括用于更新所述动态分区的数据的第一更新数据，所述第一系统升级安装包用于将所述第一操作系统升级到第二操作系统，所述第二系统升级安装包包括用于更新所述动态分区的数据的第二更新数据，所述第二系统升级安装包用于将所述第二操作系统升级到第三操作系统；
在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述第一更新数据以及所述第二更新数据；
将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动；
加载所述基础分区的数据；
加载所述第二静态分区的数据；
加载第一动态分区数据以运行所述第三操作系统，其中，所述第一动态分区数据为第二动态分区数据的全部或一部分，所述第二动态分区数据对应于第三动态分区数据与所述第二更新数据的叠加结果，所述第三动态分区数据对应于所述动态分区的数据与所述第一更新数据的叠加结果；
将所述第一更新数据落盘到所述动态分区；
将所述第二更新数据落盘到所述动态分区。
2.根据权利要求1所述的方法，其特征在于：
所述在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述第一更新数据以及所述第二更新数据，包括：将所述第一更新数据以及所述第二更新数据以COW文件的形式保存在所述用户数据分区中；
所述加载第一动态分区数据以运行所述第三操作系统，包括，基于快照技术加载所述动态分区的数据、所述第一更新数据的COW文件以及所述第二更新数据的COW文件。
3.根据权利要求1所述的方法，其特征在于，所述第一系统升级安装包还包括第一静态分区全量数据，所述第二系统升级安装包还包括第二静态分区全量数据；
所述重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动之前，所述方法还包括：将所述第二静态分区全量数据覆写到所述第二静态分区。
4.根据权利要求1所述的方法，其特征在于，所述加载所述第二静态分区的数据之前，所述方法还包括，将所述第一静态分区的数据同步到所述第二静态分区。
5.根据权利要求4所述的方法，其特征在于，所述第一系统升级安装包还包括第一静态分区更新数据，所述第二系统升级安装包还包括第二静态分区更新数据；
所述重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动之前，所述方法还包括：基于所述第一静态分区更新数据，将所述第二静态分区的数据由所述第一操作系统的静态分区数据升级为所述第二操作系统的静态分区数据；基于所述第二静态分区更新数据，将所述第二静态分区的数据由所述第二操作系统的静态分区数据升级为所述第三操作系统的静态分区数据；
在所述基于所述第一静态分区更新数据，将所述第二静态分区的数据由所述第一操作系统的静态分区数据升级为所述第二操作系统的静态分区数据之前，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
6.根据权利要求4所述方法，其特征在于，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
读取所述第一静态分区的各个子分区中的数据；
将所述第一静态分区的各个子分区中的数据覆写到所述第二静态分区对应的子分区中。
7.根据权利要求4所述的方法，其特征在于，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
计算第三子分区的数据的哈希值，其中，所述第三子分区为所述第一静态分区的一个子分区；
计算第四子分区的数据的哈希值，其中，所述第四子分区为所述第二静态分区的一个子分区，并且，所述第四子分区与所述第三子分区相对应；
当所述第三子分区的数据的哈希值与所述第四子分区的数据的哈希值不一致时，将所述第三子分区中的数据覆写到所述第四子分区中。
8.根据权利要求4所述方法，其特征在于，所述获取第一系统升级安装包以及第二系统升级安装包之前，所述方法还包括：
加载所述基础分区、所述第二静态分区以及所述动态分区的数据以运行第四操作系统；
获取第三系统升级安装包，其中，所述第三系统升级安装包包括静态分区升级数据，所述第三系统升级安装包用于将所述第四操作系统升级到第一操作系统；
根据所述第三系统升级安装包的静态分区升级数据，升级所述第一静态分区的数据；
将所述电子设备的启动顺序由从所述第二静态分区启动，修改为从所述第一静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动；
加载所述基础分区的数据；
加载所述第一静态分区的数据；
加载第四动态分区数据以运行所述第一操作系统；
其中，在所述重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
9.一种操作系统升级方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述方法包括：
加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统；
获取第一系统升级安装包以及第二系统升级安装包，其中，所述第一系统升级安装包包括用于更新所述动态分区的数据的第一更新数据，所述第一系统升级安装包用于将所述第一操作系统升级到第二操作系统，所述第二系统升级安装包包括用于更新所述动态分区的数据的第二更新数据，所述第二系统升级安装包用于将所述第二操作系统升级到第三操作系统；
在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存第三更新数据，其中，所述第三更新数据为所述第一更新数据与所述第二更新数据的合成数据；针对所述第一更新数据与所述第二更新数据中指向同一文件的数据，在所述第三更新数据中保留其中的所述第二更新数据的数据；
将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动；
加载所述基础分区的数据；
加载所述第二静态分区的数据；
加载第一动态分区数据以运行所述第三操作系统，其中，所述第一动态分区数据为第二动态分区数据的全部或一部分，所述第二动态分区数据对应于所述动态分区的数据与所述第三更新数据的叠加结果；
将所述第三更新数据落盘到所述动态分区。
10.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如权利要求1～8中任一项所述的方法流程。
11.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存取器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如权利要求9中任一项所述的方法流程。
12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～9中任一项所述的方法。
13.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～9中任一项所述的方法。
CN202110661865.2A 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品 Active CN113805914B (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202110661865.2A CN113805914B (zh) 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品
CN202211229081.3A CN115729586B (zh) 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品
US18/029,527 US20240012652A1 (en) 2021-06-15 2022-06-15 Operating system upgrade method, device, storage medium, and computer program product
EP22824228.5A EP4202647A4 (en) 2021-06-15 2022-06-15 METHOD FOR UPGRADING OPERATING SYSTEMS, AND DEVICE, STORAGE MEDIUM AND COMPUTER PROGRAM PRODUCT
PCT/CN2022/098854 WO2022262751A1 (zh) 2021-06-15 2022-06-15 操作系统升级方法、设备、存储介质及计算机程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110661865.2A CN113805914B (zh) 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202211229081.3A Division CN115729586B (zh) 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品

Publications (2)

Publication Number Publication Date
CN113805914A true CN113805914A (zh) 2021-12-17
CN113805914B CN113805914B (zh) 2022-10-14

Family

ID=78942472

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202110661865.2A Active CN113805914B (zh) 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品
CN202211229081.3A Active CN115729586B (zh) 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202211229081.3A Active CN115729586B (zh) 2021-06-15 2021-06-15 操作系统升级方法、设备、存储介质及计算机程序产品

Country Status (4)

Country Link
US (1) US20240012652A1 (zh)
EP (1) EP4202647A4 (zh)
CN (2) CN113805914B (zh)
WO (1) WO2022262751A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114265616A (zh) * 2022-03-02 2022-04-01 荣耀终端有限公司 操作系统的升级方法、电子设备及存储介质
WO2022262751A1 (zh) * 2021-06-15 2022-12-22 荣耀终端有限公司 操作系统升级方法、设备、存储介质及计算机程序产品
CN115562695A (zh) * 2022-01-10 2023-01-03 荣耀终端有限公司 操作系统升级方法、电子设备、存储介质及芯片系统
WO2023130946A1 (zh) * 2022-01-10 2023-07-13 荣耀终端有限公司 操作系统升级方法、电子设备、存储介质及芯片系统
CN116661812A (zh) * 2022-11-25 2023-08-29 荣耀终端有限公司 设备升级方法、电子设备及系统
WO2024071861A1 (ko) * 2022-09-30 2024-04-04 삼성전자 주식회사 업데이트 방법 및 이를 위한 전자 장치
WO2024131151A1 (zh) * 2022-12-22 2024-06-27 荣耀终端有限公司 一种操作系统的升级方法及电子设备

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020015259A1 (zh) * 2018-07-20 2020-01-23 华为技术有限公司 一种数据备份方法及终端
CN117971305A (zh) * 2024-03-28 2024-05-03 荣耀终端有限公司 操作系统的升级方法、服务器及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104301383A (zh) * 2014-09-05 2015-01-21 小米科技有限责任公司 一种升级方法、装置及设备
CN105260200A (zh) * 2015-09-07 2016-01-20 北京奇虎科技有限公司 操作系统升级的处理方法和装置
CN107967141A (zh) * 2017-11-27 2018-04-27 北京小米移动软件有限公司 操作系统升级方法、装置及终端
CN111694608A (zh) * 2020-06-08 2020-09-22 北京百度网讯科技有限公司 终端设备的系统升级方法和装置、电子设备和终端设备

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6351850B1 (en) * 1997-11-14 2002-02-26 Frank Van Gilluwe Computer operating system installation
CN103473067B (zh) * 2013-09-23 2016-08-31 恒鸿达科技有限公司 嵌入式Linux分区与数据还原方法、系统及系统开发方法
CN103559054B (zh) * 2013-10-30 2017-10-10 华为终端有限公司 智能终端多操作系统的实现、删除方法和装置
US9626180B2 (en) * 2013-12-16 2017-04-18 International Business Machines Corporation Live operating system update mechanisms
US9430223B2 (en) * 2014-09-25 2016-08-30 International Business Machines Corporation Live operating system update mechanisms
CN106293782A (zh) * 2015-05-15 2017-01-04 中兴通讯股份有限公司 一种系统升级方法及终端
CN104918114B (zh) * 2015-06-05 2018-05-18 青岛海信电器股份有限公司 一种操作系统升级方法及装置
CN106610840A (zh) * 2015-10-22 2017-05-03 深圳市中兴微电子技术有限公司 一种无线固件升级方法及系统
CN105893084B (zh) * 2016-03-29 2019-04-30 青岛海信移动通信技术股份有限公司 版本升级方法及终端设备
EP3441876B1 (en) * 2016-04-27 2023-02-15 Honor Device Co., Ltd. Patch upgrade-based file processing method and device, terminal, and storage medium
CN107273160A (zh) * 2017-06-09 2017-10-20 青岛海信电器股份有限公司 一种版本升级的方法及装置
US11531488B2 (en) * 2017-08-07 2022-12-20 Kaseya Limited Copy-on-write systems and methods
JPWO2019207729A1 (ja) * 2018-04-26 2020-05-07 三菱電機株式会社 産業用コンピュータ、産業用コンピュータシステム、オペレーティングシステム更新方法及びプログラム
CN110175039A (zh) * 2019-04-26 2019-08-27 潍坊歌尔电子有限公司 在线升级方法、设备、可读存储介质及电子设备
US20200341746A1 (en) * 2019-04-29 2020-10-29 Microsoft Technology Licensing, Llc Snapshot recovery states
CN110321148B (zh) * 2019-07-12 2023-04-25 Oppo广东移动通信有限公司 系统升级方法及相关装置
CN110543321A (zh) * 2019-09-06 2019-12-06 深圳市英博超算科技有限公司 Ota升级方法、装置、终端以及计算机可读存储介质
CN112416406B (zh) * 2020-11-30 2023-06-23 腾讯科技（深圳）有限公司 终端设备升级方法、装置、终端设备和介质
CN112817625B (zh) * 2021-01-29 2024-03-08 青岛海信移动通信技术有限公司 系统升级方法、装置、电子设备及存储介质
CN113805914B (zh) * 2021-06-15 2022-10-14 荣耀终端有限公司 操作系统升级方法、设备、存储介质及计算机程序产品

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104301383A (zh) * 2014-09-05 2015-01-21 小米科技有限责任公司 一种升级方法、装置及设备
CN105260200A (zh) * 2015-09-07 2016-01-20 北京奇虎科技有限公司 操作系统升级的处理方法和装置
CN107967141A (zh) * 2017-11-27 2018-04-27 北京小米移动软件有限公司 操作系统升级方法、装置及终端
CN111694608A (zh) * 2020-06-08 2020-09-22 北京百度网讯科技有限公司 终端设备的系统升级方法和装置、电子设备和终端设备

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022262751A1 (zh) * 2021-06-15 2022-12-22 荣耀终端有限公司 操作系统升级方法、设备、存储介质及计算机程序产品
CN115562695A (zh) * 2022-01-10 2023-01-03 荣耀终端有限公司 操作系统升级方法、电子设备、存储介质及芯片系统
WO2023130946A1 (zh) * 2022-01-10 2023-07-13 荣耀终端有限公司 操作系统升级方法、电子设备、存储介质及芯片系统
CN115562695B (zh) * 2022-01-10 2023-10-27 荣耀终端有限公司 操作系统升级方法、电子设备、存储介质及芯片系统
CN114265616A (zh) * 2022-03-02 2022-04-01 荣耀终端有限公司 操作系统的升级方法、电子设备及存储介质
WO2024071861A1 (ko) * 2022-09-30 2024-04-04 삼성전자 주식회사 업데이트 방법 및 이를 위한 전자 장치
CN116661812A (zh) * 2022-11-25 2023-08-29 荣耀终端有限公司 设备升级方法、电子设备及系统
CN116661812B (zh) * 2022-11-25 2024-04-02 荣耀终端有限公司 设备升级方法、电子设备及系统
WO2024131151A1 (zh) * 2022-12-22 2024-06-27 荣耀终端有限公司 一种操作系统的升级方法及电子设备

Also Published As

Publication number Publication date
EP4202647A1 (en) 2023-06-28
EP4202647A4 (en) 2024-05-22
US20240012652A1 (en) 2024-01-11
CN113805914B (zh) 2022-10-14
CN115729586A (zh) 2023-03-03
WO2022262751A1 (zh) 2022-12-22
CN115729586B (zh) 2023-10-20

Similar Documents

Publication Publication Date Title
CN113805914B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
CN113821233B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
CN113821235B (zh) 操作系统数据更新方法、设备、存储介质及程序产品
CN114116023B (zh) 操作系统启动方法、设备、存储介质及计算机程序产品
CN114265616B (zh) 操作系统的升级方法、电子设备及存储介质
CN113821221B (zh) 安装操作系统的方法、设备及存储介质
CN115686584A (zh) 一种操作系统升级方法、设备、存储介质及计算机程序产品
WO2022262748A1 (zh) 操作系统的管理方法、设备、存储介质及计算机程序产品
CN114461257B (zh) 操作系统数据配置方法、设备、存储介质及程序产品
CN113805956B (zh) 操作系统的配置方法、设备及存储介质
CN113806139B (zh) 操作系统恢复方法、设备、存储介质及计算机程序产品
CN113900673B (zh) 系统安装包的管理方法、设备、存储介质及程序产品
CN114489813B (zh) 配置操作系统制式的方法、设备及存储介质
CN113821234B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
US20240231789A1 (en) Operating System Management Method, Device, Storage Medium, and Computer Program Product
CN115686644B (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
GR01 Patent grant
GR01 Patent grant