CN114237722A - 一种系统的启动方法、装置、设备及工程车辆 - Google Patents

Abstract

本申请公开了一种系统的启动方法、装置、设备及工程车辆，应用于采用多个分区的系统，所述系统的启动方法包括：获取所述系统中所述多个分区的状态标记位；其中，所述状态标记位包括活跃状态，所述活跃状态包括活跃和不活跃；启动所述活跃状态为活跃的分区；获取启动时长；其中，所述启动时长表示从所述系统启动开始到所述系统启动完毕的总时长；当所述启动时长大于参考时长时，确定启动所述活跃的分区超时；以及当启动所述活跃的分区超时次数大于预设次数时，将所述活跃的分区的所述活跃状态标记为不活跃，另一不活跃的分区的所述活跃状态标记为活跃，重新启动所述系统。本申请能够解决多个分区的升级方案无法迅速恢复为升级前的旧系统的问题。

Description

一种系统的启动方法、装置、设备及工程车辆

技术领域

本申请涉及通信技术领域，具体涉及一种系统的启动方法、装置、设备及工程车辆。

背景技术

Android系统是Google开发的基于Linux内核的自由及开源的操作系统，至今已经发展到了Android 12版本。Android系统的升级更新技术采用OTA方案，分为非A/B系统更新和A/B系统更新，Android7.0及以前的版本的OTA升级主要采用非A/B分区的升级方案，Android7.0以后的版本的OTA升级已经支持A/B分区的升级方案，A/B系统升级也成为无缝升级，它的目标是确保在通过网络下载(OTA)更新期间，在磁盘上保留一个可正常启动和使用的系统。当使用A/B分区的OTA升级方案进行升级后，如果出现无法进入默认的系统桌面或者需要很长时间才能进入系统默认的桌面，将影响用户的操作体验，并且目前A/B分区的升级方案无法迅速恢复为升级前的旧系统。

发明内容

为了解决上述技术问题，提出了本申请。本申请的实施例提供了一种系统的启动方法、装置、设备及工程车辆，能够解决多个分区的升级方案无法迅速恢复为升级前的旧系统的问题。

根据本申请的一个方面，提供了一种系统的启动方法，应用于采用多个分区的系统，所述系统的启动方法包括：获取所述系统中所述多个分区的状态标记位；其中，所述状态标记位包括活跃状态，所述活跃状态包括活跃和不活跃；启动所述活跃状态为活跃的分区；获取启动时长；其中，所述启动时长表示从所述系统启动开始到所述系统启动完毕的总时长；当所述启动时长大于参考时长时，确定启动所述活跃的分区超时；以及当启动所述活跃的分区超时次数大于预设次数时，将所述活跃的分区的所述活跃状态标记为不活跃，另一不活跃的分区的所述活跃状态标记为活跃，重新启动所述系统。

在一实施例中，所述状态标记位的启动状态参数包括成功状态和不成功状态；所述状态标记还包括完整状态值，在所述获取启动时长之前，所述系统的启动方法还包括：进入所述活跃的分区并进行校验以检测所述活跃的分区的完整性；当校验通过时，启动所述系统，所述系统启动完毕后，将所述活跃的分区的所述启动状态参数标记为成功状态；其中，所述校验通过后所述活跃的分区的完整状态值标记为真；其中，所述获取启动时长包括：当所述活跃的分区的完整状态值为真时，启动系统并获取所述启动时长。

在一实施例中，所述启动所述活跃状态为活跃的分区包括：启动活跃状态为活跃的分区；其中，所述活跃的分区包括存储系统升级最新文件的分区。

在一实施例中，所述获取启动时长包括：启动定时轮询；其中，所述定时轮询从校验通过时开始执行；当所述活跃的分区启动完毕时，确定所述定时轮询的累计时长为所述启动时长。

在一实施例中，所述参考时长的获取方式包括：获取预先设定的预设时长作为所述参考时长。

在一实施例中，所述参考时长的获取方式还包括：对比所述启动时长和所述参考时长，获得对比结果；当所述对比结果表示所述启动时长大于所述参考时长时，根据所述启动时长设定下一次启动所述系统的分区时的参考时长。

在一实施例中，所述系统的启动方法还包括：当所述活跃的分区超时次数小于所述预设次数时，继续标记所述活跃的分区的活跃状态为活跃；其中，所述标记了所述活跃状态为活跃的分区表示下一次启动所述系统时进入的分区。

根据本申请的另一个方面，提供了一种系统的启动装置，应用于采用多个分区的系统，所述系统的启动装置包括：第一获取模块，用于获取所述系统中所述多个分区的状态标记位；其中，所述状态标记位包括活跃状态；启动模块，用于启动活跃状态为活跃的分区；第二获取模块，用于获取启动时长；其中，所述启动时长表示从所述系统启动开始到所述系统启动完毕的总时长；对比模块，用于当所述启动时长大于参考时长时，确定启动所述活跃的分区超时；以及重启模块，用于当启动所述活跃的分区超时次数大于预设次数时，进入不活跃状态的分区重启。

根据本申请的另一个方面，提供了一种系统的启动设备，应用于采用多个分区的系统，所述系统的启动设备包括：启动选择器，用于启动所述多个分区；显示器，用于展示系统运行成功或失败的信息；以及如上述实施例所述的系统的启动装置；其中，所述启动选择器、所述显示器和所述系统的启动装置通讯连接。

根据本申请的另一个方面，提供了一种工程车辆，包括：工程车辆本体；控制器，其中，所述控制器安装在所述工程车辆本体上，所述控制器采用如上述实施例所述的系统的启动装置。

本申请提供的系统的启动方法、装置、设备及工程车辆，通过检测系统的启动时长以及超时启动次数来判定是否需要自动切换到另一个系统，可以应用于升级新系统后新系统分区启动异常，从而恢复到另一分区的旧系统的情况。用户在使用系统时容易感知到启动时长的变化，从而收获不同的使用体验，因此，采用启动时长作为判断标准，自动调整系统的启动分区，高校快捷，成本低，且可以直观地提升用户体验，降低升级启动时出现异常的风险。

附图说明

通过结合附图对本申请实施例进行更详细的描述，本申请的上述以及其他目的、特征和优势将变得更加明显。附图用来提供对本申请实施例的进一步理解，并且构成说明书的一部分，与本申请实施例一起用于解释本申请，并不构成对本申请的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1是本申请一示例性实施例提供的系统的启动设备的结构示意图。图2是本申请一示例性实施例提供的系统的启动方法的流程示意图。

图3是本申请另一示例性实施例提供的系统的启动方法的流程示意图。

图4是本申请另一示例性实施例提供的系统的启动方法的流程示意图。

图5是本申请另一示例性实施例提供的系统的启动方法的流程示意图。

图6是本申请一示例性实施例提供的系统的启动方法的原理示意图。

图7是本申请另一示例性实施例提供的系统的启动方法的原理示意图。

图8是本申请另一示例性实施例提供的系统的启动方法的原理示意图。

图9是本申请一示例性实施例提供的系统的启动装置的结构示意图。

图10是本申请另一示例性实施例提供的系统的启动装置的结构示意图。

图11是本申请一示例性实施例提供的电子设备的结构图。

具体实施方式

下面，将参考附图详细地描述根据本申请的示例实施例。显然，所描述的实施例仅仅是本申请的一部分实施例，而不是本申请的全部实施例，应理解，本申请不受这里描述的示例实施例的限制。

申请概述

Android系统是Google开发的基于Linux内核的自由及开源的操作系统，至今已经发展到了Android 12版本。Android系统的升级更新技术采用OTA方案，分为非A/B系统更新和A/B系统更新，其中，Android7.0以后的版本的OTA升级已经支持A/B分区的升级方案，A/B系统升级也称为无缝升级，它的目标是确保在通过网络下载(OTA)更新期间，在磁盘上保留一个可正常启动和使用的系统。这种方式可以降低更新之后的设备无法启动的可能性(包括在升级过程中出现机器断电的场景)，这意味着用户需要将设备送到维修和保修中心进行更换和刷机的情况将会减少。

A/B分区的升级方案可以带来如下好处：(1)OTA更新可以在系统运行期间进行，即用户在系统升级过程中可以正常使用设备的系统(非A/B分区就无法做到)，更新完成后，在用户重启机器后生效；(2)系统更新后，重新启动所用的时间不会超过常规重新启动所用的时间；(3)OTA升级过程中，机器可以被断电，断电重启后，机器依旧可以正常运行；(4)更新包可以流式传输到A/B分区的设备中，因此在安装之前不需要先下载更新包，流式更新意味着用户没有必要在/data或/cache上留出足够的可用空间以存储更新包。

A/B分区的升级涉及到系统的A分区和B分区(即设备会将存储的Flash分为A分区和B分区)，系统在启动时会选择从A分区或者B分区启动，运行过程中仅使用当前启动的分区。系统采用A/B分区的结构，能够实现无缝升级，例如用户正在使用A分区，如果此时收到OTA推送，则系统会在后台一边下载OTA数据流，一边对B分区升级，当B分区系统升级完成后，用户会收到重启提示，如果重启，系统将会自动切换到B分区的新版本系统。在此过程中，仅有重启的操作是会被用户感知的，这个重启与普通重启的耗时没有什么区别，如果用户选择不重启，此时仍然可以正常使用当前A分区的系统，直至下次重启后自动使用B分区的新系统。如果OTA更新失败，也仅仅是待升级的分区出现问题，系统仍然会重新尝试OTA，而这些操作都不会影响用户当前运行分区中的系统，A分区和B分区中的系统相互独立。

Android源码中对A/B分区有以下三种标识：(1)active：如果该分区被标记为active，则表示该分区是当前运行的系统，另外一个没有被运行的系统则不会被标记为active；(2)bootable：如果该分区的该标志的值为true，表示该分区中包含了一个完整的可以被启动的系统，否则该分区不能够启动；(3)successful：系统重启后，在zygote(核心进程)启动前，init进程(由内核启动的用户级进程)会调用update_verifier服务的dm-verity机制(dm-verify保护机制位于Android内核中，专门用于文件系统的校验，它会读取文件系统的块设备并校验其hash值，从而校验该块设备是否又被恶意篡改等，从而提升系统的安全性。)校验本次升级的镜像，如果校验通过，则会将该分区标记为successful；如果系统将当前标记为active的分区通过反复多次的启动后都没能标记为successful(即没能校验成功，表示这块设备可能被恶意篡改等)，则将该分区标记为unbootable，并将另外一个分区标记为active。

例如，可以将这三个标识的状态分为active、unactive、bootable、unbootable、successful和unsuccessful，在实际的编程实现中，其变量名称可能不是这六种，但是意义是一致的，有如下场景对分区标记进行说明：

(1)普通场景：

a、系统正在从当前分区(如A分区)运行。目前为止尚未进行过任何OTA升级，A分区会被标记为active、bootable和successful。设备在通过恢复出厂设置时，A分区和B分区都可以成功启动并正确运行，所以两个分区都被标记为了bootable和successful，但由于是从A分区启动，所以只有A分区被标记为了active。

b、设备每次正常重启时，系统会选择当前处于active状态标记位的分区启动，而该分区就还有bootable和successful的状态标记位；对于处于active状态标记位的分区，当前仅有一个，因为系统每次启动时，只会选择处于active状态标记位的分区的系统启动。

(2)正在OTA升级过程中：系统正在从当前分区(如A分区)运行，因此将A分区的状态标记为active、bootable和successful；此时B分区中的内容正在更新，但是尚未完成，因此B分区的状态被标记为unbootable，在此状态下，如果系统重启，将会选择A分区启动系统。

(3)已经完成OTA系统升级：此时系统正在A分区运行，A分区的状态被标记位bootable和successful。但B分区完成了OTA系统升级，下一次启动系统时需要从升级后的B分区启动，因此，将B分区的状态标记为active，由于还没有验证过B分区是否能够成功运行，所以暂时不将B分区的状态标记设置为successful，而A分区将没有active标记位，设置为unactive。

(4)从升级后的分区新系统启动时：设备重新启动后，系统的bootloader检测到B分区为active，所以选择从B分区加载系统，进入到B分区的系统后，如果能够通过update_verifier服务的dm-verity机制的校验，则将B分区的状态标识位设置为successful。对比场景(1)中，A和B系统都设置为bootable和successful，但active从A分区切换到了B分区，因此，设备重新进入到了场景(1)的情况，同时可以对A分区进行升级更新。

尽管Android的A/B分区的OTA升级方案减少了机器因OTA升级后导致的“变砖”(设备重启后无法继续使用)概率，但是依然存在如下问题：

(1)升级后的系统启动异常。当使用A/B分区的OTA升级方案升级后，用户重启机器，并且当前使用的分区通过了系统在init.rc进程阶段的update_verifier服务的dm-verity机制校验，此时当前启动的分区已被标记为successful，即当前的分区已经设置了active、bootable和successful标记，但是因为升级前的用户环境千差万别或者升级时所使用的OTA升级包存在某些问题，系统在升级重启后，无法进入默认的系统桌面或者需要很长时间(用户无法接受的时长，如是原来启动时间的2倍甚至更多)才能进入系统默认的桌面，严重影响用户的使用体验，而此时最稳妥和快速的办法是将系统迅速恢复为升级前的旧系统，但是目前的A/B分区的升级方案无法直接迅速恢复为升级前的旧系统，需要人为进行调整。

(2)升级后的系统无法恢复为升级前的系统。当使用A/B分区的OTA升级方案升级后，用户可以正常使用升级后分区中的新系统，但是当用户无法适用新系统，想要恢复旧系统时，目前的A/B分区的方案满足用户的需求，使设备恢复到旧系统。

示例性应用场景

本申请实施例可以应用于工程车辆中，其中，该工程车辆包括：工程车辆本体和控制器，控制器可以采用座舱域控制器，座舱域控制器安装在工程车辆本体上，座舱域控制器可以使用本申请提供的系统的启动方法。座舱域控制器利用该启动方法以启动该工程车辆的系统(例如车辆控制系统)，能够提升用户体验，降低了在OTA升级启动时出现异常的风险，降低了产品的维护成本。

示例性设备

图1是本申请一示例性实施例提供的系统的启动设备的结构示意图，如图1所示，该系统的启动设备7应用于采用两个分区的系统，其中，系统包括第一分区和第二分区，该系统的启动设备7包括：启动选择器71，用于启动第一分区或第二分区；校验器72，用于检测第一分区或第二分区的完整性；分区业务逻辑器73，用于标记第一分区或第二分区的状态；系统进程器74，用于启动定时轮询；显示器75，用于展示系统运行成功或失败的信息；以及系统的启动装置；其中，启动选择器71、校验器72、分区业务逻辑器73、系统进程器74、显示器75和系统的启动装置通讯连接。

其中，第一分区可以表示A/B分区中的A分区，第二分区可以表示A/B分区中的B分区，当然，第一分区也可以表示A/B分区中的B分区，第二分区表示A/B分区中的A分区。

除系统的启动设备外，还存在服务器端2，服务器端2用于下发数据，如根据用户需求配置各种初始值以及预设值。其中，启动选择器71可以为bootloader启动选择器，该选择器主要用于为客户提供选择界面，客户可以从该界面中选择启动第一分区或者第二分区。分区业务逻辑器73可以为update-engine分区业务逻辑模块，主要用于设定第一分区或者第二分区的状态标记位(如active、bootable和successful等)。校验器72可以采用update-verifier校验器，主要用于检验第一分区或者第二分区的系统是否完整并且可以启动，是否遭到恶意篡改等。系统进程器74主要用于启动系统核心服务，如调用onResume方法，启动定时轮询等。显示器75用于告知用户升级成功与否以及其他与用户交互有关的界面显示。

该系统的启动设备7也可以应用于多个分区的系统，其中，同一时间仅只有一个分区可以被标记为活跃的分区，其他分区标记为不活跃的分区，作为备用分区。

示例性方法

图2是本申请一示例性实施例提供的系统的启动方法的流程示意图，如图2所示，该系统的启动方法应用于多个分区的系统，该系统的启动方法包括：

步骤110：获取系统中多个分区的状态标记位。

其中，状态标记位包括活跃状态，活跃状态包括活跃和不活跃。

状态标记位可以用于判断分区的活跃状态，系统通常会选择处于活跃状态的分区作为启动分区。活跃状态包括活跃(active)和不活跃(unactive)。

步骤120：启动活跃状态为活跃的分区。

以状态标记位的活跃状态来指示系统启动，系统通常会选择处于活跃状态的分区作为启动分区，同一时间，活跃的分区仅有一个，其他分区被标记为不活跃的分区作为备用。

步骤130：获取启动时长。

其中，启动时长表示从系统启动开始到系统启动完毕的总时长。

当系统开始启动时，选择从活跃的分区中启动，从活跃的分区开始启动时开始计算系统的启动时长，直到活跃的分区启动完毕。活跃的分区启动完毕的时间节点可以设置为用户能够与系统产生交互时，也可以设置为桌面完全呈现时，或者是其他可以表示活跃的分区启动完毕的情形。

例如，第二分区为活跃的分区，系统当前运行的是第二分区，并且第二分区的运行正常，当系统检测到OTA升级并且在第一分区中升级完成后，系统将标记第一分区作为活跃的分区，标记第二分区为不活跃的分区，下一次启动将从作为活跃的分区的第一分区中运行系统，获取第一分区的启动时长，用以判断第一分区的启动时长是否超出启动预期时长。

步骤140：当启动时长大于参考时长时，确定启动活跃的分区超时。

当检测到的活跃的分区的启动时长大于参考时长时，可以确定活跃的分区的启动时长不符合预期时长。

例如，开发者或用户预先设定参考时长用以评判启动时长，当启动时长大于参考时长时，或启动时长大于N倍(N可以为通过服务器端下发的重置值)的参考时长时，可以说明系统本次的启动时长过长，不符合预期。

步骤150：当启动活跃的分区超时次数大于预设次数时，将活跃的分区的活跃状态标记为不活跃，另一不活跃的分区的活跃状态标记为活跃，重新启动系统。

多次启动活跃的分区均超时时，会给用户带来较差的使用体验，因此，针对超时启动的次数进行预先设定。例如，设定预设次数为2(2为系统默认值，该预设次数可以通过服务器端下发重置)，当用户正在正常使用第二分区，第一分区系统更新完成后，系统将标记第一分区作为活跃的分区，用户重新启动设备，系统将从第一分区中开始运行，获取系统的启动时长，当系统的启动时长第一次大于参考时长时，暂时不改变第一分区的状态标记位，仍标记第一分区作为活跃的分区。用户第二次重新启动设备时，系统仍从第一分区启动，获取本次系统的启动时长，如果本次系统的启动时长仍大于参考时长，则对第一分区的标记位做出更改，将第一分区标记为不活跃的分区，将第二分区标记为活跃的分区，使用户在第三次重启时系统进入第二分区启动。

本申请提供的系统的启动方法，通过获取多个分区的状态标记位，来确定系统的启动分区，启动活跃状态为活跃的分区，并通过检测系统的启动时长以及超时启动次数来判定是否需要自动切换到另一个分区。不活跃的分区作为备用分区，当活跃的分区的启动超时次数大于预设次数时，将不活跃的分区标记为活跃分区，可以从备用分区中启动系统。本申请可以应用于升级新系统后新系统分区启动异常，从而恢复到另一分区的旧系统的情况。用户在使用系统时容易感知到启动时长的变化，从而收获不同的使用体验，因此，采用启动时长作为判断标准，自动调整系统的启动分区，高校快捷，成本低，且可以直观地提升用户体验，降低升级启动时出现异常的风险。

图3是本申请另一示例性实施例提供的系统的启动方法的流程示意图，如图3所示，状态标记位的启动状态参数包括成功状态和不成功状态，状态标记还包括完整状态值，在上述步骤130之前，上述系统的启动方法还可以包括：

步骤160：进入活跃的分区并进行校验以检测活跃的分区的完整性。

当系统进入活跃的分区时，会对活跃的分区的完整性进行校验。例如，系统当前正在运行的是第二分区，此时第二分区为活跃的分区，并且第二分区运行正常，第一分区进行OTA升级并且升级完成后，系统将第一分区标的活跃状态标记为活跃，用户重启手机，系统选择从活跃的第一分区运行。进入第一分区后，第一分区启动init.rc进程，该进程会调用update_verifier服务的dm-verity机制校验本次升级的镜像。

步骤170：当校验通过时，启动系统，系统启动完毕后，将活跃的分区的启动状态参数标记为成功状态。

其中，校验通过后活跃的分区的完整状态值标记为真。

校验通过后，系统将继续执行后续的启动逻辑，直到启动桌面，或者达到预先设定的可以表示启动完毕的状态，此时系统确定为启动完毕的状态，因此，可以将活跃的分区的启动状态参数标记为成功状态。活跃的分区校验通过后会将该活跃的分区的完整状态值标记为真，以确定活跃的分区为完整的分区。

对应的，步骤130可以调整为：

步骤131：当活跃的分区的完整状态值为真时，启动系统并获取所述启动时长。

如果校验通过，则说明活跃的区域完整，设备没有遭到恶意篡改，则直接启动system_server进程进而启动系统默认桌面，启动系统默认桌面可以代表活跃的分区启动完成，从而以此为终止计算启动时长的时间节点，获取活跃的分区的启动时长。也可以设置其他的状态作为代表活跃的分区启动完成的状态。

在一实施例中，上述步骤120可以调整为：启动活跃状态为活跃的分区；其中，活跃的分区包括存储系统升级最新文件的分区。

可以将存储系统升级最新文件的分区作为活跃的分区，将已经完成系统升级的分区标记为活跃的分区，使系统下一次可以从升级完成的活跃的分区进行启动，以达到系统自动升级的效果。系统可以在后台进行自动更新，并且在下次启动时自动启动升级最新文件的分区，用户无需再手动进行升级和换区，提升用户的使用体验，并且减少用户的操作步骤。

在一实施例中，上述系统的启动方法还可以包括：根据指令设置任一分区为活跃的分区。

指令可以由用户自行发出，用户可以自行选择从任意分区启动系统。在使用了该系统的设备中预设特殊实体按键，通过组合按键(例如长按复位键和上键)触发进入启动选择器的界面，用户可以在该界面中自由选择用于启动系统的分区。例如，在通过OTA升级重启后，用户能够正常使用升级后的分区系统，但是对升级后的系统的使用不满意(可能是新版本的UI/UE存在变更，用户不习惯，或者升级后的版本存在某些影响用户体验类的问题等)，用户可以通过使用组合按键进入启动选择器界面，选择没有进行升级的分区，从而选择自己喜欢使用的系统，提高用户的使用体验，满足更多的客户需求。

图4是本申请另一示例性实施例提供的系统的启动方法的流程示意图，如图4所示，上述步骤130可以包括：

步骤131：启动定时轮询。

其中，定时轮询从校验通过时开始执行。

通过周期性的定时轮询来确定启动时长。系统在启动system_server进程后，会同时启动一个定时轮询服务，定时轮询的间隔时间可以设置为1秒钟，1秒钟轮询一次可以减少误差。

步骤132：当活跃的分区启动完毕时，确定定时轮询的累计时长为启动时长。

开启定时轮询后，检测活跃的分区是否启动完成，可以以桌面完全展示作为抓取时间点，也可以以桌面可与用户交互作为抓取时间点，此时抓取到的定论轮询的累积时长，作为活跃的分区的启动时长。

在一实施例中，参考时长的获取方式可以包括：获取预先设定的预设时长作为参考时长。

用户可以预先通过服务器端设定参考时长的默认值，例如，设定参考时长为20秒，该默认值仍可以通过服务器端下发重置。参考时长的设定需要根据系统的正常启动时长设定，当系统进行更新时，可能会出现启动时长增加，但不能以此判定为系统出现异常启动，因此，可以通过调整参考时长来控制系统的分区选择。

在一实施例中，参考时长的获取方式还可以包括：对比启动时长和参考时长，获得对比结果；当对比结果表示启动时长大于参考时长时，根据启动时长设定下一次启动系统的分区时的参考时长。

例如，在二次启动同一个分区的情况下，第一次启动该分区时，参考时长为默认值，启动时长直接与默认值进行比较，确定启动时长是否超过预期。如果存在启动时长大于默认值的情况，则将启动时长赋值给参考时长，或者存在N倍(N大于等于1)的启动时长大于默认值的情况，则将N倍的启动时长赋值给参考时长，以本次启动时长或N倍的启动时长作为下一次的参考时长。如果启动时长小于默认值，第二次仍然使用默认值作为参考时长。

以本次启动的最长时间为参考确定参考时长，可以减少误判的情况，例如，当系统不断更新或是缓存在使用过程中不断增加时，启动时间可能会不断的增加，因此，用于评判启动时长的参考时长应该不断顺应系统的变化而变化，增加判断启动时长是否超过预期时长的准确率，减少了用户人为修改默认值的步骤，为用户节约时间，提高使用效率。

图5是本申请另一示例性实施例提供的系统的启动方法的流程示意图，如图5所示，上述系统的启动方法还可以还包括：

步骤180：当活跃的分区超时次数小于预设次数时，继续标记活跃的分区的活跃状态为活跃。

其中，标记了活跃状态为活跃的分区表示下一次启动系统时进入的分区。

当活跃的分区的超时次数小于预设次数时，可以继续标记活跃的分区的活跃状态为活跃，下次启动时，将继续选择启动活跃的分区。预设次数的默认值可以通过服务器端设置，系统默认设置为5次，用户可以根据需求通过服务器端下发重置。

例如，系统当前运行的是第二分区，并且第二分区的运行正常，当系统检测到OTA升级并且在第一分区中升级完成后，将第一分区标记为活跃的分区，下一次启动将从第一分区中运行系统，但第一分区超时启动次数大于5次，则会将第二分区标记为活跃的分区，下一次启动将会从第二分区中运行系统。也就是说，第一分区更新系统后启动时长超过了预期，将会为用户带来不好的使用体验，因此，下一次启动时从第二分区中运行系统，将会运行第二分区中没有升级的旧系统，通过对比启动时长和超时启动次数，可以自动判断是否恢复旧系统，为用户提供更好的使用体验。

图6是本申请一示例性实施例提供的系统的启动方法的原理示意图，如图6所示，举例说明，在Android系统中，当前运行的是第二分区，且第二分区运行正常，当其检测到OTA升级并升级完成后，用户重启设备后系统会自动进入升级后的新系统第一分区(步骤21)，进入第二分区的系统会启动init.rc进程，该进程会调用update_verifier服务的dm-verity机制校验本次升级的镜像，检测校验是否成功(步骤22)，如果校验通过，不执行原逻辑(现有技术)中的“标记为successful”的代码，而是继续执行Android后续的启动逻辑，启动system_server进程进而启动系统默认桌面；如果校验失败，则会继续校验多次，在多次校验中，会判断校验次数是否大于预定值(步骤23)，如果校验次数大于预定值(默认为5，可以通过服务器端下发重置)，机器则会重启进入第二分区的系统(步骤24)。

如果系统校验通过，系统则会在Activity.java中的onResume方法中监听启动的是否为系统默认的桌面，也就是检测是否展示桌面(步骤26)。之所以要在onResume方法中监听，是因为当启动默认桌面并进入桌面首页时，桌面会回调该onResume的接口，于是可以得知桌面进程是否正常启动。在该onResume方法中，系统会重新设定属性persist.sys.launcher.time(参考时长)的值，获取启动时长的值S1(步骤27)，对比S1是否大于参考时长的值(步骤28)，如果S1小于参考时长的值，则参考时长不变(步骤29)，如果S1大于参考时长的值，则将启动时长的值赋值给persist.sys.launcher.time(参考时长)，令参考时长＝S1(步骤30)，同时设定属性ab.sys.launched＝true(步骤31)，ab.sys.launched属性在系统每次重启后都会被系统自动清除，因此无需担心该属性的状态因系统重启导致出现干扰或不准确等的问题，ab.sys.launched＝true可以表示系统默认的桌面已经启动并展示了首页。

系统在启动system_server进程后，还会启动一个1秒间隔的定时轮询服务(步骤32)，该服务用于获取启动时长的值S2(步骤33)，然后再检测此时是否展示桌面，即判断persist.sys.launched的值是否等于true(步骤34)，如果没有展示桌面，则继续计时。如果展示桌面，即ab.sys.launched＝true时，判断S2是否大于参考时长(步骤35)，其中，为提高判断准确率，可以设置判断条件为：S2是否大于参考时长的N倍(该数字N为默认值，可以通过服务器端下发重置)。如果大于，则说明机器在本次启动桌面的时长太长，不符合预期(预期是小于参考时长或小于参考时长的N倍)，系统则设定第一分区的状态标记位为unactive、bootable和successful，第二分区的状态标记位为active、bootable和unsuccessful，执行重启进入第一分区系统(步骤21)，进而重新从步骤22开始执行业务逻辑。

在执行该业务逻辑的过程中，需要判断设备启动的超时次数是否大于预设次数(步骤36)，如果超时重启的次数大于预设次数(预设次数可以设定为任意值，预设次数的最优值为2)，系统则设定第二分区的状态标记位为active、bootable和successful，第一分区的状态标记位为unactive、bootable和unsuccessful，设备重启后根据第二分区的active状态，选择进入第二分区的系统。

图7是本申请另一示例性实施例提供的系统的启动方法的原理示意图，如图7所示，在该Android系统的设备上预设特殊实体按键，通过组合按键(如长按复位键+上键+下键等)触发进入“Bootloader模式”的界面，用户可以在该界面选择使用哪个系统分区启动。

例如，用户启动设备，系统自动运行第一分区(步骤40)，用户通过长按组合按键进入Bootloader模式(步骤41)，选择了使用第二分区的系统启动(步骤42)，此时系统会再次重启，在重启之前，为了方便系统在下一次启动时判别使用哪个系统启动，因此需要先设定属性值persist.sys.useab＝B(步骤43)，因为此时用户选择使用第二分区启动，如果选择使用第一分区，则设置其值为A。

系统重启进入第二分区的系统(步骤45)，在init.rc进程的update-verrifier的校验环节中，还需要判断该第二分区的状态标记位是否为bootable和successful(步骤46)，如果是，则可以继续启动系统的其他逻辑，也就是正常启动第二分区系统(步骤47)。如果不是，则说明第二分区的系统无法正常启动，为了设备依旧能够正常使用，此时系统会自动重启再去进去第一分区。在进入第一分区的系统后，依旧需要判断第一分区的状态标记位是否为bootable和successful(步骤48)，如果是，则可以正式启动第一分区系统(步骤50)；如果不是，则提示用户分区系统已被损坏，无法启动系统(步骤49)，这种情况则说明该设备的第一分区和第二分区的系统都已经被损坏或者无法启动，此时只能通过排查硬件或者刷机等的方式解决，其原因可能是分区的硬件设备被损坏了。

另外，在正式启动某个分区的系统时，其业务逻辑也是需要重新设定的，图8是本申请另一示例性实施例提供的系统的启动方法的原理示意图，如图8所示，如在正式启动第一分区的系统(步骤51)时，系统引导程序bootloader会检测属性persist.sys.useab的值是否为A(步骤52)，如果是，则继续判断第一分区的状态标记位是否为bootable和successful，如果标记位是bootable和successful，则允许继续启动第一分区系统的其他业务逻辑(步骤54)，进而进入系统默认桌面，系统可以被用户正常使用。如果persist.sys.useab的值不为A，则说明该第一分区的系统是不允许被启动的，此时系统就会重启进入第二分区的系统。正式启动第二分区系统(步骤56)时，也需要判断第二分区的状态标记位是否为bootable和successful，如果是，则允许继续启动第二分区系统的其他业务逻辑(步骤58)，进而进入系统默认桌面。如果第二分区的状态标记位也不为bootable和successful，则无法启动系统(步骤59)，说明系统的第一分区和第二分区都已经损坏了，系统会提示用户分区损坏。

最后，只要成功启动任一分区，都需要将属性persist.sys.useab的值清除(步骤55)，因为只有在通过实体按键触发，用户选择分区启动的场景中，才需要使用该属性值，其他的正常启动场景中，系统依旧会根据分区的状态标记位(active、bootable和successful)来判断启动逻辑。

示例性装置

图9是本申请一示例性实施例提供的系统的启动装置的结构示意图，如图9所示，该系统的启动装置8应用于多个分区的系统，该系统的启动装置8包括：获取标记位模块81，用于获取系统中多个分区的状态标记位；启动分区模块82，用于启动活跃状态为活跃的分区；获取模块83，用于获取启动时长；确定模块84，用于当启动时长大于参考时长时，确定启动活跃的分区超时；以及重启模块85，用于当启动活跃的分区超时次数大于预设次数时，将活跃的分区的活跃状态标记为不活跃，另一不活跃的分区的活跃状态标记为活跃，重新启动系统。

本申请提供的系统的启动装置8，通过获取标记位模块81获取多个分区的状态标记位，来确定系统的启动分区，通过启动分区模块82启动活跃状态为活跃的分区，并通过获取模块83获取系统的启动时长，通过确定模块84判断启动活跃的分区是否超时，再通过重启模块85用超时启动次数来判定是否需要自动切换到另一个分区。不活跃的分区作为备用分区，当活跃的分区的启动超时次数大于预设次数时，将不活跃的分区标记为活跃分区，可以从备用分区中启动系统。本申请提供的系统的启动装置可以应用于升级新系统后新系统分区启动异常，从而恢复到另一分区的旧系统的情况。用户在使用系统时容易感知到启动时长的变化，从而收获不同的使用体验，因此，采用启动时长作为判断标准，自动调整系统的启动分区，高校快捷，成本低，且可以直观地提升用户体验，降低升级启动时出现异常的风险。

图10是本申请另一示例性实施例提供的系统的启动装置的结构示意图，如图10所示，上述系统的启动装置8还可以包括：校验模块86，用于进入活跃的分区并进行校验以检测活跃的分区的完整性；第一标记模块87，用于当校验通过时，启动系统，系统启动完毕后，将活跃的分区的启动状态参数标记为成功状态；对应的，获取模块83可以配置为：当活跃的分区的完整状态值为真时，启动系统并获取所述启动时长。

在一实施例中，上述启动分区模块82可以调整为：启动活跃状态为活跃的分区；其中，活跃的分区包括存储系统升级最新文件的分区。

在一实施例中，如图10所示，上述获取模块83可以包括：轮询单元831，用于启动定时轮询；确定单元832，用于当当活跃的分区启动完毕时，确定定时轮询的累计时长为启动时长。

在一实施例中，上述系统的启动装置8还可以配置为：获取预先设定的预设时长作为参考时长。

在一实施例中，上述系统的启动装置8还可以配置为：对比启动时长和参考时长，获得对比结果；当对比结果表示启动时长大于参考时长时，根据启动时长设定下一次启动系统的分区时的参考时长。

在一实施例中，如图10所示，上述系统的启动装置8还可以包括：第二标记模块88，用于当活跃的分区超时次数小于预设次数时，继续标记活跃的分区的活跃状态为活跃。

示例性电子设备

下面，参考图11来描述根据本申请实施例的电子设备。该电子设备可以是第一设备和第二设备中的任一个或两者、或与它们独立的单机设备，该单机设备可以与第一设备和第二设备进行通信，以从它们接收所采集到的输入信号。

图11图示了根据本申请实施例的电子设备的框图。

如图11所示，电子设备10包括一个或多个处理器11和存储器12。

处理器11可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备10中的其他组件以执行期望的功能。

存储器12可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器11可以运行所述程序指令，以实现上文所述的本申请的各个实施例的系统的启动方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如输入信号、信号分量、噪声分量等各种内容。

在一个示例中，电子设备10还可以包括：输入装置13和输出装置14，这些组件通过总线系统和/或其他形式的连接机构(未示出)互连。

在该电子设备是单机设备时，该输入装置13可以是通信网络连接器，用于从第一设备和第二设备接收所采集的输入信号。

此外，该输入装置13还可以包括例如键盘、鼠标等等。

该输出装置14可以向外部输出各种信息，包括确定出的距离信息、方向信息等。该输出装置14可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图11中仅示出了该电子设备10中与本申请有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备10还可以包括任何其他适当的组件。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本申请的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。

Claims (10)

1.一种系统的启动方法，应用于采用多个分区的系统，其特征在于，所述系统的启动方法包括：

获取所述系统中所述多个分区的状态标记位；其中，所述状态标记位包括活跃状态，所述活跃状态包括活跃和不活跃；

启动所述活跃状态为活跃的分区；

获取启动时长；其中，所述启动时长表示从所述系统启动开始到所述系统启动完毕的总时长；

当所述启动时长大于参考时长时，确定启动所述活跃的分区超时；以及

当启动所述活跃的分区超时次数大于预设次数时，将所述活跃的分区的所述活跃状态标记为不活跃，另一不活跃的分区的所述活跃状态标记为活跃，重新启动所述系统。

2.根据权利要求1所述的系统的启动方法，其特征在于，所述状态标记位的启动状态参数包括成功状态和不成功状态；所述状态标记还包括完整状态值，在所述获取启动时长之前，还包括：

进入所述活跃的分区并进行校验以检测所述活跃的分区的完整性；

当校验通过时，启动所述系统，所述系统启动完毕后，将所述活跃的分区的所述启动状态参数标记为成功状态；其中，所述校验通过后所述活跃的分区的完整状态值标记为真；

其中，所述获取启动时长包括：

当所述活跃的分区的完整状态值为真时，启动系统并获取所述启动时长。

3.根据权利要求1所述的系统的启动方法，其特征在于，所述启动所述活跃状态为活跃的分区包括：

启动活跃状态为活跃的分区；其中，所述活跃的分区包括存储系统升级最新文件的分区。

4.根据权利要求2所述的系统的启动方法，其特征在于，所述获取启动时长包括：

启动定时轮询；其中，所述定时轮询从校验通过时开始执行；

当所述活跃的分区启动完毕时，确定所述定时轮询的累计时长为所述启动时长。

5.根据权利要求1所述的系统的启动方法，其特征在于，所述参考时长的获取方式包括：

获取预先设定的预设时长作为所述参考时长。

6.根据权利要求1所述的系统的启动方法，其特征在于，所述参考时长的获取方式还包括：

对比所述启动时长和所述参考时长，获得对比结果；

当所述对比结果表示所述启动时长大于所述参考时长时，根据所述启动时长设定下一次启动所述系统的分区时的参考时长。

7.根据权利要求1所述的系统的启动方法，其特征在于，还包括：

当所述活跃的分区超时次数小于所述预设次数时，继续标记所述活跃的分区的活跃状态为活跃；其中，所述标记了所述活跃状态为活跃的分区表示下一次启动所述系统时进入的分区。

8.一种系统的启动装置，应用于采用多个分区的系统，其特征在于，所述系统的启动装置包括：

第一获取模块，用于获取所述系统中所述多个分区的状态标记位；其中，所述状态标记位包括活跃状态；

启动模块，用于启动活跃状态为活跃的分区；

第二获取模块，用于获取启动时长；其中，所述启动时长表示从所述系统启动开始到所述系统启动完毕的总时长；

对比模块，用于当所述启动时长大于参考时长时，确定启动所述活跃的分区超时；以及

重启模块，用于当启动所述活跃的分区超时次数大于预设次数时，进入不活跃状态的分区重启。

9.一种系统的启动设备，应用于采用多个分区的系统，其特征在于，所述系统的启动设备包括：

启动选择器，用于启动所述多个分区；

显示器，用于展示系统运行成功或失败的信息；以及

如权利要求8所述的系统的启动装置；其中，所述启动选择器、所述显示器和所述系统的启动装置通讯连接。

10.一种工程车辆，其特征在于，包括：

工程车辆本体；

控制器，其中，所述控制器安装在所述工程车辆本体上，所述控制器采用如上述权利要求8所述的系统的启动装置。

Images