Method for restarting software
Patent Information
- Authority / Receiving Office
- TW · TW
- Patent Type
- Patents
- Current Assignee / Owner
- ACER INC
- Filing Date
- 2024-11-06
- Publication Date
- 2026-08-01
AI Technical Summary
Current software development methods rely heavily on human intervention, leading to code corruption and frequent crashes, which cause inconvenience to users and increase service costs, damaging the company's reputation and user loyalty.
A software restart method that monitors crashes, adjusts a recovery level based on crash time differences, and restarts the software with appropriate recovery processing to restore the original operating state, reducing the likelihood of recurring crashes.
The method effectively reduces the impact of software crashes by restoring the user's experience and giving engineers time to fix issues, minimizing user inconvenience and service disruptions.
Smart Images

Figure TWG2TB001903672_001 
Figure TWG2TB001903672_002 
Figure TWG2TB001903672_003
Abstract
Description
Technical Field
[0001] This invention relates to a software restart method, which attempts to restore the software to its original operating state as much as possible when the software crashes, so as to reduce the impact and inconvenience on users. Prior Technology
[0002] Currently, software development relies primarily on human operation and thought during coding. It's difficult to guarantee 100% programming correctness under human intervention. In severe cases, this can lead to code corruption.
[0003] When a customer uses a mobile application, such as an Android app or an app provided by a product manufacturer, and it crashes during operation, the backend (e.g., the server) typically collects the last call stack and current memory status of the crashed code via the network before handing it over to engineers for processing. Since the current version of the app is highly likely to crash repeatedly, this will lead to additional service costs or reduce customer stickiness to the app. Therefore, while handling / fixing the software, it is common practice to remove the app from platforms such as the App Store (or the manufacturer's download service page) or revert to an older version. However, this causes significant inconvenience to users and can damage the company's reputation and image.
[0004] Therefore, in the event of a code crash, it is necessary to try to restore the user's state before the crash as much as possible, in order to maintain stable operation and user experience, and to buy time for engineers to fix the problem. Summary of the Invention
[0005] In view of this, the present invention provides a software restart method that, when software crashes, can restore the software to its original stable operating state as much as possible and reduce the probability of crashes recurring, thereby reducing the impact and inconvenience on users.
[0006] A software restart method according to an embodiment of the present invention includes: monitoring whether a software program crashes during its execution phase; when the software program crashes during its execution phase, determining whether the time difference between the current crash and the previous crash exceeds a set tolerance range; if the time difference exceeds the tolerance range, setting the recovery level to an initial value when the time difference is greater than the upper limit of the tolerance range; and increasing the recovery level when the time difference is less than the lower limit of the tolerance range. Furthermore, if it is determined that the recovery level is not the highest level (i.e., the recovery level value has reached a preset value), then enabling the restart indicator and restarting the software program; after restarting the software program, performing recovery processing according to the recovery level.
[0007] In some of the above embodiments, when the aforementioned software program crashes during the execution phase, the crash time point is stored and the program stack and memory state at the time of the crash are sent to the service host.
[0008] In some of the above embodiments, the aforementioned page jump involves performing operations to retain or clear the data and page navigation stack of the program stack and memory state when a crash occurs.
[0009] In some of the above embodiments, the aforementioned software program further confirms whether the aforementioned restart indicator has been enabled each time it starts; if it is determined that the aforementioned restart indicator is enabled, the aforementioned response processing is performed according to the aforementioned response level.
[0010] In some of the above embodiments, if the aforementioned collapse time difference is within the range between the upper and lower limits of the aforementioned tolerance, the aforementioned recovery level is maintained unchanged, and then it is further determined whether the aforementioned recovery level is the highest level.
[0011] In some states of the above embodiments, when the aforementioned response level is determined to be the highest level, the operation of the aforementioned software program is terminated.
[0012] In some of the states of the above embodiments, the initial value of the aforementioned response level is zero. Simple Explanation of the Diagram
[0013] Figure 1 is a flowchart of the software restart method according to an embodiment of the present invention. Figure 2 is a diagram illustrating the response levels. Implementation
[0014] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings.
[0015] Certain terms are used in this specification and the claims to refer to specific constituent elements or components. Those skilled in the art will understand that manufacturers may use different names to refer to the same constituent element or component. This specification and the claims do not distinguish constituent elements or components based on differences in name, but rather on differences in function. The terms "comprising" and "including" used throughout this specification and the claims are open-ended and should be interpreted as "including but not limited to". The term "generally" means that within an acceptable margin of error, those skilled in the art can solve the technical problem and achieve the basic technical effect within a certain margin of error. Furthermore, the term "coupled" in this specification includes any direct and indirect electrical connection means. Therefore, if a first device is described as coupled to a second device, it means that the first device can be directly electrically connected to the second device, or indirectly electrically connected to the second device via other devices or connection means.
[0016] Modern electronic products support a wide range of functions and have diverse applications. To allow users to fully utilize the capabilities of their products, manufacturers typically provide suitable or corresponding applications for download. Similarly, users may download applications from other software vendors to enhance performance. For portable electronic devices such as smartphones, tablets, and laptops, manufacturers or software vendors can list applications on platforms like the App Store or their own download websites for users to download online. Manufacturers or software vendors also typically provide server hosting, allowing users' devices to connect to the server via the network to receive information on usage status and settings.
[0017] The following is a brief description of the software restart method of the present invention.
[0018] According to the software restart method of the present invention, when a user executes a software program in his electronic device, the processor or controller in the electronic device continuously monitors whether the software program crashes during the execution phase after starting (or executing) the software program.
[0019] It should be noted that after starting (or executing) the software program, the processor first checks whether a restart indicator has been enabled, for example, if it has been set. If the restart indicator is determined to be enabled, a predetermined recovery process is performed according to a recovery level (described below). After that, the processor continuously monitors whether the software program crashes during execution.
[0020] When the processor detects a software crash, it then determines whether the time difference between the current crash and the previous crash exceeds a set tolerance range.
[0021] If the crash time difference exceeds the tolerance limit, and if the crash time difference is greater than the upper limit of the tolerance limit, the processor sets the recovery level to its initial value, for example, zero. Conversely, if the crash time difference is less than the lower limit of the tolerance limit, the processor increments the recovery level by 1. Furthermore, if the crash time difference is within the range between the aforementioned upper and lower limits of the tolerance limit, the recovery level remains unchanged.
[0022] After deciding whether to adjust the recovery level based on whether the crash time difference exceeds the tolerance, the processor further determines whether the aforementioned recovery level is already the highest level (or whether its value has reached the preset value).
[0023] When the processor determines that the recovery level is not the highest level (i.e., the recovery level value has not reached the preset value), it enables a restart indicator, for example, setting it to 1, to indicate that a crash occurred during this software startup. If the processor determines that the recovery level is already the highest level, it terminates the software operation. The processor then restarts the software; after restarting the software, it redirects to a page based on the aforementioned recovery level to attempt to restore the software to its previous operating state.
[0024] By setting a restart indicator, the processor can check whether a crash occurred during the previous software operation each time the software program starts.
[0025] It is important to note that when a software program crashes during execution, the processor stores the crash time and sends the program stack and memory state at the time of the crash to the server. Furthermore, the processor's response involves either preserving or clearing data and page navigation stacks related to the program stack and memory state at the time of the crash.
[0026] Figure 1 is a flowchart of a software restart method according to an embodiment of the present invention. Hereinafter, the software restart method according to an embodiment of the present invention will be described in detail with reference to the flowchart in Figure 1.
[0027] When the processor of the electronic device starts (executes) the software program, firstly, in step S1, the processor confirms whether the software program startup is a "reboot". As mentioned above, the processor can check whether the reboot flag has been enabled (e.g., whether it has been set to "1") to confirm. If the software startup is not a "reboot" (step S1: No), the processor continues to monitor whether the software program has crashed, and simultaneously performs the software program's scheduled functions. Conversely, if the processor confirms that the software startup is a "reboot" (step S1: Yes), it proceeds to step S3 to perform recovery processing according to the recovery level (value). Afterward, the processor also continues to monitor whether the software program has crashed. When a crash is detected, it proceeds to step S2.
[0028] In step S2, when the processor detects a software crash during execution, it stores the crash time point and sends back or to the server host the program stack and memory state at the time of the crash, as well as relevant data that helps in problem analysis. Then, it proceeds to step S4.
[0029] In step S4, when the software program crashes during execution, the processor determines whether the time difference between the current crash and the previous crash exceeds a set tolerance range. Since crash-related information and data are recorded each time a crash occurs, the processor can obtain the previous crash time and compare it with the current crash time to obtain the crash time difference. If the crash time difference exceeds the tolerance range (Step S4: Yes), proceed to step S5. If the crash time difference does not exceed the tolerance range (Step S4: No), maintain the aforementioned recovery level (value) unchanged, and then proceed to step S6.
[0030] In step S5, when the collapse time difference is greater than the upper limit of the aforementioned tolerance range, the recovery level value is set to the initial value (e.g., zero); when the collapse time difference is less than the lower limit of the aforementioned tolerance range, the recovery level value is increased by 1. Then, proceed to step S6.
[0031] In step S6, the processor further determines whether the response level is already at the highest level (i.e., whether a predetermined value has been reached). If it is at the highest level (step S6: Yes), the process terminates the software program's operation. If the processor determines that the response level is not at the highest level (step S6: No), it will restart the flag enable (step S7), for example, setting it to 1. Afterwards, the processor restarts the software program and returns to step S1.
[0032] In this embodiment, the upper and lower limits of the tolerance range are set, for example, to 1 day and 1 hour, respectively, but are not limited to these. If the crash time difference is greater than the upper limit of the tolerance range, it means that no crash has occurred for a long time, so the recovery level can be set to the initial value, such as zero. If the crash time difference is less than the lower limit of the tolerance range, it means that crashes occur more frequently, so the recovery level (value) is increased so that subsequent software restarts can restore the original operating environment as much as possible and operate stably. If the recovery level is already the highest level (reaching the predetermined value), it means that all recovery attempts have failed, so no further software restarts will be performed.
[0033] Figure 2 is a diagram illustrating the response levels.
[0034] In the example of Figure 2, the response levels are set as Level_0, Level_1, Level_2, ..., Level_N, where N is a natural number. Level_0 is the initial response level, i.e., the response level (value) is zero, and Level_N is the highest response level. In this embodiment, the operation corresponding to response level Level_0 is, for example, restoring the complete navigation stack record of the page; the operation corresponding to response level Level_1 is, for example, jumping back to the root of the page navigation; the operation corresponding to response level Level_2 is, for example, clearing all downloadable (e.g., downloadable from the server host) non-volatile data; ...; and the operation corresponding to response level Level_N is, for example, not restarting the software after all failed attempts. Here, the operations corresponding to Level_0 to Level_N are merely illustrative and do not imply that the invention is limited thereto; they can be determined according to the actual response application requirements.
[0035] In this embodiment, the higher the recovery level, the more data or page (screen) navigation is cleared, and theoretically the chance of repeated crashes is smaller; conversely, the lower the recovery level, the more pages and data are retained, which is closer to the state of the software program before the crash. Although the user experience is better, the probability of crashing again is relatively higher.
[0036] Assume that on the server side, the current upper and lower limits of the tolerance range are set to 1 day and 1 hour. The navigation stack of the software program running on the electronic device is: (1) Login, (2) Homepage, (3) Main content, and (4) Detailed information, for a total of four layers. If a software crash is detected (step S2 in Figure 1), and the software program is currently on the "Detailed Information" page on the 4th layer, then when comparing the crash time difference with the tolerance in the aforementioned step S4, if it is found that the crash time difference (the current crash is more than 1 day from the most recent crash) has exceeded the upper limit of tolerance, then in step S5, the recovery level is set to the initial value (zero). Thus, after the software program restarts, in step S3, the operation corresponding to Level_0 will be executed according to the recovery level to attempt to restore the complete navigation stack record of the page. Additionally, if a software crash is detected (step S2 in Figure 1), the software will also remain on the "Details" page at level 4. However, if, during the comparison of the crash time difference and tolerance in step S4, it is found that the crash time difference (the time since the most recent crash) is less than 1 hour (i.e., below the lower limit of tolerance), then in step S5, the recovery level will be increased by 1, for example, from the current recovery level of Level_1 to Level_2. Thus, after the software restarts, in step S3, the operation corresponding to Level_2 will be executed according to the recovery level, clearing all non-volatile data that can be downloaded again (e.g., downloaded from the server host), and restoring the navigation stack to the login page at level 1, for example, restoring the page (screen) to the login page.
[0037] As can be seen from the above, the software restart method or mechanism of the present invention can adjust the recovery level when a crash occurs during the software program execution phase to cope with the probability of the crash recurring, and to try to restore the original navigation stack as much as possible. For example, it can restore the previous page before the crash (as mentioned in the aforementioned Level_0 handling), or restore to a page even higher than this previous page (as mentioned in the aforementioned Level_2 handling), etc. In this way, the impact of program crashes on users can be reduced, the software program can be removed and customers can be lost, and engineers can have more time to fix the problem.
[0038] While the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the scope of the invention. Anyone skilled in the art can make modifications and refinements without departing from the spirit and scope of the invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.
[0039] S1-S7: Steps
Claims
1. A software restart method, comprising: Monitor whether the monitoring software program crashes during its execution phase; When the aforementioned software program crashes during the execution phase, it is determined whether the time difference between the current crash and the previous crash exceeds the set tolerance range. In cases where the aforementioned crash time difference exceeds the aforementioned tolerance range, if the aforementioned crash time difference is greater than the upper limit of the aforementioned tolerance range, the recovery level value is set to the initial value; if the aforementioned crash time difference is less than the lower limit of the aforementioned tolerance range, the aforementioned recovery level value is increased by a predetermined value; if it is determined that the aforementioned recovery level is not the highest level (i.e., the aforementioned recovery level value has not reached the preset value), then after enabling the restart indicator, the aforementioned software program is restarted; after restarting the aforementioned software program, recovery processing is performed according to the aforementioned recovery level; wherein, if the aforementioned crash time difference is within the aforementioned tolerance range, the aforementioned recovery level is maintained unchanged, and then it is further determined whether the aforementioned recovery level is the highest level.
2. The software restart method as described in request item 1, wherein when the aforementioned software program crashes during the execution phase, the crash time point is further stored and the program stack and memory status at the time of the crash are sent to the service host.
3. The software restart method as requested in item 2, wherein the aforementioned response handling is to perform operations to retain or clear the data and page navigation stack of the program stack and memory state at the time of the crash.
4. The software restart method as requested in any of items 1 to 3, wherein after each startup, the aforementioned software program first confirms whether the aforementioned restart indicator has been enabled; and if it is determined that the aforementioned restart indicator is enabled, then the aforementioned response processing is performed according to the aforementioned response level.
5. As in the software restart method of request item 1, if the aforementioned response level is determined to be the highest level, then the operation of the aforementioned software program shall be terminated.
6. The software restart method as requested in item 1, wherein the initial value of the aforementioned response level is zero.
7. The software restart method as described in claim 1, wherein the aforementioned software restart method is executed by the processor or controller of the electronic device.