WO2021227926A1 - 系统重启方法、终端及存储介质 - Google Patents

系统重启方法、终端及存储介质 Download PDF

Info

Publication number
WO2021227926A1
WO2021227926A1 PCT/CN2021/091932 CN2021091932W WO2021227926A1 WO 2021227926 A1 WO2021227926 A1 WO 2021227926A1 CN 2021091932 W CN2021091932 W CN 2021091932W WO 2021227926 A1 WO2021227926 A1 WO 2021227926A1
Authority
WO
WIPO (PCT)
Prior art keywords
error
add
restart
fails
system restart
Prior art date
Application number
PCT/CN2021/091932
Other languages
English (en)
French (fr)
Inventor
李虎军
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2021227926A1 publication Critical patent/WO2021227926A1/zh

Links

Images

Classifications

    • 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/1438—Restarting or rejuvenating
    • 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
    • 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/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery

Definitions

  • the embodiments of the present invention relate to the field of communications, and in particular to a system restart method, terminal and storage medium.
  • the memory space of mobile phones, computers and other terminals is getting larger and larger, and users can store a large amount of user data in the memory space of the terminal; at the same time, the complexity of the system in the terminal is getting higher and higher, and more and more application software is installed.
  • the unstable factors make the terminal prone to abnormalities and cause the terminal to fail to operate normally.
  • the terminal will restart the system to eliminate the abnormality and restore normal use.
  • the terminal will clean up the data according to the number of system restarts. After cleaning the data, restart again.
  • the system restarts the number of times After reaching a certain number of times, the terminal will enter the recovery mode, and the user can choose to continue the system restart or choose to restore the factory settings.
  • the purpose of the embodiments of the present invention is to provide a system restart method, terminal, and storage medium, so as to reduce as much as possible the amount of user data loss caused by multiple system restart failures of the system.
  • an embodiment of the present invention provides a system restart method, which includes: when the system restart fails, determining the error add-on item according to the error report generated when the system restart fails ; In the process of restarting the system again, the wrong add-on is not loaded.
  • the embodiment of the present invention also provides a terminal, including: at least one processor; Instructions, the instructions are executed by the at least one processor, so that the at least one processor can execute the above-mentioned system restart method.
  • the embodiment of the present invention also provides a computer-readable storage medium storing a computer program, and the computer program is executed by a processor to realize the above-mentioned system restart method.
  • Fig. 1 is a flowchart of a system restart method according to a first embodiment of the present invention
  • Fig. 2 is a flowchart of a system restart method according to a second embodiment of the present invention
  • Fig. 3 is a flowchart of a system restart method according to a third embodiment of the present invention.
  • Fig. 4 is a schematic structural diagram of a terminal in a fourth embodiment of the present invention.
  • the first embodiment of the present invention relates to a system restart method, which is applied to a terminal, such as a mobile phone, a computer, and the like.
  • a terminal such as a mobile phone, a computer, and the like.
  • the specific process is shown in Figure 1, including:
  • Step 101 When the system fails to restart, determine the add-on with an error according to the error report generated when the system fails to restart.
  • Step 102 In the process of restarting the system again, do not load the wrong add-on.
  • the system restart in the terminal includes the system restart of the terminal based on user selection, and the system restart of the terminal in order to restore the normal operating state when an error occurs in the system service system_server process in the terminal.
  • the terminal When the terminal’s system restarts successfully, the terminal enters a normal operating state; when the terminal’s system fails to restart, the number of system restart failures at this time can be one or multiple. This embodiment does not make specific restrictions.
  • the terminal is based on the system.
  • the error log generated when the restart fails to determine the add-on that has the error.
  • the content in the error log is the information of the error code.
  • the error report record can be stored in the form of a record table or log, etc. This embodiment and the following embodiments are described by storing the error report record in a record table.
  • the error report generated when the system restart fails is used to determine the error add-on; where the preset condition is that the number of system restart failures within the preset time period is greater than the preset number , Or the number of consecutive system restart failures is greater than the preset number of times, or the system fails to restart within the preset time period.
  • the preset duration and the preset number of times are set according to actual needs, and this embodiment does not make specific limitations. For example: the preset duration is 2 minutes and the preset number of times is 3 times. If the terminal restarts 4 times within 2 minutes, but the system restart fails all 4 times, the faulty load will be determined according to the error report generated when the system restart failed item.
  • the error report generated when the system fails to restart is used to determine the error add-on, and if the number of consecutive system restart failures is not greater than the preset number, the terminal will proceed again The system restarts.
  • the preset number of times is set according to actual needs, which is not specifically limited in this embodiment.
  • the preset duration is set according to actual needs, and this embodiment does not specifically limit it.
  • the system fails to restart and meets the preset conditions, it means that the system is more likely to fail to restart again.
  • the system is to find the error record generated when the system fails to restart, and determine the error add-on based on the error record; when the system restarts again During the process, not loading error add-ons can increase the probability of successful system restart.
  • all error report records can be stored in one record table, or they can be stored in different record tables according to the add-on type corresponding to the error record.
  • the add-on types include at least the following types: application package apk , Components, classes, library files, etc.
  • different record tables can be stored in one storage module or in different storage modules.
  • the terminal can simultaneously search for records corresponding to all add-on types and find all error reporting records, and the terminal can also traverse the add-on types sorted by priority to find all error reporting records. For example: if the error record is stored in the form of a record table, when the add-on type corresponding to the error record is apk, the error record is saved in Table 1, and when the add-on type corresponding to the error record is a component, the error record is saved in Table 2, and the error is reported When the add-in type corresponding to the record is class, the error record is stored in Table 3.
  • the add-in type corresponding to the error record is a library file
  • the error record is stored in Table 4; Table 1, Table 2, Table 3, and Table 4 are stored in the same In one storage module, or Table 1, Table 2, Table 3, and Table 4 are stored in different storage modules. If the priority of the add-in type is: application package apk, component, class, library file, when the system restart fails, first look up whether the error record is included in table one, and then look up table two, table three, and table four. Find all the error records.
  • the add-on types are traversed in any order, as long as the record corresponding to any add-on type contains the error record generated when the system restart fails, stop the traversal, and determine according to the error record The add-on in error.
  • search for the error record generated when the system restart failed and determine the add-on with error according to the error record, including: traversing the add-on types sorted by priority, and finding whether the record corresponding to the add-on type contains system restart failure
  • the error record generated when any add-in type contains the error record generated when the system restart fails
  • the error record is determined according to the error record, and the traversal is stopped.
  • the priority of the add-on type is: application package apk, component, class, library file
  • the system restart fails, first look up whether there is an error record in Table 1.
  • the first contains the error record.
  • the error add-on is determined to be apk1, and the traversal is stopped. In the process of restarting the system again, the error add-on apk1 is not loaded. If the error record is not included in Table 1, continue to look up Table 2. If the error report is included in Table 2; if the error report is included in Table 2, the error add-on is determined to be component 1 based on the error report, and the traversal is stopped.
  • the error add-on component 1 is not loaded, if Table 2 If the error record is not included in Table 3, continue to look up whether the error report is included in Table 3; if the error report is included in Table 3, determine the error add-on according to the error report as Class 1, and stop the traversal. When the system restarts again, it will not be loaded. The add-on category 1 with the error. If the error report is not included in Table 3, continue to look up the error report in Table 4. According to the error report, determine the error add-on as library file 1, and stop the traversal. In the process of restarting the system again, Do not load the add-on library file with error 1.
  • the system cycle start step includes: when the system restart fails again, if the traversal is not completed, find the record corresponding to the next add-in type, Until the error record generated when the system restart failed is found again, the add-on with error is determined according to the error record, and the system restarts again; during the system restart again, the add-ons with errors found during the traversal process are not loaded; repeat; Execute the system cycle start step, when the traversal is completed, enter the recovery mode. For example: if the priority order of the add-in type is: application package apk, component, class, the error record is stored in Table 1, Table 2, and Table 3.
  • the error add-on is determined to be class 1 according to the error report.
  • the add-ons apk1, component 1 and class 1 with errors found during the traversal process are not loaded.
  • the traversal has been performed and the recovery mode is entered.
  • searching for the error record generated when the system restart fails and determining the add-on with error according to the error record, including: traversing the combination of add-on types sorted by priority, and finding whether the record corresponding to the combination of add-on types Contains the error report generated when the system restart fails; among them, the combination includes at least two types of add-ons; when the record corresponding to any one of the add-on types contains the error record generated when the system restart fails, the error load is determined according to the error record Item and stop traversing.
  • Table 1 and Table 2 are combination 1, and Table 3 and Table 4 are combination 2. If the priority order of the combination of add-on types is: combination 1, combination 2, when the system restarts fail If the error report is included in Table 1 and Table 2, if the error report is included in Table 1 and/or Table 2, the error add-on is determined to be apk1 and/or component 1 according to the error report, and the system restarts again. , Do not load the error add-on apk1 and/or component 1. If the error report is not included in Table 1 and Table 2, continue to look up the error report in Table 3 and/or Table 4, and determine the error add-on based on the error report.
  • the system cycle start step includes: when the system restart fails again, if the traversal has not been completed, find the corresponding combination of the next add-on type Record until you find the error record generated when the system restart fails again, determine the error add-on according to the error record, and restart the system again; during the system restart again, the add-ons with errors found during the traversal process are not loaded ; Repeat the system cycle start step, when the traversal is completed, enter the recovery mode.
  • Table 1 and Table 2 are combination 1, and Table 3 and Table 4 are combination 2. If the priority of the combination of add-on types is: Combination 1, Combination 2.
  • the add-ons are component 1 and/or library file 1. In the process of restarting the system again, the add-ons apk1 and/or component 1 and/or component 1 and/or library file found in the traversal process will not be loaded 1. When the system fails to restart again, the traversal has been executed and the recovery mode is entered.
  • the error add-on is temporarily marked, and the error add-on is not loaded when the system restarts again.
  • the error apk and the apk associated with the error apk are not loaded. For example, if the apk in error is apk1, and the apk associated with apk1 are apk2 and apk3, then apk1, apk2, and apk3 are not loaded.
  • determining the error add-on based on the error record generated when the system restarts failed it also includes: if the type of the errored add-on is an application package apk, check the integrity of the apk in error, and The inspection results are saved.
  • checking the integrity of apk1 refers to checking whether the file of apk1 is complete. If the file of apk1 is complete, the integrity check of apk1 is passed, and the check result is about to be checked. Save as apk1 complete, if the file of apk1 is incomplete, the integrity check of apk1 fails, that is, save the check result as apk1 incomplete. Checking the integrity of apk1 and saving the check result can be performed simultaneously with step 102, or before step 102, or after step 102.
  • the integrity check of the wrong apk it is possible to know whether the apk file itself is incomplete, so that the root cause of the system restart failure can be determined, which is conducive to the subsequent repair of the wrong add-on.
  • the type of the add-on in error is an application package apk, but it is impossible to determine which apk has an error, an integrity check can be performed on all apks.
  • the add-ons with errors are not loaded, including: the apk with the error is not loaded and the apk associated with the apk with the error is not loaded.
  • the apks are related to each other, the apk associated with the wrong apk is not loaded at the same time, which can further improve the probability of a successful system restart.
  • the error report generated when the system restart fails is searched, and the error add-on item is determined according to the error report record.
  • the error add-on item is not loaded, which improves the system restart. The probability of success, which can reduce the amount of user data loss caused by multiple system restart failures as much as possible.
  • the second embodiment of the present invention relates to a system restarting method.
  • the second embodiment is roughly the same as the first embodiment.
  • the main difference is that when the system restarts successfully again, the add-on that has an error is marked.
  • the specific process is shown in Figure 2, including:
  • step 201 when the system restart fails, the error add-on item is determined according to the error report generated when the system restart fails.
  • Step 202 In the process of restarting the system again, the wrong add-on is not loaded.
  • Steps 201-202 are similar to steps 101-102 and will not be repeated here.
  • Step 203 When the system restarts successfully again, mark the add-on with an error; wherein the marked add-on with an error is not loaded during the system restart.
  • all errored add-ons are not loaded.
  • all errored add-ons are marked.
  • the marked error add-ons are in the system restart Is not loaded.
  • the terminal enters the recovery mode.
  • the error add-on is temporarily marked.
  • the error add-on is not loaded. If the system restarts successfully, the error is loaded The item is officially marked, and the previous temporary mark is cleared.
  • the content sorted by priority is traversed to find whether the record corresponding to the content contains the error record generated when the system restart fails; where the content is the add-on type or a combination of add-on types, The combination includes at least two types of add-ons; when the record corresponding to any content includes an error record generated when the system restarts fail, the error record is determined according to the error record, and the traversal is stopped.
  • the system cycle start step includes: when the system restart fails again, if the traversal is not completed, find the next content corresponding Record until you find the error record generated when the system restart fails again, determine the add-on with error according to the error record, and restart the system again; in the process of restarting the system again, do not load the error records found in the traversal process Add-ons; repeat the system cycle startup steps, when the traversal is completed, enter the recovery mode, or when the system restarts successfully again, mark all the add-ons with errors.
  • the priority of the add-in type is: application package apk, component, class, library file
  • the system restart fails, first check whether the error record is included in Table 1, and if the error is included in Table 1, Record, according to the error report, confirm that the error add-on is apk1.
  • the error add-on apk1 is not loaded.
  • the error add-on apk1 is marked and the terminal resumes normal use.
  • the system restart fails again, continue to check whether the error report is included in Table 2. If the error report is included in Table 2, the error add-on is determined as component 1 according to the error report. During the system restart again, the error load is not loaded.
  • the wrong add-on is marked, so that the wrong add-on is not loaded when the subsequent system restarts, so as to avoid the problem of continuously restarting the system.
  • the third embodiment of the present invention relates to a system restart method.
  • the third embodiment is roughly the same as the second embodiment, and the main difference lies in: repairing an error add-on.
  • the specific process is shown in Figure 3, including:
  • step 301 when the system restart fails, the error add-on item is determined according to the error report generated when the system restart fails.
  • Step 302 In the process of restarting the system again, the wrong add-on is not loaded.
  • step 303 when the system restarts successfully again, mark the add-on with an error; wherein the marked add-on with an error is not loaded during the system restart.
  • Steps 301-303 are similar to steps 201-203, and will not be repeated here.
  • Step 304 Repair the error add-on item.
  • step 305 if the repair is successful, the mark of the add-on item that has an error is cleared.
  • the terminal's repair of the error add-on refers to the repair of the error add-on when the system is upgraded (such as fota upgrade). If the system restart fails after the upgrade is completed, it indicates that the repair is successful. , Clear the mark of the add-on with error, and the functions related to the add-on with error resume normal use.
  • the fourth embodiment of the present invention relates to a terminal. As shown in FIG. 4, it includes: at least one processor 402; and a memory 401 communicatively connected with the at least one processor; The instructions executed by 402 are executed by at least one processor 402, so that the at least one processor 402 can execute the system restarting method in the foregoing embodiment.
  • the memory 401 and the processor 402 are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects one or more various circuits of the processor 402 and the memory 401 together.
  • the bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, etc., which are all known in the art, and therefore, no further description will be given herein.
  • the bus interface provides an interface between the bus and the transceiver.
  • the transceiver may be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on the transmission medium.
  • the data processed by the processor 402 is transmitted on a wireless medium through an antenna. In some embodiments, the antenna also receives the data and transmits the data to the processor 402.
  • the processor 402 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions.
  • the memory 401 may be used to store data used by the processor 402 when performing operations.
  • the fifth embodiment of the present invention relates to a computer-readable storage medium storing a computer program.
  • the computer program is executed by the processor, the above method embodiment is realized.
  • the embodiment of the present invention determines the error add-on according to the error report generated when the system restart fails. During the system restart again, the error add-on is not loaded, which improves the system. The probability of successful restart, which can reduce the amount of user data loss caused by multiple system restart failures as much as possible.
  • the program is stored in a storage medium and includes several instructions to enable a device (which can be A single-chip microcomputer, a chip, etc.) or a processor (processor) execute all or part of the steps of the methods described in the embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disks or optical disks and other media that can store program codes. .

Abstract

一种系统重启方法、终端及存储介质。所述方法可包括：在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项（101）；在再次系统重启的过程中，不加载所述出错的加载项（102）。

Description

系统重启方法、终端及存储介质
相关申请的交叉引用
本申请基于申请号为202010410837.9、申请日为2020年5月15日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本发明实施例涉及通信领域，特别涉及一种系统重启方法、终端及存储介质。
背景技术
目前，手机、电脑等终端的内存空间越来越大，用户可以将大量的用户数据保存在终端的内存空间；与此同时，终端内系统的复杂度越来越高，安装的应用软件越来越多，为用户带来便利的同时也带来了许多的不稳定因素，不稳定因素使终端容易发生异常，导致终端无法正常使用。此时，终端会采取系统重启以达到消除异常，恢复正常使用的目的，在系统重启的过程中，终端会按照系统重启的次数进行数据的清理，清理数据后再次进行重启，当系统重启的次数到达一定次数后，终端会进入recovery模式，由用户选择继续进行系统重启或选择恢复出厂设置。
发明人发现在一些情形中至少存在以下问题：在终端不断进行系统重启过程中，用户数据已经丢失了一部分，而进入recovery模式后，会造成用户数据的大量丢失甚至完全丢失。
发明内容
本发明实施例的目的在于提供一种系统重启方法、终端及存储介质，尽可能的降低系统多次系统重启失败而导致的用户数据的丢失量。
为在至少一定程度上解决上述技术问题中的至少一个，本发明的实施例提供了一种系统重启方法，包括：在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项；在再次系统重启的过程中，不加载所述出错的加载项。
本发明的实施例还提供了一种终端，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述所述的系统重启方法。
本发明的实施例还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述所述的系统重启方法。
附图说明
一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。
图1是根据本发明第一实施例中的系统重启方法的流程图；
图2是根据本发明第二实施例中的系统重启方法的流程图；
图3是根据本发明第三实施例中的系统重启方法的流程图；
图4是本发明第四实施例中的终端的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
本发明的第一实施例涉及一种系统重启方法，应用于终端，例如：手机、电脑等。具体流程如图1所示，包括：
步骤101，在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项。步骤102，在再次系统重启的过程中，不加载出错的加载项。
在一些实施例中，终端内的系统重启包括终端基于用户选择进行的系统重启，以及终端内的系统服务system_server进程运行出错时，终端为了恢复正常运行状态而进行的系统重启。在终端的系统重启成功时，终端进入正常运行状态；在终端的系统重启失败时，此时系统重启失败的次数可以为一次，也可以为多次，本实施例不做具体限定，终端根据系统重启失败时生成的报错记录确定出错的加载项，报错记录中的内容为报错代码的信息，根据报错代码的信息可以确定具体某个apk出错、或某个组件出错、或某个类出错、某个库文件出错，则在再次系统重启的过程中，不加载出错的加载项；例如：根据报错记录确定出apk2出错，在再次系统重启的过程中，不加载apk2。其中，报错记录可以通过记录表或日志等形式进行存储，本实施例及以下各实施例以报错记录通过记录表进行储存进行说明。
在一个例子中，在系统重启失败满足预设条件时，根据系统重启失败时生成的报错记录确定出错的加载项；其中，预设条件为在预设时长内系统重启失败的次数大于预设次数，或系统连续重启失败的次数大于预设次数，或预设时长内系统重启失败。
在一些实施例中，若在预设时长内系统重启失败的次数大于预设次数，则根据系统重启失败时生成的报错记录确定出错的加载项，若在预设时长内系统重启失败的次数不大于预设次数，则终端再次系统重启。其中，预设时长和预设次数根据实际需要进行设定，本实施例不做具体限定。例如：预设时长为2分钟，预设次数为3次，若终端在2分钟内系统重启了4次，但是4次均系统重启失败，则根据系统重启失败时生成的报错记录确定出错的加载项。在一个例子中，若系统连续重启失败的次数大于预设次数，则根据系统重启失败时生成的报错记录确定出错的加载项，若系统连续重启失败的次数不大于预设次数，则终端再次进行系统重启。其中，预设次数根据实际需要进行设定，本实施例不做具体限定。在一个例子中，若预设时长内系统重启失败，则根据系统重启失败时生成的报错记录确定出错的加载项，若还未到达预设时长，则继续尝试系统重启。其中，预设时长根据实际需要进行设定，本实施例不做具体限定。当系统重启失败满足预设条件时，说明系统再次重启失败的可能性较高，而此时采取查找系统重启失败时生成的报错记录，并根据报错记录确定出错的加载项；在再次系统重启的过程中，不加载出错的加载项，可以提高系统重启成功的概率。
在一个例子中，通过查找系统重启失败时生成的所有报错记录，并根据所有的报错记录确定所有出错的加载项，在再次系统重启的过程中，不加载所有出错的加载项。
在一些实施例中，所有的报错记录可以存储在一个记录表中，也可以根据报错记录对应的加载项类型分别存储在不同的记录表中，加载项类型至少包括以下几种：应用程序包apk、组件、类、库文件等等。
当报错记录按照不同的加载项类型分别进行存储时，不同的记录表可以存储在一个存储模块中，也可以存储在不同的存储模块中。此时，终端可以同时查找所有的加载项类型对应的记录，查找出所有的报错记录，终端也可以遍历按照优先级排序的加载项类型，查找出所有的报错记录。例如：若报错记录以记录表的形式进行存储，报错记录对应的加载项类型为apk时，报错记录保存在表一，报错记录对应的加载项类型为组件时，报错记录保存在表二，报错记录对应的加载项类型为类时，报错记录保存在表三，报错记录对应的加载项类型为库文件时，报错记录保存在表四；表一、表二、表三、表四存储在同一个存储模块中，或者表一、表二、表三、表四分别存储在不同的存储模块中。若加载项类型的优先级排序为：应用程序包apk、组件、类、库文件，当系统重启失败时，先查找表一中是 否包含报错记录，再查找表二、表三、表四，从而查找完所有的报错记录。
在一个例子中，在系统重启失败时，按照任意的顺序遍历加载项类型，只要查找到任一加载项类型对应的记录中包含系统重启失败时生成的报错记录时，停止遍历，根据报错记录确定出错的加载项。
在一个例子中，查找系统重启失败时生成的报错记录，并根据报错记录确定出错的加载项，包括：遍历按照优先级排序的加载项类型，查找加载项类型对应的记录中是否包含系统重启失败时生成的报错记录；当任一加载项类型对应的记录中包含系统重启失败时生成的报错记录时，根据报错记录确定出错的加载项，并停止遍历。
在一些实施例中，如上述例子，若加载项类型的优先级排序为：应用程序包apk、组件、类、库文件，当系统重启失败时，先查找表一中是否包含报错记录，若表一中包含报错记录，根据报错记录确定出错的加载项为apk1，并停止遍历，在再次系统重启的过程中，不加载出错的加载项apk1，若表一中不包含报错记录，继续查找表二中是否包含报错记录；若表二中包含报错记录，根据报错记录确定出错的加载项为组件1，并停止遍历，在再次系统重启的过程中，不加载出错的加载项组件1，若表二中不包含报错记录，继续查找表三中是否包含报错记录；若表三中包含报错记录，根据报错记录确定出错的加载项为类1，并停止遍历，在再次系统重启的过程中，不加载出错的加载项类1，若表三中不包含报错记录，继续查找表四中的报错记录，根据报错记录确定出错的加载项为库文件1，并停止遍历，在再次系统重启的过程中，不加载出错的加载项库文件1。通过这样的方法，只要查找到一种加载项类型对应的记录中包含报错记录时，就立即根据报错记录确定出错的加载项，并停止遍历，在再次系统重启的过程中，不加载出错的加载项，使得当系统重启失败确实由该一种出错的加载项造成时，可以缩短系统重启成功的时间。在一个例子中，在不加载出错的加载项之后，还包括系统循环启动步骤；系统循环启动步骤包括：当再次系统重启失败时，若未执行完遍历，查找下一加载项类型对应的记录，直至再次查找到系统重启失败时生成的报错记录，根据报错记录确定出错的加载项，并再次系统重启；在再次系统重启的过程中，不加载遍历过程中查找到的各出错的加载项；重复执行系统循环启动步骤，当执行完遍历时，进入recovery模式。例如：若加载项类型的优先级排序为：应用程序包apk、组件、类，报错记录保存在表一、表二、表三中，当系统重启失败时，先查找表一中是否包含报错记录，若表一中包含报错记录，根据报错记录确定出错的加载项为apk1，并停止遍历，在再次系统重启的过程中，不加载出错的加载项apk1，当再次系统重启失败时，还未执行完遍历，查找表二中是否包含报错记录，若表二中包含报错记录，根据报错记录确定出错的加载项为组件1，在再次系统重启的过程中，不加载遍历过程中查找到的各出错的 加载项apk1和组件1，当再次系统重启失败时，还未执行完遍历，查找表三中是否包含报错记录，若表三中包含报错记录，根据报错记录确定出错的加载项为类1，在再次系统重启的过程中，不加载遍历过程中查找到的各出错的加载项apk1、组件1和类1，当再次系统重启失败时，已执行完遍历，进入recovery模式。
在一个例子中，查找系统重启失败时生成的报错记录，并根据报错记录确定出错的加载项，包括：遍历按照优先级排序的加载项类型的组合，查找加载项类型的组合对应的记录中是否包含系统重启失败时生成的报错记录；其中，组合中至少包括两种加载项类型；当任一加载项类型对应的记录中包含系统重启失败时生成的报错记录时，根据报错记录确定出错的加载项，并停止遍历。
在一些实施例中，如上述例子，表一、表二为组合一，表三、表四为组合二，若加载项类型的组合的优先级排序为：组合一、组合二，当系统重启失败时，先查找表一和表二中是否包含报错记录，若表一和/或表二中包含报错记录，根据报错记录确定出错的加载项为apk1和/或组件1，在再次系统重启的过程中，不加载出错的加载项apk1和/或组件1，若表一和表二中不包含报错记录，继续查找表三和/或表四中的报错记录，根据报错记录确定出错的加载项为类1和/或库文件1，在再次系统重启的过程中，不加载出错的加载项库文件1。在一个例子中，在不加载出错的加载项之后，还包括系统循环启动步骤；系统循环启动步骤包括：当再次系统重启失败时，若未执行完遍历，查找下一加载项类型的组合对应的记录，直至再次查找到系统重启失败时生成的报错记录，根据报错记录确定出错的加载项，并再次系统重启；在再次系统重启的过程中，不加载遍历过程中查找到的各出错的加载项；重复执行系统循环启动步骤，当执行完遍历时，进入recovery模式。例如：如上述例子，表一、表二为组合一，表三、表四为组合二，若加载项类型的组合的优先级排序为：组合一、组合二，当系统重启失败时，先查找表一和表二中是否包含报错记录，若表一和/或表二中包含报错记录，根据报错记录确定出错的加载项为apk1和/或组件1，并停止遍历，在再次系统重启的过程中，不加载出错的加载项apk1和/或组件1，当再次系统重启失败时，还未执行完遍历，查找表二中是否包含报错记录，若表二中包含报错记录，根据报错记录确定出错的加载项为组件1和/或库文件1，在再次系统重启的过程中，不加载遍历过程中查找到的各出错的加载项apk1和/或组件1和/或组件1和/或库文件1，当再次系统重启失败时，已执行完遍历，进入recovery模式。
在一个例子中，在根据系统重启失败时生成的报错记录确定出错的加载项之后，对出错的加载项进行临时标记，当再次系统重启时，不加载出错的加载项。
在一个例子中，若出错的加载项的类型为应用程序包apk，不加载出错的apk和与出错 的apk关联的apk。例如：出错的apk为apk1，与apk1关联的apk为apk2和apk3，则不加载apk1、apk2和apk3。
在一个例子中，在根据系统重启失败时生成的报错记录确定出错的加载项之后，还包括：若出错的加载项的类型为应用程序包apk，对出错的apk的完整性进行检查，并将检查结果进行保存。
在一些实施例中，若出错的apk为apk1，对apk1的完整性进行检查是指检查apk1的文件是否是完整的，若apk1的文件是完整的，则apk1的完整性检查通过，即将检查结果保存为apk1完整，若apk1的文件是不完整的，则apk1的完整性检查不通过，即将检查结果保存为apk1不完整。对apk1的完整性进行检查，并将检查结果进行保存可以与步骤102同时进行，或在步骤102之前进行，或在步骤102之后进行。通过对出错的apk进行完整性检查，可以知道是否apk文件本身不完整，从而可以确定出系统重启失败的根本原因，有利于后续对出错的加载项的修复。在一个例子中，若出错的加载项的类型为应用程序包apk，但是无法确定具体哪个apk出错时，可以对所有的apk进行完整性检查。在一个例子中，不加载出错的加载项，包括：不加载出错的apk和与出错的apk关联的apk。当apk之间相互关联时，同时不加载与出错的apk关联的apk，可以进一步提高系统重启成功的概率。
本实施例中，在系统重启失败时，查找系统重启失败时生成的报错记录，并根据报错记录确定出错的加载项，在再次系统重启的过程中，不加载出错的加载项，提高了系统重启成功的概率，从而可以尽可能的降低多次系统重启失败而导致的用户数据丢失的丢失量。
本发明的第二实施例涉及一种系统重启方法，第二实施例与第一实施例大致相同，主要区别之处在于：当再次系统重启成功时，对出错的加载项进行标记。具体流程如图2所示，包括：
步骤201，在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项。
步骤202，在再次系统重启的过程中，不加载出错的加载项。
步骤201-202与步骤101-102类似，在此不再赘述。
步骤203，当再次系统重启成功时，对出错的加载项进行标记；其中，被标记的出错的加载项在系统重启中不被加载。
在一个例子中，在再次系统重启的过程中，不加载所有出错的加载项，当再次系统重启成功时，对所有出错的加载项进行标记，其中，被标记的出错的加载项在系统重启中不被加载。当再次系统重启失败时，则终端进入recovery模式。在一个例子中，在根据报错记录确定出错的加载项之后，对出错的加载项进行临时标记，当再次系统重启的过程中，不加载出错的加载项，若系统重启成功，则对出错的加载项进行正式标记，并将之前的临 时标记进行清除。
在一个例子中，在系统重启失败时，遍历按照优先级排序的内容，查找内容对应的记录中是否包含系统重启失败时生成的报错记录；其中，内容为加载项类型或加载项类型的组合，组合中至少包括两种所述加载项类型；当任一内容对应的记录中包含系统重启失败时生成的报错记录时，根据报错记录确定出错的加载项，并停止遍历。之后还包括：当再次系统重启成功时，对出错的加载项进行标记；或系统循环启动步骤，系统循环启动步骤包括：当再次系统重启失败时，若未执行完遍历，查找下一内容对应的记录，直至再次查找到系统重启失败时生成的报错记录，根据报错记录确定所述出错的加载项，并再次系统重启；在再次系统重启的过程中，不加载遍历过程中查找到的各出错的加载项；重复执行系统循环启动步骤，当执行完遍历时，进入recovery模式，或者当再次系统重启成功时，对所有出错的加载项进行标记。例如：如上述例子，若加载项类型的优先级排序为：应用程序包apk、组件、类、库文件，当系统重启失败时，先查找表一中是否包含报错记录，若表一中包含报错记录，根据报错记录确定出错的加载项为apk1，在再次系统重启的过程中，不加载出错的加载项apk1，当再次系统重启成功时，对出错的加载项apk1进行标记，终端恢复正常使用，当再次系统重启失败时，继续查找表二中是否包含报错记录，若表二中包含报错记录，根据报错记录确定出错的加载项为组件1，在再次系统重启的过程中，不加载出错的加载项apk1和组件1，当再次系统重启成功时，对出错的加载项apk1和组件1进行标记，终端恢复正常使用，当再次系统重启失败时，继续查找表三中是否包含报错记录，若表三中不包含报错记录，继续查找表四中是否包含报错记录，若表四中包含报错记录，根据报错记录确定出错的加载项为库文件1，在再次系统重启的过程中，不加载出错的加载项apk1、组件1和库文件1，当再次系统重启成功时，对出错的加载项apk1、组件1和库文件1进行标记，终端恢复正常使用，当再次系统重启失败时，则终端进入recovery模式。
本实施例中，通过对出错的加载项进行标记，使后续系统重启时同样不加载出错的加载项，避免再次出现不断进行系统重启的问题。
本发明的第三实施例涉及一种系统重启方法，第三实施例与第二实施例大致相同，主要区别之处在于：对出错的加载项进行修复。具体流程如图3所示，包括：
步骤301，在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项。
步骤302，在再次系统重启的过程中，不加载出错的加载项。
步骤303，当再次系统重启成功时，对出错的加载项进行标记；其中，被标记的出错的加载项在系统重启中不被加载。
步骤301-303与步骤201-203类似，在此不再赘述。
步骤304，对出错的加载项进行修复。
步骤305，若修复成功，清除出错的加载项的标记。
在一些实施例中，终端对出错的加载项的修复是指系统进行升级时(如：fota升级)对出错的加载项进行修复，若升级完成后没有出现系统重启失败的情况，则表明修复成功，清除出错的加载项的标记，且与出错的加载项相关的功能恢复正常使用。
本实施例中，由于对出错的加载项进行了修复，可以重新使用与出错的加载项相关的功能，增强了终端的实用性。
上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。
本发明第四实施例涉及一种终端，如图4所示，包括：至少一个处理器402；以及，与至少一个处理器通信连接的存储器401；其中，存储器401存储有可被至少一个处理器402执行的指令，指令被至少一个处理器402执行，以使至少一个处理器402能够执行上述实施例中的系统重启方法。
其中，存储器401和处理器402采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器402和存储器401的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器402处理的数据通过天线在无线介质上进行传输，在一些实施例中，天线还接收数据并将数据传送给处理器402。
处理器402负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器401可以被用于存储处理器402在执行操作时所使用的数据。
本发明第五实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。
本发明实施例相对于一些情形而言，在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项，在再次系统重启的过程中，不加载出错的加载项，提高了系统重启成功的概率，从而可以尽可能的降低多次系统重启失败而导致的用户数据丢失的丢失量。
本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施例是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的本质和范围。

Claims (10)

  1. 一种系统重启方法，包括：
    在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项；
    在再次系统重启的过程中，不加载所述出错的加载项。
  2. 根据权利要求1所述的系统重启方法，其中，在所述不加载所述出错的加载项之后，还包括：
    当所述再次系统重启成功时，对所述出错的加载项进行标记；其中，被标记的所述出错的加载项在系统重启中不被加载。
  3. 根据权利要求1或2所述的系统重启方法，其中，所述根据系统重启失败时生成的报错记录确定出错的加载项，包括：
    遍历按照优先级排序的内容，查找所述内容对应的记录中是否包含系统重启失败时生成的报错记录；其中，所述内容为加载项类型或加载项类型的组合，所述组合中至少包括两种所述加载项类型；
    当任一所述内容对应的记录中包含系统重启失败时生成的报错记录时，根据所述报错记录确定出错的加载项，并停止遍历。
  4. 根据权利要求3所述的系统重启方法，其中，在所述不加载所述出错的加载项之后，还包括系统循环启动步骤；
    所述系统循环启动步骤包括：当所述再次系统重启失败时，若未执行完遍历，查找下一所述内容对应的记录，直至再次查找到系统重启失败时生成的所述报错记录，根据所述报错记录确定所述出错的加载项，并再次系统重启；在所述再次系统重启的过程中，不加载遍历过程中查找到的各所述出错的加载项；
    重复执行所述系统循环启动步骤，当执行完遍历时，进入recovery模式。
  5. 根据权利要求2所述的系统重启方法，其中，在所述当所述再次系统重启成功时，对所述出错的加载项进行标记之后，还包括：
    对所述出错的加载项进行修复；
    若修复成功，清除所述出错的加载项的标记。
  6. 根据权利要求1所述的系统重启方法，其中，所述在系统重启失败时，根据系统重启失败时生成的报错记录确定出错的加载项，包括：
    在系统重启失败满足预设条件时，根据系统重启失败时生成的报错记录确定出错的加载项；其中，所述预设条件为在预设时长内系统重启失败的次数大于预设次数，或系统连 续重启失败的次数大于预设次数，或预设时长内系统重启失败。
  7. 根据权利要求1所述的系统重启方法，其中，在所述根据系统重启失败时生成的报错记录确定出错的加载项之后，还包括：
    若所述出错的加载项的类型为应用程序包apk，对出错的apk的完整性进行检查，并将检查结果进行保存。
  8. 根据权利要求7所述的系统重启方法，其中，所述不加载所述出错的加载项，包括：
    不加载所述出错的apk和与所述出错的apk关联的apk。
  9. 一种终端，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至8中任一所述的系统重启方法。
  10. 一种计算机可读存储介质，存储有计算机程序，其中，所述计算机程序被处理器执行时，使得所述处理器执行权利要求1至8中任一项所述的系统重启方法。
PCT/CN2021/091932 2020-05-15 2021-05-06 系统重启方法、终端及存储介质 WO2021227926A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010410837.9 2020-05-15
CN202010410837.9A CN113672432A (zh) 2020-05-15 2020-05-15 系统重启方法、终端及存储介质

Publications (1)

Publication Number Publication Date
WO2021227926A1 true WO2021227926A1 (zh) 2021-11-18

Family

ID=78525287

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/091932 WO2021227926A1 (zh) 2020-05-15 2021-05-06 系统重启方法、终端及存储介质

Country Status (2)

Country Link
CN (1) CN113672432A (zh)
WO (1) WO2021227926A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086464A1 (en) * 2003-10-16 2005-04-21 International Business Machines Corporation Technique for system initial program load or boot-up of electronic devices and systems
CN101122874A (zh) * 2006-08-11 2008-02-13 中兴通讯股份有限公司 一种在不断电下保存系统数据的方法
CN101122875A (zh) * 2006-08-11 2008-02-13 深圳市朗科科技有限公司 一种系统复位方法
CN110225410A (zh) * 2019-06-18 2019-09-10 青岛海信宽带多媒体技术有限公司 提示机顶盒异常的方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086464A1 (en) * 2003-10-16 2005-04-21 International Business Machines Corporation Technique for system initial program load or boot-up of electronic devices and systems
CN101122874A (zh) * 2006-08-11 2008-02-13 中兴通讯股份有限公司 一种在不断电下保存系统数据的方法
CN101122875A (zh) * 2006-08-11 2008-02-13 深圳市朗科科技有限公司 一种系统复位方法
CN110225410A (zh) * 2019-06-18 2019-09-10 青岛海信宽带多媒体技术有限公司 提示机顶盒异常的方法及装置

Also Published As

Publication number Publication date
CN113672432A (zh) 2021-11-19

Similar Documents

Publication Publication Date Title
CN111078662B (zh) 一种区块链数据存储方法与装置
US9286164B2 (en) Electronic device to restore MBR, method thereof, and computer-readable medium
US9513894B2 (en) Database software upgrade using specify-validate-execute protocol
CN107315616B (zh) 一种固件的加载方法、装置及电子设备
CN108646982B (zh) 一种基于ubifs的数据自动修复方法及装置
US7487385B2 (en) Apparatus and method for recovering destroyed data volumes
CN108932249B (zh) 一种管理文件系统的方法及装置
KR20170040734A (ko) 업데이트 제어 방법을 갖는 전자 시스템 및 그것의 동작 방법
US9330153B2 (en) System, method, and computer readable medium that coordinates between devices using exchange of log files
US20140075248A1 (en) Failure Mode Identification and Reporting
CN114895845A (zh) 一种emmc数据存储的控制方法及嵌入式主板
US8689048B1 (en) Non-logging resumable distributed cluster
CN108280097B (zh) 一种数据库系统的故障处理方法和装置
WO2021227926A1 (zh) 系统重启方法、终端及存储介质
CN109002317B (zh) 一种pcba固件升级方法及系统、pcba
CN111045710A (zh) 一种基于IPMI命令的SAS-Expander固件升级的方法、设备及介质
CN110968456B (zh) 分布式存储系统中故障磁盘的处理方法及装置
CN112148714B (zh) 数据监控方法、系统、存储介质及电子设备
CN115576903A (zh) 一种文件系统构建方法、计算设备及存储介质
CN114741091A (zh) 固件加载方法、装置、电子设备及计算机可读存储介质
CN109683980B (zh) 实现轨旁安全平台u盘配置文件可靠装载的方法
JP2001005693A (ja) 障害自動復旧システム、障害自動復旧方法および障害自動復旧用プログラムを記録した記録媒体
CN105278993A (zh) 一种基于Linux系统的驱动模块升级方法及装置
KR20200106124A (ko) 빅데이터 분석용 dbms를 위한 테스트 자동화 프레임워크 및 테스트 자동화 방법
CN110647526B (zh) 批量数据处理方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21803689

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 17.04.2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21803689

Country of ref document: EP

Kind code of ref document: A1