Vehicle-mounted multi-source media control system, method and vehicle

Abstract

The application relates to a vehicle-mounted multi-sound-source media control system and method and a vehicle, and relates to the technical field of vehicle-mounted multimedia. The system comprises a human-computer interaction layer, which is used for forwarding a first control instruction to a service logic layer through an application layer in response to the first control instruction issued by a music playing interface in a vehicle; the service logic layer is used for generating a second control instruction by using a target music service provider corresponding to a to-be-controlled track, a control action and a sound source indicated by the first control instruction, and sending the second control instruction to a provider access layer; the provider access layer is used for calling track information corresponding to the to-be-controlled track; in the case that a target provider access device corresponding to the target music service provider is a software development kit access device, the track information is converted into target track information by using a data structure definition layer to obtain the target track information; and the target provider access device performs the control action based on the target track information, so that the hierarchical service logic, the adaptive logic and the interaction logic can be decoupled.

Description

Technical Field

[0001] This application relates to the field of vehicle multimedia technology, specifically to a vehicle multi-source media control system, method, and vehicle. Background Technology

[0002] As the automotive industry transforms towards intelligence and connectivity, in-vehicle infotainment (IVI) systems have become a core element in enhancing the automotive user experience. Among these, online music services, being a frequently used function, directly impact the overall user experience. Currently, to meet diverse music listening needs, in-vehicle systems typically need to connect to multiple third-party music service providers simultaneously.

[0003] However, music service providers lack unified standards in their technical implementation, exhibiting a high degree of fragmentation: different music service providers use different access methods; data model fields such as songs and users vary; playback control, status synchronization, and error handling mechanisms are incompatible with each other; and the support for functions such as lyrics display and sound quality selection also differs, posing a great challenge to in-vehicle system integration.

[0004] Under the aforementioned constraints, the existing in-vehicle multimedia architecture suffers from serious flaws: the interaction layer and business logic layer are only superficially decoupled. Upper-layer data binding logic and state callback interfaces directly rely on specific vendor data models, resulting in "formal decoupling but substantial coupling." This leads to extremely low code reusability, requiring extensive code copying and modification for new vendor integrations, resulting in high development costs and significant waste of in-vehicle storage resources. Furthermore, general playback logic and vendor adaptation logic are deeply intertwined, module responsibilities are confused, and modifications can easily trigger a chain reaction of failures. This deep coupling of business logic, adaptation logic, and interaction logic across different layers directly results in low system code reusability, high expansion and maintenance costs, and poor operational stability. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this application is to provide an in-vehicle multi-source media control system, method and vehicle, which aims to solve the technical problems of deep coupling of business logic, adaptation logic and interaction logic in the traditional in-vehicle multimedia architecture, resulting in low system reuse rate, poor scalability and high maintenance cost.

[0006] In a first aspect, embodiments of this application provide an in-vehicle multi-source media control system, which includes: a human-machine interaction layer, an application layer, a business logic layer, a manufacturer access layer, and a data structure definition layer; the human-machine interaction layer is communicatively connected to the business logic layer through the application layer; the manufacturer access layer is communicatively connected to both the business logic layer and the data structure definition layer. The system comprises the following layers: The human-computer interaction layer responds to a first control command issued by the music playback interface in the vehicle, forwarding the first control command to the business logic layer via the application layer. The first control command specifies the track to be controlled, its source, and the control action. The business logic layer generates a second control command using the target music service provider corresponding to the track, control action, and source, and sends this command to the provider access layer. The provider access layer retrieves the track information corresponding to the track to be controlled. If the target provider access layer is a Software Development Kit (SDK) access layer, it uses a data structure definition layer to convert the track information from a predefined general data format to a target data structure, obtaining the target track information. The provider access layer then controls the target provider access layer to execute control actions based on the target track information. The track information uses a predefined general data format, and the target data structure is the calibration data structure corresponding to the target music service provider.

[0007] Based on the above technical solution, this application adds an independent vendor access layer to abstract and encapsulate heterogeneous access methods such as SDKs and APIs, forming a unified vendor accessor interface. This not only allows for the smooth conversion of complex private objects returned by the SDK into system-wide generic objects through the data structure definition layer in SDK access scenarios, but also necessitates only adding the accessor implementation and data mapping when integrating new vendors, without requiring changes to the upper-layer business logic. This transforms the access mode from "overall reconstruction" to "plug-in extension," significantly shortening the development cycle. Simultaneously, this application predefines a universal data format circulating throughout the system through the data structure definition layer. Unlike traditional solutions where the user interface layer is forced to rely on vendor-specific data models (a pseudo-decoupling model), this application unifies the private data formats of various vendors into a predefined universal data format. This completely frees the human-computer interaction layer and business logic layer from the constraints of vendor data structures, achieving true separation of data and business logic. Common business logic (such as playback queue management and favorites logic) can be fully reused across different music service vendors, avoiding code redundancy and effectively reducing the storage space and memory consumption of the vehicle system.

[0008] Furthermore, this application employs a five-layer system architecture, clearly defining the single responsibility of each layer: the business logic layer handles core business rules such as playback control and state management; the vendor access layer adapts to specific vendor interface calls; and the data structure definition layer focuses on data format conversion and mapping. This architecture completely solves the problem of deeply intertwined general logic and adaptation logic in traditional solutions, reducing code complexity. Developers can accurately pinpoint the scope of modifications during feature iterations or bug fixes, significantly improving system stability and maintainability, and lowering the learning curve for new members.

[0009] In one possible approach, the vendor access layer is also used to: control the target vendor access device to perform control actions based on the target track information when the target vendor access device is an application programming interface (API) access device or a data source access device.

[0010] Based on the above technical solutions, in existing technologies, the business logic layer often needs to write lengthy conditional judgment logic for SDK function calls, network requests, and local file parsing, resulting in complex and error-prone code. This application, through the abstract interface design of the target vendor's accessor, completely encapsulates the underlying implementation details within the access layer. When the business logic layer issues control commands, the vendor's access layer instantiates the corresponding accessor object based on the current audio source identifier. If the target vendor's accessor is an API accessor, it internally constructs a Hypertext Transfer Protocol (HTTP) request to retrieve the target track information over the network and execute playback; if the target vendor's accessor is a data source accessor, it internally performs local I / O operations, reads and parses a pre-set JSON / XML file to obtain the target track information, and then drives the local decoder to execute actions. The business logic layer only needs to issue unified control commands such as "play" and "pause," without needing to know whether the underlying layer initiates a network call or reads a local file, effectively eliminating a large amount of protocol judgment code and significantly reducing the amount of code and the complexity of the business logic.

[0011] In one possible approach, the vendor access layer is specifically used to: invoke the target vendor accessor using a predefined unified interface, so as to retrieve the track information corresponding to the track to be controlled from the target music service vendor through the target vendor accessor; wherein, the predefined unified interface interfaces with the vendor accessor corresponding to each music service vendor in the vendor access layer.

[0012] Based on the above technical solutions, traditional business logic layers often hold instances of specific vendor classes, requiring modifications to business code when changing vendors. In this application, the business logic layer relies solely on an abstract "predefined unified interface," calling specific access points through this interface. This interface-oriented programming model eliminates the need for the business logic layer to know which music service vendor's access logic is behind it, severing the code-level dependency of the business logic layer on the specific implementation in the vendor's access layer. This achieves complete decoupling between the business logic layer and the access layer, eliminating hard-coded dependencies. Furthermore, since all access points adhere to the same interface specification, the vendor's access layer can distribute instances based on the audio source of the track to be controlled using a simple access point factory pattern. This eliminates a large amount of branching and conditional code in traditional architectures. Regardless of whether underlying access points are added or removed, the calling logic of the business logic layer remains constant, improving code readability and maintainability.

[0013] In one possible approach, a predefined unified interface includes multiple sub-interfaces corresponding one-to-one with multiple media control classes; the vendor access layer includes multiple sub-accessors corresponding one-to-one with multiple media control classes. Based on this, the vendor access layer is specifically used for: determining the target media control class corresponding to the control action; and using the target sub-interface to call the target sub-accessor to retrieve the track information corresponding to the track to be controlled from the target music service vendor through the target sub-accessor; wherein, the target sub-interface is the sub-interface corresponding to the target media control class among multiple sub-interfaces; and the target sub-accessor is the sub-accessor corresponding to the target media control class among multiple sub-accessors.

[0014] Based on the above technical solution, this application splits the interface into multiple sub-interfaces such as playback control, lyrics acquisition, and audio quality switching. Manufacturer access devices only need to implement the sub-access devices they support. This "on-demand implementation" mechanism conforms to the interface isolation principle, avoids unnecessary code accumulation, and significantly reduces the storage overhead and memory usage of the vehicle system. Simultaneously, by precisely mapping control actions to the target media control class (e.g., "play" corresponds to the playback control class, and "get lyrics" corresponds to the lyrics control class), the business logic layer directly locates the target sub-interface and target sub-access device during invocation. This precise invocation mode eliminates the need for secondary logic judgments within a large interface, as is common in traditional architectures, ensuring that functional modules do not interfere with each other. For example, modifying the lyrics parsing logic will not affect the playback control module, greatly reducing the risk of cascading failures caused by code modifications and improving system robustness.

[0015] In one possible approach, the business logic layer is also used to: determine the candidate vendor access device in operation before sending the second control instruction to the vendor access layer; and if the candidate vendor access device and the target vendor access device are inconsistent, shut down the candidate vendor access device and activate the target vendor access device.

[0016] Based on the above technical solution, this application utilizes a predictive mechanism in the business logic layer before sending the second control command to automatically identify the currently running candidate vendor access devices. When the candidate vendor access device and the target vendor access device are inconsistent, the application proactively shuts down the candidate vendor access device, ensuring that only one target vendor access device is active at any given time. This mandatory mutual exclusion mechanism prevents audio focus confusion from the outset, guaranteeing the user's auditory experience.

[0017] In one possible approach, the vendor access layer is further configured to: during the execution of control actions, in response to a state change in the track to be controlled, send a state change notification instruction to the application layer through the business logic layer; wherein, the state change notification instruction includes: state change information of the track to be controlled and track information after the state change; the data format of the track information after the state change is a predefined general data format; the application layer is further configured to send the state change notification instruction to the human-computer interaction layer when the music playback interface is in a display state; the human-computer interaction layer is further configured to update the display content corresponding to the track to be controlled in the music playback interface based on the state change notification instruction.

[0018] Based on the above technical solutions, in traditional solutions, the data structures of status callbacks (such as playback progress and buffer percentage) from different vendors' SDKs vary, requiring the human-computer interaction layer to adapt to multiple data models. This application explicitly stipulates that status change notification instructions must carry track information in a predefined, universally formatted data format, ensuring that the human-computer interaction layer always receives data of a unified standard. Regardless of whether the underlying data is a private object pushed by the SDK or a segment obtained through API polling, after conversion by the vendor's access layer, the human-computer interaction layer always sees a unified set of data fields. This mechanism decouples the user interface (UI) rendering logic from the underlying data source, avoiding large-scale reconstruction of the interface layer due to changes in vendor protocols.

[0019] In one possible approach, the vendor access layer is also used to: detect the status information of the track to be controlled in real time through the callback listener built into the target vendor access device when the target vendor access device is an SDK access device; and send status query requests to the target music service vendor at preset time intervals when the target vendor access device is an API access device and a data source server, in order to detect the status information of the track to be controlled.

[0020] Based on the above technical solution, this application implements differentiated processing within the vendor access layer: For the SDK accessor, an event-driven model is adopted to avoid invalid queries and ensure millisecond-level real-time state synchronization; for the API accessor and data source accessor, polling is performed at preset time intervals (e.g., 1 second), ensuring smooth refresh of the user interface progress bar while avoiding network congestion or CPU idling caused by high-frequency requests. This intelligent frequency control balances system real-time performance and resource consumption, improving operational efficiency while ensuring user experience.

[0021] In one possible approach, the vendor access layer is further configured to: respond to the access requirements of a new music service vendor, determine the media control class corresponding to the new music service vendor; determine the interface relationship between multiple sub-interfaces and multiple new sub-accessors based on the media control class corresponding to the new music service vendor; the multiple new sub-accessors are multiple sub-accessors included in the new vendor accessor corresponding to the new music service vendor; and register the new vendor accessor based on the interface relationship and the calibration data structure of the new music service vendor.

[0022] Based on the above technical solution, this application automatically establishes a mapping relationship between sub-interfaces and new sub-accessors by identifying the media control classes required by new vendors. Through this design, developers only need to focus on the implementation logic of specific functions, without having to manually write interface distribution and routing code. This on-demand assembly mechanism transforms new vendor integration from tedious coding work into simple configuration and implementation filling, shortening the integration cycle by more than 60% and significantly improving product iteration speed.

[0023] Secondly, embodiments of this application provide an in-vehicle multi-source media control method, applied to the in-vehicle multi-source media control system of the first aspect. The method includes: receiving a first control command issued by a music playback interface in the vehicle; wherein the first control command is used to indicate the track to be controlled, the audio source of the track to be controlled, and the control action; calling the track information corresponding to the track to be controlled; when the target manufacturer access device corresponding to the target music service provider is a software development kit (SDK) access device, converting the track information from a predefined general data format to a target data structure to obtain target track information; controlling the target manufacturer access device to execute control actions based on the target track information; wherein the data format of the track information is a predefined general data format; and the target data structure is a calibration data structure corresponding to the target music service provider.

[0024] Based on the above technical solutions, this application adds an independent vendor access layer to abstract and encapsulate heterogeneous access methods such as SDKs and APIs, forming a unified vendor accessor interface. This not only allows for the smooth conversion of complex private objects returned by the SDK into system-wide generic objects through the data structure definition layer in SDK access scenarios, but also necessitates only adding the accessor implementation and data mapping when accessing new vendors, without requiring changes to the upper-layer business logic. This transforms the access mode from "overall reconstruction" to "plug-in extension," significantly shortening the development cycle. Simultaneously, this application predefines a universal data format circulating throughout the system through the data structure definition layer. Unlike traditional solutions where the user interface layer is forced to rely on vendor-specific data models (a pseudo-decoupling model), this application uniformly converts the private data formats of various vendors into a predefined universal data format. This completely frees the human-computer interaction layer and business logic layer from the constraints of vendor data structures, achieving true separation of data and business logic. Common business logic (such as playback queue management and favorites logic) can be fully reused across different music service vendors, avoiding code redundancy and effectively reducing the storage space and memory consumption of the vehicle system.

[0025] Furthermore, this application employs a five-layer system architecture, clearly defining the single responsibility of each layer: the business logic layer handles core business rules such as playback control and state management; the vendor access layer adapts to specific vendor interface calls; and the data structure definition layer focuses on data format conversion and mapping. This architecture completely solves the problem of deeply intertwined general logic and adaptation logic in traditional solutions, reducing code complexity. Developers can accurately pinpoint the scope of modifications during feature iterations or bug fixes, significantly improving system stability and maintainability, and lowering the learning curve for new members.

[0026] Thirdly, embodiments of this application provide a vehicle equipped with the in-vehicle multi-source media control device described in the first aspect.

[0027] Fourthly, embodiments of this application provide an electronic device, including: a processor; and a memory for storing processor-executable instructions. The processor is configured to execute instructions to implement the in-vehicle multi-source media control method described in the second aspect and any possible implementation thereof.

[0028] Fifthly, this application provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by the processor of an electronic device, enables the electronic device to perform the in-vehicle multi-source media control method described in the second aspect above and any possible implementation thereof.

[0029] Sixthly, embodiments of this application provide a computer program product, which includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the in-vehicle multi-source media control method described in the second aspect and any possible implementation thereof.

[0030] It should be noted that the technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0031] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application will be described below.

[0033] Figure 1 This application provides a schematic diagram of the structure of an in-vehicle multi-source media control system. Figure 2 This is a schematic diagram of another vehicle-mounted multi-source audio media control system provided in an embodiment of this application; Figure 3 A flowchart illustrating a vehicle-mounted multi-source audio media control method provided in an embodiment of this application; Figure 4 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0035] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] In the embodiments of this application, the words "exemplarily," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "exemplarily," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0037] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0038] The in-vehicle multi-source media control system provided in this application embodiment can be deployed in a vehicle. A vehicle can also be referred to as a vehicle, mobile carrier, electric vehicle (EV), hybrid electric vehicle (HEV), plug-in hybrid electric vehicle (PHEV), fuel cell vehicle (FCV), autonomous vehicle, intelligent and connected vehicle (ICV), driverless vehicle, etc.

[0039] In this application, the vehicle can be a sedan, a sport utility vehicle (SUV), a truck, an electric vehicle, a motorcycle, a tricycle, a special vehicle (such as an ambulance, fire truck, police car, etc.), a driverless taxi, an intelligent connected bus, an autonomous logistics vehicle, an electric truck, etc. Furthermore, this method is also applicable to various special-purpose vehicles, such as agricultural vehicles, mining vehicles, forestry vehicles, airport vehicles, and port vehicles. This application does not impose specific limitations in this regard.

[0040] like Figure 1 As shown in the figure, an in-vehicle multi-source media control system provided in this application includes: a human-machine interaction layer 101, an application layer 102, a business logic layer 103, a vendor access layer 104, and a data structure definition layer 105. The human-machine interaction layer 101 is communicatively connected to the business logic layer 103 through the application layer 102; the vendor access layer 104 is communicatively connected to both the business logic layer 103 and the data structure definition layer 105.

[0041] The human-machine interface layer (HMI) 101 serves as the interaction point between the in-vehicle multi-source media control system (or in-vehicle infotainment system) and the user, handling user interface rendering and capturing interactive events. Its core components include the main music playback interface (playback control, playlist display, and lyrics synchronization), the system settings interface (sound quality adjustment and download management), and the playlist management interface. The HMI layer 101 binds data to the underlying business logic via a ViewModel interface or a Presenter interface, without containing any business logic code itself. Furthermore, this layer achieves physical separation between UI style and business logic, supports dynamic skinning and night mode switching, and does not directly rely on any third-party music service provider SDK, ensuring the independence and reusability of interface development.

[0042] For example, such as Figure 2 As shown, the human-computer interaction layer 101 carries various user interfaces and interaction logic, including but not limited to the first type of audio source UI layer, the second type of audio source UI layer, ..., local media UI layer, etc., and is responsible for completing interface rendering, capturing user operation events and providing visual feedback.

[0043] The Application Abstraction Layer (AppBase) 102, located below the Human-Computer Interaction Layer 101, is responsible for encapsulating application-level common capabilities and lifecycle management. Core modules of AppBase 102 include, but are not limited to: the Activity Base Class (BaseActivity) and the Fragment Base Class (BaseFragment), which serve as the parent classes for all UI containers, encapsulating lifecycle monitoring, permission callback handling, page routing, and unified resource release logic, thus providing a standardized page hosting environment for the upper HMI layer; a ViewModel / Presenter manager to ensure page state consistency; a dynamic skinning engine (such as dynamic skinning, theme switching, and night mode); and a cross-page event bus framework to implement cross-page event communication mechanisms. The core responsibility of AppBase 102 is to shield the differences between the underlying hardware and the music service provider's SDK, providing a unified calling interface for HMI Layer 101; it also uniformly manages the application's global state (such as user login state and current playback source) and establishes a unified exception handling and error message mechanism, acting as a bridge between AppBase 102 and the Business Logic Layer 103.

[0044] For example, such as Figure 2As shown, the application layer 102 can provide, but is not limited to, core modules such as application base class services, activity base class services, fragment base class services, general utility / common components, and UI general tools, in order to uniformly manage the application lifecycle, handle page navigation and permission logic, and provide basic support for dynamic skinning and cross-page event communication, thereby shielding the underlying differences and providing a unified calling interface for the upper UI.

[0045] The business logic layer (Service) 103 encapsulates the core logic of multimedia playback and coordinates various vendor access points, providing a unified playback control interface to the upper application layer 102. For example... Figure 2 As shown, the core reused logic functional modules of the business logic layer 103 include, but are not limited to: the MediaPlayer control center, which provides a unified control interface for playback, pause, track switching, and progress jumping; the global state management engine, which manages the global context, including playback status, download status, and user status; the MediaSession management module, which enables system-level media control and access to playback control commands from external devices such as Bluetooth headsets; the event distribution center, which handles cross-system events such as power-on / off signals, voice commands, and instrument communication; the cloud data synchronization service, which enables cloud synchronization of user data such as playlists, favorites, and playback history; the event tracking reporting system, which collects user behavior data and performs statistical analysis; the exception handling engine, which captures underlying exceptions and converts them into business exceptions in a unified format; the voice command access, which controls media playback via voice; the instrument data communication, which displays song information synchronously; and the virtual vehicle control, which supports remote control.

[0046] The system extracts core business functions such as playback control, status management, exception handling, data synchronization, and event tracking reporting from various vendor adapters and centralizes them in the business logic layer, forming a vendor-independent, universal core module. All vendor access devices only need to implement data conversion and interface calls related to their proprietary protocols, without needing to repeatedly implement the aforementioned universal logic. This "universal kernel + differentiated shell" design allows the same core logic code to be shared and reused by all vendor access devices. Its technical effects are significant: First, it avoids repeatedly writing similar control code for different vendors, shortening the development cycle for multi-vendor access by an average of over 60%; second, it significantly reduces code redundancy caused by logic copying, effectively reducing vehicle-mounted system memory usage by approximately 30%-40% in actual tests, improving system smoothness; finally, the unified logic implementation ensures a consistent experience across different audio sources in terms of playback behavior, status feedback, and exception handling, solving the problem of fragmented audio source experiences in traditional architectures.

[0047] The business logic layer 103 defines the standard vendor adapter interface specification and dynamically loads specific adapter instances through the "vendor adapter manager." All business requests from the upper layer are logically aggregated and processed at this layer before being converted into calls to the lower-level standardized interfaces. This achieves complete decoupling of business logic from specific vendor technology implementations at the architectural level, significantly improving the system's scalability and maintainability. Figure 2 As shown, the business logic layer 103 defines a general access interface (marked by a dashed box, IvendorApapter / Imedia Source Media-framework-core module), which is used to coordinate and issue instructions to various vendor access devices in a standardized manner, so as to realize centralized business processing such as playback control, status synchronization, exception handling and data reporting.

[0048] The Vendor Adapter Layer 104, also known as the vendor adaptation layer, connects the system core with various music content providers and is the core development layer when adding new vendors. The Vendor Adapter Layer 104 contains specific access devices (or adapters) for different music service providers. Depending on the differences in the technology stack provided by the music service providers, such as... Figure 2 As shown, the accessors in the vendor access layer 104 can include, but are not limited to: SDK accessors (encapsulating native SDKs), API accessors (encapsulating RESTful interface calls), data source accessors (parsing JSON / XML and other data), and extended accessors. Each adapter follows the unified abstract interface specification defined in the business logic layer 103, converting vendor-specific SDK calls, network requests, or data parsing logic into standardized calls that the system can recognize, and supports dynamic loading and switching through factory pattern or configuration. This layer adopts a factory pattern and configuration loading mechanism, supporting dynamic switching or concurrent running of multiple vendor accessors without recompiling the code, greatly reducing the cost of accessing new music service vendors.

[0049] The data structure definition layer (Infrastructure Layer) 105, also known as the CommonBase basic capability layer, is used to provide general basic capability support. For example... Figure 2As shown, the core functions of the data structure definition layer 105 include, but are not limited to: globally unified general data structure definitions (or data model definitions), such as objects like Song, Playlist, and PlayState; network framework encapsulation, building a unified network request management system based on OkHttp and Retrofit; a collection of general utility classes covering functions such as encryption algorithms, JSON parsing, log management, and local storage; a unified thread pool scheduling center for managing the execution of asynchronous tasks; and a multi-level cache management mechanism, including memory caching and disk caching strategies; encoding and configuration management, etc. This layer does not depend on any other business logic layer, aiming to eliminate code redundancy, ensure the stability and efficiency of the underlying basic capabilities, and provide a solid operating environment for the entire application architecture.

[0050] like Figure 2 As shown, in the above hierarchical structure, the HMI layer 101 forms a top-down call and data acquisition link with the business logic layer 103 through the application layer 102; the business logic layer initiates calls to the lower-level vendor access layer 104 through a predefined general access interface; each vendor access device uses the general data structure defined by the application layer 102 as needed when executing business. In addition, the system also has a data feedback channel to transmit the underlying playback status, vendor callbacks, and system signals (such as power on / off, voice commands, Bluetooth control, etc.) from bottom to top to the corresponding processing modules, ensuring the consistency and real-time performance of UI display, business logic, and underlying playback status in multi-vendor concurrent scenarios.

[0051] In one example, the data downlink flow refers to the process by which control commands triggered by user actions or system events are passed down the architectural hierarchy from top to bottom, ultimately driving the execution of the underlying vendor's SDK or hardware (e.g., user action → playback execution). The data downlink flow (control flow / request flow) includes: like Figure 2 As shown, when a user initiates operations such as play, pause, track switching, or volume adjustment at the human-computer interaction layer, the UI layer first encapsulates the operation event into a standardized business request and passes it to the application layer. The application layer uses the Presenter / ViewModel manager to perform validity checks and lifecycle matching on the request, and then calls a unified routing interface to forward the request to the business logic layer. In the business logic layer, the player control center performs logical arbitration based on the context maintained by the global state management engine (such as network status and account authentication information), then locates the target vendor accessor instance through the vendor adapter manager and calls its standardized interface. Finally, the vendor access layer maps the standardized call to specific instructions from the corresponding vendor SDK, API, or data source and executes them, thereby achieving unified control across vendors.

[0052] In another example, the data uplink process refers to the process by which underlying playback states, hardware events, or system signals are passed up the architectural hierarchy, ultimately driving UI updates and business decisions (e.g., data acquisition → UI display). The data uplink process (state flow / callback flow) includes: like Figure 2 As shown, at the vendor access layer, the vendor SDK or data source captures raw playback state changes (such as buffering progress, playback completion, error messages) or hardware interruption signals (such as Bluetooth headset button events, power-on / off notifications) through a callback mechanism, and converts them into a unified data model that conforms to the definition of the business logic layer. Subsequently, the state data is reported to the business logic layer via the playback state listener (PlayStateListener) registered by the vendor accessor. The state management engine in the business logic layer normalizes and resolves conflicts in the reported data, and distributes standardized state change events to subscribers through the event distribution center. The application layer receives the above events through the event bus framework, and the ViewModel / Presenter updates the corresponding observable data objects, triggering the data binding mechanism of the human-computer interaction layer to realize real-time UI updates such as playback progress bar refresh, lyrics synchronization, and button state switching. At the same time, critical state changes (such as playback errors, network timeouts) are captured by the exception handling engine and converted into unified user prompt information, which is fed back to the user interface through the application layer, thus forming a closed-loop state synchronization mechanism.

[0053] The in-vehicle multi-source media control system provided in this application embodiment is built on the Android Studio integrated development environment, uses Kotlin as the core programming language, relies on the JDK (Java Development Kit) for underlying runtime support, and utilizes the Gradle build tool to achieve automated compilation, dependency management, and multi-module packaging. In this environment, the system is divided into multiple independent Gradle modules. Through Gradle's dependency configuration mechanism, compile-time decoupling between the general interface definition layer and the specific vendor adapter implementation layer is achieved. Simultaneously, combined with Kotlin's coroutine features and null safety design, the processing efficiency and code robustness of asynchronous tasks (such as network requests) are effectively improved, providing underlying technical guarantees for the stable operation of the aforementioned five-layer architecture.

[0054] The five-layer in-vehicle multi-source media control system provided in this application achieves both physical and logical isolation between interface display, application abstraction, business logic, vendor adaptation, and basic capabilities through unidirectional dependencies between layers and standardized interface definitions. Under this architecture, when a new music service provider needs to be integrated, developers only need to add a corresponding adapter implementation in the vendor access layer according to the preset general interface specifications (approximately 5-10 days), without requiring any targeted modifications to the core code of the upper application layer and business logic layer. Compared to traditional methods, this shortens the development cycle by 70%, and increases code reuse rate from less than 20% to over 85%. This "plug-in" extension mechanism effectively avoids the risk of code refactoring due to frequent vendor changes, significantly improving the system's scalability, maintainability, and cross-software / hardware platform adaptation efficiency, making it particularly suitable for complex application scenarios with multiple audio sources and hardware solutions in an in-vehicle environment.

[0055] The above describes the specific functions of each layer and the communication interaction between each layer. To facilitate understanding, the functional modules of each layer and the inter-layer communication interaction mechanism will be further explained in detail below with reference to specific embodiments.

[0056] In one optional implementation, the human-machine interaction layer is used to respond to a first control command issued by the music playback interface in the vehicle and forward the first control command to the business logic layer through the application layer.

[0057] The first control command is used to indicate the track to be controlled, as well as the sound source and control actions of the track to be controlled.

[0058] In some embodiments, when a user performs control operations on the music playback interface on the vehicle's infotainment screen, the human-machine interaction layer can capture the user's control events (such as clicks, long presses, or swipes) on the music playback interface through an event listening mechanism. It then parses the corresponding track and associated parameters, determines the source identifier and control action (such as play, pause, or favorite) of the track, and generates a first control command. The human-machine interaction layer can then send the first control command to the application layer, which forwards it to the business logic layer.

[0059] For example, the music playback interface is managed by MusicActivity, which inherits from the activity base class (BaseActivity), and the playlist within the interface is implemented by RecyclerView and its accompanying adapter. During the list construction phase, the onBindViewHolder method of RecyclerView.Adapter iterates through the data source queue, encapsulates each track to be controlled as an instance of a playable item, and associates the playable item with the corresponding list item view through a data binding mechanism.

[0060] Based on this, when a user clicks on a track in the playlist, the HCI layer captures the click event through MusicActivity or its host Fragment. After the click event is triggered, the adapter retrieves the PlayableItem object corresponding to the list item from the bound view tag (itemView.getTag()) or callback parameters through the view holder (ViewHolder) or directly through a callback closure. Here, PlayableItem is the specific data carrier (i.e., track information) of the track to be controlled in the software architecture, which encapsulates at least the unique identifier (id), source identifier, and metadata (such as title, artist, etc.) of the track to be controlled. Then, the HCI layer uses this PlayableItem as the core parameter of the track to be controlled, combined with the control action determined by the user's intent (such as "play"), to generate the first control command. The HCI layer calls the playback method of the associated view model (ViewModel1) (such as ViewModel1.play(PlayableItem)) and sends the first control command containing the PlayableItem to the application layer.

[0061] Accordingly, after receiving the first control instruction, the application layer manages the lifecycle of the MusicViewModel through the ViewModel manager. When the play method is called, the application layer executes the following preprocessing logic: First, BaseActivity checks the current page's lifecycle state to ensure that subsequent operations are not performed in the onDestroy state; second, it starts a coroutine using ViewModelScope or lifecycleScope to avoid the risk of memory leaks caused by asynchronous tasks; finally, through the routing and scheduling mechanism encapsulated in the Base class, it calls the interface of the business logic layer to forward the first control instruction to the business logic layer to trigger subsequent distribution and processing. During this process, the application layer only acts as a "pipeline" and does not parse or modify the PlayableItem, ensuring that the data maintains its universality when flowing through this layer. At the same time, it sends a "playing soon" pre-notification to other UI components through the EventBus to achieve UI refresh.

[0062] In one optional implementation, the business logic layer is used to generate a second control instruction using the track to be controlled, the control action, and the target music service provider corresponding to the sound source, and send the second control instruction to the provider access layer.

[0063] In some embodiments, the business logic layer can parse the first control instruction, use the vendor adapter manager to determine the target music service vendor matching the audio source identifier, and load the target vendor accessor corresponding to the target music service vendor. Furthermore, the business logic layer can determine the currently running candidate vendor accessors. If the candidate vendor accessor and the target vendor accessor are inconsistent, the candidate vendor accessor is closed, and the target vendor accessor is activated. After activating the target vendor accessor, the second control instruction is generated by encapsulating the track to be controlled as a generic Song object and combining it with the control action, and then sent to the vendor access layer.

[0064] For example, the business logic layer 103 is the core hub of playback control, responsible for arbitrating playback requests, routing by vendors, and managing their lifecycle. After receiving the first control instruction (such as a playback request) from the application layer, its internal player control center executes the following processing logic: 1-1. Pre-processing State Verification: The player control center first calls the state management engine to check the current global playback state (such as whether it is in the process of releasing resources or whether there is no network connection). If the current state does not meet the playback conditions (such as when Deinit operation is being performed), the first control command is immediately blocked, and an exception code is returned to the upper layer via callback; if the state is valid, the process is allowed to proceed to the next stage.

[0065] 1-2. Behavior tracking: After confirming that the first control command can be executed, the business logic layer records the user's playback behavior (such as click timestamp, song ID, audio source identifier, etc.) and reports the data to the data analysis service to complete the user behavior tracking.

[0066] 1-3. Vendor Routing and Access Device Lifecycle Management: The player control center calls the vendor adapter manager, determines the target music service vendor (such as music service vendor A) that matches the track to be controlled based on the source field (sound source identifier) ​​in PlayableItem, and loads the target vendor access device (such as A_Music_Adapter) corresponding to the target music service vendor.

[0067] During this process, the adapter manager can further determine whether a candidate vendor access point (i.e., the adapter instance currently providing audio services) is already running in the system. If the candidate vendor access point and the target vendor access point are the same instance (e.g., both are A_Music_Adapter), the current instance remains active to avoid duplicate initialization. If the candidate vendor access point and the target vendor access point are different (e.g., the currently running candidate vendor access point is B_Music_Adapter, while the target vendor access point is A_Music_Adapter), it is determined that an audio source switch has occurred. At this time, the adapter manager first calls the release() or pause() method of the candidate vendor access point to release the hardware and network resources it occupies, shuts down the candidate vendor access point, and then activates and initializes the target vendor access point, ensuring that only one vendor SDK occupies the system audio channel at any given time, thereby avoiding audio conflicts or resource leaks caused by multiple SDK concurrency.

[0068] 1-4. Command Generation and Issuance: After the target vendor's access device is activated and ready, the business logic layer uses PlayableItem (a predefined general data format) as the carrier of the track to be controlled. Combined with the parsed control action (playback), it encapsulates and generates a second control command (i.e., calls the playItem(item) method of the standard interface). The business logic layer then calls the general access interface method implemented by the target vendor's access device to issue the second control command to the vendor's access layer.

[0069] It should be noted that the business logic layer relies solely on the abstract definition of the general access interface throughout the entire process, remaining completely unaware of the internal details of the underlying SDK accessors or API accessors. The parameters passed in are always of the PlayableItem general data structure type defined by the application layer. By introducing the aforementioned "candidate accessor comparison and closure" mechanism, the business logic layer not only decouples the business logic from the vendor's underlying technical implementation but also ensures the atomicity of audio source switching and the integrity of resource release from an architectural perspective.

[0070] In one optional implementation, a vendor access layer is used to call the track information corresponding to the track to be controlled. Then, if the target vendor accessor corresponding to the target music service vendor is a software development kit (SDK) accessor, the track information is converted from a predefined general data format to a target data structure using a data structure definition layer to obtain the target track information; the target vendor accessor is then controlled to execute control actions based on the target track information.

[0071] In this embodiment, the vendor access layer may include multiple accessors, with at least one vendor accessor. Each vendor accessor corresponds to a music service vendor, and the accessor type of each vendor accessor is determined based on the service access method provided by the music service vendor corresponding to the vendor accessor. For example, if music service vendor A provides an SDK access method, music service vendor B provides an API access method, and music service vendor C provides a data source (such as JSON / XML) access method, then the accessor corresponding to music service vendor A is an SDK accessor, the accessor corresponding to music service vendor B is an API accessor, and the accessor corresponding to music service vendor C is a data source accessor.

[0072] The data format for track information is a predefined general data format. That is, the data structure definition layer can define all general data models related to media playback (i.e., predefined general data formats), including but not limited to: PlayableItem, which encapsulates fields such as unique identifier (id), title (title), artist (artist), album (album), duration (duration), cover link (coverUrl), lyrics link (lyricUrl), and source identifier (source); PlayState, which encapsulates fields such as playing status (isPlaying), current progress (currentPos), total duration (duration), buffering progress (bufferingProgress), and current song (currentSong); a unified playlist model (Playlist); a playback state enumeration (PlayerState), which includes at least the states of idle (IDLE), playing (PLAYING), paused (PAUSED), buffering (BUFFERING), and error (ERROR); and a unified authentication configuration (AuthConfig).

[0073] The aforementioned general data structure is designed to be completely independent of specific music service providers. Its internal field naming conventions, nested structures, and data types do not depend on any vendor's proprietary protocols. This ensures that in cross-vendor access scenarios, the upper-layer business logic only needs to program against the predefined general data format and does not need to be aware of the differences in the source of the underlying data.

[0074] The target data structure refers to the specified data structure corresponding to the target music service provider. In other words, within the software architecture, different music service providers define their own proprietary data interaction specifications due to their own technical implementation, copyright protection, and historical iterations. The specified data structure corresponding to the music service provider refers to the specific data organization format mandated by the music service provider's SDK or API when receiving playback instructions.

[0075] In some embodiments, after receiving the second control instruction from the business logic layer, the vendor access layer first parses the instruction to extract the track to be controlled (i.e., the PlayableItem object), the corresponding audio source, and the control action. Here, PlayableItem is a predefined generic data format instance defined by the data structure definition layer, carrying the core metadata of the track to be controlled. Then, the vendor access layer can determine the target music service vendor matching the audio source, and the target vendor accessor corresponding to the target music service vendor. If the target vendor accessor is determined to be an SDK accessor, the target vendor accessor can execute the following processing flow: First, the track information of the track to be controlled, encapsulated in the PlayableItem, is read. Since the field definitions of PlayableItem (such as id, title, artist) are incompatible with the input parameter format required by the target music service provider's SDK, the target provider's accessor further calls the conversion tool provided by the data structure definition layer to reverse-engineer the track information from a predefined general data format into a target provider's SDK-specific labeled data structure. This conversion process specifically includes: mapping general fields to vendor-private fields (e.g., mapping the general id to songMid, and title to songName), and generating a complete data object conforming to the SDK interface specification, i.e., the target track information.

[0076] Afterwards, the target vendor access device calls the native playback interface provided by the target music service vendor's SDK, passes in the target track information as input parameters, and controls the SDK's underlying engine to execute corresponding control actions (such as play, pause, or skip) based on the target track information, thereby completing the final execution from general control commands to the vendor's private protocol.

[0077] For example, the target vendor access point (taking the SDK access point: A_Music_Adapter as an example) can specifically execute the following processing logic: 2-1. Asynchronous Thread Scheduling: To prevent time-consuming input / output (I / O) operations from blocking the Android main thread, leading to UI lag or application not responding (ANR), the target vendor's accessor first executes subsequent logic in a suspend function or background thread. Specifically, by switching the context to the I / O scheduler (withContext(Dispatchers.IO)), the coroutine context is switched to the I / O thread pool, ensuring that network requests and data parsing operations are executed in the background.

[0078] 2-2. Data Reverse Conversion: The target vendor's accessor extracts fields from the PlayableItem object. PlayableItem, as a predefined generic data format defined in the data structure definition layer, has fields that are incompatible with the calibration data structure required by the target music service vendor's SDK. Therefore, reverse conversion must be performed: Parameter extraction: Read common fields from PlayableItem, including unique identifier (id), title (title), artist (artist), album (album), and duration (duration).

[0079] Structure Mapping: Based on preset mapping rules, the above general fields are converted into structure fields specific to music company A. For example, the general field id is mapped to the music company A's private field songMid, title is mapped to songName, artist is mapped to singerName, album is mapped to albumName, and duration is mapped to interval.

[0080] Object Construction: Instantiate a PlayableItem_A object using the mapped parameters. In particular, if the PlayableItem already contains a playback URL that has been authenticated by the cloud (applicable to some third-party music vendor SDK scenarios), the target vendor's accessor can inject this URL into the PlayableItem_A object to meet the SDK's playback requirements.

[0081] 2-3. Native SDK Call: After the data reverse conversion is completed, the PlayableItem_A object can call the native playback interface provided by the music vendor A's SDK. Depending on the SDK version of music vendor A, there are two calling methods: Lightweight call: If the SDK supports playback using only a unique identifier, then call aMusicSDK.play(songMid); Full object call: If the SDK requires the complete context, then call aMusicSDK.play(aSong). This step completes the final conversion from "system common language" to "vendor-specific protocol," enabling the underlying SDK to correctly parse playback instructions.

[0082] 2-4. After receiving the playback command and PlayableItem_A object from the A_Music_Adapter, the SDK of music vendor A takes over the subsequent underlying audio processing flow: (1) Authentication and parsing: verify the validity of songMid or playback URL; (2) Resource loading: if it is an online song, establish a network connection, pull audio stream data, and dynamically adjust the buffering strategy according to the network conditions; (3) Decoding and output: call the AudioTrack or OpenSL ES interface of the Android system to decode the audio data and start playing the track to be controlled through its internal player engine; (4) Status callback: at key nodes such as playback preparation, buffering, playback, pause, completion or error, the status information is sent back to the A_Music_Adapter through the callback mechanism.

[0083] In other embodiments, when the target vendor accessor is an application programming interface (API) accessor or a data source accessor, the vendor access layer can control the target vendor accessor to perform control actions based on the target track information.

[0084] For example, in the API access method, the corresponding music service provider only provides a RESTful API interface to return audio data and metadata (JSON format), without providing an SDK or player. Therefore, the vendor's access layer needs to encapsulate its own player (such as ExoPlayer) to implement audio playback capabilities. Based on this, when the target vendor's accessor is an API accessor or a data source accessor, the process of the vendor's access layer calling the target vendor's accessor to execute control actions differs significantly from that of an SDK accessor. The specific processing logic is as follows: 3-1. Asynchronous thread scheduling: Switch to the I / O thread using withContext(Dispatchers.IO) to ensure that network requests do not block the main thread.

[0085] 3-2. Obtaining Playback Parameters: Extract the core parameters required for audio playback from the PlayableItem. For API accessors, since they are not subject to the strong constraints of vendor-owned SDKs, the playback address (such as the audio URL) usually comes directly from the extended fields of the PlayableItem (obtained from the cloud via item.id), or directly from common fields such as duration (item.duration) and title.

[0086] 3-3. Direct Call Without Conversion: Unlike the SDK accessor, which is required to convert PlayableItem into a vendor-specific data structure, the API accessor in this embodiment is associated with a self-encapsulated player (such as a player based on ExoPlayer). This self-encapsulated player is designed to be compatible with predefined general data structures in the application layer, and its exposed playback interface (such as the `play` method) can directly receive and process standard fields in PlayableItem. Therefore, the API accessor does not need to perform a data reverse conversion step; instead, it directly passes the extracted audio URL and other playback parameters (such as duration and caching strategy) to the self-encapsulated player's `ExoPlayer.play(audioUrl, item.duration)` method, driving the player to start. This step fully demonstrates the architectural advantages of the API access method: by unifying the player's external data reception standard, it eliminates the data format conversion overhead of the adaptation layer and simplifies the logical complexity of the implementation layer.

[0087] 3-4. After receiving the audio URL and playback parameters, the self-encapsulated ExoPlayer player takes over the entire underlying audio rendering process. Its functional positioning is equivalent to the vendor's private player engine in the SDK access method, specifically including: resource loading: establishing a network connection and pulling the network audio stream; decoding and output: calling the Android underlying audio interface (such as AudioTrack) to decode the audio data and outputting sound waves through the car audio system; status callback: at key nodes such as buffering, playback, pause, and completion, it sends status information back to the accessor through the listening interface, and then reports it to the business logic layer.

[0088] Based on the above process, when the target vendor's access device is an API access device, the system leverages the compatibility of its self-encapsulated player with common data formats, eliminating the reverse conversion step of "common format → vendor's proprietary format". This not only reduces code redundancy and runtime CPU overhead, but also makes the control logic of the playback kernel more unified, facilitating subsequent unified upgrades and maintenance of the player kernel without affecting upper-layer services and the independence of each vendor's access device.

[0089] It should be noted that, to decouple business logic from vendor implementation, this application adopts a modular design approach, building each vendor adapter as an independent Gradle module compilation unit. For example, they are named adapter-amusic, adapter-bmusic, adapter-kugou, etc. This design makes each audio source access capability a pluggable, independent component at the engineering construction level, achieving true compile-time on-demand integration and runtime plug-and-play functionality.

[0090] For example, as shown in Table 1 below, the system can be divided into an application main module, a media framework core layer, and a vendor access layer. Each access module exists as an independent third-party dependency: the application main module (App Module), as the system entry point, must depend on the media framework core layer to obtain basic service capabilities; at the same time, specific access module modules (such as adapter-amusic) are selectively compiled and introduced according to project requirements. Access module modules that are not selected do not participate in compilation at all. The media framework core layer (media-framework-core) is the cornerstone of the architecture. This module only defines a general access interface, provides an access factory (AdapterFactory), and an access loading / unloading management mechanism. This core layer does not contain any vendor-specific implementation code, nor does it have any compile-time dependencies on any vendor's SDK.

[0091] Table 1. Description of the application main module, media framework core layer, and vendor access layer structure.

[0092] Based on the above technical solutions, traditional architectures often require separate troubleshooting and repair of functional defects or compatibility issues across different vendor modules. This not only involves a large amount of repetitive work but also easily leads to version inconsistencies due to omissions. This application constructs a unified business logic by encapsulating common logic such as playback control, state management, and exception handling into the core module of the business logic layer. Under this mechanism, all vendor access devices reuse the same set of core logic through a standardized, universal access interface. When a bug occurs or logic optimization is required, developers only need to modify the code once in the universal core logic module of the business logic layer. The modified logic can then be automatically synchronized and applied to all vendor access scenarios and related projects through the standardized interface. This "single modification point" design avoids the persistent problem of repeatedly modifying the same bug in different modules and projects. Its technical effects are significant: First, it achieves "fix once, all effective", and the correction of similar compatibility issues or logical vulnerabilities can be instantly applied to all audio sources; second, it avoids repetitive work and waste of human resources; third, it greatly improves maintenance efficiency. According to actual tests, the efficiency of bug fixing is improved by more than 80%, the workload of regression verification is reduced by 70%, and the maintainability and version stability of the system are significantly enhanced.

[0093] In one optional implementation, the aforementioned vendor access layer calls the track information corresponding to the track to be controlled, which may specifically include: using a predefined unified interface to call the target vendor access device, so as to call the track information corresponding to the track to be controlled from the target music service vendor through the target vendor access device.

[0094] The predefined unified interface (also known as the general access interface or general abstract interface) serves as a standard contract between the business logic layer and the vendor access layer. This predefined unified interface interfaces with the vendor access device corresponding to each music service vendor in the vendor access layer, and all vendor access devices implement the standard methods defined by this interface. Through this interface, the business logic layer only needs to be aware of the abstract calling methods, without needing to concern itself with the specific vendor's data acquisition details. The target vendor access device encapsulates the specific network request construction, SDK function calls, or local data retrieval logic within the interface implementation, thereby decoupling the data acquisition process from the upper-layer business logic.

[0095] In this embodiment, the predefined unified interface adopts a modular design, internally organizing methods by functional category / media control category, covering a complete set of capabilities from lifecycle management to media playback control. The interface internally defines the following five categories of standard methods: (a) Lifecycle methods: used to manage the loading and unloading of the adapter, including initialize(Contextcontext, AuthConfig config) (initialize the accessor) and release() (release resources).

[0096] (ii) Playback control methods: These are used to execute the core playback logic, including playItem(PlayableItemitem) (play the specified song), pause() (pause playback), seekTo(long position) (jump to the specified position), and setVolume(float volume) (set the volume).

[0097] (iii) Status query methods: used to get the current running status, including getCurrentState() (get the current playback status).

[0098] (iv) Data acquisition methods: used to retrieve cloud or local media resources, including searchSong(String keyword, int page) (search for songs) and getUserPlaylist(String userId) (get user playlists). (v) Status listener class methods: used to establish a status reporting channel, including registerPlayStateListener(PlayStateListener listener) (register the playback status listener).

[0099] Based on the above interface definition, when the business logic layer needs to call the track information corresponding to the track to be controlled, it only programs against this predefined unified interface, calling its data acquisition class methods (such as searchSong or getUserPlaylist). Since this interface connects to the vendor accessor corresponding to each music service vendor in the vendor access layer, the call request will be dynamically distributed to the currently active target vendor accessor through a polymorphic mechanism. In its internal implementation, the target vendor accessor performs specific data retrieval and acquisition operations according to the target music service vendor's private protocol (such as SDK calls or RESTful API requests), and encapsulates the returned heterogeneous data into a system-unified PlayableItem object before sending it back upwards.

[0100] Furthermore, to improve code maintainability and readability, the predefined unified interface can be logically divided into multiple sub-interfaces corresponding to multiple media control classes. Correspondingly, the vendor accessor includes multiple sub-accessors corresponding to multiple media control classes.

[0101] In some embodiments, in combination with the above content, after receiving the second control instruction, the vendor access layer first parses the second control instruction to determine the target media control class (such as a playback control class, a data acquisition class, etc.) to which the control action (e.g., "play", "search" or "acquire playlist") of the to-be-controlled track belongs. After that, the vendor access layer may determine the target sub-interface corresponding to the target media control class from the plurality of sub-interfaces, and the target sub-accessor corresponding to the target media control class from the plurality of sub-accessors according to the determined target media control class. Finally, the target sub-interface is used to invoke the target sub-accessor, so as to invoke the track information corresponding to the to-be-controlled track of the vendor access layer from the target music service vendor of the vendor access layer through the target sub-accessor of the vendor access layer.

[0102] Exemplarily, it is assumed that the user initiates an operation of "searching for the song 'Sunny Day'" in an environment where the current sound source is "Class A Music". The vendor access layer parses the received second control instruction, and may determine that the "search" action belongs to the data acquisition class. Based on this identification result, the vendor access layer may implement the following interface routing mechanism: First, the target sub-interface is determined: since the operation is data query, the target sub-interface is locked as the DataFetchController (data acquisition sub-interface) in the predefined unified interface, specifically pointing to its defined searchSong(keyword, page) method. Second, the target sub-accessor is matched: since the currently activated accessor is the A_Music_Adapter accessor corresponding to Class A Music, the specific implementation module that has implemented the DataFetchController interface inside the A_Music_Adapter accessor may be automatically matched as the target sub-accessor. After that, the vendor access layer may invoke the searchSong("Sunny Day", 1) method of A_Music_Adapter through the predefined unified interface. This invocation process is transparent to upper-layer services, and the service logic layer does not need to perceive the specific adapter type.

[0103] Through the above process, the system utilizes the mapping relationship between the sub-interfaces and the sub-accessors to realize the accurate conversion and execution of the search instruction from the general interface to the vendor private protocol, which fully reflects the decoupling characteristic of the architecture.

[0104] In an optional implementation, the vendor access layer may be further configured to, in response to a state change of the to-be-controlled track during the process of executing the control action, send a state change notification instruction to the application layer through the service logic layer.

[0105] The state change notification instruction includes: state change information of the to-be-controlled track and track information after the state change. The data format of the track information after the state change is a predefined general data format, so as to ensure that the uplink data remains vendor-independent in the entire link.

[0106] In some embodiments, when the target vendor accessor is an SDK accessor, the vendor access layer can detect the status information of the track to be controlled in real time through the callback listener built into the SDK accessor. If a status change of the track to be controlled is detected (such as from idle to playing, from playing to paused, or buffering), the vendor access layer will send a status change notification instruction to the application layer through the business logic layer. The status change notification instruction includes at least the status change information of the track to be controlled (such as play / pause / buffering / error) and the track information after the status change. The track information after the status change is converted from the calibration data structure to a predefined general data format (such as PlayableItem, PlayerState) defined by the data structure definition layer, thereby ensuring that the uplink data remains vendor-independent throughout the entire link.

[0107] For example, the SDK of music service provider A monitors changes in playback state in real time during playback (such as changing from the idle state to the playable state), and actively pushes the state change event to the A_Music_Adapter accessor through a pre-registered callback listener (SDK push mode / event-driven mode). At this time, the callback parameter uses the private state type of music service provider A, which is not yet a general system state.

[0108] In the above scenario, the A_Music_Adapter accessor maps vendor-private states to the unified playback state enumeration PlayerState defined by the application layer according to preset mapping rules. For example, AState.PLAYING→PlayerState.PLAYING, AState.PAUSED→PlayerState.PAUSED, AState.BUFFERING→PlayerState.BUFFERING, and other undefined states are mapped to PlayerState.IDLE.

[0109] After the conversion is complete, the A_Music_Adapter can call listener.onStateChanged(PlayerState.PLAYING) to pass the unified state change notification instruction up to the business logic layer. This step ensures that the state received by the upper layer is always a unified PlayerState enumeration, without needing to be aware of the track playback state definition inside the music service provider A.

[0110] In other embodiments, when the target vendor accessor is an API accessor and a data source server, the vendor access layer can send status query requests to the target music service vendor at preset time intervals to detect the status information of the track to be controlled.

[0111] For example, in the API access mode, the mechanism by which the target vendor's access device (such as the B_Music_Adapter access device) obtains state information is more diverse than in the SDK access mode, mainly including the following two parallel sources, which together constitute a complete state monitoring system: (1) Local Player State: The ExoPlayer player, encapsulated by the B_Music_Adapter, maintains a precise playback state machine. When the playback state changes (such as from buffering to playing, or from playing to paused), ExoPlayer actively pushes the state change event through its native Player.Listener callback interface. This mechanism is similar to the SDK's callback mode, featuring low latency and high efficiency, and is mainly used to drive real-time UI refresh (such as progress bar updates and button state switching).

[0112] (2) Remote Server Status (Polling-Driven / Pull Mode): Given that API access methods often involve cloud synchronization requirements (such as cross-device playback continuation, cloud collection status synchronization, or heartbeat keep-alive requirements of certain special protocols), relying solely on local callbacks is insufficient. Therefore, during playback, the B_Music_Adapter actively initiates a status query request to the target music service provider's server at preset time intervals (e.g., every 1 second). This request is used to pull status information recorded on the server side (e.g., {"status":"playing", "progress":12000}) to ensure consistency between the local playback status and the cloud status, which is particularly suitable for scenarios requiring high-frequency synchronization.

[0113] The sources of state information data differ in this step (SDK method originates from private playback state enumeration callbacks, API method originates from ExoPlayer constants or HTTP JSON responses), and the API method adds active polling logic. However, the two maintain a high degree of consistency in architectural responsibilities and processing flow: both shield the underlying differences within the adapter, mapping the heterogeneous raw state data to the application-layer defined PlayerState general enumeration, thereby ensuring that the upper-layer business logic and UI layer always face a standardized state interface without needing to be aware of the differences in the underlying communication mechanism.

[0114] In one alternative implementation, the application layer can also be used to send a status change notification instruction to the human-computer interaction layer when the music playback interface is in a display state.

[0115] For example, after receiving the onStateChanged(PlayerState.PLAYING) callback, the state management engine of the business logic layer executes the following general processing logic: (a.1) Update the internal global state machine to maintain the current playback context; (b.1) Synchronize the playback state to the Android system through the MediaSession protocol so that system components such as the lock screen, notification bar, and vehicle dashboard can consistently display the current playback information; (c.1) Encapsulate PlayerState and the current PlayableItem into a playback state change event through the EventBus and send the state change notification instruction to the application layer; (d.1) Trigger the instrument data communication logic to synchronize the song metadata to the instrument panel display via the vehicle bus to achieve multi-terminal linkage.

[0116] In response, after receiving the aforementioned state change notification instructions via the event bus or LiveData / StateFlow, the application layer's ViewModel1 manager further executes application-level scheduling: (a.2) Utilizing the lifecycle management capabilities of BaseActivity, it determines whether the current MusicActivity is in the foreground; if it is in the background, the event is cached and dispatched only after the Activity returns to the foreground, thus avoiding performance loss caused by invalid UI updates; (b.2) PlayerState and PlayableItem are exposed to the human-computer interaction layer through the observable data container (LiveData / StateFlow) in ViewModel1; (c.2) The skinning logic engine determines whether to synchronously refresh the colors and styles of UI controls based on the current theme configuration. During this process, the application layer only undertakes the responsibilities of data pass-through and lifecycle management, and does not perform any vendor-related conversions on PlayerState or PlayableItem.

[0117] In one optional implementation, the human-computer interaction layer is further used to update the display content corresponding to the track to be controlled in the music playback interface based on the state change notification instruction.

[0118] For example, after receiving a state change notification, the human-computer interaction layer can receive the latest PlayerState and PlayableItem in real time based on the observable data exposed in the ViewModel1 by observing the Activity or Fragment. The UI components directly refresh the interface based on this common data: (a.3) The playback control button switches icons according to state.isPlaying (e.g., from play icon to pause icon R.drawable.ic_pause); (b.3) The song title is updated via tvTitle.setText(state.currentSong.title); (c.3) The artist name is updated via tvArtist.setText(state.currentSong.artist); (d.3) The total duration of the progress bar is set via progressBar.max = state.duration.toInt(); (e.3) A scheduled task is started to periodically call the progress query interface provided by the business logic layer to update the playback progress.

[0119] Based on the above technical solution, during the entire UI update process, the human-computer interaction layer code does not need to determine whether the current sound source comes from music service provider A or music service provider B, nor does it need to parse the private data structures of music service provider A and music service provider B. All displayed content originates from the predefined general data format defined by the application layer, thereby achieving complete decoupling between the interface display and the underlying vendor implementation.

[0120] In one optional implementation, the vendor access layer can also respond to the access request of a new music service vendor, determine the media control class corresponding to the new music service vendor, and then, based on the media control class corresponding to the new music service vendor, determine the interface relationship between multiple sub-interfaces and multiple new sub-accessors. Afterwards, based on the interface relationship and the identification data structure of the new music service vendor, the new vendor accessor is registered.

[0121] Among them, the multiple newly added sub-accessors are the multiple sub-accessors included in the newly added vendor accessors corresponding to the newly added music service vendors.

[0122] In some embodiments, when responding to the access request of a new music service provider (such as music service provider C), the required capabilities of music service provider C are first analyzed to determine its corresponding media control class (such as playback control class, data acquisition class). Then, developers are guided to build a new provider accessor, which internally contains multiple new sub-accessors (such as MiguPlaybackImpl and MiguDataFetchImpl) corresponding one-to-one with the media control class. Each sub-accessor is ensured to implement the corresponding sub-interface in the predefined unified interface, thereby establishing the interface relationship between the two. Finally, data mapping rules are configured based on the calibration data structure of music service provider C, and metadata containing the relationship between the audio source identifier and the interface implementation is registered to the adapter manager. Based on this, the system can automatically discover and load music service provider C at runtime through the audio source identifier, enabling the access and function invocation of a new provider to be completed simply by adding an independent module without modifying the upper-layer business logic code.

[0123] For example, the specific steps to implement the access requirement of a new music service provider (such as music service provider C) are as follows: Step 1: Requirements Analysis and Control Class Mapping: Developers can analyze the API interface documentation provided by the music service provider C's open platform to interpret its business capabilities and data formats. Through analysis, it is determined that music service provider C needs to support two core media control classes: playback control and data acquisition, and its private data structures (such as NESong and NEPlayers) must be clearly defined.

[0124] Step 2: Construct the adapter's internal structure and interface implementation: Create the B_Music_Adapter class as a new vendor access point. Unlike traditional monolithic designs, this access point is internally divided into multiple new sub-access points based on functionality, and each implements the corresponding sub-interface in the predefined unified interface: implement the PlaybackController sub-interface to encapsulate playback, pause, and other logic; implement the DataFetchController sub-interface to encapsulate search, playlist retrieval, and other logic.

[0125] Step 3: Lifecycle and Playback Logic Implementation: In the `initialize(Context, AuthConfig)` method, the vendor's access layer can complete the API authentication configuration based on the passed `appKey` and `appSecret`; in the `playItem(PlayableItem)` method, an HTTP request conforming to the music service vendor's C specification is constructed to call its playback API; in the `searchSong(String, int)` method, the search API is called, and the returned heterogeneous JSON data is forward-converted (e.g., mapping `NESong` to `PlayableItem`) to adapt to the system's general data model.

[0126] Step 4: Implementation of the State Listening Mechanism: In the `registerPlayStateListener()` method, establish a state synchronization mechanism. Given that API access typically uses polling or WebSocket push, the developers encapsulate scheduled tasks or callback parsing logic here, uniformly mapping the private state of the music service provider B's server (e.g., `{"code":200,"status":"playing"}`) to the `PlayerState` enumeration defined in the CommonBase layer, and reporting it to the upper layer via listener callbacks.

[0127] Step 5: Modular Construction and Configurable Registration: Encapsulate B_Music_Adapter as an independent GradleModule (e.g., adapter-bmusic). In the module's configuration file, declare the accessor's metadata: specify the audio source identifier (e.g., bmusic) and register its implemented sub-interface list. Subsequently, import this module in the main project's Gradle configuration, or configure it to be dynamically loaded at runtime via ServiceLoader.

[0128] Step 6: Runtime Dynamic Loading and Business Verification: When the application starts, the AdapterFactory in the business logic layer scans the configuration file or classpath and automatically registers B_Music_Adapter. When the user switches to "the audio source corresponding to music service provider C" through the vendor selection interface in the human-computer interaction layer, the business logic layer instantiates the C_Music_Adapter corresponding to music service provider C through the AdapterFactory using reflection. Thereafter, all control commands for music service provider C are handled by this C_Music_Adapter.

[0129] Step 7: Architecture Decoupling Verification: The system needs to adjust the UI display style in the human-computer interaction layer (e.g., to adapt to the red theme of music service provider C), while the code in the application layer and business logic layer remains completely unchanged.

[0130] It should be noted that, in conjunction with the above embodiments, a core design principle of the system framework provided in this application is that all code in the upper three layers (business logic layer, application layer, and human-computer interaction layer) uses the general data structures (PlayableItem, PlayState, Playlist, PlayerState enumeration, etc.) defined in the application layer, and no vendor-specific data types appear. This design can bring the following technical effects: First, common media components and frameworks can be used directly: Since all data flows through the upper layer in a common format, the common UI components provided by the framework (such as the PlaybackControlBar, SongListFragment, LyricView, and SearchSuggestionEngine) can work in different vendor scenarios without modification. For example, SongListAdapter... <playableitem>The same Adapter code can be reused in both the music playlist page and the music service provider B's playlist page because its bound data model is always PlayableItem.

[0131] Secondly, there is zero modification to the upper-layer code when switching vendors: When a user switches from audio source A to audio source B, the business logic layer switches to B_Music_Adapter through AdapterManager, and the upper three layers of code do not need to be modified at all - because the upper layer communicates with the access device through a common access interface and a common data model. Switching the access device only changes the interface implementation, while the interface signature and data format remain completely unchanged.

[0132] Secondly, UI development is decoupled from underlying vendors: UI developers in the human-computer interaction layer only need to understand the general data model defined in the application layer, without needing to learn the proprietary data structures and API documentation of various music service vendors. UI components can be developed and tested independently using mock data (populating the common fields of PlayableItem and PlayState), without relying on the actual vendor SDK environment.

[0133] Finally, the common logic is truly reusable: the nine categories of common logic in the business logic layer, such as playback control, state management, and exception handling, rely only on common data structures and common access interfaces (rather than specific vendor types), achieving true "write once, reuse across all vendors," with a common logic reuse rate of 85-90%. When adding a new vendor, this common logic can be used directly without any modification, with an integration time of approximately 5-10 person-days and only about 10 interface methods need to be implemented.

[0134] Furthermore, due to the need to define a general interface, a unified data model, and an adapter management mechanism, the initial investment was 15 person-days, slightly higher than the traditional 10 person-days. However, in the first vendor integration phase, thanks to the standardized definition of the interface and the reuse of basic capabilities, this application only required 15 person-days to complete, saving 50% of the time compared to the traditional 30 person-days. Particularly noteworthy is that when expanding to the second and third vendor integrations, this application only required 5 person-days for incremental adapter development each time, without modifying the upper-layer business logic, while the traditional approach required a repeated investment of 30 person-days per vendor. In the scenario of integrating three music service vendors, the traditional approach accumulated 100 person-days, while this application only required 40 person-days, shortening the overall development cycle by 60% (saving 60 person-days). Therefore, although this application involves a certain time investment in the initial architecture design phase, as the number of integrated vendors increases, its "plug-in" expansion advantage becomes exponentially apparent, significantly reducing long-term R&D costs and maintenance complexity.

[0135] The following sections, in conjunction with the aforementioned embodiments, will elaborate in detail on the specific implementation methods of the predefined unified interface, general data structure, accessor registration, accessor implementation, accessor integration and use, and the end-to-end flow of audio source switching provided in this application. For ease of understanding, key code snippets will be used to illustrate the following content.

[0136] I. Unified Interface Definition When integrating with a new vendor, developers need to implement the following standard interfaces: / /

[0137] Unified interface for vendor access devices (general access interface)

[0138] [General Access Interface] This interface is a standardized communication contract between the business logic layer and the vendor access layer.

[0139] This interface defines the set of methods that all music vendor access points must implement, enabling the upper business logic layer to... Operate any music service provider transparently, without needing to be aware of underlying differences between providers.

[0140]

[0141] [Relationship with native interfaces of various vendors] The generic access interface is a "translation layer"—each accessor implementation class (For example, A_Music_Adapter) internally calls the corresponding vendor's native interface when implementing the methods of this interface. Complete the conversion from "unified standard call" to "vendor-specific call".

[0142] Analogy: The universal access interface is like the USB-C interface standard, and the SDKs from different manufacturers are like different peripheral protocols. A connector is a converter / adapter.

[0143]

[0144] Design Principles - Single Responsibility: The overall interface focuses on the core responsibility of "vendor integration". - Version compatibility: The interface design considers backward compatibility, and new methods provide default implementations. - High scalability: Reserves expansion points to support seamless integration of new features. / interface UniversalMediaAdapter { / / ========== Lifecycle Class Methods ========== /

[0145] Initialize the access controller – Complete the authentication configuration and initialization of the SDK / API.

Core Responsibilities

[0146] 3. The initialization result is returned by wrapping it in Kotlin Result, which facilitates unified handling of success / failure by the upper layer.

[0147]

[0148] @param context The Android context, typically used for SDK initialization or resource access. @param config Unified authentication configuration (appId, appKey, appSecret, accessToken, etc.) @return Result <unit>Initialization result (success / failure reason) / suspend fun initialize(context: Context, config: AuthConfig): Result <unit> / / ========== Playback control methods ========== /

[0149] Play the specified song

Core Responsibilities

[0150] @param item A generic playable item; the data format is vendor-independent. @return Result <unit>Playback call result / suspend fun playItem(item: PlayableItem): Result <unit> /

[0151] Pause playback - directly delegate to the manufacturer's native pause method / suspend fun pause(): Result <unit> /

[0152] Jump to the specified playback position @param position Target position (milliseconds), generated by dragging the upper SeekBar. / suspend fun seekTo(position: Long): Result <unit> /

[0153] Adjust volume @param volume Volume value (0.0-1.0), generated by the upper volume slider. / suspend fun setVolume(volume: Float): Result <unit> / / ========== Status query methods ========== /

[0154] Get the current playback status

Core Responsibilities

[0155] Search for songs

Core Responsibilities

[0156] @param keyword Search keywords @param page Page number (default is page 1) @return Result <List <playableitem>Search results (uniform format) / suspend fun searchSong(keyword: String, page: Int = 1): Result <List <playableitem>> /

[0157] Get user playlists [Core Responsibilities] Same as above, after obtaining the user's playlist, convert the vendor's playlist model into a unified Playlist model. / suspend fun getUserPlaylist(userId: String): Result <List <playlist>> / / ========== State Listener Class Methods ========== /

[0158] Register playback status listener

Core Responsibilities

[0159] Release all resources occupied by the access point

Core Responsibilities

[0160] Playable Item Data Model – Framework Unified Data Structure All vendor access devices will convert their respective native data models to this model.

Field Semantic Description

[0161] @param title Song title, used for UI display.

[0162] @param artist: Artist name, used for UI display and retrieval.

[0163] @param album The album name, used for display on the product details page.

[0164] @param duration Total song duration in milliseconds (ms), used for progress bar rendering and playback progress calculation.

[0165] @param coverUrl The web address (URL) of the album cover image, used to load and display the album cover asynchronously; defaults to an empty string.

[0166] / data class PlayableItem( val id: String, / / Unique ID of the song val title: String, / / Song title val artist: String, / / Artist name val album: String, / / Album name val duration: Long, / / Duration (milliseconds) val coverUrl: String = "" / / Cover URL ) /

[0167] Playback State Enumeration - Unified State Definition for the Framework / enum class PlayerState { IDLE, / / Idle (no playback task) PLAYING, / / Playing PAUSED, / / Paused BUFFERING ERROR / / Playback error } /

[0168] Authentication Configuration – Initialization Parameters for Each Vendor

Field Semantic Description

[0169] @param appKey is the application's public key, used for signing API requests or initializing the SDK, and is usually transmitted in plaintext with the request.

[0170] @param appSecret The application's private key, used for signing API requests. It must be kept strictly confidential and not transmitted in plaintext over the network.

[0171] @param accessToken Access token, mainly used in the authentication process, represents the user's login status and authorization information on the application side, and usually has an expiration period.

[0172] / data class AuthConfig( val appId: String = "", / / Application ID (required for SDK implementation) val appKey: String = "", / / Application key (general) val appSecret: String = "", / / Application key (required for API signing) val accessToken: String = "" / / Access token (required for OAuth authentication) ) For example, Table 2 shows data structure transformation examples for different music service providers.

[0173] Table 2 shows examples of data structure conversions for different music service providers.

[0174] III. Access Implementation Example 1: SDK Access Implementation (SDK Access Method) / /

[0175] SDK Accessor

[0176] [Overall Description] This access controller implements a general access interface, encapsulating the access method as a call to the native SDK of music service provider A. - Integration method: SDK integration (the vendor provides a complete SDK, and local method calls are used) - Core responsibility: To convert the calling methods and data models of music service provider A's SDK into the standard format of this framework. - Transparent to upper layers: The business logic layer calls through a common access interface and is unaware that the underlying SDK is from music service provider A. / class A_Music_Adapter : General access interface { / / The native instance of music service provider A's SDK is encapsulated internally by this accessor and is not exposed externally. / / This instance cannot be accessed directly by the upper-level code; it must be operated indirectly through a generic access interface method. private lateinit var aMusicSDK: aMusicSDK /

[0177]

Method 1

[0178] [Detailed Explanation of Steps] Step 1: Switch to the IO thread using withContext(Dispatchers.IO). Avoid SDK initialization blocking the Android main thread Step 2: Call A_Music_SDK.getInstance() to obtain a singleton instance of the SDK. (Music service provider A's SDK uses the singleton pattern, with only one instance globally.) Step 3: Call the aMusicSDK.init() method, passing in: - context: Android context, used internally by the SDK for creating services, etc. - config.appId: Application ID, used for SDK authentication - config.appKey: Application key used for SDK authentication and signing. Step 4: After init() succeeds, the SDK becomes usable and can then call interfaces such as playback and search. Step 5: Return Result.success(Unit) to indicate that initialization was successful. Step 6: If an exception is thrown during initialization, catch it and return Result.failure(e). / override suspend fun initialize( context: Context, config: AuthConfig ): Result <unit>= withContext(Dispatchers.IO) { try { / / Get the SDK Singleton - A globally unique SDK instance of music service provider A aMusicSDK = A_MusicSDK.getInstance() / / Initialize SDK - pass in context and authentication parameters aMusicSDK.init(context, config.appId, config.appKey) / / Returns a success result Result.success(Unit) } catch (e: Exception) { / / If initialization fails (e.g., network failure, authentication failure), an exception is returned. Result.failure(e) } } /

[0179]

Method 2

[0180] [Detailed Explanation of Steps] Step 1: Receive the PlayableItem unified data structure model passed from the upper application layer. Step 2: Extract item.id as the unique identifier for the song. (Note: No data model conversion is needed here, because PlayableItem is already a unified model. You can directly pass its id field to the SDK.) Step 3: Call aMusicSDK.play(item.id) to execute playback. Music service provider A's SDK plays the song based on its ID and returns a success / failure message. Step 4: Return to playback results / override suspend fun playItem(item: PlayableItem): Result <unit>= withContext(Dispatchers.IO) { try { / / Directly call the SDK playback method using the item ID of the unified model aMusicSDK.play(item.id) Result.success(Unit) } catch (e: Exception) { Result.failure(e) } } /

[0181] [Method 3] Pause playback - Delegate the pause method to the SDK / override suspend fun pause(): Result <unit>= withContext(Dispatchers.IO) { try { aMusicSDK.pause(); Result.success(Unit)} catch (e: Exception) { Result.failure(e)} } /

[0182] [Method 4] Jump to a specified playback position - Delegate the jump method to the SDK / override suspend fun seekTo(position: Long): Result <unit>= withContext(Dispatchers.IO) { try { aMusicSDK.seek(position); Result.success(Unit)} catch (e: Exception) { Result.failure(e)} } /

[0183]

Method 5

[0184]

Method 6

[0185] [Detailed Explanation of Steps - Core Example of Data Transformation] Step 1: Call aMusicSDK.getState() to get the current state of the SDK of music service provider A. Returns an A_State enumeration (such as AState.PLAYING, etc.). Step 2: Map the A_State enumeration to the PlayerState enumeration of this framework using the when expression. - A_State.PLAYING → PlayerState.PLAYING - A_State.PAUSED → PlayerState.PAUSED - A_State.BUFFERING → PlayerState.BUFFERING - Other states → PlayerState.IDLE (default mapping) Step 3: Return a unified PlayerState enumeration; the upper layer does not need to know the internal state definition of music service provider A. / override suspend fun getCurrentState(): Result <playerstate>= withContext(Dispatchers.IO) { try { val A_State = aMusicSDK.getState() / / State mapping: Internal state of music service provider A → Unified state of this framework val state = when (A_State) { A_State.PLAYING ->PlayerState.PLAYING A_State.PAUSED ->PlayerState.PAUSED A_State.BUFFERING ->PlayerState.BUFFERING else ->PlayerState.IDLE } Result.success(state) } catch (e: Exception) { Result.failure(e) } } /

[0186]

Method 7

[0187] [Detailed Explanation of Steps – Core Example of Data Model Transformation] Step 1: Call aMusicSDK.search(keyword, page) to retrieve search results for music service provider A. Returns the A_Song list (the native data model of music service provider A). Step 2: Iterate through each A_Song object using the map operator. Step 3: Map each field of A_Song to a field of PlayableItem: - song.id → id (Song ID: direct mapping) - song.title → title (song name: songName → title, field names are different) - song.artist → artist (singerName → artist, the field names are different) - song.album → album (Album: albumName → album, field names are different) - song.duration → duration (duration: interval → duration, the field names and meanings are different) - song.coverUrl → coverUrl (Cover URL: direct mapping) Step 4: Return to the PlayableItem list; the upper-level UI components can now use it directly.

[0188] [Differences in Logic] This section illustrates the differences in data structures among various vendors—music service vendor A uses songName / singerName / The albumName / interval name needs to be mapped to the title / artist / album / duration of this framework.

[0189] These mapping logics are encapsulated within the local accessor and will not propagate to higher layers.

[0190] / override suspend fun searchSong( keyword: String, page: Int ): Result <List <playableitem>>= withContext(Dispatchers.IO) { try { / / Call the SDK search interface to obtain the list of native data models of music service provider A val A_Songs = aMusicSDK.search(keyword, page) / / Convert the data model of music service provider A into the unified data model of this framework one by one. val items = A_Songs.map { song -> PlayableItem( id = song.songId, / / QQ: songId → Unicom: id title = song.songName, / / QQ: songName → unified: title artist = song.singerName, / / QQ: singerName → Unified: artist album = song.albumName, / / QQ: albumName → Uniform: album duration = song.interval, / / QQ: interval → Unified: duration coverUrl = song.coverUrl ) } Result.success(items) } catch (e: Exception) { Result.failure(e) } } /

[0191] [Method 8] Obtaining User Playlists - Simplified Example Implementation / override suspend fun getUserPlaylist(userId: String): Result <List <playlist>>= withContext(Dispatchers.IO) { / / In actual projects, this section calls the SDK to retrieve the playlist and convert it into a unified Playlist model. Result.success(emptyList()) } /

[0192] [Method 9] Register a playback status listener

[0193] [Detailed Explanation of Steps] Step 1: Register a status change listener callback with the SDK of music service provider A. (Characteristics of the SDK approach: event-driven / push mode – the SDK actively pushes state changes) Step 2: When the playback status of the music service provider A's SDK changes (e.g., start playing, pause, buffer, etc.). The SDK will automatically call back to this closure, passing in the A_State enumeration value. Step 3: Convert the A_State enumeration to the PlayerState enumeration of this framework using a when expression. Step 4: Call listener.onStateChanged() to notify the upper-layer Service business logic layer of the unified state.

[0194] [Comparison with API method] The SDK method is a push mode (real-time callback), while the API method requires polling (periodic query). However, both methods provide the same interface to the upper-level listener—listener.onStateChanged(PlayerState). / override fun registerPlayStateListener(listener: PlayStateListener) { aMusicSDK.registerStateListener { A_State -> / / Convert the music service provider's ASDK state to the unified state of this framework val state = when (A_State) { A_State.PLAYING ->PlayerState.PLAYING A_State.PAUSED ->PlayerState.PAUSED A_State.BUFFERING ->PlayerState.BUFFERING else ->PlayerState.IDLE } / / Notify the upper layer that the state has changed listener.onStateChanged(state) } } /

[0195]

Method 10

[0196]

Meaning of Steps

[0197] API Access Provider

[0198] [Overall Description] This access controller implements a generic access interface, encapsulating the RESTful API calls of music service provider B, which uses API access as the access method. - Access method: API access (the vendor provides a RESTful API, which is invoked via HTTP requests) - Core responsibility: To convert HTTP request and JSON response data into the standard format of this framework. - The core difference between this and the SDK approach: (1) Initialization method: Configure an API service instance (Retrofit) instead of an SDK singleton. (2) Playback control: via HTTP request instead of local method call (3) Status acquisition: The status is obtained by periodically polling the HTTP interface (actively pulling). Instead of SDK event-driven callbacks (passive push) (4) Data field mapping: different field names and nested structures / class B_Music_Adapter : General access interface { / / API Service Instance - A Network Request Client Generated Based on Retrofit / / All operations on music service provider B are completed via HTTP requests. private lateinit var apiService: B_ApiService / / Polling the Job reference—used to cancel polling during release() to prevent coroutine leaks. private var pollingJob: Job? = null /

[0199]

Method 1

[0200] [Detailed Explanation of Steps] Step 1: Switch to the IO thread to perform network-related initialization. Step 2: Construct a B_ApiService instance, passing in the appKey and appSecret. - appKey: The identity identifier used for API requests. - appSecret: Used to generate API request signatures (HMAC-SHA256, etc.) - Difference from SDK method: SDK only requires appId / appKey, while API also requires appSecret for signing. Step 3: The API service internally configures Retrofit's BaseUrl, interceptors (signature / logging), etc. Step 4: Return the initialization result / override suspend fun initialize( context: Context, config: AuthConfig ): Result <unit>= withContext(Dispatchers.IO) { try { / / Building an API service instance — Configuring the signing key apiService = B_ApiService(config.appKey, config.appSecret) Result.success(Unit) } catch (e: Exception) { Result.failure(e) } } /

[0201] [Method 2] Playing a song – achieved via HTTP API request

[0202]

Difference from SDK method

[0203]

Methods 3-5

[0204]

Method 6

[0205] [Detailed Explanation of Steps] Step 1: Send an HTTP GET request to the status query interface Step 2: Obtain the HTTP response JSON object (e.g., {"status":"playing"}) Step 3: Map the string status returned by the API to a unified enumeration of this framework: - "playing" → PlayerState.PLAYING - "paused" → PlayerState.PAUSED - Other → PlayerState.IDLE

[0206]

Difference from SDK method

[0207] [Method 7] Searching for songs – API method, demonstrating the complete data model transformation process.

[0208] [Detailed Explanation of Steps] Step 1: Send an HTTP GET request to the search API Step 2: Retrieve the songs array (JSON format) from the HTTP response. Step 3: Iterate through each song object and map the JSON fields returned by the API to PlayableItems: - song.id → id (direct mapping) - song.name → title (NE uses name to represent the song title) - song.artists[0].name → artist (NE's artist information is a nested array, so you need to take the first element) - song.album.name → album (NE's album information is a nested object, so you need to retrieve the inner name field) - song.duration → duration (NE uses dt to represent duration, the field names are different) - song.album.picUrl → coverUrl (The cover URL is nested within the album object)

[0209] [Differences in logic] The JSON structure returned by the API of music service provider B is completely different from that of the SDK of music service provider A: Different field names (name vs songName), different nesting structures (artists array vs singerName string) The cover path is different (album.picUrl vs coverUrl). These differences are encapsulated within this method.

[0210] / override suspend fun searchSong( keyword: String, page: Int ): Result <List <playableitem>>= withContext(Dispatchers.IO) { try { / / Initiate an HTTP search request val response = apiService.search(keyword, page) / / Traverse the search results and convert them one by one into a unified data model val items = response.songs.map { song -> PlayableItem( id = song.id, / / NE: id → Unified: id title = song.name, / / NE: name → Uniform: title (different field names!) artist = song.artists.firstOrNull()?.name ?: "", / / NE: artists[0].name → Unified: artist (takes the first element from a nested array!) album = song.album.name, / / NE: album.name → Uniform: album (nested object!) duration = song.dt, / / NE: dt → Uniform: duration (different field names!) coverUrl = song.album.picUrl / / NE: album.picUrl → Uniform: coverUrl (different paths!) ) } Result.success(items) } catch (e: Exception) { Result.failure(e) } } /

[0211]

Method 8

[0212] [Detailed Explanation of Steps] Step 1: Initiate an HTTP request to retrieve the user's playlist. Step 2: Convert each playlist JSON object returned by the API into a unified Playlist model: - playlist.id → id - playlist.name → name - playlist.coverImgUrl → coverUrl (different field names) - playlist.trackCount → songCount (the field names and semantics are different) / override suspend fun getUserPlaylist(userId: String): Result <List <playlist>>= withContext(Dispatchers.IO) { try { val response = apiService.getUserPlaylist(userId) val playlists = response.playlists.map { playlist -> Playlist id = playlist.id, name = playlist.name, coverUrl = playlist.coverImgUrl, / / NE: coverImgUrl → unified: coverUrl songCount = playlist.trackCount, / / NE: trackCount → Unified: songCount creator = "", description = "" ) } Result.success(playlists) } catch (e: Exception) { Result.failure(e) } } /

[0213] [Method 9] Registering a playback status listener – Key differences from API methods

[0214] [Detailed Explanation of Steps] Step 1: Launch a background coroutine (CoroutineScope(Dispatchers.IO).launch) Step 2: Continuously poll in the while(isActive) loop: - Send an HTTP request to check the server status every 1 second (delay(1000)). - Map the returned status string to a unified PlayerState enumeration - Notify the upper layer via listener.onStateChanged() Step 3: When the coroutine is canceled (such as switching audio sources or exiting the application), automatically stop polling.

[0215] Key differences between this method and the SDK method - SDK approach (music service provider A): Event-driven / push mode – SDK actively calls back, offering good real-time performance and no additional network overhead. - API method (music service provider B): Polling mode - the access device queries periodically, which incurs network overhead and latency. However, the external interface is completely consistent—the upper layer neither knows nor cares whether the lower layer uses push or polling. This is a typical limitation of API access methods—RESTful APIs do not support server-side state pushing like SDKs do. / override fun registerPlayStateListener(listener: PlayStateListener) { / / Start a background coroutine to continuously poll the playback status. pollingJob = CoroutineScope(Dispatchers.IO).launch { while (isActive) { / / Continuously poll until the coroutine is canceled. try { / / Actively query playback status via HTTP request val response = apiService.getStatus() / / Map the string status returned by the API to a unified enumeration val state = when (response.status) { "playing" ->PlayerState.PLAYING "paused" ->PlayerState.PAUSED else ->PlayerState.IDLE } / / Notify the upper layer of state changes listener.onStateChanged(state) } catch (e: Exception) { / / Notify the upper layer of the error status when there is a network anomaly listener.onStateChanged(PlayerState.ERROR) } delay(1000) / / Poll once every 1 second } } } /

[0216]

Method 10

[0217]

Meaning of Steps

[0218] / / json { / / [vendorAdapters] Vendor Adapter Registration List / / This array defines all registered accessors, which can be loaded on demand at runtime via AdapterFactory. "vendorAdapters": [ { / / [type] Access type identifier / / Corresponds one-to-one with the parameters of loadAdapter("amusic") in the code. / / Used for runtime identification and accessor lookup "type": "amusic", / / [className] The fully qualified name of the accessor implementation class / / Used for reflection loading: Class.forName(className).newInstance() / / Modifying this field will switch the accessor implementation; no code modification is required. "className": "com.example.media.adapter.A_Music_Adapter", / / [priority] Receiver priority (the smaller the number, the higher the priority) / / Used for automatic selection of the default audio source and priority sorting when multiple accessors are running concurrently. "priority": 1, / / [config] Authentication configuration information for this vendor's access device / / Pass in when calling adapter.initialize() "config": { "appId": "10001", / / Application ID (assigned by music service provider A's open platform) "appKey": "your_app_key" / / Application key (used for SDK authentication and signing) } }, { / / Music service provider B access point configuration "type": "bmusic", "className": "com.example.media.adapter.B_Music_Adapter", "priority": 2, "config": { "appKey": "your_app_key", / / API request identifier "appSecret": "your_app_secret" / / API request signing key (required additionally for API requests) } } ], / / [defaultAdapter] The default adapter type loaded when the application starts. / / Must match the value of a certain type field in vendorAdapters "defaultAdapter": "amusic } V. Integration and Use of the Access Device Step 1: Integrate the framework in Gradle / / gradle dependencies { / / [Required] Media Framework Core Module / / Contents included: / / - General access interface definition (interface specification layer, belonging to the business logic layer) / / - Unified data model such as PlayableItem / PlayState (belongs to the application layer) / / - AdapterFactory (reflection loading mechanism) / / - MediaPlayerController (General Logic) / / - Common modules such as event bus, exception handling engine, and state management engine / / Note: The core module does not contain any vendor-specific implementation code. implementation project(:media-framework-core) / / [Optional Dependencies] Access Modules from various vendors (import as needed, plug and play) / / Each access module is compiled independently; modules that are not imported will not be packaged into the APK. / / Introducing rules: Flexible selection based on vehicle model / regional requirements implementation project(:adapter-amusic) / / SDK accessor implementation project(:adapter-bmusic) / / API accessor / / Implementation project(:adapter-cmusic) / / Data source accessor } Step 2: Initialize the framework in the Application class (including comments). / /

[0219] Application initialization – Registering all accessors when the application starts.

[0220] [Detailed Explanation of the Steps] Step 1: Call MediaFramework.initialize(this) to initialize the media framework core. The framework internally handles: thread pool creation, event bus initialization, cache initialization, etc. Step 2: Call registerAdapter() to register the accessor—binding the accessor identifier to the implementation class. Parameter 1 (string): Unique identifier for the access device, corresponding to the type field in the configuration file, used at runtime to find the access device. Parameter 2 (Class object): The Class object of the accessor implementation class, used for reflection instantiation (Class.forName + newInstance). Step 3: Call setDefaultAdapter() to set the default adapter—this adapter is automatically loaded when the application starts. / class MainApplication : Application() { override fun onCreate() { super.onCreate() / / Step 1: Initialize the media framework (complete infrastructure initialization) MediaFramework.initialize(this) { / / Step 2: Register the SDK Integrator / / "amusic" — Access device identifier, used to find and switch access devices later. / / amusicAdapter::class.java — The accessor implementation class, used for reflection instantiation. registerAdapter("amusic", amusicAdapter::class.java) / / Step 3: Register the API Integrator registerAdapter("bmusic", B_Music_Adapter::class.java) / / Step 4: Set the default access point - automatically load music service provider A when the application starts / / This value must match an identifier previously registered using registerAdapter(). setDefaultAdapter("amusic") } } } Step 3: Use frames to play music in the Activity / /

[0221] Player Activity – Demonstrates how to play music using a frame.

[0222] [Detailed Explanation of the Steps] Step 1: Obtain the MediaPlayerController singleton using lazy loading MediaPlayerController is the unified playback control entry point exposed by the framework. Step 2: Register a playback status listener in onCreate. When the playback status changes (play / pause / buffering / error), the framework automatically calls the updateUI() callback. Step 3: Build a unified data model for PlayableItem Developers only need to fill in common fields and do not need to care about which vendor is behind the underlying system. Step 4: Call playerController.play(item) to start playback. Internal process of the framework: playerController → Service Business Logic Layer (Player Control Center) → General Access Interface → amusicAdapter.playItem() → Music Service Provider ASDK Step 5: Process playback results – onSuccess() indicates successful playback, onFailure() indicates failure. / class PlayerActivity : BaseActivity() { / / Step 1: Obtain the Media Playback Controller Singleton / / MediaPlayerController encapsulates all common playback control logic private val playerController by lazy { MediaPlayerController.getInstance() } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) / / Step 2: Register playback status listener / / When the playback status changes (e.g., start playing, paused, buffering, error). / / The framework automatically calls back this lambda, passing in the latest PlayerState. playerController.registerStateListener { state -> / / Update the UI based on the unified playback status (no need to determine the manufacturer's origin). updateUI(state) } / / Step 3: Perform playback operation in the coroutine lifecycleScope.launch { / / Step 4: Construct the song data to be played (using a unified data model) val item = PlayableItem( id = "123456", / / Unique ID of the song (from search results or playlist) title = "Example Song", / / Song Title artist = "example singer", / / singer name album = "Example album", / / Album name duration = 240000 / / Duration 240000 milliseconds = 4 minutes ) / / Step 5: Call the unified playback interface to play the song / / The framework automatically completes the following process (transparent to developers): / / ① The business logic layer receives the play() request / / ② The state management engine checks the current state and confirms that playback is possible. / / ③ Call the playItem() method of the currently active access device through the general access interface. / / ④ The access device internally calls the manufacturer's native SDK / API to perform playback. / / ⑤ The playback status callback returns along the original path, notifying the UI to update. playerController.play(item) .onSuccess { / / Playback successful: The UI has automatically updated in the status listener. / / Additional processing can be done here (such as disabling the loading animation). } .onFailure { e -> Playback failed: Error message displayed / / Exceptions have been uniformly packaged into standard exception types by the exception handling engine. showError(e.message) } } } } In some embodiments, to address the problem of hard-coded coupling between the access device and business logic in traditional architectures, this application proposes a dynamic adapter loading scheme based on the factory pattern and reflection mechanism. This mechanism postpones the instantiation process of the access device from the compile-time to the runtime, and achieves "plug-and-play" and full lifecycle management of the access device by driving it through configuration files rather than code logic.

[0223] The following is the core implementation logic of AdapterFactory: / / /

[0224] Access Factory – Dynamically creates access instance via reflection. Core value: Switching access providers only requires modifying the JSON configuration file, without changing any Java / Kotlin code. / class AdapterFactory { /

[0225] Dynamically create accessor instances using reflection @param className The fully qualified name of the accessor class, read from the configuration file. For example: "com.example.media.adapter.A_Music_Adapter" @return Instance of a generic access interface type / fun createAdapter(className: String): General access interface { / / Step 1: Load the accessor class via reflection using Class.forName() / / Pass in the fully qualified name string of the class, which the Java Virtual Machine will look up and load at runtime. / / We don't need to know which specific accessor class it is at compile time (no import required). val adapterClass = Class.forName(className) / / Step 2: Create an instance using getDeclaredConstructor().newInstance() / / Equivalent to new A_Music_Adapter(), but the class name is determined by a runtime string variable. val adapter = adapterClass.getDeclaredConstructor().newInstance() / / Step 3: Upcast the instance to a generic access interface type and return it / / The upper-level caller only sees the general access interface and is unaware of the specific implementation class. Return adapter as general access interface } } / / ===== Usage Examples ===== / / Scenario: After reading the accessor class name from the configuration file, create an instance using reflection. val config = loadAdapterConfig() / / Read configuration from JSON configuration file / / config.className = "com.example.media.adapter.A_Music_Adapter" val adapter = AdapterFactory().createAdapter(config.className) / / The actual type of the adapter is A_Music_Adapter, but the user only sees the generic access interface. adapter.initialize(context, config.authConfig) Based on the aforementioned reflection capability, this application implements the following three core mechanisms: Configurable adapter selection: The system determines the currently active accessor by parsing the vendorAdapters configuration table. Switching audio sources only requires modifying the className field in the configuration file, without modifying any business code, achieving "configuration equals change".

[0226] Hot Swapping: Based on a unified interface and lifecycle management (initialize / release), the system supports destroying old adapter instances and creating new ones while the application is running.

[0227] Full lifecycle management: The factory class uniformly manages the state migration of the adapter, ensuring that the resources of the old instance (such as network connection, audio focus, and hardware resources) have been completely released before the new instance is created, thus avoiding resource leaks.

[0228] In some embodiments, before sending the second control command to the vendor access layer, candidate vendor access devices in operation are identified. If the candidate vendor access device and the target vendor access device are inconsistent, the candidate vendor access device is shut down and the target vendor access device is activated. The specific implementation code for this step is as follows: / /

[0229] Audio source switcher – responsible for managing hot-switching between different music service providers. A plug-and-play mechanism has been implemented, requiring no modification to the upper-layer UI and Service business logic code during the switching process. / class MusicSourceSwitcher { /

[0230] A unified method for switching audio sources (including optimizations for identifying audio sources from the same source). @param targetSource The identifier for the target audio source, such as "amusic" or "bmusic". / fun switchToSource(targetSource: String) { / / Step 1: Get the currently active access devices val currentAdapter = adapterManager.getCurrentAdapter() / / Step 2: Determine whether the audio source corresponding to the candidate vendor's access device is the same as that corresponding to the target vendor's access device. / / If they are the same, there is no need to switch; return directly to avoid unnecessary resource release and reinitialization. if (currentAdapter?.getSourceType() == targetSource) { Log.d(TAG, "Already using $targetSource, skip switching") return / / Skip the switch to improve response speed } / / Step 3: Uninstall the current candidate vendor access point and release the resources it occupies (memory, network connection, player instance, etc.) adapterManager.unloadCurrentAdapter() / / Step 4: Dynamically load the target vendor's access module via the access manager / / The parameter "targetSource" is a unique identifier for the access point, corresponding to the type field in the configuration file. adapterManager.loadAdapter(targetSource) { adapter -> / / Step 5: After obtaining the loaded accessor instance via callback, / / Notify the media playback controller to register the access point as the currently active playback source. mediaPlayerController.switchAdapter(adapter) } } /

[0231] Switching to music service provider A – entrusting a unified switching method / fun switchToamusic() { switchToSource("amusic") } /

[0232] Switching to music service provider B – entrusting the switching method to a unified approach / fun switchTobmusic() { switchToSource("bmusic") } } Based on the aforementioned technical solutions, current multi-vendor interface implementations differ significantly, making it difficult to balance unified abstraction granularity with functional scalability; heterogeneous multimedia data structures lack uniformity, making it difficult to guarantee universal abstraction modeling and multi-vendor compatibility. Furthermore, application modules are heavily coupled, making it difficult to guarantee circular dependency decoupling and architectural stability; the underlying logic of each vendor differs significantly, making it difficult to unify global interaction logic and user experience consistency; and the in-vehicle multimedia business scenarios are complex, involving numerous interactions with the system and application layers, making it difficult to guarantee compatibility and scalability when extracting universal logic. Therefore, the in-vehicle multi-source media control system provided in this application can effectively solve the pain point of deep coupling between business logic, adaptation logic, and interaction logic in multi-source access scenarios. This application encapsulates core business logic such as playback control, state management, exception handling, and data synchronization in the business logic layer, constructing a stable "universal kernel." Each vendor's access device only needs to implement data conversion logic related to its private protocol, without needing to repeatedly write similar control code. This "write once, reuse in all scenarios" mechanism makes the marginal development cost after the first vendor's access approach zero, significantly shortening the iteration cycle of multi-source projects. Secondly, through a strict five-layer architecture, this application clearly defines the single responsibility and unidirectional dependency relationship of each layer. Utilizing the interface isolation principle, it completely breaks the strong coupling and circular dependencies between modules in the traditional model, making the system architecture clearer and more stable, and significantly reducing the risk of systemic crashes caused by local modifications. Thirdly, the decoupling architecture effectively reduces code redundancy, and actual tests show a 30%-40% reduction in memory usage on the vehicle's infotainment system, improving operational smoothness. Finally, it provides standardized access specifications, allowing developers to focus only on differences in vendor-specific protocols without delving into the underlying interaction logic, effectively lowering the development threshold and skill requirements. This application balances system stability, scalability, and maintainability, and is particularly suitable for multi-source concurrent management in in-vehicle environments.

[0233] like Figure 3 As shown, the in-vehicle multi-source media control method provided in this application embodiment is applied to the above-mentioned in-vehicle multi-source media control system. The method includes: S301, Receive the first control command issued by the music playback interface in the vehicle.

[0234] The first control command is used to indicate the track to be controlled, as well as the sound source and control actions of the track to be controlled.

[0235] The specific implementation of step S301 can be referred to the description of the above embodiments, and will not be repeated here.

[0236] S302, Call up the track information corresponding to the track to be controlled.

[0237] The specific implementation of step S302 can be referred to the description of the above embodiments, and will not be repeated here.

[0238] S303. When the target music service provider's access device is an SDK access device, the track information is converted from a predefined general data format to the target data structure to obtain the target track information.

[0239] The data format for track information is a predefined general data format; the target data structure is the calibration data structure corresponding to the target music service provider.

[0240] The specific implementation of step S303 can be referred to the description of the above embodiments, and will not be repeated here.

[0241] S304. Control the target manufacturer's access device to perform control actions based on the target track information.

[0242] The specific implementation of step S304 can be referred to the description of the above embodiments, and will not be repeated here.

[0243] Based on the above technical solution, this application adds an independent vendor access layer to abstract and encapsulate heterogeneous access methods such as SDKs and APIs, forming a unified vendor accessor interface. This not only allows for the smooth conversion of complex private objects returned by the SDK into system-wide generic objects through the data structure definition layer in SDK access scenarios, but also necessitates only adding the accessor implementation and data mapping when integrating new vendors, without requiring changes to the upper-layer business logic. This transforms the access mode from "overall reconstruction" to "plug-in extension," significantly shortening the development cycle. Simultaneously, this application predefines a universal data format circulating throughout the system through the data structure definition layer. Unlike traditional solutions where the user interface layer is forced to rely on vendor-specific data models (a pseudo-decoupling model), this application unifies the private data formats of various vendors into a predefined universal data format. This completely frees the human-computer interaction layer and business logic layer from the constraints of vendor data structures, achieving true separation of data and business logic. Common business logic (such as playback queue management and favorites logic) can be fully reused across different music service vendors, avoiding code redundancy and effectively reducing the storage space and memory consumption of the vehicle system.

[0244] Furthermore, this application employs a five-layer system architecture, clearly defining the single responsibility of each layer: the business logic layer handles core business rules such as playback control and state management; the vendor access layer adapts to specific vendor interface calls; and the data structure definition layer focuses on data format conversion and mapping. This architecture completely solves the problem of deeply intertwined general logic and adaptation logic in traditional solutions, reducing code complexity. Developers can accurately pinpoint the scope of modifications during feature iterations or bug fixes, significantly improving system stability and maintainability, and lowering the learning curve for new members.

[0245] like Figure 4 As shown in the embodiments of this application, an electronic device includes, but is not limited to, a processor 401 and a memory 402.

[0246] The memory 402 described above is used to store the executable instructions of the processor 401. It is understood that the processor 401 is configured to execute instructions to implement the in-vehicle multi-source media control method in the above embodiments.

[0247] It should be noted that those skilled in the art will understand that Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 4 This may indicate more or fewer components, or a combination of certain components, or a different arrangement of components.

[0248] Processor 401 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 402, and by calling data stored in memory 402, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 401 may include one or more processing units. Optionally, processor 401 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 401.

[0249] The memory 402 can be used to store software programs and various data. The memory 402 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 402 may include high-speed random access memory and may also include non-volatile memory. For example, the non-volatile memory may include at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0250] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 402 including instructions, which can be executed by a processor 401 of an electronic device to implement the methods in the above embodiments.

[0251] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0252] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by a processor 401 of an electronic device to perform the methods described above.

[0253] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of an electronic device, they implement the various processes of the above method embodiments and achieve the same technical effect as the above method. To avoid repetition, they will not be described again here.

[0254] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0255] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0256] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0257] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0258] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0259] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / playlist> < / playableitem> < / playerstate> < / unit> < / unit> < / unit> < / unit> < / unit> < / playlist> < / playableitem> < / playerstate> < / unit> < / unit> < / unit> < / unit> < / unit> < / playlist> < / playableitem> < / playableitem> < / playerstate> < / unit> < / unit> < / unit> < / unit> < / unit> < / unit> < / unit> < / playableitem>

Claims

1. A vehicle-mounted multi-source audio media control system, characterized in that, The in-vehicle multi-source media control system includes: a human-machine interaction layer, an application layer, a business logic layer, a manufacturer access layer, and a data structure definition layer; the human-machine interaction layer communicates with the business logic layer through the application layer; the manufacturer access layer communicates with both the business logic layer and the data structure definition layer. The human-computer interaction layer is used to respond to a first control command issued by the music playback interface in the vehicle, and forward the first control command to the business logic layer through the application layer; wherein, the first control command is used to indicate the track to be controlled, the sound source of the track to be controlled, and the control action; The business logic layer is used to generate a second control instruction using the track to be controlled, the control action, and the target music service provider corresponding to the sound source, and send the second control instruction to the provider access layer; The vendor access layer is used to call the track information corresponding to the track to be controlled; when the target vendor accessor corresponding to the target music service vendor is a software development kit (SDK) accessor, the data structure definition layer is used to convert the track information from the predefined general data format into a target data structure to obtain the target track information; the target vendor accessor is controlled to execute the control action based on the target track information; wherein, the data format of the track information is a predefined general data format; the target data structure is the calibration data structure corresponding to the target music service vendor.

2. The vehicle-mounted multi-source audio media control system according to claim 1, characterized in that, The vendor access layer is further configured to: control the target vendor access device to perform the control action based on the target track information when the target vendor access device is an application programming interface (API) access device or a data source access device.

3. The vehicle-mounted multi-source audio media control system according to claim 1, characterized in that, The vendor access layer is specifically used for: The target vendor access point is invoked using a predefined unified interface to retrieve the track information corresponding to the track to be controlled from the target music service provider through the target vendor access point. The predefined unified interface connects to the vendor access device corresponding to each music service vendor in the vendor access layer.

4. The vehicle-mounted multi-source audio media control system according to claim 3, characterized in that, The predefined unified interface includes multiple sub-interfaces corresponding one-to-one with multiple media control classes; the vendor access layer includes multiple sub-access layers corresponding one-to-one with the multiple media control classes; the vendor access layer is specifically used for: Determine the target media control class corresponding to the control action; The target sub-interface is used to call the target sub-accessor, so as to retrieve the track information corresponding to the track to be controlled from the target music service provider through the target sub-accessor; Wherein, the target sub-interface is the sub-interface corresponding to the target media control class among the plurality of sub-interfaces; the target sub-accessor is the sub-accessor corresponding to the target media control class among the plurality of sub-accessors.

5. The vehicle-mounted multi-source audio media control system according to claim 1, characterized in that, The business logic layer is also used for: Before sending the second control command to the vendor access layer, determine the candidate vendor access devices that are in operation; If the candidate vendor access device and the target vendor access device are inconsistent, the candidate vendor access device is shut down and the target vendor access device is activated.

6. The vehicle-mounted multi-source audio media control system according to claim 2, characterized in that, The vendor access layer is further configured to: during the execution of the control action, in response to a state change in the track to be controlled, send a state change notification instruction to the application layer through the business logic layer; wherein, the state change notification instruction includes: state change information of the track to be controlled and track information after the state change; the data format of the track information after the state change is a predefined general data format; The application layer is also used to send the state change notification instruction to the human-computer interaction layer when the music playback interface is in the display state. The human-computer interaction layer is also used to update the display content corresponding to the track to be controlled in the music playback interface based on the state change notification instruction.

7. The vehicle-mounted multi-source audio media control system according to claim 6, characterized in that, The vendor access layer is also used for: When the target manufacturer's access device is an SDK access device, the status information of the track to be controlled is detected in real time through the callback listener built into the target manufacturer's access device. When the target vendor access device is the API access device and the data source server, a status query request is sent to the target music service vendor at a preset time interval to detect the status information of the track to be controlled.

8. The vehicle-mounted multi-source audio media control system according to claim 4, characterized in that, The vendor access layer is also used for: In response to the access requirements of new music service providers, determine the media control class corresponding to the new music service providers; Based on the media control class corresponding to the newly added music service provider, the interface relationship between the multiple sub-interfaces and the multiple newly added sub-accessors is determined; the multiple newly added sub-accessors are multiple sub-accessors included in the newly added provider accessor corresponding to the newly added music service provider. Based on the aforementioned connection relationship and the calibration data structure of the newly added music service provider, register the new provider access point.

9. A method for controlling multi-source audio media in a vehicle, characterized in that, The in-vehicle multi-source media control method, applied to any one of claims 1-8, comprises: Receive a first control command from the music playback interface in the vehicle; wherein the first control command is used to indicate the track to be controlled, the sound source of the track to be controlled, and the control action; Call the track information corresponding to the track to be controlled; When the target music service provider's access device is a software development kit (SDK) access device, the track information is converted from the predefined general data format to the target data structure to obtain the target track information; The target vendor access device is controlled to execute the control action based on the target track information; wherein the data format of the track information is a predefined general data format; and the target data structure is the calibration data structure corresponding to the target music service vendor.

10. A vehicle, characterized in that, The vehicle is equipped with an in-vehicle multi-source media control system as described in any one of claims 1-8.

Images