Application crash processing method, electronic device, and storage medium
By performing keep-alive repair when an application crashes and preventing the restart of frequently crashing applications, the problem of high system load caused by frequent application crashes is solved, achieving effective application keep-alive and improved device stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG GEELY HLDG GRP CO LTD
- Filing Date
- 2026-05-14
- Publication Date
- 2026-07-21
Smart Images
Figure CN122431935A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, specifically to an application crash handling method, electronic device, and storage medium. Background Technology
[0002] When the application crashes frequently, the user interface will switch to the rescue mode interface for troubleshooting.
[0003] To prevent application (APP) crashes from triggering the system to automatically enter rescue mode, which would cause the user interface to frequently enter rescue mode and affect normal use, some electronic devices will disable rescue mode by default.
[0004] However, when rescue mode is turned off, if an application crashes, the electronic device will repeatedly try to restart the application in the background, which will cause the system server load to increase continuously, the electronic device to become less responsive, and the overall user experience to deteriorate. Summary of the Invention
[0005] In view of the above, embodiments of this application provide an application crash handling method, an electronic device, and a storage medium, which can solve the problem that frequent application crashes lead to high system service load, affect normal user interaction, and worsen the user experience.
[0006] In a first aspect, embodiments of this application provide an application crash handling method, including: If the target application experiences a first crash event and meets the first crash handling conditions when the rescue mode is off, then the target application will be saved and repaired. If a second crash event occurs in the target application after the target application has completed the keep-alive repair and the second crash handling conditions are met, the target application shall be prohibited from restarting.
[0007] This technical solution first determines whether the first crash handling condition is met when an application crashes. If the application meets this condition, a keep-alive repair is performed to restore normal application operation as much as possible, achieving the goal of keeping the application alive. After the keep-alive repair, if the application continues to crash and meets the second crash handling condition, the application is prohibited from restarting, avoiding ineffective restarting. This prevents frequent application crashes and repeated restarts from continuously consuming system resources, reducing the load on system services, and preventing system lag and slow response. Therefore, it effectively keeps applications alive while ensuring application continuity, preventing abnormal applications from unrestrainedly consuming system resources, improving overall system stability and smoothness, and not interfering with normal user interaction, thereby optimizing the device user experience.
[0008] In some embodiments, before confirming that the target application has experienced a first crash event and that the target application meets the first crash handling conditions, the method further includes: In response to the launch event of the target application, identify whether the target application is a disabled application; In response to the detection that the target application is a disabled application, the launch of the target application is prohibited.
[0009] By using this technical solution, the system can pre-check whether the target application is disabled before it starts, thereby intercepting and repairing ineffective faulty applications and avoiding invalid startup attempts and resource waste.
[0010] In some embodiments, identifying whether the target application is a disabled application includes: In response to the presence of the target application's program identifier in the abnormal application array, it is determined that the target application is a disabled application.
[0011] This technical solution allows for the accurate identification of disabled programs by examining an array of abnormal applications.
[0012] In some embodiments, when preventing the target application from restarting, the method further includes: Add the identifier of the target application to the array of abnormal applications.
[0013] This technical solution adds the application identifier that is prohibited from starting to an array, ensuring that subsequent startup requests are also rejected, thus avoiding a restart loop caused by program crashes.
[0014] In some embodiments, when preventing the target application from restarting, the method further includes: Determine the crash logs of the target application; In response to the program upgrade instruction for the crash log, the target application is updated.
[0015] This technical solution enables faulty applications to be accurately repaired without manual user intervention.
[0016] In some embodiments, after the update process for the target application is performed, the method further includes: After the target application is updated, the application identifier of the target application is removed from the abnormal application array; the abnormal application array indicates the application identifier of the abnormal application.
[0017] This technical solution enables the updated target application to start normally without manual user intervention.
[0018] In some embodiments, the program upgrade instruction is sent by the server, and after determining the crash log of the target application, the method further includes: The crash logs of the target application will be uploaded to the server.
[0019] In some embodiments, the first crash handling condition includes: the target application crashing a certain number of times within a first duration; and / or The second crash handling condition includes: the target application crashing a second time within a second duration.
[0020] This technical solution can accurately identify applications that are frequently crashing, thus avoiding accidental crashes that could lead to erroneous operations.
[0021] In some embodiments, the application crash handling method is applied to a target electronic device, and before detecting whether the target application meets a first crash handling condition, it further includes: Obtain the current hardware load of the target electronic device to obtain the first load; The first duration and / or the first number of times are determined based on the first load and / or the application type of the target application.
[0022] In some embodiments, before detecting whether the target application meets the second crash handling condition, the method further includes: Obtain the current hardware load of the target electronic device to obtain the second load; The second duration and / or the second number of times are determined based on the second load and / or the application type of the target application.
[0023] By adopting this technical solution, adjusting the crash detection threshold based on hardware load allows for earlier intervention when resources are scarce and reduces false positives when resources are plentiful. Adjusting the crash detection threshold based on application type enables differentiated crash handling and detection for applications with different security requirements, thereby achieving a balance between system stability and user experience.
[0024] In some embodiments, performing a keep-alive repair on the target application includes: Delete the application data of the target application.
[0025] This technical solution can solve the problem of application crashes caused by data corruption and keep the target application alive as much as possible.
[0026] In some embodiments, deleting the application data of the target application includes: Obtain the crash logs of the target application; The target exception directory is determined based on the crash log; Delete the application data in the target abnormal directory.
[0027] This technical solution allows for precise location of the specific data directory causing the crash by parsing the crash logs. Data in that directory can be deleted while other application data is preserved, which facilitates accurate repair and maximizes the protection of user data while resolving the crash issue, thus minimizing data loss.
[0028] In some embodiments, the application crash handling method is applied to a target electronic device, which includes at least one of in-vehicle devices, home appliances, wearable devices, drones, robots, mobile phones, and tablets.
[0029] Secondly, embodiments of this application also provide an electronic device, the electronic device including a processor and a memory, the memory being used to store instructions, and the processor being used to call the instructions in the memory, causing the electronic device to execute the above-described application crash handling method.
[0030] Thirdly, embodiments of this application also provide a computer-readable storage medium that stores computer instructions that, when executed on an electronic device, cause the electronic device to perform the aforementioned application crash handling method.
[0031] Fourthly, embodiments of this application also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the steps of the application crash handling method as described in the first aspect.
[0032] Understandably, the electronic devices, storage media, and computer program products provided above correspond to the application crash handling method of the first aspect above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding application crash handling method provided above, and will not be repeated here. Attached Figure Description
[0033] Figure 1 This is a flowchart of the steps of an application crash handling method according to an embodiment of this application.
[0034] Figure 2 This is a flowchart of the steps of an application crash handling method according to another embodiment of this application.
[0035] Figure 3 This is a schematic diagram of the device structure of an application crash handling apparatus according to an embodiment of this application.
[0036] Figure 4This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation
[0037] To better understand the above-mentioned objectives, features, and advantages of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.
[0038] The following description sets forth many specific details to provide a full understanding of this application. The described embodiments are only some, not all, of the embodiments of this application.
[0039] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein in the specification of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.
[0040] It should be further noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0041] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects, not to describe a specific order or sequence.
[0042] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0043] This application provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for handling target application crashes.
[0044] The application crash handling method may include: if a target application crashes and meets a first crash handling condition when rescue mode is off, then perform a keep-alive repair on the target application; after the keep-alive repair is completed, if a second crash occurs and meets a second crash handling condition, then prevent the target application from restarting.
[0045] The embodiments of this application take into account the continuity of electronic device operation, effectively keep applications alive, and avoid abnormal applications from consuming system resources without restraint, ensuring the overall stability and smoothness of the system, without affecting normal user interaction, and thus improving the user experience of electronic devices.
[0046] The application crash handling method of this application can be applied to one or more target electronic devices. The target electronic device is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, processors, microprogrammed control units (MCUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc. The target electronic device can be an in-vehicle device, such as a display head unit (DHU) or an in-vehicle infotainment head unit (IHU); home appliances, such as robot vacuums and smart refrigerators; wearable devices, such as smartwatches; drones; robots; mobile phones and tablets, etc., but is not limited to these.
[0047] Figure 1 This is a flowchart illustrating the steps of an embodiment of the application crash handling method of this application. Depending on different requirements, the order of the steps in the flowchart can be changed, and some steps can be omitted.
[0048] See Figure 1 As shown, the application crash handling method may include the following steps.
[0049] Step 101: If the target application crashes and meets the first crash handling condition when the rescue mode is off, perform a keep-alive repair on the target application.
[0050] The target application is an application configured in the target electronic device that is capable of crash handling. For example, assuming the target electronic device is an in-vehicle device, the target application can be a navigation and map application, an audio-visual entertainment application, or a vehicle control application, such as an application for controlling the vehicle's air conditioning temperature, but is not limited to these.
[0051] Rescue Mode refers to the crash intervention mechanism for applications in an operating system (such as Android).
[0052] For example, when the operating system detects that a target application meets the triggering conditions for rescue mode, such as a crash loop occurring within a set time window and the number of crashes exceeding a safety threshold, and rescue mode is not turned off, the operating system will trigger rescue mode. For example, it will terminate the target application's repeated restart behavior and then automatically perform operations to clean up application data or enter the underlying repair environment, etc.
[0053] If rescue mode is triggered, the operating system may interrupt the normal operation of foreground applications and the desktop. Users will not be able to stay on the current normal operation interface, but will be forced to jump to the rescue mode interface such as safe mode, black screen restart state or underlying diagnostic screen, or a rescue mode pop-up will appear, causing the original interaction process and display content to be interrupted.
[0054] For example, when the target electronic device is an in-vehicle device, the operating system used by the in-vehicle device can be called the in-vehicle system. In this case, rescue mode refers to the crash intervention mechanism of the target application in the in-vehicle system. The in-vehicle system can be Android, but is not limited to it. When the rescue mode in the in-vehicle system is not disabled, and the target application meets the triggering conditions of the rescue mode, the in-vehicle system will trigger the rescue mode and enter the rescue mode interface. This may interrupt the interaction between the driver / passengers and the in-vehicle device or the display content of the in-vehicle device. Therefore, the rescue mode of the in-vehicle device is generally set to the off state to ensure the driving experience and driving safety.
[0055] With rescue mode off, the target electronic device can detect whether the target application has experienced its first crash event.
[0056] The first crash event refers to a crash of the target application that has not undergone keep-alive repair. The target electronic device can detect whether a keep-alive repair has been performed on the target application using a keep-alive repair flag. This flag records whether the target application has been kept-alive repaired. For example, a keep-alive repair flag of true indicates that a keep-alive repair has been performed on the target application, while a flag of false indicates that a keep-alive repair has not been performed.
[0057] A target application crash refers to the unexpected exit of a target application during its operation due to unhandled exceptions or errors. It is usually manifested as the target application suddenly closing or becoming unresponsive.
[0058] If the target application experiences the first crash event described above, the target electronic device can further detect whether the target application meets the first crash handling conditions.
[0059] The first crash handling condition refers to the condition that triggers the keep-alive repair operation. The first crash handling condition can be used to determine whether the target application has entered a frequent crash state due to data corruption or other reasons, and whether it needs to perform preliminary repair, thereby accurately identifying the faulty application that needs intervention and avoiding premature or late intervention.
[0060] The first crash handling condition may include the target application crashing a certain number of times within a first time period.
[0061] The first duration refers to a backward time window with the current crash time as the end point and a length of the first duration. The current crash time refers to the time when the target application last crashed. That is, after the target application crashes, the first duration is traced back. If the number of crashes within this time period reaches the first count, it means that the first crash handling condition is met; if the number of crashes of the target application within this time period does not reach the first count, it means that the first crash handling condition is not met.
[0062] The first duration and the number of first crashes can be set according to actual application needs. For example, the first duration is 10 seconds and the number of first crashes is 5. That is, the first crash handling condition can include 5 crashes within 10 seconds, but is not limited to this.
[0063] For example, the first duration and / or the first count can also be dynamically determined in the following ways: First, the hardware load of the electronic device is obtained, resulting in the first load. The hardware load represents the usage of various computer hardware resources in the electronic device, which may include, but is not limited to, CPU utilization, available memory size, etc.
[0064] Then, based on the first load and / or the application type of the target application, determine the first duration and the first count.
[0065] For example, when the CPU utilization exceeds 80% or the available memory is less than 200MB, it indicates that the system resources are strained. The first duration is shortened to 8 seconds and the first number of times is reduced to 3 to allow for earlier intervention. When the system load is normal, the default of 10 seconds and 5 times is restored.
[0066] For example, electronic devices can determine the initial duration and number of times based on the security level corresponding to the application type. Navigation and vehicle control applications use stricter thresholds (e.g., 2 times in 5 seconds), while multimedia entertainment applications use more lenient thresholds (e.g., 8 times in 15 seconds).
[0067] Electronic devices can also determine the first duration and the first count by combining the first load and the application type of the target application. For example, the first duration and / or the first count can be obtained by weighted summation of the duration and / or the first count determined by both, thereby determining the first crash handling condition.
[0068] The embodiments of this application can adapt to differences in hardware load and application, respond quickly when resources are scarce, reduce misjudgments when resources are abundant, and provide stricter protection for applications involving driving safety, thereby achieving a balance between stability and user experience.
[0069] In some embodiments, step 101 can be implemented in the following way: the electronic device can monitor the running status of each target application in real time through a system server to detect whether the target application meets the first crash handling condition.
[0070] For example, when any target application crashes, the system service can use a crash handling callback function. Within this callback function, the system service can further call a crash counting function (denoted as updateProcessCrashCountLBp). This function counts the number of crashes within a short period, thereby promptly identifying applications that meet the first crash handling criteria. This provides an accurate basis for subsequent crash classification and handling, while also preventing false triggers due to occasional crashes, thus improving the reliability of the judgment.
[0071] If the target application meets the first crash handling condition mentioned above, then the target application will be kept alive and repaired.
[0072] Keep-alive repair is an application repair method performed when the application data of a target application is corrupted. For example, specific methods of keep-alive repair may include, but are not limited to, at least one of the following: clearing the application data in the target application, repairing the application data in the target application, such as replacing it with default application data.
[0073] For example, electronic devices can call a custom function, namely the application data deletion function (denoted as removeCrashedAppData), to delete application data. Deleting application data can solve the problem of target application startup failure due to data corruption.
[0074] The function performs the following sub-steps: forcibly terminates the application process to ensure that no files are occupied when data is subsequently deleted; deletes the target application's local storage data (i.e., application data).
[0075] For example, electronic devices can delete file data in a preset directory.
[0076] The default directory can be " / data / data / xxxAPP" or " / data / user / xxx / xxxAPP". The above directories are the standard storage locations for the private data of the target application in the operating system, but are not limited to these. In actual application, the user can set the path of the default directory according to the storage location of the application data.
[0077] In other embodiments, the electronic device may also acquire the crash log (logcat) of the target application, which refers to the logs from before to after a preset period of time when the target application crashes; determine the target abnormal directory based on the crash log; and delete the application data in the target abnormal directory.
[0078] For example, electronic devices can parse the exception stack in the crash log to identify the specific data unit type that caused the crash (i.e., the target exception directory).
[0079] For example, if the log contains SharedPreferencesImpl related exceptions (such as IllegalStateException, XmlPullParserException), the target exception directory is determined to be shared_prefs / ; if it contains SQLiteException or database is malformed, the target exception directory is determined to be databases / .
[0080] The above-mentioned method for identifying the target abnormal directory is merely an example, and the embodiments of this application do not limit it.
[0081] Once the target abnormal directory is identified, the application data under the target abnormal directory can be deleted, while other local storage data of the target application (such as login token, user settings, offline map favorites, etc.) can be retained.
[0082] This application embodiment identifies the target abnormal directory by analyzing crash logs, which can protect the integrity of application data to the greatest extent while repairing crashes, thereby improving user experience and reducing the risk of data loss caused by clearing all application data.
[0083] After performing a keep-alive repair, you can also set a keep-alive repair flag to record whether the target application has been kept-alive repaired, that is, whether the application data of the target application has been cleared.
[0084] For example, after deleting application data, the updateProcessCrashCountLBp function is called again. In the updateProcessCrashCountLBp function, there is also a field (denoted as dataCleaned), which is a keep-alive repair flag. Setting this field to true indicates that the target application has been kept-alive repaired. Recording whether the application data of the target application has been cleared through this field helps the electronic device to successfully identify the application data that has been kept-alive repaired when starting the target application, and prevents the clearing operation from being performed repeatedly.
[0085] In some embodiments, after a keep-alive repair, the electronic device can also reset the crash count of the target application to zero so that the statistics can be restarted in subsequent monitoring.
[0086] This application embodiment can solve the application crash problem caused by data corruption (such as database corruption or configuration file error) by clearing potentially corrupted private data, and restore the application to a usable state. In addition, this application embodiment can avoid repeated clearing operations on the same application by setting a flag and resetting the count, protect user data from being repeatedly deleted, and reduce unnecessary system overhead.
[0087] Step 102: After the target application completes the keep-alive repair, if the target application experiences a second crash event and meets the second crash handling conditions, then the target application is prohibited from restarting.
[0088] The second type of crash refers to a crash occurring in the target application after it has been saved and repaired.
[0089] The second crash handling condition is used to determine whether the fault of the target application has been resolved after keep-alive repair, that is, whether it still crashes frequently, so as to identify whether it is necessary to prevent the target application from restarting. This method can realize the hierarchical handling of target application crashes, and prevent the target application from restarting when keep-alive repair is ineffective, thus avoiding excessive intervention.
[0090] The second crash handling condition may include the target application crashing a second time within a second duration.
[0091] The second duration refers to the backward time window with the current crash time as the end point and a length of this second duration. The current crash time refers to the time when the target application last crashed after the keep-alive repair was performed.
[0092] In other words, the detection of whether the target application meets the second crash handling condition by the target electronic device may include: after the target application is kept alive and repaired, if a crash occurs, the second time period is traced back. If the number of crashes in that time period reaches the second number, it means that the second crash handling condition is met; if the number of crashes of the target application in that time period does not reach the second number, it means that the second crash handling condition is not met.
[0093] The values of the second duration and the second number can be the same as or different from the first duration and the first number. This application does not limit this.
[0094] In some embodiments, the second duration and the second number of times can be set according to actual application requirements. For example, the second duration is 10 seconds, the second number of times is 5, and the second crash handling condition may include crashing 5 times within 10 seconds, but is not limited to this.
[0095] For example, the second duration and / or the second number can also be dynamically determined in the following ways: First, the hardware load of the target electronic device is obtained, resulting in the second load. The hardware load represents the usage of various computer hardware resources of the electronic device, which may include, but is not limited to, CPU utilization, available memory size, etc.
[0096] Then, based on the second load and / or the application type of the target application, the second duration and the second number of times are determined.
[0097] For example, when the CPU utilization exceeds 80% or the available memory is less than 200MB, it indicates that the system resources are strained. The second duration is shortened to 8 seconds and the number of repetitions is reduced to 3 to allow for earlier intervention. When the system load is normal, the default of 10 seconds and 5 repetitions is restored.
[0098] For example, the target electronic device can determine the second duration and the second number of times based on the security level corresponding to the application type. Navigation and vehicle control applications use stricter thresholds (e.g., 2 times in 5 seconds), while multimedia entertainment applications use more lenient thresholds (e.g., 8 times in 15 seconds).
[0099] The target electronic device can also determine the second duration and the second number of occurrences by combining the second load and the application type of the target application. For example, the second duration and / or the second number of occurrences determined by the two can be weighted and summed to obtain the second duration and / or the second number of occurrences, thereby determining the second crash handling condition.
[0100] The embodiments of this application can adapt to differences in hardware load and application, respond quickly when resources are scarce, reduce misjudgments when resources are abundant, and provide stricter protection for applications involving driving safety, thereby achieving a balance between stability and user experience.
[0101] In step 102, after the target application completes the keep-alive repair, the electronic device can detect whether the target application has started. If the target application has started successfully, it means that the keep-alive repair was successful.
[0102] If the target application fails to start completely, that is, if the target application experiences a second crash event, the electronic device can detect whether the target application meets the second crash handling conditions. For example, the electronic device can recount the number of crashes of the target application within the second time period.
[0103] If the target application crashes a second time within the second time period, such as crashing 5 times within 10 seconds, it indicates that the keep-alive repair has failed to resolve the fault of the target application. The target application may have code defects rather than simple data corruption, and more stringent measures need to be taken. Therefore, the target application is determined to meet the second crash handling condition, and the target application is prohibited from starting at this time.
[0104] In this scenario, the target electronic device can also determine the crash log of the target application; and update the target application in response to the program upgrade instructions based on the crash log.
[0105] The target electronic device can upload the crash logs of the target application to the server. For example, the error code and the crash logs can be uploaded to the server together. After receiving the crash logs, the server can provide them to the developers for analysis to generate a repair package for handling the crashes of the target application. The server will then send an upgrade instruction to the target electronic device, which will instruct the target application to be updated using the repair package. Upon receiving the upgrade instruction, the target electronic device can update the target application in response to the upgrade instruction based on the crash logs.
[0106] For example, after a keep-alive repair, the target electronic device continues to monitor the target application for crashes. When the target application is subsequently restarted and crashes again, it indicates a second crash event. The operating system will call the crash counting function again. In this case, the target electronic device can also check the keep-alive repair flag (denoted as dataCleaned). If the keep-alive repair flag indicates that the target application has been kept-alive repaired, for example, if the dataCleaned flag is true, then the target electronic device checks whether the target application meets the second crash handling conditions. If the second crash handling conditions are met, the target application is prevented from restarting.
[0107] In some embodiments, when the second crash handling condition is met, the operation of preventing the target application from restarting can be implemented by adding the identifier of the target application to the abnormal application array. When this method is applied to the target electronic device, the abnormal application array records the application identifiers of the disabled target applications on the target electronic device. Those skilled in the art can set the specific representation of the aforementioned application identifiers according to actual needs, such as, but not limited to, setting the application identifier to at least one of the following: the package name corresponding to the target application, a string, a unique identifier number, etc.
[0108] For example, a target electronic device can initialize an empty array. When it is necessary to prevent the target application from starting, the identifier of the target application can be added to the array to form an abnormal application array, which can be persistently stored in the target electronic device.
[0109] If the target application is identified by its package name, and the package name of the target application to be launched is in the array of abnormal applications, then the launch failure will be returned directly, and the launch of the target application will be prohibited.
[0110] By using the above method, the target application will be unable to be launched again, thus completely avoiding the multiple restarts of the crashed target application, thereby avoiding the problem of continuously increasing system server load and slowing down system response, and thus restoring the overall response speed of electronic devices and avoiding the lag caused by the smart cockpit.
[0111] Specifically, refer to Figure 2 As shown in the embodiment of this application, another application crash handling method is provided. In this application crash handling method, before the application starts, it checks whether the identifier of the target application is stored in the abnormal application array.
[0112] The crash handling method for this target application includes the following steps: Step 201: In response to the launch event of the target application, identify whether the target application is a disabled application.
[0113] The identification of whether a target application is a disabled application can be achieved in the following ways: in response to the existence of the program identifier of the target application in the abnormal application array, the target application is determined to be a disabled application; in response to the absence of the program identifier of the target application in the abnormal application array, the target application is determined to be a non-disabled application.
[0114] For example, when rescue mode is off, when a user clicks an application icon or the system needs to launch an application, the Activity Manager Service (AMS) first obtains the package name of the application to be launched, and then searches in a pre-maintained array of abnormal applications (blacklist) to see if the package name of the target application to be launched exists, thus preventing the target application that has been banned from launching from occupying resources and improving the response efficiency of electronic devices.
[0115] If the target application is a disabled application, then perform step 202 below.
[0116] If the target application is not disabled, proceed with steps 203 to 205 below.
[0117] Step 202: Prevent the target application from launching.
[0118] If the package name of the target application is found in the abnormal application array, it means that the target application has been banned from starting due to frequent crashes and ineffective keep-alive repair. In this case, the electronic device can directly prevent the target application from starting, thereby intercepting the faulty application and preventing it from continuing to restart and crash.
[0119] In some embodiments, the electronic device may also display a prompt message on the user interface, such as the application being temporarily disabled due to frequent malfunctions.
[0120] Step 203: Launch the target application.
[0121] If the application's package name is not found in the abnormal application array, it indicates that the application is in a normal state. The system starts the target application normally and proceeds to steps 204 to 206 to ensure that normal applications are not affected and maintain the user experience.
[0122] Step 204: If the target application experiences a first crash event and meets the first crash handling conditions, then perform a keep-alive repair on the target application.
[0123] Step 205: After the target application completes the keep-alive repair, if the target application experiences a second crash event and meets the second crash handling conditions, then the target application is prohibited from restarting.
[0124] Steps 204 to 205 are largely the same as steps 101 to 102, and will not be repeated here.
[0125] The embodiments of this application perform blacklist checks before the target application starts, which can intercept isolated applications earlier and avoid invalid startup attempts and resource consumption.
[0126] In some embodiments, when the target application is prevented from restarting (i.e. added to the abnormal application array), the electronic device can capture and upload crash logs. For example, the target electronic device notifies the logging module to capture system logs for the corresponding time period, such as capturing system logs, event logs, and kernel logs for 30 seconds before and after the crash, compressing them, and uploading them to the server, such as the cloud. After receiving the logs of the abnormal application, the server developers analyze the cause of the crash, locate code defects, and generate a repair package for the target application.
[0127] The server can send program upgrade commands to the target electronic device. For example, if the target electronic device is an in-vehicle device, the server can push the repair package based on the vehicle VIN or device ID through software over-the-air (SOTA) upgrade.
[0128] The target electronic device responds to the program upgrade command by performing signature verification and integrity verification. After the verification is completed, the target application is updated using the repair package.
[0129] After the target application is updated, the electronic device automatically removes the target application's application identifier from the list of abnormal applications and resets the crash count and keep-alive repair flag. After that, the target application can start and be used normally.
[0130] When the target electronic device is an in-vehicle device, such as a car infotainment system, this technical solution enables faulty applications to be repaired remotely without manual user intervention, thereby improving the maintainability and user satisfaction of the smart cockpit.
[0131] Furthermore, in this embodiment of the application, if the target application fails to start within a specified time, a progressive crash handling method is adopted for the exception. First, the data under APP data (i.e., application data) is deleted to prevent startup failure caused by data corruption. If this method cannot repair the target application, the exception target application is marked, the target application is temporarily prohibited from starting, the exception code is recorded, the crash log is captured, and the error is reported to the cloud. The exception of the target application is addressed in a targeted manner, so as to keep the target application alive as much as possible when the target application crashes frequently, without affecting the system load.
[0132] Based on the same idea as the application crash handling method in the above embodiments, this application also provides an application crash handling apparatus, which can be used to execute the above application crash handling method. For ease of explanation, the structural schematic diagram of the application crash handling apparatus embodiment only shows the parts related to the embodiments of this application. Those skilled in the art will understand that the illustrated structure does not constitute a limitation on the apparatus, and may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.
[0133] like Figure 3 As shown, the application crash handling device includes a crash monitoring module 301 and a boot prevention module 302. In some embodiments, the above modules can be programmable software instructions stored in memory and executable by the processor. It is understood that in other embodiments, the above modules can also be program instructions or firmware embedded in the processor.
[0134] The crash monitoring module 301 is used to perform a keep-alive repair on the target application if a first crash event occurs in the target application and the target application meets the first crash handling conditions when the rescue mode is off. The startup prevention module 302 is used to prevent the target application from restarting if a second crash event occurs in the target application and the second crash handling conditions are met after the target application has completed the keep-alive repair.
[0135] This technical solution first determines whether the first crash handling condition is met when an application crashes. If the application meets this condition, a keep-alive repair is performed to restore normal application operation as much as possible, achieving the goal of keeping the application alive. After the keep-alive repair, if the application continues to crash and meets the second crash handling condition, the application is prohibited from restarting, avoiding ineffective restarting. This prevents frequent application crashes and repeated restarts from continuously consuming system resources, reducing the load on system services, and preventing system lag and slow response. Therefore, it effectively keeps applications alive while ensuring application continuity, preventing abnormal applications from unrestrainedly consuming system resources, improving overall system stability and smoothness, and not interfering with normal user interaction, thereby optimizing the device user experience.
[0136] In some embodiments, before confirming that the target application has experienced a first crash event and that the target application meets the first crash handling conditions, the method further includes: In response to the launch event of the target application, identify whether the target application is a disabled application; In response to the detection that the target application is a disabled application, the launch of the target application is prohibited.
[0137] By using this technical solution, the system can pre-check whether the target application is disabled before it starts, thereby intercepting and repairing ineffective faulty applications and avoiding invalid startup attempts and resource waste.
[0138] In some embodiments, identifying whether the target application is a disabled application includes: In response to the presence of the target application's program identifier in the abnormal application array, it is determined that the target application is a disabled application.
[0139] This technical solution allows for the accurate identification of disabled programs by examining an array of abnormal applications.
[0140] In some embodiments, when preventing the target application from restarting, the method further includes: Add the identifier of the target application to the array of abnormal applications.
[0141] This technical solution adds the application identifier that is prohibited from starting to an array, ensuring that subsequent startup requests are also rejected, thus avoiding a restart loop caused by program crashes.
[0142] In some embodiments, when preventing the target application from restarting, the method further includes: Determine the crash logs of the target application; In response to the program upgrade instruction for the crash log, the target application is updated.
[0143] This technical solution enables faulty applications to be accurately repaired without manual user intervention.
[0144] In some embodiments, after the update process for the target application is performed, the method further includes: After the target application is updated, the application identifier of the target application is removed from the abnormal application array; the abnormal application array indicates the application identifier of the abnormal application.
[0145] This technical solution enables the updated target application to start normally without manual user intervention.
[0146] In some embodiments, the program upgrade instruction is sent by the server, and after determining the crash log of the target application, the method further includes: The crash logs of the target application will be uploaded to the server.
[0147] In some embodiments, the first crash handling condition includes: the target application crashing a certain number of times within a first duration; and / or The second crash handling condition includes: the target application crashing a second time within a second duration.
[0148] This technical solution can accurately identify applications that are frequently crashing, thus avoiding accidental crashes that could lead to erroneous operations.
[0149] In some embodiments, the application crash handling apparatus is applied to a target electronic device, and before detecting whether the target application meets a first crash handling condition, it further includes: Obtain the current hardware load of the target electronic device to obtain the first load; The first duration and / or the first number of times are determined based on the first load and / or the application type of the target application.
[0150] In some embodiments, before detecting whether the target application meets the second crash handling condition, the method further includes: Obtain the current hardware load of the target electronic device to obtain the second load; The second duration and / or the second number of times are determined based on the second load and / or the application type of the target application.
[0151] By adopting this technical solution, adjusting the crash detection threshold based on hardware load allows for earlier intervention when resources are scarce and reduces false positives when resources are plentiful. Adjusting the crash detection threshold based on application type enables differentiated crash handling and detection for applications with different security requirements, thereby achieving a balance between system stability and user experience.
[0152] In some embodiments, performing a keep-alive repair on the target application includes: Delete the application data of the target application.
[0153] This technical solution can solve the problem of application crashes caused by data corruption and keep the target application alive as much as possible.
[0154] In some embodiments, deleting the application data of the target application includes: Obtain the crash logs of the target application; The target exception directory is determined based on the crash log; Delete the application data in the target abnormal directory.
[0155] This technical solution allows for precise location of the specific data directory causing the crash by parsing the crash logs. Data in that directory can be deleted while other application data is preserved, which facilitates accurate repair and maximizes the protection of user data while resolving the crash issue, thus minimizing data loss.
[0156] In some embodiments, the application crash handling apparatus is applied to a target electronic device, which includes at least one of in-vehicle devices, home appliances, wearable devices, drones, robots, mobile phones, and tablets.
[0157] Figure 4 This is a schematic diagram of an embodiment of the electronic device of this application.
[0158] Electronic device 100 includes memory 20, processor 30, and computer program 40 stored in memory 20 and executable on processor 30. When processor 30 executes computer program 40, it implements the steps described in the application crash handling method embodiment above, for example... Figure 1 Steps 101 to 103 are shown.
[0159] For example, computer program 40 can also be divided into one or more modules / units, which are stored in memory 20 and executed by processor 30. The one or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 40 in electronic device 100.
[0160] Those skilled in the art will understand that the schematic diagram is merely an example of the electronic device 100 and does not constitute a limitation on the electronic device 100. It may include more or fewer components than shown in the diagram, or combine certain components, or different components. For example, the electronic device 100 may also include input / output devices, network access devices, buses, etc.
[0161] Processor 30 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors, single-chip microcomputers, or any conventional processor.
[0162] The memory 20 can be used to store computer programs 40 and / or modules / units. The processor 30 implements various functions of the electronic device 100 by running or executing the computer programs and / or modules / units stored in the memory 20 and by calling data stored in the memory 20. The memory 20 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device 100 (such as audio data), etc. In addition, the memory 20 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.
[0163] If the modules / units integrated in the electronic device 100 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.
[0164] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the application crash handling method described above.
[0165] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the electronic device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and other division methods may be used in actual implementation.
[0166] Furthermore, the functional units in the various embodiments of this application can be integrated into the same processing unit, or each unit can exist physically separately, or two or more units can be integrated into the same unit. The integrated units described above can be implemented in hardware or in the form of hardware plus software functional modules.
[0167] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and not restrictive in all respects. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or electronic devices recited in the electronic device claims may also be implemented by the same unit or electronic device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.
[0168] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.
Claims
1. A method for handling application crashes, characterized in that, The application crash handling method includes: If the target application experiences a first crash event and meets the first crash handling conditions when the rescue mode is off, the target application will be saved and repaired. If a second crash event occurs in the target application after the target application has completed the keep-alive repair and the second crash handling conditions are met, the target application shall be prohibited from restarting.
2. The application crash handling method as described in claim 1, characterized in that, Before confirming that the target application has experienced a first crash event and that the target application meets the first crash handling conditions, the process further includes: In response to the launch event of the target application, identify whether the target application is a disabled application; In response to the detection that the target application is a disabled application, the launch of the target application is prohibited.
3. The application crash handling method as described in claim 1, characterized in that, The method for preventing the target application from restarting also includes: Add the identifier of the target application to the array of abnormal applications.
4. The application crash handling method as described in claim 1, characterized in that, The method of preventing the target application from restarting also includes: Determine the crash logs of the target application; In response to the program upgrade instruction for the crash log, the target application is updated.
5. The application crash handling method as described in claim 4, characterized in that, After updating the target application, the process further includes: After the target application is updated, the application identifier of the target application is removed from the abnormal application array; the abnormal application array indicates the application identifier of the abnormal application.
6. The application crash handling method as described in claim 4, characterized in that, The program upgrade instruction is sent by the server. After determining the crash log of the target application, the process further includes: The crash logs of the target application will be uploaded to the server.
7. The application crash handling method as described in claim 1, characterized in that, The first crash handling condition includes: the target application crashing a certain number of times within a first time period; and / or The second crash handling condition includes: the target application crashing a second time within a second duration.
8. The application crash handling method as described in claim 1, characterized in that, The keep-alive repair of the target application includes: Delete the application data of the target application.
9. The application crash handling method as described in claim 8, characterized in that, Deleting the application data of the application includes: Obtain the crash logs of the target application; The target exception directory is determined based on the crash log; Delete the application data in the target abnormal directory.
10. The application crash handling method according to any one of claims 1-9, characterized in that, The method is applied to a target electronic device, which includes at least one of in-vehicle devices, home appliances, wearable devices, drones, robots, mobile phones, and tablets.
11. An electronic device, the electronic device comprising a processor and a memory, characterized in that, The memory is used to store instructions, and the processor is used to invoke the instructions in the memory to cause the electronic device to execute the application crash handling method as described in any one of claims 1 to 10.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on an electronic device, cause the electronic device to perform the application crash handling method as described in any one of claims 1 to 10.