System restart method, terminal and storage medium

Abstract

An embodiment of the present invention relates to the field of communications, and discloses a system restart method, a terminal, and a storage medium. In the present invention, when a system restart fails, a loading item in error is determined according to an error record generated when the system restart fails; during the next system restart, the loading item in error is not loaded. By such a method, the amount of user data lost due to multiple system restart failures can be minimized as much as possible.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of communications, and in particular to a system restart method, a terminal and a storage medium. Background Art

[0002] At present, the memory space of terminals such as mobile phones and computers is getting larger and larger, and users can save 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. While bringing convenience to users, it also brings many unstable factors. Unstable factors make the terminal prone to abnormalities, resulting in the terminal being unable to be used normally. At this time, the terminal will take the system restart to eliminate the abnormality and restore normal use. During the system restart process, the terminal will clean up the data according to the number of system restarts, and restart again after cleaning the data. When the number of system restarts reaches a certain number, the terminal will enter the recovery mode, and the user can choose to continue the system restart or choose to restore the factory settings.

[0003] The inventors have found that the prior art has at least the following problems: when the terminal is continuously restarting the system, part of the user data has been lost, and after entering the recovery mode, a large amount of user data will be lost or even completely lost. Summary of the invention

[0004] The purpose of the embodiments of the present invention is to provide a system restart method, a terminal and a storage medium, so as to reduce the amount of user data lost due to multiple system restart failures as much as possible.

[0005] To solve the above technical problems, an embodiment of the present invention provides a system restart method, comprising: when the system restart fails, determining the erroneous add-on according to the error record generated when the system restart fails; during the process of restarting the system again, not loading the erroneous add-on.

[0006] An embodiment of the present invention also provides a terminal, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the system restart method described above.

[0007] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, wherein the computer program implements the above-mentioned system restart method when executed by a processor.

[0008] In the embodiments of the present invention, compared with the prior art, when the system restart fails, the loading item with an error is determined according to the error report record generated when the system restart fails. During the next system restart process, the loading item with an error is not loaded, which increases the probability of successful system restart, and thus can reduce the loss of user data caused by multiple system restart failures as much as possible. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] One or more embodiments are exemplarily illustrated by the pictures in the corresponding drawings. These exemplary illustrations do not limit the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the drawings in the figures do not constitute a proportional limitation.

[0010] Figure 1 is a flowchart of the system restart method according to the first embodiment of the present invention;

[0011] Figure 2 is a flowchart of the system restart method according to the second embodiment of the present invention;

[0012] Figure 3 is a flowchart of the system restart method according to the third embodiment of the present invention;

[0013] Figure 4 is a schematic structural diagram of the terminal according to the fourth embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0014] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below with reference to the drawings. However, those of ordinary skill in the art can understand that in the embodiments of the present invention, many technical details are provided to help readers better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solutions required to be protected by the present application can still be implemented. The following division of each embodiment is for convenience of description and should not constitute any limitation to the specific implementation manner of the present invention. Each embodiment can be combined and cross-referenced with each other on the premise of not being contradictory.

[0015] The first embodiment of the present invention relates to a system restart method applied to a terminal, such as a mobile phone, a computer, etc. The specific process is as Figure 1 shown, including:

[0016] Step 101, when the system restart fails, determine the loading item with an error according to the error report record generated when the system restart fails. Step 102, during the next system restart process, do not load the loading item with an error.

[0017] Specifically, the system restart within the terminal includes the system restart performed by the terminal based on user selection, and the system restart performed by the terminal to restore the normal operating state when the system_server process, which is a system service within the terminal, runs into an error. When the system restart within the terminal is successful, the terminal enters the normal operating state; when the system restart within the terminal fails, the number of times of system restart failure can be one or multiple times, and this embodiment does not make specific limitations. The terminal determines the faulty loading item according to the error record generated when the system restart fails. The content in the error record is the information of the error code. According to the information of the error code, it can be determined that a specific apk is faulty, or a specific component is faulty, or a specific class is faulty, or a specific library file is faulty. Then, during the next system restart process, the faulty loading item is not loaded. For example, if it is determined from the error record that apk2 is faulty, apk2 is not loaded during the next system restart process. Among them, the error record can be stored in the form of a record table or a log, etc. This embodiment and the following embodiments are described with the error record stored in a record table.

[0018] In one example, when the system restart failure meets a preset condition, the faulty loading item is determined according to the error record generated when the system restart fails; among them, the preset condition is that the number of times of system restart failure within a preset duration is greater than a preset number of times, or the number of consecutive system restart failures is greater than a preset number of times, or there is a system restart failure within a preset duration.

[0019] Specifically, if the number of system restart failures within a preset duration is greater than a preset number, determine the malfunctioning load item according to the error record generated when the system restart fails. If the number of system restart failures within the preset duration is not greater than the preset number, the terminal performs another system restart. Herein, the preset duration and the preset number are set according to actual needs and are not specifically limited in this embodiment. For example: the preset duration is 2 minutes and the preset number is 3 times. If the terminal attempts to restart the system 4 times within 2 minutes but all 4 attempts fail, determine the malfunctioning load item according to the error record generated when the system restart fails. In one example, if the number of consecutive system restart failures is greater than the preset number, determine the malfunctioning load item according to the error record generated when the system restart fails. If the number of consecutive system restart failures is not greater than the preset number, the terminal performs another system restart. Herein, the preset number is set according to actual needs and is not specifically limited in this embodiment. In one example, if the system restart fails within the preset duration, determine the malfunctioning load item according to the error record generated when the system restart fails. If the preset duration has not been reached, continue to attempt a system restart. Herein, the preset duration is set according to actual needs and is not specifically limited in this embodiment. When the system restart failure meets the preset conditions, it indicates that the probability of another system restart failure is relatively high. At this time, search for the error record generated when the system restart fails and determine the malfunctioning load item according to the error record. During the subsequent system restart, do not load the malfunctioning load item, which can increase the probability of a successful system restart.

[0020] In one example, by searching for all the error records generated when the system restart fails and determining all the malfunctioning load items according to all the error records, do not load all the malfunctioning load items during the subsequent system restart.

[0021] Specifically, all the error records can be stored in a record table, or can be separately stored in different record tables according to the load item types corresponding to the error records. The load item types at least include the following: application package apk, component, class, library file, etc.

[0022] When error records are stored separately according to different add-in types, different record tables can be stored in one storage module or in different storage modules. At this time, the terminal can search for all records corresponding to add-in types simultaneously to find all error records, or the terminal can traverse the add-in types sorted by priority to find all error records. For example: If error records are stored in the form of record tables, when the add-in type corresponding to the error record is apk, the error record is saved in Table 1; when the add-in type corresponding to the error record is a component, the error record is saved in Table 2; when the add-in type corresponding to the error record is a class, the error record is saved in Table 3; when the add-in type corresponding to the error record is a library file, the error record is saved in Table 4; Table 1, Table 2, Table 3, and Table 4 are stored in the same storage module, or Table 1, Table 2, Table 3, and Table 4 are stored in different storage modules respectively. If the priority order of add-in types is: application package apk, component, class, library file, when the system fails to restart, first check whether Table 1 contains error records, and then check Table 2, Table 3, and Table 4 to find all error records.

[0023] In one example, when the system fails to restart, traverse the add-in types in any order. As long as an error record generated when the system fails to restart is found in the records corresponding to any add-in type, stop traversing and determine the faulty add-in based on the error record.

[0024] In one example, find the error records generated when the system fails to restart and determine the faulty add-in based on the error records, including: traversing the add-in types sorted by priority to check whether the records corresponding to the add-in types contain the error records generated when the system fails to restart; when an error record generated when the system fails to restart is found in the records corresponding to any add-in type, determine the faulty add-in based on the error record and stop traversing.

[0025] Specifically, as in the above example, if the priority order of the add-on types is: application package apk, component, class, library file, when the system restart fails, first check whether Table 1 contains an error record. If Table 1 contains an error record, determine the add-on that has an error as apk1 according to the error record, and stop traversing. During the next system restart, do not load the add-on apk1 that has an error. If Table 1 does not contain an error record, continue to check whether Table 2 contains an error record; if Table 2 contains an error record, determine the add-on that has an error as component1 according to the error record, and stop traversing. During the next system restart, do not load the add-on component1 that has an error. If Table 2 does not contain an error record, continue to check whether Table 3 contains an error record; if Table 3 contains an error record, determine the add-on that has an error as class1 according to the error record, and stop traversing. During the next system restart, do not load the add-on class1 that has an error. If Table 3 does not contain an error record, continue to check the error record in Table 4, determine the add-on that has an error as library file 1 according to the error record, and stop traversing. During the next system restart, do not load the add-on library file 1 that has an error. By this method, as long as an error record is found in the record corresponding to a certain add-on type, immediately determine the add-on that has an error according to the error record, and stop traversing. During the next system restart, do not load the add-on that has an error, so that when the system restart failure is indeed caused by this one add-on with an error, the time for the system to restart successfully can be shortened. In an example, after not loading the add-on that has an error, it further includes a system loop startup step; the system loop startup step includes: when the system restart fails again, if the traversal has not been completed, check the record corresponding to the next add-on type until the error record generated when the system restart fails again is found, determine the add-on that has an error according to the error record, and restart the system again; during the next system restart, do not load each add-on that has an error found during the traversal; repeat the system loop startup step, and when the traversal is completed, enter the recovery mode.For example: If the priority order of add-in types is: application package apk, component, class, and the error records are saved in Table 1, Table 2, and Table 3. When the system fails to restart, first check if Table 1 contains error records. If Table 1 contains error records, determine the faulty add-in as apk1 based on the error records and stop traversing. During the next system restart, do not load the faulty add-in apk1. When the system fails to restart again and the traversal has not been completed, check if Table 2 contains error records. If Table 2 contains error records, determine the faulty add-in as component1 based on the error records. During the next system restart, do not load the faulty add-ins apk1 and component1 found during the traversal. When the system fails to restart again and the traversal has not been completed, check if Table 3 contains error records. If Table 3 contains error records, determine the faulty add-in as class1 based on the error records. During the next system restart, do not load the faulty add-ins apk1, component1, and class1 found during the traversal. When the system fails to restart again and the traversal has been completed, enter the recovery mode.

[0026] In one example, to find the error records generated when the system fails to restart and determine the faulty add-in based on the error records, it includes: traversing the combinations of add-in types sorted by priority, and checking if the records corresponding to the combinations of add-in types contain the error records generated when the system fails to restart; where at least two add-in types are included in the combination; when the records corresponding to any add-in type contain the error records generated when the system fails to restart, determine the faulty add-in based on the error records and stop traversing.

[0027] Specifically, as in the above example, Table 1 and Table 2 form a combination, and Table 3 and Table 4 form a combination. If the priority order of the combinations of add-on types is: combination one, combination two, when the system restart fails, first check whether Table 1 and Table 2 contain error records. If Table 1 and / or Table 2 contain error records, determine the faulty add-ons as apk1 and / or component 1 according to the error records. During the next system restart, do not load the faulty add-ons apk1 and / or component 1. If Table 1 and Table 2 do not contain error records, continue to check for error records in Table 3 and / or Table 4. Determine the faulty add-ons as class 1 and / or library file 1 according to the error records. During the next system restart, do not load the faulty add-on library file 1. In one example, after not loading the faulty add-ons, it further includes a system loop startup step; the system loop startup step includes: when the system restart fails again, if the traversal has not been completed, search for records corresponding to the next combination of add-on types until the error records generated when the system restart fails again are found. Determine the faulty add-ons according to the error records and restart the system again; during the next system restart, do not load each of the faulty add-ons found during the traversal; repeat the system loop startup step. When the traversal is completed, enter the recovery mode. For example: as in the above example, Table 1 and Table 2 form a combination, and Table 3 and Table 4 form a combination. If the priority order of the combinations of add-on types is: combination one, combination two, when the system restart fails, first check whether Table 1 and Table 2 contain error records. If Table 1 and / or Table 2 contain error records, determine the faulty add-ons as apk1 and / or component 1 according to the error records and stop the traversal. During the next system restart, do not load the faulty add-ons apk1 and / or component 1. When the system restart fails again and the traversal has not been completed, check whether Table 2 contains error records. If Table 2 contains error records, determine the faulty add-ons as component 1 and / or library file 1 according to the error records. During the next system restart, do not load each of the faulty add-ons apk1 and / or component 1 and / or component 1 and / or library file 1 found during the traversal. When the system restart fails again and the traversal has been completed, enter the recovery mode.

[0028] In one example, after determining the faulty add-ons according to the error records generated when the system restart fails, temporarily mark the faulty add-ons. When the system restarts again, do not load the faulty add-ons.

[0029] In one example, if the type of the faulty add-on is the application package apk, do not load the faulty apk and the apks associated with the faulty apk. For example: if the faulty apk is apk1 and the apks associated with apk1 are apk2 and apk3, then do not load apk1, apk2, and apk3.

[0030] In one example, after determining the faulty load item based on the error record generated when the system restart fails, it further includes: if the type of the faulty load item is an application package apk, checking the integrity of the faulty apk and saving the check result.

[0031] Specifically, if the faulty apk is apk1, checking the integrity of apk1 means checking whether the file of apk1 is complete. If the file of apk1 is complete, the integrity check of apk1 passes, and the check result is saved as apk1 is complete. If the file of apk1 is incomplete, the integrity check of apk1 fails, and the check result is saved as apk1 is incomplete. Checking the integrity of apk1 and saving the check result can be carried out simultaneously with step 102, or before step 102, or after step 102. By checking the integrity of the faulty apk, it can be known whether the apk file itself is incomplete, so as to determine the root cause of the system restart failure, which is beneficial to the subsequent repair of the faulty load item. In one example, if the type of the faulty load item is an application package apk, but it is impossible to determine which specific apk is faulty, the integrity of all apks can be checked. In one example, not loading the faulty load item includes: not loading the faulty apk and the apk associated with the faulty apk. When apks are associated with each other, not loading the apk associated with the faulty apk at the same time can further increase the probability of successful system restart.

[0032] In this embodiment, when the system restart fails, searching for the error record generated when the system restart fails and determining the faulty load item according to the error record. During the process of restarting the system again, not loading the faulty load item increases the probability of successful system restart, thereby minimizing the amount of user data loss caused by multiple system restart failures.

[0033] The second embodiment of the present invention relates to a system restart method. The second embodiment is substantially the same as the first embodiment, and the main difference is that: when the system restart is successful again, marking the faulty load item. The specific process is as Figure 2 shown, including:

[0034] Step 201, when the system restart fails, determining the faulty load item according to the error record generated when the system restart fails.

[0035] Step 202, during the process of restarting the system again, not loading the faulty load item.

[0036] Steps 201 - 202 are similar to steps 101 - 102 and will not be elaborated here.

[0037] Step 203: When the system restarts successfully again, mark the faulty load items; among them, the marked faulty load items are not loaded during system restart.

[0038] In one example, during the process of the system restarting again, all faulty load items are not loaded. When the system restarts successfully again, all faulty load items are marked. Among them, the marked faulty load items are not loaded during system restart. When the system restart fails again, the terminal enters the recovery mode. In one example, after determining the faulty load items according to the error record, the faulty load items are temporarily marked. During the process of the system restarting again, the faulty load items are not loaded. If the system restart is successful, the faulty load items are formally marked, and the previous temporary marks are cleared.

[0039] In one example, when the system restart fails, traverse the content sorted by priority to check whether the record corresponding to the content contains the error record generated when the system restart fails; where the content is a type of load item or a combination of load item types, and the combination includes at least two of the load item types; when the record corresponding to any content contains the error record generated when the system restart fails, determine the faulty load item according to the error record and stop the traversal. It also includes: when the system restart is successful again, mark the faulty load item; or the system loop startup step, which includes: when the system restart fails again, if the traversal is not completed, search for the record corresponding to the next content until the error record generated when the system restart fails is found again, determine the faulty load item according to the error record, and restart the system again; during the process of restarting the system again, do not load each faulty load item found during the traversal; repeat the system loop startup step, when the traversal is completed, enter the recovery mode, or when the system restart is successful again, mark all faulty load items. For example: in the above example, if the priority order of the load item types is: application package apk, component, class, library file, when the system restart fails, first check whether Table 1 contains the error record. If Table 1 contains the error record, determine that the faulty load item according to the error record is apk1. During the process of restarting the system again, do not load the faulty load item apk1. When the system restart is successful again, mark the faulty load item apk1, and the terminal resumes normal use. When the system restart fails again, continue to check whether Table 2 contains the error record. If Table 2 contains the error record, determine that the faulty load item according to the error record is component1. During the process of restarting the system again, do not load the faulty load items apk1 and component1. When the system restart is successful again, mark the faulty load items apk1 and component1, and the terminal resumes normal use. When the system restart fails again, continue to check whether Table 3 contains the error record. If Table 3 does not contain the error record, continue to check whether Table 4 contains the error record. If Table 4 contains the error record, determine that the faulty load item according to the error record is library file 1. During the process of restarting the system again, do not load the faulty load items apk1, component1, and library file 1. When the system restart is successful again, mark the faulty load items apk1, component1, and library file 1, and the terminal resumes normal use. When the system restart fails again, the terminal enters the recovery mode.

[0040] In this embodiment, by marking the faulty load item, the faulty load item is not loaded either during the subsequent system restart, avoiding the problem of continuous system restart again.

[0041] The third embodiment of the present invention relates to a system restart method. The third embodiment is substantially the same as the second embodiment, and the main difference is that: the faulty load items are repaired. The specific process is as follows Figure 3 shown, including:

[0042] Step 301, when the system restart fails, determine the faulty load item according to the error record generated when the system restart fails.

[0043] Step 302, during the process of restarting the system again, do not load the faulty load item.

[0044] Step 303, when the system restart is successful again, mark the faulty load item; among them, the marked faulty load item is not loaded during the system restart.

[0045] Steps 301-303 are similar to steps 201-203 and will not be elaborated here.

[0046] Step 304, repair the faulty load item.

[0047] Step 305, if the repair is successful, clear the mark of the faulty load item.

[0048] Specifically, the repair of the faulty load item by the terminal means that when the system is upgraded (such as: fota upgrade), the faulty load item is repaired. If there is no system restart failure after the upgrade is completed, it indicates that the repair is successful, the mark of the faulty load item is cleared, and the functions related to the faulty load item return to normal use.

[0049] In this embodiment, since the faulty load item is repaired, the functions related to the faulty load item can be reused, enhancing the practicality of the terminal.

[0050] The step division of the above various methods is only for clear description. When implemented, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are within the protection scope of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs, but not changing the core design of its algorithm and process are within the protection scope of this patent.

[0051] The fourth embodiment of the present invention relates to a terminal, as Figure 4 shown, including: at least one processor 402; and a memory 401 communicatively connected to the at least one processor; wherein, the memory 401 stores instructions executable by the at least one processor 402, and the instructions are executed by the at least one processor 402 so that the at least one processor 402 can execute the system restart method in the above embodiment.

[0052] Among them, the memory 401 and the processor 402 are connected in a bus manner. The bus can include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 402 and the memory 401 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art, and thus will not be further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single component or multiple components, such as multiple receivers and transmitters, and provides a unit for communicating with various other devices over a transmission medium. The data processed by the processor 402 is transmitted over a wireless medium via an antenna. Further, the antenna also receives data and transmits the data to the processor 402.

[0053] The processor 402 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions. The memory 401 can be used to store data used by the processor 402 when performing operations.

[0054] The fifth embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the method embodiments described above are implemented.

[0055] That is, those skilled in the art can understand that all or part of the steps of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a program. The program is stored in a storage medium and includes several instructions for causing a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs that can store program codes.

[0056] Those of ordinary skill in the art can understand that the above embodiments are specific embodiments for implementing the present invention, and in practical applications, various changes can be made in form and details without departing from the spirit and scope of the present invention.

Claims

1. A system restart method, characterized in that, including: When the system restart fails, traverse the content sorted by priority, and check whether the record corresponding to the content contains the error record generated when the system restart fails; wherein, the content is a type of load item or a combination of load item types, and the combination includes at least two of the load item types; When the record corresponding to any of the content contains the error record generated when the system restart fails, determine the faulty load item according to the error record, and stop traversing; During the subsequent system restart, do not load the faulty load item.

2. The system restart method according to claim 1, wherein After not loading the faulty load item, it further includes: When the subsequent system restart is successful, mark the faulty load item; wherein, the marked faulty load item is not loaded during system restart.

3. The system restart method according to claim 1, wherein After not loading the faulty load item, it further includes a system loop startup step; The system loop startup step includes: when the subsequent system restart fails, if the traversal has not been completed, find the record corresponding to the next content until the error record generated when the system restart fails is found again, determine the faulty load item according to the error record, and perform a system restart again; during the subsequent system restart, do not load each of the faulty load items found during the traversal; Repeat the system loop startup step, and when the traversal is completed, enter the recovery mode.

4. The system restart method according to claim 2, wherein After marking the faulty load item when the subsequent system restart is successful, it further includes: Repair the faulty load item; If the repair is successful, clear the mark of the faulty load item.

5. The system restart method according to claim 1, wherein When determining the faulty load item according to the error record generated when the system restart fails, it includes: When the system restart failure meets a preset condition, determine the faulty load item according to the error record generated when the system restart fails; wherein, the preset condition is that the number of system restart failures within a preset time period is greater than a preset number, or the number of consecutive system restart failures is greater than a preset number, or the system has restarted unsuccessfully within a preset time period.

6. The system restart method according to claim 1, wherein After determining the faulty load item according to the error record generated when the system restart fails, it further includes: If the type of the faulty load item is an application package apk, check the integrity of the faulty apk and save the check result.

7. The system restart method according to claim 6, characterized in that Not loading the faulty load item includes: Not loading the faulty apk and the apk associated with the faulty apk.

8. A terminal, characterized in that, including: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the system restart method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program, when executed by a processor, implements the system restart method according to any one of claims 1 to 7.

Images