Process management method and device, storage medium and program product

Abstract

The invention provides a process management method and device, a storage medium and a program product, and the method comprises the steps that in the starting process of an operating system of a vehicle-mounted device, a first main service module is operated in a first process, the first process is a resident process of the operating system, and the first main service module provides resident service for the operating system; a plurality of first plug-ins are loaded in the first process through the first main service module, and each first plug-in is used for achieving the monitoring function of the corresponding resident service; and under the condition that the first preset system event is monitored through one or more plug-ins in the plurality of first plug-ins, starting the corresponding first application, so that the first application executes the resident service corresponding to the first preset event.

Description

Technical Field

[0001] The present application relates to, but is not limited to, the field of computer technology, and in particular to a process management method, device, storage medium, and program product. Background Art

[0002] The resident services of the vehicle are services that run or listen in real time during the operation of the vehicle. Since these resident services are always running in the vehicle, the memory required for the operation of the resident services cannot be released. This memory is called resident memory. Since the total memory size of the vehicle is limited, too high resident memory can easily cause various performance experience problems. Summary of the invention

[0003] One purpose of the present application is to provide a process management method, which has the advantage that, during the startup process of the operating system of the vehicle-mounted device, the vehicle-mounted device can run the first main service module in the first process, the first process is the resident process of the operating system, and the first main service module is the resident service of the operating system; then multiple first plug-ins are loaded in the first process through the first main service module, each first plug-in is used to implement the listening function of the corresponding resident service, and when one or more plug-ins in the multiple first plug-ins listen to the first preset system event, the corresponding first application is started, so that the first application executes the resident service corresponding to the first preset system event. Therefore, the embodiment of the present application extracts the listening function of the resident service into a common resident process, reduces unnecessary resident service processes, and these resident services can share memory space and system resources, thereby reducing the overhead and delay of inter-process communication, which helps to improve the overall performance and response speed of the operating system. Moreover, the embodiment of the present application makes each resident service in the same process when running through the plug-in method, and each is independently compiled during development, which not only meets the performance requirements, but also facilitates development, and can improve the user experience. Furthermore, the vehicle-mounted device can more easily control the behavior and state of the plug-in through the first main service module to ensure the stability and consistency of the operating system. Furthermore, through the plug-in mechanism, the operating system can dynamically add or delete functions without modifying the code of the first main service module, which helps to improve the flexibility and scalability of the operating system.

[0004] Another object of the present application is to provide a process management method, the advantage of which is that the vehicle-mounted device can determine multiple first plug-ins by querying the configuration files of one or more services in the operating system; create a first instance for each first plug-in, and run the first instance in the first process through the first main service module. Therefore, the embodiment of the present application can manage the loading and configuration of the plug-in through the configuration file, which can more easily implement the version control of the plug-in and improve the reliability and stability of the system.

[0005] Another object of the present application is to provide a process management method, the advantage of which is that the vehicle-mounted device traverses the configuration file of each service, and when the type information in the configuration file indicates that the first service among one or more services is configured with a plug-in and the process configuration information in the configuration file indicates that the first service is configured to run in the first process, the plug-in corresponding to the first service is determined to be the first plug-in. Therefore, the embodiment of the present application can determine the first plug-in corresponding to the resident service according to the type information and process configuration information in the configuration file of each service, and the operation is simple and fast.

[0006] Another object of the present application is to provide a process management method, the advantage of which is that the vehicle-mounted device can determine whether the first plug-in is legal by querying whether the package name and / or class name of the first plug-in is in the white list, and create a first instance for the first plug-in when it is determined that the package name and / or class name of the first plug-in is in the white list. In this way, by only maintaining a clear white list, the vehicle-mounted device can have full control over the plug-ins running in the system, which helps to ensure that only verified plug-ins are allowed to load, thereby maintaining the stability and security of the system. Moreover, when verifying the plug-in, it is only necessary to query whether the package name and / or class name of the plug-in is in the white list to quickly determine the legitimacy of the plug-in, which can simplify the verification process.

[0007] Another purpose of the present application is to provide a process management method, the advantage of which is that in the embodiment of the present application, the vehicle-mounted device can determine whether the first plug-in is legal through the signature mechanism, and create a first instance for the first plug-in when the signature data verification is confirmed. In this way, the vehicle-mounted device can have full control over the plug-ins running in the system, and only the plug-ins that pass the verification can be allowed to load, thereby maintaining the stability and security of the system. The signature mechanism uses the pairing of public keys and private keys to determine the identity authentication of both parties in communication and improve the security of data transmission.

[0008] Another object of the present application is to provide a process management method, which has the advantage that, during the startup process of the operating system, a second main service module is run in the second process, the second process and the first process are resident processes corresponding to different user groups in the operating system, and the second main service module and the first main service module are resident services corresponding to different user groups in the operating system; through the second main service module, multiple second plug-ins are loaded in the second process, and each second plug-in is used to implement the listening function of the corresponding non-resident business; in the case of listening to the second preset system event through one or more plug-ins in the multiple second plug-ins, the corresponding second application is started so that the second application executes the non-resident business corresponding to the second preset system event. The embodiment of the present application can extract the listening function of the non-resident business into a common resident process, reduce unnecessary non-resident business processes, and avoid performance experience problems caused by insufficient system resource supply. Moreover, the embodiment of the present application can classify and process plug-ins through dual processes, the first process is used to load the plug-in corresponding to the resident business, and the second process is used to load the plug-in corresponding to the non-resident business, which is conducive to providing boot speed, avoiding some plug-ins from obtaining unnecessary system-level permissions, and providing system security.

[0009] Another object of the present application is to provide a vehicle-mounted device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and the processor implements the steps in the above method when executing the computer program. The embodiment of the present application uses a plug-in method to enable each resident service to be in the same process when running, and to be independently compiled during development, which not only meets performance requirements, but also facilitates development and can improve user experience.

[0010] Another object of the present application is to provide a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the steps in the above method are implemented. The embodiment of the present application uses a plug-in method to enable each resident service to be in the same process when running, and to be compiled independently during development, which not only meets performance requirements, but also facilitates development and improves user experience.

[0011] Another object of the present application is to provide a computer program product, including a computer program or an instruction, which implements the steps in the above method when executed by a processor. The embodiment of the present application uses a plug-in method to enable each resident service to be in the same process when running, and to be compiled independently during development, which not only meets performance requirements, but also facilitates development and improves user experience.

[0012] To achieve the above purpose, the technical solution of the embodiment of the present application is implemented as follows:

[0013] In a first aspect, an embodiment of the present application provides a process management method, which is executed by a vehicle-mounted device, and the method includes: during the startup process of the operating system of the vehicle-mounted device, running a first main service module in a first process, the first process being a resident process of the operating system, and the first main service module being a resident service of the operating system; through the first main service module, loading multiple first plug-ins in the first process, wherein each first plug-in is used to implement a listening function for a corresponding resident service; when a first preset system event is listened to through one or more of the multiple first plug-ins, starting a corresponding first application so that the first application executes the resident service corresponding to the first preset system event.

[0014] In a second aspect, an embodiment of the present application provides an operating system for an in-vehicle device, including: a kernel, a service layer, and an application layer, wherein:

[0015] The kernel is configured to start the service layer during the startup of the operating system of the vehicle-mounted device;

[0016] The service layer is configured to start the application layer;

[0017] The application layer is configured as follows: running a first main service in a first process, the first process being a resident process, and the first main service being a resident service of an operating system; loading a plurality of first plug-ins in the first process, each first plug-in being used to implement a listening function for a corresponding resident service; and when a first preset system event is listened to through one or more of the plurality of first plug-ins, starting a first application corresponding to one or more plug-ins, so that the first application executes a resident service corresponding to the first preset system event.

[0018] In a third aspect, an embodiment of the present application provides a vehicle-mounted device, including a memory and a processor, wherein the memory stores a computer program that can be executed on the processor, and the processor implements the steps in the above method when executing the program.

[0019] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps in the above method when executed by a processor.

[0020] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in the above-mentioned method.

[0021] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.

[0023] Figure 1 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0024] Figure 2 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0025] Figure 3 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0026] Figure 4 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0027] Figure 5 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0028] Figure 6 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0029] Figure 7 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0030] Figure 8 This is an optional flowchart of the process management method provided in the embodiment of the present application;

[0031] Fig. 9 It is a hardware entity schematic diagram of a vehicle-mounted device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further elaborated in detail below in conjunction with the drawings and embodiments. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0033] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. The terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific order for the objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0034] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing this application and are not intended to limit this application.

[0035] As an indispensable part of automobile intelligence, the resident services of the vehicle computer run continuously during the driving process of the vehicle, and undertake key tasks such as navigation positioning, voice interaction, and vehicle status monitoring. The efficient and stable operation of these resident services is crucial to improving the driving safety, convenience, and comfort of the vehicle. Since the resident services are always running in the vehicle computer, the memory occupied by these resident services during operation cannot be released, resulting in performance problems caused by unreasonable occupation of system resources during the operation of the vehicle computer.

[0036] At present, it is common to simply integrate multiple resident services into an Android application package (Android Package Kit, APK) and share a code repository. Although this simplifies the deployment process, it brings a series of problems and challenges that cannot be ignored. First, since the codes of all resident services are mixed in the same application code, developers of different service modules often need to communicate and coordinate frequently to ensure that their codes do not conflict with each other during integration. This tightly coupled architecture makes code modification and maintenance extremely complicated, especially when faced with the needs of rapid iteration and frequent updates. A small change may affect the entire system, resulting in a longer debugging cycle and greatly reduced development efficiency. In addition, excessive code coupling directly increases the risk of system errors. When a resident service has a problem, it is easy to affect other related resident services, resulting in unpredictable errors or crashes in the entire system. This chain reaction not only increases the difficulty of troubleshooting, but also greatly affects the user experience.

[0037] In order to solve the above problems, the embodiment of the present application provides a process management method, which can extract the listening function of the resident service into a common resident process, reducing unnecessary resident service processes. Moreover, through the plug-in method, each resident service is in the same process at runtime and compiled independently during development, which not only meets the performance requirements, but also facilitates development and improves the user experience.

[0038] Figure 1 is an optional flow chart of the process management method provided in the embodiment of the present application. Exemplarily, the method can be executed by the operating system of the vehicle-mounted device. Figure 1 As shown, the method includes the following steps S101 to S103. In one embodiment, the method may be executed by the application layer in the above operating system.

[0039] In step S101, during the startup of the operating system of the vehicle-mounted device, a first main service module is run in a first process, the first process is a resident process of the operating system, and the first main service module is a resident service of the operating system.

[0040] In some embodiments, the operating system of the vehicle-mounted device, which may also be referred to as the vehicle-mounted operating system, is an operating system installed and running in the vehicle-mounted device. The vehicle-mounted operating system is system software that manages and controls vehicle-mounted hardware and software resources.

[0041] In some embodiments, the startup process of the operating system of the vehicle-mounted device refers to the process of the vehicle-mounted operating system changing from a closed state or a dormant state to a running state. This process is a prerequisite for the normal operation of the vehicle-mounted device and is also the basis for realizing functions such as vehicle intelligence and networking.

[0042] In some embodiments, the operating system of the vehicle-mounted device can be an Android system, a Linux system, a Windows system, an Apple system, a Harmony system, or other operating systems, which is not limited to the embodiments of the present application.

[0043] In some embodiments, starting the operating system of the vehicle-mounted device may include the following steps:

[0044] Step 1: Hardware self-test (Power-On Self-Test, POST). When the vehicle-mounted device is powered on, it can first perform a hardware self-test, that is, the vehicle-mounted device checks whether all key hardware components (such as the central processor, memory, storage device, network interface, etc.) are working properly.

[0045] Step 2: Load the bootloader. After the self-test passes, the bootloader is loaded into the memory and executed. The bootloader is a small program before the operating system starts, which is responsible for loading the operating system kernel into the memory and setting the necessary startup parameters.

[0046] Step 3: Load the operating system kernel. The boot program loads the operating system kernel from a storage device (such as a hard disk, a secure digital memory card (SD) card, or an embedded flash memory) into the memory and transfers control to the operating system kernel.

[0047] Step 4: Initialize the operating system. After the operating system kernel is started, a series of initialization operations will be performed, including setting system parameters, initializing driver programs, and creating necessary system processes and threads.

[0048] In some embodiments, after the operating system is initialized, the operating system loads and starts the first main service module in the first process. The first process is a resident process, and the first main service module is a resident service of the operating system. The first main service module runs in the operating system as a resident service of the operating system and is responsible for managing and coordinating various services. Moreover, the resident service will not be actively killed by the operating system, and can be automatically restarted when an abnormal crash occurs.

[0049] In some embodiments, the operating system can manage and discover the first main service module through a service registry or a similar mechanism (e.g., a configuration file). In some embodiments, the service registry can record the configuration information of all services in the operating system, for example, the configuration information can include the name, path, startup type, etc. of the service. Based on this, the operating system can read the configuration information in the service registry to query the executable file or library file of the first main service module and load it into the memory. During the file loading process, the operating system can allocate necessary resources to the first main service module, such as memory space, so that the first main service module can execute the initialization code after being loaded into the memory. In one embodiment, the initialization code is responsible for setting the internal state of the first main service module, creating necessary threads or processes, registering necessary callback functions, etc. After the initialization is completed, the first main service module can report the status to the operating system to indicate that the first main service module is ready and can start processing requests.

[0050] In some embodiments, in the configuration file of the first main service module, the attribute of the first main service module is declared as persistent = "true" to indicate that the first main service module continues to run during the operation of the vehicle-mounted device, that is, the first main service module is a resident service. Then, in step S101, after querying persistent = "true" in the configuration file of the main service module, the vehicle-mounted device can run the first main service module. In some embodiments, since persistent = "true" indicates that the first main service module is a resident service, it is determined that the first main service module can automatically restart even after an abnormal crash.

[0051] In step S102, a plurality of first plug-ins are loaded in a first process through a first main service module, wherein each first plug-in is used to implement a listening function of a corresponding resident service.

[0052] It is understandable that the resident service is a service that keeps running during the operation of the vehicle-mounted device and can automatically restart after an abnormal crash. After the first main service module is running, the first plug-in can be loaded in the first process through the first main service module.

[0053] In some embodiments, the first main service module is the core part of the application or operating system, responsible for managing and coordinating various services. A plug-in is a module that can be dynamically loaded and unloaded, and is used to expand the functionality of the first main service module. Resident services can be implemented in the form of independent plug-ins, and different resident services correspond to different plug-ins. Through the first main service module, multiple first plug-ins are loaded in the first process. In this way, the embodiment of the present application extracts the listening function of the resident service into a common resident process, reduces unnecessary resident service processes, and avoids performance experience problems caused by insufficient system resource supply. Moreover, through the plug-in mechanism, the operating system can dynamically add or delete functions without modifying the code of the first main service module, which helps to improve the flexibility and scalability of the operating system.

[0054] In some embodiments, the resident services may include at least one of the following: desktop, status bar, instrument, Bluetooth management, power management, thermal management, telematics box (Tbox), fatigue detection, reversing signal detection, etc. These resident services run continuously during the operation of the vehicle-mounted equipment and are indispensable for the daily operation, maintenance and management of the vehicle.

[0055] In some embodiments, the vehicle-mounted device reads the registry or configuration file of each service through the first main service module to obtain the configuration information of the service, which generally includes the name, path, version number, running process, etc. of the service. Exemplarily, the vehicle-mounted device can query the configuration information in the configuration file to determine the service that is configured with a plug-in and whose running process is the first process, and determine the plug-in corresponding to the service as the first plug-in. After determining the first plug-in, the vehicle-mounted device can load the first plug-in into the memory through the first main service module. Exemplarily, the process of the main service module loading the first plug-in into the memory may include the steps of parsing the plug-in file, creating a plug-in instance, and initializing the plug-in.

[0056] In step S103, when a first preset system event is intercepted by one or more plug-ins among the plurality of first plug-ins, a corresponding first application is started so that the first application executes a resident service corresponding to the first preset system event.

[0057] In some embodiments, after the vehicle-mounted device loads multiple first plug-ins through the first main service module, each first plug-in can listen to system events through the system interface. System events refer to events that occur during the operation of the operating system and need to be listened to and processed by specific components (such as plug-ins). System events can be triggered by user operations, such as clicking a button, submitting a form, etc.; they can also be triggered by changes in the internal state of the system, such as data updates, service startup or shutdown, etc.

[0058] It can be understood that when a certain event (first preset system event) occurs, only the first plug-in that can identify and listen to the event will execute the preset business logic associated with the event. That is, a first plug-in listens to a system event, and when a first plug-in listens to the corresponding system event, the vehicle-mounted device can call the corresponding application (such as the first application) through the first plug-in to execute the resident business corresponding to the system event.

[0059] Below Figure 2 For example Figure 1 The illustrated embodiment is further described. Figure 2 FIG. 1 is an optional flow chart of the process management method provided in the embodiment of the present application. Figure 2As shown, exemplarily, the vehicle-mounted device runs the first main service module in the first process. When the first service is a Bluetooth service, the first plug-in corresponding to the Bluetooth service is a Bluetooth module plug-in. The vehicle-mounted device can load the Bluetooth module plug-in in the first process through the first main service module, and the first main service module can listen to the connection status of the Bluetooth service through the Bluetooth module plug-in. When the Bluetooth connection status indicates that Bluetooth is connected, the Bluetooth module plug-in can call the Bluetooth-related application 1 to perform the corresponding task. For example, when application 1 is a contact application, the Bluetooth module plug-in can process tasks such as contact synchronization through the contact application. When the first service is a power management service, the first plug-in corresponding to the power management service is a power management module plug-in. The vehicle-mounted device can load the power management module plug-in in the first process through the first main service module, and the first main service module can listen to the power status through the power management module plug-in. When the power status changes, the power management module plug-in can call the power-related application 2 to perform the corresponding task, for example, when the power status indicates off, the power management module plug-in can turn on the power by calling the power application. When the first service is a Tbox service, the first plug-in corresponding to the Tbox service is a Tbox module plug-in. The vehicle-mounted device can load the Tbox module plug-in in the first process through the first main service module. The first main service module can monitor the connection status, signal strength and other states between the vehicle and the user terminal through the Tbox module plug-in. When these states change, the Tbox module plug-in can call the Tbox-related application 3 to perform the corresponding task. For example, when the connection status between the vehicle and the user terminal indicates that the connection between the vehicle and the user terminal is interrupted, the Tbox module plug-in can call the relevant applications of the vehicle and the user terminal to re-establish the communication connection between the two. Among them, the first service is a service whose type information indicates that the service is configured with a plug-in, and the process configuration information indicates that the service is configured to run in the first process. The explanation of the first service will be explained in detail later, and will not be repeated here.

[0060] In an embodiment of the present application, during the startup process of the operating system of the vehicle-mounted device, the vehicle-mounted device can run the first main service module in the first process, and then load multiple first plug-ins in the first process through the first main service module, each first plug-in is used to implement the listening function of the corresponding resident service, and when one or more plug-ins in the multiple first plug-ins listen to the first preset system event, the corresponding first application is started, so that the first application executes the resident service corresponding to the first preset system event. Therefore, the embodiment of the present application extracts the listening function of the resident service into a common resident process, reduces unnecessary resident service processes, and these resident services can share memory space and system resources, thereby reducing the overhead and delay of inter-process communication, which helps to improve the overall performance and response speed of the operating system. Moreover, the embodiment of the present application makes each resident service in the same process when running through the plug-in method, and each is compiled independently during development, which not only meets the performance requirements, but also facilitates development and improves the user experience. Further, the vehicle-mounted device can more easily control the behavior and state of the plug-in through the first main service module to ensure the stability and consistency of the operating system. In addition, through the plug-in mechanism, the operating system can dynamically add or delete functions without modifying the code of the first main service module, which helps to improve the flexibility and scalability of the operating system.

[0061] Figure 3 This is an optional flowchart of process management provided by the embodiment of the present application. Figure 1 , Figure 1 Step S102 in can be updated to step S301 to step S303, which will be combined with Figure 2 The steps shown are explained.

[0062] In step S201, configuration files of one or more services in the operating system are queried to determine a plurality of first plug-ins.

[0063] It is understandable that the operating system of the vehicle-mounted equipment can be responsible for managing and scheduling the computing resources, storage resources and network resources inside the vehicle, and providing the necessary resource guarantees for multiple services on the vehicle. Moreover, the operating system plays the role of a basic platform, which can provide an operating environment and support for multiple services. In some embodiments, the services on the vehicle cover navigation and positioning, driving assistance and safety, entertainment, remote control, information query and other aspects. The integration of these services not only improves the convenience and safety of driving, but also enriches the entertainment experience of the passengers.

[0064] It is understandable that the configuration file of a service is a file that stores the parameters and settings of the service. In some embodiments, the configuration file may exist in a text format to facilitate reading and modification. Exemplarily, the format of the configuration file may be json, xml, etc. Since the configuration file of the service defines the configuration information such as the startup conditions, resource allocation, and loading priority of the service, the vehicle-mounted device can determine the first plug-in corresponding to the resident service in the operating system by querying the configuration file of the service.

[0065] In some embodiments, the vehicle-mounted device may request the operating system to read the configuration file of each service through the first main service module to obtain the configuration information of each service. For example, the configuration file of each service may be stored in a memory inside the vehicle-mounted system, and for example, the memory may be a storage device such as a built-in flash memory chip or a hard disk.

[0066] In some embodiments, the vehicle-mounted device may determine the first plug-in from the plurality of services according to the configuration information in the configuration file of each service. In this case, step S301 may be updated to steps S3011 to S3012.

[0067] In step S3011, configuration files of one or more services in the operating system are traversed, where the configuration files include service type information and process configuration information.

[0068] Exemplarily, the type information of a service may indicate whether the service is configured with a plug-in. Exemplarily, the process configuration information of a service may include the running process configured for the service, and the running process may be a first process or other processes, and the first process is the process where the first main service module is located, that is, the process where the resident service is located. If the process configuration information of a service indicates that the service is configured to run in the first process, it indicates that the service is a resident service. If the process configuration information of the service indicates that the service is configured to run in other processes, it indicates that the service is not a resident service.

[0069] In some embodiments, the configuration file of each service may also include configuration information such as the package name (PackageName), class name (Class Name), loading priority (priority), startup conditions, resource allocation, etc. of the service.

[0070] In some embodiments, the configuration file of a service may include an "android name" attribute, which is used to indicate the name of the service and may also indicate the type information of the service. If the type information of a service is declared as android:name="com.xxx.car.action.PLUGIN", it indicates that the service is configured with a plug-in. Then, after the first main service module queries android:name="com.xxx.car.action.PLUGIN" in the configuration file of a service, the vehicle-mounted device can determine that the service is configured with a plug-in.

[0071] In some embodiments, the configuration file of a service may include a "uidGroup" attribute, which is used to indicate the process configuration information of the service. If the process configuration information of a service is declared as meta-data android:name="uidGroup" android:value="u0", it indicates that the service is configured to run in the u0 process. Then, after the first main service module queries the meta-data android:name="uidGroup" android:value="u0" in the configuration file of a service, the vehicle-mounted device can determine that the service is configured to run in the u0 process. When the first process (the process where the first main service module is located) is u0, the vehicle-mounted device can determine that the service is a resident service.

[0072] It can be understood that the in-vehicle system can traverse the configuration files of one or more services and determine the first plug-in based on the type information and process configuration information of the services included in the configuration files.

[0073] In step S3012, when the type information indicates that a first service among the one or more services is configured with a plug-in and the process configuration information indicates that the first service is configured to run in a first process, it is determined that the plug-in corresponding to the first service is the first plug-in.

[0074] In one example, if the vehicle-mounted device queries a configuration file of a certain service, determines that the service is configured with a plug-in based on the type information, and determines that the service is configured to run in the first process based on the process configuration information, then the vehicle-mounted device can determine that the plug-in corresponding to the service is the first plug-in. The vehicle-mounted device can traverse the configuration files of all services in the operating system, and determine multiple first plug-ins in the operating system based on this.

[0075] In some embodiments, the vehicle-mounted device can query the package name and / or class name of the plug-in through the query intent service method of the package manager (PackageManager) (such as queryIntentService(intent)), and distinguish different plug-ins through the package name and / or class name to subsequently create an instance object of the plug-in.

[0076] In step S302, a first instance is created for each first plug-in.

[0077] It can be understood that after determining the first plug-in, the in-vehicle device can instantiate the first plug-in, that is, create a first instance of the first plug-in.

[0078] In some embodiments, the vehicle-mounted device may use the class loader provided by the operating system to create an instance of the plug-in. Exemplarily, the class loader may include a path class loader (PathClassLoader), a boot loader (BootstrapClassLoader), an extension loader (ExtensionsClassLoader), a system loader, and other class loaders. In some embodiments, the vehicle-mounted device may also use a user-defined class loader to create an instance of the plug-in to meet user needs. Exemplarily, the user-defined class loader may include a class loader implemented by inheriting the java.lang.ClassLoader class, etc.

[0079] In some embodiments, the configuration file of the service may further include a loading priority of each service. Based on this, the vehicle-mounted device may sequentially create a first instance of the first plug-in according to the loading priority of each service. Exemplarily, the smaller the value of the loading priority of the plug-in, the higher the priority of the plug-in.

[0080] In step S303, a first instance is run in a first process through a first main service module.

[0081] It is understandable that since the plug-in instance includes predefined methods or functions (such as a listening function), these functions need to be called at runtime to perform specific tasks. Therefore, after creating the first instance of the first plug-in, the vehicle-mounted device can run the first instance in the first process through the first main service module, so as to ensure that these functions are correctly executed when needed.

[0082] In an embodiment of the present application, the vehicle-mounted device can query the configuration file of each business in the operating system, and when the type information in the configuration file indicates that the first business is configured with a plug-in and the process configuration information in the configuration file indicates that the business is configured to run in the first process, determine that the plug-in corresponding to the first business is the first plug-in, then create the first instance of the first plug-in, and run the instance in the first process. Therefore, the embodiment of the present application can determine the first plug-in corresponding to the resident business by querying the type information and process configuration information in the configuration file of the business, and the operation is simple and fast. Moreover, by managing the loading and configuration of the plug-in through the configuration file, the version control of the plug-in can be more easily implemented, thereby improving the reliability and stability of the system. The embodiment of the present application only needs to deploy the new plug-in or the updated configuration file to the corresponding position to achieve the upgrade and expansion of the system, making the system deployment and upgrade simpler and more flexible.

[0083] Figure 4 This is an optional flowchart of the process management method provided in the embodiment of the present application. Figure 3 , Figure 3 Step S302 in the above example can be updated to step S401 to step S403. Figure 4 The steps shown are explained.

[0084] In step S401, a configuration file related to each first plug-in is queried through the first main service module to determine the package name and / or class name of each first plug-in.

[0085] In some embodiments, after the vehicle-mounted device determines that the plug-in corresponding to the first business is the first plug-in, the embodiment of the present application may refer to the configuration file of the first business as a configuration file related to the first plug-in. The configuration file related to the first plug-in includes various configuration information of the first plug-in, so the vehicle-mounted device can determine the package name and / or class name of the first plug-in by querying the configuration file related to the first plug-in. Among them, the package name is used to uniquely identify a group of related classes, interfaces, enumerations and annotations. For plug-ins, the package name usually includes the reverse domain name of the plug-in developer (also called the reverse domain name) to reduce the possibility of naming conflicts. The class name is used to identify a specific class.

[0086] In some embodiments, since the package name and class name are unique, the package name and class name of a plug-in are unique globally, so the vehicle-mounted device can determine whether the plug-in is legal based on the package name or class name of the plug-in. Exemplarily, the vehicle-mounted device can obtain the package name of the first plug-in, the class name of the first plug-in, and the package name and class name of the first plug-in.

[0087] In step S402, the first main service module determines whether the package name and / or class name of each first plug-in is in the whitelist.

[0088] In some embodiments, the vehicle-mounted device may test and review multiple plug-ins in advance to determine which plug-ins are legal or trusted, and after passing the test verification, add the package names and class names of the legal plug-ins to a whitelist, and store the whitelist in the operating system.

[0089] It is understandable that when the vehicle-mounted device obtains the package name of the first plug-in, it can query through the first main service module whether the package name of the first plug-in is in the whitelist. When the class name of the first plug-in is obtained, it can query through the first main service module whether the class name of the first plug-in is in the whitelist. When the package name and class name of the first plug-in are obtained, it can query through the first main service module whether both the package name and class name of the first plug-in are in the whitelist.

[0090] In step S401 , when the package name and / or class name of each first plug-in is in the whitelist, a first instance is created for each first plug-in.

[0091] In some embodiments, the first plug-in in the operating system may be illegally tampered with, or data errors may occur during network transmission. Therefore, the vehicle-mounted device can first verify the legitimacy of the first plug-in. After determining that the first plug-in is legitimate, the vehicle-mounted device creates a first instance of the first plug-in. In this way, the normal use of the first plug-in can be guaranteed, and external malicious applications can be prevented from disguising themselves as the first plug-in to attack the operating system, or from increasing the time and process costs due to repeated loading caused by abnormalities of the first plug-in.

[0092] It can be understood that when the vehicle-mounted device obtains the package name of the first plug-in, if it is found that the package name of the first plug-in is in the whitelist, the first plug-in is determined to be legal, otherwise the first plug-in is determined to be illegal. When the class name of the first plug-in is obtained, if the class name of the first plug-in is in the whitelist, it indicates that the first plug-in is legal, otherwise the first plug-in is determined to be illegal. When the package name and class name of the first plug-in are obtained, the vehicle-mounted device can determine that the first plug-in is legal only if the package name and class name of the first plug-in are both in the whitelist, otherwise the first plug-in is determined to be illegal.

[0093] In some embodiments, new legitimate plug-ins may appear over time, while old plug-ins may become unsafe or outdated. Therefore, the vehicle-mounted device may also periodically update the whitelist to ensure that the whitelist always includes the latest legitimate plug-in information.

[0094] In some embodiments, the vehicle-mounted device can also determine whether the first plug-in is legal by querying whether the information used to uniquely identify the first plug-in is in the whitelist. Of course, other methods can also be used to determine whether each first plug-in is legal, and this embodiment of the application does not limit this.

[0095] In an embodiment of the present application, the vehicle-mounted device can determine whether the first plug-in is legal by querying whether the package name and / or class name of the first plug-in is in the whitelist, and create a first instance for the first plug-in when it is determined that the package name and / or class name of the first plug-in is in the whitelist. In this way, by only maintaining a clear whitelist, the vehicle-mounted device can have complete control over the plug-ins running in the system, which helps to ensure that only verified plug-ins are allowed to load, thereby maintaining the stability and security of the system. Moreover, when verifying a plug-in, it is only necessary to query whether the package name and / or class name of the plug-in is in the whitelist to quickly determine the legitimacy of the plug-in, which can simplify the verification process.

[0096] Figure 5 This is an optional flowchart of the process management method provided in the embodiment of the present application. Figure 3 , Figure 3 Step S302 in can be updated to step S501 to step S503, which will be combined with Figure 5 The steps shown are explained.

[0097] In step S501, the signature data of each first plug-in is obtained, the signature data includes the original package name and / or class name of the first plug-in, and the package name and / or class name of each first plug-in encrypted by the server using a private key, and the signature data is pre-generated by the first main service module.

[0098] In this case, the embodiment of the present application verifies the first plug-in through a signature mechanism.

[0099] In some embodiments, the embodiments of the present application can pre-build an environment for signing (encrypting) the plug-in. For example, a server (such as a cloud server) can be provided, and the private key of the relevant key verification mechanism is stored on the server. In this case, the plug-in developer can first send the package name and / or class name of the first plug-in to the server through the vehicle-mounted device, for example, send "com.xxx.car.example / com.xxx.car.example.SamplePlugin" to the server, and the server can use the private key to sign the first plug-in and obtain the package name and / or class name of the first plug-in after signing.

[0100] Exemplarily, the key authentication mechanism may be a Secure Shell (SSH) asymmetric key authentication mechanism. The asymmetric key authentication mechanism ensures the privacy of the private key and the publicity of the public key, so that only the server holding the private key can generate a valid signature, thereby verifying the identity of the client.

[0101] In some embodiments, the algorithm used by the server to sign the first plug-in can be: signed_result = RSA (sha 256 (to_sign_data)). Among them, signed_result represents the signature result, and RSA (sha 256 (to_sign_data)) is a digital signature process. The process usually involves two steps: hashing calculation and digital signing. Exemplarily, the hash calculation process is to use an algorithm such as sha 256 to hash to_sign_data (i.e., original data) to obtain a hash value of a fixed length, which can be a 256-bit hash value. to_sign_data can be the original package name and / or class name of the first plug-in. The digital signature is to sign the hash value obtained in the previous step using an algorithm such as RSA. That is, the hash value is encrypted by a private key to generate a signature result. The signature result is the encrypted package name and / or class name of the first plug-in. Therefore, the process of digital signature is: calculate the hash value of the original data; sign the hash value to obtain a digital signature. Exemplarily, after obtaining the signature result, the server may also convert the signature result into a base 64-encoded string, and then send the string together with the original data to the vehicle-mounted device.

[0102] It should be noted that the hash calculation using the sha 256 algorithm and the digital signature using the RSA algorithm are only examples. Hash calculation and digital signature can also be performed using other algorithms, and the embodiments of the present application are not limited to this.

[0103] In some embodiments, after obtaining the signature result, that is, the encrypted package name and / or class name of the first plug-in, the server can send the encrypted package name and / or class name of the first plug-in and the original package name and / or class name of the first plug-in (original data) to the vehicle-mounted device, so that the vehicle-mounted device can obtain the signature data of the first plug-in, so as to verify the plug-in through the signature data.

[0104] In some embodiments, the vehicle-mounted device can obtain the signature data of the first plug-in by calling the "onVerify()" interface of the first plug-in through the first main service module.

[0105] In step S502, the signature data is verified using a public key through the first main service module.

[0106] It can be understood that after receiving the signature data, the vehicle-mounted device can verify the integrity of the signature data through the public key.

[0107] In some embodiments, step S502 may be updated to include steps S5021 to S5023.

[0108] In step S5021, a hash calculation is performed on the original package name and / or class name in the signature data through the first main service module to obtain a first hash value.

[0109] In some embodiments, after obtaining the signature data, the vehicle-mounted device can use the first main service module to perform hash calculation on the original data of the first plug-in using an algorithm to obtain a first hash value. Exemplarily, the vehicle-mounted device can use the first main service module to perform hash calculation on the original package name and / or class name of the first plug-in using the same sha 256 algorithm as in the above-mentioned signature process to obtain the first hash value.

[0110] In step S5022, the first main service module uses the public key to decrypt the encrypted package name and / or class name in the signature data to obtain a second hash value.

[0111] It is understandable that after obtaining the signature data, the vehicle-mounted device can use the public key to decrypt the signature result through the first main service module to obtain the second hash value. Exemplarily, the vehicle-mounted device can use the RSA algorithm to decrypt the encrypted package name and / or class name through the first main service module, and the obtained second hash value is the hash value of the above-mentioned to_sign_data.

[0112] In step S5023, the signature data is verified based on the first hash value and the second hash value, wherein when the first hash value and the second hash value are the same, the signature data verification succeeds.

[0113] It can be understood that after obtaining the first hash value and the second hash value, the vehicle-mounted device can compare the calculated hash value (first hash value) and the hash value (second hash value) decrypted from the signature through the first main service module to see if they are the same. If they are the same, it means that the signature data is complete and comes from the signer (server), so it can be determined that the first plug-in comes from the real issuer and has not been illegally tampered with. If they are not the same, it means that the signature data is incomplete or may be illegally tampered with.

[0114] In step S503, when the signature data verification passes, a first instance is created for each first plug-in.

[0115] It is understandable that if the signature data verification passes, the vehicle-mounted device can determine that the first plug-in is legitimate and then create an instance of the first plug-in. On the contrary, if the signature data verification fails, the vehicle-mounted device can ignore the first plug-in and does not perform the operation of creating an instance of the first plug-in.

[0116] In the embodiment of the present application, the vehicle-mounted device can determine whether the first plug-in is legitimate through the signature mechanism, and create a first instance for the first plug-in when the signature data verification is confirmed. In this way, the vehicle-mounted device can have full control over the plug-ins running in the system, and only plug-ins that pass the verification can be allowed to load, thereby maintaining the stability and security of the system. The signature mechanism uses the paired use of public keys and private keys to determine the identity authentication of both parties in communication and improve the security of data transmission.

[0117] Figure 6 This is an optional flowchart of the process management method provided in the embodiment of the present application. Figure 1 , Figure 1 The method may further include steps S601 to S603, combining Figure 7 The steps shown are explained.

[0118] In step S601, during the startup of the operating system, the second main service module is run in the second process, the second process and the first process are resident processes corresponding to different user groups in the operating system, and the second main service module and the first main service module are resident services corresponding to different user groups in the operating system.

[0119] In some embodiments, the operating system of the vehicle-mounted device in the embodiments of the present application may be a dual-user system or a multi-user system. In the case where the operating system is a dual-user system, the main service module may also include a first main service module and a second main service module. The first main service module is a resident service running in a first process (resident process) corresponding to the first user in the dual-user system, and the second main service module is a resident service running in a second process (resident process) corresponding to the second user in the dual-user system. Therefore, after the operating system is initialized, in the case where the first main service module is running in the first process, the second main service module may also be running in the second process.

[0120] In step S602, a plurality of second plug-ins are loaded in a second process through a second main service module, wherein each second plug-in is used to implement a listening function of a corresponding non-resident service.

[0121] It is understandable that the vehicle-mounted equipment can load multiple second plug-ins through the second main service module, and extract the listening functions of multiple non-resident services into a common resident process. This can reduce unnecessary non-resident business processes and avoid performance experience problems caused by insufficient system resource supply.

[0122] For example, non-resident services may include at least one of the following: Head Up Display (HUD), Over The Air Technology (OTA), scenario mode, vehicle settings, etc. These non-resident services are intermittently operated during the operation of vehicle equipment, are not necessary for the daily operation of the vehicle, and are provided to the vehicle under specific circumstances or special needs.

[0123] In some embodiments, the vehicle-mounted device reads the registry or configuration file of each business through the second main service module to obtain the configuration information of the business, which generally includes the name, path, version number, running process, etc. of the business. Exemplarily, the vehicle-mounted device can query the configuration information in the configuration file to determine the business that is configured with a plug-in and the running process is the second process, and determine the plug-in corresponding to the business as the second plug-in. After determining the second plug-in, the vehicle-mounted device can load the second plug-in into the memory through the second main service module. Exemplarily, the process of the main service module loading the second plug-in into the memory may include the steps of parsing the plug-in file, creating a plug-in instance, and initializing the plug-in.

[0124] In step S603, when a second preset system event is intercepted by one or more plug-ins among the plurality of second plug-ins, a corresponding second application is started so that the second application executes a non-resident service corresponding to the second preset system event.

[0125] In some embodiments, after the vehicle-mounted device loads multiple second plug-ins through the second main service module, each second plug-in can listen to system events through the system interface. System events refer to events that occur during the operation of the operating system and need to be listened to and processed by specific components (such as plug-ins). System events can be triggered by user operations, such as clicking a button, submitting a form, etc.; they can also be triggered by changes in the internal state of the system, such as data updates, service startup or shutdown, etc.

[0126] It can be understood that when a certain event (second preset system event) occurs, only the second plug-in that can identify and listen to the event will execute the preset business logic associated with the event. That is, one second plug-in listens to one system event, and when a second plug-in listens to the corresponding system event, the vehicle-mounted device can call the corresponding application (for example, the second application) through the second plug-in to execute the non-resident business corresponding to the system event.

[0127] Below Figure 7 Taking the example, the method for loading the second plug-in and instantiating the second plug-in through the second main service module of the above-mentioned vehicle-mounted device is further explained. Figure 7FIG. 1 is an optional flow chart of the process management method provided in the embodiment of the present application. Figure 7 As shown, exemplarily, the vehicle-mounted device runs the second main service module in the second process. When the second service is a HUD service, the second plug-in corresponding to the HUD service is a HUD module plug-in. The vehicle-mounted device can load the HUD module plug-in in the second process through the second main service module, and the second main service module can listen to the status of the display system of the vehicle through the HUD module plug-in. When the status of the display system changes, the HUD module plug-in can call the application 4 related to the HUD to perform the corresponding task. When the second service is an OTA service, the second plug-in corresponding to the OTA service is an OTA module plug-in. The vehicle-mounted device can load the OTA module plug-in in the second process through the second main service module, and the second main service module can listen to the upgrade status of the operating system through the OTA module plug-in. When the upgrade status of the operating system changes, the OTA module plug-in can call the application 5 related to OTA to perform the corresponding task. When the second service is a scene mode service, the second plug-in corresponding to the scene mode service is a scene mode module plug-in. The vehicle-mounted device can load the scene mode module plug-in in the second process through the second main service module, and the second main service module can listen to the status of the scene mode of the vehicle through the scene mode module plug-in. When the state of the scene mode changes, the scene mode module plug-in can call the application 6 related to the scene mode to perform the corresponding task. When the second service is the vehicle setting service, the second plug-in corresponding to the vehicle setting service is the vehicle setting module plug-in. The vehicle-mounted device can load the vehicle setting module plug-in in the second process through the second main service module. The second main service module can use the vehicle setting module plug-in to set the driving mode and entertainment mode of the vehicle. When a certain setting state changes, the vehicle setting module plug-in can call the application 7 related thereto to perform the corresponding task. When the second service is other non-resident services, the corresponding second plug-in is other module plug-in. The vehicle-mounted device can load other module plug-ins in the second process through the second main service module. The second main service module can use the module plug-ins of other non-resident services to monitor a certain state of the vehicle. When the state changes, the other module plug-ins can call the application 8 related thereto to perform the corresponding task. Among them, the second service is a service whose type information indicates that the service is configured with a plug-in and the process configuration information indicates that the service is configured to run in the second process.

[0128] The embodiment of the present application can process plug-ins through dual-process classification. The first process is only used to load plug-ins corresponding to resident services, and the second process is used to load plug-ins corresponding to non-resident services. This is beneficial for increasing boot speed, preventing certain plug-ins from obtaining unnecessary system-level permissions, and providing system security.

[0129] In some embodiments, the implementation process of loading multiple second plug-ins in the second process through the second main service module can be: querying the configuration files of one or more services in the operating system to determine multiple second plug-ins; creating a second instance for each second plug-in; and running the second instance in the second process through the second main service module.

[0130] In some embodiments, the vehicle-mounted device queries the configuration files of one or more services in the operating system, and the implementation process of determining multiple second plug-ins can be: traversing the configuration files of one or more services in the operating system, the configuration files include the type information and process configuration information of the services; when the type information indicates that the second service in the one or more services is configured with a plug-in, and the process configuration information indicates that the second service is configured to run in the second process, determining that the plug-in corresponding to the second service is the second plug-in. Among them, the implementation process of the vehicle-mounted device loading multiple second plug-ins in the second process through the second main service module can refer to the relevant content of the vehicle-mounted device loading multiple first plug-ins in the first process through the first main service module, which will not be repeated here.

[0131] The above describes a method in which the vehicle-mounted device loads and instantiates a first plug-in corresponding to a resident service through a first main service module, and loads and instantiates a second plug-in corresponding to a non-resident service through a second main service module. Figure 8 Take as an example to further illustrate the above method.

[0132] Figure 8 FIG. 1 is an optional flow chart of the process management method provided in the embodiment of the present application. Figure 8 As shown, the method may include steps S801 to S807.

[0133] Step S801: During the startup process of the operating system of the vehicle-mounted device, a first main service module is run.

[0134] Step S802: Determine multiple first plug-ins in the operating system through the first main service module, each first plug-in is used to implement a listening function of a corresponding resident service.

[0135] Step S803: Determine whether the package name and / or class name of the first plug-in is in the whitelist.

[0136] It can be understood that the implementation process of step S903 can refer to the above Figure 4 The relevant content will not be repeated here.

[0137] If the package name and / or class name of the first plug-in is not in the whitelist, the vehicle-mounted device performs the operation of step S804; if the package name and / or class name of the first plug-in is in the whitelist, the vehicle-mounted device performs the operation of step S805.

[0138] Step S804: Ignore the first plug-in.

[0139] Step S805: Verify whether the first plug-in is legitimate through a signature mechanism.

[0140] It can be understood that the implementation process of step S805 can refer to the above Figure 5 The relevant content will not be repeated here.

[0141] If the signature data verification of the first plug-in fails, the vehicle-mounted device performs the operation of step S806; if the signature data verification of the first plug-in passes, the vehicle-mounted device performs the operation of step S807.

[0142] Step S806: Ignore the first plug-in.

[0143] Step S807: Create a first instance of the first plug-in, and run the first instance in the first process.

[0144] Step S808: The first system event is monitored by multiple first plug-ins, and when one of the multiple first plug-ins monitors the occurrence of the first preset system event, the corresponding first application is started, so that the first application executes the resident business corresponding to the first preset system event.

[0145] In addition, in some embodiments, while the vehicle-mounted device determines multiple first plug-ins in the operating system through the first main service module, it can also determine multiple second plug-ins in the operating system through the second main service module; then determine whether the package name and / or class name of the second plug-in is in the whitelist; when the package name and / or class name of the second plug-in is in the whitelist, verify whether the second plug-in is legal through a signature mechanism; when it is determined that the second plug-in is legal, create a second instance of the second plug-in and run the second instance in a second process; listen to the second system event through multiple second plug-ins, and when one of the multiple second plug-ins detects the occurrence of a second preset system event, start the corresponding second application, so that the second application executes the non-resident business corresponding to the second preset system event.

[0146] Therefore, the embodiment of the present application adopts a dual-process mechanism to process plug-ins, and loads plug-ins for different business scenarios into independent processes, so as to optimize the resource utilization of the operating system. And the legality and integrity of the first plug-in are verified through a dual verification mechanism, thereby reducing the risk of potential malicious plug-ins or unauthorized plug-ins, and the dual verification mechanism combines multiple verification methods to significantly enhance the security of the system.

[0147] In the embodiment of the present application, each resident service is in the same process when running through a plug-in method, and is independently compiled during development, which not only meets the performance requirements, but also facilitates development and improves the user experience. Moreover, the embodiment of the present application can also process plug-ins through dual-process classification. The first process is used to load the plug-in corresponding to the resident service, and the second process is used to load the plug-in corresponding to the non-resident service. This is conducive to increasing the boot speed, avoiding certain plug-ins from obtaining unnecessary system-level permissions, and providing system security. Furthermore, the plug-in verification mechanism in the embodiment of the present application ensures that the operating system is not used by illegal plug-ins to elevate privileges, thereby ensuring the security of the operating system.

[0148] All the above optional technical solutions can be combined in any way to form optional embodiments of the present application, and the embodiments of the present application will not be described in detail one by one.

[0149] Based on the above embodiments, the embodiments of the present application provide an operating system for an in-vehicle system. The operating system for the in-vehicle device includes: a kernel, a service layer, and an application layer, wherein:

[0150] The kernel is configured to start the service layer during the startup of the operating system of the vehicle-mounted device;

[0151] The service layer is configured to start the application layer;

[0152] The application layer is configured to run a first main service in a first process, the first process is a resident process, and the first main service is a resident service of the operating system; multiple first plug-ins are loaded in the first process, each first plug-in is used to implement the listening function of the corresponding resident service; when a first preset system event is listened to by one or more plug-ins among the multiple first plug-ins, the first application corresponding to the one or more plug-ins is started, so that the first application executes the resident service corresponding to the first preset system event.

[0153] In some embodiments, the application layer is further configured to query configuration files of one or more services in the operating system to determine multiple first plug-ins; create a first instance for each first plug-in; and run the first instance in a first process through a first main service module.

[0154] In some embodiments, the application layer is further configured to traverse configuration files of one or more services in the operating system, the configuration files including type information and process configuration information of the services; when the type information indicates that a first service among the one or more services is configured with a plug-in, and the process configuration information indicates that the first service is configured to run in a first process, it is determined that the plug-in corresponding to the first service is the first plug-in.

[0155] In some embodiments, the application layer is further configured to query the configuration file related to each first plug-in through the first main service module to determine the package name and / or class name of each first plug-in; determine whether the package name and / or class name of each first plug-in is in the whitelist through the first main service module; and create a first instance for each first plug-in if the package name and / or class name of each first plug-in is in the whitelist.

[0156] In some embodiments, the application layer is also configured to obtain signature data of each first plug-in, the signature data including the original package name and / or class name of each first plug-in, and the package name and / or class name encrypted by the server using a private key for each first plug-in, the signature data being pre-generated by the first main service module; the signature data is verified using a public key by the first main service module; and when the signature data verification passes, a first instance is created for each first plug-in.

[0157] In some embodiments, the application layer is further configured to: perform hash calculation on the original package name and / or class name in the signature data through the first main service module to obtain a first hash value; decrypt the encrypted package name and / or class name in the signature data using the public key through the first main service module to obtain a second hash value; verify the signature data based on the first hash value and the second hash value, wherein when the first hash value is the same as the second hash value, the signature data verification succeeds.

[0158] In some embodiments, the application layer is further configured as follows: during the startup of the operating system, a second main service module is run in a second process, the second process and the first process are resident processes corresponding to different user groups in the operating system, and the second main service module and the first main service module are resident services corresponding to different user groups in the operating system; through the second main service module, multiple second plug-ins are loaded in the second process, wherein each second plug-in is used to implement a listening function for a corresponding non-resident service; when the occurrence of a second preset system event is intercepted through one or more of the multiple second plug-ins, the corresponding second application is started so that the second application executes a non-resident service corresponding to the second preset system event.

[0159] The description of the above vehicle-mounted device operating system embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. In some embodiments, the functions or modules included in the operating system provided in the embodiment of the present application can be used to execute the method described in the above method embodiment. For technical details not disclosed in the operating system embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0160] It should be noted that in the embodiment of the present application, if the above-mentioned process management method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific hardware, software or firmware, or any combination of hardware, software, and firmware.

[0161] An embodiment of the present application provides a vehicle-mounted device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and the processor implements the steps in the above method when executing the program.

[0162] The embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the steps in the above method are implemented. The computer-readable storage medium can be transient or non-transient.

[0163] An embodiment of the present application provides a computer program, including a computer-readable code. When the computer-readable code is run in a computer device, a processor in the computer device executes the steps for implementing the above method.

[0164] The embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, the steps in the above method are implemented. The computer program product can be implemented specifically by hardware, software or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK) and the like.

[0165] It should be noted here that the description of the various embodiments above tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. The description of the above device, storage medium, computer program and computer program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the embodiments of the device, storage medium, computer program and computer program product of this application, please refer to the description of the method embodiment of this application for understanding.

[0166] Fig. 9 A schematic diagram of a hardware entity of a vehicle-mounted device provided in an embodiment of the present application, such as Fig. 9 As shown, the hardware entity of the vehicle-mounted device 9 includes: a processor 901 and a memory 902, wherein the memory 902 stores a computer program that can be run on the processor 901, and the processor 901 implements the steps in the method of any of the above embodiments when executing the program.

[0167] The memory 902 stores computer programs that can be run on the processor. The memory 902 is configured to store instructions and applications executable by the processor 901. It can also cache data to be processed or processed by the processor 901 and various modules in the vehicle-mounted device 9 (for example, image data, audio data, voice communication data, and video communication data). This can be achieved through flash memory (FLASH) or random access memory (Random Access Memory, RAM).

[0168] When the processor 901 executes the program, the steps of any of the above process management methods are implemented. The processor 901 usually controls the overall operation of the vehicle-mounted device 9.

[0169] An embodiment of the present application provides a computer storage medium, which stores one or more programs. The one or more programs can be executed by one or more processors to implement the steps of the process management method of any of the above embodiments.

[0170] It should be noted here that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0171] The processor may be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, and a microprocessor. It is understandable that the electronic device that implements the functions of the processor may also be other, and the embodiments of the present application are not specifically limited.

[0172] The above-mentioned computer storage medium / memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory (Flash Memory), a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM) and the like; it can also be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0173] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the serial number of each step / process mentioned above does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The serial numbers of the embodiments of the present application mentioned above are for description only and do not represent the advantages and disadvantages of the embodiments.

[0174] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0175] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0176] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected based on actual needs to achieve the purpose of the present embodiment.

[0177] In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0178] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, etc., various media that can store program codes.

[0179] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0180] The above is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A process management method, executed by a vehicle-mounted device, characterized in that: The method comprises: During the startup of the operating system of the vehicle-mounted device, a first main service module is run in a first process, the first process is a resident process of the operating system, and the first main service module is a resident service of the operating system; Loading a plurality of first plug-ins in the first process through the first main service module, wherein each first plug-in is used to implement a listening function of a corresponding resident service; When a first preset system event is intercepted by one or more plug-ins among the plurality of first plug-ins, a corresponding first application is started so that the first application executes a resident service corresponding to the first preset system event.

2. The method according to claim 1, characterized in that The step of loading a plurality of first plug-ins in the first process through the first main service module includes: Querying configuration files of one or more services in the operating system to determine the plurality of first plug-ins; Creating a first instance for each first plugin; The first instance is run in the first process through the first main service module.

3. The method according to claim 2, characterized in that The querying of the configuration files of one or more services in the operating system to determine the plurality of first plug-ins includes: Traversing configuration files of the one or more services in the operating system, the configuration files including type information and process configuration information of the services; When the type information indicates that a first service among the one or more services is configured with a plug-in, and the process configuration information indicates that the first service is configured to run in the first process, it is determined that the plug-in corresponding to the first service is the first plug-in.

4. The method according to claim 2, characterized in that: The step of creating a first instance for each first plug-in includes: querying, through the first main service module, a configuration file related to each of the first plug-ins to determine a package name and / or a class name of each of the first plug-ins; Determine, by the first main service module, whether the package name and / or class name of each first plug-in is in the whitelist; In a case where the package name and / or class name of each first plug-in is in the whitelist, the first instance is created for each first plug-in.

5. The method according to claim 2, characterized in that: The step of creating a first instance for each first plug-in includes: Acquire signature data of each first plug-in, the signature data including the original package name and / or class name of each first plug-in, and the package name and / or class name of each first plug-in encrypted by the server using a private key, the signature data being pre-generated by the first main service module; Verifying the signature data using a public key through the first main service module; When the signature data is verified successfully, the first instance is created for each first plug-in.

6. The method according to claim 5, characterized in that The verifying the signature data using a public key by the first main service module includes: Performing hash calculation on the original package name and / or class name in the signature data through the first main service module to obtain a first hash value; Decrypting the encrypted package name and / or class name in the signature data using the public key through the first main service module to obtain a second hash value; The signature data is verified based on the first hash value and the second hash value, wherein when the first hash value is the same as the second hash value, the signature data is verified successfully.

7. The method according to claim 1, characterized in that The method further comprises: During the startup of the operating system, a second main service module is run in a second process, the second process and the first process are resident processes corresponding to different user groups in the operating system, and the second main service module and the first main service module are resident services corresponding to different user groups in the operating system; Loading a plurality of second plug-ins in the second process through the second main service module, wherein each second plug-in is used to implement a listening function of a corresponding non-resident service; When a second preset system event is intercepted by one or more plug-ins among the plurality of second plug-ins, a corresponding second application is started so that the second application executes a non-resident service corresponding to the second preset system event.

8. A vehicle-mounted device, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the steps in the method according to any one of claims 1 to 7 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps in the method according to any one of claims 1 to 7 are implemented.

10. A computer program product, comprising a computer program or instructions, characterized in that: When the computer program or instruction is executed by a processor, the steps in the method according to any one of claims 1 to 7 are implemented.

Images