自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
概览
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android Automotive OS (AAOS) 是在核心 Android 音频堆栈的基础之上打造而成,以支持用作车辆信息娱乐系统的用例。AAOS 负责实现信息娱乐声音(即媒体、导航和通讯声音),但不直接负责具有严格可用性和时间要求的铃声和警告。
虽然 AAOS 提供了信号和机制来帮助车辆管理音频,但最终还是由车辆来决定应为驾驶员和乘客播放什么声音,从而确保对保障安全至关重要的声音和监管声音能被确切听到,而不会中断。
由于 AAOS 利用了 Android 音频堆栈,因此播放音频的第三方应用不需要执行与手机中不同的操作。应用的音频路由由 AAOS 自动管理,如音频政策配置中所述。
当 Android 管理车辆的媒体体验时,应通过应用来代表外部媒体来源(例如电台调谐器),这类应用可以处理该来源的音频焦点和媒体键事件。
Android 声音和声音流
汽车音频系统可以处理以下声音和声音流:
图 1. 以声音流为中心的架构图。
Android 管理来自 Android 应用的声音,同时控制这些应用,并根据其声音类型将声音路由到 HAL 中的输出设备:
为了确保可靠性,外部声音(来自独立声源,例如安全带警告铃声)在 Android 外部(HAL 下方,甚至是在单独的硬件中)进行管理。系统实现者必须提供一个混音器,用于接受来自 Android 的一个或多个声音输入流,然后以合适的方式将这些声音流与车辆所需的外部声源组合起来。Android 控件 HAL 为在 Android 外部生成的声音提供了一种不同的机制来与 Android 通信:
音频 HAL 实现和外部混音器负责确保对保障安全至关重要的外部声音能够被用户听到,而且负责在 Android 提供的声音流中进行混音,并将混音结果路由到合适的音响设备。
Android 声音
应用可以有一个或多个通过标准 Android API(如用于控制焦点的 AudioManager 或用于在线播放的 MediaPlayer)交互的播放器,以便发出一个或多个音频数据逻辑声音流。这些数据可能是单声道声音,也可能是 7.1 环绕声,但都会作为单个声源进行路由和处理。应用声音流与 AudioAttributes(可向系统提供有关应如何表达音频的提示)相关联。
逻辑声音流通过 AudioService 发送,并路由到一个(并且只有一个)可用的物理输出声音流,其中每个声音流都是混音器在 AudioFlinger 内的输出。音频属性在混合到物理声音流后将不再可用。
接下来,每个物理声音流都会传输到音频 HAL,以在硬件上呈现。在汽车应用中,呈现硬件可能是本地编解码器(类似于移动设备),也可能是车辆物理网络中的远程处理器。无论是哪种情况,音频 HAL 实现都需要提供实际样本数据并使其能被用户听见。
外部声音流
如果声音流因认证或计时原因而不应经由 Android,则可以直接发送到外部混音器。从 Android 11 开始,HAL 现在能够针对这些外部声音请求焦点,以通知 Android,使其能够采取适当措施(例如暂停媒体或阻止其他应用获得焦点)。
如果外部声音流是应与 Android 正在生成的声音环境交互的媒体源(例如,当外部调谐器处于开启状态时,停止 MP3 播放),则那些外部声音流应由 Android 应用表示。此类应用将代表媒体来源(而非 HAL)请求音频焦点,并根据需要通过启动/停止外部声音源来响应焦点通知,以符合 Android 音频焦点政策规定。
应用还负责处理媒体键事件,例如播放和暂停。如需控制此类外部设备,建议使用的一种机制是 HwAudioSource
。如需了解详情,请参阅在 AAOS 中连接输入设备。
输出设备
在音频 HAL 级别,设备类型 AUDIO_DEVICE_OUT_BUS
提供用于车载音频系统的通用输出设备。总线设备支持可寻址端口(其中每个端口都是一个物理声音流的端点),并且应该是车辆内唯一受支持的输出设备类型。
系统实现可以针对所有 Android 声音使用一个总线端口,在这种情况下,Android 会将所有声音混合在一起,并将混音结果作为一个声音流进行传输。此外,HAL 可以分别为每个 CarAudioContext 提供一个总线端口,以允许并发传输任何声音类型。这样一来,HAL 实现就可以根据需要混合和闪避不同的声音。
音频上下文到输出设备的分配是通过 car_audio_configuration.xml
文件完成的。如需了解详情,请参阅音频政策配置。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-17。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-03-17。"],[],[],null,["# Overview\n\nAndroid Automotive OS (AAOS) builds on the core Android audio stack to support\nthe use cases for operating as the infotainment system in a vehicle. AAOS is\nresponsible for infotainment sounds (that is media, navigation, and\ncommunications) but isn't directly responsible for chimes and warnings that have\nstrict availability and timing requirements.\n\nWhile AAOS provides signals and mechanisms to help the vehicle manage audio, in\nthe end it is up to the vehicle to make the call as to what sounds should be\nplayed for the driver and passengers, ensuring safety critical sounds and\nregulatory sounds are properly heard without interruption.\n\nSince AAOS leverages the Android audio stack, third party applications playing\naudio do not need to do anything different then they would in phones. The\napplication's audio routing is automatically managed by AAOS as described in\n[Audio policy configuration](/docs/automotive/audio/audio-policy-configuration).\n\nAs Android manages the vehicle's media experience, external media sources such\nas the radio tuner should be represented by apps, which can handle audio focus\nand media key events for the source.\n\nAndroid sounds and streams\n--------------------------\n\nAutomotive audio systems handle the following sounds and streams:\n\n**Figure 1.** Stream-centric architecture diagram.\n\nAndroid manages the sounds coming from Android apps, controlling those apps and\nrouting their sounds to output devices at the HAL based on the type of sound:\n\n- **Logical streams** , known as sources in core audio nomenclature, are tagged\n with [Audio attributes](/docs/core/audio/attributes).\n\n- **Physical streams**, known as devices in core audio nomenclature, have no\n context information after mixing.\n\nFor reliability, **external sounds** (coming from independent sources, such as\nseatbelt warning chimes) are managed outside Android, below the HAL or even in\nseparate hardware. System implementers must provide a mixer that accepts one or\nmore streams of sound input from Android and then combines those streams in a\nsuitable way with the external sound sources required by the vehicle. The\n[Android Control HAL](/docs/automotive/audio/audio-control-hal) provides a\ndifferent mechanism for sounds generated outside Android to communicate back to\nAndroid:\n\n- Audio focus request\n- Gain or volume limitations\n- Gain and volume changes\n\nThe audio HAL implementation and external mixer are responsible for ensuring the\nsafety-critical external sounds are heard and for mixing in the Android-provided\nstreams and routing them to suitable speakers.\n\n### Android sounds\n\nApps may have one or more players that interact through the standard Android\nAPIs (for example,\n[AudioManager](https://developer.android.com/reference/android/media/AudioManager.html)\nfor focus control or\n[MediaPlayer](https://developer.android.com/reference/android/media/MediaPlayer.html)\nfor streaming) to emit one or more logical streams of audio data. This data\ncould be single channel mono or 7.1 surround, but is routed and treated as a\nsingle source. The app stream is associated with\n[AudioAttributes](/devices/audio/attributes)\nthat give the system hints about how the audio should be expressed.\n\nThe logical streams are sent through AudioService and routed to one (and only\none) of the available physical output streams, each of which is the output of a\nmixer within AudioFlinger. After the audio attributes have been mixed down to a\nphysical stream, they are no longer available.\n\nEach physical stream is then delivered to the Audio HAL for rendering on the\nhardware. In automotive apps, rendering hardware can be local codecs (similar to\nmobile devices) or a remote processor across the vehicle's physical network.\nEither way, it's the job of the Audio HAL implementation to deliver the actual\nsample data and cause it to become audible.\n\n### External streams\n\nSound streams that shouldn't be routed through Android (for certification or\ntiming reasons) may be sent directly to the external mixer. As of Android 11,\nthe HAL is now able to request focus for these external sounds to inform Android\nsuch that it can take appropriate actions such as pausing media or preventing\nothers from gaining focus.\n\nIf external streams are media sources that should interact with the sound\nenvironment Android is generating (for example, stop MP3 playback when an\nexternal tuner is turned on), those external streams should be represented by an\nAndroid app. Such an app would request\n[Audio focus](/docs/automotive/audio/audio-focus) on behalf of the media source\ninstead of the HAL, and would respond to focus notifications by starting and\nstopping the external source as necessary to fit into the Android focus policy.\n\nThe app is also responsible for handling media key events such as play and\npause. One suggested mechanism to control such external devices is\n`HwAudioSource`. To learn more, see\n[Connect an input device in AAOS](/docs/automotive/audio/optional-player).\n\nOutput devices\n--------------\n\nAt the Audio HAL level, the device type `AUDIO_DEVICE_OUT_BUS` provides a\ngeneric output device for use in vehicle audio systems. The bus device supports\naddressable ports (where each port is the end point for a physical stream) and\nis expected to be the only supported output device type in a vehicle.\n\nA system implementation can use one bus port for all Android sounds, in which\ncase Android mixes everything together and delivers it as one stream.\nAlternatively, the HAL can provide one bus port for each\n[CarAudioContext](/docs/automotive/audio/audio-policy-configuration#static)\nto allow concurrent delivery of any sound type. This makes it possible for the\nHAL implementation to mix and duck the different sounds as desired.\n\nThe assignment of audio contexts to output devices is done through the\n`car_audio_configuration.xml` file. To learn more, see\n[Audio policy configuration](/docs/automotive/audio/audio-policy-configuration#sample)."]]