Audio focus determination method, vehicle and electronic equipment

Abstract

The invention provides an audio focus determination method, a vehicle and electronic equipment, and relates to the technical field of vehicle-mounted information processing.The method comprises the steps that firstly, in response to a query request for the audio focus state of a target audio area, an audio focus state query identifier corresponding to the target audio area is generated, the target audio region is used for representing a physical or logic audio region designated as a query object in the vehicle-mounted system; secondly, based on the audio focus state query identifier, determining audio focus state information of a target audio region from a shared storage region, the shared storage region storing the audio focus state information of each audio region; and finally, based on the audio focus state information, determining a query result of the audio focus of the target audio region. The technical problem that in the prior art, regionalization state information of the audio focus in a vehicle-mounted system lacks a sharing mechanism is solved.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle information processing technology, and more particularly to a method for determining audio focus, a vehicle, and an electronic device. Background Technology

[0002] With the rapid development of smart cockpit technology, the audio interaction scenarios of in-vehicle systems are becoming increasingly complex, evolving from traditional single-channel audio playback to a more refined interaction mode that supports independent control of multiple audio zones, parallel use by multiple users, and coexistence of multiple application audio. As a core resource ensuring the orderly playback of audio, the audio focus needs to manage the occupancy and release status of different applications in different audio zones to ensure that various audio interactions do not conflict, thereby enhancing the user's driving experience.

[0003] To address the requirement for a system to support concurrent playback of multiple audio streams within physically or logically isolated audio regions, existing technologies typically rely on underlying audio services to provide state query interfaces. If upper-layer applications need to obtain the focus state of a specific audio region, they must interact with the underlying service through privately defined inter-process communication mechanisms (such as AIDL Binder). This approach results in tight coupling between system modules, significant communication overhead, and is generally limited by inter-process access permission barriers, increasing development complexity and system runtime burden.

[0004] In summary, existing technologies suffer from a lack of mechanisms for sharing the regionalized status information of audio focus in in-vehicle systems. Summary of the Invention

[0005] In view of the above problems, this disclosure provides a method, vehicle, and electronic equipment for determining audio focus to overcome or at least partially solve the current shortcomings in the overall traffic efficiency and safety of vehicle fleets. The technical solution is as follows: A method for determining audio focus, the method comprising: In response to a query request for the audio focus status of a target audio region, an audio focus status query identifier corresponding to the target audio region is generated. The target audio region is used to characterize the physical or logical audio region in the vehicle system that is designated as the query object. Based on the audio focus status query identifier, the audio focus status information of the target audio region is determined from the shared storage area, where the shared storage area stores the audio focus status information of each audio region; Based on the audio focus status information, the query result for determining the audio focus of the target audio region is obtained.

[0006] In this way, by generating corresponding identifiers in response to focus status query requests for target audio areas, specific physical or logical audio areas in the vehicle system are accurately associated, solving the problem of insufficient global query granularity in traditional solutions and adapting to the needs of independent management of multiple audio zones in smart cockpits. At the same time, by relying on the shared storage area to obtain audio focus status information, the dependence on the private cross-process communication channel of the underlying audio service is eliminated, significantly reducing system coupling and maintenance costs. Moreover, its query results can cover multiple scenarios such as "whether the audio area is occupied, information on the occupying application, and whether the target application occupies it", improving the versatility and adaptability of the solution. The concise "identifier generation-storage query-result confirmation" process also improves query efficiency and can support high-frequency in-vehicle interaction scenarios such as ambient lighting linkage and audio permission conflict determination, effectively optimizing the audio interaction experience during driving.

[0007] Optionally, the query result for determining the audio focus of the target audio region based on the audio focus state information includes: Determine whether the audio focus status information contains the application identifier of the target application; In response to the fact that the audio focus status information contains the application identifier of the target application, the query result is determined to be that the target application occupies the audio focus of the target audio region; If the application identifier of the target application is not included in the audio focus status information, the query result is determined to be that the target application does not occupy the audio focus of the target audio area.

[0008] This approach refines the logic for determining focus occupancy status, using the presence of the target application identifier in the audio focus status information as the core criterion. It establishes a clear and quantifiable standard, avoiding misjudgments of focus attribution caused by ambiguous rules in traditional solutions. This ensures consistent focus status judgments for the same audio region across different upper-layer applications. Simultaneously, it simplifies the judgment process, eliminating the need for complex parsing of status information. Conclusions can be quickly reached simply through identifier matching, improving the efficiency of focus determination. This adapts to high-frequency status query scenarios such as ambient light linkage and playback status display, effectively reducing function response latency and enhancing the user experience.

[0009] Optionally, the method further includes: In response to detecting that an application occupies or releases audio focus in the audio region, a state storage identifier corresponding to the audio region is generated, and information representing the focus occupancy state is written to the location associated with the state storage identifier in the system's native shared storage region.

[0010] In this way, by generating corresponding state storage identifiers when an application occupies or releases focus and writing the state information into the shared storage area, reliable data support is provided for subsequent query operations, realizing full lifecycle management of focus state and ensuring that the state information in the shared storage area is synchronized with the actual focus occupancy in real time. At the same time, relying on the system's native shared storage area to complete state publication replaces the traditional private interface communication method, breaks down the permission barriers of the underlying services, and allows more third-party upper-layer applications to easily obtain focus state, improving the compatibility and scalability of the solution.

[0011] Optionally, the method further includes: In response to detecting that the application releases the audio focus of the audio area, the value stored in the shared storage area at the location corresponding to the state storage identifier is cleared or deleted.

[0012] In this way, by promptly clearing or deleting the corresponding data in the shared storage area when the application releases the audio focus, the problem of "dirty data" caused by the failure to update the status information in a timely manner is avoided. This ensures that the focus status queried by the upper-layer application is completely consistent with the actual situation, and eliminates the misjudgment scenario where the application has released the focus but the status still shows that it is occupied. At the same time, timely cleaning up invalid data can optimize the resource usage of the shared storage area, reduce the accumulation of redundant data, improve the read and write efficiency of the storage area, and ensure the system performance stability in scenarios with high frequency of status changes.

[0013] Optionally, the method further includes: In response to detecting that an application occupies or releases audio focus in the audio region, based on a preset rule that combines a public identifier and a region identifier into a structured key, the predefined public identifier is combined with the region identifier of the audio region to form the state storage identifier.

[0014] In this way, by generating identifiers by combining public identifiers and region identifiers into structured keys, a standardized identifier construction logic is established. The unified structured rules ensure that the focus state of each audio region has a unique and locatable storage key name, avoiding conflicts in the storage of different audio region states. At the same time, the standardized identifier generation method allows the producers and consumers of focus states to follow the same rules without the need for additional negotiation of interface definitions, further reducing system coupling, ensuring smooth connection of the "storage-query" process, and improving the versatility and maintainability of the solution.

[0015] Optionally, determining the audio focus status information of the target audio region from the shared storage region based on the status query identifier includes: Using the audio focus status query identifier as the retrieval condition, the system interface that supports cross-user queries is invoked to query the shared storage area and obtain the corresponding audio focus status information.

[0016] In this way, by using a system interface that supports cross-user queries to obtain audio focus status information from the shared storage area, the limitation of user space isolation in the vehicle system is broken. This allows upper-layer applications running in different user spaces (such as the driver and passenger) to query the focus status of the target audio area, meeting the needs of multi-user collaborative use in smart cockpits. At the same time, cross-user queries are achieved through the system's native interface, eliminating the need to develop additional permission adaptation logic, reducing the development cost of upper-layer applications, and improving the adaptability of the solution.

[0017] Optionally, the method further includes: In response to the failure of the system interface call that supports cross-user queries, the standard query interface is called to query the shared storage area and obtain the corresponding audio focus status information.

[0018] In this way, when the cross-user query interface call fails, it automatically switches to the standard query interface, building a highly fault-tolerant query mechanism. This effectively avoids interface call failures caused by system version differences, permission restrictions, and other reasons, ensuring the stability and reliability of the focus status information query operation. At the same time, the degradation strategy does not require manual intervention, realizing automated fault-tolerant processing of the query process, reducing the impact of system anomalies on upper-layer application functions, improving the robustness of the solution, and ensuring that audio focus status information can still be obtained normally in complex in-vehicle system environments.

[0019] Optionally, generating an audio focus state query identifier corresponding to the target audio region includes: Based on a preset rule that combines a public identifier and a region identifier into a structured key, the public identifier is concatenated with the region identifier of the target audio region to generate the audio focus status query identifier.

[0020] This clarifies the generation rules for audio focus status query identifiers, adopting the same structured combination rule of "public identifier + area identifier" as the status storage identifier. This ensures that the query identifier and the storage identifier have completely consistent formats, enabling them to match the target status record in the shared storage area and avoiding query failures due to inconsistent identifier formats. At the same time, the standardized splicing rules lower the development threshold for upper-layer applications to generate query identifiers, allowing for rapid identifier construction without complex logic design. This further enhances the usability and efficiency of the focus query process and ensures the smooth operation of the "publish-subscribe" model.

[0021] An audio focus determination device, the device comprising: The generation module is used to generate an audio focus state query identifier corresponding to the target audio region in response to a query request for the audio focus state of the target audio region. The target audio region is used to characterize the physical or logical audio region in the vehicle system that is designated as the query object. The first determining module is used to determine the audio focus status information of the target audio region from the shared storage area based on the audio focus status query identifier, wherein the shared storage area stores the audio focus status information of each audio region; The second determining module is used to determine the query result of the audio focus of the target audio region based on the audio focus status information.

[0022] Optionally, the second determining module is also used for: Determine whether the audio focus status information contains the application identifier of the target application; In response to the fact that the audio focus status information contains the application identifier of the target application, the query result is determined to be that the target application occupies the audio focus of the target audio region; If the application identifier of the target application is not included in the audio focus status information, the query result is determined to be that the target application does not occupy the audio focus of the target audio area.

[0023] Optionally, the audio focus determination device also includes a first generation module: The first generation module is used to generate a state storage identifier corresponding to the audio region in response to detecting that the application occupies or releases the audio focus in the audio region, and write the information representing the focus occupancy state into the location associated with the state storage identifier in the system's native shared storage region.

[0024] Optionally, the audio focus determination device also includes a clearing module: The clear module is used to clear or delete the value stored in the shared storage area corresponding to the state storage identifier in response to the detection that the application releases the audio focus of the audio area.

[0025] Optionally, the audio focus determination device may also include a combination module: The combination module is used to respond to the detection that an application occupies or releases audio focus in the audio region, and based on a preset rule for combining a public identifier and a region identifier into a structured key, combine a predefined public identifier with the region identifier of the audio region to form the state storage identifier.

[0026] Optionally, the first determining module is also used for: Using the audio focus status query identifier as the retrieval condition, the system interface that supports cross-user queries is invoked to query the shared storage area and obtain the corresponding audio focus status information.

[0027] Optionally, the audio focus determination device may also include a calling module: The calling module is used to respond to the failure of the system interface call that supports cross-user queries, and to call the standard query interface to query the shared storage area to obtain the corresponding audio focus status information.

[0028] Optionally, the generation module is also used for: Based on a preset rule that combines a public identifier and a region identifier into a structured key, the public identifier is concatenated with the region identifier of the target audio region to generate the audio focus status query identifier.

[0029] A vehicle includes an onboard controller, the onboard controller including a memory, a processor, and a computer program stored in the memory, wherein when the processor executes the computer program, it implements any of the optional audio focus determination methods described above.

[0030] An electronic device includes a memory, a processor, and a computer program stored in the memory, wherein when the processor executes the computer program, it implements any of the optional audio focus determination methods described above.

[0031] Using the above technical solution, this disclosure provides a method for determining audio focus. First, in response to a query request for the audio focus status of a target audio region, an audio focus status query identifier corresponding to the target audio region is generated. The target audio region is used to characterize a physical or logical audio region in an in-vehicle system that is designated as the query object. Second, based on the audio focus status query identifier, the audio focus status information of the target audio region is determined from a shared storage region, which stores the audio focus status information of each audio region. Finally, based on the audio focus status information, the query result of the audio focus of the target audio region is determined. This closed-loop design, which involves "responding to target audio region query requests to generate a unique identifier - obtaining status information from the shared storage area - outputting multi-dimensional query results," not only solves the pain point of "global queries being unable to adapt to fine-grained multi-sound zone control" in traditional in-vehicle audio focus management, but also generates corresponding query identifiers for any physical or logical audio region, such as the driver's seat, passenger seat, and rear seats, ensuring that status queries are strictly bound to the target region. This provides accurate data support for core smart cockpit scenarios such as parallel playback of multiple sound zones and independent permission control. Furthermore, it eliminates the reliance on private cross-process communication channels of underlying audio services in traditional solutions, relying on the system's native shared storage area to achieve status reading. This significantly reduces the coupling between upper-layer applications and the underlying system, avoiding the full adaptation costs caused by changes in underlying interfaces. Simultaneously, it breaks down the permission barriers of private communication, allowing third-party multimedia applications, Various upper-layer applications, such as the cockpit linkage module, can easily obtain focus status, significantly improving the compatibility and scalability of the solution. It also has multi-scenario general capabilities, and its query results can flexibly cover multiple core needs such as "whether the target audio area is occupied", "the identity information of the currently occupying application", and "whether a specific application is the focus occupant". It can support the use of different scenarios such as audio permission conflict determination, playback status display and cockpit function linkage through a single unified process, improving the reusability of the solution. Moreover, the shared storage area, as the system's native lightweight carrier, has low read and write latency. With the simple three-step core process, it can achieve millisecond-level query response, perfectly adapting to in-vehicle real-time interaction scenarios such as high-frequency linkage of ambient lights and fast launch of audio applications. It effectively avoids the latency problems caused by traditional cross-process communication and ensures the smoothness of audio interaction and user experience during driving.

[0032] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, specific embodiments of this disclosure are described below. Attached Figure Description

[0033] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this disclosure. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 One of the flowcharts illustrating the method for determining audio focus provided in this embodiment of the present disclosure is shown. Figure 2 A second schematic flowchart of the method for determining audio focus provided in this embodiment of the present disclosure is shown; Figure 3 A schematic diagram of an audio focus determination device provided in an embodiment of this disclosure is shown. Detailed Implementation

[0034] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0035] With the rapid development of smart cockpit technology, the audio interaction scenarios of in-vehicle systems are becoming increasingly complex, evolving from traditional single-function whole-vehicle audio playback to a more refined interaction mode that supports independent control of multiple audio zones, parallel use by multiple users, and coexistence of multiple application audio. For example, a smart cockpit can achieve parallel playback and independent control of navigation audio for the driver, music audio for the passenger, and entertainment audio for the rear seats. This places higher demands on the management of in-vehicle audio focus. As a core resource ensuring the orderly playback of audio, the audio focus needs to accurately manage the occupation and release status of different applications in different audio zones to ensure that various audio interactions do not conflict and improve the user's driving experience. In this context, how to efficiently and accurately obtain the audio focus status of specific audio zones has become a key prerequisite for upper-level applications (such as ambient lighting control, status bar display, and multimedia linkage modules) to achieve functional adaptation.

[0036] In current mainstream solutions for in-vehicle audio focus management, upper-layer applications typically need to establish a private cross-process communication mechanism (typically AIDLBinder communication) with the underlying audio management service (such as CarAudioService) of the in-vehicle system to obtain the audio focus status. This is achieved by calling the private interface provided by the service. However, this approach has several inherent drawbacks: First, the system is highly coupled. The development and maintenance of upper-layer applications heavily rely on the private interface definition of the underlying audio management service. If the interface changes, all upper-layer applications that depend on it must be modified and recompiled, significantly increasing development costs and system maintenance difficulty. Second, regional query capabilities are lacking. The native Android audio focus management API and existing mainstream solutions are not designed for "multi-zone" scenarios and cannot support precise focus status queries based on specific audio zones (such as the passenger-side audio zone or the rear-seat audio zone). They can only obtain general, fuzzy focus information, which is insufficient to meet the refined zone control requirements of smart cockpits. Third, the system overhead is significant. Cross-process communication requires establishing inter-process connections, data serialization, and deserialization. Complex operations such as syncing and multi-threading synchronization, even simple focus state queries, consume significant system resources, easily leading to performance bottlenecks in high-frequency state query scenarios (such as ambient lighting following audio rhythm in real time); fourth, poor multi-user adaptability, limited by Android's user space isolation mechanism, applications running on top of Guest users (such as a passenger temporarily using the vehicle) find it difficult to query the audio focus state of the System user under the driver through a private cross-process communication channel, failing to meet the needs of multi-user collaborative use in smart cockpits; fifth, high permission barriers, the underlying audio management service typically has strict permission control, making it difficult for ordinary third-party applications to obtain access permissions to the private cross-process communication mechanism, thus limiting the application adaptability of focus state acquisition.

[0037] To address the technical problem of the lack of a sharing mechanism for the regionalized state information of audio focus in existing vehicle systems, this disclosure provides a method for determining audio focus, such as... Figure 1 As shown, Figure 1 This is a schematic flowchart illustrating a method for determining audio focus according to an embodiment of this disclosure. The method includes: S11. In response to a query request for the audio focus status of a target audio region, generate an audio focus status query identifier corresponding to the target audio region.

[0038] The target audio region is used to characterize the physical or logical audio region in the in-vehicle system that is designated as the query object. Audio regions in the in-vehicle system are divided into physical audio regions and logical audio regions. Physical audio regions refer to independent sound-emitting areas defined based on hardware layout (such as the driver's dedicated speaker coverage area, the passenger's dedicated speaker coverage area, and the independent left / right rear speaker areas). Logical audio regions refer to virtual sound-emitting areas defined based on system functions (such as the vehicle-wide synchronized sound area, the external device associated area, and the multi-user shared area). The target audio region is a specific region explicitly designated as the query object from the above audio regions. It can be a single physical / logical region (such as the passenger's physical area) or a combination of multiple regions (such as the logical combination area of ​​the left and right rear sides). Audio focus status refers to various queryable parameters related to the audio focus, including but not limited to "whether the audio focus is occupied," "the application identifier (package name / ID) currently occupying the audio focus," "focus occupation duration," "focus occupation priority," and "whether the focus is in a pending release state." The generated query identifier will serve as the core search key for subsequently retrieving the above status parameters from the shared storage area.

[0039] Specifically, the only triggering condition is a query request for the audio focus status of the target audio area. This request can be initiated by any upper-layer application (such as the ambient light control module, audio player, or cockpit status bar). The triggering condition does not depend on the private interface of the underlying audio service; it only needs to specify the core parameter of the target audio area. The query request may include, but is not limited to: a query request to see if the target audio area is occupied, a query request to see the identity information of the currently occupying application, or a query request to see if a specific application is the focus occupant.

[0040] Specifically, a collaborative closed loop of triggering mechanism, identifier generation module, and state storage module was constructed to form the basic capability of pre-storing and querying focus states.

[0041] The triggering mechanism can be as follows: Before determining the audio focus status of the target application in the target audio region, upon detecting that the application occupies or releases audio focus in the audio region, a state storage identifier corresponding to the audio region is generated, and the information representing the focus occupancy status is written to the location associated with the state storage identifier in the system's native shared storage area. Based on a preset rule that combines the public identifier and the region identifier into a structured key, the public identifier is concatenated with the region identifier of the target audio region to generate an audio focus status query identifier. In other words, the triggering mechanism is divided into two categories: query triggering (when the focus status of the target application needs to be determined), in which the trigger identifier generation module generates an audio focus status query identifier; and state change triggering (when any application occupies / releases audio focus), in which the trigger identifier generation module generates a state storage identifier and simultaneously triggers the state storage module to perform a "write / clear" operation.

[0042] For example, the trigger scenarios can be further refined: "The trigger scenarios for "needing to determine the focus state" include: ambient light linkage with audio playback, status bar display of the currently playing application, and determination of audio permission conflicts between multiple applications, etc., which are initiated by upper-level applications; "Application occupying / releasing focus" trigger scenarios include: application starting audio playback, pausing playback, switching audio output areas, exiting the application, etc.

[0043] Specifically, in response to the detection of an application occupying or releasing audio focus in the audio region, based on preset rules that combine public identifiers and region identifiers into a structured key, the predefined public identifier is combined with the region identifier of the audio region to form a state storage identifier. In other words, the identifier generation module undertakes the function of standardized identifier construction, ensuring that the query identifier and the stored identifier are matched through a unified structured rule of public identifier + region identifier, avoiding state confusion between different regions and different applications.

[0044] For example, the public identifier is a predefined fixed string constant (such as "car.audio.focus.namespace") used to distinguish the focus state storage key from other system storage keys and avoid conflicts; the area identifier is a unique identifier assigned by the vehicle system (such as the number "1" representing the driver's area, "2" representing the passenger's area, "3" representing the rear area, or the character identifier "main" "passenger"); an example of a structured concatenation rule: public identifier + separator (such as "_" " / ") + area identifier, which ultimately generates "car.audio.focus.namespace_1" (driver's area storage / query identifier).

[0045] Simultaneously, in response to detecting the application releasing the audio focus in the audio area, the value stored at the location corresponding to the state storage identifier in the shared storage area is cleared or deleted. In other words, the state storage module undertakes the full lifecycle management function of focus state, writing information to the shared storage area when the state changes and clearing invalid data when focus is released, ensuring the real-time nature and accuracy of the state information in the storage area.

[0046] For example, storage operation details: the shared storage area is specifically the vehicle system's native lightweight database (such as the Settings.System database in Android), which has global sharing and low-latency read and write characteristics; the "focus status information" written is specifically the unique identifier of the application occupying focus (such as the application package name "com.spotify.music" and the application ID "10086"); the "clear / delete" operation when releasing focus is specifically implemented by calling the system's native storage interface (such as using Settings.System.putString(null, storage identifier) ​​in Android to clear, or calling the delete interface to delete).

[0047] Specifically, the public identifier is a root namespace (e.g., "com.android.car.audio.focus.state") predefined during system compilation or initialization. Its function is to completely isolate the state keys managed by this invention from thousands of other settings within the system, preventing key name pollution and accidental access. The zone identifier is strongly coupled with the in-vehicle audio architecture. In a typical AAOS multi-zone implementation, zoneId=0 usually represents "whole vehicle audio" (used for navigation, alarms, and other global sounds), zoneId=1 represents the "driver's audio zone," zoneId=2 represents the "passenger's audio zone," and so on. The identifier construction rules must be completely consistent with the zone definitions used by the underlying CarAudioService. Structured concatenation is not limited to simple string concatenation. A more robust rule is to introduce a version number, forming an identifier such as "v1.focus.state / zone / 1," reserving a compatibility path for possible future rule upgrades.

[0048] In one specific embodiment, in addition to ambient lighting linkage and status bar display, it can also be applied to: determining audio permission conflicts between multiple applications (such as when the driver's navigation APP and the passenger's music APP simultaneously request to occupy the front audio area, priority needs to be determined by querying the focus status); third-party audio application adaptation (such as when a third-party APP starts, it needs to query whether the target audio area is occupied to avoid playback conflicts); and cockpit voice assistant linkage (when the voice command "pause passenger music" is given, the voice assistant needs to first query the focus ownership of the passenger audio area before sending the command to the corresponding application).

[0049] In this embodiment, a mapping between audio regions and focus states is established through a unified structured identifier, enabling proactive storage and full lifecycle management of focus states in advance, laying the data foundation for subsequent decoupled queries. This approach addresses three core pain points in traditional in-vehicle audio focus management: the inability to locate regional focus states, high coupling due to upper-layer application queries relying on private cross-process communication of underlying services (such as AIDLBinder), and untimely updates to focus states. By employing a unified identifier generation and pre-stored state information, the approach achieves queryable and real-time synchronized focus states, supporting the refined interaction needs of multi-sound zones and multi-application parallel operation in smart cockpits.

[0050] S12. Based on the audio focus status query identifier, determine the audio focus status information of the target audio region from the shared storage region.

[0051] The shared storage area stores the audio focus status information of each audio region. For example, the shared storage area uses a key-value pair storage structure with "audio region identifier + status parameter type" as the key and status value as the value, ensuring that each type of focus status parameter of each audio region has a unique corresponding storage entry and avoiding data confusion.

[0052] Specifically, a collaborative logic of "search criteria - query interface module - result acquisition module" was constructed. The search criteria use the audio focus state query identifier generated by S11 as the core search key. Utilizing a unified generation rule between the query identifier and the state storage identifier, a mapping between the query identifier, storage identifier, and focus state is achieved, avoiding query bias. The state storage identifier is generated in response to the detection of an application occupying or releasing audio focus in the audio region. Based on a preset rule that combines a common identifier and a region identifier into a structured key, a predefined common identifier is combined with the region identifier of the audio region to form the state storage identifier. The result acquisition module extracts focus state records matching the search key from the shared storage area.

[0053] For example, a query request is initiated by calling the vehicle system's native content parsing component (such as ContentResolver in Android); the audio focus status query identifier is passed as a retrieval parameter, and the target record in the shared storage area is located through the system's native query interface (such as Settings.System.getString(resolver, query identifier) ​​in Android).

[0054] Specifically, in response to a failure of a system interface call supporting cross-user queries, the standard query interface is invoked to query the shared storage area and obtain the corresponding audio focus status information. In other words, the query interface module employs a dual-interface fault-tolerance strategy, with the core responsible for adapting to multi-user scenarios and ensuring query stability, prioritizing cross-user query capabilities while also considering compatibility in special scenarios.

[0055] For example, the "cross-user query interface" that is called first is a hidden system interface (such as Android's Settings.System.getStringForUser(resolver, query identifier, userId)), which supports querying the audio focus status information of the corresponding user space by specifying a user ID (such as the driver's user ID=0, the passenger's Guest user ID=10). The conditions for judging the failure of the interface call are: the system version does not support it (such as the low version of Android does not have this hidden interface), insufficient permissions, the interface call throws an exception, etc. The downgraded "standard query interface" is a public system interface (such as Android's Settings.System.getString(resolver, query identifier)), which ensures that the query can still be completed in special scenarios without interrupting the process.

[0056] In one specific embodiment, for high-frequency query scenarios (such as ambient lights querying focus status once per second), a new memory caching layer is added. After the first query retrieves the result from the shared storage area, it is cached in LruCache (cache capacity is set to 10, covering all audio areas). Subsequent queries first read from the cache, and after the cache expires (default 500ms), it is synchronized to the shared storage area, reducing the query latency from 20ms to less than 3ms. Batch query interface: It supports querying the focus status of multiple audio areas simultaneously, reducing the number of system interface calls. For example, when the cockpit control module needs to obtain the status of three areas, namely "driver's seat, passenger's seat, and whole vehicle", query identifiers are generated in batches, and the query method of ContentResolver is called once to obtain them in batches, improving efficiency.

[0057] In one specific embodiment, Settings.System can be selected as the shared storage area. This is a global key-value database maintained by the Android system, designed to store system settings such as screen brightness and volume levels. Advantages compared to traditional AIDL solutions: Performance: Reading and writing to Settings.System is a high-speed, memory-level operation, and the system has deep optimizations for it. AIDL calls, on the other hand, involve inter-process communication (IPC) and data serialization / deserialization, resulting in high overhead and latency. Coupling: AIDL requires the server and client to share the same interface definition (.aidl file). Once the interface changes, all clients must update synchronously. This solution, based on a "string key name" convention, has minimal impact from changes. Permissions: Read permissions for Settings.System are generally easier to obtain than directly calling the underlying CarAudioService's private Binder interface, lowering the barrier to entry for third-party applications.

[0058] In this embodiment, decoupled queries of focus states are achieved by relying on a shared storage area. A fault-tolerance strategy that prioritizes cross-user interfaces and degrades to standard interfaces ensures the reliability and compatibility of queries in multi-user scenarios. The core solution addresses three major pain points in traditional solutions: inability to query focus states across user spaces (e.g., the Guest user cannot query the audio status of the System user), susceptibility of single query interfaces to failure due to system version / permission issues, and inability to locate regional states in global queries. By leveraging cross-process communication through shared storage area readings and interface fault tolerance, low-cost and highly reliable acquisition of focus states is achieved.

[0059] S13. Based on the audio focus status information, determine the query results of the audio focus of the target audio region.

[0060] Specifically, a simplified judgment logic of "state parsing - identifier matching - result output" is constructed, which undertakes the core function of transforming the original state information into a clear judgment conclusion: the state parsing module judges the validity of the audio focus state information obtained by S12 (such as whether it is empty or whether the format is valid); the identifier matching module compares the parsed valid state information with the identity identifier of the target application to complete the core judgment of "occupied / unoccupied"; the result output module feeds back the judgment conclusion (occupied / unoccupied) to the upper layer application that initiated the query to support subsequent functional linkage.

[0061] For example, regarding the details of state parsing: if the audio focus status information is an "empty string," "null," or a string that is not in the application identifier format (such as garbled characters), it is determined as "invalid status information," directly pointing to "no application occupying focus"; if it is a valid string (conforming to the application package name / ID format), it enters the matching stage; regarding the identifier matching details: the target application's identifier is the application package name (such as "com.spotify.music") or application ID (such as "10086"), which must be consistent with the format of the "focus status information" stored in S11; the matching rule is "exact match". (If the stored information is "com.spotify.music", the target application package name is the same and the match is successful); Match result determination: Match successful → the target application occupies focus; Match failed / status information invalid → the target application does not occupy focus; Result output details: The output format is a boolean value (true=occupied, false=not occupied) or a status code (such as 1=occupied, 0=not occupied); After the output, the upper layer application's function linkage is triggered (such as if it is determined to be "occupied", the ambient light starts the rhythm mode linked with the audio rhythm; if it is determined to be "not occupied", the ambient light returns to the default mode).

[0062] In one specific embodiment, the ambient light is linked to the audio focus: Target application: driver's music APP (package name com.netease.cloudmusic); Target audio area: driver's independent audio area (area code 1); Judgment process: The ambient light control module calls queryFocusStateCrossUser(1,0) to obtain the status information com.netease.cloudmusic, which matches the target application package name, determines that "focus is occupied", and triggers the ambient light to move rhythmically according to the music (red → blue gradient, frequency synchronized with the music beat); Release linkage: When the music APP pauses playback, the status information is cleared, determines that "focus is not occupied", and the ambient light returns to the default white constant light.

[0063] In one specific embodiment, the multi-application permission conflict handling is as follows: Scenario description: The driver's navigation APP (package name com.autonavi.minimap) has occupied the "driver's independent audio area". At this time, the driver's music APP requests to occupy the area; Judgment process: The music APP finds the status information as com.autonavi.minimap, which does not match its own package name, and determines that "focus is not occupied"; Conflict handling: The music APP pops up a prompt "The current navigation occupies the audio channel. Do you want to pause navigation?". After the user confirms, the music APP sends a broadcast notification to the navigation APP to release the focus. After the status information is cleared, the music APP occupies the area and writes its own package name.

[0064] In this embodiment, application identifier matching is the core to construct a unified and objective standard for determining focus occupancy. This addresses the pain points of traditional solutions, such as ambiguous focus determination rules (e.g., relying on complex multi-dimensional judgments) and inconsistent judgment logic among different upper-layer applications leading to abnormal functional linkages (e.g., ambient light malfunctions or incorrect playback status display). Through a simple identifier matching approach, a unified determination of focus status is achieved, ensuring the functional consistency of multiple upper-layer applications.

[0065] In the above scheme, in response to a query request for the audio focus status of a target audio region, an audio focus status query identifier corresponding to the target audio region is generated. The target audio region is used to characterize the physical or logical audio region in the vehicle system that is designated as the query object. Secondly, based on the audio focus status query identifier, the audio focus status information of the target audio region is determined from a shared storage area, which stores the audio focus status information of each audio region. Finally, based on the audio focus status information, the query result of the audio focus of the target audio region is determined. This closed-loop design, which involves "responding to target audio region query requests to generate a unique identifier - obtaining status information from the shared storage area - outputting multi-dimensional query results," not only solves the pain point of "global queries being unable to adapt to fine-grained multi-sound zone control" in traditional in-vehicle audio focus management, but also generates corresponding query identifiers for any physical or logical audio region, such as the driver's seat, passenger seat, and rear seats, ensuring that status queries are strictly bound to the target region. This provides accurate data support for core smart cockpit scenarios such as parallel playback of multiple sound zones and independent permission control. Furthermore, it eliminates the reliance on private cross-process communication channels of underlying audio services in traditional solutions, relying on the system's native shared storage area to achieve status reading. This significantly reduces the coupling between upper-layer applications and the underlying system, avoiding the full adaptation costs caused by changes in underlying interfaces. Simultaneously, it breaks down the permission barriers of private communication, allowing third-party multimedia applications, Various upper-layer applications, such as the cockpit linkage module, can easily obtain focus status, significantly improving the compatibility and scalability of the solution. It also has multi-scenario general capabilities, and its query results can flexibly cover multiple core needs such as "whether the target audio area is occupied", "the identity information of the currently occupying application", and "whether a specific application is the focus occupant". It can support the use of different scenarios such as audio permission conflict determination, playback status display and cockpit function linkage through a single unified process, improving the reusability of the solution. Moreover, the shared storage area, as the system's native lightweight carrier, has low read and write latency. With the simple three-step core process, it can achieve millisecond-level query response, perfectly adapting to in-vehicle real-time interaction scenarios such as high-frequency linkage of ambient lights and fast launch of audio applications. It effectively avoids the latency problems caused by traditional cross-process communication and ensures the smoothness of audio interaction and user experience during driving.

[0066] In some embodiments, such as Figure 2 As shown, based on focus state information, it is determined whether the target application occupies the audio focus of the target audio region, including: S131. Determine whether the audio focus status information contains the application identifier of the target application.

[0067] Specifically, the system receives the original audio focus status information obtained from the shared storage area in step S12, performs validity screening and core element extraction on the information to prevent invalid data (such as garbled characters or empty values) from entering the subsequent judgment steps; it outputs a binary verification result to determine whether the target application identifier is included, which directly determines the execution branch of subsequent steps S132 (forward judgment) or S133 (reverse judgment), ensuring the orderliness and uniqueness of the judgment process.

[0068] For example, the core parameter definitions are as follows: "Audio Focus Status Information": This is a string of data obtained by S12 from the shared storage area. If not empty, it is the "identifier of the application currently occupying focus" (e.g., application package name "com.tencent.music", application ID "10010"); if empty, it is "no application occupying focus". "Target Application's Application Identifier": This is the unique identifier of the upper-layer application initiating the query. Its format must be completely consistent with the application identifier in the audio focus status information (e.g., both are application package names or both are application IDs). The judgment method is refined: A "complete match verification" logic is used. If the audio focus status information is a non-empty string and matches the character of the target application identifier... If the sequence is completely identical (e.g., both are "com.tencent.music"), it is determined to be "included"; if the audio focus status information is empty (null / empty string), or is another application identifier (e.g., "com.spotify.music"), or is garbled, it is determined to be "not included"; Execution subject and tool: executed by the "target application" that initiated the query (e.g., ambient light control application, status bar module), and the verification is completed through a string matching function (e.g., the equals() method in Java); Exception handling details: if the audio focus status information format is illegal (e.g., not a string type), it is directly determined to be "not included" to avoid program crashes.

[0069] In this embodiment, application identifier matching is established as a unified and objective prerequisite for focus determination, abandoning the fuzzy logic of traditional solutions that rely on multi-dimensional complex parameters (such as process ID and playback status code). This addresses the pain points of traditional in-vehicle audio focus determination, including inconsistent determination rules (significant differences in determination logic across different applications), ambiguous determination criteria (prone to misjudgment due to missing parameters), and poor consistency across applications. Through the core idea of ​​single identifier matching, it lays the foundation for subsequent occupancy / unoccupiedness determination.

[0070] S132. In response to the application identifier of the target application contained in the audio focus status information, determine that the query result is the audio focus of the target application occupying the target audio area.

[0071] Specifically, after S131 completes the verification of "whether the audio focus status information contains the target application identifier", if the verification result is that it contains the identifier, the judgment rule of this step is directly triggered, and the identifier is matched with this verification result, which is converted into an occupation conclusion that can be directly used by the upper layer application. This provides a clear signal for subsequent function linkage (such as ambient light starting rhythm, status bar display of playback status) and ensures the coordination between focus status and upper layer functions.

[0072] For example, the triggering conditions are refined: triggering only when the "containment" check of S131 is a "complete match" (e.g., audio focus status information = "com.tencent.music", target application identifier = "com.tencent.music"), excluding "partial containment" and "fuzzy match" cases; the conclusion output format: output data type: boolean value (true = occupied) or status code (e.g., 1 = occupied), facilitating quick parsing by upper-layer applications; output method: passing the conclusion through a callback function within the target application (e.g., onFocusOccupied()). Subsequent linkage operations: triggering preset functions of the upper-layer application, examples include: the ambient light control application starting the "audio rhythm linkage" mode, the status bar module displaying the "target application is playing in the current audio area" icon, the multimedia management application allowing the target application to perform "volume adjustment" operations, etc.; execution time requirements: the delay from triggering to outputting the conclusion must be controlled within 100ms to adapt to the real-time interaction requirements of in-vehicle scenarios.

[0073] In this embodiment, a simplified positive judgment logic based on identifier matching is constructed. A single condition triggering a single conclusion ensures the uniqueness and accuracy of the judgment result. This core solution addresses the judgment delay and logical redundancy issues caused by the need for multiple conditions (such as process liveness + playback status + region matching) in traditional solutions, enabling rapid positive output of focus occupancy status and adapting to high-frequency interaction scenarios (such as real-time ambient lighting linkage).

[0074] S133. In response to the fact that the application identifier of the target application is not contained in the audio focus status information, the query result is determined to be that the target application does not occupy the audio focus of the target audio area.

[0075] Specifically, it provides clear "non-executable signals" (such as "stop ambient light rhythm" and "hide current application playback status") for upper-layer applications to avoid functional abnormalities caused by "misjudgment of occupancy" in upper-layer applications; it covers two core scenarios: the target audio area has no application occupying focus (focus status information is empty); the target audio area is occupied by other applications (focus status information is other application identifier), achieving "no blind spots in the whole scene" reverse judgment.

[0076] For example, the triggering conditions are refined: covering three "not included" scenarios: the focus status information is empty (null / empty string); the focus status information is the identifier of another application (e.g., target application identifier = "com.tencent.music", status information = "com.spotify.music"); and the focus status information format is invalid (e.g., garbled characters, numeric type). The output format is as follows: the output data type is a boolean value (false = unoccupied) or a status code (e.g., 0 = unoccupied), consistent with the S132 output format, facilitating unified parsing by upper-layer applications; the output method is through the target application's internal... Callback functions (such as onFocusNotOccupied()) pass the conclusion; subsequent linkage operations: trigger the preset functions of the upper layer application, examples include: the ambient light control application stops the rhythm and restores the default brightness, the status bar module hides the "target application play" icon, the multimedia management application rejects the target application's "audio playback permission" request, etc.; special handling: if the triggering scenario is "other applications occupy focus", the "current application occupying focus" identifier can be output (extracted from the status information obtained from S12) to provide the upper layer application with more decision-making basis (such as prompting the user "this area is currently occupied by XX application").

[0077] In this embodiment, a simplified reverse determination logic is constructed based on the mismatch of identifiers, indicating that the application is not occupied. This logic complements the forward logic of S132, achieving a closed-loop determination that covers all scenarios. This solution addresses the pain points of traditional solutions, such as omissions in reverse determination scenarios (e.g., not considering the two cases of no application occupying focus and other applications occupying focus) and the complexity of the reverse determination logic. It ensures that regardless of whether the focus state is "no application occupying focus" or "other application occupying focus," a unified "not occupied" conclusion can be quickly output, guaranteeing the completeness of the determination.

[0078] In the above solution, the audio focus determination process constructed by S131 to S133 establishes a complete closed loop of "pre-verification - forward determination - reverse determination" by using application identifier matching as the core determination criterion. This not only abandons the fuzzy determination logic that relies on multi-dimensional and complex parameters in traditional solutions, but also unifies the focus determination standards of different upper-layer applications, effectively avoiding functional linkage anomalies caused by differences in determination rules. Furthermore, it covers all scenarios of target application occupying focus, other applications occupying focus, and no application occupying focus through clear binary branches, ensuring the accuracy and completeness of the determination results. At the same time, the extremely simplified identifier matching logic significantly reduces the development and execution costs of upper-layer applications, eliminating the need to call the private interfaces of the underlying audio service, further weakening the system coupling, adapting to the high-frequency query scenarios of multi-sound zones and multi-application parallelism in smart cockpits, ensuring the real-time response of functions such as ambient lighting linkage and status bar display, and improving the user's driving and riding interaction experience.

[0079] In one specific embodiment, the following code is the core embodiment for the consumer side.

[0080]

[0081]

[0082] In the code above, the `hasAudioFocus` method illustrates the consumer-side logic of this solution. It clearly demonstrates how to construct structured key names, use them to query data, and ultimately make an attribution determination. The `getSystemSettingsForUser` method calls a hidden API via reflection, which is to accurately query the settings of a specific user in a multi-user environment, demonstrating the completeness and robustness of the solution.

[0083] In addition, such as Figure 3 As shown, Figure 3 This is a schematic diagram of an audio focus determination device 300 provided in an embodiment of the present disclosure. The device includes: The generation module 301 is used to generate an audio focus status query identifier corresponding to the target audio region in response to a query request for the audio focus status of the target audio region. The target audio region is used to characterize the physical or logical audio region in the vehicle system that is designated as the query object. The first determining module 302 is used to determine the audio focus status information of the target audio region from the shared storage area based on the audio focus status query identifier, wherein the shared storage area stores the audio focus status information of each audio region; The second determining module 303 is used to determine the query result of the audio focus of the target audio region based on the audio focus status information.

[0084] In the above scheme, in response to a query request for the audio focus status of a target audio region, an audio focus status query identifier corresponding to the target audio region is generated. The target audio region is used to characterize the physical or logical audio region in the vehicle system that is designated as the query object. Secondly, based on the audio focus status query identifier, the audio focus status information of the target audio region is determined from a shared storage area, which stores the audio focus status information of each audio region. Finally, based on the audio focus status information, the query result of the audio focus of the target audio region is determined. This closed-loop design, which involves "responding to target audio region query requests to generate a unique identifier - obtaining status information from the shared storage area - outputting multi-dimensional query results," not only solves the pain point of "global queries being unable to adapt to fine-grained multi-sound zone control" in traditional in-vehicle audio focus management, but also generates corresponding query identifiers for any physical or logical audio region, such as the driver's seat, passenger seat, and rear seats, ensuring that status queries are strictly bound to the target region. This provides accurate data support for core smart cockpit scenarios such as parallel playback of multiple sound zones and independent permission control. Furthermore, it eliminates the reliance on private cross-process communication channels of underlying audio services in traditional solutions, relying on the system's native shared storage area to achieve status reading. This significantly reduces the coupling between upper-layer applications and the underlying system, avoiding the full adaptation costs caused by changes in underlying interfaces. Simultaneously, it breaks down the permission barriers of private communication, allowing third-party multimedia applications, Various upper-layer applications, such as the cockpit linkage module, can easily obtain focus status, significantly improving the compatibility and scalability of the solution. It also has multi-scenario general capabilities, and its query results can flexibly cover multiple core needs such as "whether the target audio area is occupied", "the identity information of the currently occupying application", and "whether a specific application is the focus occupant". It can support the use of different scenarios such as audio permission conflict determination, playback status display and cockpit function linkage through a single unified process, improving the reusability of the solution. Moreover, the shared storage area, as the system's native lightweight carrier, has low read and write latency. With the simple three-step core process, it can achieve millisecond-level query response, perfectly adapting to in-vehicle real-time interaction scenarios such as high-frequency linkage of ambient lights and fast launch of audio applications. It effectively avoids the latency problems caused by traditional cross-process communication and ensures the smoothness of audio interaction and user experience during driving.

[0085] In one specific embodiment, the second determining module 303 is further configured to: Determine whether the audio focus status information contains the application identifier of the target application; In response to the fact that the audio focus status information contains the application identifier of the target application, the query result is determined to be that the target application occupies the audio focus of the target audio region; If the application identifier of the target application is not included in the audio focus status information, the query result is determined to be that the target application does not occupy the audio focus of the target audio area.

[0086] In one specific embodiment, the audio focus determination device 300 further includes a first generation module: The first generation module is used to generate a state storage identifier corresponding to the audio region in response to the detection that the application occupies or releases the audio focus in the audio region, and write the information representing the focus occupancy status into the location associated with the state storage identifier in the system's native shared storage area.

[0087] In one specific embodiment, the audio focus determining device 300 further includes a clearing module: The clear module is used to clear or delete the value stored in the shared storage area corresponding to the state storage identifier in response to the detection that the application releases the audio focus of the audio area.

[0088] In one specific embodiment, the audio focus determining device 300 further includes a combination module: The combination module is used to respond to the detection that the application occupies or releases the audio focus in the audio region. Based on the preset rules for combining the public identifier and the region identifier into a structured key, it combines the predefined public identifier with the region identifier of the audio region to form a state storage identifier.

[0089] In one specific embodiment, the first determining module 302 is further configured to: Using the audio focus status query identifier as the retrieval condition, the system interface that supports cross-user queries is called to query the shared storage area and obtain the corresponding audio focus status record.

[0090] In one specific embodiment, the audio focus determination device 300 further includes a calling module: The calling module is used to respond to the failure of system interface calls that support cross-user queries, and to call the standard query interface to query the shared storage area to obtain the corresponding audio focus status information.

[0091] In one specific embodiment, the generation module 301 is further configured to: Based on a preset rule that combines public identifiers and region identifiers into a structured key, the public identifier is concatenated with the region identifier of the target audio region to generate an audio focus status query identifier.

[0092] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0093] This embodiment also provides a vehicle, wherein the vehicle controller includes a memory, a processor, and a computer program stored in the memory, and when the processor executes the computer program, it implements any of the optional audio focus determination methods described above.

[0094] This embodiment also provides an electronic device, including a memory, a processor, and a computer program stored in the memory. When the processor executes the computer program, it implements any of the optional audio focus determination methods described above, thus achieving the same effect as the implementation method described above.

[0095] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0096] Through the above description of the embodiments, those skilled in the art will 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.

[0097] In the embodiments provided in this disclosure, 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 coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0098] In the description of this disclosure, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure.

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

[0100] The above are merely embodiments of this disclosure and are not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A method for determining audio focus, characterized in that, The method includes: In response to a query request for the audio focus status of a target audio region, an audio focus status query identifier corresponding to the target audio region is generated, wherein the target audio region is used to characterize the physical or logical audio region in the vehicle system that is designated as the query object; Based on the audio focus status query identifier, the audio focus status information of the target audio region is determined from the shared storage area, where the shared storage area stores the audio focus status information of each audio region; Based on the audio focus status information, the query result for determining the audio focus of the target audio region is obtained.

2. The determination method according to claim 1, characterized in that, The query result for determining the audio focus of the target audio region based on the audio focus state information includes: Determine whether the audio focus status information contains the application identifier of the target application; In response to the fact that the audio focus status information contains the application identifier of the target application, the query result is determined to be that the target application occupies the audio focus of the target audio region; If the application identifier of the target application is not included in the audio focus status information, the query result is determined to be that the target application does not occupy the audio focus of the target audio area.

3. The determination method according to claim 1, characterized in that, The method further includes: In response to detecting that an application occupies or releases audio focus in the audio region, a state storage identifier corresponding to the audio region is generated, and information representing the focus occupancy state is written to the location associated with the state storage identifier in the system's native shared storage region.

4. The determination method according to claim 3, characterized in that, The method further includes: In response to detecting that the application releases the audio focus of the audio area, the value stored in the shared storage area at the location corresponding to the state storage identifier is cleared or deleted.

5. The determination method according to claim 3, characterized in that, The method further includes: In response to detecting that an application occupies or releases audio focus in the audio region, based on a preset rule that combines a public identifier and a region identifier into a structured key, the predefined public identifier is combined with the region identifier of the audio region to form the state storage identifier.

6. The determination method according to claim 1, characterized in that, The step of determining the audio focus status information of the target audio region from the shared storage region based on the status query identifier includes: Using the audio focus status query identifier as the retrieval condition, the system interface that supports cross-user queries is invoked to query the shared storage area and obtain the corresponding audio focus status information.

7. The determination method according to claim 6, characterized in that, The method further includes: In response to the failure of the system interface call that supports cross-user queries, the standard query interface is called to query the shared storage area and obtain the corresponding audio focus status information.

8. The determination method according to claim 1, characterized in that, Generate an audio focus status query identifier corresponding to the target audio region, including: Based on a preset rule that combines a public identifier and a region identifier into a structured key, the public identifier is concatenated with the region identifier of the target audio region to generate the audio focus status query identifier.

9. A vehicle, characterized in that, The system includes an in-vehicle controller, which includes a memory, a processor, and a computer program stored in the memory. The processor, when executing the computer program, implements the method for determining audio focus as described in any one of claims 1 to 8.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method for determining audio focus as described in any one of claims 1 to 8.

Images