CN115328563B

CN115328563B - 系统启动方法及电子设备

Info

Publication number: CN115328563B
Application number: CN202211229448.1A
Authority: CN
Inventors: 钟微; 余亮
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-10-09
Filing date: 2022-10-09
Publication date: 2023-04-14
Anticipated expiration: 2042-10-09
Also published as: WO2024078218A1; CN117707626A; CN115328563A

Abstract

本申请实施例提供了一种系统启动方法及电子设备。在该方法中，电子设备在其中一个系统启动分区中进行系统启动的过程中，如果该系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中进行系统重启；电子设备在第一系统启动分区中系统重启成功。这样能够解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致死机的几率。

Description

系统启动方法及电子设备

技术领域

本申请涉及智能终端技术领域，尤其涉及一种系统启动方法及电子设备。

背景技术

从终端设备的开机总体流程上来看，终端设备上电后首先运行的是BootLoader。也即，在嵌入式操作系统中，BootLoader是在操作系统内核运行之前运行的。BootLoader可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。

其中，在BootLoader阶段，会对各个系统启动分区镜像进行校验，一旦各个系统启动分区镜像均校验失败，终端设备就会进入Fastboot模式。此时，用户需要请专业维护人员来解决。鉴于用户越来越依赖于以智能手机为代表的移动智能终端，终端系统进入Fastboot模式无疑会给用户的生活和工作带来严重困扰。

因此，在移动智能终端在BootLoader阶段遇到开机故障时，如何降低终端进入Fastboot模式的几率是需要解决的问题。

发明内容

为了解决上述技术问题，本申请实施例提供一种系统启动方法及电子设备。在该方法中，电子设备在其中一个系统启动分区中进行系统启动的过程中，如果该系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致死机的几率。

第一方面，本申请实施例提供一种系统启动方法。该方法应用于电子设备中，电子设备包括第一系统启动分区和第二系统启动分区。该方法包括：包括：

电子设备在第一系统启动分区中进行系统启动的过程中，如果第一系统启动分区的镜像校验失败，则电子设备在第一系统启动分区中进行系统重启；

电子设备在第一系统启动分区中系统重启成功。

镜像校验失败大部分是概率性问题，示例性的，原因可能是由电平调变、硬件器件的概率性故障导致，并非是永久性损坏问题。

这样，如果某个系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致死机的几率。

根据第一方面，该方法还包括：在电子设备在第一系统启动分区中进行系统重启的过程中，如果第一系统启动分区的镜像校验失败，则电子设备切换到第二系统启动分区中进行系统启动；

电子设备在第二系统启动分区中进行系统启动的过程中，如果第二系统启动分区的镜像校验失败，则电子设备在第二系统启动分区中进行系统重启；

电子设备在第二系统启动分区中系统重启成功。

其中，第一系统启动分区和第二系统启动分区互为备份分区。

这样，如果某个系统启动分区的镜像校验失败非概率性问题，则电子设备切换到对区进行启动。当电子设备在对区启动时，如果对区的镜像校验也失败，则电子设备继续在对区中进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，极大减少了电子设备由于镜像校验概率性失败而导致死机的几率。

根据第一方面，或者以上第一方面的任意一种实现方式，电子设备切换到第二系统启动分区中进行系统启动，可以包括：如果第二系统启动分区的属性为可启动状态，则电子设备切换到第二系统启动分区中进行系统启动。

在一种应用场景下，电子设备对第二系统启动分区OTA升级成功，则第一系统启动分区和第二系统启动分区的属性均为可启动状态，电子设备可以在两个分区之间进行切换。

根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括：如果第二系统启动分区的属性为不可启动状态，则电子设备进行快速启动模式。

在一种应用场景下，电子设备对第二系统启动分区OTA时，如果升级失败发生回滚，则第二系统启动分区的属性为不可启动状态，此时电子设备不会在两个分区之间进行切换，而是在第一系统启动分区被确认为非概率性损坏问题时，电子设备进行快速启动模式（Fastboot模式）。

根据第一方面，或者以上第一方面的任意一种实现方式，该方法还包括：在电子设备在第二系统启动分区中进行系统重启的过程中，如果第二系统启动分区的镜像校验失败，则电子设备进行快速启动模式。

在一种应用场景下，电子设备确认第一系统启动分区和第二系统启动分区均非概率性损坏问题时，电子设备进行快速启动模式（Fastboot模式）。

根据第一方面，或者以上第一方面的任意一种实现方式，如果第一系统启动分区的镜像校验失败，则电子设备在第一系统启动分区中进行系统重启，包括：

如果第一系统启动分区的镜像校验失败，且第一系统启动分区的镜像校验失败次数小于第一阈值，则电子设备在第一系统启动分区中进行系统重启；

如果第一系统启动分区的镜像校验失败，则电子设备切换到第二系统启动分区中进行系统启动，包括：

如果第一系统启动分区的镜像校验失败，且第一系统启动分区的镜像校验失败次数等于第一阈值，则电子设备切换到第二系统启动分区中进行系统启动；其中，第一阈值大于2。

示例性的，第二阈值为3。

这样，如果某个系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中多次（例如两到三次）进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，避免电子设备进入Fastboot模式。若电子设备在该系统启动分区中多次进行系统重启均无法正常启动，则可以确认该系统启动分区非概率性损坏问题，此时电子设备切换分区继续启动。

根据第一方面，或者以上第一方面的任意一种实现方式，如果第二系统启动分区的镜像校验失败，则电子设备在第二系统启动分区中进行系统重启，包括：

如果第二系统启动分区的镜像校验失败，且第二系统启动分区的镜像校验失败次数小于第二阈值，则电子设备在第二系统启动分区中进行系统重启；其中，第二阈值大于1。

示例性的，第二阈值为2。

这样，在电子设备进行分区切换后，如果某个系统启动分区的镜像校验失败，则电子设备继续在该系统启动分区中多次（例如两到三次）进行系统重启，以此解决系统启动分区的镜像校验失败的概率性问题，提高电子设备在系统启动过程中的自恢复能力，避免电子设备进入Fastboot模式。

如果第一系统启动分区的镜像校验失败，且第一系统启动分区未处于OTA升级中，则电子设备在第一系统启动分区中进行系统重启。

这样，将终端设备的正常使用场景与OTA升级场景进行分区，使终端设备执行基于概率性AVB校验失败问题而确定的恢复策略，不会对原生的OTA升级流程产生影响，确保了OTA原生升级流程可以正常则执行。

根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备在第一系统启动分区中进行系统重启时，还包括：记录与第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，恢复策略为电子设备在第一系统启动分区中进行系统重启。

根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备在第二系统启动分区中进行系统重启时，还包括：记录与第二系统启动分区的镜像校验失败对应的日志信息以及恢复策略，恢复策略为电子设备在第二系统启动分区中进行系统重启。

根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备切换到第二系统启动分区中进行系统启动时，还包括：记录与第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，恢复策略为电子设备切换到第二系统启动分区中进行系统启动。

根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备系统启动成功后，还包括：向云端上传日志信息及恢复策略。

第二方面，本申请实施例提供一种电子设备。该电子设备包括：一个或多个处理器；存储器；以及一个或多个计算机程序，其中一个或多个计算机程序存储在存储器上，当计算机程序被一个或多个处理器执行时，使得电子设备执行第一方面以及第一方面中任意一项的系统启动方法。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请实施例提供一种计算机可读存储介质。该计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行第一方面以及第一方面中任意一项的系统启动方法。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请实施例提供一种计算机程序产品，包括计算机程序，当计算机程序被运行时，使得计算机执行如第一方面或第一方面中任意一项的系统启动方法。

第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚和该处理电路通过内部连接通路互相通信，该处理电路执行如第一方面或第一方面中任意一项的系统启动方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的Android系统终端的开机启动流程的框架图；

图2为已有技术中的系统启动流程示意图；

图3a为示例性示出的一种应用场景示意图；

图3b为示例性示出的一种应用场景示意图；

图4为申请实施例提供的系统启动流程示意图之一；

图5为申请实施例提供的系统启动流程示意图之一；

图6为申请实施例提供的系统启动流程示意图之一；

图7为示例性是会出的系统启动时的软件框架示意；

图8为示例性示出的存储分区中的数据示意图；

图9为示例性示出的模块交互示意图；

图10为示例性示出的电子设备的硬件结构示意图；

图11为示例性示出的电子设备的软件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

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

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

本申请实施例所提供的方法可以应用于各种类型的电子设备。示例性的，本申请实施例中的电子设备可以是手机、平板电脑、桌面型、膝上型、手持型计算机、笔记本电脑、超级移动个人计算机（ultra-mobile personal computer，UMPC）、上网本，以及蜂窝电话、个人数字助理（personal digital assistant，PDA）、增强现实（augmented reality，AR）\虚拟现实（virtual reality，VR）设备等电子设备，本申请实施例对电子设备的具体形态不作特殊限制。

在本申请实施例中，电子设备可以包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。该硬件层包括中央处理器（central processingunit，CPU）、内存管理单元（memory management unit，MMU）和内存（也称为主存）等硬件。该操作系统可以是任意一种或多种通过进程（process）实现业务处理的计算机操作系统，例如，Android操作系统、iOS操作系统或windows操作系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用。

下述以Android操作系统为例简述终端的开机流程。Android操作系统的启动过程可以分为两个阶段，第一阶段是Linux的启动，第二阶段是Android的启动（可以称为上层开机流程）。图1为一种基于Android系统的终端的开机启动流程的框架图。如图1所示，开机启动流程包括：

01、Boot Rom——当按开机按键的时候，引导芯片开始从固化在ROM的预设代码开始执行，然后加载引导程序到RAM。

02、Bootloader，又称为引导程序，是在操作系统运行之前运行的一段程序，是运行的第一个程序，用于把操作系统镜像文件拷贝到RAM中去，然后跳到镜像文件的入口去执行该文件，也可以称之为进入启动加载模式。

03、Kernel——将内核加载进内存后，首先进入内核引导阶段，在内核引导阶段的最后，调用start_kernel进入内核启动阶段，主要是完成内核的大部分初始化工作。Start_kernel会最终启动用户空间的init进程。

04、init进程——当初始化内核之后，就会启动init进程，在Linux中所有的进程都是由init进程直接或间接fork出来的。init进程负责创建系统中最关键的几个核心daemon（守护）进程，包括但不限于zygote和service manager。其中，zygote是android启动的第一个dalvik虚拟机，它负责启动Java进程。service manager是Binder通信的基础。

05、Zygote进程——该进程是所有Java进程的父进程。例如，zygote虚拟机启动子进程system_server，同时定义了一个Socket，用于接收ActivityManagerService启动应用程序的请求。

06、System Server进程——在System Server进程开启的时候，会初始化ActivityManagerService。同时，会加载本地系统的服务库，调用createSystemContext( )创建系统上下文，创建ActivityThread及开启各种服务等等。

07、Home Activity——在ActivityManagerService开启之后，会调用finishBooting( )完成引导过程，同时发送开机广播，进入home界面，显示桌面。

在上述开机流程中，Bootloader会对操作系统镜像文件进行合法性校验。由于安卓系统是一个基于内核的操作系统，因此在实际启动的过程中，可以依次将启动操作系统的引导程序镜像、内核镜像、主系统镜像加载至内存，并在内存中依次验证每种镜像的合法性，并仅在前一种镜像经验证合法后才加载下一种镜像至内存，直至主系统镜像也通过合法性验证后，才会将主系统镜像在内核的帮助下展开为用户真正能够看到的主系统程序，至此完成安卓设备的启动全过程。

需要说明的是，此处给出的描述仅是对实际启动过程做了一个较上位的概括，实际启动过程更加复杂，但原理相同，不同版本的安卓系统可能在某些步骤的细节上做了一些调整，此处并不做具体限定。

换句话说，需要在主系统镜像展开为主系统程序前，对其是否满足合法性进行校验，并只有合法性校验通过后，才能展开为主系统程序。一旦主系统镜像合法性校验失败，则安卓系统无法正常启动。

目前，安卓系统终端大多都采用Android A/B分区系统。A/B分区系统，顾名思义是有两套系统，一套系统分区，另一套备份分区。这两套系统出厂时一样，此后可能不一样，一个新版本，另一个旧版本。

假设正常系统启动分区为slot_a，备份系统启动分区为slot_b。当slot_a分区数据发生损坏时，终端设备会自动切换到slot_b分区以重启系统，若slot_b分区不可用或者slot_b分区数据发生损坏时，终端设备会自动进Fastboot模式。其中，Fastboot模式指的是快速启动模式。Fastboot是Android定义的一种简单的刷机协议，可以通过Fastboot命令行工具进行刷机。一旦终端设备进入Fastboot模式，则用户需要请专业维护人员来解决。

在一种实现方式中，在Bootloader中基于AVB（Android verify boot）安全机制对分区镜像文件的数据完整性、可靠性和合法性进行校验。其中，AVB校验功能主要是由external/avb/libavb库实现的，该库主要完成的工作包括各个分区镜像的校验，签名验证，以及vbmeta数据的解析，包括了各种flags的处理以及dm-verity所需要的参数解析。

目前，在系统启动的原生逻辑中，如图2所示，终端设备在开机时正常启动slot_a分区，如果slot_a分区镜像AVB校验失败，则终端设备切换到slot_b分区进行启动，如果slot_b分区启动，则终端开机成功。然而，如果slot_b分区镜像AVB校验失败，则终端设备进入Fastboot模式。

然而，系统启动分区发生数据损坏大部分是概率性问题，原因可能是由电平跳变、硬件器件（如存储介质）的概率性故障导致，并非是永久性损坏问题。例如，硬件存储介质使用时的环境因素、温度因素、静电因素等不可预知的因素都可能导致概率性电平跳变，进而导致系统启动分区镜像校验失败。研究发现，大部分由于分区镜像校验失败而进入Fastboot模式的终端设备，在其系统启动分区被重启激活并再次启动后，都能正常启动，这就更加印证了存储器件存在概率性异常问题，而非是永久性异常。

在实际应用中，由于Android A/B分区系统需要开辟两个boot存储空间和两个system存储空间，这是为了保证升级分区不对运行分区产生影响，是实现系统OTA（Over-the-Air，空中下载）不宕机的一个保障。

在OTA场景下，A/B分区系统更新又称之为无缝更新（Seamless updates）。其中，OTA更新在系统后台运行，该过程中用户仍可以正常使用设备。待更新完成后，需重启一次方可进入新系统。若OTA更新失败后（OTA更新无法应用或应用后无法启动），设备可重启回滚到旧分区继续使用，并重新尝试更新升级。终端设备可采用流式升级方式，即无需/data或/cache分区留出足够空间用于存储下载的升级包，也可进行OTA升级。终端设备确保在OTA更新期间磁盘上保留一套可以正常启动使用的系统，减少刷机变砖的可能性，减轻售后服务工作量。

在一种实际应用场景中，终端设备对slot_b分区进行OTA升级，OTA升级失败后系统回滚至slot_a分区。此时，slot_a分区正常可启动，slot_b分区无法启动（或称不可启动）。终端设备在开机时正常启动slot_a分区，如果slot_a分区镜像AVB校验失败，则由于slot_b分区无法启动，终端直接进入Fastboot模式。

在另一种实际应用场景中，终端设备对slot_b分区进行OTA升级，OTA升级成功，slot_b分区正常可启动。此时，slot_a分区正常可启动，slot_b分区也正常可启动。终端设备在开机时正常启动slot_b分区，如果slot_b分区镜像AVB校验失败，则终端设备切换到slot_a分区进行启动，如果slot_a分区启动，则终端开机成功。然而，如果slot_a分区镜像AVB校验失败，则终端设备进入Fastboot模式。

在这些应用场景中，已有逻辑无法处理分区镜像概率性校验失败的问题。一旦分区镜像AVB校验失败就切换分区，切换的分区镜像再次AVB校验失败，则终端进入Fastboot模式，无疑增加了终端设备进入Fastboot模式的几率，缺乏稳定的恢复机制，降低了用户的使用体验。

为了解决上述问题，本申请实施例提供了一种系统启动方法。在该方法中，充分考虑了分区镜像AVB校验概率性失败的问题，设计了一种恢复策略，保证了终端在分区镜像AVB校验概率性失败时，能够自动恢复并正常启动系统，以此降低终端设备进入Fastboot模式的几率，进而提升用户的使用体验。

在本申请实施例中，终端设备系统启动涉及的场景可以包括正常使用场景和OTA升级场景。其中，正常使用场景又可以划分为OTA升级成功场景和OTA升级失败回滚场景。

在基于这几种应用场景对本申请实施例提供的系统启动方法进行阐述之前，对相关概念进行解释说明。

终端设备开机启动可以是用户按压设备的电源键触发的，也可以是由于系统的某些设置自行触发的，例如终端设备定时启动等，还可以是由于系统的某些异常而自行触发的，本申请实施例对此不做限定。

Bootloader为了判断一个系统启动分区是否为可以启动的状态，需要为其定义对应的属性（状态）。示例性的，其状态说明如下：

属性Active，为活动分区标识，排他，代表分区为启动分区，bootloader总会选择该分区进行系统启动；

属性bootable，表示分区存在一套可能可以启动的系统；

属性successful，表示分区的系统能正常启动；

属性unbootable，代表分区损坏，无法启动，在升级过程总被标记。

其中，分区被标记为unbootable时，其他标记（active、bootable、successful）会被清空，而分区被标记为active时，unbootable标记将会被清空。

在slot_a分区和slot_b分区中，只有一个分区可以具有active属性，但两个分区可以同时具有bootable属性和successful属性。

在终端设备开机启动时，bootloader检测到1个或者2个slot分区都是bootable的状态，选择active属性的slot分区或者选择successful属性的slot分区进行尝试启动。如果分区启动成功，则可以设置该分区属性为successful和active；如果分区启动失败，则可以设置该分区属性为unbootable，并设置另一个分区的属性为active进行下一次尝试。

下述结合几个场景对slot分区的属性设置进行说明：

1.普通场景（Normal cases）

普通场景是最常见的情形，例如设备出厂时，slot_a分区和slot_b分区都可以成功启动并正常运行，所以两个分区都设置为bootable和successful。假设从slot_b分区启动，所以只有slot_b分区设置为active。

2.升级中（Update in progress）

slot_b分区检测到升级数据，在slot_a分区进行升级，此时将slot_a分区标识为unbootable，另外清除slot_a分区的successful标识；slot_b分区属性仍然为active，bootable和successful。

3.更新完成，等待重启（Update applied, reboot pending）

slot_b分区将slot_a分区成功更新后，将slot_a分区标识为bootable。另外，由于重启后需要从slot_a分区启动，所以也需要将slot_a分区设置为active。但是，由于还没有验证过slot_a分区是否能成功运行，所以slot_a分区不设置successful；slot_b分区的状态变为bootable和successful，但没有active。

4.重新系统成功启动（System rebooted into new update）

设备重启后，bootloader检测到slot_a分区为active，所以加载slot_a分区系统。进入slot_a分区系统后如果能正常运行，需要将slot_a分区标识为successful。对比普通场景，slot_a分区和slot_b分区都设置为bootable和successful，但active从slot_b分区切换到slot_a分区。至此，slot_b分区成功更新并切换到slot_a分区，设备重新进入普通场景。

场景一

在本场景中，终端设备处于正常使用状态，且在此之前终端设备某个系统启动分区OTA升级成功。此时，终端设备的两个系统启动分区（如slot_a分区和slot_b分区）均处于正常可启动（bootable）状态。

如图4所示，假设slot_a分区的属性为active，终端设备在开机时正常启动slot_a分区。如果slot_a分区镜像AVB校验失败，则终端设备重启slot_a分区。如果重启slot_a分区时，slot_a分区成功启动，则表明果slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果重启slot_a分区时，slot_a分区镜像再次AVB校验失败，则终端设备再次重启slot_a分区。如果再次重启slot_a分区时，slot_a分区成功启动，则表明slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果再次重启slot_a分区时，slot_a分区镜像又一次AVB校验失败，则表明slot_a分区镜像AVB校验失败非概率性问题，可能为slot_a分区镜像永久性损坏问题，此时切换到slot_b分区继续启动。

需要指出的是，终端设备由于重启后需要从slot_a分区启动，所以终端设备在重启前需要将slot_a分区设置为active。

继续参照图4，在终端设备切换到slot_b分区进行启动时，如果slot_b分区slot_b分区，则此时通过分区切换实现了对终端设备异常开机问题的修复。在终端设备切换到slot_b分区进行启动时，如果slot_b分区镜像AVB校验失败，则终端设备重启slot_b分区。如果重启slot_b分区时，slot_b分区成功启动，则表明果slot_b分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果重启slot_b分区时，slot_b分区镜像再次AVB校验失败，则表明slot_b分区镜像AVB校验失败非概率性问题，可能为slot_b分区镜像永久性损坏问题，此时终端设备进入Fastboot模式。

需要指出的是，终端设备由于重启后需要从slot_b分区启动，所以终端设备在重启前需要将slot_b分区设置为active。

在由于某个系统启动分区镜像校验失败导致终端设备出现开机故障时，终端设备根据与当前系统启动分区对应的前一次恢复记录来选择下一次的恢复策略。其中，如果当前系统启动分区发生第一次AVB校验失败和第二次AVB校验失败之后，则为了排除概率性AVB校验失败问题，将重启作为下一次的恢复策略；如果当前系统启动分区发生第三次AVB校验失败之后，则可以确定当前系统启动分区非概率性AVB校验失败问题，可能为分区镜像永久性损坏，将切换分区启动作为下一次的恢复策略。在切换分区之后，第四次AVB校验的是对区镜像，如果对区镜像AVB校验失败，为了排除对区概率性AVB校验失败问题，将重启作为下一次的恢复策略；如果对区镜像连续两个AVB校验失败，则可以确定对区非概率性AVB校验失败问题，可能为分区镜像永久性损坏，终端设备进入Fastboot模式。

需要注意的是，在上述流程中，slot_a分区重启两次，slot_b分区重启一次，该重启次数仅仅为示例性的说明。为了解决分区镜像AVB校验失败的概率性问题，slot_a分区和/或slot_b分区的重启次数可以根据实际情况合理性设置，例如为两到三次等，本申请实施例对此不做限定。

这样，本方案可以保证终端设备更加安全地实现自动恢复，增加终端设备在异常AVB校验失败之后的可靠性，保证异常情况下终端设备能够自恢复，极大减少了终端设备由于分区镜像AVB校验概率性失败问题而导致死机的概率。

场景二

在本场景中，终端设备处于正常使用状态，且在此之前终端设备某个系统启动分区OTA升级失败回滚。此时，终端设备的两个系统启动分区，一个为正常可启动（bootable）状态，一个为异常不可启动（unbootable）状态。

如图5所示，假设slot_a分区的属性为active，终端设备在开机时正常启动slot_a分区。如果slot_a分区镜像AVB校验失败，则终端设备重启slot_a分区。如果重启slot_a分区时，slot_a分区成功启动，则表明果slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果重启slot_a分区时，slot_a分区镜像再次AVB校验失败，则终端设备再次重启slot_a分区。如果再次重启slot_a分区时，slot_a分区成功启动，则表明slot_a分区镜像AVB校验失败为概率性问题，通过重启的恢复策略即可使终端设备正常启动。如果再次重启slot_a分区时，slot_a分区镜像又一次AVB校验失败，则表明slot_a分区镜像AVB校验失败非概率性问题，可能为slot_a分区镜像永久性损坏问题。

此时，若终端设备需要切换到slot_b分区进行继续启动，则首先需要对slot_b分区的属性进行判断。如果slot_b分区的属性为正常可启动（bootable）状态，则终端设备切换到slot_b分区继续启动，后续流程可以参照场景一，在此不再赘述。如果slot_b分区的属性为异常不可启动（unbootable）状态，则终端设备直接进入Fastboot模式。

这样，对于处在正常使用过程中的终端设备，终端设备可分为两种：一种为OTA成功升级之后的终端设备，两个分区都是可启动的，另外一种为OTA升级失败并回滚之后的终端设备，此时终端设备的另外一个分区是不可启动的。因此，终端设备在使用过程（非OTA升级）中发生AVB镜像校验失败时，需要判断终端设备对区是否可启动，当对区可启动时，才会执行切分区的恢复策略。

另一种可选的实施方式中，在终端设备OTA升级失败回滚的场景下，虽然升级失败的系统启动分区的状态的异常不可启动（unbootable），但在终端设备OTA升级失败回滚后，两个系统启动分区的镜像应该是一致的。示例性的，在slot_b分区OTA升级之前，slot_a分区的镜像为镜像1，slot_b分区的镜像也为镜像1；在slot_b分区OTA升级失败回滚之后，slot_a分区的镜像不变为镜像1，slot_b分区的镜像也未成功升级，还是镜像1。

由此，在终端设备OTA升级失败回滚的场景下，当slot_a分区多次重启已排除概率性AVB镜像校验失败问题时，也可以尝试切换至slot_b分区以执行如上文所述的恢复策略。其中，需要指出的是，为了实现此种实施方式，需要在切换至slot_b分区启动之前，将slot_b分区的属性设置为active。

场景三

在本场景中，终端设备处于OTA升级状态。

当终端设备处于OTA升级状态时，如果出现了分区镜像出现了AVB校验失败问题，则为了保证OTA的原生升级流程的正常执行，终端设备不会执行基于概率性AVB校验失败问题而确定的恢复策略。

如图6所示，假设在slot_a分区启动过程中，终端设备检测到分区镜像AVB校验失败问题，则首先判断slot_a分区是否处于OTA升级过程中。若slot_a分区处于OTA升级过程中，则按照已有逻辑继续启动，否则按照本申请实施例提供的系统启动逻辑继续启动，可以参照场景一和场景二，在此不再赘述。

示例性的，在slot_a分区处于OTA升级过程中，如果slot_a分区镜像AVB校验失败，则不会执行基于概率性AVB校验失败问题而确定的恢复策略，而是按照OTA升级失败的逻辑将系统回滚至slot_b分区。

为了实现本申请实施例提供的系统启动方法，如图7所示，终端设备可以包括Bootloader开机框架、启动故障检测（BootDetector）模块、启动故障恢复（BootRecovery）模块以及适配器（adapter）。

其中，Bootloader用于进行不开机故障检测，在本申请实施例中具体用于检测分区镜像AVB校验是否失败；BootDetector用于处理不开机故障，在本申请实施例中具体用于处于分区镜像AVB校验失败故障；BootRecovery用于确定及记录故障恢复策略，在本申请实施例中具体用于确定及记录与分区镜像AVB校验失败对应的故障恢复策略。

继续参照图7，在终端设备的物理资源中包括存储分区以及保留物理内存。其中，保留物理内存用于存储系统当前所处启动阶段的标识信息。示例性的，系统启动阶段包括但不限于Bootloader启动阶段、kernel启动阶段、Android启动阶段等。

如图8所示，存储分区可以用于存储终端设备系统启动信息和系统恢复信息。其中，系统启动信息中至少可以包括系统启动日志信息，每组日志信息至少包括日志头信息、Bootloader日志信息和kernel日志信息。其中，日志头信息用于描述Bootloader日志信息和kernel日志信息所占用的字节数。系统恢复信息中至少可以包括系统恢复所采用的策略信息，还可以包括系统恢复记录。关于存储分区的格式以及字段分布，本申请实施例不做限定。

为了保证Bootloader和kernel能够同时访问存储分区并不依赖文件系统，存储分区可以被设计成裸分区的形式。

需要说明的是，为了使得本申请提供的系统启动方法适用于不同芯片平台，终端设备中还设置有预先封装的适配器，以使BootDetector和BootRecovery可以通过该适配器访问与不同芯片平台对应的存储分区（裸分区）。

图9示例性的示出了一种模块交互示意图。如图9所示，本申请实施例提供的系统启动方法的步骤具体包括：

1. Bootloader检测到分区镜像AVB校验失败。

在终端设备的开启过程中，Bootloader检测是否存在不开机故障。在本实施例中，Bootloader用于检测启动系统的slot分区的镜像是否存在AVB校验失败问题。

2. Bootloader调用BootDetector处理开机故障。

当Bootloader检测到当前存在slot分区镜像AVB校验失败的问题时，调用BootDetector处理开机故障。在本实施例中，Bootloader调用BootDetector处理的是slot分区镜像AVB校验失败问题。

示例性的，Bootloader调用BootDetector时，设置的处理参数可以包括但不限于：slot分区标识，slot分区是否可启动的状态（unbootable或bootable）。其中，处理参数中包括的slot分区标识，用于指示当前发生镜像AVB校验失败的分区。

3. BootDetector校验处理参数的合法性。

BootDetector接收到Bootloader的调用之后，首先校验处理参数的合法性，若处理参数合法则继续向下执行，否则不响应Bootloader的调用。

4. BootDetector调用BootRecovery获取恢复策略。

当Bootloader的调用处理参数合法时，BootDetector继续调用BootRecovery以获取相应的恢复策略。

示例性的，BootDetector调用BootRecovery时的参数，可以包括但不限于：slot分区标识，slot分区是否可启动的状态（unbootable或bootable）。其中，参数中包括的slot分区标识，用于指示当前发生镜像AVB校验失败的分区。

5. BootRecovery读取恢复记录。

响应于BootDetector的调用，BootRecovery可以在存储分区（裸分区）中读取与本轮开机对应的恢复记录。其中，恢复记录可以包括但不限于：slot分区标识，AVB校验失败次数等。需要说明的是，恢复记录也可以存储于其他分区，本实施例对此不做限定。

6. BootRecovery校验更正恢复记录。

BootRecovery对读取到的恢复记录进行校验，以确保读取到的恢复记录的准确性和合法性。在确定读取到的恢复记录通过校验之后，对恢复记录进行更正存储。

示例性的，假设读取到的恢复记录为：slot_a分区，AVB校验失败次数为1，则在BootDetector调用参数指示当前发生镜像AVB校验失败的分区为slot_a分区时，将恢复记录更正为slot_a分区，AVB校验失败次数为2。

又示例性的，假设读取到的恢复记录为：slot_a分区，AVB校验失败次数为3，则在BootDetector调用参数指示当前发生镜像AVB校验失败的分区为slot_b分区时，将恢复记录更正为slot_a分区，AVB校验失败次数为3；slot_b分区，AVB校验失败次数为1。

再示例性的，假设读取到的恢复记录为空，则在BootDetector调用参数指示当前发生镜像AVB校验失败的分区为slot_a分区时，将恢复记录更正为slot_a分区，AVB校验失败次数为1。

7. BootRecovery选择恢复策略。

BootRecovery根据更正后的恢复记录，选择当前的恢复策略。

假设，分区切换前终端设备设置的AVB校验失败次数阈值为x1，分区切换后终端设备设置的AVB校验失败次数阈值为x2。其中，AVB校验失败次数阈值x1可以设置为大于2的整数，AVB校验失败次数阈值x2可以设置为大于1的整数。

在终端设备开始在slot_a分区启动的情况下，slot_a分区的AVB校验失败次数阈值为x1。由于分区切换后终端设备在slot_b分区启动，则slot_b分区的AVB校验失败次数阈值为x2。

示例性的，分区切换前终端设备设置的AVB校验失败次数阈值x1可以设置为3，分区切换后终端设备设置的AVB校验失败次数阈值x2可以设置为2。可以理解的，此处提及的AVB校验失败次数阈值仅为示例性的举例，可以根据实际情况合理性设置，既能解决分区镜像AVB校验失败的概率性问题，又不会由于重启次数过多而影响用户使用体验。

BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数小于阈值x1，则将当前的恢复策略确定为在slot_a分区进行系统重启。

BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数等于阈值x1，slot_b分区的AVB校验失败次数为0（或者称不存在slot_b分区的恢复记录），且slot_b分区的属性为可启动的状态（bootable），则将当前的恢复策略确定为切换到slot_b分区进行系统启动。

BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数等于阈值x1，且slot_b分区的AVB校验失败次数小于阈值x2，则将当前的恢复策略确定为在slot_b分区进行系统重启。

BootRecovery根据恢复记录，如果确定slot_a分区的AVB校验失败次数等于阈值x1，且slot_b分区的AVB校验失败次数等于阈值x2，则将当前的恢复策略确定进入Fastboot模式。

8. BootRecovery保存恢复策略。

在确定当前的恢复策略之后，BootRecovery将恢复策略保存至存储分区（裸分区）。

9. BootRecovery向BootDetector返回恢复策略。

10. BootDetector保存日志。

BootDetector接收到BootRecovery反馈的恢复策略之后，生成系统恢复日志（Bootloader log）写入存储分区（裸分区）中，以使后续可以根据日志信息定位相应的恢复策略便于读取。

11. BootDetector更新日志meta信息。

BootDetector根据在存储分区（裸分区）中写入Bootloader log的情形，适应性地更新日志meta信息。其中，日志meta信息用于对存储分区（裸分区）中存储的日志信息进行描述。

12. BootDetector指示Bootloader执行恢复策略。

BootDetector根据BootRecovery反馈的恢复策略指示执行相应的恢复策略。

13. Bootloader重启开机。

在恢复策略指示在slot_a分区进行系统重启，或者切换到slot_b分区进行系统启动，或者在slot_b分区进行系统重启时，Bootloader执行相应的重启开机操作。

在恢复策略指示进入Fastboot模式时，Bootloader执行相应的进入Fastboot模式的操作。

14. Bootloader开机成功。

如果在前次系统启动时，分区镜像AVB校验失败为概率性问题，则在恢复策略指示在slot_a分区进行系统重启，或者切换到slot_b分区进行系统启动，或者在slot_b分区进行系统重启，Bootloader执行相应的重启操作可以使终端设备开机成功，避免终端设备进入Fastboot模式。

15. BootCollector转储日志及系统恢复结果。

待终端设备开机成功后，安卓系统启动成功。BootCollector为安卓系统应用程序层中的模块，用于收集终端设备在启动过程中的日志信息以及系统恢复结果。

16. BootCollector将日志及系统恢复结果上传至云端。

当BootCollector启动后，在存储分区（裸分区）中读取相应的日志信息以及系统恢复结果，以将这些日志信息以及系统恢复结果上传至云端。

示例性的，BootCollector可以在存储分区（裸分区）中读取本轮开机流程中与最后一次启动对应的日志信息以及系统恢复结果，也可以读取本轮开机流程中所有的日志信息以及系统恢复结果。本申请实施例对此不做限定。

本流程未尽详细解释之处可以参照已有技术，在此不再赘述。

作为一种可选的实施方式，BootCollector可以对slot分区每次出现AVB校验失败问题、执行的恢复策略，以及系统启动是否成功，进行对应性的记录，例如可以是通过日志的形式进行记录。

这样，在终端设备执行恢复策略正常启动后，运维人员就可以根据相应的日志信息分析当前启动分区是否由于镜像AVB校验失败概率性问题被重启过，以及重启后是否镜像AVB校验成功且系统成功启动。

如图10所示为电子设备100的结构示意图。可选地，电子设备100可以为终端，也可以称为终端设备，终端可以为蜂窝电话（cellular phone）或平板电脑（pad）等设备，本申请不做限定。应该理解的是，图10所示的电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图10中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。其中传感器模块180可以包括压力传感器，陀螺仪传感器，加速度传感器，温度传感器，运动传感器，气压传感器，磁传感器，距离传感器，接近光传感器，指纹传感器，触摸传感器，环境光传感器，骨传导传感器等。

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

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

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。

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

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器（low noise amplifier，LNA）等。

无线通信模块160可以提供应用在电子设备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）等无线通信的解决方案。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件（charge coupled device，CCD）或互补金属氧化物半导体（complementary metal-oxide-semiconductor，CMOS）光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。

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

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐，或收听免提通话。在一些实施例中，电子设备100可以设置多个扬声器170A。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

压力传感器用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器可以设置于显示屏194。电子设备100也可以根据压力传感器的检测信号计算触摸的位置。

陀螺仪传感器可以用于确定电子设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器确定电子设备100围绕三个轴（即，x，y和z轴）的角速度。

加速度传感器可检测电子设备100在各个方向上（一般为三轴）加速度的大小。当电子设备100静止时加速度传感器可检测出重力的大小及方向。加速度传感器还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。

触摸传感器，也称“触控面板”。触摸传感器可以设置于显示屏194，由触摸传感器与显示屏194组成触摸屏，也称“触控屏”。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。

按键190包括开机键（或称电源键），音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用（例如拍照，音频播放等）的触摸操作，可以对应不同的振动反馈效果。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

图11是本申请实施例的电子设备100的软件结构框图。

电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时（Android Runtime）和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图11所示，应用程序包可以包括相机、日历、地图、WLAN、音乐、短信息、图库、通话、视频等应用程序。

应用程序包还可以包括BootCollector（启动数据收集）模块。其中，BootCollector模块可以用于收集终端设备在启动过程中的日志信息以及系统恢复结果。

应用程序框架层为应用程序层的应用程序提供应用编程接口（applicationprogramming interface，API）和编程框架。应用程序框架层包括一些预先定义的函数。

如图11所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供电子设备100的通信功能。例如通话状态的管理（包括接通，挂断等）。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知信息被用于告知下载完成，消息提醒等。通知信息还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，通知信息还可以是以对话窗口形式出现在屏幕上的通知。通知信息还例如可以是在状态栏提示文本信息，发出的提示音，电子设备的振动，指示灯的闪烁等。

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

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

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

系统库可以包括多个功能模块。例如：表面管理器（surface manager），媒体库（Media Libraries），三维图形处理库（例如：OpenGL ES），2D图形引擎（例如：SGL）等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，音频驱动，Wi-Fi驱动，蓝牙驱动，传感器驱动等。其中，硬件至少包括处理器、显示屏、Wi-Fi模块、传感器等。

可以理解的是，图11示出的软件结构中的层以及各层中包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

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

本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的系统启动方法。

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

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的系统启动方法。

其中，本实施例提供的电子设备（如手机等）、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

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

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims

1.一种系统启动方法，其特征在于，应用于电子设备中，所述电子设备包括第一系统启动分区和第二系统启动分区，包括：

所述电子设备在所述第一系统启动分区中进行系统启动的过程中，如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区未处于OTA升级中，则所述电子设备在所述第一系统启动分区中进行系统重启，所述电子设备在所述第一系统启动分区中进行系统重启的结果包括重启成功，与所述第一系统启动分区重启成功对应的日志信息用于指示所述第一系统启动分区镜像校验失败为概率性故障，非永久性损坏；

所述电子设备在所述第一系统启动分区中进行系统重启的过程中，如果所述第一系统启动分区的镜像校验失败，则所述电子设备切换到第二系统启动分区中进行系统启动；

所述电子设备在第二系统启动分区中进行系统启动的过程中，如果所述第二系统启动分区的镜像校验失败，则所述电子设备在所述第二系统启动分区中进行系统重启；所述电子设备在所述第二系统启动分区中进行系统重启的结果包括重启成功，与所述第二系统启动分区重启成功对应的日志信息用于指示所述第二系统启动分区镜像校验失败为概率性故障，非永久性损坏；

在所述电子设备在所述第二系统启动分区中进行系统重启的过程中，如果所述第二系统启动分区的镜像校验失败，则所述电子设备进行快速启动模式；

其中，所述电子设备在所述第一系统启动分区中进行系统启动之前，所述电子设备在所述第二系统启动分区中进行了OTA升级，所述OTA升级成功或所述OTA升级后回滚。

2.根据权利要求1所述的方法，其特征在于，所述电子设备切换到第二系统启动分区中进行系统启动，包括：

如果所述第二系统启动分区的属性为可启动状态，则所述电子设备切换到第二系统启动分区中进行系统启动。

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

如果所述第二系统启动分区的属性为不可启动状态，则所述电子设备进行快速启动模式。

4.根据权利要求1所述的方法，其特征在于，如果所述第一系统启动分区的镜像校验失败，则所述电子设备在所述第一系统启动分区中进行系统重启，包括：

如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区的镜像校验失败次数小于第一阈值，则所述电子设备在所述第一系统启动分区中进行系统重启；

如果所述第一系统启动分区的镜像校验失败，则所述电子设备切换到第二系统启动分区中进行系统启动，包括：

如果所述第一系统启动分区的镜像校验失败，且所述第一系统启动分区的镜像校验失败次数等于所述第一阈值，则所述电子设备切换到所述第二系统启动分区中进行系统启动；

其中，第一阈值大于2。

5.根据权利要求1所述的方法，其特征在于，如果所述第二系统启动分区的镜像校验失败，则所述电子设备在所述第二系统启动分区中进行系统重启，包括：

如果所述第二系统启动分区的镜像校验失败，且所述第二系统启动分区的镜像校验失败次数小于第二阈值，则所述电子设备在所述第二系统启动分区中进行系统重启；

其中，第二阈值大于1。

6.根据权利要求1所述的方法，其特征在于，在所述电子设备在所述第一系统启动分区中进行系统重启时，还包括：记录与所述第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备在所述第一系统启动分区中进行系统重启。

7.根据权利要求1所述的方法，其特征在于，在所述电子设备在所述第二系统启动分区中进行系统重启时，还包括：记录与所述第二系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备在所述第二系统启动分区中进行系统重启。

8.根据权利要求1所述的方法，其特征在于，在所述电子设备切换到第二系统启动分区中进行系统启动时，还包括：记录与所述第一系统启动分区的镜像校验失败对应的日志信息以及恢复策略，所述恢复策略为所述电子设备切换到第二系统启动分区中进行系统启动。

9.根据权利要求8所述的方法，其特征在于，在所述电子设备系统启动成功后，还包括：

向云端上传所述日志信息及恢复策略。

10.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储器；

以及一个或多个计算机程序，其中所述一个或多个计算机程序存储在所述存储器上，当所述计算机程序被所述一个或多个处理器执行时，使得所述电子设备执行如权利要求1-9中任一项所述的系统启动方法。

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