CN116701318B - 系统升级信息获取方法、电子设备及存储介质 - Google Patents

Abstract

本申请实施例涉及计算机技术领域，尤其涉及一种系统升级信息获取方法、电子设备及存储介质。在该方法中，通过在电子设备执行一次merge操作失败后，再执行一次merge操作。可以使得电子设备中的OUC能够在merge过程中，获取到升级打点数据；升级打点数据包括新增打点数据。同时，对于升级打点数据，如新增打点数据来讲，没有文件格式的配置要求；以及在后续也不需要解析格式文件后才能得到升级打点数据。使用这种方案，可以更加高效、便捷地获取到系统升级信息，并对系统升级信息进行扩展。

Description

系统升级信息获取方法、电子设备及存储介质

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种系统升级信息获取方法、电子设备及存储介质。

背景技术

在电子设备出厂前，电子设备的供应商会将操作系统烧录到电子设备中，从而实现在电子设备出厂前安装操作系统。此后，电子设备的供应商为了提升用户体验，可能需要对电子设备中的操作系统进行升级。

通常，在操作系统升级的过程中，电子设备会获取一些与操作系统升级相关的信息（下文可简称为系统升级信息）。在获取系统升级信息后，电子设备可以将该系统升级信息发送给电子设备供应商的服务器，以使得电子设备供应商可以基于该系统升级信息，对电子设备的系统升级过程进行优化；或者，将该系统升级信息展示给用户，以使得用户可以感知到电子设备的操作系统升级过程，执行一些操作。

目前，在操作系统升级的过程中，电子设备会以文件格式记录系统升级信息。以文件格式记录系统升级信息，会有一些文件格式的配置要求；以及，在后续使用时还需要对文件格式进行解析，这会比较复杂、繁琐。

发明内容

本申请实施例提供一种系统升级信息获取方法、电子设备及存储介质，可以更加高效、便捷、直接地获取到系统升级信息。

为达到上述目的，本申请的实施例采用如下技术方案：

第一方面，提供了一种系统升级信息获取方法，该方法可以应用于具有操作系统的电子设备。其中，电子设备可以是例如，手机、个人计算机、平板电脑等等具有操作系统的电子设备。该方法包括：

电子设备运行第一操作系统。接下来，电子设备运行第二操作系统的升级安装包。之后，电子设备关机；然后，电子设备开机。接下来，电子设备运行第二操作系统。而后，在第一时间点，电子设备执行第一落盘merge操作。接下来，在第二时间点，电子设备执行第一merge操作成功；第二时间点晚于第一时间点。然后，在第三时间点，电子设备启动在线升级客户端OUC；第三时间点晚于第一时间点。接下来，电子设备运行第三操作系统的升级安装包。之后，电子设备关机；然后，电子设备开机。接下来，电子设备运行第三操作系统。然后，在第四时间点，电子设备执行第二merge操作。而后，在第五时间点，电子设备执行第二merge操作完成，且第二merge操作失败；第五时间点晚于第四时间点；在第六时间点，OUC启动完成，第六时间点晚于第四时间点。接下来，在第七时间点，电子设备执行第三merge操作；第七时间点晚于第六时间点。其中，升级打点数据可以是电子设备在执行merge操作的过程中，基于打点位生成的。以及，上述merge操作（如，第一merge操作、第二merge操作或第三merge操作）可以包括：将电子设备的（用户数据分区中的）虚拟动态分区保存的升级文件，写入到电子设备的动态分区。

在第一方面所描述的方法中，OUC在第二merge操作执行之后才启动，考虑到电子设备在执行第二merge操作时，OUC可能没有启动，也就是说OUC难以在第二merge操作时获取到完整的系统升级信息。基于此，在OUC启动完成后，在第二merge操作失败的情况下，电子设备触发再次执行merge操作，也就是执行第三merge操作。这样，在OUC启动完成后，电子设备就可以执行完整的merge操作过程。那么，OUC就能够在执行merge的过程中直接地获取到完整的系统升级信息（如，升级打点数据），而不用解析文件格式后再从文件中获取系统升级信息。可见，这种方式可以便捷、高效地、直接地获取到系统升级信息。

相比于在一些方案中，以文件（如，系统升级记录文件）作为媒介获取新增加的系统升级信息，需要对新增加的系统升级信息进行格式处理，以满足文件格式的配置要求。以及，在后续使用新增加的系统升级信息时，还需要从文件格式中解析出新增加的系统升级信息。在第一方面中，不需要将新增加的系统升级信息写入系统升级记录文件，以及，在后续也不需要对文件进行解析，电子设备能够直接地获取到新增加的系统升级信息。

可见，在第一方面中，通过在电子设备执行第二merge操作失败后，再执行一次merge操作。可以使得OUC能够在merge过程中，获取到新增加的系统升级信息。同时，对于新增加的系统升级信息来讲，没有文件格式的配置要求；以及在后续也不需要解析格式文件后才能得到新增加的系统升级信息。使用这种方案，可以更加高效、便捷地对系统升级信息进行扩展。

在第一方面的一种可能的设计中，上述方法还包括：在执行第三merge操作的过程中，OUC从缓存中获取升级打点数据。

在这种设计方式中，电子设备中的OUC获取升级打点数据是从缓存中获取的，如果需要在merge过程中新增打点位，使得在merge过程中运行到新增打点位时，生成新增打点数据，OUC就可以直接从缓存中获取新增升级打点数据。也就是说，OUC是通过以缓存为媒介获取的升级打点数据。相比于在一些方案中，以文件（如，系统升级记录文件）作为媒介将新增打点数据传递给OUC，需要对新增打点数据进行格式处理，以满足文件格式的配置要求；以及，在后续使用升级打点数据时，还需要从文件格式中解析出升级打点数据。在这种设计中，通过使用缓存作为媒介，不需要对升级打点数据进行格式处理，也无需满文件格式的配置要求；以及，OUC从缓存中获取到的是比较原始的数据；不需要对新增打点数据进行格式处理，就可以将新增打点数据传递给OUC。同时，后续使用升级打点数据时，无需从文件格式中解析出升级打点数据，OUC从缓存中获取的升级打点数据可以直接被使用。同时，考虑到，OUC可能会在merge过程中启动；以及，在merge过程中，在后生成的升级打点数据会在缓存中会覆盖掉在先生成的升级打点数据；也就是说，缓存中的升级打点数据是会变化的；可见，OUC在merge过程中启动的情况下，OUC可能获取不到完整的打点数据。由此在OUC启动后，执行第二merge操作，可以使得OUC可以在完整的merge过程中获取升级打点数据；那么OUC就可以获取到完整的升级打点数据。

可见，在这种设计方式中，电子设备的OUC通过从缓存中获取升级打点数据，可以很方便增加打点位，可以很便捷地对升级打点数据进行扩展。以及，由于OUC从cache中获取的升级打点数据是比较原始的升级打点数据，没有文件格式要求，也不需要解析格式文件后才能得到升级打点数据，会更加便于后续对升级打点数据的使用。

在第一方面的一种可能的设计中，上述OUC从缓存中获取升级打点数据，可以包括：OUC监测缓存中的目标存储区域，若目标存储区域发生数据变化，则OCU从目标存储区域中获取升级打点数据；目标存储区域是电子设备执行merge操作的过程中写入升级打点数据的存储区域。

在第一方面的一种可能的设计中，上述方法还包括：若上述第三merge操作成功，则电子设备中的升级引擎生成升级结果文件（如，升级成功文件），OUC获取升级结果文件（如，升级成功文件）；该升级结果文件（如，升级成功文件）用于指示升级成功，且未包括升级打点数据。在这种设计中，由于升级结果文件中未包括升级打点数据，也就是说，升级结果和升级打点数据时分离的，不会在一个文件中。这会使得升级结果文件中的系统升级信息比较简洁，在后续使用起来比较方便。当电子设备只需要升级结果时，就可以通过搜索升级结果文件的方式直接获取到升级结果。相比于一些方案中，在手机生成的系统升级记录文件中，系统升级记录文件中同时存在升级结果信息和升级打点数据，手机需要对升级记录文件解析，并从解析后的系统升级记录文件中，滤除升级打点数据，提取出升级结果。本方案中，不需要解析包含升级结果信息和升级打点数据的升级记录文件，只需要解析升级结果文件，就可以直接获取到升级结果文件中的升级结果。也就是说，手机获取升级结果的过程不会被升级打点数据干扰。可见，在本申请实施例提供的方法中，通过将升级结果和升级打点数据分离，可以使得电子设备可以直接、准确、高效地获取到系统升级的结果，更加便于对系统升级信息的利用。

在第一方面的一种可能的设计中，上述第一merge操作成功包括：若第一merge操作成功，则所述电子设备中的升级引擎生成升级结果文件，所述OUC获取所述升级结果文件，所述升级结果文件用于指示升级成功，所述升级结果文件未包括升级打点数据。

在第一方面的一种可能的设计中，上述方法还包括：若第二merge操作成功则，则电子设备中的升级引擎生成升级结果文件，OUC获取升级结果文件，升级结果文件用于指示升级成功。以及，上述电子设备执行第三merge操作，可以包括：若OUC未获取到升级结果文件，所述第二merge操作失败，则OUC指示电子设备中的升级引擎执行第三merge操作。

在第一方面的一种可能的设计中，上述电子设备执行第一merge操作，包括：若电子设备加载第一静态分区中的第二操作系统成功，则电子设备执行第一merge操作。上述方法还包括：若电子设备加载第一静态分区中的第二操作系统失败，则加载第二静态分区中的第一操作系统。电子设备中的升级引擎生成升级结果文件（如，系统回滚文件），OCU获取升级结果文件（如，系统回滚文件），升级结果文件（系统回滚文件）用于指示操作系统发生回滚，且该升级结果文件未包括升级打点数据。

在这种设计中，如果电子设备发生了系统回滚，以第一静态分区运行，则电子设备会生成升级结果文件。这样，后续就可以通过升级结果文件获取到，电子设备上的系统升级失败，发生了系统回滚。

在第一方面的另一种可能的设计中，上述电子设备生成升级结果文件，可以包括：电子设备获取电子设备正在运行的操作系统的版本号，若该版本号是第一操作系统的版本号，则生成用于指示操作系统发生回滚的升级结果文件。

在第一方面的另一种可能的设计中，上述方法还包括：在第五时间点晚于第四时间点的情况下，在电子设备启动OUC启动完成后，若电子设备确定上述第二merge操作正在执行，则OUC等待第二merge操作执行完成（失败或成功）。其中，电子设备可以通过升级打点数据、merge数据或者预设的接口确定该第一merge操作正在执行。

在这种设计中，通过打点数据、merge数据或预设的接口等来判断是否正在进行merge操作。可以很便捷地判断电子设备是否正在执行merge操作。

在第一方面的又一种可能的设计中，电子设备还可以将获取到的升级结果文件或升级打点数据发送给服务器（例如，该电子设备供应商的服务器）。这样，就可以基于升级打点数据对电子设备的merge过程进行修复。或者，就可以基于升级结果文件得知电子设备的系统升级结果。

第二方面，提供了又一种系统升级信息获取方法，该方法可以应用于具有操作系统的电子设备。其中，电子设备可以是例如，手机、个人计算机、平板电脑等等具有操作系统的电子设备。该方法包括：电子设备运第四操作系统。接下来，电子设备运行第五操作系统的升级安装包。之后，电子设备关机。接下来，电子设备开机。然后，电子设备运行第五操作系统。而后，在第八时间点，电子设备启动在线升级客户端OUC。接下来，响应于OUC启动完成，在第九时间点，电子设备执行落盘merge操作；第九时间点晚于第八时间点。其中，电子设备执行merge操作的过程中，OUC从缓存中获取升级打点数据。

在第二方面所述的方法中，考虑到，OUC可能会在merge过程中启动；以及，在merge过程中，在后生成的升级打点数据会在缓存中会覆盖掉在先生成的升级打点数据；也就是说，缓存中的升级打点数据是会变化的；可见，OUC在merge过程中启动的情况下，OUC可能获取不到完整的打点数据。由此在OUC启动完成后，再执行merge操作，这样可以使得OUC可以在完整的merge过程中获取升级打点数据；那么OUC就可以获取到完整的升级打点数据。

第三方面，提供了另一种系统升级信息获取方法，该方法可以应用于具有操作系统的电子设备，该方法包括：电子设备运行第一操作系统。接下来，电子设备运行第二操作系统的升级安装包。之后，电子设备关机，电子设备开机。然后，电子设备运行上述第二操作系统。而后，电子设备执行第四merge操作；接下来，电子设备启动在线升级客户端OUC。之后，若电子设备执行第四merge操作失败，则执行第五merge操作。然后，在执行第五merge操作的过程中，电子设备的OUC从缓存中获取升级打点数据。

在第三方面的一种可能的设计中，上述方法还包括：若第五merge操作成功，则电子设备的升级引擎生成升级结果文件，电子设备的OUC获取升级结果文件（如，升级成功文件），升级结果文件（升级成功文件）用于指示电子设备的第五操作系统升级成功，升级结果文件未包括升级打点数据。或者，若第五merge操作失败，则电子设备保存在执行第五merge操作的过程中，OUC从缓存中获取到的升级打点数据。或者，若第五merge操作成功，则电子设备的升级引擎生成升级结果文件，电子设备的OUC获取升级结果文件，升级结果文件用于指示升级成功，升级结果文件未包括升级打点数据。

在第三方面的又一种可能的设计中，上述电子设备的OUC从缓存中获取升级打点数据，可以包括：电子设备的OUC监测缓存中的目标存储区域，若目标存储区域发生数据变化（如，数据修改、增加数据等），则电子设备的OCU从目标存储区域中获取升级打点数据。该目标存储区域是缓存中的且电子设备在执行merge操作的过程中写入升级打点数据的存储区域。

在第三方面的另一种可能的设计中，在电子设备启动在线升级客户端OUC启动完成后，若电子设备确定上述第四merge操作正在执行，则电子设备等待第四merge操作执行完成。之后，若第五merge操作失败，则电子设备执行第五merge操作。其中，电子设备可以通过升级打点数据、merge数据或者预设的接口确定该第四merge操作正在执行。

在第三方面的又一种可能的设计中，电子设备还可以将获取到的升级结果文件或升级打点数据发送给服务器（例如，该电子设备供应商的服务器）。这样，就可以基于升级打点数据对电子设备的merge过程进行修复。或者，就可以基于升级结果文件得知电子设备的系统升级结果。

第四方面，提供了一种电子设备，电子设备包括处理器以及存储器，存储器包括第一静态分区、第二静态分区、动态分区和用户数据分区，处理器用于执行存储器上存储的计算机指令，使得电子设备执行上述第一方面以及第一方面任一种可能的设计所提供的方法；或者，使得电子设备执行上述第二方面以及第二方面任一种可能的设计所提供的方法；或者，使得电子设备执行上述第三方面以及第三方面任一种可能的设计所提供的方法。

第五方面，提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当计算机指令在电子设备上运行时，使得电子设备执行上述第一方面以及第一方面任一种可能的设计所提供的方法；或者，使得电子设备执行上述第二方面以及第二方面任一种可能的设计所提供的方法；或者，使得电子设备执行上述第三方面以及第三方面任一种可能的设计所提供的方法。

第六方面，提供了一种包含指令的计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面以及第一方面任一种可能的设计所提供的方法；或者，使得电子设备执行上述第二方面以及第二方面任一种可能的设计所提供的方法；或者，使得电子设备执行上述第三方面以及第三方面任一种可能的设计所提供的方法。

其中，第三至第四方面中任一种设计方式所带来的技术效果可参见第一方面以及第二方面中不同设计方式所带来的技术效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种使用场景示意图；

图2为本申请实施例提供的一种电子设备的结构示意图；

图3为本申请实施例提供的一种电子设备的软件结构示意图；

图4为本申请实施例提供的一种数据存储结构示意图；

图5为本申请实施例提供的系统升级信息获取方法的一种流程示意图；

图6为本申请实施例提供的操作系统升级的一种流程示意图；

图7为本申请实施例提供的操作系统升级的又一种流程示意图；

图8为本申请实施例提供的操作系统升级的又一种流程示意图；

图9为本申请实施例提供的操作系统升级的又一种流程示意图；

图10为本申请实施例提供落盘操作的一种流程示意图；

图11为本申请实施例提供的系统升级信息获取方法的又一种流程示意图；

图12为本申请实施例提供的系统升级信息获取方法的又一种流程示意图；

图13为本申请实施例提供的电子设备的又一种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“/”表示前后关联的对象是一种“或”的关系，例如，A/B可以表示A或B；本申请中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A，B可以是单数或者复数。并且，在本申请实施例的描述中，除非另有说明，“多个”是指两个或多于两个。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项（个）或复数项（个）的任意组合。例如，a，b，或c中的至少一项（个），可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

同时，在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念，便于理解。

在电子设备中，操作系统是最基本也是最为重要的基础性系统软件。电子设备在安装操作系统的情况下，才能被用户使用。以电子设备是手机为例，手机上需要安装手机操作系统，如苹果移动设备操作系统（iPhone Operation System，IOS™）、安卓（Android™）系统等，才可以被用户使用。

在电子设备出厂前，电子设备的供应商会将操作系统烧录到电子设备中，从而实现在电子设备出厂前安装操作系统。此后，电子设备的供应商为了提升用户体验，可能需要对电子设备中的操作系统进行升级。

通常，在操作系统升级的过程中，电子设备会获取一些与操作系统升级相关的信息（下文可简称为系统升级信息）。其中，升级信息可以包括：升级打点数据或升级结果。在获取了系统升级信息后，电子设备可以将该系统升级信息发送给电子设备供应商的服务器，以使得电子设备供应商可以基于该系统升级信息，对电子设备的系统升级包进行优化；或者，将该系统升级信息展示给用户，以使得用户可以感知到电子设备的操作系统升级过程或升级结果；或者，如果，电子设备的操作系统升级失败，电子设备可以基于该系统升级信息对电子设备的操作系统升级过程进行诊断并修复。

在一些方案中，在操作系统升级的过程中，电子设备可以通过文件格式记录系统升级信息；如，将系统升级信息记录到系统升级记录文件中。可以理解的，以文件格式记录升级信息，会有一些文件格式的配置要求，比较复杂。同时，在后续使用时，还需要对文件格式进行解析，如对系统升级记录文件进行解析，解析后才能获取到系统升级记录文件中的系统升级信息。

如果需要对系统升级信息进行扩展，如，新增（减少）系统升级信息；又如，新增升级打点数据或减少升级打点数据。电子设备需要针对这些新增加的系统升级信息额外配置文件格式以及该文件格式对应的解析方式。也就是说，电子设备需要对这些新增加的系统升级信息，进行一些处理，以满足文件格式的配置要求。以及，以文件格式记录系统升级信息，在后续使用系统升级信息时，需要对文件格式解析后，才能读取到文件格式中记录的内容，这会比较复杂。

如，系统升级记录文件是键值对（key-value，kv）的文件格式（下文可简称为kv格式）。电子设备以kv格式记录系统升级信息，会有kv格式的配置要求；以在，后续使用时还需要对kv格式进行解析才能获取到系统升级记录文件中记录的内容。电子设备若要增加升级打点数据，电子设备需要先声明一个新的键，之后将新增加的升级打点数据写入到这个新的键对应的值中。以及，在电子设备供应商的服务器接收到系统升级记录文件后，也需要对应配置，对系统升级记录文件中新的键对应的解析方式，才能获取到新增加的升级打点数据。可见，这种以文件格式记录系统升级信息的方式不利于对系统升级信息进行扩展。

以及，在上述系统升级记录文件中会写入升级打点数据和升级结果，这会造成升级打点数据和升级结果杂糅在一起。如果电子设备只需要获取升级结果，不需要获取升级打点数据；则由于系统升级记录文件中既包括了升级打点数据又包括了升级结果，那么电子设备就需要先对升级记录文件的文件格式进行解析；之后从解析后的系统升级记录文件中，滤除升级打点数据，提取出升级结果。以及，由于升级打点数据的数据量可能会远多于升级结果的数据量，也就是说，电子设备需要在数据量比较多的升级打点数据中，筛选出升级结果。可见，在系统升级记录文件中写入升级打点数据和升级结果，会导致电子设备获取升级结果的过程比较繁琐，且耗时较长。

可见，在上述方案中，获取以文件格式记录系统升级信息的方式不利于对系统升级信息进行扩展，也不利于对系统升级信息的准确获取以供后续使用。

有鉴于此，本申请实施例提供一种系统升级信息获取方法，在该方法中，电子设备通过将升级结果和升级打点数据分离，可以便于后续对系统升级信息的使用；以及，在该方法中，电子设备通过以缓存为媒介获取升级打点数据，也就是，对升级打点数据来讲不存在文件格式的解析要求，可以很方便地对升级打点数据进行扩展。

本申请实施例提供的系统升级信息获取方法，可以应用于对电子设备100进行操作系统升级的场景下。

示例性的，参见图1，电子设备100可以通过空中下载技术（Over-the-AirTechnology，OTA），接收电子设备100的供应商发送给电子设备100的系统升级包（下文可简称为，升级包）。接下来，电子设备100基于升级包对电子设备100上的操作系统进行升级。如，电子设备100通过OTA技术下载了新版本的升级包；之后，电子设备100将旧版本的操作系统升级为新版本的操作系统。在操作系统升级过程中，电子设备100可以根据预先配置好的打断点，获取操作系统升级过程中的打点数据。并且电子设备还可以在系统升级结束后，获取电子设备100的升级结果。也就是说，电子设备100可以获取，在操作系统升级过程中的系统升级信息。之后，电子设备100可以将该系统升级信息发送给服务器（如，电子设备100的供应商的服务器），使得电子设备100的供应商可以基于该系统升级信息，对其发布的升级包进行优化；或者将系统升级信息展示给用户，使得用户可以感知到电子设备100的升级过程，并做出相应的操作（如，重启电子设备100等等）。

需要指出的是，在图1所示的场景下，电子设备100也可以通过，通用串行总线(universal serial bus，USB)接口，或者移动存储设备（如，U盘（USB flash disk））等，获取电子设备的供应商发布的升级包。本申请实施例对电子设备100获取升级包的方式不做任何限制。

可以理解的，上述电子设备可以是手机、平板电脑、可穿戴设备、智慧屏、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personaldigital assistant，PDA)等具有操作系统的电子设备；也可以是，智能手表、智能手环等等具有操作系统的物联网设备，还可以是，车载电脑、车载控制器等具有操作系统的车载设备。本申请实施例对电子设备的具体类型不作任何限制。其中，上述操作系统包括但不限于iOS®、Android®、Windows®、Linux®或者其它操作系统。

图2示出了电子设备100的硬件结构示意图。

如图2所示，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，电源管理模块141，天线，无线通信模块150，显示屏140等。

可以理解的是，本发明实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

无线通信模块150可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。

显示屏140用于显示图像，视频等。显示屏140包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。例如，在本申请实施例中，处理器110可以通过执行存储在内部存储器121中的指令，内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100提供电能，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

示例性的，电子设备100可以通过无线通信模块150和天线等，获取升级包。并将该升级包写入内部存储器121或者与外部存储器接口120连接的外部存储器中。又示例性的，电子设备100可以通过USB接口130获取升级包，并将该升级包写入内部存储器121，或者与外部存储器接口120连接的外部存储器中。

示例性的，电子设备100可以通过处理器110，基于获取到的升级包执行操作系统升级的过程，并生成系统升级信息。接下来，电子设备100可以通过无线通信模块150和天线，或者通过USB接口130将系统升级信息发送给电子设备100的供应商的服务器。或者，电子设备也可以通过显示屏140，向用户展示系统升级信息。

图3示出了本申请实施例的电子设备100的软件结构（架构）示意图。分层架构可将软件分成若干个（架构）层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，可以将Android™系统分为四层，从上至下分别为应用程序层(可以简称为应用（application，APP）层，应用程序框架层(简称框架层，(framework，FWK))，本地(native)层以及内核（kernel）层。例如，如图3所示，电子设备100可以包括应用层、框架层、本地层和内核层。

可以理解的是，图3示出的软件结构，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的架构层，或者组合某些架构层，或者拆分某些架构层等等。对于Android™系统也可以有其他的层级划分方式，例如，划分为：应用程序层（可简称为，应用层）、应用程序框架层、系统库、内核层等等。以及，对于不同的操作系统也可以有不同的层级划分方式，技术人员具体可以根据实际的使用情况对操作系统进行不同层级的划分。

其中，应用层可以包括一系列应用程序包。如图3所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频等应用程序。

其中，应用层还可以包括系统升级应用，例如，在线升级客户端（online updateclient，OUC）。

示例性的，电子设备可以通过OUC获取升级包。后续，电子设备也可以通过OUC向用户展示升级结果。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。例如，应用程序层可以包括系统服务和媒体服务。

系统服务(system server)是一个进程，提供了很多子系统服务，每个子系统服务都以线程的形态运行，等待应用程序发出的请求，然后对请求进行处理，再将结果返回给应用程序。上述子系统服务例如包括窗口管理服务(window manager service，WMS)、通知管理服务(notification manager service，NMS)、活动管理服务(activity managerservice，AMS)、输入管理服务(input manager service，IMS)等。

本地层，也可被称为系统运行库层，可以包含多个功能模块。例如；表面管理器(surface manager)，媒体库(Media Libraries)，三维(3D)图形处理库(例如：OpenGL ES)，二维（2D）图形引擎(例如：SGL)和安卓™运行时（Android™ runtime，ART）。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如: MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。

Android™Runtime包括核心库和虚拟机。Android™Runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

其中，本地层还可以包括升级引擎（update_engine），示例性的，电子设备可以通过升级引擎，在系统升级过程中，执行虚拟A/B安装或者执行落盘的过程。

内核驱动层，也可被称为内核层，是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

示例性的，电子设备可以通过系统服务，启动上述OUC、或者升级引擎。

以安卓™系统为例，图4所示为根据本申请实施例提供的一种数据存储结构示意图。如图4所示，安卓系统数据存储区包含基础分区（common）、静态分区（A）、静态分区（B）、动态分区（super）、用户数据分区（userdata）。

用户数据分区（userdata）用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础部分中保存的数据为不参与操作系统升级的系统数据。静态分区（A）与静态分区（B）的结构相互对应，子分区命名通过后缀_a以及_b相互区分。例如，静态分区（A）包括：boot_a、vendor_boot_a、dtbo_a、vbmeta_a；静态分区（B）包括：boot_b、vendor_boot_b、dtbo_b、vbmeta_b。动态分区（Super）包含多个子分区。例如，记录着A1数据的S1分区、记录着B1数据的S2分区、记录着C1数据的S3分区、记录着D1数据的S4分区、记录着E1数据的S5分区、记录着F1数据的S6分区。可以理解的，在电子设备进行操作系统升级时，需要升级静态分区和动态分区中的文件（数据），基础分区和用户数据分区中的文件不需要升级。

在电子设备启动时，电子设备会从一个静态分区启动。例如，电子设备从静态分区（A）启动：依次加载基础分区（common）、静态分区（A）以及动态分区（super）。又例如，电子设备从静态分区（B）启动：依次加载基础分区（common）、静态分区（B）以及动态分区（super）。

以采用主引导记录（master boot record，MBR）格式的通用闪存（universalflash storage，UFS）为例。在UFS的MBR（主引导扇区，UFS的第一个扇区，即C/H/S地址的0柱面0磁头1扇区）中，保存有设备启动顺序（例如，手机启动顺序）的描述。设备启动顺序可以用于指示从静态分区（A）启动（启动顺序标志为A）或从静态分区（B）启动（启动顺序标志为B）。设备启动后首先从UFS的MBR中读取设备启动顺序。并按照读取到的设备启动顺序依次启动（加载）各数据分区。MBR通常记录在基础分区（common）中。当然，在不同平台中，MBR也可以记录在不同的位置，本申请实施例对此不作具体限定。

可以理解的是，图4示出的数据分区的划分方式，并不构成对电子设备100数据存储分区的具体限定。在本申请另一些实施例中，也可以对电子设备100的数据存储分区进行不同形式的划分。电子设备100可以包括比图示更多或更少的数据分区，或者组合某些数据分区，或者拆分某些数据分区等等。具体可以根据实际的使用情况对电子设备100数据存储分区的划分方式进行设计，本申请实施例对此不做任何限制。

下面，将以图1所示的使用场景中，电子设备100是手机为例，对本申请实施例提供的技术方案进行介绍。

假设手机上正在运行的是旧版本的操作系统（例如，版本1.1），需要升级到新版本的操作系统（例如，版本1.2）。手机可以根据图5所示的流程实现操作系统的升级，并获取系统升级信息。

示例性的，参见图5，本申请实施例提供的系统升级信息获取方法，可以包括步骤S500-S512。

S500.手机加载基础分区（common）、静态分区（A），从静态分区（A）启动，从而以版本1.1启动运行。

示例性的，参见图6，手机可以依次加载基础分区（common）、静态分区（A）、动态分区和用户数据分区，以从静态分区（A）启动。也就是说，手机以旧版本的操作系统，也就是版本1.1的操作系统启动运行。

可以理解的，由于手机此时还没有获取到升级包，因此手机的静态分区（A）、静态分区（B）和动态分区中存储的应是旧版本的操作系统，如版本1.1的操作系统。由于此时手机的静态分区（A）、静态分区（B）中均是旧版本的操作系统，也就是说，手机也可以以静态分区（B），启动版本1.1的操作系统。下面，为了便于表述，将以手机以静态分区（A）启动并运行版本1.1的操作系统为例进行介绍。

S501.OUC获取升级包。

在一些实施例中，OUC可以定期的向搜包服务器发起搜包请求，搜包请求包含手机当前运行的操作系统的版本号（例如，版本1.1）；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否存在新版本的操作系统的升级包（例如，版本1.2）；当存在新版本的操作系统的升级包时，搜包服务器向设备反馈升级包（例如，由版本1.1升级到版本1.2的操作系统升级包）的下载地址；设备根据升级包的下载地址下载升级包。

其中，该升级包可以是全量系统升级包或者差量系统升级包；全量升级包，可以理解为，包含了版本1.2的全量数据的系统升级包。差量系统升级包，可以理解为，包含了版本1.2与版本1.1之间差异数据的系统升级包。假设，版本1.2的动态分区中包括：A2、B1、C1、D2、E1和F1；版本1.1的动态分区中包括：A1、B1、C1、D1、E1和F1。则全量系统升级包可以指的是，包括了A2、B1、C1、D2、E1和F1的系统升级包。差量系统升级包可以指的是，包括了A2和D2的系统升级包。具体可以根据实际的使用需求对升级包的类型进行设计，本申请实施例对此不做任何限制。

在一些实施例中，OUC也可以通过手机的USB接口获取升级包；以及，OUC还可以通过外部存储器接口，获取安装在存储介质（如，U盘）上的升级包等等。具体可以根据实际的使用需要对OUC获取升级包的方式进行设计，本申请实施例对此不做任何限制。

S502.升级引擎基于升级包进行虚拟A/B安装。

可以理解的，由于手机此时正在运行，手机无法修改数据分区中正在使用的文件。也就是说，如果手机是从静态分区（A）启动的，则升级引擎可以将升级包中包含版本1.2的静态分区数据写入到静态分区（B）中。如果手机是从静态分区（B）启动的，则升级引擎可以将升级包中包含版本1.2的静态分区数据写入到静态分区（A）中。

以及，对于升级包中包含版本1.2的动态分区数据，升级引擎可以在用户数据分区中，创建虚拟动态分区；并将升级包中包含版本1.2的动态分区数据写入到虚拟动态分区中。

之后，升级引擎修改手机启动顺序。可以理解的，手机启动顺序是指，手机启动（加载）数据分区的顺序。

示例性的，OUC可以通过调用mutipayloads接口，指示升级引擎（update_engine）执行虚拟A/B安装。之后，update_engine在虚拟A/B安装完成后，通过mutipayloads接口向OUC回调虚拟A/B安装结果（如，虚拟A/B安装成功，或虚拟A/B安装成功失败）。

在一些实施例中，参见图7，上述步骤S502可以包括步骤S5021-S5023。

S5021.升级引擎根据升级包，针对静态分区（B）进行数据写入操作以升级静态分区。

示例性的，参见图8，如果版本1.1升级到版本1.2的升级包包含版本1.2的静态分区的全量数据，升级引擎将版本1.2的静态分区的数据覆写到静态分区（B）中。以使得静态分区（B）中的数据升级为，版本1.2的静态分区数据。

可以理解的，如果此时手机是以静态分区（B）运行版本1.1的操作系统，也可以将升级包包含的版本1.2的静态分区的升级数据写入到静态分区（A）中，本申请实施例对此不做限制。

S5022.升级引擎根据升级包在用户数据分区（userdata）创建虚拟动态分区，在虚拟动态分区写入动态分区（super）的升级数据。

例如，如果升级包中包含版本1.2的动态分区（super）的全量数据，则升级引擎在用户数据分区中写入版本1.2的动态分区（super）的全量数据，并在用户数据分区中创建版本1.2的虚拟动态分区，该虚拟动态分区中包括了版本1.2的动态分区的全量数据。

在一些实施例中，在升级引擎进行虚拟A/B安装中，如果针对动态分区（super），采用差量升级方式。在升级过程中，用户数据分区（userdata）的虚拟动态分区中保存的并不是升级后新版本的动态分区（super）的全部文件，而是旧版本的动态分区（super）中需要升级的数据在升级后的升级结果。即，用户数据分区（userdata）的虚拟动态分区中保存的是动态分区（super）的升级数据。

在一些实施例中，在升级引擎进行虚拟A/B安装中，升级引擎也可以基于快照技术（snapshot）实现动态分区（super）的增量升级。具体的，用户数据分区（uerdata）的虚拟动态分区中，采用写时拷贝（Copy-On-Write，COW）文件保存动态分区（super）的升级数据。这样，在后续加载虚拟动态分区时，手机就可以通过snapshot加载用户数据分区中的COW文件和动态分区中的文件，以加载虚拟动态分区。

示例性的，再次参见图8。假设版本1.2相比于版本1.1，只更新了动态分区（super）中S1的数据A1和S4中的数据D1。如，将A1更新为A2，将D1更新为D2。也就是说，版本1.1中动态分区的S1中的数据是A1，动态分区的S4中的数据是D1；而版本1.2动态分区的S1中的数据是A2，动态分区S4中的数据是D2。

基于此，升级引擎在用户数据分区创建虚拟动态分区时，为了节约用户数据分区的空间。可以只在用户数据分区创建针对动态分区S1和动态分区S4的虚拟动态分区。并将数据A2的地址设置为与A1的地址S1对应的S1-1；将数据D2的地址设置为与D1的地址S4对应的S4-1。之后，在后续使用版本1.2时，通过snapshot，加载A2、B1、C1、D2、E1、F1。以运行版本1.2的操作系统。

S5023.升级引擎将手机启动顺序由从静态分区（A）启动变更为从静态分区（B）启动。

例如，升级引擎可以改写主引导记录（master boot record，MBR）的启动顺序标识，将启动顺序标识由A改写为B。在手机上电后，当手机读取到启动顺序标识为A，手机从静态分区（A）启动，启动过程中加载静态分区（A）；当手机读取到启动顺序标识为B，手机从静态分区（B）启动，启动过程中加载静态分区（B）。

在一些实施例中，上述步骤S5023还可以包括：升级引擎（update engine）修改卡槽（slot）。

示例性的，再次参见图8，在基础分区，或者静态分区中，可以包含对应静态分区（A）的卡槽0（slot0）以及静态分区（B）的卡槽1（slot1）。slot0以及slot1用于保存super分区的分区表。

例如，在UFS的MBR中，设备启动顺序描述中，配置slot0对应从静态分区（A）启动，配置slot1对应从静态分区（B）启动。在手机启动时，根据启动的静态分区的不同，选择从slot0或slot1中的一个中获取super分区的分区信息。以手机当前从静态分区（A）启动为例，在加载动态分区（super）时，手机读取slot0，以获取动态分区（super）的子分区地址（例如，以加载S1、S2、S3、S4、S5、S6的方式加载动态分区）。在手机由静态分区B启动时，在加载super分区时，手机读取slot1，以获取动态分区（super）的子分区地址。（例如，以加载S1-1、S2、S3、S4-1、S5、S6的方式加载动态分区）。

S503.手机重启。

在一些实施例中，手机上的系统服务（system server）也可以在上述步骤S510升级引擎完成虚拟A/B安装后（如修改手机启动顺序完成后），system server指示手机掉电关机，手机退出当前的操作系统。接下来，手机再开启电源，手机上电。

在一些实施例中，在步骤S520时，手机可以不需要立即重启，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。示例性的，手机可以通过弹窗，或者通知消息等形式提示用户，手机上的虚拟A/B安装已经完成。之后，手机响应于用户对手机的重启操作，手机执行重启。

S504.手机依次加载基础分区、静态分区（B），以及加载动态分区和用户数据分区中的虚拟动态分区，从而使得手机以版本1.2启动运行。然后，手机执行S505a-S506a，或者执行S505b-506b以及后续步骤。

在一些实施例中，可以由手机上的加载引导程序（bootloader），加载基础分区、静态分区（B）。接下来，bootloader读取静态分区（B）对应的slot1，并基于slot1使用snapshot从动态分区或虚拟动态分区中的COW文件中提取相应的文件进行加载。

其中，加载引导程序（bootloader）可以是一段固化在手机处理器上的代码程序，通过该程序可以加载数据分区，并依次加载手机不同软件架构层中的功能模块；以实现手机的开机，使得手机可以进入用户交互界面。如，bootloader可以先加载内核层中的功能模块（如，显示驱动、音频驱动、操作系统内核等等）。之后，内核层（如，操作系统内核）加载本地层中的功能模块（如，升级引擎、表明管理器等等）。接下来，内核层（如，操作系统内核）加载框架层中的功能模块（如，系统服务、媒体服务等等）。再之后，内核层（如，操作系统内核）加载应用层中的功能模块（如，相机应用、OUC应用等等）。可见，在手机重启后，手机上的升级引擎可能会早于OUC启动。

示例性的，参见图9，假设slot在手机的基础分区中。bootloader读取MBR中的启动顺序标识。如，读取得到手机从静态分区（B）启动。之后，bootloader加载基础分区，并从加载的基础分区中，读取slot1。接下来，bootloader加载静态分区（B）。然后，bootloader在静态分区（B）加载完成后，bootloader基于slot1通过snapshot加载动态分区和用户数据分区中的COW文件，以加载虚拟动态分区。在虚拟动态分区加载完成后，bootloader加载用户数据分区。

示例性的，bootloader在加载数据分区，以及加载并启动软件架构层中的功能模块之后，手机会进入用户交互界面。此时，手机启动标志位是“启动成功”。例如，boot_complete的值为1。

S505a.若手机以静态分区（B）启动不成功，则加载引导程序（bootloader）执行系统回滚，以静态分区（A）启动。

在一些实施例中，引导加载程序（bootloader）可以记录以静态分区（B）启动的次数，如引导加载程序发现以静态分区（B）启动的次数大于或等于预设阈值（如，3次，5次），且以静态分区（B）启动不成功，则引导加载程序会执行系统回滚，以静态分区（A）启动。也就是说，引导加载程序（bootloader）依次加载：基础分区、静态分区（A）、动态分区（super）和用户数据分区。这样，手机就会以静态分区（A）对应的操作系统（如，版本1.1的操作系统）启动。

可以理解的，在手机以静态分区（B）启动时，会因为多种原因导致以静态分区（B）启动不成功，也就是说手机无法运行版本1.2的操作系统。由此，手机会在多次尝试以静态分区（B）启动，手机仍没有启动成功后，手机执行系统回滚，以静态分区（A）启动；也就是说手机运行版本1.1的操作系统。由于在上述虚拟A/B安装过程中，并没有对版本1.1操作系统的相关数据进行改动，因此手机依然可以以版本1.1的操作系统启动。这样，即使手机的操作系统更新不成功，手机仍可以使用未更新的操作系统（如，版本1.1），进入用户交互界面，并不会影响到用户对手机的正常使用。

S506a.在手机以静态分区（A）启动成功后，升级引擎（update engine）生成包括系统回滚信息的升级结果文件。

示例性的，bootloader可以在手机以静态分区（A）启动完成后。bootloader会修改手机启动标志位。接下来，在升级引擎（update engine）启动后，升级引擎（update engine）可以生成包括系统回滚信息的升级结果文件。在升级结果文件包括系统回滚信息时，该升级结果文件用于指示OUC该手机的操作系统升级失败（虚拟A/B安装失败），操作系统发生了回滚。以及，由于手机的虚拟A/B安装失败，手机运行在版本1.1的操作系统下，升级引擎（update engine）无需也不会执行merge过程。

在一些实施例中，升级结果文件可以包括升级结果标志位。升级结果标志位可以通过不同的值，来表示操作系统升级的成功或失败。如，升级结果标志位的值为“50”，可以表示手机操作系统发生了系统回滚。也就是说，在一些实施例中，如果手机发生系统回滚，加载引导程序会将升级结果标志位的值设置为“50”，以表征手机发生了系统回滚。

在一些实施例中，升级引擎（update engine）在启动后，可以获取手机上正在运行的版本号，若发现手机上正在运行的版本号是旧操作系统的版本号，则生成包括系统回滚信息的升级结果文件。

可以理解的，如手机发生系统回滚，以静态分区（A）运行，会导致加载引导程序（boot loader）生成升级结果文件（该升级结果文件包括的是系统回滚信息），且由于手机以静态分区（A）运行升级引擎（update engine）不会执行merge，也不会产生升级打点数据。这样，后续OUC就可以通过升级结果文件获取到，手机上的虚拟A/B升级不成功，发生了系统回滚。

S505b.若手机以静态分区（B）启动成功，则系统服务启动升级引擎（updateengine）和OUC。

在一些实施例中，系统服务（system server）加载并启动成功后，系统服务可以搜索，手机启动标志位。如搜索得到手机启动标志位是启动成功，则系统服务（systemserver）指示启动升级引擎（update engine）和OUC。以使得升级引擎（update engine）执行落盘（merge）操作。

其中，打点又可称为埋点，是指在程序运行过程中，添加打断点，程序运行暂停；之后输出程序运行到打断点时程序产生的数据。例如，update engine在进行merge时，如果update engine运行到了预设的打点，update engine会暂停merge，并输出升级打点数据。

在本实施例中，升级引擎（update engine）在启动之后，升级引擎（updateengine）会检查用户数据分区中的COW文件的落盘情况（也就是说，用户数据分区中的COW文件落盘到动态分区（super）的落盘情况），并执行merge操作。

示例性的，基础分区（common）的元数据分区（/metadata）中可以记载着落盘状态信息。该落盘状态信息包括“已落盘（merged）”或“未落盘（wait for merge）”。落盘状态信息用于表示当前用户数据分区中是否存在需要落盘到动态分区（super）的COW文件。

具体的，落盘状态信息包含针对动态分区（super）的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘（merged）”时，代表动态分区（super）的所有子分区均不需要进行落盘操作；当整体标识为“未落盘（wait for merge）”时，代表动态分区（super）的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘（merged）”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘（wait for merge）”时，代表该子分区需要进行落盘操作。

如果update engine通过上述落盘状态信息确定需要对动态分区（super）进行落盘操作，update engine就可以执行merge过程，将用户数据分区中的COW文件落盘到，该COW文件对应的动态分区的子分区中。

S506b.升级引擎（update engine）执行落盘（merge）操作。

可以理解的，升级引擎（update engine）执行merge操作的触发时机可以包括，升级引擎启动成功。也就是说，在升级引擎启动成功后，升级引擎会检查落盘状态信息，并根据落盘状态信息执行merge操作。可以理解的，对于升级引擎来讲，在升级引擎启动成功后，升级引擎可以主动执行merge操作。

在一些实施例中，上述落盘操作指的是，在操作系统升级过程中，将用户数据分区（userdata）上虚拟动态分区中保存的动态分区（super）升级文件（如，COW文件）写入到动态分区（super）中，使得动态分区（super）的文件完成数据升级，以便手机在下次启动时不需要加载动态分区（super）和虚拟动态分区，加载动态分区（super）就可以完手机启动。

示例性的，升级引擎（update engine）将用户数据分区（userdata）中的COW文件中的升级数据写入到动态分区（super）中的对应地址上，使得动态分区（super）中的全部数据均为升级后的新版本的数据。并在后续，升级引擎（update engine）merge操作成功后，升级引擎（update engine）删除用户数据分区（userdata）中的COW文件，将存储空间归还给用户数据分区（userdata）；并且，将基础分区（common）的元数据（/metadata）中的落盘状态信息由“未落盘（wait for merge）”改为“已落盘（merged）”。

例如，参见图10；升级引擎（update engine）将用户数据分区（userdata）中的COW文件中的升级数据（如，A2、D2），写入到动态分区（super）对应的地址上。如用户数据分区（userdata）中的COW文件中的升级数据是，地址为S1-1的A2；其中，地址S1-1与动态分区（super）中的地址S1对应。又如，用户数据分区（userdata）中的COW文件中的升级数据是，地址为S4-1的D2；其中，地址S4-1与动态分区（super）中的地址S4对应。升级引擎（updateengine）会将升级数据A2覆写到地址S1中的A1上，也就是说将动态分区（super）中的A1修改为A2；以及，升级引擎（update engine）会将升级数据D2覆写到地址S4中的D1上，也就是说将动态分区（super）中的D1修改为D2。

在一些实施例中，升级引擎（update engine）会在merge过程中，根据预设的打点位，生成并输出升级打点数据。

示例性，升级引擎在执行merge的过程中，如果运行到预设的打点位，升级引擎会暂停merge过程。接下来，在merge过程暂停后，升级引擎读取merge过程中的merge数据（例如，变量数值、升级文件的位置、升级文件的完整性、文件校验位、升级文件的状态等等），并基于该merge数据生成升级打点数据，并将该升级打点数据存入缓存（cache）中。之后，OUC可以从缓存（cache）获取到升级打点数据。

在一些实施例中，在update engine进行merge的过程中，update engine晚生成的升级打点数据，会覆盖掉update engine早生成的升级打点数据。假设某升级打点数据是，文件校验位；update engine会将在后生成的文件校验位，覆写到在先生成的文件校验位上。也就是说，在先生成的文件校验位在cache中会被删除。

在一些实施例中，升级引擎（update engine）会在merge结束，且merge成功后，生成升级结果（如，生成包括升级成功信息的升级结果文件）。

在一些实施例中，升级结果文件可以包括升级结果标志位。升级结果标志位可以通过不同的值，来表示操作系统升级的成功或失败。如，升级结果标志位的值为“0”，可以表示手机操作系统升级成功。也就是说，在一些实施例中，如果升级引擎（update engine）的merge成功，update engine可以将升级结果标志位的值设置为“0”，以表征手机上的merge过程成功，用户数据分区中的与系统升级相关的文件，已经被同步到了动态分区中。

需要指出的是，在update engine执行merge成功的情况下，update engine生成的升级结果文件中，仅包括升级成功信息，不会包括升级打点数据。以及，由于OUC获取升级打点数据是从cache中获取的，而升级结果文件是以文件的形式获取到的。也就是说，升级打点数据和升级结果信息是分离的。

可见，在本申请实施例提供的系统升级信息获取方法中，升级结果文件包括的升级结果信息和升级打点数据是分离开的，不会杂糅在一起。

相比于一些方案中，在手机生成的系统升级记录文件中，系统升级记录文件同时存在升级结果信息和升级打点数据，需要对系统升级文件解析，并从解析后的系统升级文件中提取得到。由于，本申请实施例中升级结果信息是和升级打点数据分离的，此时如果手机只关心升级结果，不关心升级打点数据；手机可以直接搜索升级结果文件获取到手机的升级结果（如，升级成功或系统回滚），手机无需获取升级打点数据。这会使手机上的系统升级信息比较简洁，在后续使用起来比较方便；当手机只需要升级结果时，就可以通过搜索升级结果文件的方式直接获取到升级结果，不会获取被升级打点数据影响。以及，相比于一些方案中，在手机生成的系统升级记录文件中，系统升级记录文件中同时存在升级结果信息和升级打点数据，手机需要对升级记录文件解析，并从解析后的系统升级记录文件中，滤除升级打点数据，提取出升级结果。本方案中，不需要解析包含升级结果信息和升级打点数据的升级记录文件，只需要解析升级结果文件，就可以直接获取到手机的升级结果。也就是说，手机获取升级结果的过程不会被升级打点数据干扰。

可见，在本申请实施例提供的方法中，通过将升级结果和升级打点数据分离，可以使得手机可以直接、准确、高效地获取到系统升级的结果，更加便于对系统升级信息的利用。

在一些实施例中，手机还可以将包括升级成功信息的升级结果文件和上述包括系统回滚信息的升级结果文件分离。例如，分离为升级成功文件和系统回滚文件，其中升级成功文件用于记录升级成功信息，系统回滚文件用于记录系统回滚信息。这样，还可以精简升级结果文件中的信息。

在一些实施例中，升级引擎（update engine）还会在merge成功后，删除升级文件（如，用户数据分区中的虚拟动态分区）这样，可以将存储空间归还给用户数据分区（userdata）。

在一些实施例中，在升级引擎（update engine）的落盘（merge）操作执行成功后。update engine可以清除安装文件。如，删除用户数据分区（user date）中的虚拟动态分区。这样，手机就可以以更新后的，完整的操作系统（如，版本1.2）运行。

示例性的，在升级引擎（update engine）的落盘（merge）操作执行成功后，升级引擎（update engine）会删除用户数据分区中的COW文件。需要指出的是，在升级引擎（updateengine）的落盘（merge）操作执行失败后，update engine不清除安装文件。由于此时merge失败，手机的super中并没有完整的升级后的操作系统数据（如，上述A2和D2），以及手机此时是以动态分区和虚拟动态分区的形式运行的操作系统，如清除上述安装文件会导致手机的崩溃，造成手机无法正常运行版本1.2的操作系统。

S507.在OUC启动成功后，OUC获取升级结果文件。若OUC未获取到升级结果文件则执行S508；若OUC获取到升级结果文件则执行步骤S512。

在一些实施例中，OUC可以尝试获取升级结果文件，如果OUC获取到了升级结果文件，则OUC可以得知，手机上的升级引擎（update engine）已经merge结束，且merge成功，系统升级成功。也就是说，手机上的升级引擎（update engine）没有正在进行merge。

这样，在OUC获取到升级结果文件后，OUC就可以基于该升级结果文件提示手机的操作系统升级成功；或者，将升级结果文件发送给服务器等等。

如果OUC未获取到升级结果文件，则此时升级引擎（update engine）可能是正在进行merge过程，也可能是merge过程已经完成且merge失败。接下来，OUC可以去判断升级引擎（update engine）是正在merge，还是merge结束。

S508.OUC判断升级引擎（update engine）是否正在merge；若正在merge则执行S509，若没有正在merge，则执行S510。

在一些实施例中，OUC可以通过预设的接口（如，cleanupsuccful 接口）去获取升级引擎（update engine）在merge过程中生成的升级打点数据，来判断升级引擎（updateengine）是否正在merge。如可以获取到升级打点数据，则OUC可以确定update engine正在进行merge；若获取不到升级打点数据，则OUC可以确定update engine已经结束merge。这样，可以比较便捷地判断电子设备是否正在执行merge操作。

示例性的，OUC通过cleanupsuccful接口，获取update engine在merge过程中生成的打点数据的过程可以理解为，OUC监测cache中，update engine在merge过程中写入升级打点数据的位置（也可被称为，目标存储区域）；若该位置存在数据，或者该位置的数据发生变化；则OUC从cache的该位置获取升级打点数据。

根据上述分析可知，如果update engine正在进行merge，则update engine会在cache中输出打点数据，也就是说，在cache中会存在升级打点数据，以及如果updateengine结束了merge，则update engine会退出，从而导致update engine使用的内存释放，也就是说，在cache中不会存在升级打点数据。基于此，OUC可以通过获取升级打点数据，来判断升级引擎（update engine）是否正在merge。

在一些实施例中，OUC也可以通过升级引擎（update engine）在merge过程中生成的数据来判断，升级引擎（update engine）是否正在merge。这样，也可以比较便捷地判断电子设备是否正在执行merge操作。

可以理解的，升级引擎（update engine）在merge过程中会生成一些数据（如，接口调用记录、临时文件生成数据、文件校验数据等等），如果升级引擎（update engine）merge结束merge，这些数据会被升级引擎（update engine）删除。基于此，OUC可以通过搜索升级引擎（update engine）在merge过程中生成的数据（如，接口调用记录、临时文件生成数据、文件校验数据等等），来判断升级引擎（update engine）是否正在merge。例如，若搜索得到文件校验数据，则OUC确定升级引擎（update engine）正在merge；若没有搜索得到文件校验数据，则OUC确定升级引擎（update engine）结束merge。

在一些实施例中，OUC也可以通过预设的接口（如，runing接口）返回的数据，去判断升级引擎（update engine）是否正在merge。这样，也可以比较便捷地判断电子设备是否正在执行merge操作。

在另一些实施例中，手机也可以先判断升级引擎（update engine）是否正在merge，后判断是否获取到升级结果；以及，手机也可以同时判断升级引擎（update engine）是否正在merge，以及判断是否获取到升级结果。

示例性的，OUC可以获取升级打点数据和升级结果，并根据获取情况（如，是否获取到升级打点数据，是否获取到升级结果），执行与获取情况相对应的后续步骤。

例如，获取情况与后续步骤的对应关系可以如下述表1所示。

表1

S509.升级引擎正在进行merge操作，OUC等待升级引擎（update engine）的落盘（merge）操作执行完成；若升级引擎（update engine）merge成功，则OUC可以获取到升级引擎（update engine）生成的升级结果文件，并执行步骤S512；若升级引擎（update engine）merge失败，则执行步骤S510。

S510.OUC指示升级引擎（update engine）执行落盘（merge）操作。

在一些实施例中，升级引擎（update engine）执行merge操作的触发时机，还可以包括：接收到落盘指示。例如，响应于接收到落盘指示，升级引擎执行merge操作。

示例性的，OUC可以向升级引擎（update engine）发送落盘指示，以触发升级引擎（update engine）执行merge操作。

在一些实施例中，OUC也可以通过系统调用去触发升级引擎（update engine）执行落盘操作（merge）。例如，OUC可以向系统服务（system server）发送落盘启动消息，系统服务（system server）响应于接收到落盘启动消息，系统服务（system server）向升级引发送落盘指示，以触发升级引擎（update engine）执行落盘操作（merge）。

在另一些实施例中，也可以由手机上的其他模块指示升级引擎（update engine）执行落盘（merge）操作。例如，由系统服务指示升级引擎（update engine）执行落盘（merge）操作。

可以理解的，由于升级引擎（update engine）位于本地层，OUC位于应用层；相对于OUC来讲，升级引擎（update engine）会更加底层。也就是说，OUC的启动会比升级引擎（update engine）更加复杂，需要的资源（如，OUC依赖的进程，OUC依赖的服务）会更多。因此，OUC的启动时间会晚于升级引擎（update engine）的启动时间。也就是说，在手机以静态分区（B）启动成功之后，手机上的升级引擎（update engine）会先于OUC启动。以及，由于OUC大概率不会在升级引擎（update engine）之前启动，且升级引擎（update engine）在启动后会基于落盘状态信息执行merge操作。可见，在OUC启动成功时，升级引擎（update engine）可能正在进行merge，也可能是已经merge结束（如，merge成功，或merge失败）。

以及，由于update engine是将升级打点数据写入到cache中的，也就是说，该cache会是update engine申请的。基于此，update engine的merge过程结束，cache中的数据就会被清空。可见，如果update engine的merge过程结束，则OUC获取不到升级打点数据。并且，由于手机上的cache空间会比较宝贵，为了节约cache空间，update engine会将再后生成的升级打点数据，覆盖到在前生成的打点数据中，也就是说，如果在update engine执行merge的过程中，OUC启动，从cache中获取升级打点数据，OUC可能不会获取到完整的升级打点数据。

也就是说，OUC如果在升级引擎（update engine）执行第一次落盘（merge）操作的过程中，获取升级打点数据。由于OUC的启动时间会比update engine晚，以及在updateengine进行merge的过程中，晚生成的升级打点数据，会覆盖掉早生成的升级打点数据。这会导致OUC会获取不到完整的升级打点数据。基于此，如果update engine执行merge的过程失败（如，S509中的merge操作失败），OUC需要再次指示update engine启动，并执行merge操作。这样，OUC在update engine从merge开始到结束的过程中获取升级打点数据。以使得，OUC可以获取到update engine执行完整merge过程中生成的升级打点数据。以及，如果update engine第二次执行落盘（merge）操作成功，update engine就会生成包括升级成功信息的升级结果文件。

由此可见，由于OUC不会在升级引擎（update engine）执行merge前启动；以及，在升级引擎（update engine）执行merge的过程中，升级引擎（update engine）会更新在缓存（cache）中的升级打点数据。基于此，OUC在升级引擎（update engine）第一次执行merge时（如，上述步骤S506b中），OUC可能无法从cache中获取到完整的升级打点数据。因此，OUC需要指示升级引擎（update engine）执行merge操作，以使得升级引擎（update engine）执行第二次merge操作，并在升级引擎（update engine）执行merge操作的过程中，获取升级打点数据。这样，OUC才可以从cache中获取到升级引擎（update engine）生成的完整的升级打点数据。

S511.OUC在升级引擎（update engine）执行落盘（merge）操作的过程中，从缓存（cache）中获取升级打点数据。

在一些实施例中，在步骤S511执行的merge操作可以被称为第二merge操作。

在步骤S511中，升级引擎（update engine）执行落盘（merge）操作可以理解为，在上述步骤S509中升级引擎（update engine）执行的merge操作。

升级引擎（update engine）执行落盘（merge）操作的过程中可以根据打点位，生成并通过cache输出升级打点数据。其中，打点位可以包括预设的打点位和可扩展的打点位。

示例性的，假设升级引擎（update engine）的merge过程包括：将用户数据分区（userdata）中的COW文件中的升级数据（如，A2、D2）覆写到动态分区（super）对应的地址上。

参见图11，升级引擎（update engine）可以先读取COW文件中的A2，并计算A2的哈希值（如，hash_A2）。在A2的哈希值计算完成后，update engine执行到打点位1，updateengine将A2的哈希值作为升级打点数据，写入cache。之后，update engine将cow文件中的A2覆写到super中A2对应的位置（如，S1）。

接下来，再次参见图11，update engine在A2覆写完成后，update engine读取COW文件中的D2，并计算D2的哈希值（如，hash_D2）。在D2的哈希值计算完成后，update engine执行到打点位2，将D2的哈希值作为升级打点数据，写入cache。之后，update engine将cow文件中的D2覆写到super中D2对应的位置（如，S4）。

之后，参见图11，update engine在D2覆写完成后，update engine计算super中更新后的文件的哈希值。在更新后的文件的哈希值计算完成后，update engine执行到打点位3，update engine读取上述super中更新后的文件的哈希值（如，hash_super），将super中更新后的文件的哈希值作为升级打点数据，写入cache。

这样，升级引擎（update engine）就可以在merge过程中输出打点数据。可以使得相关技术人员可以根据升级引擎（update engine）merge过程中输出的打点数据，对手机的升级引擎（update engine）的merge过程进行修复。

示例性的，OUC可以通过预设的接口（如，clean up succful 接口），获取到升级打点数据。其中，OUC通过clean up succful 接口，获取update engine在merge过程中生成的打点数据的过程可以理解为，OUC监测cache中，update engine在merge过程中写入升级打点数据的位置，若该位置存在数据，或者该位置的数据发生变化；则OUC从cache的该位置中将升级打点数据下载并保存。

由于本申请实施例中，OUC获取的升级打点数据是直接从cache中获取的，如果手机需要在merge过程中新增打点位，使得update engine在merge过程中运行到新增打点位时，生成新增打点数据。update engine就可以直接的以cache作为中介将新增升级打点数据传递给OUC。

在一些方案中，update engine以文件（如，系统升级记录文件）作为媒介将新增打点数据传递给OUC，update engine需要对新增打点数据进行格式处理，以满足文件格式的配置要求；以及，在后续使用升级打点数据时，还需要从文件格式中解析出升级打点数据。这会导致不方便对升级打点数据扩展，以及不方便对升级打点数据的使用。然而，本方案中，使用cache作为媒介，不需要对升级打点数据进行格式处理，也无需满文件格式的配置要求；OUC从cache中获取到的是比较原始的数据；update engine不需要对新增打点数据进行格式处理，就可以将新增打点数据传递给OUC。同时，后续使用升级打点数据时，无需从文件格式中解析出升级打点数据，OUC从cache中获取的升级打点数据可以直接被使用。

可见，本申请实施例提供的系统升级信息获取方法，通过OUC从cache中获取升级打点数据，可以很方便增加打点位，可以便捷的对系统升级信息（如，升级打点数据进行扩展）。以及，由于OUC从cache中获取的升级打点数据是比较原始的升级打点数据，没有文件格式要求，也不需要解析格式文件后才能得到升级打点数据，会更加便于后续对升级打点数据的使用。

S512.OUC保存升级结果文件或升级打点数据。

在一些实施例中，OUC还可以向与手机建立了通信连接的服务器（如，上述搜包服务器），发送升级结果文件或升级打点数据。这样，服务器就可以获知手机的升级情况。

在一些实施例中，OUC若获取到升级结果文件，OUC还可以根据升级结果文件展示该升级结果文件对应的升级结果。这样，使用该手机的用户就可以得知该手机操作系统的升级情况，可以提升用户的使用体验。

示例性的，OUC在获取到升级结果文件后，OUC可以解析升级结果文件的内容，如果升级结果文件包括的是升级成功信息，则OUC可以提示用户操作系统升级成功。如果升级结果文件包括的是系统回滚信息，则OUC可以提示用户操作系统升级失败，发生了系统回滚。这样，用户就可以感知到手机上操作系统的升级结果。可以提升用户的使用体验。其中，OUC提示用户的方式包括但不限于：显示通知消息、显示弹窗、播放提示音等等。

在一些实施例中，OUC该可以基于升级打点数据对update engine的merge过程进行修复。假设，升级打点数据包括上述hash_super，OUC通过分析hash_super发现，更新后的super值不正确。OUC可以向搜包服务器发送修改包获取请求，以请求搜包服务器向OUC发送针对super分区的修复包。之后，在OUC接收到该针对super分区的修复包后，OUC基于针对super分区的修复包对merge过程进行修复（如，指示update engine 基于该针对super分区的修复包，再次进行merge）。

在一些实施例中，本申请实施例提供的系统升级信息获取方法，还可以包括步骤S513。

S513.OUC发送升级结果文件或升级打点数据。

在一些实施例中，OUC可以向服务器（如，上述搜包服务器，或者该手机供应商的服务器）发送升级结果文件。这样服务器就可得到手机上的操作系统升级结果，并在后续基于操作系统升级结果对升级包进行优化。

在一些实施例中，OUC可以向服务器发送升级打点数据；这样，服务器就可以基于该升级打点数据，分析得到手机merge失败的原因，并对手机的merge过程进行修复。以完成手机的操作系统升级。如，如果升级打点数据包括上述hash_D2，服务器通过分析hash_D2发现，hash_D2与正确的hash_D2不相同，也就是说D2数据不正确。服务器可以再次向手机发送系统修复包（该，修复包中包括正确的D2数据）；之后，手机上的update engine再基于系统修复包，执行merge过程。这样，服务器就可以对手机的merge过程进行修复。

在一些实施例中，在OUC发送升级结果文件或升级打点数据之后，OUC还可以删除该升级打点数据或该升级结果文件。这样，可以节约OUC的存储空间。

需要指出的是，在一些实施例中，本申请实施例提供的系统升级信息获取方法可以保存系统升级记录文件，在另一些实施例中，本申请实施例提供的系统升级信息获取方法也可以不保存系统升级记录文件，本申请实施例对是否保存相关技术中的系统升级记录文件不予限定。

示例性的，本申请实施例中的预设的打点位可以包括下述一种或多种：分区拷贝失败（partitions copy fail）打点位、升级包不存在（package not exist）打点位、校验（payload zip verify sign）打点位、参数不符合预设（invalid para）打点位、证书不符合预设（auth fail）打点位、分区更新失败（table update fail）打点位、二进制转换器（binary）更新失败（update by update binary fail）打点位、升级小分区哈希（hash）校验（download block hash mismatch）打点位。

以及，可以扩展的打点位（新增打点位）可以包括下述一种或多种：读状态（readstatus）打点位、获取merge表（get table info）打点位、未知表（unknown table）打点位、未知目标类型（unknown trage type）打点位、merge后未合并（unmerged sectors aftercompletion）打点位、合并状态未按预期（unexpected merge state）打点位等等。

在一些实施例中，升级引擎（update engine）在merge过程中，若运行到预设的打点位，升级引擎（update engine）会暂停merge过程。接下来，在merge过程暂停后，升级引擎读取merge过程中的merge数据（如，参数数据、变量数据等等），并判断该merge数据是否属于异常分支，如属于异常分支，则基于该merge数据生成升级打点数据，并将该升级打点数据存入缓存（cache）中。如不属于异常分支，则不生成升级打点数据。示例性的，updateengine中会配置有每个打点位对应的非异常分支（正常分支）的merge数据；若updateengine读取到的merge数据与正常分支的merge数据不同，则将update engine读取到的merge数据作为升级打点数据存入cache中。

这样，可以减少update engine生成的升级打点数据的数据量。以及，由于在本申请实施例中，update engine生成的升级打点数据会存入手机的cache中；因此，减少updateengine生成的升级打点数据的数据量，可以减少对手机上cache的占用。

在另一些实施例中，升级引擎（update engine）在运行到打点位，判断merge数据属于异常分支，生成升级打点数据的情况下，同时生成该打点位对应的结果（如，可以称为异常结果）。并将该异常结果存入cache中。

示例性，假设升级引擎（update engine）在merge过程中，update engine读取用户数据分区中的COW文件；之后，update engine运行到了上述升级包不存在（package notexist）打点位，update engine的merge过程暂停。如果update engine从用户数据分区中读取到了COW文件，update engine判断该merge数据（读取到了COW文件）属于该打点位的正常分支，则update engine不生成升级打点数据，继续执行后续merge过程。如果updateengine未从用户数据分区中读取到COW文件，update engine判断该merge数据（未读取到COW文件）属于该打点位的异常分支，则update engine生成升级打点数据，并继续执行后续merge过程（如，再次读取COW文件，直至读取到COW文件等等）。

又示例性的，假设升级引擎（update engine）在merge过程中，update engine判断用户数据分区中的COW文件是否落盘到动态分区中的对应位置；之后，update engine运行到了上述合并状态未按预期（unexpected merge state）打点位，update engine的merge过程暂停。update engine，对比用户数据分区中的COW文件和动态分区中对应位置（子分区）的文件（如，对比图10中S1和S1-1中的文件；或者，对比图10中S4和S4-1中的文件），如对比发现二者文件不同（如，S1和S1-1中的文件不同；或者，S4和S4-1中的文件不同），updateengine判断该merge数据属于该打点位的异常分支，则update engine生成升级打点数据，并继续执行后续merge过程。如对比发现二者文件相同，update engine判断该merge数据属于该打点位的正常分支，则update engine不生成升级打点数据，并继续执行后续merge过程。

在上述图5对应的实施例中，升级引擎是在启动成功后，搜索落盘状态信息，并根据基于落盘状态信息执行merge操作的。然而，在一些场景中，升级引擎执行merge操作的触发时机也可以不包括，升级引擎启动成功；升级引擎执行merge操作的触发时机包括，接收到落盘指示。也就是说，在这些场景中，对于升级引擎来讲，在升级引擎启动成功后，升级引擎可以不主动执行merge操作，升级引擎可以被动执行merge操作（例如，响应于接收到落盘指示，升级引擎执行merge操作）。

这样，可以使得在升级引擎（update engine）执行一次merge的情况下，OUC就可以获取到，升级结果文件或升级打点数据。也可以使得，手机上操作系统的升级过程比较简洁。

具体的，参见图12，在这种场景下，本申请实施例提供的系统升级信息获取方法，可以包括步骤S1200-S1211。

其中，步骤S1200-S1204，可参见上述步骤S500-S504，在此不再赘述。

在步骤S1204之后，手机执行S1205a-1206a，或者执行S1205b-S1206b以及后续步骤。

接下来，若手机以版本1.2运行不成功，也就是说，手机以新系统启动失败。引导加载程序（bootloader）会执行步骤S1205a，以实现系统回滚。之后，在手机发生了系统回滚也就是以旧版本（如，版本1.1）启动成功后，升级引擎（update engine）可以执行S1206a，以生成包括系统回滚信息的升级结果文件。具体的，步骤S1205a和S1206a可参考上述步骤S505a和S506a。

S1205b.若手机以静态分区（B）启动成功，则系统服务（system server）启动升级引擎（update engine）和OUC。

若手机以版本1.2运行成功，也就是说，手机以新系统启动成功；系统服务（systemserver）可以启动升级引擎（update engine）和OUC。

在本场景中，升级引擎（update engine）在启动成功后，等待落盘指示才执行merge操作。这样可以使得，在OUC启动完成后升级引擎（update engine）可以执行一次完整的merge操作。这样，即使是OUC晚于升级引擎（update engine）启动，升级引擎（updateengine）也可以在OUC启动后执行完整的merge过程，以使得OUC可以获取到升级引擎（update engine）在merge过程中生成的完整的打点数据。

S1206b.OUC指示升级引擎（update engine）执行merge操作；以触发升级引擎（update engine）执行落盘操作（merge）。

在一些实施例中，OUC可以向升级引擎（update engine）发送落盘指示，以触发升级引擎（update engine）执行merge。

其中，落盘指示，也可以被称作落盘指示、merge指示等等；在一些实施例中，落盘指示可以是一段预设好的字符串，OUC可以通过预设的与升级引擎（update engine）之间的通信接口向升级引擎（update engine）发送落盘指示。

在一些实施例中，OUC也可以通过系统调用去触发升级引擎（update engine）执行落盘操作（merge）。例如，OUC可以向系统服务（system server）发送落盘启动消息，系统服务（system server）响应于接收到落盘启动消息，系统服务（system server）向升级引发送落盘指示，以触发升级引擎（update engine）执行落盘操作（merge）。

这样，OUC就可以在升级引擎（update engine）执行落盘操作（merge）的过程中，获取到升级引擎（update engine），在执行落盘操作（merge）过程中完整的升级打点数据。

S1207.若升级引擎（update engine）接收到OUC的指示，则升级引擎（updateengine）执行落盘（merge）操作。

示例性的，升级引擎（update engine）在执行merge的过程中，可以根据打点位以cache为中介向OUC输出升级打点数据。具体的，此步骤可以参见上述步骤S506b和S510，再此不再赘述。

S1208.OUC在升级引擎（update engine）执行落盘操作（merge）的过程中，从缓存（cache）中获取升级打点数据。

具体的，此步骤可以参见上述步骤S511，再此不再赘述。

S1209.在升级引擎（update engine）merge结束后，OUC判断是否获取到升级结果文件。若获取到升级结果文件则执行步骤S1210，若未获取到升级结果文件则执行步骤S1211。

S1210.OCU保存升级结果文件，不保存升级打点数据。

S1211.OCU保存升级打点数据。

在一些场景中，电子设备也可以多次进行操作系统升级。如，由版本1.1的操作系统升级到版本1.2的操作系统；之后，由版本1.2的操作系统升级到版本1.3的操作系统。可以理解的是，由版本1.2的操作系统升级到版本1.3的操作系统的过程，与上述由版本1.1的操作系统升级到版本1.2的操作系统的过程类似，可参见前文的描述，此处不予赘述。

下面，将在多次操作系统升级场景下，对本申请实施例提供的系统升级信息获取方法进行介绍。

电子设备运行第一操作系统。接下来，电子设备运行第二操作系统的升级安装包。其中，第一操作系统是版本1.1的操作系统，第二操作系统是版本1.2的操作系统。示例性的，此过程可以参照上述步骤S500-S502的相关描述。

之后，电子设备关机；然后，电子设备开机。接下来，电子设备运行第二操作系统。示例性的，此过程可以参照上述步骤S503和S504的相关描述。

而后，在第一时间点，电子设备执行第一落盘merge操作。

接下来，在第二时间点，电子设备执行第一merge操作成功；第二时间点晚于第一时间点。

然后，在第三时间点，电子设备启动在线升级客户端OUC；第三时间点晚于第一时间点。

接下来，电子设备运行第三操作系统的升级安装包。示例性的，此过程可以参照上述步骤S500-S502的相关描述。

之后，电子设备关机；然后，电子设备开机。接下来，电子设备运行第三操作系统。示例性的，此过程可以参照上述步骤S503和S504的相关描述。其中，第三操作系统可以是版本1.3的操作系统。

然后，在第四时间点，电子设备执行第二merge操作。

而后，在第五时间点，电子设备执行第二merge操作完成，且第二merge操作失败；第五时间点晚于第四时间点；在第六时间点，OUC启动完成，第六时间点晚于第四时间点。

接下来，在第七时间点，电子设备执行第三merge操作；第七时间点晚于第六时间点。其中，升级打点数据可以包括是电子设备在执行merge操作的过程中，基于打点位生成的。以及，上述merge操作（如，第一merge操作、第二merge操作或第三merge操作），可以包括：将电子设备的（用户数据分区中的）虚拟动态分区保存的升级文件，写入到电子设备的动态分区。

在本实施例中，OUC在第二merge操作执行之后才启动，考虑到电子设备在执行第二merge操作时，OUC可能没有启动，也就是说OUC难以在第二merge操作时获取到完整的系统升级信息。基于此，在OUC启动完成后，在第二merge操作失败的情况下，电子设备触发再次执行merge操作，也就是执行第三merge操作。这样，在OUC启动完成后，电子设备就可以执行完整的merge操作过程。那么，OUC就能够在执行merge的过程中获取到完整的系统升级信息，而不用解析文件格式后再从文件中获取系统升级信息。可见，这种方式可以便捷、高效地、直接地获取到系统升级信息。

在另一些实施例中，本申请还提供一种系统升级信息获取方法，在该方法中，电子设备运第四操作系统。接下来，电子设备运行第五操作系统的升级安装包。之后，电子设备关机。接下来，电子设备开机。然后，电子设备运行第五操作系统。示例性的，此过程可以参见上述步骤S1200-S1204的相关描述。

而后，在第八时间点，电子设备启动在线升级客户端OUC。此过程可参见上述步骤S1205b的相关描述。

接下来，响应于OUC启动完成，在第九时间点，电子设备执行落盘merge操作；第九时间点晚于第八时间点。此过程可参见上述步骤S1206b的相关描述。

其中，电子设备执行merge操作的过程中，OUC从缓存中获取升级打点数据。此过程可参见上述步骤S1208的相关描述。

可以理解的是，为了实现上述功能，电子设备包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

本申请实施例还提供一种电子设备，如图13所示，该电子设备可以包括一个或者多个处理器1001、存储器1002和通信接口1003。

其中，存储器1002、通信接口1003与处理器1001耦合。例如，存储器1002、通信接口1003与处理器1001可以通过总线1004耦合在一起。

其中，通信接口1003用于与其他设备进行数据传输。存储器1002中存储有计算机程序代码。计算机程序代码包括计算机指令，当计算机指令被处理器1001执行时，使得电子设备执行本申请实施例中的设备认证。

其中，处理器1001可以是处理器或控制器，例如可以是中央处理器（centralprocessing unit，CPU），通用处理器，数字信号处理器（digital signal processor，DSP），专用集成电路（application-specific integrated circuit，ASIC），现场可编程门阵列（field programmable gate array，FPGA）或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。

其中，总线1004可以是外设部件互连标准（peripheral componentinterconnect，PCI）总线或扩展工业标准结构（extended industry standardarchitecture， EISA）总线等。上述总线1004可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机程序代码，当上述处理器执行该计算机程序代码时，电子设备执行上述方法实施例中的相关方法步骤。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述方法实施例中的相关方法步骤。

其中，本申请提供的电子设备、计算机可读存储介质或者计算机程序产品均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备（可以是单片机，芯片等）或处理器（processor）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种系统升级信息获取方法，其特征在于，应用于电子设备，所述方法包括：

运行第一操作系统；

运行第二操作系统的升级安装包；

所述电子设备关机；

所述电子设备开机；

运行所述第二操作系统；

在第一时间点，执行第一落盘merge操作；

在第二时间点，所述第一落盘merge操作成功；所述第二时间点晚于所述第一时间点；

在第三时间点，启动在线升级客户端OUC；所述第三时间点晚于所述第一时间点；

运行第三操作系统的升级安装包；

所述电子设备关机；

所述电子设备开机；

运行所述第三操作系统；

在第四时间点，执行第二merge操作；

在第五时间点，所述第二merge操作完成，且所述第二merge操作失败；所述第五时间点晚于所述第四时间点；

在第六时间点，所述OUC启动完成，所述第六时间点晚于所述第四时间点；

在第七时间点，执行第三merge操作；所述第七时间点晚于所述第六时间点；

所述第一操作系统、所述第二操作系统和所述第三操作系统是不同版本的目标操作系统；

其中，所述执行第三merge操作，包括：

若所述OUC未获取到升级结果文件，则所述OUC指示所述电子设备中的升级引擎执行所述第三merge操作。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在执行所述第三merge操作的过程中，所述OUC从缓存中获取升级打点数据。

3.根据权利要求2所述的方法，其特征在于，所述OUC从缓存中获取升级打点数据，包括：

所述OUC监测所述缓存中的目标存储区域，若所述目标存储区域发生数据变化，则所述OUC从所述目标存储区域中获取升级打点数据；所述目标存储区域是执行merge操作的过程中所述电子设备的升级引擎写入升级打点数据的存储区域。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

若所述第三merge操作成功，则所述电子设备中的升级引擎生成升级结果文件，所述OUC获取所述升级结果文件，所述升级结果文件用于指示升级成功，所述升级结果文件未包括升级打点数据。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

若所述第一落盘merge操作成功，则所述电子设备中的升级引擎生成升级结果文件，所述OUC获取所述升级结果文件，所述升级结果文件用于指示升级成功，所述升级结果文件未包括升级打点数据。

6.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

若所述第二merge操作成功，则所述电子设备中的升级引擎生成升级结果文件，所述OUC获取所述升级结果文件，所述升级结果文件用于指示升级成功。

7.根据权利要求1-3任一项所述的方法，其特征在于，所述执行第一落盘merge操作，包括：

若加载第一静态分区中的第二操作系统成功，则执行所述第一落盘merge操作；

所述方法还包括：

若加载第一静态分区中的第二操作系统失败，则加载第二静态分区中的第一操作系统；

所述电子设备中的升级引擎生成升级结果文件，所述OUC获取所述升级结果文件；所述升级结果文件用于指示操作系统发生回滚，所述升级结果文件未包括升级打点数据。

8.根据权利要求7所述的方法，其特征在于，所述电子设备中的升级引擎生成升级结果文件，包括：

获取所述电子设备正在运行的操作系统的版本号，若所述版本号是所述第一操作系统的版本号，则所述电子设备中的升级引擎生成所述升级结果文件。

9.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述处理器用于执行所述存储器上存储的计算机指令，以使得所述电子设备执行如权利要求1-8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-8中任一项所述的方法。