Vehicle-mounted 3D application card drawing management method and system

Abstract

The invention discloses a vehicle-mounted 3D application card drawing management method, which comprises the following steps: when a vehicle-mounted system is started, registering a card management service interface of a card management service module into the system; after the 3D desktop application is started, providing a card host interface, acquiring a card management service interface, and sending the card host interface to a card management service module through the card management service interface so as to communicate with the 3D desktop application; the card management service module calls a card host interface to request the Surface from the 3D desktop application for all cards which do not request the Surface; after the 3D desktop receives the Surface request, a corresponding Surface object is created; the card management service module searches for the corresponding card application, then the Surface object is transmitted to the card application through the card callback interface, and the card application receives the Surface object and is connected to the native View system through the 3D card development module for card loading and drawing. According to the invention, a developer can easily add the 3D card function for the application program.

Description

Technical Field

[0001] The present invention relates to the field of intelligent vehicle-mounted technology, and in particular to a vehicle-mounted 3D application card drawing management method and system. Background Art

[0002] In automotive technology, the evolution of the in-car central control screen is particularly eye-catching, especially the automotive desktop application CarLauncher. It has evolved from a 2D model with basic functions and a single interface to a pseudo-3D interface with complex and diversified functions and 3D vehicle model simulation. With the development of automotive intelligence and interconnection, traditional desktop applications are gradually unable to meet users' visual experience needs, and customers expect more intelligent and personalized solutions.

[0003] Therefore, full 3D desktop applications came into being. This 3D desktop application provides users with a new sensory experience and a unique way of interaction, greatly enriching the interactive fun between users and in-vehicle terminals.

[0004] In the prior art, developers generally use native Android widgets (plugins) to create interactive mini card applications on the Launcher interface of the home screen to display real-time information and provide quick operations. These widgets can display various information, such as weather, calendar events, music control, and to-do lists. In order to create interactive mini card applications on the Launcher interface of the home screen, application developers need to create a class that inherits from AppWidgetProvider. This class acts as a broadcast receiver and is responsible for handling widget updates and user interactions. The specific solution is as follows:

[0005] In AppWidgetProvider, application developers can define the data update logic of the widget by overriding the onUpdate() method. At the same time, through the RemoteViews class, developers can design the layout and appearance of the widget and update the widget view through the AppWidgetManager when necessary.

[0006] When the user adds a widget to the home screen, the Launcher notifies the application's AppWidgetProvider through a broadcast mechanism to update it, ensuring that the widget can display the latest information in real time.

[0007] This solution, which relies on Android native widgets, is mainly used to provide information display and interactive functions on a 2D plane. It has certain limitations, especially the lack of support for 3D visual experience. Its limitations are as follows: 1. It uses RemoteViews to display views between processes, but RemoteViews only supports limited layouts and controls, such as not supporting WebView controls or RecyclerView. 2. Because it is updated through broadcasting, it cannot adapt to cards with high-frequency refresh requirements. 3. It does not support complex user interactions, such as long press events, touch events, etc. 4. It cannot adapt to 3D environments. The display of native widgets depends on the View system, and the View cannot be directly displayed in a 3D environment.

[0008] Therefore, the traditional CarLauncher interface can only display application icons and application plug-ins, which is difficult to meet users' needs for interactive operations and personalized experience. It is necessary to abandon the traditional solution that mainly displays application icons and instead support the technical solution of dynamic application card insertion, so as to achieve richer and more intuitive interactive elements. Summary of the invention

[0009] One of the purposes of the embodiments of the present invention is to provide a method and system for managing the drawing of in-vehicle 3D application cards, so that Android application cards can be seamlessly integrated into a 3D desktop environment and support a variety of customized interactive functions.

[0010] In order to solve the above technical problems, in a first aspect, an embodiment of the present invention provides a vehicle-mounted 3D application card drawing management method, the method comprising:

[0011] S1. When the vehicle-mounted system is started, the card management service process registers the card management service interface of the card management service module into the vehicle-mounted system;

[0012] S2. After the 3D desktop application is started, a card host interface is provided, and the card host interface is obtained and sent to a card management service module through the card management service interface to communicate with the 3D desktop application;

[0013] S3, the card management service module calls the request surface method in the card host interface to request the Surface from the 3D desktop application for all cards that have not requested the Surface;

[0014] S4. After receiving the Surface request, the 3D desktop application creates a corresponding Surface object according to the card type. The Surface object is first passed to the card management service module through the card management service interface. The parameters of the Surface object include the card token, Surface, and card size.

[0015] S5. The card management service module searches for the corresponding card application through the card token, and then passes the Surface object to the card application through the card callback interface. The card application receives the Surface object, connects to the native View system through the 3D card development module, and loads and draws the card.

[0016] Furthermore, before S2, the steps include:

[0017] S10, the 3D card development module sends the card data to the card management service module through the card management service interface, wherein the card data includes a card token, card information, a card callback interface, and a transmission channel InputChannel, the card token is used to uniquely identify the card, the card callback interface is used for the card management service module to communicate with the card application, and the transmission channel InputChannel is used to transfer events between the 3D desktop and the card application;

[0018] S11. After receiving the card data, the card management service module establishes a data interface, takes the card token as the key, and encapsulates the card token, card information, card callback interface and InputChannel into a card data structure and saves it.

[0019] Furthermore, the method also includes pre-querying the plug-in service of the card application:

[0020] S12, querying the WidgetService service information implemented by the card application through the card management service module, and starting the WidgetService service implemented by the card application;

[0021] S13. Obtain service information of the card application.

[0022] Preferably, the WidgetService service information includes card information and card view, and the card information includes card component, card title, card type, and card click intention.

[0023] Preferably, the step of connecting to the native View system through the 3D card development module to load and draw the card specifically includes:

[0024] The 3D card development module implements the WidgetRootImpl class, which inherits ViewParent and creates a root view FrameLayout. The card view View is added to the root view as a child View, and the root view sets ViewParent to the WidgetRootImpl object;

[0025] According to the Surface object, measure and layout the root view, refresh the card view, and draw it on the Surface.

[0026] Furthermore, the method further comprises:

[0027] The card management service module calls the register InputChannel method of the card host interface and passes the card token and InputChannel to the 3D desktop application;

[0028] After the 3D desktop application obtains the InputChannel, it establishes a communication channel for event data with the card application, converts the original event coordinate data from the screen coordinate system to the card coordinate system and passes it to the card application.

[0029] In a second aspect, an embodiment of the present invention further provides a vehicle-mounted 3D application card drawing management system, the system comprising: a 3D desktop application, a card application, a card management service module, and a 3D card development module, wherein:

[0030] The card management service module is used to provide a card management service interface. When the vehicle-mounted system is started, the card management service process registers the card management service interface of the card management service module with the vehicle-mounted system;

[0031] The 3D desktop application is used to provide a card host interface after being started, obtain the card host interface and send it to the card management service module through the card management service interface to communicate with the 3D desktop application;

[0032] The card management service module is also used to call the request surface method in the card host interface to request the Surface from the 3D desktop application for all cards that have not requested the Surface;

[0033] The 3D desktop is also used to create a corresponding Surface object according to the card type after receiving the Surface request. The Surface object is first passed to the card management service module through the card management service interface. The parameters of the Surface object include the card token, Surface and card size.

[0034] The card management service module is also used to find the corresponding card application through the card token, and then pass the Surface object to the card application through the card callback interface;

[0035] The 3D card development module is also used to connect the Surface object to the native View system when the card application receives the Surface object, so as to load and draw the card.

[0036] Furthermore, the 3D card development module is also used to send card data to the card management service module through the card management service interface, wherein the card data includes a card token, card information, a card callback interface, and a transmission channel InputChannel, the card token is used to uniquely identify a card, the card callback interface is used for the card management service module to communicate with the card application, and the transmission channel InputChannel is used to transfer events between the 3D desktop and the card application;

[0037] The card management service module is also used to establish a data interface after receiving the card data, using the card token as the key, and encapsulating the card token, card information, card callback interface and InputChannel into a card data structure and saving it.

[0038] In a third aspect, an embodiment of the present invention further provides a vehicle-mounted device, which includes a processor and a memory, wherein the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to call the program instructions to execute the method as described above.

[0039] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor or a computer, the processor executes the method as described above.

[0040] Compared with the prior art, the vehicle-mounted 3D application card drawing management method and system provided by the embodiment of the present invention has at least the following beneficial effects:

[0041] The technical solution of the embodiment of the present invention enables developers to easily add 3D card functions to applications, which not only improves the richness and interactivity of the user experience, but also provides unlimited possibilities for the personalization and innovation of applications. In addition, it also provides developers with an efficient and flexible development platform, enabling them to quickly respond to market changes and launch more attractive products. It has good scalability, can perfectly adapt to the 3D desktop systems of various car companies, and allows all applications to be displayed on the 3D desktop in the form of custom cards. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The preferred implementation modes will be described below in a clear and understandable manner with reference to the accompanying drawings to further illustrate the above-mentioned characteristics, technical features, advantages and implementation methods of the present invention.

[0043] Figure 1 This is a flow chart of a method for drawing and managing a vehicle-mounted 3D application card according to an embodiment of the present invention;

[0044] Figure 2 This is a schematic diagram of a vehicle-mounted 3D application card drawing management system according to an embodiment of the present invention;

[0045] Figure 3 A schematic diagram of the structure of an in-vehicle device for a method for managing in-vehicle 3D application card drawing according to an embodiment of the present invention. DETAILED DESCRIPTION

[0046] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings and other implementation methods can be obtained based on these drawings without creative work.

[0047] In order to simplify the drawings, only the parts related to the invention are schematically shown in each figure, and they do not represent the actual structure of the product. In addition, in order to simplify the drawings and facilitate understanding, in some figures, only one of the parts with the same structure or function is schematically drawn or marked. In this article, "one" not only means "only one", but also means "more than one".

[0048] The following mainly takes some specific embodiments as examples to describe in detail the implementation of the technical solution of the present invention.

[0049] like Figure 1 As shown, in order to achieve the purpose of the invention, an embodiment of the invention provides a vehicle-mounted 3D application card drawing management method, the method comprising:

[0050] S1. When the vehicle-mounted system is started, the card management service process registers the card management service interface of the card management service module into the vehicle-mounted system;

[0051] S2. After the 3D desktop application is started, a card host interface is provided, and the card host interface is obtained and sent to a card management service module through the card management service interface to communicate with the 3D desktop application;

[0052] S3, the card management service module calls the request surface method in the card host interface to request the Surface from the 3D desktop application for all cards that have not requested the Surface;

[0053] S4. After receiving the Surface request, the 3D desktop application creates a corresponding Surface object according to the card type. The Surface object is first passed to the card management service module through the card management service interface. The parameters of the Surface object include the card token, Surface, and card size.

[0054] S5. The card management service module searches for the corresponding card application through the card token, and then passes the Surface object to the card application through the card callback interface. The card application receives the Surface object, connects to the native View system through the 3D card development module, and loads and draws the card.

[0055] In an embodiment of the present invention, when the vehicle-mounted system is started, the card management service process is started synchronously. The card management service process is a card management service module, which implements the card management service interface and is directly started by the system. When the card management service process is started, the card management service interface is registered to the vehicle-mounted system, so that the card application and the 3D desktop application can obtain the card management service interface from the system.

[0056] Here, the 3D desktop application is a Home application. The native behavior of Android starts the 3D desktop application when the boot is completed. After the card management service module is started, a registration completion notification is sent to the 3D desktop application. The 3D desktop application can receive the notification and obtain the card management service interface.

[0057] After the 3D desktop application gets the card management service interface, it communicates with the card management service module. The 3D desktop application uses several functions of the card management service interface, such as deleting a card - parameter: card token; providing a card Surface - parameter: card token, Surface object, card size width and height; notifying the host (3D desktop application) of the preparation completion method - parameter: card host interface; 3D desktop display - parameter: none; 3D desktop hide - parameter: none; query all card information - parameter: none; return all card information.

[0058] The 3D desktop application notifies the card management service module: when the 3D desktop application is started, it notifies the card management service module that it has been started, and the card management service module can communicate with the 3D desktop application through the card host interface.

[0059] After the 3D desktop is started, an instantiated object of the card host interface is implemented, and the methods of the card host interface are implemented. The card host interface is used for the card management service module to communicate with the 3D desktop. The card host interface provides several functions: request Surface-parameters: card token and card type; register InputChannel-parameters: card token and InputChannel; set the card click intent method-parameters: card token and card click intent (Intent); release the card interface, parameter: card token.

[0060] When the 3D desktop implements the card host interface, it will call the card management service interface to pass the card host interface to the card management service module. The card management service module will request Surface for all cards that have not requested Surface through the card host interface, and call the request surface method in the card host interface to request Surface from the 3D desktop. After receiving the Surface request from the card management service module, the 3D desktop will create the corresponding Surface according to the card type, large card or small card.

[0061] The Surface object is created by the 3D desktop and is first passed to the card management service module through the card management service interface. The parameters passed include the card token, Surface, and the card width and height. The card management service module finds the corresponding card through the card token and then passes it to the card application through the card callback interface. The parameters passed include the Surface object and the Surface size width and height.

[0062] Furthermore, before S2, the steps include:

[0063] S10, the 3D card development module sends the card data to the card management service module through the card management service interface, wherein the card data includes a card token, card information, a card callback interface, and a transmission channel InputChannel, the card token is used to uniquely identify the card, the card callback interface is used for the card management service module to communicate with the card application, and the transmission channel InputChannel is used to transfer events between the 3D desktop and the card application;

[0064] S11. After receiving the card data, the card management service module establishes a data interface, takes the card token as the key, and encapsulates the card token, card information, card callback interface and InputChannel into a card data structure and saves it.

[0065] After the card management service interface is registered to the system, the 3D desktop, 3D card development module or card application can obtain the card management service interface from the system.

[0066] The 3D card development module implements adding cards through the card management service interface. Card addition is to send the card token, card information, card callback interface and InputChannel to the card management service module.

[0067] The 3D card development module (SDK) passes the card token, card information, card callback interface and InputChannel to the card management service through the card management service interface.

[0068] Here, the card token is a Binder object that uniquely identifies the card and will be used as the unique identifier of the card management service and the 3D desktop. The card information includes the card title, card click intent, card component (available in WidgetService), and card type. The card callback interface is a Binder callback interface used for communication between the card management service module and the card application. InputChannel is part of the Android input system, which provides a mechanism for passing input events between different processes (from the 3D desktop to the card application), such as touch events. In fact, the underlying implementation of InputChannel is a socketpair, which communicates via sockets. If the card application provides a card click intent, the passed InputChannel object is an empty object, and the 3D desktop no longer needs to pass touch events to the card application.

[0069] The card management service module receives the card data of the card application added from the 3D card development module through the card management service interface: card token, card information, card callback interface and InputChannel. At the same time, it will create a Map data interface with the card token as the key, and then encapsulate the card token, card information, card callback interface and InputChannel into a card data structure as the value and save it in the Map. Then it confirms whether there is a card host interface (the card host interface is implemented by the 3D desktop). If there is a card host interface, it will execute several requests:

[0070] Call the card host interface, pass the card token and card type to the 3D desktop, and request Surface;

[0071] If InputChannel is not a null object, the InputChannel is passed to the 3D desktop to establish a channel for touch events between the 3D desktop and the card application.

[0072] If the card application implements the card click intent in the card information, the card click intent is passed to the 3D desktop, which is used by the 3D desktop to execute the card click intent. If the request is executed at this time, a state value of surface requested will be set for the card. When the 3D desktop notifies the card management service module that it is ready (at this time, the host interface is called to communicate and interact with the 3D desktop), this state will be judged. If the card state does not request a surface, the request for the surface will be executed.

[0073] When adding a card, the 3D desktop is either ready or not (it can be understood as whether the 3D desktop is started). When the 3D desktop is already started, when adding a card, the card management service will apply for a Surface from the 3D desktop for the card (the request refers to the action of applying for a Surface). If the 3D desktop is not started, it will wait until the 3D desktop is started and then tell the card management service that the 3D desktop is already started. At this time, the card management service will apply for a Surface from the 3D desktop for the card. Whether the card has applied for a Surface, the card management service module will record a status for the card.

[0074] Furthermore, the method also includes pre-querying the plug-in service of the card application:

[0075] S12, querying the WidgetService service information implemented by the card application through the card management service module, and starting the WidgetService service implemented by the card application;

[0076] S13. The card management service module obtains service information of the card application.

[0077] After obtaining the service information of the card application, the card management service module will then start the services of all card applications.

[0078] When the card management service module is started, query and start the card service of the card application: the card application needs to implement the WidgetService (inherited from the WidgetService service) in the card development module. The WidgetService service information includes card information and card view. The card information includes card components, card titles, card types, and card click intents. In AndroidManifest.xml, the action of the intent is configured as android.action.launcher.widget for the implemented service. The native PackageManager will parse this action and save it when installing the card application.

[0079] The card management service module can query all the services implemented by the card by calling the PackageManager method through this action. That is, the card management service module calls the native PackageManager interface to query android.action.launcher.widget to find the service information of all card applications that implement WidgetService, thereby starting the card service of the application (the card management service module uses the package name and component name of the card application to start the WidgetService service implemented by the card application), that is, start the WidgetService service implemented by the card application.

[0080] That is, preferably, the WidgetService service information includes card information and card view, and the card information includes card view, card title, card type, and card click intention.

[0081] Obtaining WidgetService service information includes obtaining card information and card view, wherein the card information includes card title, card click intent, card component (obtainable from WidgetService), and card type.

[0082] The 3D card development module (SDK) obtains the card information and card view, wherein the card information is passed to the card management service module through the card management service interface, and the card view is saved by itself for drawing.

[0083] In the embodiment of the present invention, the application card needs to obtain the following information to implement the WidgetService service:

[0084] Get the card view (return type: View). This View determines how the card is displayed. Compared with the native widget mechanism of Android, the native widget mechanism only supports RemoteView, which limits the use of certain controls. However, the embodiment of the present invention has no limitation and can support the use of controls such as SurfaceView and WebView. Then the card can support playing videos or displaying web pages, etc.

[0085] Get the card title (return type: String). The card title is used to indicate the function of this card, which facilitates the visual management of the card later.

[0086] Method to get the card type (return type: int). There are two types of cards: BIG and SMALL. The 3D desktop will use this card type to allocate Surfaces of different sizes.

[0087] Get the card click intent (return type: Intent), which is optional. When this method is implemented, the 3D desktop will execute this intent after clicking the card. For example, when this card is used to display date and time, the card application implements this method and returns the intent to open the calendar application. When the user clicks this card, the 3D desktop will execute the opening of the calendar application. When this method returns null, it means that the card application will handle all click events on the card by itself, then the 3D desktop application will return all touch events to the card application.

[0088] Preferably, the step of connecting to the native View system through the 3D card development module to load and draw the card specifically includes:

[0089] The 3D card development module implements the WidgetRootImpl class, which inherits ViewParent and creates a root view FrameLayout. The card view View is added to the root view as a child View, and the root view sets ViewParent to the WidgetRootImpl object;

[0090] According to the Surface object, measure and layout the root view, refresh the card view, and draw it on the Surface.

[0091] After the card application obtains the Surface and width and height, it is connected to the native View system through the card development module (SDK). The implementation of the connection requires several steps:

[0092] The 3D card development module implements the WidgetRootImpl class to inherit ViewParent and creates a root view (FrameLayout). The card view (View) is added to the root view as a child View. The root view sets ViewParent to the WidgetRootImpl object, so that the WidgetRootImpl object can manage the card view (View). WidgetRootImpl can know when to refresh the card interface through the notification refresh method of ViewParent.

[0093] Through the card width and height parameters, the root view is measured. The default behavior of Android will set the width and height for the card view (View) and its subviews.

[0094] Through the card width and height parameters, the layout of the root view is initiated. The default behavior of Android will set the position for the card view (View) and its subviews.

[0095] After the layout of the root view is initiated, a refresh will be triggered. WidgetRootImpl knows that it is time to refresh and will draw on the Surface. After drawing on the Surface, the 3D desktop can get new drawings and update the card display.

[0096] Draw the card view on the Surface: Lock a Canvas from the Surface, and pass the Canvas to the root view by calling the View's draw method. Android's default behavior is to call the draw method for the card view (View) and its sub-Views to complete the drawing of the card view. After a round of drawing, unlock the canvas, and the drawn data will be automatically notified to the 3D desktop.

[0097] Surface is a producer and consumer model, with the card application as the producer and the 3D desktop as the consumer. When the canvas is unlocked, the 3D desktop can receive a new frame of data and update the card display.

[0098] Furthermore, the method further comprises:

[0099] The card management service module calls the register InputChannel method of the card host interface and passes the card token and InputChannel to the 3D desktop application;

[0100] After the 3D desktop application obtains the InputChannel, it establishes a communication channel for event data with the card application, converts the original event coordinate data from the screen coordinate system to the card coordinate system and passes it to the card application.

[0101] In a second aspect, an embodiment of the present invention further provides a vehicle-mounted 3D application card drawing management system, the system comprising: a 3D desktop application, a card application, a card management service module, and a 3D card development module, wherein:

[0102] The card management service module is used to provide a card management service interface. When the vehicle-mounted system is started, the card management service process registers the card management service interface of the card management service module with the vehicle-mounted system;

[0103] The 3D desktop application is used to provide a card host interface after being started, obtain the card host interface and send it to the card management service module through the card management service interface to communicate with the 3D desktop application;

[0104] The card management service module is also used to call the request surface method in the card host interface to request the Surface from the 3D desktop application for all cards that have not requested the Surface;

[0105] The 3D desktop is also used to create a corresponding Surface object according to the card type after receiving the Surface request. The Surface object is first passed to the card management service module through the card management service interface. The parameters of the Surface object include the card token, Surface and card size.

[0106] The card management service module is also used to find the corresponding card application through the card token, and then pass the Surface object to the card application through the card callback interface;

[0107] The 3D card development module is also used to connect the Surface object to the native View system when the card application receives the Surface object, so as to load and draw the card.

[0108] Furthermore, the 3D card development module is also used to send card data to the card management service module through the card management service interface, wherein the card data includes a card token, card information, a card callback interface, and a transmission channel InputChannel, the card token is used to uniquely identify a card, the card callback interface is used for the card management service module to communicate with the card application, and the transmission channel InputChannel is used to transfer events between the 3D desktop and the card application;

[0109] The card management service module is also used to establish a data interface after receiving the card data, using the card token as the key, and encapsulating the card token, card information, card callback interface and InputChannel into a card data structure and saving it.

[0110] The technical solution of the embodiment of the present invention includes: a 3D card development module, a card management service module, a card application that needs to display cards, and a 3D desktop application.

[0111] Among them, the 3D card development module provides a tool set SDK, so that application developers can integrate the cards of the card application into the 3D desktop environment. The card application developer needs to use the tool set (SDK) of the 3D card development module to implement a card base class Service inherited from the SDK.

[0112] The card application here refers to the application that implements the card function, such as music application, weather application, etc. For example, if you want to display the playing music card in the 3D desktop, the music application needs to use the SDK. For example, if you want to display the weather card, the weather application needs to use the SDK.

[0113] The card base class Service defines some interfaces, such as: card view interface, click card behavior interface.

[0114] If a card application wants to customize a card, it must inherit the card base class Service and implement these interfaces, such as:

[0115] To implement the card view interface, the application needs to return a View object;

[0116] To implement the card click behavior interface, you need to provide an Intent object, etc.

[0117] The developer of the card application needs to obtain the card view interface in the card base class Service, return a View object, and then draw this View object on the Surface, and finally display it on the 3D desktop. The view content of this View object is drawn on the Surface provided by the 3D desktop application, so that the View view can be seamlessly integrated into the 3D desktop.

[0118] At the same time, card application developers also need to use the tool set (SDK) of the 3D card development module and the card host interface of the 3D desktop application. The card host interface is used to provide the Surface objects required to draw the cards of the card application and establish communication with user input events.

[0119] Here, the underlying implementation of the channel for transmitting input events between the 3D desktop and the card application is socket communication.

[0120] After the card of the card application is displayed in the 3D desktop, when the user clicks on the card, the system will dispatch the click event to the 3D desktop, and the 3D desktop will pass the data of the click event (after coordinate conversion) to the application through the socket communication channel.

[0121] The 3D card development module also communicates with the card application through the card callback interface, ensuring that the card application can receive event notifications in a timely manner. In addition, it also interacts with the 3D desktop through the card host interface to manage the state of the widget and ensure the continuity and consistency of the user experience.

[0122] The 3D card management service module is used to manage card information and implement card addition, deletion, display and hiding.

[0123] In the specific implementation, when the vehicle system is turned on, the resident process corresponding to the 3D card management service module will be started first. After the card management service process is started, the card management service will be registered. Registering the card management service means that the card management service process calls addService to add the card management service interface to the system. Then the application and 3D desktop can use getService to get the card management service interface. The card application and 3D desktop access the card management service through the card management service interface.

[0124] Here, the card management service interface is a binder interface. The card management service implements this interface to manage card information and card addition, deletion, display, and hiding. The card management service interface is used to communicate with the card management service in the SDK. The SDK code runs in the card application and 3D desktop processes. The calls to the card management service interface are all in the SDK. These interfaces will not be used directly for application and 3D desktop development.

[0125] When the vehicle system is started, the system starts the 3D desktop application by default. After the 3D desktop is started, it will notify the card management service module through the card management service interface that it is ready to provide Surface.

[0126] The card management service module scans all card applications that implement card basic services. These card applications, such as music applications, weather music, alarm clock card applications, etc., may display cards on the 3D desktop. They need to inherit the card base class Service and implement the card view interface, and the card management service module starts these applications.

[0127] The card application inherits the card base class Service, and configures a specific action in AndroidManifest.xml. By calling the PackageManager interface and passing this action, all the card services of the application can be scanned out.

[0128] After the card application is started, add a card through the card management service interface, and pass the card's unique identification token, card information, card callback interface, and InputChannel to the card management service module. The card management service module will apply for a Surface from the 3D desktop for the added card. After the card management service module obtains the Surface, it will pass it to the card application through the card callback interface. After the card application receives the Surface from the 3D desktop, it will draw on the Surface, and the drawn content will be displayed on the 3D desktop.

[0129] The card information includes the card type (large card, small card) to apply for Surfaces of different sizes.

[0130] The card callback interface is used to receive the Surface passed back from the 3D desktop and obtain the card's state change (show or hide). If the 3D desktop is ready to provide Surface when the card application is added, the card management service module will immediately apply for Surface from the 3D desktop.

[0131] The card callback interface is defined by the SDK of the 3D card development module. The card callback interface calls back the card status to the card application. For example, when a user starts a 3D game, the 3D desktop retreats to the background. At this time, all other card applications need to be notified. These card applications display the cards, but the cards of these other card applications will be hidden at this time, and these cards do not need to be drawn.

[0132] InputChannel is used to establish a touch event channel between the card application and the 3D desktop. When the 3D desktop receives the touch event, it converts the coordinate system of the screen 3D desktop into the coordinate system of the corresponding card and passes it to the card application.

[0133] Different from the conventional method that relies on the SurfaceFlinger process to obtain the Surface for drawing, the embodiment of the present invention directly obtains the Surface from the 3D desktop application to achieve a more efficient rendering process.

[0134] The card drawing of the embodiment of the present invention is implemented through the WidgetRootImpl class in the 3D card development module: as the root management class of the view system, it plays a bridging role, so that the card view (the view displayed by the card, which determines the display content of the card) can be seamlessly integrated and use the system's native View component.

[0135] WidgetRootImpl is a key class in the 3D card development module, which connects to the native View system to enable the drawing, refreshing and event dispatching of various controls to work normally.

[0136] This seamlessness refers to the development of the application. When implementing the card view, you can use the native View mechanism and define it freely, just like developing an interface. You can use the XML layout file to define the display of the card view, etc. In addition, the WidgetRootImpl class is also responsible for creating the root view, aggregating all the card views into it, and ensuring that they can be correctly mapped to the Surface obtained from the 3D desktop, so as to be presented in the user interface. The WidgetRootImpl class also has functions such as input event distribution and View refresh, providing users with a smooth and interactive experience.

[0137] The card drawing process is mainly implemented in the WidgetRootImpl component. After obtaining the Surface and its size information, the WidgetRootImpl component will be responsible for accurate measurement and layout of the View to ensure the beauty and functionality of the user interface.

[0138] After the layout is determined, the WidgetRootImpl class will trigger the drawing action of the View and render the interface elements onto the Surface.

[0139] In addition, the card application can trigger WidgetRootImpl to redraw the View by actively requesting a refresh (invalidate) in response to user interaction or data updates, thereby ensuring the real-time and consistency of the user interface.

[0140] Implementation steps:

[0141] 1.WidgetRootImpl needs to inherit the ViewParent interface and implement the methods of the interface in ViewParent to respond to various requests and events of child views. ViewParent is a native class of Android with many methods. The child here is relative to ViewParent, and the view is the view of the card.

[0142] 2.WidgetRootImpl creates a root View of ViewGroup type, and the card view View provided by the application will be added to this root View: In the SDK, the card view provided by the application is added to this root View.

[0143] WidgetRootImpl directly connects to this root View instead of the card View provided by the application. For example, when WidgetRootImpl receives a click event, it will pass the event to the root View, and the root View will pass the event down layer by layer.

[0144] 3.WidgetRootImpl is also responsible for drawing. It saves the Surface from the 3D desktop, obtains a Canvas object through the Surface.lockCanvas method, calls the draw method of the root View, and passes the canvas parameter, then it connects to the native View drawing mechanism.

[0145] The native drawing mechanism will draw all subviews in sequence. When the drawing is completed, call the Surface.unlockCanvasAndPost method, and the 3D desktop can get the drawn image to display.

[0146] 4. WidgetRootImpl creates a Choreographer for interface refresh, coordination of UI rendering and animation execution. Its role is to ensure that the application's interface rendering and animation are performed at the right time to achieve a smooth user experience.

[0147] 5. WidgetRootImpl creates a pair of InputChannels, one of which is passed to the 3D desktop for sending touch events. WidgetRootImpl implements an InputEventReceiver associated with the InputChannel to receive touch events.

[0148] When a touch event is received, the dispatchTouchEvent method of the root View will be called, and the native View touch event dispatching mechanism will be connected.

[0149] In summary, the 3D desktop of the embodiment of the present invention not only inherits the display function of the traditional desktop application icons, but also provides a rich interface for application developers, so that applications can be directly integrated into the vivid scene of the 3D model desktop in the form of custom cards. These applications can be playing music cards, real-time updated weather cards, and dynamic clock cards.

[0150] The embodiment of the present invention provides such an innovative 3D card plug-in technical solution, providing a simple and efficient access solution for applications. At the same time, the embodiment of the present invention also redesigns and optimizes the underlying card application control and interaction methods to ensure that they can seamlessly adapt to the 3D desktop environment.

[0151] Through the technical solution of the embodiment of the present invention, Android applications can customize and display required cards, allowing users to enjoy a smooth and intuitive operating experience on the new 3D desktop.

[0152] In the system embodiment, its implementation method is the same as the method implementation method, and will not be repeated here.

[0153] In a third aspect, an embodiment of the present invention further provides a vehicle-mounted device, which includes a processor or a calculator and a memory, wherein the memory is used to store a computer program, and the computer program includes program instructions, and the processor or calculator is configured to call the program instructions to execute the method as described above.

[0154] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor or a computer, the processor or the computer executes the method as described above.

[0155] like Figure 3 As shown, an embodiment of the present application provides a vehicle-mounted device, the vehicle-mounted device 1000 includes a processor or a calculator (not shown in the figure) 1001 and a memory 1002, and the processor or calculator 1001 and the memory 1002 can be interconnected through a communication bus 1003. The communication bus 1003 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 1003 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the memory 1002 is used to store a computer program, and the computer program includes program instructions. The processor 1001 is configured to call the program instructions, and the above program includes a method for executing some or all of the steps in the aforementioned method.

[0156] The processor 1001 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the above program.

[0157] The memory 1002 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor via a bus. The memory may also be integrated with the processor.

[0158] The electronic device 1000 may further include a communication module 1004 and a display 1005. The communication module 1004 may be connected to the optical tracking device for communication. The communication module 1004 may be a wireless communication module (eg, a WiFi module, a Bluetooth module, etc.) or a wired communication module.

[0159] In addition, the electronic device 1000 may also include common components such as a communication interface (eg, a USB interface, a microphone interface, etc.), an antenna, etc., which will not be described in detail here.

[0160] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0161] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0162] In the several embodiments provided in the present application, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are only schematic, such as the division of the units, which 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 integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0163] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0164] In addition, the functional units in the various embodiments of the application may be integrated into one processing unit, or each unit may exist physically separately, 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 software program modules.

[0165] If the integrated unit is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a memory, including a number of instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned memory includes: U disk, read-only memory (ROM), random access memory (RAM), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0166] A person skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable memory, which can include: a flash drive, a read-only memory, a random access memory, a magnetic disk or an optical disk, etc.

[0167] The embodiments of the present application are introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

[0168] It should be noted that the above embodiments can be freely combined as needed. The above are only preferred embodiments of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be regarded as the protection scope of the present invention.

Claims

1. A method for managing the drawing of an in-vehicle 3D application card, characterized in that: The method comprises: S1. When the vehicle-mounted system is started, the card management service process registers the card management service interface of the card management service module into the vehicle-mounted system; S2. After the 3D desktop application is started, a card host interface is provided, and the card host interface is obtained and sent to a card management service module through the card management service interface to communicate with the 3D desktop application; S3, the card management service module calls the request surface method in the card host interface to request the Surface from the 3D desktop application for all cards that have not requested the Surface; S4. After receiving the Surface request, the 3D desktop application creates a corresponding Surface object according to the card type, and the Surface object is passed to the card management service module through the card management service interface. The parameters of the Surface object include the card token, Surface, and card size. S5. The card management service module searches for the corresponding card application through the card token, and then passes the Surface object to the card application through the card callback interface. The card application receives the Surface object, connects to the native View system through the 3D card development module, and loads and draws the card.

2. The vehicle-mounted 3D application card drawing management method according to claim 1, characterized in that: S2 also includes the following steps: S10, the 3D card development module sends the card data to the card management service module through the card management service interface, wherein the card data includes a card token, card information, a card callback interface, and a transmission channel InputChannel, the card token is used to uniquely identify the card, the card callback interface is used for the card management service module to communicate with the card application, and the transmission channel InputChannel is used to transfer events between the 3D desktop and the card application; S11. After receiving the card data, the card management service module establishes a data interface, takes the card token as the key, and encapsulates the card token, card information, card callback interface and InputChannel into a card data structure and saves it.

3. The vehicle-mounted 3D application card drawing management method according to claim 2, characterized in that: The method further includes pre-querying the plug-in service of the card application, specifically including: S12, the card management service module queries the WidgetService service information implemented by the card application, and starts the WidgetService service implemented by the card application; S13. The card management service module obtains service information of the card application.

4. The vehicle-mounted 3D application card drawing management method according to claim 1, characterized in that: The WidgetService service information includes card information and card view, and the card information includes card component, card title, card type, and card click intention.

5. The vehicle-mounted 3D application card drawing management method according to claim 4, characterized in that: The process of connecting the 3D card development module to the native View system and loading and drawing the card specifically includes: The 3D card development module implements the WidgetRootImpl class, which inherits ViewParent and creates a root view FrameLayout. The card view View is added to the root view as a child View, and the root view sets ViewParent to the WidgetRootImpl object; According to the Surface object, measure and layout the root view, refresh the card view, and draw it on the Surface.

6. The vehicle-mounted 3D application card drawing management method according to claim 4, characterized in that: The method further comprises: The card management service module calls the register InputChannel method of the card host interface and passes the card token and InputChannel to the 3D desktop application; After the 3D desktop application obtains the InputChannel, it establishes a communication channel for event data with the card application, converts the original event coordinate data from the screen coordinate system to the card coordinate system and passes it to the card application.

7. A vehicle-mounted 3D application card drawing management system, characterized in that: The system includes: 3D desktop application, card application, card management service module, 3D card development module, wherein: The card management service module is used to provide a card management service interface. When the vehicle-mounted system is started, the card management service process registers the card management service interface of the card management service module with the vehicle-mounted system; The 3D desktop application is used to provide a card host interface after being started, obtain and send the card host interface to the card management service module through the card management service interface to communicate with the 3D desktop application; The card management service module is also used to call the request surface method in the card host interface to request the Surface from the 3D desktop application for all cards that have not requested the Surface; The 3D desktop is also used to create a corresponding Surface object according to the card type after receiving the Surface request. The Surface object is first passed to the card management service module through the card management service interface. The parameters of the Surface object include the card token, Surface and card size. The card management service module is also used to find the corresponding card application through the card token, and then pass the Surface object to the card application through the card callback interface; The 3D card development module is also used to connect the Surface object to the native View system when the card application receives the Surface object, so as to load and draw the card.

8. The vehicle-mounted 3D application card drawing management system according to claim 7, characterized in that: The 3D card development module is also used to send card data to the card management service module through the card management service interface, wherein the card data includes a card token, card information, a card callback interface and a transmission channel InputChannel, the card token is used to uniquely identify the card, the card callback interface is used for the card management service module to communicate with the card application, and the transmission channel InputChannel is used to transfer events between the 3D desktop and the card application; The card management service module is also used to establish a data interface after receiving the card data, using the card token as the key, and encapsulating the card token, card information, card callback interface and InputChannel into a card data structure and saving it.

9. A vehicle-mounted device, characterized in that: The method comprises a processor and a memory, wherein the memory is used to store a computer program, the computer program comprises program instructions, and the processor is configured to call the program instructions to execute the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor, the processor or the computer executes the method according to any one of claims 1 to 6.

Images