Vehicle-mounted application management method and related device
By creating status record processes and running examples on the vehicle terminal, the problem of inability to effectively manage multiple vehicle applications in the prior art is solved, and precise control and operation stability of vehicle applications are achieved.
Patent Information
- Application Number
- CN202510121384.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-24
- Publication Date
- 2025-05-23
AI Technical Summary
There is a lack of methods for effectively managing multiple vehicle applications in the prior art, which leads to the in-vehicle applications being unable to effectively manage the in-vehicle applications when the number of in-vehicle applications is installed at a large number of in-vehicle applications, which can easily lead to abnormal operation of in-vehicle applications.
Provides a method of on-board application management, by obtaining application startup requests, creating status record processes and running instances of target on-board applications, realizing life cycle management of on-board applications, and promptly responding to user startup and termination requests.
It realizes effective start and termination of on-board applications, can respond to users' control needs in a timely manner, improves the control accuracy of on-board applications, and avoids abnormal application operation.
Smart Images
Figure CN120029687A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of information processing technology, and in particular to a vehicle-mounted application management method and related devices. Background Art
[0002] With the continuous development of the automobile industry, the functions that vehicles can provide to users are becoming more and more diverse. For example, vehicles can be equipped with various vehicle terminals, such as a vehicle tablet installed on a vehicle control panel, etc. Various vehicle applications can be installed in the vehicle terminal for users to use.
[0003] However, the related technology lacks a management method that can effectively manage multiple vehicle-mounted applications, resulting in an inability to effectively manage the vehicle-mounted applications when a large number of vehicle-mounted applications are installed on the vehicle terminal, which can easily lead to abnormal operation of the vehicle-mounted applications. Summary of the invention
[0004] In order to solve the above technical problems, the present application provides a vehicle-mounted application management method, which can effectively manage the life cycle of vehicle-mounted applications and achieve timely response to the startup and termination of vehicle-mounted applications.
[0005] The embodiments of the present application disclose the following technical solutions:
[0006] In a first aspect, an embodiment of the present application discloses a method for managing vehicle-mounted applications, the method comprising:
[0007] Obtaining an application startup request, where the application startup request is used to request startup of a target vehicle-mounted application;
[0008] Creating a state recording process and a running instance corresponding to the target vehicle-mounted application, wherein the running instance is used to run the target vehicle-mounted application, the state recording process is used to record the application state corresponding to the target vehicle-mounted application, and the deletion operation of the state recording process is used to terminate the running instance;
[0009] Based on obtaining a termination request for the target in-vehicle application, changing the application state recorded in the state recording process to a termination state;
[0010] Based on the application state recorded in the state recording process being the termination state, the state recording process is deleted.
[0011] In a possible implementation, before creating the state recording process and the running instance corresponding to the target in-vehicle application, the method further includes:
[0012] Detecting whether the target vehicle-mounted application is in a running state;
[0013] The step of creating a status record process and a running instance corresponding to the target vehicle-mounted application includes:
[0014] Based on the fact that the target in-vehicle application is not in a running state, a state recording process and a running instance corresponding to the target in-vehicle application are created.
[0015] In a possible implementation, before creating the state recording process and the running instance corresponding to the target in-vehicle application, the method further includes:
[0016] Detecting whether an application package corresponding to the target vehicle-mounted application meets the running conditions;
[0017] The step of creating a status record process and a running instance corresponding to the target vehicle-mounted application includes:
[0018] Based on the application package satisfying the running condition, a state recording process and a running instance corresponding to the target in-vehicle application are created.
[0019] In a possible implementation, the method further includes:
[0020] Initializing the target vehicle-mounted application through the running instance;
[0021] During the initialization process of the target vehicle-mounted application, the application state recorded in the state recording process is determined as the initialization state.
[0022] In a possible implementation, the method further includes:
[0023] Based on the completion of initialization of the target vehicle-mounted application, the application state recorded in the state recording process is determined as a running state.
[0024] In a possible implementation, the method further includes:
[0025] Based on the target in-vehicle application satisfying the application restart condition, determining the application state recorded in the state recording process as a restart state;
[0026] Based on the application state recorded in the state recording process being the restart state, restart the target vehicle-mounted application.
[0027] In a possible implementation, the application restart condition includes:
[0028] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration;
[0029] Or, the time duration during which the application state recorded in the state recording process remains in the terminated state reaches a second time duration.
[0030] In a possible implementation, the application restart condition includes:
[0031] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration, the target in-vehicle application does not correspond to a first application type, and the initialization duration of an application corresponding to the first application type is not less than the first duration;
[0032] Or, the duration for which the application state recorded in the state recording process remains in the terminated state reaches a second duration and the target in-vehicle application does not correspond to a second application type, and the termination duration of the application corresponding to the second application type is not less than the second duration.
[0033] In a possible implementation, determining the application state recorded in the state recording process as a restart state based on the target in-vehicle application satisfying an application restart condition includes:
[0034] Based on the target vehicle application satisfying the application restart condition and the target vehicle application not having a process daemon, the application state recorded in the state recording process is determined as a restart state, and the process daemon is used to indicate that the target vehicle application cannot be restarted.
[0035] In a possible implementation, the method further includes:
[0036] The target in-vehicle application is uninstalled based on the number of restarts of the target in-vehicle application within a preset time period reaching a preset threshold.
[0037] In a second aspect, an embodiment of the present application discloses a vehicle-mounted application management device, the device comprising an acquisition unit, a creation unit, a change unit and a deletion unit:
[0038] The acquisition unit is used to acquire an application startup request, where the application startup request is used to request to start a target vehicle-mounted application;
[0039] The creation unit is used to create a state recording process and a running instance corresponding to the target vehicle-mounted application, the running instance is used to run the target vehicle-mounted application, the state recording process is used to record the application state corresponding to the target vehicle-mounted application, and the deletion operation of the state recording process is used to terminate the running instance;
[0040] The changing unit is configured to change the application state recorded in the state recording process to a terminated state based on obtaining a termination request for the target vehicle-mounted application;
[0041] The deleting unit is configured to delete the status recording process based on the application status recorded in the status recording process being the termination status.
[0042] In a possible implementation manner, the device further includes a first detection unit:
[0043] The first detection unit is used to detect whether the target vehicle-mounted application is in a running state;
[0044] The creation unit is specifically used for:
[0045] Based on the fact that the target in-vehicle application is not in a running state, a state recording process and a running instance corresponding to the target in-vehicle application are created.
[0046] In a possible implementation, the device further includes a second detection unit:
[0047] The second detection unit is used to detect whether the application package corresponding to the target vehicle-mounted application meets the running condition;
[0048] The creation unit is specifically used for:
[0049] Based on the application package satisfying the running condition, a state recording process and a running instance corresponding to the target in-vehicle application are created.
[0050] In a possible implementation manner, the device further includes an initialization unit and a first determination unit:
[0051] The initialization unit is used to initialize the target vehicle-mounted application through the running instance;
[0052] The first determining unit is configured to determine, during the initialization process of the target vehicle-mounted application, the application state recorded in the state recording process as the initialization state.
[0053] In a possible implementation manner, the apparatus further includes a second determining unit:
[0054] The second determining unit is configured to determine the application state recorded in the state recording process as the running state based on the completion of initialization of the target vehicle-mounted application.
[0055] In a possible implementation manner, the device further includes a third determining unit and a restarting unit:
[0056] The third determining unit is configured to determine the application state recorded in the state recording process as a restart state based on the target in-vehicle application satisfying the application restart condition;
[0057] The restart unit is configured to restart the target vehicle-mounted application based on the application state recorded in the state recording process being the restart state.
[0058] In a possible implementation, the application restart condition includes:
[0059] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration;
[0060] Or, the time duration during which the application state recorded in the state recording process remains in the terminated state reaches a second time duration.
[0061] In a possible implementation, the application restart condition includes:
[0062] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration, the target in-vehicle application does not correspond to a first application type, and the initialization duration of an application corresponding to the first application type is not less than the first duration;
[0063] Or, the duration for which the application state recorded in the state recording process remains in the terminated state reaches a second duration and the target in-vehicle application does not correspond to a second application type, and the termination duration of the application corresponding to the second application type is not less than the second duration.
[0064] In a possible implementation manner, the third determining unit is specifically configured to:
[0065] Based on the target vehicle application satisfying the application restart condition and the target vehicle application not having a process daemon, the application state recorded in the state recording process is determined as a restart state, and the process daemon is used to indicate that the target vehicle application cannot be restarted.
[0066] In a possible implementation, the device further includes an unloading unit:
[0067] The uninstallation unit is configured to uninstall the target vehicle-mounted application based on the number of restarts of the target vehicle-mounted application within a preset time period reaching a preset threshold.
[0068] In a third aspect, an embodiment of the present application discloses a computer device, wherein the computer device includes a processor and a memory:
[0069] The memory is used to store a computer program and transmit the computer program to the processor;
[0070] The processor is used to execute the in-vehicle application management method according to any one of the first aspects according to the instructions in the computer program;
[0071] In a fourth aspect, an embodiment of the present application discloses a computer-readable storage medium, wherein the computer-readable storage medium is used to store a computer program, and the computer program is used to execute the vehicle-mounted application management method described in any one of the first aspects;
[0072] In a fifth aspect, an embodiment of the present application discloses a computer program product including a computer program, which, when executed on a computer device, enables the computer device to execute the in-vehicle application management method described in any one of the first aspects.
[0073] It can be seen from the above technical solution that the present application can create a state recording process and a running instance corresponding to the target vehicle application after obtaining an application start request for requesting to start the target vehicle application, wherein the running instance is used to run the target vehicle application, and the state recording process is used to record the application state corresponding to the target vehicle application. If the state recording process is deleted, the running instance will be terminated, thereby terminating the running of the target vehicle application. If the user wants to terminate the running of the target vehicle application, a termination request for the target vehicle application can be initiated, at which time the application state recorded in the state recording process can be changed to a terminated state. Based on the fact that the application state recorded in the state recording process is a terminated state, the processing device can delete the state recording process, thereby terminating the running instance, and further terminating the running of the target vehicle application. It can be seen that through the vehicle application management method of the present application, the effective startup and termination of the vehicle application can be achieved, and the user's control requirements for the vehicle application can be responded to in a timely manner, thereby improving the control accuracy of the vehicle application. BRIEF DESCRIPTION OF THE DRAWINGS
[0074] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0075] Figure 1 A flowchart of a vehicle application management method provided in an embodiment of the present application;
[0076] Figure 2 A schematic diagram of a vehicle application management method in an actual application scenario provided by an embodiment of the present application;
[0077] Figure 3 A schematic diagram of a vehicle application management method in an actual application scenario provided by an embodiment of the present application;
[0078] Figure 4 A schematic diagram of a vehicle application management method in an actual application scenario provided by an embodiment of the present application;
[0079] Figure 5 A structural block diagram of a vehicle-mounted application management device provided in an embodiment of the present application;
[0080] Figure 6A structural diagram of a terminal provided in an embodiment of the present application;
[0081] Figure 7 A structural diagram of a server provided in an embodiment of the present application. DETAILED DESCRIPTION
[0082] The embodiments of the present application are described below in conjunction with the accompanying drawings.
[0083] It is understandable that the method can be applied to a computer device, which is a computer device capable of managing vehicle-mounted applications, such as a terminal device or a server. The method can be executed independently by a terminal device or a server, or it can be applied to a network scenario in which a terminal device and a server communicate, and is executed in cooperation with a terminal device and a server. Among them, the terminal device can be a mobile phone, a tablet computer, a laptop computer, a desktop computer and other devices. The terminal device can also include a variety of virtual reality devices, such as augmented reality (AR) devices, such as AR glasses, AR screens and other devices, and virtual reality (VR) technology (VR) devices, such as head-mounted VR glasses and other devices. The server can be understood as an application server, or a Web server. In actual deployment, the server can be an independent server, a cluster server, or a cloud server.
[0084] See also Figure 1 , Figure 1 This is a flowchart of a vehicle application management method provided in an embodiment of the present application. In this embodiment, the processing device can be any of the above-mentioned processing devices with vehicle application management functions. The method includes:
[0085] S101: Obtain an application startup request.
[0086] The application start request is used to request to start the target vehicle-mounted application. The application start request may be a request generated by a start operation of the user. For example, the user may start the target vehicle-mounted application through voice control, touch screen control, or other operations.
[0087] S102: Create a status record process and running instance corresponding to the target vehicle-mounted application.
[0088] The running instance is used to run the target vehicle-mounted application, for example, it can be an application thread (ApplicationThread), the state recording process is used to record the application state corresponding to the target vehicle-mounted application, and the deletion operation of the state recording process is used to terminate the running instance. That is, the target vehicle-mounted application can be terminated by deleting the state recording process.
[0089] S103: Based on obtaining a termination request for the target vehicle-mounted application, changing the application state recorded in the state recording process to a termination state.
[0090] If the user wants to terminate the target vehicle-mounted application, a termination request for the target vehicle-mounted application may be initiated, and the termination request is used to request the termination of the target vehicle-mounted application. At this time, the processing device may change the application state recorded in the state recording process to a terminated state.
[0091] S104: Based on the application status recorded in the status recording process being a termination status, the status recording process is deleted.
[0092] In the present application, the application status recorded in the status recording process can be used to instruct the processing device to perform corresponding management on the target vehicle-mounted application. For example, when the application status recorded in the status recording process is a terminated state, it means that the target vehicle-mounted application needs to be terminated at this time. The processing device can delete the running instance by deleting the status recording process, thereby terminating the target vehicle-mounted application.
[0093] It can be seen from the above technical solution that the present application can create a state recording process and a running instance corresponding to the target vehicle application after obtaining an application start request for requesting to start the target vehicle application, wherein the running instance is used to run the target vehicle application, and the state recording process is used to record the application state corresponding to the target vehicle application. If the state recording process is deleted, the running instance will be terminated, thereby terminating the running of the target vehicle application. If the user wants to terminate the running of the target vehicle application, a termination request for the target vehicle application can be initiated, at which time the application state recorded in the state recording process can be changed to a terminated state. Based on the fact that the application state recorded in the state recording process is a terminated state, the processing device can delete the state recording process, thereby terminating the running instance, and further terminating the running of the target vehicle application. It can be seen that through the vehicle application management method of the present application, the effective startup and termination of the vehicle application can be achieved, and the user's control requirements for the vehicle application can be responded to in a timely manner, thereby improving the control accuracy of the vehicle application.
[0094] In a possible implementation, before creating the status record process and running instance corresponding to the target vehicle application, in order to avoid the target vehicle application being repeatedly started, thereby causing abnormal application operation, the processing device can detect whether the target vehicle application is in a running state.
[0095] When executing step S102, the processing device may execute step S1021 (not shown in the figure). Step S1021 is a possible implementation of step S102, including:
[0096] S1021: Based on the fact that the target in-vehicle application is not in the running state, create a state recording process and a running instance corresponding to the target in-vehicle application.
[0097] The processing device starts the target in-vehicle application only when the target in-vehicle application is not in a running state, that is, is not running.
[0098] In addition, before creating the state record process and running instance corresponding to the target vehicle-mounted application, the processing device may also detect whether the application package required to run the target vehicle-mounted application supports the running of the target vehicle-mounted application. The method further includes:
[0099] The processing device may detect whether the application package corresponding to the target in-vehicle application satisfies an operating condition, where the operating condition is used to determine whether the application package supports the operation of the target in-vehicle application.
[0100] When executing step S102, the processing device may execute step S1022 (not shown in the figure), where step S1022 is a possible implementation of step S102, including:
[0101] S1022: Based on the application package satisfying the running conditions, create a status record process and a running instance corresponding to the target vehicle-mounted application.
[0102] If the application package meets the running conditions, it means that the application package supports the running of the target vehicle application, so the processing device can start the target vehicle application. The running conditions may include the existence of the package information of the application program, the application package name is not empty, the application package specification, etc.
[0103] Next, the operation process of the target vehicle application will be introduced in detail.
[0104] In one possible implementation, the processing device may first initialize the target vehicle-mounted application through the running instance, and then during the initialization process of the target vehicle-mounted application, determine the application state recorded in the state recording process as the initialization state, thereby being able to identify that the target vehicle-mounted application is in the initialization process, thereby avoiding the occurrence of erroneous calls to the target vehicle-mounted application.
[0105] In a possible implementation, the target vehicle application has completed initialization, indicating that the target vehicle application has completed initialization and entered the running state. At this time, the processing device can determine the application state recorded in the state recording process as the running state to indicate that the target vehicle application is running.
[0106] It is understandable that during the operation of the target vehicle application, various abnormal situations may occur, causing the target vehicle application to fail to operate normally, and a restart is required to resolve the abnormal situation of the application. In a possible implementation, in order to further improve the effectiveness of vehicle application management, the processing device may restart the target vehicle application when necessary.
[0107] The processing device may determine whether the target vehicle application satisfies the application restart condition, and the application restart condition is used to determine whether the target vehicle application has an abnormal situation that requires restarting the application. Based on the fact that the target vehicle application satisfies the application restart condition, it indicates that the target vehicle application has an abnormal situation that requires restarting the application. At this time, the processing device may determine the application state recorded in the state recording process as the restart state. Based on the fact that the application state recorded in the state recording process is the restart state, the processing device may restart the target vehicle application to resolve the abnormal situation of the target vehicle application.
[0108] Specifically, in a possible implementation, the application restart condition includes:
[0109] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration;
[0110] Or, the duration of the application state recorded in the state recording process remaining in the terminated state reaches a second duration. Under normal circumstances, the initialization process and the termination process of the target vehicle-mounted application are relatively short, so if the recorded application state remains in the initialization state or the termination state for too long, it means that the target vehicle-mounted application is likely to have an abnormal situation, so the processing device can restart the target vehicle-mounted application.
[0111] In a possible implementation, the application restart condition includes:
[0112] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration, the target in-vehicle application does not correspond to a first application type, and the initialization duration of an application corresponding to the first application type is not less than the first duration;
[0113] Or, the duration for which the application state recorded in the state recording process remains in the terminated state reaches a second duration and the target in-vehicle application does not correspond to a second application type, and the termination duration of the application corresponding to the second application type is not less than the second duration.
[0114] It is understandable that some applications can remain in the initialization or termination state for a long time due to their characteristic functions. For example, when the vehicle-mounted application is a debugAPP, it can remain in the initialization state for a long time. Therefore, in a possible implementation, the processing device can exclude such program types when setting the application restart conditions. Only when the target vehicle-mounted application is not an application of the first application type or the second application type, and the time in the initialization state or the time in the termination state is long, the processing device will determine that the target vehicle-mounted application has an abnormal situation, thereby avoiding restarting the normally running application.
[0115] In a possible implementation, some vehicle-mounted applications may have a process daemon, which is used to indicate that the vehicle-mounted application cannot be restarted. Based on this, when the application state recorded in the state recording process is determined as a restart state based on the target vehicle-mounted application meeting the application restart condition, the processing device can determine whether the target vehicle-mounted application has a process daemon.
[0116] Based on the fact that the target vehicle-mounted application meets the application restart condition and there is no process daemon for the target vehicle-mounted application, the application status recorded in the status recording process is determined to be a restart status. The process daemon is used to identify that the target vehicle-mounted application cannot be restarted, thereby avoiding erroneous application restart and causing abnormal application operation.
[0117] It is understandable that if the target vehicle-mounted application is restarted multiple times in a short period of time, it means that the target vehicle-mounted application has multiple anomalies in a short period of time. Based on this, in a possible implementation, based on the number of restarts of the target vehicle-mounted application within a preset time period reaching a preset threshold, the processing device can uninstall the target vehicle-mounted application, thereby uninstalling applications that often have abnormal situations to prevent users from using abnormal applications again.
[0118] In order to facilitate understanding of the technical solution provided by the present application, the in-vehicle application management method provided by the present application will be introduced below in combination with an actual application scenario.
[0119] In this implementation, the vehicle-mounted application management method of the present application can be applied to Figure 2 In the system architecture shown, APP represents the in-vehicle application, and the functions of the processing device mainly include two parts. One is the application lifecycle management, that is, the interaction between the application and the system during the startup process, which can be used to start, run and terminate the in-vehicle application; the other is the application health management, including the system monitoring the application status, timely discovering the application abnormalities, and the system processing logic when an abnormality occurs during the operation of the application, such as restarting when the restart conditions are met.
[0120] See also Figure 3 , Figure 3 The first aspect provided by this application, namely the specific process of application lifecycle management, is shown. As the core service of the Auto Framework (AF), the application management service is responsible for managing the lifecycle management of all AF vehicle-mounted applications. By interacting with the application launcher, it controls the start, stop, and forced stop of the application. The application status is checked regularly in the application management service. Once an application exception is found, the application exception management mechanism will be triggered. The application management service has the ability to create and guard application processes. When an application process exits abnormally, the application management service is responsible for restarting the application.
[0121] The application management service uses an important data structure to manage the application life cycle, process scheduling, health management and other tasks. This data structure is the state record process ApplicationRecord.
[0122] Each ApplicationRecord corresponds to an application process. ApplicationRecord stores the application process ID, application status information, application package information (including application package name, application version number, version name, etc.), and the app instance running in the process.
[0123] When the AF system starts, the system service SystemServer is the entry point of the system service and is responsible for loading and starting various system services, including the application management service. SystemServer first creates an application management service instance and registers it as a system service, then starts the main thread Looper of the application management service to handle various operations of the application management service.
[0124] When a user starts an application, the Application Manager Service (AMS) is responsible for handling the application startup process. The following is a brief overview of the AMS process in application startup:
[0125] 1. When the user starts the application, the system sends a request to start the application to AMS.
[0126] 2. After receiving the start request, AMS will first check whether the application package information exists, whether the application package name is empty, and whether the application package is standardized. Then it will check whether the application is running. If the application is already running, no processing will be done, and a log will be sent to notify the user that the application has been started.
[0127] 3. If the application is not running yet, AMS will create a new process (i.e., the state recording process) based on the application package information and the application running path, and add the process to the system's process list. Then, app-launcher will create an ApplicationThread (i.e., running instance) instance in the new process, and ApplicationThread will construct an ApplicationTransit instance to be responsible for switching the application state.
[0128] 4. ApplicationThread is responsible for handling the life cycle management tasks of the application. After creating the ApplicationThread instance, app-launcher will call the run method of ApplicationThread to start the main thread of the process.
[0129] 5. After the main thread is started, ApplicationThread will initialize the application context and load the application resources. Then, ApplicationThread will send a message (MSG_APP_READY) to the looper message queue, and then the ApplicationTransit instance will call the state switching interface to start the application state switching, and then communicate with AMS through the Binder mechanism.
[0130] 6. When the application state is CREATE (initialization state), ApplicationThread will send a create message (MSG_APP_CREATE), and ApplicationThread will call the OnCreate method of the application to notify the application instance to perform initialization operations and execute the initialization logic of the application. In this process, Application can load layouts, register timers, and other operations.
[0131] 7. After the application instance of the application is initialized, ApplicationThread sends a run message (MSG_APP_START) and calls the onStart method of the application to create and start the Application instance. During this process, the Application can perform operations such as registering broadcasts, obtaining services and calling service interfaces. At this time, the application state recorded in the state recording process will change to the onStart state (running state).
[0132] 8. When the user wants to stop the application, ApplicationThread sends a stop message (MSG_APP_STOP) to call the onStop interface of the application. This process will stop the application instance. The application will not respond to user operations during this period until the application is restarted. After the call, the application state recorded in the state recording process will change to onStop (terminated state), and the processing device will directly delete the corresponding state recording process, thereby terminating the operation of the in-vehicle application.
[0133] See also Figure 4 , Figure 4 This is a schematic diagram corresponding to the second part of application health management, which is used to control the restart and uninstallation of vehicle-mounted applications. The processing device can determine whether the application status recorded in the status recording process is RESTART (restart status). If so, the application is restarted, if not, the judgment continues. Among them, when the application is in an unstable state for a long time (that is, it is in the initialization state or the termination state for a long time), and the application is not a debugAPP, it means that the application is abnormal and needs to be restarted. Before restarting, the processing device will determine whether there is a process guardian for the application. If so, the application will be erased and the next application will be detected. If not, the restart process will be performed; at the same time, if the application has multiple unresponsive (ANR) problems in a short period of time, that is, multiple restarts have occurred and the abnormal problem has not been resolved, the processing device can record the application as an application to be uninstalled, thereby uninstalling the application in subsequent processing.
[0134] Based on the vehicle application management method provided in the above embodiment, the present application also provides a vehicle application management device, see Figure 5 , Figure 5 This is a structural block diagram of a vehicle-mounted application management device provided in an embodiment of the present application. The device 500 includes an acquisition unit 501, a creation unit 502, a change unit 503, and a deletion unit 504:
[0135] The acquisition unit 501 is used to acquire an application startup request, where the application startup request is used to request to start a target vehicle-mounted application;
[0136] The creation unit 502 is used to create a state recording process and a running instance corresponding to the target vehicle-mounted application, the running instance is used to run the target vehicle-mounted application, the state recording process is used to record the application state corresponding to the target vehicle-mounted application, and the deletion operation of the state recording process is used to terminate the running instance;
[0137] The changing unit 503 is configured to change the application state recorded in the state recording process to a terminated state based on obtaining a termination request for the target vehicle-mounted application;
[0138] The deleting unit 504 is configured to delete the status recording process based on the application status recorded in the status recording process being the termination status.
[0139] In a possible implementation manner, the device further includes a first detection unit:
[0140] The first detection unit is used to detect whether the target vehicle-mounted application is in a running state;
[0141] The creation unit 502 is specifically used for:
[0142] Based on the fact that the target in-vehicle application is not in a running state, a state recording process and a running instance corresponding to the target in-vehicle application are created.
[0143] In a possible implementation, the device further includes a second detection unit:
[0144] The second detection unit is used to detect whether the application package corresponding to the target vehicle-mounted application meets the running condition;
[0145] The creation unit 502 is specifically used for:
[0146] Based on the application package satisfying the running condition, a state recording process and a running instance corresponding to the target in-vehicle application are created.
[0147] In a possible implementation manner, the device further includes an initialization unit and a first determination unit:
[0148] The initialization unit is used to initialize the target vehicle-mounted application through the running instance;
[0149] The first determining unit is configured to determine, during the initialization process of the target vehicle-mounted application, the application state recorded in the state recording process as the initialization state.
[0150] In a possible implementation manner, the apparatus further includes a second determining unit:
[0151] The second determining unit is configured to determine the application state recorded in the state recording process as the running state based on the completion of initialization of the target vehicle-mounted application.
[0152] In a possible implementation manner, the device further includes a third determining unit and a restarting unit:
[0153] The third determining unit is configured to determine the application state recorded in the state recording process as a restart state based on the target in-vehicle application satisfying the application restart condition;
[0154] The restart unit is configured to restart the target vehicle-mounted application based on the application state recorded in the state recording process being the restart state.
[0155] In a possible implementation, the application restart condition includes:
[0156] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration;
[0157] Or, the time duration during which the application state recorded in the state recording process remains in the terminated state reaches a second time duration.
[0158] In a possible implementation, the application restart condition includes:
[0159] The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration, the target in-vehicle application does not correspond to a first application type, and the initialization duration of an application corresponding to the first application type is not less than the first duration;
[0160] Or, the duration for which the application state recorded in the state recording process remains in the terminated state reaches a second duration and the target in-vehicle application does not correspond to a second application type, and the termination duration of the application corresponding to the second application type is not less than the second duration.
[0161] In a possible implementation manner, the third determining unit is specifically configured to:
[0162] Based on the target vehicle application satisfying the application restart condition and the target vehicle application not having a process daemon, the application state recorded in the state recording process is determined as a restart state, and the process daemon is used to indicate that the target vehicle application cannot be restarted.
[0163] In a possible implementation, the device further includes an unloading unit:
[0164] The uninstallation unit is configured to uninstall the target vehicle-mounted application based on the number of restarts of the target vehicle-mounted application within a preset time period reaching a preset threshold.
[0165] The present application also provides a computer device, see Figure 6 As shown, the computer device may be a terminal device, and a mobile phone is taken as an example:
[0166] Figure 6 FIG. 1 is a block diagram showing a partial structure of a mobile phone related to a terminal device provided in an embodiment of the present application. Figure 6The mobile phone includes: a radio frequency (RF) circuit 710, a memory 720, an input unit 730, a display unit 740, a sensor 750, an audio circuit 760, a wireless fidelity (WiFi) module 770, a processor 780, and a power supply 790. Those skilled in the art will understand that Figure 6 The mobile phone structure shown in the figure does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.
[0167] Combine the following Figure 6 A detailed introduction to the various components of the mobile phone:
[0168] The RF circuit 710 can be used for receiving and sending signals during the process of sending and receiving information or making calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 780 for processing; in addition, the designed uplink data is sent to the base station. Usually, the RF circuit 710 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (Low Noise Amplifier, referred to as LNA), a duplexer, etc. In addition, the RF circuit 710 can also communicate with the network and other devices through wireless communication. The above-mentioned wireless communication can use any communication standard or protocol, including but not limited to the Global System of Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.
[0169] The memory 720 can be used to store software programs and modules. The processor 780 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 720. The memory 720 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 720 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.
[0170] The input unit 730 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone. Specifically, the input unit 730 may include a touch panel 731 and other input devices 732. The touch panel 731, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 731 or near the touch panel 731 using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 731 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 780, and can receive and execute commands sent by the processor 780. In addition, the touch panel 731 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 731, the input unit 730 may further include other input devices 732. Specifically, the other input devices 732 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.
[0171] The display unit 740 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 740 may include a display panel 741. Optionally, the display panel 741 may be configured in the form of a liquid crystal display (Liquid Crystal Display, LCD), an organic light-emitting diode (Organic Light-Emitting Diode, OLED), etc. Further, the touch panel 731 may cover the display panel 741. When the touch panel 731 detects a touch operation on or near it, it is transmitted to the processor 780 to determine the type of touch event. Subsequently, the processor 780 provides a corresponding visual output on the display panel 741 according to the type of touch event. Although in Figure 6 In the embodiment, the touch panel 731 and the display panel 741 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 731 and the display panel 741 can be integrated to realize the input and output functions of the mobile phone.
[0172] The mobile phone may also include at least one sensor 750, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 741 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 741 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.
[0173] The audio circuit 760, the speaker 761, and the microphone 762 can provide an audio interface between the user and the mobile phone. The audio circuit 760 can transmit the received audio data to the speaker 761 after converting the received audio data into an electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 762 converts the collected sound signal into an electrical signal, which is received by the audio circuit 760 and converted into audio data, and then the audio data is output to the processor 780 for processing, and then sent to another mobile phone through the RF circuit 710, or the audio data is output to the memory 720 for further processing.
[0174] WiFi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the WiFi module 770. It provides users with wireless broadband Internet access. Figure 6A WiFi module 770 is shown, but it is understandable that it is not an essential component of the mobile phone and can be omitted as needed without changing the essence of the invention.
[0175] The processor 780 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. By running or executing software programs and / or modules stored in the memory 720, and calling data stored in the memory 720, it executes various functions of the mobile phone and processes data, thereby performing overall detection of the mobile phone. Optionally, the processor 780 may include one or more processing units; preferably, the processor 780 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 780.
[0176] The mobile phone also includes a power supply 790 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 780 through a power management system, so that the power management system can manage charging, discharging, power consumption and other functions.
[0177] Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.
[0178] In this embodiment, the processor 780 included in the terminal device also has the following functions:
[0179] Obtaining an application startup request, where the application startup request is used to request startup of a target vehicle-mounted application;
[0180] Creating a state recording process and a running instance corresponding to the target vehicle-mounted application, wherein the running instance is used to run the target vehicle-mounted application, the state recording process is used to record the application state corresponding to the target vehicle-mounted application, and the deletion operation of the state recording process is used to terminate the running instance;
[0181] Based on obtaining a termination request for the target in-vehicle application, changing the application state recorded in the state recording process to a termination state;
[0182] Based on the application state recorded in the state recording process being the termination state, the state recording process is deleted.
[0183] The present application also provides a server. Figure 7 As shown, Figure 7The structural diagram of the server 800 provided in the embodiment of the present application, the server 800 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 822 (for example, one or more processors) and a memory 832, and one or more storage media 830 (for example, one or more mass storage devices) storing application programs 842 or data 844. Among them, the memory 832 and the storage medium 830 can be temporary storage or permanent storage. The program stored in the storage medium 830 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the central processing unit 822 can be configured to communicate with the storage medium 830 and execute a series of instruction operations in the storage medium 830 on the server 800.
[0184] The server 800 may also include one or more power supplies 826, one or more wired or wireless network interfaces 850, one or more input and output interfaces 858, and / or one or more operating systems 841, such as Windows Server 2000. TM , Mac OS X TM , Unix TM ,Linux TM , FreeBSD TM etc.
[0185] The steps performed by the server in the above embodiment can be based on Figure 7 The server structure shown.
[0186] An embodiment of the present application also provides a computer-readable storage medium for storing a computer program, which is used to execute any one of the implementation methods of the in-vehicle application management methods described in the aforementioned embodiments.
[0187] An embodiment of the present application also provides a computer program product including a computer program, which, when executed on a computer device, enables the computer device to execute the in-vehicle application management method described in any one of the above embodiments.
[0188] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.
[0189] A person of ordinary skill in the art can understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the above-mentioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the above-mentioned storage medium can be at least one of the following media: read-only memory (English: read-only memory, abbreviated: ROM), RAM, magnetic disk or optical disk, etc. Various media that can store program codes.
[0190] It should be noted that each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can refer to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments. The device and system embodiments described above are merely schematic, in which the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.
[0191] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A vehicle-mounted application management method, characterized in that: The method comprises: Obtaining an application startup request, where the application startup request is used to request startup of a target vehicle-mounted application; Creating a state recording process and a running instance corresponding to the target vehicle-mounted application, wherein the running instance is used to run the target vehicle-mounted application, the state recording process is used to record the application state corresponding to the target vehicle-mounted application, and the deletion operation of the state recording process is used to terminate the running instance; Based on obtaining a termination request for the target in-vehicle application, changing the application state recorded in the state recording process to a termination state; Based on the application state recorded in the state recording process being the termination state, the state recording process is deleted.
2. The method according to claim 1, characterized in that Before creating the state recording process and running instance corresponding to the target vehicle-mounted application, the method further includes: Detecting whether the target vehicle-mounted application is in a running state; The step of creating a status record process and a running instance corresponding to the target vehicle-mounted application includes: Based on the fact that the target in-vehicle application is not in a running state, a state recording process and a running instance corresponding to the target in-vehicle application are created.
3. The method according to claim 1, characterized in that Before creating the state recording process and running instance corresponding to the target vehicle-mounted application, the method further includes: Detecting whether an application package corresponding to the target vehicle-mounted application meets the running conditions; The step of creating a status record process and a running instance corresponding to the target vehicle-mounted application includes: Based on the application package satisfying the running condition, a state recording process and a running instance corresponding to the target in-vehicle application are created.
4. The method according to claim 1, characterized in that: The method further comprises: Initializing the target vehicle-mounted application through the running instance; During the initialization process of the target vehicle-mounted application, the application state recorded in the state recording process is determined as the initialization state.
5. The method according to claim 4, characterized in that The method further comprises: Based on the completion of initialization of the target vehicle-mounted application, the application state recorded in the state recording process is determined as a running state.
6. The method according to claim 1, characterized in that The method further comprises: Based on the target in-vehicle application satisfying the application restart condition, determining the application state recorded in the state recording process as a restart state; Based on the application state recorded in the state recording process being the restart state, restart the target vehicle-mounted application.
7. The method according to claim 6, characterized in that: The application restart conditions include: The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration; Or, the time duration during which the application state recorded in the state recording process remains in the terminated state reaches a second time duration.
8. The method according to claim 6, characterized in that The application restart conditions include: The duration for which the application state recorded in the state recording process remains in the initialization state reaches a first duration, the target in-vehicle application does not correspond to a first application type, and the initialization duration of an application corresponding to the first application type is not less than the first duration; Or, the duration for which the application state recorded in the state recording process remains in the terminated state reaches a second duration and the target in-vehicle application does not correspond to a second application type, and the termination duration of the application corresponding to the second application type is not less than the second duration.
9. The method according to claim 6, characterized in that The step of determining the application state recorded in the state recording process as a restart state based on the target vehicle-mounted application satisfying the application restart condition includes: Based on the target vehicle application satisfying the application restart condition and the target vehicle application not having a process daemon, the application state recorded in the state recording process is determined as a restart state, and the process daemon is used to indicate that the target vehicle application cannot be restarted.
10. A vehicle-mounted application management device, characterized in that: The device comprises an acquisition unit, a creation unit, a change unit and a deletion unit: The acquisition unit is used to acquire an application startup request, where the application startup request is used to request to start a target vehicle-mounted application; The creation unit is used to create a state recording process and a running instance corresponding to the target vehicle-mounted application, the running instance is used to run the target vehicle-mounted application, the state recording process is used to record the application state corresponding to the target vehicle-mounted application, and the deletion operation of the state recording process is used to terminate the running instance; The changing unit is configured to change the application state recorded in the state recording process to a terminated state based on obtaining a termination request for the target vehicle-mounted application; The deleting unit is configured to delete the status recording process based on the application status recorded in the status recording process being the termination status.