CN116069375A - 操作***数据更新方法、设备及存储介质 - Google Patents

操作***数据更新方法、设备及存储介质 Download PDF

Info

Publication number
CN116069375A
CN116069375A CN202211524404.1A CN202211524404A CN116069375A CN 116069375 A CN116069375 A CN 116069375A CN 202211524404 A CN202211524404 A CN 202211524404A CN 116069375 A CN116069375 A CN 116069375A
Authority
CN
China
Prior art keywords
partition
data
static
operating system
sub
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211524404.1A
Other languages
English (en)
Inventor
王艳召
陈超
张赠辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202211524404.1A priority Critical patent/CN116069375A/zh
Publication of CN116069375A publication Critical patent/CN116069375A/zh
Pending legal-status Critical Current

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/658—Incremental updates; Differential updates
    • 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/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • 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/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • 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/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例提供的一种操作***数据更新方法、设备及存储介质，方法应用于电子设备，电子设备启动后加载基础分区、第一静态分区以及动态分区的数据以运行第一操作***，第一操作***运行之后，方法包括：获取补丁包；根据补丁包更新第二静态分区中的数据；重启电子设备，确认当前的启动顺序为从第二静态分区启动；加载基础分区、第二静态分区以及动态分区的数据以运行静态分区数据更新后的第一操作***。根据本申请实施例的方法，可以针对静态分区的数据打补丁修正，而不需要升级整个操作***，大大降低了操作***修复难度。

Description

操作***数据更新方法、设备及存储介质
技术领域
本申请涉及计算机技术领域，具体地涉及一种操作***数据更新方法、设备及存储介质。
背景技术
在现有技术的应用场景中，用户终端需要安装操作***才可以被用户使用。例如，手机上需要安装手机操作***(例如：IOS***、安卓***)才可以被用户使用。
在现有技术的应用场景中，在操作***发布后，有时需要对已发布的操作***中的***数据进行更新。例如，在操作***发布后，操作***的应用环境发生变化，需要对操作***中的某些参数进行对应更新。又例如，在编写操作***代码时，由于程序员人为失误、程序员考虑不够全面等原因，操作***数据中可能存在漏洞(bug)。一般的，在操作***刚被发布时，操作***的供应商不会意识到操作***中存在的bug。此时，用户终端上就会安装上存在bug的操作***。随着操作***运行数据的积累以及检测数据的积累，操作***的供应商检测到了bug的存在。此时，就需要对之前安装了存在bug的操作***的用户终端进行***bug修复。
因此，需要一种操作***数据更新的方法，以在存在操作***数据更新需求时更新操作***数据。
发明内容
有鉴于此，本申请提供一种操作***数据更新方法、设备及存储介质，以利于解决现有技术中操作***数据存在更新需求的问题。
第一方面，本申请实施例提供了一种操作***数据更新方法，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以运行第一操作***，所述第一操作***运行之后，所述方法包括：
获取补丁包，所述补丁包包括更新定位描述以及更新数据，所述更新定位描述用于指定静态分区中需要进行数据更新的更新目标，所述更新数据用于描述静态分区的数据更新结果；
根据所述补丁包中的更新定位描述以及更新数据，更新所述第二静态分区中的数据；
将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动；
加载所述基础分区、所述第二静态分区以及动态分区的数据以运行静态分区数据更新后的所述第一操作***；
其中，所述根据所述补丁包中的更新定位描述以及更新数据，更新所述第二静态分区中的数据之前，所述方法还包括，将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
读取所述第一静态分区的各个子分区中的数据；
将所述第一静态分区的各个子分区中的数据覆写到所述第二静态分区对应的子分区中。
在第一方面的一种实现方式中，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
计算第三子分区的数据的哈希值，其中，所述第三子分区为所述第一静态分区的一个子分区；
计算第四子分区的数据的哈希值，其中，所述第四子分区为所述第二静态分区的一个子分区，并且，所述第四子分区与所述第三子分区相对应；
当所述第三子分区的数据的哈希值与所述第四子分区的数据的哈希值不一致时，将所述第三子分区中的数据覆写到所述第四子分区中。
在第一方面的一种实现方式中，所述获取补丁包之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，所述获取补丁包之前，所述方法还包括：
加载所述基础分区、所述第二静态分区以及所述动态分区的数据以运行第二操作***；
获取升级安装包，所述升级安装包包括静态分区升级文件；
基于所述静态分区升级文件升级所述第一静态分区的数据；
将所述电子设备的启动顺序由从所述第二静态分区启动，修改为从所述第一静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动；
加载所述基础分区、所述第一静态分区以及所述动态分区的数据，以运行所述第一操作***；
其中，在所述重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，在加载所述第一静态分区的数据的过程中，在静态分区数据校验成功后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，在加载所述动态分区的数据的过程中，在待加载动态分区文件校验成功后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，所述升级安装包还包括动态分区升级数据；
所述重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动之前，所述方法还包括，在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述动态分区升级数据；
所述加载所述基础分区、所述第一静态分区以及所述动态分区的数据，以运行所述第一操作***，包括，加载所述动态分区的数据以及所述动态分区升级数据；
所述加载所述基础分区、所述第一静态分区以及所述动态分区的数据，以运行所述第一操作***之后，所述方法还包括，将所述动态分区升级数据落盘到所述动态分区；
在所述将所述动态分区升级数据落盘到所述动态分区之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。
在第一方面的一种实现方式中，所述根据所述补丁包中的更新定位描述以及更新数据，更新所述第二静态分区中的数据，包括：
为所述更新定位描述添加针对所述第二静态分区路径修正。
在第一方面的一种实现方式中，所述更新定位描述为指向第一文件的第一路径，所述更新数据为第二文件，所述第二文件为与所述第一文件同名的文件，所述第二文件为所述第一文件的更新文件，所述根据所述补丁包中的更新定位描述以及更新数据，更新所述第二静态分区中的数据，包括：
为所述第一路径添加对应所述第二静态分区的目录名后缀，生成第二路径；
根据所述第二路径定位到所述第二静态分区中的所述第一文件；
删除所述第二静态分区中的所述第一文件；
将所述第二文件写入到所述第二路径下。
在第一方面的一种实现方式中，所述更新定位描述为第三路径，所述更新数据为第三文件，所述根据所述补丁包中的更新定位描述以及更新数据，更新所述第二静态分区中的数据，包括：
为所述第三路径添加对应所述第二静态分区的目录名后缀，生成第四路径；
将所述第三文件写入到所述第四路径下。
在第一方面的一种实现方式中，所述更新定位描述为指向第四文件的第一代码段的第五路径，所述更新数据为第二代码段，所述根据所述补丁包中的更新定位描述以及更新数据，更新所述第二静态分区中的数据，包括：
为所述第五路径添加对应所述第二静态分区的目录名后缀，生成第六路径；
根据所述第六路径定位到所述第二静态分区中的所述第四文件；
打开所述第四文件，定位所述第一代码段；
使用所述第二代码段覆写所述第一代码段。
第二方面，本申请还提供一种电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得：
所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以运行第一操作***，
以及在所述第一操作***运行之后，执行如第一方面所述的方法流程。
第三方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第一方面所述的方法。
第四方面，本申请还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如第一方面所述的方法。
根据本申请实施例所提出的上述技术方案，至少可以实现下述技术效果：
根据本申请实施例的方法，可以针对静态分区的数据进行打补丁修正，而不需要升级整个操作***，大大降低了操作***修复难度，提高了操作***修复效率，提高了操作***的运行稳定性。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
图1所示为采用虚拟A/B升级方式的安卓***在终端设备上的数据存储结构示意图；
图2所示为根据本申请一实施例进行操作***数据更新的流程图；
图3a所示为根据本申请一实施例针进行操作***数据更新的流程图；
图3b所示为根据本申请一实施例针进行操作***数据更新的流程图；
图3c所示为根据本申请一实施例针进行操作***数据更新的流程图；
图4所示为根据本申请一实施例的操作***升级的流程图；
图5所示为根据本申请一实施例进行操作***数据更新的流程图；
图6所示为根据本申请一实施例的静态分区同步流程图；
图7所示为根据本申请一实施例的静态分区同步流程图；
图8所示为根据本申请一实施例的静态分区同步流程图；
图9所示为根据本申请一实施例的操作***升级的流程图；
图10所示为根据本申请一实施例的操作***升级的流程图。
具体实施方式
为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。
应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
当操作***存在数据更新需求时，一种可行的解决方案是发布新版本的操作***。用户设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作***的版本号(例如版本1.1，版本1.1的操作***中存在bug)；搜包服务器根据搜包请求中的操作***版本号，检索当前是否存在更新版本号的操作***安装包(例如版本1.2，版本1.2的操作***中已修复bug)；当存在更新版本的操作***安装包时，搜包服务器向设备反馈操作***升级安装包(例如，由版本1.1升级到版本1.2的操作***升级包)的下载地址；设备根据操作***升级安装包的下载地址下载操作***升级安装包；***升级安装包下载完毕后进行操作***升级。
上述方案虽然可以更新用户设备上的操作***数据，但是，下载操作***安装包所需消耗的数据量较高，操作***升级所占用的***资源以及操作耗时也会大大影响用户对设备的正常使用。
针对操作***存在数据更新需求的情况，另一种可行的解决方案是发布用于更新数据的补丁文件。补丁文件仅用于更新指定的操作***数据。例如，参数A赋值错误导致操作***出现bug，补丁文件中包含参数A的定位信息以及参数A的正确赋值。根据补丁文件，仅仅对参数A的赋值进行更新，而不需对整个操作***进行升级。由于补丁文件的数据量远远小于操作***升级安装包的数据量，因此大大节省了用户的流量消耗。并且，仅针对指定数据的更新操作所占用的***资源以及操作耗时也远远小于针对整个操作***进行升级时所占用的***资源以及操作耗时，因此，可以有效降低操作***数据更新操作对用户正常使用设备的影响。
然而，虽然使用补丁文件仅针对指定数据进行更新可以有效控制下载流量消耗、***资源占用以及修复耗时，但是，在通常状况下，设备启动会加载操作***数据，在操作***运行的过程中，被加载的操作***数据是只读的，例如，在设备正常运行操作***时，操作***的静态分区是只读的。如果需要更新的数据存在于静态分区中，那么，在设备运行操作***的过程中，就无法对静态分区中的操作***数据进行更新。
针对上述问题，本申请提出了一种更新操作***数据的方法。基于静态分区的A/B分区配置，在设备正常运行时，对静态分区的数据进行更新。
具体的，图1所示为采用虚拟A/B升级方式的安卓***在终端设备上的数据存储结构示意图。如图1所示，安卓***数据存储区包含基础分区(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)包含多个子分区。
在设备启动时，从一个静态分区启动。例如，设备从静态分区(A)启动：依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)；设备从静态分区(B)启动：依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
在图1所示的***存储结构中，静态分区(A)与静态分区(B)的分区结构是一致的，当静态分区(A)与静态分区(B)中烧录的数据一致的时候(例如，在某些应用场景中，设备进行出厂前***安装后，静态分区(A)与静态分区(B)中烧录的数据是一致的)，静态分区(A)与静态分区(B)可以相互替代。
图2所示为根据本申请一实施例针对图1所示***存储结构进行操作***数据更新的流程图，设备从静态分区(A)启动，静态分区(A)与静态分区(B)中的数据一致。设备按照如图2所示的流程实现更新操作***的静态分区中的数据。
S200，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动；
S210，设备获取操作***补丁包；
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作***的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作***版本号，检索当前是否存在针对该版本号的操作***补丁包；当存在针对该版本号的操作***补丁包时，搜包服务器向设备反馈操作操作***补丁包的下载地址；设备根据操作***补丁包的下载地址下载操作***补丁包，并将操作***补丁包保存到用户数据分区(Userdata)。
S220，设备从用户数据分区(Userdata)读取操作***补丁包，根据操作***补丁包对静态分区(B)进行更新。
S230，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B，其中，在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)。
S240，设备重启。退出当前的操作***，切断设备电源，再次开启设备电源。
在S230之后，设备并不需要立即重启，可以由用户自行选择重启时机。
S250，设备依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。
S260，设备成功启动，进入用户交互界面。此时，操作***运行所加载的静态分区数据为更新后的数据。
根据本申请实施例的方法，可以针对静态分区的数据进行打补丁修正，而不需要升级整个操作***，大大降低了操作***修复难度，提高了操作***修复效率，提高了操作***的运行稳定性。
具体的，在本申请实施例中，对操作***补丁包的数据结构以及根据操作***补丁包对静态分区中的数据进行更新的方式不做具体限定。本领域的技术人员可以根据实际需求，采用多种不同数据结构的操作***补丁包以及采用多种不同的数据更新方案更新静态分区中的数据。
例如，图3a所示为根据本申请一实施例针对图1所示***存储结构进行操作***数据更新的流程图，设备从静态分区(A)启动，静态分区(A)与静态分区(B)中的数据一致。操作***补丁包中包含用于定位更新对象的定位数据以及更新数据。例如，更新目标是更新vbmeta子分区中的A文件。操作***补丁包中包含A文件在设备上的保存路径描述/dev/block/by-name/vbmeta/A、最新版本的A文件以及最新版本的vbmeta子分区的哈希值。
设备按照如图3a所示的流程实现更新操作***的静态分区中的数据。
S300a以及S301a，参照S200以及S210；
S309a，从操作***补丁包中提取路径描述；设备获取路径描述/dev/block/by-name/vbmeta/A；
S310a，识别操作***当前的启动顺序；设备获知操作***当前从静态分区(A)启动；例如，参照S230，读取MBR；
S311a，根据操作***当前的启动顺序修正待更新文件的路径；由于操作***当前从静态分区(A)启动，因此设备在路径描述/dev/block/by-name/vbmeta/A上增加对应静态分区(B)的后缀，得到路径描述/dev/block/by-name/vbmeta_b/A；
S312a，删除待更新文件；设备删除/dev/block/by-name/vbmeta_b下的A文件；
S313a，从操作***补丁包中提取更新文件；设备获取最新版本的A文件；
S314a，写入更新文件；设备将最新版本的A文件写入到/dev/block/by-name/vbmeta_b下；
S320a，校验更新结果；设备计算vbmeta_b子分区的哈希值，对比计算出的哈希值以及操作***补丁包中最新版本的vbmeta子分区的哈希值是否一致；
如果校验失败，哈希值不一致，执行S330a，重新获取操作***补丁包，重复执行S220～S226；或者，设备提示用户打补丁失败，由用户手动检测失败原因。
如果校验成功，哈希值一致，执行S340a，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。具体的，改写common分区中改写启动标识，将启动标识由A改写为B。
S350a，设备重启。退出当前的操作***，切断设备电源，再次开启设备电源。
在S340a完成后，设备并不需要立即重启，可以由用户自行选择重启时机。
S360a，设备依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
S370a，设备成功启动，进入用户交互界面。此时，设备所加载的静态分区中的数据为更新后的最新版本数据。
又例如，例如，图3b所示为根据本申请一实施例针对图1所示***存储结构进行操作***数据更新的流程图，设备从静态分区(A)启动，静态分区(A)与静态分区(B)中的数据一致。操作***补丁包中包含用于定位更新对象的定位数据以及更新数据。例如，更新目标是在vbmeta子分区中增加B文件。操作***补丁包中包含B文件在设备上的保存路径描述/dev/block/by-name/vbmeta、B文件以及最新版本的vbmeta子分区的哈希值。
设备按照如图3b所示的流程实现更新操作***的静态分区中的数据。
S300b以及S301b，参照S200以及S210；
S309b，从操作***补丁包中提取路径描述；设备获取路径描述/dev/block/by-name/vbmeta；
S310b，识别操作***当前的启动顺序；设备获知操作***当前从静态分区(A)启动；
S311b，根据操作***当前的启动顺序修正待更新文件的路径；由于操作***当前从静态分区(A)启动，因此设备在路径描述/dev/block/by-name/vbmeta上增加对应静态分区(B)的后缀，得到路径描述/dev/block/by-name/vbmeta_b；由于路径描述/dev/block/by-name/vbmeta并未指向具体文件，因此设备不需要删除静态分区(B)中的文件；
S313b，从操作***补丁包中提取更新文件；设备获取B文件；
S314b，写入更新文件；设备将B文件写入到/dev/block/by-name/vbmeta_b下；
S320b～S370b，参照S320a～S361a。
又例如，例如，图3c所示为根据本申请一实施例针对图1所示***存储结构进行操作***数据更新的流程图，设备从静态分区(A)启动，静态分区(A)与静态分区(B)中的数据一致。操作***补丁包中包含用于定位更新对象的定位数据以及更新数据。例如，更新目标是将vbmeta子分区下的C文件中代码段S替换为S1。操作***补丁包中包含C文件在设备上的保存路径描述/dev/block/by-name/vbmeta/C:S、代码段S1以及最新版本的vbmeta子分区的哈希值。
设备按照如图3c所示的流程实现更新操作***的静态分区中的数据。
S300c以及S301c，参照S200以及S210；
S309c,从操作***补丁包中提取路径描述；设备获取路径描述/dev/block/by-name/vbmeta/C:S；
S310c，识别操作***当前的启动顺序；设备获知操作***当前从静态分区(A)启动；
S311c，根据操作***当前的启动顺序修正待更新文件的路径；由于操作***当前从静态分区(A)启动，因此设备在路径描述/dev/block/by-name/vbmeta/C:S上增加对应静态分区(B)的后缀，得到路径描述/dev/block/by-name/vbmeta_b/C:S；由于路径描述/dev/block/by-name/vbmeta/C:S指向具体文件中的代码段，因此设备执行S312c；
S312c，根据/dev/block/by-name/vbmeta_b/C，打开vbmeta_b子分区中的C文件；
S313c，根据/dev/block/by-name/vbmeta_b/C:S，定位C文件中的代码段S；例如，将/dev/block/by-name/vbmeta_b/C:S中的S与C文件中的代码做匹配，搜索C文件的代码中与S一致的代码段；
S314c，从操作***补丁包中提取代码段S1，使用代码段S1替换vbmeta_b子分区中C文件中的代码段S；
S320c～S370c，参照S320a～S361a。
进一步的，在设备出厂后，在实际应用场景中，设备还存在升级需求。图4所示为针对图1所示***数据存储结构进行操作***升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图4所示的流程实现操作***的升级。
S400，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动；。
S410，设备获取操作***升级安装包；。
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作***的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作***版本号，检索当前是否存在更新版本号的操作***安装包(例如版本1.2)；当存在更新版本的操作***安装包时，搜包服务器向设备反馈操作***升级安装包(例如，由版本1.1升级到版本1.2的***增量升级安装包)的下载地址；设备根据操作***升级安装包的下载地址下载操作***升级安装包，并将操作***升级安装包保存到用户数据分区(Userdata)。
S420，设备根据操作***升级安装包针对静态分区(B)进行数据写入操作以升级静态分区。
例如，版本1.1升级到版本1.2的***增量升级安装包包含版本1.2的静态分区的全量数据，设备将版本1.2的静态分区的数据覆写到静态分区(B)中。
S430，设备根据操作***升级安装包在用户数据分区(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。那么，在S430中，设备在用户数据分区(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)子分区相对应。
在S410所获取的操作***升级安装包中，动态分区(Super)的升级数据的COW文件以二进制代码形式压缩保存。在操作***升级安装包中，每个COW文件根据其所针对的动态分区(Super)子分区所命名。例如，针对system子分区的COW文件被命名为system-cow-img.img.0000。
在S430中，设备解包操作***升级安装包以获取所有的COW文件，为每个COW文件附加A/B分区标记。具体的，当设备当前从静态分区(A)启动时，可以理解为设备当前运行操作***所加载的动态分区(Super)为动态分区(A)。在升级操作***时，用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。因此，为COW文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
进一步的，在S430中，在用户数据分区(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子分区的数据升级。
进一步的，在S430中，在将COW文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+COW文件进行整体校验，校验动态分区(Super)+COW文件的有效性，验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super)数据。
具体的，以从1.1版本升级到1.2版本为例，计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.2未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.2需要升级的数据)的合成结果的哈希值，判断该哈希值与1.2版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明COW文件有效；如果不一致，则说明COW文件无效，升级失败，中断升级进程并报错；其中，1.2版本中动态分区(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)”时，代表该子分区需要进行落盘操作。
S431，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。
例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B。在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)。
S432，设备重启。退出当前的操作***，切断设备电源，再次开启设备电源。
S440，设备依次加载基础分区(Common)、静态分区(B)。
S441，设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。
具体的，设备读取元数据(/metadata)中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索COW文件，并采用snapshot合并加载动态分区(Super)以及COW文件。
进一步的，在S441中，设备并不加载动态分区(Super)以及用户数据分区(Userdata)中的全部COW文件，而是根据操作***运行需求加载对应的文件。具体的，在S441中，设备根据操作***运行需求确定需要加载的文件，基于snapshot从动态分区(Super)或虚拟动态分区中的COW文件中提取对应的文件进行加载。
具体的，在S441中，当动态分区(Super)的子分区首存在对应的COW文件时，先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照S430。设备根据操作***运行需求确定需要加载的文件，基于动态分区(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文件写入错误或者落盘状态信息写入错误)，此时设备回滚***并报错。
进一步的，在S441中，在加载文件之前，设备还需要对加载文件进行校验。不同于S430，在S441中，不对动态分区(Super)+COW文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验(dm-verity是dm(device mapper)的一个目标(target)，是一个虚拟块设备，专门用于文件***的校验)。校验成功则加载文件，校验失败则重启设备，回滚***或者尝试再次加载文件。
S450，设备成功启动，进入用户交互界面。
S451，设备将虚拟动态分区的数据落盘到动态分区(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)”。
在S420中，静态分区升级的数据操作是针对静态分区(B)中的操作***数据的，其并不会影响到当前启动的静态分区(A)的操作***数据；并且，在S430中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前挂载的动态分区(Super)。因此，在整个操作***升级的过程中，用户可以正常使用设备；并且，在S431完成后，设备并不需要立即重启，可以由用户自行选择重启时机；这样，操作***的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。进一步的，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。
在某些应用场景中，当设备基于图4所示流程进行操作***升级后，静态分区(B)与静态分区(A)就存在版本差异，静态分区(A)与静态分区(B)的数据就可能是不一致的。这样，如果现当前设备从静态分区(B)启动；那么，当需要更新设备的当前操作***的数据时，就不能直接针对静态分区(A)的数据进行打补丁操作。
图5所示为根据本申请一实施例针对图1所示***存储结构进行操作***数据更新的流程图。设备从静态分区(A)启动后，基于图4所示流程进行操作***升级，从静态分区(B)启动完成操作***升级。在此之后，在设备从静态分区(B)启动的状态下，设备按照如图5所示的流程实现更新操作***的静态分区中的数据。
S500，依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动；
S510，获取操作***补丁包；参照S210；
S511，将静态分区(B)的数据同步到静态分区(A)；
S520，设备从用户数据分区(Userdata)读取操作***补丁包，根据操作***补丁包对静态分区(A)进行更新；参照S220；
S530，将设备的启动顺序由从静态分区(B)启动变更为从静态分区(A)启动；参照S230；
S540，设备重启；参照S240；
S550，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动；
S560，设备成功启动，进入用户交互界面。此时，操作***运行所加载的静态分区数据为更新后的数据。
进一步的，本申请对S511的具体实现方式不做具体限制，本领域的技术人员可以采用多种可行的实现方式实现S511。以下通过具体实施例举例说明S511的具体实现流程。
在S420中，设备将操作***升级安装包中的静态分区的数据写入到静态分区(B)。因此，如果使用同样的操作***升级安装包，将操作***升级安装包中的静态分区的数据写入到静态分区(A)中，就会使得静态分区(A)中的数据与静态分区(B)中的数据一致。
因此，在一应用场景中，S511包括：获取从用户数据分区(Userdata)中读取S410中所保存的操作***升级安装包，将操作***升级安装包中的静态分区的数据写入到静态分区(A)中。
静态分区(A)与静态分区(B)在分区结构以及分区大小上是完全一致的。因此，可以直接将静态分区(A)的数据镜像到静态分区(B)，或者，将静态分区(B)的数据镜像到静态分区(A)。
图6所示为S511的一种实现方式的流程图。终端设备执行如图6所示的下述流程以实现S511。
S600，将静态分区(B)中的所有数据读出，打包压缩后制作为镜像文件B；
S610，将镜像文件B解包后恢复到静态分区(A)，从而实现将静态分区(B)的数据覆写到静态分区(A)。
静态分区(A)与静态分区(B)在分区结构上是一致的，其包含相同的子分区。因此，将静态分区(B)中每个子分区的文件覆写到静态分区(A)中对应子分区中，就可以实现将静态分区(B)中的数据同步到静态分区(A)。
图7所示为S511的一种实现方式的流程图。终端设备执行如图7所示的下述流程以实现S511。
S700，读取设备存储器上与分区表相关的参数(该参数在设备出厂时预存在设备中)，合成存储器的总分区表。
例如，读取/dev/block/by-name/下各个分区的地址映射描述，将所有分区的地址映射整合为一个总分区表。
又例如，读取MBR中保存的分区表。
S710，从总分区表中读取后缀名为_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
S720，从总分区表中读取后缀名为_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中，以文件路径的方式指代该子分区的地址，在实际应用场景中，本领域的技术人员可以使用多种不同的方式描述子分区的地址。例如，采用线性地址描述。
S730，在列表1中选定一个未被选定过的子分区(第一子分区)，获取该子分区的名称(第一子分区名称)以及地址(第一文件路径)。
具体的，在S730之前，列表1中的子分区均未被选定。在S730中，可以按照列表1中子分区的排列顺序(编号顺序)依次选定子分区，也可以从所有未被选定过的子分区中随机选定。
进一步的，在选定一个子分区后，标记该子分区以便在后续确认该子分区是否被选定过。例如，如表1所示，在表1中增加被选定状态列，被选定状态的初始值为0，如子分区被选定，则被选定状态修改为1。
S740，将S730中选定的子分区与列表2中的各个子分区做去后缀匹配；确定列表2中，去掉后缀后，与S730中选定的子分区名称一致的子分区(第二子分区名称)以及在列表2中，该第二子分区名称对应的子分区地址(第二文件路径)；
S741，读取第一文件路径下的数据；
S742，将读取到的数据覆写到第二文件路径下。
S750，判断列表1中是否还存在未被选定过的子分区；
如果存在，返回步骤S730，重新选定第一子分区；
如果不存在，静态分区同步结束。
以表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)数据不一致的子分区，仅同步数据不一致的子分区，就可以在实现数据一致的基础上，大大降低数据读写量。
图8所示为S511的一种实现方式的流程图。终端设备执行如图8所示的下述流程以实现S511。
S810～S840，参照S710～S740。
S841，对第一路径下的数据做哈希计算，获得第一哈希值；
S842，对第二子路径下的数据做哈希计算，获得第二哈希值；
S843，验证第一哈希值与第二哈希值是否一致；
如果一致，跳转到S850；
如果不一致，S845，读取第一路径下的数据；
S846，将读取到的数据覆写到第二路径下。
S850，参照S750；
如果存在，返回步骤S830，重新选定第一子分区；
如果不存在，静态分区同步结束。
进一步的，在本申请的方案中，静态分区(A)与静态分区(B)间进行数据同步的执行节点为静态分区(A)与静态分区(B)中任意一个被写入升级数据后，S511的执行时间节点并不仅限于S510之后。
具体的，在S420之后，静态分区(B)中被写入升级数据，但是，由于此时操作***运行加载静态分区(A)，此时，静态分区(B)的数据无法同步到静态分区(A)。而在S431后，在S440执行过程中，设备加载静态分区(B)以运行操作***，操作***的运行无需加载静态分区(A)，此时静态分区(B)的数据可以同步到静态分区(A)。因此，在本申请的实施例中，可以在S431之后的任意时刻执行S511。本申请对S511的执行时序不做具体限制，本领域的技术人员可以根据实际需求设定静态分区的同步时刻或者触发静态分区同步的触发条件。以下通过具体实施例举例描述S511的其他执行时序。
图9所示为根据本申请一实施例的操作***升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图9所示的流程实现操作***的升级以及静态分区的同步。
S900～S932，参照S400～S432；
S940，设备加载基础分区(Common)；
S950，设备加载静态分区(B)；
S951，判断静态分区(B)是否加载成功；
如静态分区(B)加载失败，S952，重启设备并从静态分区(A)启动；
如静态分区(B)加载成功，S953，将静态分区(B)的数据同步到静态分区(A)；S953的执行参照S511。
S960，加载动态分区(Super)+虚拟动态分区；参照S541。
S970，设备成功启动，进入用户交互界面；参照S450。
S971，设备将虚拟动态分区的数据落盘到动态分区(Super)；参照S451。
在虚拟A/B升级方案中，在设备重启并从升级后的静态分区启动后，设备会对动态分区+虚拟动态分区中当前***运行所需要加载的文件进行验证，验证成功后才会加载动态分区+虚拟动态分区中当前***运行所需要加载的文件。验证失败则会重启并回滚***，此时***升级失败。
因此，为避免在升级失败下进行静态分区同步，在本申请一实施例中，在动态分区+虚拟动态分区所需要加载的文件被成功验证，或者，动态分区+虚拟动态分区所需要加载的文件被成功加载后，才进行静态分区的同步。
图10所示为根据本申请一实施例的操作***升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图10所示的流程实现操作***的升级以及静态分区的同步。
S1000～S1052，参照S900～S952；
如果静态分区(B)加载成功，S1053，对动态分区+虚拟动态分区中需要加载的文件进行校验；例如，使用dmverity。
S1054，判断校验是否成功。
如校验失败，S1060，重启设备并回滚***，例如，从静态分区(A)启动。
如校验成功，执行S1055；
S1055，将静态分区(B)的数据同步到静态分区(A)；S1055的执行参照S511；
S1056～S1058，参照S960～S971。
进一步的，在S520之前，静态分区(A)与静态分区(B)中的数据一致，在S520之后，由于静态分区(B)的数据被更新，因此，静态分区(A)与静态分区(B)中的数据不一致。为确保静态分区(A)与静态分区(B)的数据一致，如图5所示，在S560之后，设备还执行S570，将静态分区(A)的数据同步到静态分区(B)。S570的执行参照S511。
可以理解的是，上述实施例中的部分或全部步骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照上述实施例呈现的不同的顺序来执行，并且有可能并非要执行上述实施例中的全部操作。
进一步的，一般的，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(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 (11)

1.一种操作***数据更新方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以运行第一操作***，所述第一操作***运行之后，所述方法包括：
基于所述第一操作***的版本号获取补丁包；
确认所述第一静态分区的数据与所述第二静态分区的数据是否一致；
在确认所述第一静态分区的数据与所述第二静态分区的数据一致后，根据所述补丁包更新所述第二静态分区中的数据；
将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；
重启所述电子设备；
加载所述基础分区、所述第二静态分区以及动态分区的数据以运行静态分区数据更新后的所述第一操作***。
2.根据权利要求1所述方法，其特征在于，所述方法还包括：
在确认所述第一静态分区的数据与所述第二静态分区的数据不一致后，将所述第一静态分区的数据同步到所述第二静态分区。
3.根据权利要求2所述方法，其特征在于，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
读取所述第一静态分区的各个子分区中的数据；
将所述第一静态分区的各个子分区中的数据覆写到所述第二静态分区对应的子分区中。
4.根据权利要求2所述的方法，其特征在于，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：
计算第三子分区的数据的哈希值，其中，所述第三子分区为所述第一静态分区的一个子分区；
计算第四子分区的数据的哈希值，其中，所述第四子分区为所述第二静态分区的一个子分区，并且，所述第四子分区与所述第三子分区相对应；
当所述第三子分区的数据的哈希值与所述第四子分区的数据的哈希值不一致时，将所述第三子分区中的数据覆写到所述第四子分区中。
5.根据权利要求1所述的方法，其特征在于，所述加载所述基础分区、所述第二静态分区以及动态分区的数据以运行静态分区数据更新后的所述第一操作***之后，所述方法还包括：
将所述第二静态分区的数据同步到所述第一静态分区。
6.根据权利要求1所述的方法，其特征在于，所述获取补丁包之前，所述方法还包括：
加载所述基础分区、所述第二静态分区以及所述动态分区的数据以运行第二操作***；
获取升级安装包，所述升级安装包包括静态分区升级文件；
基于所述静态分区升级文件升级所述第一静态分区的数据；
将所述电子设备的启动顺序由从所述第二静态分区启动，修改为从所述第一静态分区启动；
重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动；
加载所述基础分区、所述第一静态分区以及所述动态分区的数据，以运行所述第一操作***；
其中，在所述重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动之后，将所述第一静态分区的数据同步到所述第二静态分区。
7.根据权利要求6所述的方法，其特征在于，在加载所述动态分区的数据的过程中，在待加载动态分区文件校验成功后，将所述第一静态分区的数据同步到所述第二静态分区。
8.根据权利要求1～7中任一项所述的方法，其特征在于，所述补丁包包括更新定位描述以及更新数据，所述更新定位描述用于指定所述第二静态分区中需要进行数据更新的更新目标，所述更新数据用于描述所述第二静态分区的数据更新结果；
所述根据所述补丁包更新所述第二静态分区中的数据，包括：
根据所述补丁包中的更新定位描述以及更新数据，更新所述第二静态分区中的数据。
9.根据权利要求8所述的方法，其特征在于，所述基于所述第一操作***的版本号获取补丁包，包括：
获取第一路径；
为所述第一路径添加对应所述第二静态分区的目录名后缀，生成所述更新定位描述。
10.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得：
所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以运行第一操作***，
以及在所述第一操作***运行之后，执行如权利要求1～9中任一项所述的方法流程。
11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～9中任一项所述的方法。
CN202211524404.1A 2021-06-15 2021-06-15 操作***数据更新方法、设备及存储介质 Pending CN116069375A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211524404.1A CN116069375A (zh) 2021-06-15 2021-06-15 操作***数据更新方法、设备及存储介质

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211524404.1A CN116069375A (zh) 2021-06-15 2021-06-15 操作***数据更新方法、设备及存储介质
CN202110662973.1A CN113821235B (zh) 2021-06-15 2021-06-15 操作***数据更新方法、设备、存储介质及程序产品

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN202110662973.1A Division CN113821235B (zh) 2021-06-15 2021-06-15 操作***数据更新方法、设备、存储介质及程序产品

Publications (1)

Publication Number Publication Date
CN116069375A true CN116069375A (zh) 2023-05-05

Family

ID=78923883

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202211524404.1A Pending CN116069375A (zh) 2021-06-15 2021-06-15 操作***数据更新方法、设备及存储介质
CN202110662973.1A Active CN113821235B (zh) 2021-06-15 2021-06-15 操作***数据更新方法、设备、存储介质及程序产品

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202110662973.1A Active CN113821235B (zh) 2021-06-15 2021-06-15 操作***数据更新方法、设备、存储介质及程序产品

Country Status (4)

Country Link
US (1) US20240220226A1 (zh)
EP (1) EP4141651A4 (zh)
CN (2) CN116069375A (zh)
WO (1) WO2022262754A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116069375A (zh) * 2021-06-15 2023-05-05 荣耀终端有限公司 操作***数据更新方法、设备及存储介质
US11922158B2 (en) * 2021-06-25 2024-03-05 Intigua, Inc. Unified local patch repository
CN115543368B (zh) * 2022-01-10 2023-05-23 荣耀终端有限公司 一种操作***升级方法及电子设备
CN114265616B (zh) * 2022-03-02 2022-08-05 荣耀终端有限公司 操作***的升级方法、电子设备及存储介质
CN114661322B (zh) * 2022-03-11 2023-05-23 荣耀终端有限公司 操作***的升级方法、电子设备及存储介质
CN118113318A (zh) * 2022-11-30 2024-05-31 荣耀终端有限公司 一种操作***的升级方法及电子设备

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8286883B2 (en) * 2007-11-12 2012-10-16 Micron Technology, Inc. System and method for updating read-only memory in smart card memory modules
CN101477471B (zh) * 2009-01-07 2014-04-30 杭州海康威视数字技术股份有限公司 一种嵌入式***固件在线升级方法
TW201102924A (en) * 2009-07-03 2011-01-16 Inventec Appliances Corp Embedded electronic device and method for updating firmware thereof
CN103092662A (zh) * 2013-02-04 2013-05-08 烽火通信科技股份有限公司 一种基于嵌入式操作***的终端设备的软件模块升级方法
US8725995B1 (en) * 2013-11-04 2014-05-13 Symantec Corporation Systems and methods for updating system-level services within read-only system images
CN104182255B (zh) * 2014-08-20 2017-11-21 青岛海信宽带多媒体技术有限公司 一种***应用的库文件升级方法及终端
US9430223B2 (en) * 2014-09-25 2016-08-30 International Business Machines Corporation Live operating system update mechanisms
CN106055430A (zh) * 2016-05-27 2016-10-26 北京奇虎科技有限公司 云台摄像头的***备份更新方法及装置
CN106802813B (zh) * 2016-12-06 2020-04-17 智车优行科技（北京）有限公司 用于空中固件升级的方法、装置及车辆
CN107168731B (zh) * 2017-04-20 2020-06-02 北京小米移动软件有限公司 ***更新控制方法和装置
CN107967141B (zh) * 2017-11-27 2021-04-13 北京小米移动软件有限公司 操作***升级方法、装置及终端
CN109408153B (zh) * 2018-11-01 2022-03-01 百度在线网络技术（北京）有限公司 软件启动方法和软件升级方法
CN110175039A (zh) * 2019-04-26 2019-08-27 潍坊歌尔电子有限公司 在线升级方法、设备、可读存储介质及电子设备
CN110543321A (zh) * 2019-09-06 2019-12-06 深圳市英博超算科技有限公司 Ota升级方法、装置、终端以及计算机可读存储介质
CN110737453A (zh) * 2019-10-17 2020-01-31 北京智芯微电子科技有限公司 安全芯片的升级方法、装置及安全芯片
CN110780890B (zh) * 2019-10-24 2023-06-06 百度在线网络技术（北京）有限公司 ***升级方法、装置、电子设备和介质
CN111104148B (zh) * 2019-12-26 2023-06-16 红石阳光（北京）科技股份有限公司 集成有Linux和android两***的芯片平台的升级方法、***及可读存储介质
CN111522569B (zh) * 2020-05-09 2023-08-18 中瓴智行(成都)科技有限公司 基于Hypervisor的嵌入式多***升级方法及计算机可读存储介质
CN111694585A (zh) * 2020-06-02 2020-09-22 深圳Tcl数字技术有限公司 替换***分区文件的方法、***、终端和存储介质
CN112783537B (zh) * 2020-12-31 2023-03-03 浙江万胜智能科技股份有限公司 基于MTD存储设备的嵌入式linux操作***升级方法及***
CN112764627B (zh) * 2021-01-28 2022-08-26 青岛海信传媒网络技术有限公司 一种升级包安装进度显示方法及显示设备
CN116069375A (zh) * 2021-06-15 2023-05-05 荣耀终端有限公司 操作***数据更新方法、设备及存储介质

Also Published As

Publication number Publication date
US20240220226A1 (en) 2024-07-04
CN113821235A (zh) 2021-12-21
EP4141651A4 (en) 2024-01-24
CN113821235B (zh) 2023-10-20
WO2022262754A1 (zh) 2022-12-22
EP4141651A1 (en) 2023-03-01

Similar Documents

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