Vehicle machine operating system
Through the vehicle SDK of the vehicle OS, the unified management of account binding and unbinding of the three-party applications has been solved, and the problem of low account authentication efficiency in the existing technology has been solved, and unified and efficient management of account binding has been achieved.
Patent Information
- Application Number
- CN202510203256.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-24
- Publication Date
- 2025-05-16
AI Technical Summary
When using three-party applications, existing vehicle-side applications need to be authenticated separately, resulting in low efficiency and complexity in login and logout operations.
It provides a vehicle computer operating system, which can uniformly manage the account binding and unbinding of the three-party applications through the vehicle computer SDK, and store the storage system in the vehicle computer cloud to reduce the workload of the three-party application development.
It realizes unified binding and unbinding between car-door accounts and three-party application accounts, improves access efficiency, reduces the development workload of three-party applications, and realizes unified binding interface.
Smart Images
Figure CN120017390A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of vehicle Internet of Things interaction, and specifically relates to a vehicle computer operating system. Background Art
[0002] As vehicle-side applications become increasingly diverse, more and more third-party applications with independent user authentication systems are beginning to be integrated and released on the vehicle side. When users use these applications, they need to log in and out separately for each user authentication system, which is not only inefficient but also complex to operate.
[0003] At present, the more mature implementation scheme is that the vehicle-side application encapsulates and integrates the SDK (Software Development Kit) provided by the third-party application, and then calls the third-party cloud through the SDK provided by the third party to bind and unbind the account. The binding relationship is also stored in the third-party cloud, or the SDK is notified to the vehicle-side application through local storage after the third-party cloud binding or unbinding is successful, or the vehicle-side application is directly synchronized to the vehicle-side cloud through cloud-to-cloud after the third-party cloud is bound or unbinded. When binding, the vehicle-side application pulls up the login (binding) page of each third party. When unbinding, the unbinding method corresponding to the SDK of each third party is called to unbind, and then the third-party application monitors the login / logout status of the vehicle-side application, and then logs in and out of the third-party application, which greatly affects the access efficiency. Summary of the invention
[0004] In view of the shortcomings of the prior art mentioned above, the purpose of the present invention is to provide a vehicle operating system that uniformly stores storage relationships in the vehicle cloud, so that when third-party applications need to obtain binding relationships, they can uniformly obtain them from the vehicle technology cloud through the vehicle SDK, thereby reducing the workload of third-party application development.
[0005] To achieve the above-mentioned purpose and other related purposes, the present invention provides a car operating system, including: at least one third-party application, a car account application, a car cloud, and a car SDK; the car account application is used to call the account information of the third-party application bound to the current login account of the vehicle from the car cloud according to the application information of the third-party application, so as to display the account binding status of the third-party application, and provide a trigger interface for the corresponding account binding function and account unbinding function; wherein, when the user triggers the account binding function of any third-party application, the car account application is used to The vehicle-mounted SDK is called to obtain the account information of the currently logged-in account of the third-party application, and the information is fed back to the user for confirmation, so that after the user confirms, the currently logged-in account on the vehicle side and the currently logged-in account on the third-party application are bound and stored in the vehicle-mounted cloud, and the account binding status of the currently logged-in account on the vehicle side regarding the third-party application is updated; when the user triggers the account unbinding function of any third-party application, the vehicle-mounted account application is used to unbind the currently logged-in account on the vehicle side and the account bound to it by the third-party application, and update the account binding status of the currently logged-in account on the vehicle side regarding the third-party application.
[0006] According to a specific embodiment of the present invention, the third-party application is used to call the vehicle SDK to query the account binding status of the current login account on the vehicle side with respect to the third-party application, and when the current login account on the vehicle side is bound to the account information about the third-party application, the bound account is kept synchronized with the current login account on the vehicle side.
[0007] According to a specific embodiment of the present invention, when the currently logged-in account on the vehicle side logs out, the third-party application is used to verify whether the currently logged-in account is consistent with the account bound to the third-party application on the vehicle side, and synchronously logs out of the currently logged-in account after confirming the consistency.
[0008] According to a specific embodiment of the present invention, when an account is currently logged in on the vehicle side, the third-party application is used to obtain the account information bound to the third-party application for the current logged-in account on the vehicle side, and feed back to the user to confirm whether to log in quickly.
[0009] According to a specific embodiment of the present invention, each third-party application is configured with unique metadata allocated by the vehicle side, and a Service of a specific action; wherein the vehicle account application reads the metadata and Service of each third-party application according to the system's configuration table for the Service, and obtains the package name and meta-data value corresponding to the third-party application based on it, so as to query the application information of the third-party application from the system.
[0010] According to a specific embodiment of the present invention, when the user triggers the account binding function, the vehicle account application is also used to identify whether the third-party application is started: if not, the third-party application is launched through the Service of the third-party application.
[0011] According to a specific embodiment of the present invention, when the user triggers the account binding function, the vehicle computer account application is also used to identify whether the third-party application currently has an account logged in: if not, the vehicle computer SDK is called to request the third-party application to provide a corresponding login shortcut, and feedback is given to the user for login, so as to obtain the account information currently logged in to the third-party application after the user logs in.
[0012] According to a specific embodiment of the present invention, when the user triggers the account binding function, the vehicle account application is also used to call the vehicle SDK to request the third-party application to provide a corresponding login shortcut based on the binding change instruction triggered by the user, and feedback to the user for re-login, so as to obtain the new login account information of the third-party application after the user re-logins.
[0013] According to a specific embodiment of the present invention, the vehicle machine account application is also used to call the vehicle machine SDK to notify the third-party application of the corresponding binding result or unbinding result.
[0014] According to a specific embodiment of the present invention, the following interfaces are defined in the vehicle SDK: an interface for obtaining binding information, and the vehicle account application calls the interface for obtaining binding information to obtain the account information currently logged in to the third-party application; an interface for obtaining binding change information, and the vehicle account application calls the interface for obtaining binding change information to request the third-party application to provide a corresponding login shortcut, and obtains the account information newly logged in to the third-party application after the user re-logins; an interface for obtaining binding list, and the third-party application obtains the account binding status of the vehicle-side current login account about the third-party application and the corresponding bound account through the interface for obtaining binding list; a callback interface for changing binding relationship status, and the vehicle account application is used to notify the third-party application through the callback interface for changing binding relationship status after the account binding status with the third-party application changes; an interface for logging in and out of accounts, and the vehicle account application is used to notify the third-party application through the interface for logging in and out of the vehicle-side account, so that the third-party application and the account bound to the vehicle-side current login account and the vehicle-side current login account can keep synchronous login or synchronous logout.
[0015] The present invention provides a vehicle computer operating system, which ensures that the binding relationship between the vehicle-side account and the third-party application account is unified and uniquely stored in the vehicle computer cloud. Even if the vehicle is changed or the factory settings are restored, the corresponding bound third-party application account can be obtained according to the vehicle-side account.
[0016] At the same time, third-party applications are no longer required to provide SDKs for account binding and account unbinding, reducing the development workload of third-party applications.
[0017] In addition, the binding interface has been unified, and there is no need to maintain a third-party binding interface jump list. The currently bound third-party applications can be displayed dynamically, and the third-party applications can be launched and offline at any time without modifying any code. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Figure 1 A schematic diagram of the structure of a specific embodiment of a vehicle operating system provided by the present invention; Figure 2 A schematic diagram of a specific embodiment of the process of dynamically obtaining a three-party application binding list provided by the present invention; Figure 3 A schematic diagram of a specific embodiment of a process for binding a third-party application account provided by the present invention; Figure 4 A schematic diagram of a specific embodiment of the process of unbinding a third-party application account provided by the present invention; Figure 5 This is a flowchart of a specific embodiment of the three-party application simultaneous login and logout provided by the present invention. DETAILED DESCRIPTION
[0019] In order to facilitate understanding of the present application, the present application will be described more fully below with reference to the relevant drawings. Embodiments of the present application are provided in the drawings. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, the purpose of providing these embodiments is to make the disclosure of the present application more thorough and comprehensive.
[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.
[0021] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.
[0022] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it is obvious to those skilled in the art that the embodiments of the present invention can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present invention difficult to understand.
[0023] First of all, it should be explained that in order to enable people in this technical field to better understand the present application scheme, the technical background of this application is explained accordingly.
[0024] At present, the binding / unbinding functions of the vehicle-side account and the third-party account are basically implemented by the third party, and accordingly, the binding relationship is also stored in the cloud of each third party. Usually, on the one hand, each time the vehicle-side application binds or unbinds the third-party application, it synchronizes with the third-party cloud through its corresponding cloud, so there are two copies of the binding relationship, and it is necessary to verify whether the synchronization is successful to ensure the consistency of the binding relationship. If the synchronization fails, it is necessary to execute the subsequent synchronization mechanism, and the cloud of the vehicle-side application needs to adapt the relevant data of the binding relationship before it can be stored. On the other hand, after the vehicle-side application is bound or unbound to the third-party application, the binding relationship is completely uniformly obtained from the third party, and the vehicle-side and its corresponding cloud are not stored. Therefore, each time the relevant data of the binding relationship is pulled, the cloud of the vehicle-side application needs to access the clouds of all supported third-party applications, and then encapsulate the data, and the access efficiency is low.
[0025] Secondly, if the binding page is provided by a third-party application and the vehicle-side application jumps when the user triggers the binding, then the vehicle-side application needs to maintain a jump method list. When a third-party application is added or the jump method of the third-party application is changed, the code of the vehicle-side application needs to be modified again, which has a high maintenance cost. In addition, the binding page style and form of each third-party application are different. For example, some pull up a pop-up window, and some pull up a page, which cannot be well unified.
[0026] At the same time, when the third-party application of the newly added independent user authentication system is not configured with an SDK for binding or unbinding, the third-party application must provide a related SDK to support the binding or unbinding function, which will increase a lot of workload. When the third-party application is configured with an SDK for binding or unbinding, each time the vehicle-side application accesses a third-party application, it needs to access a new SDK for packaging. Due to the various forms of SDK, the vehicle-side application needs to adapt these SDKs one by one. In addition, when the third-party applications integrated after the new car model or version iteration are different, if the SDK integration function is not deleted, the vehicle-side application will redundantly integrate unnecessary SDKs. If the SDK is deleted, it cannot be made into a universal vehicle-side application, resulting in high maintenance costs.
[0027] In addition, when the vehicle-side application or the corresponding cloud configures a third-party application that can be bound to the same version of a vehicle model, as the number of vehicle models increases and newly released iterative versions increase, the number of configuration items that need to be maintained continues to increase, making it more prone to errors. Therefore, in order to solve the problem of storing binding relationships in various third-party applications, this application will uniformly store the storage relationships in the cloud of the vehicle-side application, so that when the third-party application needs to obtain the binding relationship, it can be obtained from the cloud of the vehicle-side application through the provided vehicle-side SDK.
[0028] To address the issue of inconsistent binding interfaces, the vehicle-side application can be developed uniformly. Each third-party application only needs to provide the binding data for display to the vehicle-side SDK, so there is no need to maintain a jump method list.
[0029] In response to the problem that when a third-party application with an independent user authentication system is added and the third-party application does not provide a binding and unbinding SDK, the vehicle side can provide a unified standardized access SDK. The third-party application or the cloud of the third-party application no longer needs to develop an SDK that supports the corresponding binding or unbinding functions. It is also no longer necessary to access and encapsulate various third-party SDKs to complete the binding or unbinding functions, so that a universal version can be implemented to complete the binding or unbinding functions of various third-party applications.
[0030] To address the issue of differences in third-party applications caused by different car models or different versions of the same car model, the vehicle-side application dynamically obtains the list of supported binding / unbinding by reading the Manifest files of each third-party application in the current system ROM (read-only memory), without the need to maintain any additional configuration items.
[0031] For details, please see Figure 1 The vehicle operating system shown includes: at least one third-party application 10, a vehicle account application 20, a vehicle cloud 30, and a vehicle SDK. Among them, the vehicle account application 20 is the corresponding account that the car owner needs to register or log in to when using the vehicle terminal of the vehicle, so as to record the relevant data of the car owner during the use of the vehicle terminal. Therefore, when the login account of the third-party application is bound to the vehicle login account (the account logged in by the vehicle account application), the corresponding third-party application can be directly logged in to the current login account of the vehicle, thereby reducing unnecessary operations of the car owner and improving his car experience.
[0032] In this embodiment, the binding relationship between the account logged in at the vehicle end and the account logged in to the third-party application is uniformly stored in the vehicle-mounted cloud 30. When the third-party application needs to obtain the relevant binding relationship for quick login, the vehicle-mounted account application 20 can obtain it from the vehicle-mounted cloud 30 and provide an interface to the third-party application 10 for calling through the standardized SDK on the vehicle end, that is, the vehicle-mounted SDK. As a result, there is no need for any form of communication between the vehicle-mounted cloud 30 and the third-party cloud, and there is no need for the third-party application to provide an SDK for the binding or unbinding function. A unified standardized SDK is formed at the vehicle end.
[0033] In a specific embodiment, the third-party application needs to configure a unique meta-data assigned by the vehicle end and a Service with a specific action in the Manifest.xml file in the application local. Correspondingly, as Figure 2 shown, the vehicle-mounted account application 20 can read the meta-data and Service of each third-party application from the configuration table of the Service stored in the system ROM through the queryIntentServiceAsUser method in the PackageManger, and obtain the package name and the value of the meta-data of the third-party application according to it. Furthermore, the application information of the third-party application (information such as icon and application name that can be read through the system configuration) can be obtained through the package name. Finally, the account information of the currently logged-in account at the vehicle end for the bound third-party application is called from the vehicle-mounted cloud 30 using the application information of the third-party application, so as to form a corresponding third-party application binding list and display it to the user. Here, it can be understood that the third-party application binding list shows the bound third-party applications and provides an interface for the corresponding account unbinding function, as well as the unbound third-party applications and provides an interface for the corresponding account binding function.
[0034] In this regard, the meta-data can be configured in the following manner: <meta-data android:name="key defined by the vehicle end" android:value="unique meta-data assigned by the vehicle end" / > The Service can be configured in the following manner: <service android:name=".XXXService" android:exported="true"> <intent-filter><action android:name="Specific action defined at the vehicle end" / >< / intent-filter> It should also be added that the Service of a specific action configured in a third-party application can support the situation where accounts of different third-party applications with the same package name are bound to the same vehicle-side account. Specifically, different third-party applications can be defined separately through meta-data + third-party package name + the uniqueness of the third-party ID, thereby supporting the situation where different third-party applications with the same package name need to be bound separately.
[0035] In addition, only when a third-party application is installed in the system and a Service with a specific action is configured in the third-party application, can the vehicle account application 20 read the configuration table about the Service stored in the system ROM and dynamically display the account binding status of the third-party application, that is, display it through the third-party application binding list.
[0036] Based on the above, the account binding process for third-party applications is as follows: like Figure 3 As shown, when the user triggers the account binding function of the third-party application (it can be a button or other forms of UI, which is formulated according to the interactive method and is not limited to this), first, it is necessary to determine whether the third-party application is pulled up, that is, whether it is started. If the third-party application has not been started, the car account application 20 can pull up the application through the Service of the specific action of the third-party application. When the third-party application is started, the car account application 20 can obtain the account information currently logged in to the third-party application through the interface pre-defined in the car SDK, including the unique ID of the account, the token information used for subsequent login and exit (the token information is customized by each third party, and the subsequent third parties need to use these token information to log in or log out), nickname, avatar, token expiration time, binding agreement, etc. Of course, if the third-party application is not currently logged in with a corresponding account, the car account application 20 can request the third-party application to provide a corresponding login shortcut through the interface pre-defined in the car SDK, and feedback to the user for login, such as a QR code for login, and display it to the user so that the user can log in by scanning the code on the mobile app. When the user successfully logs in, the third-party application calls the vehicle SDK to notify the vehicle account application 20 that it can be bound, and the corresponding vehicle account application 20 continues to obtain the account information currently logged in by the third-party application through the above interface. Among them, if the user fails to log in, the third-party application notifies the vehicle account application 20 of the login failure and the reason for the failure through the vehicle SDK, and then the vehicle account application 20 uniformly prompts the user.
[0037] Finally, the vehicle account application 20 binds the account of the third-party application with the account currently logged in on the vehicle side according to the account information of the third-party application obtained. After the binding is successful, the binding success result will be notified to the third-party application through the interface pre-defined in the vehicle SDK, and the vehicle account application 20 will prompt the user that the binding is successful. When the binding fails, the binding failure result will be notified to the third-party application through the interface pre-defined in the vehicle SDK, and the vehicle account application 20 will prompt the user of the binding failure and the reason. At the same time, the vehicle account application 20 will also store the account currently logged in on the vehicle side and the account of the third-party application to which it is bound to the vehicle cloud 30, and update the account binding status of the third-party application accordingly, and replace the interface that triggers the account binding function with the interface of the account unbinding function.
[0038] In addition, in the above process, if the current third-party application has an account logged in, but the user wants to change to another account, then the vehicle account application 20 will request the third-party application to provide the corresponding login shortcut through the interface pre-defined in the vehicle SDK based on the user-triggered binding instruction, and feedback to the user for re-login, so that after the user re-logins, the third-party application's newly logged-in account information can be obtained through the interface pre-defined in the vehicle SDK for subsequent account binding.
[0039] Furthermore, the account unbinding process for third-party applications is as follows: like Figure 4 As shown, when the user triggers the account unbinding function of the third-party application, the vehicle account application 20 can call the corresponding unbinding interface from the vehicle cloud 30 to unbind the current login account on the vehicle side from the account bound to the third-party application, and after the unbinding is successful, update the account binding status of the current login account on the vehicle side with respect to the third-party application, and replace the interface that triggers the account unbinding function with the interface of the account binding function. At the same time, the third-party application is notified of the change in binding status through the interface pre-defined in the vehicle SDK. When the unbinding fails, the vehicle account application 20 also prompts the user of the unbinding failure and its corresponding reason.
[0040] In addition, when the account of a third-party application is bound to the account logged in on the vehicle side, synchronous login and synchronous logout can be achieved. For example, when the account logged in on the vehicle side is bound to accounts of multiple different third-party applications, multiple accounts can be logged in or logged out simultaneously.
[0041] In this regard, the same login and logout process for third-party applications is as follows: like Figure 5As shown, when a third-party application is started, the third-party application binding list corresponding to the current logged-in account on the vehicle side can be obtained through the pre-defined interface in the vehicle SDK, so as to identify whether it is bound to the account currently logged in on the vehicle side. If the account currently logged in on the vehicle side is not bound to any account of the third-party application, no subsequent process will be generated accordingly.
[0042] When the currently logged-in account on the vehicle side is bound to the account of the third-party application, the third-party application can call the account bound to the currently logged-in account on the vehicle side through the vehicle SDK to achieve quick login. It can be understood here that it is necessary to first determine whether the vehicle side account is logged in. If it is not logged in, the corresponding quick login cannot be achieved through the vehicle side account. Only when the vehicle side account is logged in can the third-party application binding list of the vehicle side account be obtained, and the corresponding token information can be obtained to log in to the corresponding bound account.
[0043] It is also understandable that when the third-party application has logged in an account, it is necessary to determine whether the account bound to the currently logged in account on the vehicle side is consistent, and if consistent, keep logging in and out with the vehicle side account. For example, when the vehicle side account logs out, the corresponding account bound to the third-party application will also be logged out synchronously. Therefore, the third-party application needs to continuously monitor the login / logout status of the bound vehicle side account, as well as the account binding status between the vehicle side account and the vehicle side account.
[0044] Based on the above account binding, account unbinding, and simultaneous login and logout, the following interfaces are pre-defined in the vehicle SDK: Get the binding information interface, and the car account application calls the binding information interface to obtain the account information currently logged in to the third-party application, and feedback the login shortcut to the user when the third-party application has no account logged in.
[0045] The vehicle account application calls the interface for obtaining the binding information change to request the third-party application to provide the corresponding login shortcut, and obtains the new account information of the third-party application after the user logs in again.
[0046] Get the binding list interface, and the third-party application obtains the account binding status of the current logged-in account on the vehicle side with respect to the third-party application through the binding list interface. It is understandable that the obtained account binding status will only reflect the binding relationship of the currently logged-in vehicle side account, and can only obtain its own account binding status, and cannot obtain the account binding status of other third-party applications in the third-party application binding list.
[0047] A binding relationship status change callback interface, and the vehicle machine account application notifies the third-party application through the binding relationship status change callback interface after the account binding status with the third-party application changes.
[0048] The account login and logout interface is used to notify the third-party application when the vehicle-side account logs in or out, so that the third-party application and the account information bound to the vehicle-side account login can maintain synchronous login or synchronous logout.
[0049] In summary, the present invention provides a vehicle computer operating system, which ensures that the binding relationship between the vehicle-side account and the third-party application account is unified and uniquely stored in the vehicle computer cloud. Even if the vehicle is changed or the factory settings are restored, the corresponding bound third-party application account can be obtained according to the vehicle-side account.
[0050] At the same time, third-party applications are no longer required to provide SDKs for account binding and account unbinding, reducing the development workload of third-party applications.
[0051] In addition, the binding interface has been unified, and there is no need to maintain a third-party binding interface jump list. The currently bound third-party applications can be displayed dynamically, and the third-party applications can be launched and offline at any time without modifying any code.
[0052] The above embodiments are merely illustrative of the principles and effects of the present invention, and are not intended to limit the present invention. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present invention. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed by the present invention shall still be covered by the claims of the present invention.
Claims
1. A vehicle operating system, characterized in that: include: At least one third-party application, vehicle account application, vehicle cloud, and vehicle SDK; The vehicle machine account application is used to call the account information of the third-party application bound to the current login account of the vehicle side from the vehicle machine cloud according to the application information of the third-party application, so as to display the account binding status of the third-party application and provide the trigger interface of the corresponding account binding function and account unbinding function; Among them, when the user triggers the account binding function of any third-party application, the vehicle account application is used to call the vehicle SDK to obtain the account information currently logged in to the third-party application after the third-party application goes online, and feedback to the user for confirmation, so as to bind the vehicle-side current login account and the third-party application current login account after the user confirms, and store them in the vehicle cloud, and update the account binding status of the vehicle-side current login account with respect to the third-party application; When the user triggers the account unbinding function of any third-party application, the vehicle account application is used to unbind the current login account on the vehicle side and the account bound to the third-party application, and update the account binding status of the current login account on the vehicle side regarding the third-party application.
2. The vehicle operating system according to claim 1, characterized in that: The third-party application is used to call the vehicle SDK to query the account binding status of the current login account on the vehicle side with respect to the third-party application, and when the current login account on the vehicle side is bound to the account information about the third-party application, the bound account is synchronized with the current login account on the vehicle side.
3. The vehicle operating system according to claim 2, characterized in that: When the vehicle-side currently logged-in account logs out, the third-party application is used to verify whether the currently logged-in account is consistent with the account bound to the third-party application for the vehicle-side currently logged-in account, and synchronously logs out of the currently logged-in account after confirming the consistency.
4. The vehicle operating system according to claim 2, characterized in that: When the vehicle has an account currently logged in, the third-party application is used to obtain the account information bound to the third-party application for the current account logged in on the vehicle, and feed back to the user to confirm whether to log in quickly.
5. The vehicle operating system according to claim 1, characterized in that: The vehicle operating system according to claim 1 is characterized in that each third-party application is configured with unique meta-data allocated by the vehicle end and a Service of a specific action; Among them, the vehicle account application reads the meta-data and Service of each third-party application according to the system's configuration table for Service, and obtains the package name and meta-data value corresponding to the third-party application based on it, so as to query the application information of the third-party application from the system.
6. The vehicle operating system according to claim 5, characterized in that: When the user triggers the account binding function, the vehicle account application is also used to identify whether the third-party application is started: if not, the third-party application is launched through the Service of the third-party application.
7. The vehicle operating system according to claim 1, characterized in that: When the user triggers the account binding function, the vehicle account application is also used to identify whether the third-party application currently has an account logged in: if not, the vehicle SDK is called to request the third-party application to provide the corresponding login shortcut, and feedback to the user for login, so as to obtain the account information currently logged in to the third-party application after the user logs in.
8. The vehicle operating system according to claim 1, characterized in that: When the user triggers the account binding function, the vehicle account application is also used to call the vehicle SDK to request the third-party application to provide a corresponding login shortcut based on the binding change instruction triggered by the user, and feedback to the user for re-login, so as to obtain the newly logged-in account information of the third-party application after the user re-logins.
9. The vehicle operating system according to claim 1, characterized in that: The vehicle machine account application is also used to call the vehicle machine SDK to notify the third-party application of the corresponding binding result or unbinding result.
10. The vehicle operating system according to claim 1, characterized in that: The following interfaces are defined in the vehicle SDK: Obtain binding information interface, and the vehicle account application calls the binding information acquisition interface to obtain the account information currently logged in by the third-party application; An interface for obtaining a binding change information is used, and the vehicle account application calls the interface for obtaining a binding change information to request the third-party application to provide a corresponding login shortcut, and obtains the new account information of the third-party application after the user logs in again; Obtaining a binding list interface, and the third-party application obtains the account binding status of the current login account on the vehicle side with respect to the third-party application and the corresponding bound account through the obtaining binding list interface; A binding relationship status change callback interface, and the vehicle account application is used to notify the third-party application through the binding relationship status change callback interface after the account binding status with the third-party application is changed; The vehicle-side account login and logout interface is used to notify the third-party application through the account login and logout interface after the vehicle-side account logs in or out, so that the third-party application and the account bound to the vehicle-side current login account and the vehicle-side current login account can maintain synchronous login or synchronous logout.