自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
總覽
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android Automotive OS (AAOS) 以核心 Android 音訊堆疊為基礎，可支援在車輛中做為資訊娛樂系統的用途。AAOS 負責提供資訊娛樂音效 (即媒體、導航和通訊)，但不會直接提供有嚴格可用性和時間限制的鈴聲和警示。
雖然 AAOS 提供信號和機制，協助車輛管理音訊，但最終還是要由車輛決定應向駕駛員和乘客播放哪些音訊，確保安全性重要音訊和法規音訊不會中斷。
由於 AAOS 會運用 Android 音訊堆疊，因此播放音訊的第三方應用程式不需要採取與手機不同的做法。如音訊政策設定所述，應用程式的音訊轉送會由 AAOS 自動管理。
由於 Android 會管理車輛的媒體體驗，因此應用程式應代表外部媒體來源 (例如收音機)，以便處理來源的音訊焦點和媒體按鍵事件。
Android 音效和串流
汽車音響系統會處理下列音訊和串流：
圖 1. 以串流為中心的架構圖。
Android 會管理來自 Android 應用程式的音訊，控制這些應用程式，並根據音訊類型將音訊路由至 HAL 的輸出裝置：
為確保可靠性，外部聲響 (來自獨立來源，例如安全帶警示鈴聲) 會在 Android 外部、HAL 之下，甚至在獨立硬體中管理。系統導入者必須提供混合器，以便接受來自 Android 的一或多個音訊輸入串流，然後以適當方式將這些串流與車輛所需的外部音訊來源結合。Android Control HAL 提供不同的機制，讓 Android 以外產生的聲音能夠傳回 Android：
音訊 HAL 實作和外部混合器負責確保可聽到安全性至關重要的外部聲音，並混合 Android 提供的串流，並將其路由至適當的喇叭。
Android 音效
應用程式可能會有一或多個透過標準 Android API 互動的播放器 (例如，用於焦點控制的 AudioManager 或用於串流的 MediaPlayer)，以便發出一個或多個邏輯音訊資料串流。這類資料可能是單聲道或 7.1 環場音效，但會以單一來源進行路由和處理。應用程式串流會與 AudioAttributes 建立關聯，提供系統有關音訊應如何呈現的提示。
邏輯串流會透過 AudioService 傳送，並路由至一個 (且僅一個) 可用的實體輸出串流，每個串流都是 AudioFlinger 中混合器的輸出內容。音訊屬性混合至實體串流後，就無法再使用。
然後將每個實體串流傳送至 Audio HAL，以便在硬體上轉譯。在車用應用程式中，轉譯硬體可以是本機編解碼器 (類似行動裝置)，或車輛實體網路中的遠端處理器。無論如何，Audio HAL 實作功能的任務就是提供實際的取樣資料，並讓取樣資料可供播放。
外部串流
不應透過 Android 路由的音訊串流 (出於認證或時間因素) 可能會直接傳送至外部混音器。自 Android 11 起，HAL 現可針對這些外部聲音要求焦點，以便通知 Android 採取適當的動作，例如暫停媒體或防止其他人獲得焦點。
如果外部串流是應與 Android 產生的音訊環境互動的媒體來源 (例如在啟用外部調諧器時停止 MP3 播放)，則應由 Android 應用程式代表媒體來源 (而非 HAL) 要求音訊焦點，並根據需要啟動及停止外部來源，以符合 Android 焦點政策。
應用程式也負責處理媒體鍵事件，例如播放和暫停。建議您使用 HwAudioSource 來控制這類外部裝置。詳情請參閱「在 AAOS 中連接輸入裝置」。
輸出裝置
在 Audio HAL 層級，裝置類型 AUDIO_DEVICE_OUT_BUS 會提供通用輸出裝置，用於車輛音訊系統。匯流排裝置支援可尋址的通訊埠 (每個通訊埠都是實體串流的端點)，且應為車輛中唯一支援的輸出裝置類型。
系統實作可以使用一個匯流排埠來處理所有 Android 音效，在這種情況下，Android 會將所有音效混合在一起，並以單一串流提供。或者，HAL 可以為每個 CarAudioContext 提供一個匯流排埠，以便同時傳送任何聲音類型。這樣一來，HAL 實作項目就能視需要混合及降低不同音效的音量。
音訊內容會透過 car_audio_configuration.xml 檔案指派給輸出裝置。詳情請參閱「音訊政策設定」。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-06-12 (世界標準時間)。
[[["容易理解","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"]],["上次更新時間：2025-06-12 (世界標準時間)。"],[],[],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)."]]
