Vehicle communication method, device and vehicle

Abstract

This application relates to a vehicle communication method, apparatus, and vehicle. The method includes: when the vehicle operating system is started, acquiring various protocol applications installed in the vehicle operating system and establishing communication channels with protocol adapters in each protocol application; upon receiving a device discovery event reported by any protocol adapter through the corresponding communication channel, determining device information corresponding to the terminal device from the device discovery event, wherein the device discovery event is generated by the protocol adapter listening to the terminal device; displaying the device information through a display device in the vehicle; and upon detecting a connection trigger operation for the device information, enabling a first protocol application corresponding to the first protocol adapter to communicate with the terminal device through the first protocol adapter corresponding to the terminal device. This application avoids the increased development and maintenance work caused by the protocol adapter being embedded in the vehicle operating system, thus reducing the development and maintenance costs of vehicle communication.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, specifically to a vehicle communication method, device, and vehicle. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, the secure and convenient mapping of navigation, calling, and media functions from smartphones and other smart terminals to the in-vehicle system has become a necessary technological path to reduce driving interference and enhance the cabin experience. Currently, vehicles generally communicate with smart terminals from different brands through various protocol applications (such as Apple CarPlay and Huawei HiCar) based on underlying transmission links such as USB, Wi-Fi, or Bluetooth.

[0003] However, existing solutions generally adopt a structural design that deeply couples the protocol application with the vehicle operating system. That is, each interconnection protocol corresponds to a protocol application and protocol adapter that are deeply bound to it, forming an independent communication unit that is completely isolated from other protocols, and each protocol adapter is embedded in the vehicle operating system. After the vehicle operating system starts, each protocol application independently starts its own process to achieve communication between the protocol application and the smart terminal through the corresponding protocol adapter.

[0004] However, due to the deep coupling between the protocol adapters and the vehicle operating system, any configuration modification for any protocol requires code adjustment and recompilation of the underlying framework of the vehicle operating system. This results in a linear increase in development and maintenance work with the number of protocols, leading to persistently high development and maintenance costs. Summary of the Invention

[0005] One objective of this application is to provide a vehicle communication method that decouples the protocol application from the underlying framework of the vehicle operating system, avoiding the increased development and maintenance work caused by the protocol adapter being embedded in the vehicle operating system, and reducing the development and maintenance costs of vehicle communication; another objective of this application is to provide a vehicle communication device; and a third objective of this application is to provide a vehicle.

[0006] To achieve the above objectives, in a first aspect, this application provides a vehicle communication method applied to a device management service, wherein the device management service runs on an in-vehicle operating system in a vehicle, the method comprising: When the vehicle operating system is started, obtain the various protocol applications installed in the vehicle operating system, and establish a communication channel with the protocol adapters in each of the protocol applications; When a device discovery event is received from any of the protocol adapters through the corresponding communication channel, the device information corresponding to the terminal device is determined from the device discovery event. The device discovery event is generated by the protocol adapter listening to the terminal device. The device information is displayed via a display device in the vehicle; When a connection trigger operation for the device information is detected, the first protocol application corresponding to the first protocol adapter of the terminal device communicates with the terminal device.

[0007] To achieve the above objectives, in a second aspect, this application provides a vehicle communication device applied to a device management service, wherein the device management service runs on an in-vehicle operating system in the vehicle, the device comprising: The acquisition module is used to acquire each protocol application installed in the vehicle operating system when the vehicle operating system is started, and to establish a communication channel with the protocol adapter in each of the protocol applications. The determination module is used to determine the device information corresponding to the terminal device from the device discovery event when it receives a device discovery event reported by any of the protocol adapters through the corresponding communication channel. The device discovery event is generated by the protocol adapter listening to the terminal device. A display module is used to display the device information via a display device in the vehicle; The communication module is configured to, when a connection trigger operation for the device information is detected, enable a first protocol application corresponding to the first protocol adapter to communicate with the terminal device via the first protocol adapter corresponding to the terminal device.

[0008] To achieve the above objectives, in a third aspect, this application also provides a vehicle, including: a processor and a memory, wherein the processor is configured to execute a vehicle communication program stored in the memory to implement the vehicle communication method described above.

[0009] The beneficial effects of this application are as follows: This application provides a vehicle communication method applied to a device management service, which runs on an in-vehicle operating system in a vehicle. The method includes: when the in-vehicle operating system is started, acquiring various protocol applications installed in the in-vehicle operating system and establishing communication channels with the protocol adapters in each protocol application; when receiving a device discovery event reported by any protocol adapter through the corresponding communication channel, determining the device information corresponding to the terminal device from the device discovery event, wherein the device discovery event is generated by the protocol adapter listening to the terminal device; displaying the device information through a display device in the vehicle; and when a connection trigger operation for the device information is detected, enabling the first protocol application corresponding to the first protocol adapter to communicate with the terminal device through the first protocol adapter corresponding to the terminal device. Through the above methods, this application constructs a device management service in the vehicle operating system as a centralized scheduling hub. When the vehicle operating system starts, it obtains the installed protocol applications and establishes communication channels with the protocol adapters in each protocol application. The device management service centrally receives device discovery events reported by each protocol adapter, determines the device information accordingly, and uniformly drives the display device to display the device information, thereby triggering communication between the protocol application and the terminal device corresponding to the device information. This decouples the protocol applications from the underlying framework of the vehicle operating system, avoids the increased development and maintenance work caused by the protocol adapters being embedded in the vehicle operating system, and reduces the development and maintenance costs of vehicle communication. Attached Figure Description

[0010] Figure 1 This illustration shows a flowchart of a vehicle communication method provided in an embodiment of this application; Figure 2 A flowchart illustrating another vehicle communication method provided in an embodiment of this application is shown; Figure 3 This illustration shows a flowchart of yet another vehicle communication method provided in an embodiment of this application; Figure 4 This illustration shows a thread allocation diagram provided in an embodiment of this application; Figure 5 This illustration shows a timing diagram of vehicle communication provided in an embodiment of this application; Figure 6 This diagram illustrates the structure of a data communication device according to an embodiment of this application. Figure 7 This illustration shows a structural diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0011] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0012] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0013] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this application.

[0014] refer to Figure 1 , Figure 1 This is a flowchart illustrating a vehicle communication method provided in an embodiment of this application. The vehicle communication method provided in this application specifically includes the following steps: S101: When the vehicle operating system is started, obtain the various protocol applications installed in the vehicle operating system, and establish a communication channel with the protocol adapters in each protocol application.

[0015] In this embodiment, the method is applied to a device management service, which runs on the vehicle's onboard operating system. The device management service is essentially a centralized scheduling hub.

[0016] Protocol applications are those already installed in the vehicle's operating system. These applications are visible as application icons on the vehicle's infotainment screen and exist as independent installation packages within the operating system. Examples of protocol applications include Apple CarPlay and Huawei HiCar. Each protocol application integrates a corresponding protocol adapter, which serves as the interface between the protocol application in the vehicle and the terminal device.

[0017] The communication channel can be understood as a two-way communication link established between the device management service and each protocol adapter.

[0018] Specifically, upon startup of the vehicle operating system, the device management service is initiated as a system-level service. The device management service first scans the installed protocol applications within the vehicle operating system, identifying the protocol adapters integrated within each application. The device management service establishes a bidirectional communication channel with each protocol adapter. This communication channel is implemented based on the inter-process communication mechanism (IPC) within the vehicle operating system. The device management service assigns a communication handle to each protocol adapter and stores it in the protocol registry maintained internally by the device management service. At this point, the device management service gains the ability to communicate with all protocol adapters, and each protocol adapter gains a path to report events to the device management service.

[0019] In the above, step S101, which establishes a communication channel with the protocol adapters in each protocol application, specifically includes: Communication channels are established with protocol adapters in various protocol applications through the Software Development Kit (SDK) interface.

[0020] The Software Development Kit (SDK) interface can be understood as a standardized application programming interface provided by the device management service to various protocol adapters. The SDK interface defines a unified specification for communication between the protocol adapters and the device management service. Protocol adapters register with the device management service, report events, and receive commands by calling the SDK interface, while the device management service manages the protocol adapters uniformly through the SDK interface. The SDK interface enables all protocol adapters to access the device management service in a unified manner.

[0021] Specifically, when the vehicle operating system boots up, the device management service first loads the standardized SDK interface and completes its initialization. Then, the device management service scans the various protocol applications installed in the vehicle operating system and identifies the protocol adapters integrated within each application. For each protocol adapter, the device management service opens a registration portal to it through the SDK interface.

[0022] After each protocol adapter starts up, it actively calls the registration interface defined in the SDK interface to initiate a registration request to the device management service. The registration request carries information such as the protocol adapter's identity and supported protocol types. After receiving the registration request through the SDK interface, the device management service verifies the interface validity of the protocol adapter. If the verification is successful, the device management service establishes a bidirectional communication channel with the protocol adapter through the SDK interface and records the protocol adapter in its internal protocol registry. During subsequent operation, the protocol adapter reports device discovery events to the device management service through the SDK interface, and the device management service issues corresponding instructions to the protocol adapter through the SDK interface.

[0023] In this embodiment, a standardized software development kit (SDK) interface is used to establish a communication channel with each protocol adapter. This transforms the existing decentralized interface method, where each protocol adapter directly couples with the vehicle operating system through its own private interface, into a centralized interface method where each protocol adapter registers with the device management service and establishes a communication channel through a unified SDK interface. This avoids the repetitive work of developing dedicated adaptation code for each protocol due to inconsistent protocol interface specifications, and achieves standardized access and unified management of multiple protocol adapters.

[0024] S102: When a device discovery event is received from any protocol adapter through the corresponding communication channel, the device information corresponding to the terminal device is determined from the device discovery event.

[0025] In this embodiment, the device discovery event is generated by the protocol adapter listening to the terminal device. That is, after the protocol adapter listens to the physical access signal of the terminal device corresponding to the protocol, it generates a device discovery event according to the corresponding format. The device discovery event carries the device information corresponding to the terminal device, including the identifier of the terminal device being listened to.

[0026] Specifically, when a user's terminal device enters the vehicle's connectivity range via a physical link such as USB or Bluetooth, the protocol adapter responsible for monitoring that physical link detects the presence of the terminal device. Based on its corresponding proprietary protocol specification, the protocol adapter extracts the terminal device's device identifier from the physical signal and generates a device discovery event. This event is then reported to the device management service through the established communication channel. Upon receiving the device discovery event, the device management service parses the terminal device's device identifier from the discovery data to determine the corresponding device information.

[0027] It should be noted that after executing step S102, the historical connection frequency of the terminal device within a preset time period can be queried. If the historical connection frequency is greater than a preset frequency threshold, a connection trigger operation is generated for the device information. Based on the connection trigger operation, the first protocol application corresponding to the first protocol adapter of the terminal device communicates with the terminal device. The preset time period is a time period prior to the current moment, and the historical connection frequency is the number of times the terminal device establishes communication with the vehicle within the preset time period. The preset frequency threshold can be set according to actual needs; it is not limited in this embodiment.

[0028] S103: Display device information via a display device in the vehicle.

[0029] In this embodiment, the display device may be an in-vehicle display screen, such as a central control screen.

[0030] Specifically, the device management service sends the identified device information to the display device in the vehicle, driving the display device to show the device entry corresponding to the terminal device in the device list interface. This device entry contains basic information such as the device identifier corresponding to the terminal device, which can be browsed and selected by the user. Since the display action is uniformly driven by the device management service, the display format and interaction interface remain consistent regardless of the underlying protocol adapter that discovers the terminal device.

[0031] It should be noted that when displaying device information via the display device, the current driving status information of the vehicle is obtained; when the current driving status information meets preset safety conditions, the device information is displayed via the display device. Preset safety conditions include the vehicle's current driving speed being less than a preset safe speed threshold, and / or the vehicle's current gear being in park.

[0032] Furthermore, when the current driving status information meets preset safety conditions, the occupancy status of each seat in the vehicle is obtained; when there are multiple devices to be displayed, the device location of the terminal device corresponding to each device is obtained; based on each occupancy status and device location, the display priority of each display information is determined; and based on each display priority, the device information is displayed through a display device. Specifically, based on each occupancy status and device location, the terminal can be associated with and matched with the seat, thus determining the display priority of each display information according to preset rules (e.g., driver's seat priority), and then displaying the information based on each display priority to improve the user experience.

[0033] S104: When a connection trigger operation for device information is detected, the first protocol application corresponding to the first protocol adapter of the terminal device communicates with the terminal device.

[0034] In this embodiment, the connection trigger operation refers to the connection operation initiated by the user after seeing the device information on the display device, which is usually clicking the connection button on the device entry.

[0035] The first protocol adapter refers to the protocol adapter corresponding to the terminal device selected by the user for connection.

[0036] The first protocol application refers to a protocol application that integrates a first protocol adapter. After a user selects to connect to a terminal device, the device management service enables the first protocol application to communicate with the terminal device through the first protocol adapter.

[0037] Specifically, after seeing the device information on the display device, the user clicks the connect button for the corresponding device entry, triggering a connection operation. Upon detecting this connection operation, the device management service identifies the first protocol adapter corresponding to the terminal device and sends a connection command to the first protocol adapter through the established communication channel. After receiving the connection command, the first protocol adapter establishes a communication connection between the first protocol application and the terminal device, and then enables communication between the first protocol application and the terminal device through the first protocol adapter.

[0038] The vehicle communication method provided in this embodiment further includes the following steps after executing step S104: When a new protocol application is installed in the vehicle operating system, obtain the new protocol adapter corresponding to the new protocol application. Establish a communication channel with the newly added protocol adapter; After establishing a communication channel with the newly added protocol adapter, the step of determining the device information corresponding to the terminal device from the device discovery event when a device discovery event is received from any protocol adapter through the corresponding communication channel is executed.

[0039] The newly added protocol applications mentioned above can be understood as those newly installed onto the vehicle operating system via OTA (Over-The-Air) or local installation during the system's operation. Each newly added protocol application corresponds to a mobile connectivity protocol brand not included in the device management service's scope. These applications exist as independent installation packages, each integrating a corresponding new protocol adapter.

[0040] Specifically, during the operation of the vehicle operating system, the vehicle operating system installs new protocol applications via OTA or local installation. The device management service detects that the new protocol application has been installed by listening to the protocol application change events of the vehicle operating system, scans the inside of the new protocol application, and obtains the corresponding new protocol adapter.

[0041] After obtaining a newly added protocol adapter, the device management service performs interface verification on the new protocol adapter. If the verification is successful, the device management service establishes a communication channel with the new protocol adapter and records the new protocol adapter in the internally maintained protocol registry.

[0042] After the device management service establishes a communication channel with the newly added protocol adapter, the device management service returns to execute the above-mentioned step S102 to enable subsequent communication between the newly added protocol application and the device.

[0043] In this embodiment, the device management service obtains the protocol adapter and establishes a communication channel when a new protocol application is added, thereby enabling communication between the newly added protocol application and the device. This avoids the need to modify the vehicle operating system code for each new protocol application, as is required in the prior art, and achieves dynamic expansion of multiple protocols.

[0044] This embodiment provides a vehicle communication method that constructs a device management service in the vehicle operating system as a centralized scheduling hub. When the vehicle operating system starts, it acquires the installed protocol applications and establishes communication channels with the protocol adapters in each application. The device management service centrally receives device discovery events reported by each protocol adapter, determines the device information accordingly, and uniformly drives the display device to display the device information, thereby triggering communication between the protocol applications and the terminal devices corresponding to the device information. This decouples the protocol applications from the underlying framework of the vehicle operating system, avoids the increased development and maintenance work caused by the protocol adapters being embedded in the vehicle operating system, and reduces the development and maintenance costs of vehicle communication.

[0045] refer to Figure 2 , Figure 2 This is a flowchart illustrating another vehicle communication method provided in an embodiment of this application. The vehicle communication method provided in this application specifically includes the following steps: S201: When the vehicle operating system is started, obtain the various protocol applications installed in the vehicle operating system, establish communication channels with the protocol adapters in each protocol application, and create an interface resource pool.

[0046] In this embodiment, the acquisition of the protocol application and the establishment of the communication channel can be referred to the above description, and will not be repeated here.

[0047] The UI resource pool can be understood as a collection of idle view containers pre-created by the device management service when the in-vehicle operating system starts. Each view container is a UI resource that can be used by protocol applications to render interactive interfaces. The UI resource pool is exclusively managed by the device management service.

[0048] Specifically, when the vehicle operating system starts up, the device management service, while acquiring various protocol applications and establishing communication channels, initiates a request for interface resources from the vehicle operating system to pre-acquire a set of idle view containers. The device management service stores these view containers in an internally maintained unified interface resource pool, and each view container is marked as idle.

[0049] S202: When a device discovery event is received from any protocol adapter through the corresponding communication channel, the device information corresponding to the terminal device is determined from the device discovery event.

[0050] S203: Display device information via a display device in the vehicle.

[0051] Regarding steps S202 and S203, step S202 is the same as step S102, and step S203 is the same as step S103. For details, please refer to the above description. This embodiment will not repeat the details here.

[0052] S204: When a connection trigger operation for device information is detected, a connection command is sent to the first protocol adapter corresponding to the terminal device so that the first protocol application corresponding to the first protocol adapter can establish a communication connection with the terminal device through the first protocol adapter.

[0053] In this embodiment, the connection command refers to the control message sent by the device management service to the first protocol adapter, which is used to trigger the establishment of a communication link between the first protocol adapter and the terminal device.

[0054] Communication connection refers to the underlying communication link established between the first protocol application and the terminal device through the first protocol adapter.

[0055] Specifically, when a user triggers a connection operation on a display device for a specific device, the device management service identifies the first protocol adapter corresponding to that device and sends a connection command to the first protocol adapter through the established communication channel. Upon receiving the connection command, the first protocol adapter establishes an underlying communication link with the terminal device, enabling the first protocol application to establish a communication connection with the terminal device through the first protocol adapter.

[0056] S205: After the first protocol application establishes a communication connection with the terminal device, allocate matching target interface resources to the first protocol application based on the interface resource pool.

[0057] In this embodiment, the target interface resource can be understood as a view container allocated by the device management service from the interface resource pool for the first protocol application, which is used to carry the interactive interface presented after the first protocol application successfully connects with the terminal device.

[0058] Specifically, after the first protocol application establishes a communication connection with the terminal device, the device management service selects an idle view container from the interface resource pool created at startup, marks it as allocated, and determines that the view container is the target interface resource. The device management service sends the target interface resource to the first protocol application, enabling the first protocol application to obtain rendering permissions for the view container.

[0059] S206: Based on the target interface resources, the target interactive interface corresponding to the first protocol application is displayed through the display device, so that the terminal device can interact and communicate with the first protocol application based on the target interactive interface and the first protocol adapter.

[0060] In this embodiment, the target interactive interface can be understood as the terminal interconnection function screen corresponding to the first protocol application that can be operated by the user, which is rendered on the display device using the target interface resources. It includes function entrances and interactive controls such as navigation map, music control, and call interface.

[0061] Specifically, after the first protocol application is assigned to the target interface resource, it renders its interactive interface content within the view container. The rendering data is based on the screen data stream or UI description instructions obtained by the first protocol adapter from the terminal device, and is drawn by the first protocol application within the window area defined by the target interface resource. The display device ultimately presents the target interactive interface, through which the user can interact and communicate with the functions of the terminal device.

[0062] In this embodiment, when the vehicle operating system is started, an interface resource pool is pre-created through the device management service. After the protocol application establishes a communication connection with the terminal device, interface resources are uniformly allocated from the interface resource pool to present the interactive interface. This transforms the decentralized approach in the prior art, where each protocol application independently applies for windows and renders the interface independently, into a centralized interface management approach where the device management service centrally allocates display resources and the protocol application renders content within the uniformly allocated window. This avoids the problems of window resource contention and interface style fragmentation caused by each protocol application independently controlling interface resources.

[0063] In one embodiment, the vehicle communication method provided in this embodiment further includes the following steps after displaying the target interactive interface: Receive the operating status information reported by the first protocol adapter through the corresponding communication channel; The device status of the terminal device is updated based on the operating status information; Based on the updated device information, the device status of the terminal device in the target interactive interface is updated through the display device to complete the update of the target interactive interface.

[0064] Among them, the running status information corresponds to the terminal device. That is, after the first protocol application communicates with the terminal device through the first protocol adapter, the first protocol adapter continuously monitors the status changes on the terminal device side and encapsulates them into running status information. The running status information includes at least one of the following: the running status of the foreground application on the terminal device, foreground / background switching events, audio focus change information, abnormal alarm information, and user operation results.

[0065] Device status refers to the current operational status description maintained by the device management service in the device status table for each connected terminal device. Device status includes pending discovery, registered, connecting, connected, abnormal, and disconnected states.

[0066] Specifically, after the target interactive interface is displayed, the first protocol adapter continuously monitors the operational status changes of the connected terminal device. When events such as navigation initiation, incoming phone calls, music playback switching, application foreground / background switching, or communication anomalies occur on the terminal device, the first protocol adapter encapsulates the perceived operational status changes into operational status information and proactively reports it to the device management service through the corresponding established communication channel. Based on the received operational status information, the device management service updates the device status record corresponding to that terminal device in the device status table. The update operation is uniformly executed by the device management service, ensuring the real-time nature and accuracy of the device status in the device status table.

[0067] Based on the updated device status information, the device management service sends a screen refresh command to the display device. This command carries the latest device status of the terminal device. Upon receiving the screen refresh command, the display device updates the corresponding device status in the target interface. After the update is complete, the device status seen by the user on the target interface is completely consistent with the device status recorded in the device status table maintained by the device management service.

[0068] It should be noted that this can be used as a reference. Figure 4 As shown, the device management service is configured to run with a higher process priority than individual protocol applications upon startup, ensuring that user operation commands and critical events reported by protocol adapters receive priority processing. Furthermore, when the device management service detects concurrent communication from multiple terminal devices (i.e., multiple first protocol adapters reporting operational status information through their respective communication channels), it can use a pre-defined multi-threading allocation strategy to distribute the communication tasks corresponding to each terminal device to different processing threads for parallel execution, avoiding processing delays caused by single-thread blocking. The multi-threading allocation strategy can be understood as a set of pre-defined rules within the device management service that determine how to allocate communication tasks corresponding to different terminal devices to different worker threads for parallel processing.

[0069] In this embodiment, after the target interactive interface, the device management service continuously receives the terminal device's corresponding operating status information reported by the first protocol adapter. Based on this operating status information, the device status of the terminal device is updated, and the display device is driven to synchronously refresh the terminal device's device information in the target interactive interface. This transforms the decentralized approach of each protocol application maintaining its own status and independently updating the interface in the prior art into a centralized management approach where the device management service centrally maintains the device status and uniformly drives the interface refresh. This avoids the problems of scattered device status information and inconsistencies between the interface display and the actual status caused by each protocol application independently managing the device status.

[0070] In another embodiment, the vehicle communication method provided in this embodiment further includes the following steps after displaying the target interactive interface: Upon receiving a communication disconnection event from the terminal device reported by the first protocol adapter, a communication disconnection command is sent to the first protocol adapter to disconnect the communication connection between the first protocol application and the terminal device. Receive the disconnection execution result corresponding to the terminal device reported by the first protocol adapter; Based on the result of the disconnection, the target interactive interface is closed via the display device, and the target interface resources are recycled to the interface resource pool.

[0071] A communication disconnection event can be understood as an event message that triggers the termination of the communication connection between the first protocol application and the terminal device. Sources of communication disconnection events include active disconnection triggered by the user clicking the disconnect button on the target interface, hardware disconnection signals caused by the interruption of the physical link between the first protocol application and the terminal device, and abnormal protocol exit detected by the first protocol adapter. This communication disconnection event is sensed by the first protocol adapter and reported to the device management service.

[0072] A communication disconnection command can be understood as a control message issued by the device management service to the first protocol adapter after receiving a communication disconnection event reported by the first protocol adapter. This communication disconnection command is used to notify the first protocol adapter to perform a communication connection disconnection operation with the terminal device, including releasing underlying link resources and closing the protocol.

[0073] The disconnection execution result can be understood as the execution feedback message returned to the device management service through the corresponding communication channel after the first protocol adapter executes the communication disconnection command between the first protocol application and the terminal device. This disconnection execution result is used to indicate whether the disconnection operation was successfully completed, whether the underlying link resources have been completely released, etc., so that the device management service can confirm that the communication disconnection process has been fully executed.

[0074] Specifically, after the target interactive interface is displayed, the device management service continuously monitors for communication disconnection events related to the first protocol application and the connected terminal devices. When the device management service receives a communication disconnection event, it identifies the first protocol adapter corresponding to the communication disconnection event and sends a communication disconnection command to the first protocol adapter through the established communication channel.

[0075] After receiving the communication disconnect command, the first protocol adapter executes the communication disconnection operation between the first protocol application and the terminal device. Upon completion of the communication disconnection operation, the first protocol adapter generates a disconnection execution result and reports it to the device management service through the corresponding communication channel.

[0076] After receiving the disconnection execution result reported by the first protocol adapter, if the device management service confirms that the communication connection has been completely broken, the device management service closes the target interactive interface and removes it from the display device. At the same time, the device management service reclaims the allocated target interface resources into the interface resource pool, marks the view container as idle, and waits for reallocation when the next communication connection is established.

[0077] In this embodiment, the device management service uniformly issues disconnection commands and receives disconnection execution results when a communication disconnection event is received. Based on the disconnection execution results, the interactive interface is closed and the target interface resources are reclaimed to the interface resource pool. This transforms the decentralized approach of independent disconnection cleanup by each protocol application in the prior art into centralized disconnection management. This avoids the problem of interface residue caused by each protocol application's autonomous management of interface resource release, and realizes unified disconnection management of multi-protocol communication connections and reliable reclamation of system resources.

[0078] The above-mentioned step of issuing a communication disconnect command to the first protocol adapter specifically includes: When a communication disconnection event is used to indicate an abnormal communication disconnection of a terminal device, the disconnection reason code is determined from the communication disconnection event; Determine the duration of the terminal device disconnection and determine the matching result between the disconnection reason code and the preset reason code set; If the duration exceeds a preset duration threshold and / or the matching result is a failure, a communication disconnection command is sent to the first protocol adapter.

[0079] The disconnection reason code can be understood as an encoding carried in the communication disconnection event to identify the specific reason for the communication disconnection. When the first protocol adapter detects an abnormal communication disconnection from the terminal device, it generates a corresponding disconnection reason code based on the electrical signal status reported by the underlying hardware or the protocol error type detected by the first protocol adapter. For example, a USB electrical signal abnormality may correspond to a specific reason code, while a momentary loss of Wi-Fi signal may correspond to another specific reason code.

[0080] The preset reason codes in the preset reason code set are used to indicate that the terminal device that has experienced an abnormal communication disconnection can automatically restore the communication connection. For example, the preset reason code can be the reason code corresponding to the disconnection caused by a momentary contact of the USB interface, or the preset reason code can be the reason code corresponding to the disconnection caused by short-term interference with the Wi-Fi signal.

[0081] Duration can be understood as the elapsed time from when the device management service receives the communication disconnection event to the current moment. This duration is used to measure how long the terminal device remains in a disconnected state.

[0082] The preset duration threshold is a time length value preset within the device management service. If the duration of the terminal device being in a communication disconnected state exceeds this preset duration threshold, it indicates that the terminal device cannot restore the communication connection on its own.

[0083] Specifically, after the target interactive interface is displayed, when a communication failure occurs on the terminal device, the first protocol adapter detects the communication failure event, generates a communication failure event carrying a failure reason code, and reports it to the device management service through the corresponding communication channel. After receiving the communication failure event, the device management service parses the failure reason code and determines whether the communication failure is a failure type not caused by user-initiated operation.

[0084] The device management service starts timing from the moment it receives a communication disconnection event, continuously updating the duration the terminal device has been in a disconnected state. Simultaneously, the device management service compares the disconnection reason code determined from the communication disconnection event with an internally preset set of reason codes to determine whether the disconnection reason code is a self-recoverable reason code, thus obtaining a matching result.

[0085] The device management service makes conditional judgments based on the duration and matching result. If the duration exceeds a preset threshold, it indicates that the terminal device has been unable to restore the communication connection for an extended period. Regardless of the matching result, the device management service sends a communication disconnect command to the first protocol adapter to perform a thorough disconnection cleanup. If the matching result is a failure, it indicates that this abnormal disconnection type cannot be recovered automatically, and the device management service immediately sends a communication disconnect command. Only when both conditions are met—that the duration is less than or equal to the preset threshold and the matching result is a successful match—will the device management service temporarily refrain from sending a communication disconnect command, waiting for the terminal device to restore the communication connection automatically.

[0086] During the waiting period before the device management service issues a communication disconnection command, the device management service maintains the device status of the terminal device in the device status table as "connected" or "abnormal" but does not immediately change it to "disconnected." It continues to prevent the reclaiming of interface and communication resources allocated to the terminal device and replaces the currently rendered screen with the latest static image frame captured from the frame buffer to maintain visual continuity. If the first protocol adapter detects that the terminal device has reconnected and reports a recovery event within a preset time threshold, the device management service resumes dynamic screen rendering, and the user is unaware of the connection recovery. If the connection is not restored after the preset time threshold, the management service then issues a disconnection command and reclaims resources.

[0087] In this embodiment, the device management service extracts the disconnection reason code and matches it with a preset reason code set when it receives a communication abnormal disconnection event. It also makes a dual judgment based on the duration of the disconnection. If the disconnection reason code is of the self-recoverable type and the duration does not exceed the preset duration threshold, the communication disconnection command will not be issued temporarily, thus avoiding unnecessary interface shutdown and resource release problems caused by instantaneous jitter of the physical link.

[0088] This embodiment provides a vehicle communication method that constructs a device management service in the vehicle operating system as a centralized scheduling hub. When the vehicle operating system starts, it acquires the installed protocol applications and establishes communication channels with the protocol adapters in each application. The device management service centrally receives device discovery events reported by each protocol adapter, determines the device information accordingly, and uniformly drives the display device to display the device information, thereby triggering communication between the protocol applications and the terminal devices corresponding to the device information. This decouples the protocol applications from the underlying framework of the vehicle operating system, avoids the increased development and maintenance work caused by the protocol adapters being embedded in the vehicle operating system, and reduces the development and maintenance costs of vehicle communication.

[0089] refer to Figure 3 , Figure 3 This is a flowchart illustrating another vehicle communication method provided in an embodiment of this application. The vehicle communication method provided in this application includes the following steps: S301: When the vehicle operating system is started, obtain the various protocol applications installed in the vehicle operating system and establish communication channels with the protocol adapters of each protocol application.

[0090] S302: When a device discovery event is received from any protocol adapter through the corresponding communication channel, the device information corresponding to the terminal device is determined from the device discovery event.

[0091] S303: Display device information via a display device in the vehicle.

[0092] Regarding steps S301 to S303, step S301 is the same as step S101, step S302 is the same as step S102, and step S303 is the same as step S103. For details, please refer to the above description. This embodiment will not repeat the details here.

[0093] S304: When a connection trigger operation for device information is detected, a connection command is sent to the first protocol adapter corresponding to the terminal device so that the first protocol application corresponding to the first protocol adapter can establish a communication connection with the terminal device through the first protocol adapter.

[0094] S305: After the first protocol application establishes a communication connection with the terminal device, if a resource occupation request is received from the first protocol adapter through the corresponding communication channel, the target type of the resource occupied by the first protocol application is determined from the resource occupation request.

[0095] S306: When it is determined that there is at least one second protocol application in each protocol application, the target priority corresponding to the first protocol application and each second protocol application is determined.

[0096] S307: Based on the priority of each target, respond to the resource occupancy request through the first protocol adapter so that the first protocol application can communicate with the terminal device.

[0097] For steps S304 to S307 above, the connection instructions can be referred to above, and will not be repeated here in this embodiment.

[0098] A resource occupancy request can be understood as a message submitted to the device management service through the corresponding communication channel after the first protocol application establishes a communication connection with the terminal device, requesting the occupancy of a specific type of system resource. For example, when the first protocol application needs to use functions such as audio playback or voice interaction, it needs to initiate a resource occupancy request to the device management service through the first protocol adapter, rather than directly requesting resources from the underlying vehicle operating system.

[0099] The target type can be understood as the category of system resources targeted by the resource usage request. Target types include audio resources, display resources, and voice interaction resources. Audio resources involve the usage rights of the vehicle's audio channels, display resources involve the usage rights of the main display area of ​​the central control screen, and voice interaction resources involve the usage rights of the vehicle's microphone and voice recognition engine.

[0100] The resource type occupied by the second protocol application is the target type. In other words, the second protocol application can be understood as another protocol application, besides the first protocol application, that is currently using system resources of the same target type. The existence of a second protocol application implies a resource conflict, meaning that two or more protocol applications simultaneously need to use the same type of system resource.

[0101] Target priority can be understood as the usage priority of the first protocol application and various second protocol applications on target type resources. Target priority is evaluated by the device management service according to a preset resource priority strategy. For example, the audio priority of telephone calls is higher than that of navigation voice broadcasts, and the priority of navigation voice broadcasts is higher than that of media music playback.

[0102] Specifically, when a user triggers a connection operation for a specific device, the device management service sends a connection command to the first protocol adapter corresponding to that device. Upon receiving the connection command, the first protocol adapter enables the first protocol application to establish a communication connection with the terminal device through the first protocol adapter.

[0103] After the communication connection is established, when the first protocol application needs to use specific types of resources from the in-vehicle system—for example, when a user needs audio playback to open navigation or needs to occupy a channel to start music playback—the first protocol application generates a resource occupancy request through the first protocol adapter and reports it to the device management service through the corresponding communication channel. Upon receiving the resource occupancy request, the device management service parses the target type of the requested resource, determining whether the request targets audio resources, display resources, or voice interaction resources, etc.

[0104] After determining the target type, the device management service checks whether at least one second protocol application is occupying resources of that target type among all protocol applications. If so, a resource conflict has occurred. Based on a preset resource priority policy, the device management service determines the target priority of the first protocol application and each second protocol application for that target type.

[0105] The device management service determines the priority ranking based on the priority of each target and responds to resource usage requests accordingly. If the target priority of the first protocol application is higher than that of all second protocol applications, the device management service issues a resource usage instruction to the first protocol adapter, granting the first protocol application permission to use the resource of that target type. Simultaneously, it issues a resource degradation instruction to the protocol adapters corresponding to each second protocol application, notifying them to release or reduce their usage of the resource of that target type. If the target priority of a second protocol application is higher than that of the first protocol application, the device management service issues a resource waiting instruction or a resource rejection instruction to the first protocol adapter, temporarily denying the first protocol application permission to use the resource of that target type.

[0106] In this embodiment, the device management service uniformly receives resource usage requests reported by protocol adapters and identifies the type of resource usage. When multiple protocol applications are detected using the same type of resource, arbitration is performed based on a priority strategy. The resource usage request is then responded to based on the arbitration result, thus avoiding the problem of contention for the same type of resource when multiple protocols are running concurrently.

[0107] This embodiment provides a vehicle communication method that constructs a device management service in the vehicle operating system as a centralized scheduling hub. When the vehicle operating system starts, it acquires the installed protocol applications and establishes communication channels with the protocol adapters in each application. The device management service centrally receives device discovery events reported by each protocol adapter, determines the device information accordingly, and uniformly drives the display device to display the device information, thereby triggering communication between the protocol applications and the terminal devices corresponding to the device information. This decouples the protocol applications from the underlying framework of the vehicle operating system, avoids the increased development and maintenance work caused by the protocol adapters being embedded in the vehicle operating system, and reduces the development and maintenance costs of vehicle communication.

[0108] The following is an example for reference. Figure 4 The following is a detailed description of the entire vehicle communication process: 1. Standardized Interface Registration: With the in-vehicle operating system booted, the device management service first loads the SDK interfaces. Subsequently, the protocol adapters within each protocol application start as independent processes, actively calling the SDK interfaces to initiate registration requests to the Binder driver. The registration request carries information such as the protocol adapter's identity and supported protocol types.

[0109] 2. Forwarding: As a system-level inter-process communication (IPC) mechanism, the Binder driver receives the registration request from the protocol adapter and forwards it to the device management service. After the device management service completes the registration verification, the Binder driver establishes a communication channel between the device management service and the protocol adapter during this process.

[0110] 3. Notify the connected device of the processing result: After registration is completed, when the terminal device physically connects to the vehicle via USB or Bluetooth, the protocol adapter listens for and matches the protocol type of the terminal device, generates a device discovery event carrying device information such as the terminal device identifier, and reports the generated device discovery event to the device management service through the established communication channel via the Binder driver.

[0111] 4. Update Device List Display Results: After receiving a device discovery event, the device management service determines the device information of the terminal device and updates the internally maintained device status table. Subsequently, the device management service synchronizes the device information to the UI device list module through a memory sharing mechanism, driving the UI device list module to display the corresponding device entry in the unified device list of the display device in the vehicle. Users can then see the newly discovered terminal device on the screen.

[0112] 5. Device Control: After seeing a device entry in the unified device list on the display device, the user clicks the connect button for the corresponding device entry to trigger a connection. The UI device list module captures this connection trigger and sends it to the Binder driver.

[0113] 6. Forwarding: After receiving the connection trigger operation, the Binder driver forwards it to the device management service. Based on the connection trigger operation, the device management service determines the first protocol adapter corresponding to the terminal device and generates the corresponding connection command.

[0114] 7. Call the device standard interface: The device management service calls the SDK interface through the Binder driver and passes the connection command to the first protocol adapter through the corresponding communication channel.

[0115] 8. Notification of device control: After receiving the connection command, the first protocol adapter translates it into the private command of the corresponding interconnection protocol and establishes a communication connection between the first protocol application and the terminal device in accordance with the protocol specification.

[0116] 9. Execute device control operations: After a complete communication connection is established between the first protocol application and the terminal device, the user can then operate the terminal device's functions through the interactive interface on the vehicle's infotainment screen. Simultaneously, the successful connection result is transmitted back to the device management service, which updates the device status table and synchronizes the successful status to the UI device list module. This drives the UI device list module to mark the corresponding device entry as connected in the unified device list on the display device.

[0117] refer to Figure 6 , Figure 6This is a schematic diagram of a vehicle communication device provided in an embodiment of this application. The vehicle communication device provided in this application includes a device management service, which runs on an in-vehicle operating system in the vehicle. The device includes: an acquisition module 10, a determination module 20, a display module 30, and a communication module 40. The acquisition module 10 is used to acquire various protocol applications installed in the in-vehicle operating system when the in-vehicle operating system is started, and to establish communication channels with the protocol adapters in each of the protocol applications. The determination module 20 is used to determine the device information corresponding to the terminal device from the device discovery event reported by any protocol adapter through the corresponding communication channel. The device discovery event is generated by the protocol adapter listening to the terminal device. The display module 30 is used to display the device information through a display device in the vehicle. The communication module 40 is used to enable communication between the first protocol application corresponding to the first protocol adapter and the terminal device when a connection trigger operation for the device information is detected, through the first protocol adapter corresponding to the terminal device.

[0118] The vehicle communication method provided in this embodiment further includes a creation module, which is used for: When the vehicle operating system is started, an interface resource pool is created, which is used to provide interface resources for the interactive interfaces of each of the protocol applications.

[0119] In this embodiment, the communication module 40 is further used for: A connection command is sent to the first protocol adapter corresponding to the terminal device, so that the first protocol application corresponding to the first protocol adapter establishes a communication connection with the terminal device through the first protocol adapter; After the first protocol application establishes a communication connection with the terminal device, a matching target interface resource is allocated to the first protocol application based on the interface resource pool. Based on the target interface resources, the target interactive interface corresponding to the first protocol application is displayed through the display device, so that the terminal device can interact and communicate with the first protocol application based on the target interactive interface and the first protocol adapter.

[0120] The vehicle communication method provided in this embodiment further includes an update module, which is used for: The system receives the operating status information reported by the first protocol adapter through the corresponding communication channel, and the operating status information corresponds to the terminal device. Based on the operating status information, the device status of the terminal device is updated; Based on the updated device information, the device status corresponding to the terminal device in the target interactive interface is updated through the display device to complete the update of the target interactive interface.

[0121] The vehicle communication method provided in this embodiment also includes a recycling module, which is used for: Upon receiving a communication disconnection event reported by the first protocol adapter for the terminal device, a communication disconnection command is sent to the first protocol adapter to cause the first protocol adapter to disconnect the communication connection between the first protocol application and the terminal device. Receive the disconnection execution result corresponding to the terminal device reported by the first protocol adapter; Based on the disconnection execution result, the target interactive interface is closed via the display device, and the target interface resources are recycled to the interface resource pool.

[0122] In this embodiment, the recycling module is also used for: When the communication disconnection event is used to indicate that the terminal device has abnormally disconnected communication, the disconnection reason code is determined from the communication disconnection event; Determine the duration of the disconnection of the terminal device, and determine the matching result between the disconnection reason code and the preset reason code set. The preset reason code set is used to indicate that the terminal device that has abnormally disconnected can restore the communication connection on its own. When the duration exceeds a preset duration threshold and / or the matching result is a failure, a communication disconnection command is sent to the first protocol adapter.

[0123] In this embodiment, the determining module 20 is further configured to: When the newly added protocol application is installed in the vehicle operating system, obtain the newly added protocol adapter corresponding to the newly added protocol application; Establish the communication channel with the newly added protocol adapter; After establishing the communication channel with the newly added protocol adapter, the step of determining the device information corresponding to the terminal device from the device discovery event when receiving a device discovery event reported by any of the protocol adapters through the corresponding communication channel is executed.

[0124] In this embodiment, the communication module 40 is further used for: A connection command is sent to the first protocol adapter corresponding to the terminal device, so that the first protocol application corresponding to the first protocol adapter establishes a communication connection with the terminal device through the first protocol adapter; After the first protocol application establishes a communication connection with the terminal device, if a resource occupation request is received from the first protocol adapter through the corresponding communication channel, the target type of the resource occupied by the first protocol application is determined from the resource occupation request. When it is determined that at least one second protocol application exists in each of the protocol applications, the target priority corresponding to the first protocol application and each of the second protocol applications is determined, and the type of resource occupied by the second protocol application is the target type; Based on the respective target priorities, the resource occupancy request is responded to through the first protocol adapter, so that the first protocol application can communicate with the terminal device.

[0125] In this embodiment, the acquisition module 10 is further configured to: A communication channel is established with the protocol adapters in each of the aforementioned protocol applications through the Software Development Kit (SDK) interface.

[0126] This embodiment provides a vehicle communication device that uses a device management service built into the vehicle operating system as a centralized scheduling hub. When the vehicle operating system starts, it acquires the installed protocol applications and establishes communication channels with the protocol adapters in each application. The device management service centrally receives device discovery events reported by each protocol adapter, determines the device information accordingly, and uniformly drives the display device to display the device information, thereby triggering communication between the protocol applications and the terminal devices corresponding to the device information. This decouples the protocol applications from the underlying framework of the vehicle operating system, avoids the increased development and maintenance work caused by the protocol adapters being embedded in the vehicle operating system, and reduces the development and maintenance costs of vehicle communication.

[0127] refer to Figure 7 As shown, Figure 7 This is a schematic diagram of a vehicle structure provided in an embodiment of this application. The vehicle 700 in this embodiment may include at least one processor 701, a memory 702, at least one network interface 704, and other user interfaces 703. The various components in the vehicle 700 are coupled together via a bus system 705. It is understood that the bus system 705 is used to implement communication between these components. In addition to a data bus, the bus system 705 also includes a power bus, a control bus, and a status signal bus. However, for clarity, all buses are referred to as bus system 705.

[0128] The user interface 703 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0129] It is understood that the memory 702 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 702 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0130] In some implementations, memory 702 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 7021 and application program 7022.

[0131] The operating system 7021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 7022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of the embodiments of this application can be included in the application program 7022.

[0132] In the embodiments of this application, the processor 701 executes the methods provided in the various method embodiments by calling the program or instructions stored in the memory 702, specifically the program or instructions stored in the application program 7022.

[0133] The methods disclosed in the embodiments of this application can be applied to or implemented by processor 701. Processor 701 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 701 or by instructions in the form of software. The processor 701 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 702. Processor 701 reads the information in memory 702 and uses its hardware to complete the above method.

[0134] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0135] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0136] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0137] When one or more programs in a storage medium can be executed by one or more processors, the above-described method can be implemented when the storage medium is used in a vehicle. The processor executes the programs stored in the memory to implement the above-described execution method.

[0138] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0139] It should be noted that the terms "one implementation," "embodiment," "exemplary embodiment," and "some embodiments" used in the specification indicate that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in connection with an embodiment, implementing such a feature, structure, or characteristic in conjunction with other embodiments, whether explicitly described or not, is within the knowledge scope of those skilled in the art.

[0140] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, or article that comprises a list of elements, or not only those elements, but also other elements not expressly listed, or elements inherent to such a process, method, or article. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, or article that includes said element.

[0141] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A vehicle communication method characterized by, The method, applied to a device management service running on an in-vehicle operating system, includes: When the vehicle operating system is started, obtain the various protocol applications installed in the vehicle operating system, and establish a communication channel with the protocol adapters in each of the protocol applications; When a device discovery event is received from any of the protocol adapters through the corresponding communication channel, the device information corresponding to the terminal device is determined from the device discovery event. The device discovery event is generated by the protocol adapter listening to the terminal device. The device information is displayed via a display device in the vehicle; When a connection trigger operation for the device information is detected, the first protocol application corresponding to the first protocol adapter of the terminal device communicates with the terminal device.

2. The vehicle communication method according to claim 1, characterized by, When the vehicle operating system is started, the method further includes: Create a UI resource pool, which is used to provide UI resources for the interactive interfaces of each of the protocol applications; The step of enabling the first protocol application corresponding to the first protocol adapter to communicate with the terminal device via the first protocol adapter corresponding to the terminal device further includes: A connection command is sent to the first protocol adapter corresponding to the terminal device, so that the first protocol application corresponding to the first protocol adapter establishes a communication connection with the terminal device through the first protocol adapter; After the first protocol application establishes a communication connection with the terminal device, a matching target interface resource is allocated to the first protocol application based on the interface resource pool. Based on the target interface resources, the target interactive interface corresponding to the first protocol application is displayed through the display device, so that the terminal device can interact and communicate with the first protocol application based on the target interactive interface and the first protocol adapter.

3. The vehicle communication method according to claim 2, characterized by, After displaying the target interactive interface, the method further includes: The system receives the operating status information reported by the first protocol adapter through the corresponding communication channel, and the operating status information corresponds to the terminal device. Based on the operating status information, the device status of the terminal device is updated; Based on the updated device information, the device status corresponding to the terminal device in the target interactive interface is updated through the display device to complete the update of the target interactive interface.

4. The vehicle communication method according to claim 2, characterized by, After displaying the target interactive interface, the method further includes: Upon receiving a communication disconnection event reported by the first protocol adapter for the terminal device, a communication disconnection command is sent to the first protocol adapter to cause the first protocol adapter to disconnect the communication connection between the first protocol application and the terminal device. Receive the disconnection execution result corresponding to the terminal device reported by the first protocol adapter; Based on the disconnection execution result, the target interactive interface is closed via the display device, and the target interface resources are recycled to the interface resource pool.

5. The vehicle communication method according to claim 4, characterized by, The step of sending a communication disconnect command to the first protocol adapter includes: When the communication disconnection event is used to indicate that the terminal device has abnormally disconnected communication, the disconnection reason code is determined from the communication disconnection event; Determine the duration of the disconnection of the terminal device, and determine the matching result between the disconnection reason code and the preset reason code set. The preset reason code set is used to indicate that the terminal device that has abnormally disconnected can restore the communication connection on its own. When the duration exceeds a preset duration threshold and / or the matching result is a failure, a communication disconnection command is sent to the first protocol adapter.

6. The vehicle communication method according to claim 1, characterized by, After the first protocol application communicates with the terminal device, the method further includes: When the newly added protocol application is installed in the vehicle operating system, obtain the newly added protocol adapter corresponding to the newly added protocol application; Establish the communication channel with the newly added protocol adapter; After establishing the communication channel with the newly added protocol adapter, the step of determining the device information corresponding to the terminal device from the device discovery event when receiving a device discovery event reported by any of the protocol adapters through the corresponding communication channel is executed.

7. The vehicle communication method according to claim 1, characterized by, The step of enabling the first protocol application corresponding to the first protocol adapter to communicate with the terminal device through the first protocol adapter corresponding to the terminal device includes: A connection command is sent to the first protocol adapter corresponding to the terminal device, so that the first protocol application corresponding to the first protocol adapter establishes a communication connection with the terminal device through the first protocol adapter; After the first protocol application establishes a communication connection with the terminal device, if a resource occupation request is received from the first protocol adapter through the corresponding communication channel, the target type of the resource occupied by the first protocol application is determined from the resource occupation request. When it is determined that at least one second protocol application exists in each of the protocol applications, the target priority corresponding to the first protocol application and each of the second protocol applications is determined, and the type of resource occupied by the second protocol application is the target type; Based on the respective target priorities, the resource occupancy request is responded to through the first protocol adapter, so that the first protocol application can communicate with the terminal device.

8. The vehicle communication method according to claim 1, characterized by, Establishing a communication channel with the protocol adapters in each of the aforementioned protocol applications includes: A communication channel is established with the protocol adapters in each of the aforementioned protocol applications through the Software Development Kit (SDK) interface.

9. A vehicle communication device, characterized by The device, which is used for device management services and runs on the vehicle's in-vehicle operating system, includes: The acquisition module is used to acquire each protocol application installed in the vehicle operating system when the vehicle operating system is started, and to establish a communication channel with the protocol adapter in each of the protocol applications. The determination module is used to determine the device information corresponding to the terminal device from the device discovery event when it receives a device discovery event reported by any of the protocol adapters through the corresponding communication channel. The device discovery event is generated by the protocol adapter listening to the terminal device. A display module is used to display the device information via a display device in the vehicle; The communication module is configured to, when a connection trigger operation for the device information is detected, enable a first protocol application corresponding to the first protocol adapter to communicate with the terminal device via the first protocol adapter corresponding to the terminal device.

10. A vehicle characterized by comprising: include: A processor and a memory, wherein the processor is configured to execute a vehicle communication program stored in the memory to implement the vehicle communication method according to any one of claims 1 to 8.

Images