Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Công cụ chính sách âm thanh có thể định cấu hình

Trong Android 14, Hệ điều hành Android Automotive (AAOS) tận dụng tính năng quản lý âm thanh trên ô tô bằng công cụ chính sách âm thanh có thể định cấu hình (CAP) trong vùng âm thanh chính. Cụ thể, công cụ CAP cho phép AAOS chỉ kiểm soát việc định tuyến âm thanh, chỉ kiểm soát âm lượng âm thanh hoặc đồng thời kiểm soát cả việc định tuyến và âm lượng. Bạn có thể dùng các cờ sau để kiểm soát hành vi:

Sử dụng cờ useCoreAudioVolume để bật tính năng quản lý âm lượng CAP. Khi giá trị này là true, dịch vụ âm thanh trên ô tô sẽ dùng API trình quản lý âm thanh để quản lý các nhóm âm lượng.
Sử dụng cờ useCoreAudioRouting để bật tính năng quản lý định tuyến âm thanh CAP. Khi giá trị này là true, dịch vụ âm thanh trên ô tô sẽ sử dụng chế độ định tuyến chính sách âm thanh có thể định cấu hình để quản lý việc định tuyến âm thanh.

Theo mặc định, công cụ chính sách âm thanh cũng được hỗ trợ trong Android dưới dạng công cụ chính sách âm thanh mặc định.

Thông tin khái quát

Công cụ CAP dựa trên khung tham số của Intel, đây là một khung dựa trên quy tắc và dựa trên trình bổ trợ để xử lý các tham số. Cụ thể đối với tính năng quản lý âm thanh trên Android, công cụ CAP đã giới thiệu khả năng xác định các quy tắc trong tệp XML để chỉ định những nội dung sau:

Chiến lược về sản phẩm âm thanh
Quy tắc chọn thiết bị đầu ra âm thanh
Quy tắc chọn thiết bị đầu vào âm thanh
Các quy tắc quản lý âm lượng và tắt tiếng cùng với các bảng âm lượng

Khởi chạy CAP trước Android 16

Hình sau đây cho thấy thông tin tổng quan cấp cao về hoạt động quản lý cấu hình công cụ chính sách âm thanh có thể định cấu hình kể từ Android 6:

Cấu trúc công cụ CAP trước Android 16

Hình 1. Quản lý cấu hình công cụ CAP kể từ Android 6.

Như minh hoạ trong hình, cấu hình công cụ CAP được dịch vụ chính sách âm thanh thu thập bằng cách phân tích cú pháp thông tin từ tệp audio_policy_engine_configuration.xml trong phân vùng vendor. Tệp cấu hình công cụ CAP sử dụng giản đồ được xác định trong audio_policy_engine_configuration.xsd để lấy thông tin cần thiết. audio_policy_engine_configuration.xml là một ví dụ cho ngành ô tô. Các ví dụ tương tự cho các kiểu dáng khác nằm trong thư mục frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

Hình sau đây cho thấy thông tin chi tiết hơn về cách thông tin công cụ chính sách âm thanh có thể định cấu hình được tải trong dịch vụ chính sách âm thanh. Trong trường hợp này, khung tham số sẽ tải cấu trúc và chế độ cài đặt từ các tệp XML.

Đường dẫn tải công cụ CAP trước Android 16

Hình 2. Thông tin CAP được tải trong dịch vụ chính sách về âm thanh.

Tệp cấu trúc CAP trong Android 15 trở xuống

Để lấy cấu trúc và chế độ cài đặt, dịch vụ chính sách âm thanh sẽ đọc tệp ParameterFrameworkConfigurationPolicy.xml. Thao tác này tham chiếu thông tin cấu trúc thông qua vị trí tệp mô tả cấu trúc:

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

Thẻ này chỉ đến thông tin cấu trúc trong tệp:

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

Cấu trúc khung được cung cấp trong Android. Thông tin cấu trúc yêu cầu thông tin cấu trúc chiến lược sản phẩm, vì vậy Android cung cấp buildStrategiesStructureFile.py công cụ tạo, có thể tạo thông tin từ tệp XML chiến lược sản phẩm hiện có. Bạn có thể tham chiếu đến quy tắc này thông qua genrule default buildstrategiesstructurerule như sau:

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

Trong đó, audio_policy_engine_configuration_files là các tệp cấu hình của công cụ chính sách âm thanh. Ví dụ này dành cho ô tô tham chiếu đến các tệp cấu hình chính sách âm thanh trong thư mục ô tô. Các ví dụ khác cho biết cách định cấu hình bản dựng để đẩy các tệp trong phân vùng nhà cung cấp của thiết bị.

Tệp cài đặt CAP trong Android 15 trở xuống

Tương tự như cấu trúc, thông tin về chế độ cài đặt (đại diện cho các quy tắc và giá trị của tham số) được tham chiếu trong tệp ParameterFrameworkConfigurationPolicy.xml dưới dạng:

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

Android cũng cung cấp các công cụ tạo bản dựng để tạo thông tin này bằng cách sử dụng cấu hình công cụ chính sách âm thanh và các tệp khung tham số. Hãy xem phần Cấu hình để biết thêm thông tin.

Khởi động CAP HAL âm thanh AIDL

Kể từ Android 16, định nghĩa API AIDL Audio HAL được mở rộng bằng các cấu hình của công cụ chính sách âm thanh, AudioHalCapConfiguration.aidl. Hình sau đây cho thấy thông tin tổng quan cấp cao về hoạt động quản lý cấu hình công cụ CAP kể từ Android 16:

Cấu trúc aidl của công cụ CAP

Hình 3. Quản lý cấu hình công cụ CAP kể từ Android 16.

Dịch vụ chính sách âm thanh lấy thông tin về công cụ CAP bằng cách sử dụng trực tiếp API AIDL Audio HAL thay vì phân tích cú pháp thông tin từ các tệp XML trong phân vùng nhà cung cấp của thiết bị.

Trong cấu hình này, cấu trúc của khung tham số vẫn được công cụ CAP tải ở phía máy chủ âm thanh.

Đường dẫn tải aidl của công cụ CAP

Hình 4. Cấu trúc công cụ CAP.

Trong mọi trường hợp, cấu hình phải chỉ định đầy đủ thông tin liên quan đến chiến lược sản phẩm, nhóm số lượng lớn và tiêu chí.

Hình sau đây cho thấy thông tin tổng quan cấp cao về các API HAL âm thanh AIDL mà dịch vụ chính sách âm thanh dùng để lấy cấu hình công cụ CAP:

API AIDL của công cụ CAP Hình 5. Các API HAL âm thanh AIDL.

Trong chế độ thiết lập này, dịch vụ chính sách âm thanh sẽ lấy thông tin sau từ HAL âm thanh AIDL:

Cấu hình
Chiến lược
Tập
Tiêu chí
Cài đặt

Trình tải HAL âm thanh AIDL mặc định

Để quá trình chuyển đổi từ HIDL sang AIDL diễn ra suôn sẻ, HAL âm thanh AIDL mặc định cung cấp một trình tải công cụ CAP XML. Nhà cung cấp có thể sử dụng trực tiếp trình tải này bằng cách mở rộng HAL âm thanh của họ bằng HAL âm thanh mặc định hoặc tham chiếu đến thư viện libaudioserviceexampleimpl.

Trình tải HAL âm thanh AIDL mặc định sử dụng audio_policy_engine_configuration.xml để lấy thông tin sau:

Cấu hình
Chiến lược
Tập
Tiêu chí

Thông tin cấu trúc được lấy từ tệp PolicyConfigurableDomains.xml. Điểm khác biệt chính so với cơ chế trước đây là thông tin cấu trúc cũng được HAL âm thanh AIDL thu thập thay vì khung tham số tại dịch vụ chính sách âm thanh.

Nhà cung cấp có thể sử dụng công cụ domaingeneratorpolicyrule để tạo các miền có thể định cấu hình bằng thông tin từ cấu hình công cụ chính sách âm thanh. Bạn có thể dùng ví dụ về thiết bị ảo Cuttlefish dành cho ô tô làm tài liệu tham khảo.

Cấu trúc trong cấu hình AIDL

Trong Android 16 trở lên, dịch vụ chính sách âm thanh sẽ lấy thông tin cấu trúc bằng cách đọc và phân tích ParameterFrameworkConfigurationCap.xml[tệp](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). Cụ thể, nó lấy thông tin từ tệp mô tả cấu trúc:

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

Khung này sẽ thả các tệp bắt buộc vào thư mục /etc/parameter-framework/ cùng với thông tin cần thiết.

Cấu trúc này đại diện cho các tham số cần được kiểm soát, vì vậy, bạn nên tham chiếu các tham số này trong cấu hình hoặc miền. Để làm việc này, cấu hình công cụ AIDL phải sử dụng một tên được xác định trước cho các tham số. Đối với các chiến lược sản phẩm, cấu trúc được định cấu hình trong CapProductStrategies.xml.

Chiến lược mặc định cho sản phẩm

Bắt đầu với các giá trị mặc định được cung cấp trong công cụ mặc định, các chiến lược sản phẩm bắt đầu bằng tiền tố STRATEGY_:

STRATEGY_PHONE
STRATEGY_SONIFICATION
STRATEGY_ENFORCED_AUDIBLE
STRATEGY_ACCESSIBILITY
STRATEGY_SONIFICATION_RESPECTFUL
STRATEGY_MEDIA
STRATEGY_DTMF
STRATEGY_CALL_ASSISTANT
STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Định dạng này được cung cấp để giảm bớt quá trình chuyển đổi từ HIDL sang AIDL cho những thiết bị đang sử dụng các chiến lược mặc định. Thay đổi định dạng này có một số tác động đến các tệp hiện có (ví dụ: PfW, XML) được dùng để định cấu hình công cụ. Cụ thể, bạn nên thay đổi tất cả các tham chiếu đến chiến lược sản phẩm để sử dụng tên mới, ví dụ:

Tên thông số cấu hình không phải AIDL
`/Policy/policy/product_strategies/media/device_address` `/Policy/policy/product_strategies/media/selected_output_devices/mask`

Tên thông số cấu hình AIDL
`/Policy/policy/product_strategies/STRATEGY_MEDIA/device_address` `/Policy/policy/product_strategies/STRATEGY_MEDIA/selected_output_devices/mask`

Chiến lược sản phẩm do OEM xác định

Công cụ có thể định cấu hình cho phép các OEM thay đổi định nghĩa về chiến lược sản phẩm. Để tiếp tục hỗ trợ việc này, tệp chiến lược sản phẩm CapProductStrategies.xml cũng cung cấp 40 chiến lược sản phẩm có thể mở rộng của nhà cung cấp từ vx_1000 đến vx_1039. Tất cả các tiện ích của nhà cung cấp phải bắt đầu bằng tiền tố vx_ và theo sau là một số đại diện cho mã chiến lược sản phẩm trong định nghĩa chiến lược sản phẩm AIDL audio HAL. Các định nghĩa còn lại (ví dụ: nhóm thuộc tính âm thanh, tên) được lấy từ đối tượng AudioHALProductStrategy trong cấu hình công cụ HAL âm thanh.

Tương tự như các chiến lược sản phẩm mặc định, các tài liệu tham khảo OEM do nhà cung cấp xác định cũng phải được điều chỉnh giữa cấu hình không phải AIDL và cấu hình AIDL, ví dụ:

Tên thông số cấu hình không phải AIDL
`/Policy/policy/product_strategies/oem_extension_strategy/device_address` `/Policy/policy/product_strategies/oem_extension_strategy/selected_output_devices/mask`

Tên thông số cấu hình AIDL
`/Policy/policy/product_strategies/vx_1037/device_address` `/Policy/policy/product_strategies/vx_1037/selected_output_devices/mask`

Chiến lược sản phẩm

Chiến lược sản phẩm cung cấp một cách để tuỳ chỉnh cách phân loại và nhóm các luồng âm thanh. Điều này giúp bạn linh hoạt hơn trong việc định cấu hình các thiết bị âm thanh, bao gồm cả cách định tuyến và cách quản lý âm lượng của các thiết bị đó. Mỗi chiến lược sản phẩm có thể có một hoặc nhiều nhóm thuộc tính âm thanh. Các nhóm này xác định những luồng cần được liên kết với chiến lược sản phẩm đó. Các nhóm thuộc tính âm thanh này cho phép phân loại âm thanh theo cách chi tiết hơn và có thể là sự kết hợp của các loại sau:

Các loại Mục đích sử dụng mô tả lý do một âm thanh đang được phát (tức là nội dung nghe nhìn, thông báo, cuộc gọi).
Loại nội dung mô tả nội dung đang phát (tức là nhạc, lời nói, video, âm thanh hoá).
Các loại cờ xác định các hành vi hoặc yêu cầu khác nhau liên quan đến luồng phát.
Các loại thẻ hỗ trợ mọi danh sách tuỳ ý gồm các giá trị chuỗi của nhà cung cấp.
- Mỗi chuỗi phải bắt đầu bằng VX_, theo sau là một chuỗi dạng chữ và số (ví dụ: VX_OEM, VX_NAVIGATION)

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

Đoạn trích này cho thấy một ví dụ về chiến lược sản phẩm được dùng trong trình mô phỏng ô tô. Thẻ này chứa 2 thuộc tính âm thanh, lần lượt là nội dung nghe nhìn và trò chơi sử dụng âm thanh. Chiến lược sản phẩm này phù hợp với ngữ cảnh âm thanh MUSIC được dùng trong dịch vụ âm thanh trên ô tô, nhưng không bắt buộc phải có sự phù hợp như vậy. Một trong những tiện ích chính dành cho các OEM sử dụng CAP cùng với Android là cho phép các định nghĩa nhóm âm thanh linh hoạt hơn.

Nhóm âm lượng

Ngoài ra, mỗi nhóm thuộc tính âm thanh phải có một nhóm âm lượng được liên kết. Nhóm âm lượng này được liên kết với mọi luồng có thuộc tính âm thanh phù hợp thuộc nhóm thuộc tính âm thanh. Chiến lược sản phẩm âm nhạc mẫu trong phần Chiến lược sản phẩm có nhóm âm lượng media và định nghĩa về nhóm âm lượng nội dung nghe nhìn như sau:

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

Trong định nghĩa này, nhóm ổ đĩa chứa:

Tên nhóm
Chỉ mục tối thiểu của nhóm
Chỉ mục tối đa của nhóm
Đường cong nhóm âm lượng

Các đường cong nhóm âm lượng chứa ánh xạ theo điểm giữa chỉ mục nhóm âm lượng và mức tăng âm lượng theo đơn vị mili-bel. Các điểm được cung cấp dùng để nội suy tuyến tính mức tăng phù hợp nhất khi âm lượng được quản lý. Mỗi đường cong nhóm âm lượng được liên kết với một danh mục loại thiết bị (ví dụ: tai nghe, loa, nội dung nghe nhìn bên ngoài).

Nhóm âm lượng quản lý âm lượng cho các luồng thuộc nhóm thuộc tính âm thanh. Ví dụ: khi một luồng có thuộc tính âm thanh chứa nhạc hoặc trò chơi được bắt đầu, chỉ mục âm lượng được đặt gần đây nhất cho nhóm âm lượng nội dung nghe nhìn sẽ được dùng. Trong trường hợp này, đường cong danh mục thiết bị tương ứng sẽ được chọn dựa trên thiết bị đã chọn và mức tăng tương ứng sẽ được đặt khi luồng bắt đầu.

Cấu hình

Trong công cụ CAP, các cấu hình được dùng để xác định các điều kiện hoặc quy tắc quyết định cách hoạt động của âm thanh. Các cấu hình này được đánh giá trong thời gian chạy để chọn các quy tắc phù hợp cần áp dụng tuỳ thuộc vào trạng thái hiện tại của hệ thống âm thanh.

Như minh hoạ trong hình 5, API này chứa nhiều miền, mục tiêu của mỗi miền là chia logic thành các vấn đề định tuyến nhỏ hơn để giải quyết (ví dụ: thiết bị 1, thiết bị 2).

Mỗi miền đều có các cấu hình và mỗi cấu hình đều có một bộ quy tắc. Các quy tắc được thiết lập dựa trên tiêu chí do AudioPolicyManager cung cấp:

Chế độ âm thanh
Các thiết bị đầu vào và đầu ra hiện có
Địa chỉ của các thiết bị đầu vào và đầu ra hiện có
Sử dụng cho
- Nội dung nghe nhìn
- Liên lạc
- Đang ghi âm
- Đế
- Hệ thống
- Âm thanh hệ thống HDMI
- Âm thanh vòm được mã hoá
- Rung khi đổ chuông

Mỗi miền chứa các cấu hình quy định những quy tắc sẽ ảnh hưởng đến hành vi. Xin lưu ý rằng thứ tự cấu hình rất quan trọng và bạn cần đảm bảo các cấu hình được sắp xếp theo thứ tự bắt buộc. Sau khi các quy tắc cho một cấu hình được xác thực, cấu hình đó sẽ được chọn.

Đoạn mã sau đây cho thấy ví dụ trích dẫn về một tệp khung tham số. Bạn có thể dùng tệp này để tạo tệp XML cần thiết nhằm định cấu hình các miền có thể định cấu hình:


supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

Miền DeviceForProductStrategies xác định cách áp dụng các quy tắc khác nhau khi xử lý việc chọn thiết bị theo chiến lược về sản phẩm. Các phần màu xanh dương mô tả những quy tắc cần được xem xét và phần màu xanh lục là cấu hình được áp dụng. Ví dụ cụ thể này chứa các cấu hình sau:

Chọn thiết bị Bluetooth A2DP cho chiến lược sản phẩm âm nhạc (mã nhận dạng 1000, vx_1000)
- Nếu dùng cho nội dung nghe nhìn, không loại trừ A2DP
- Nếu dùng để giao tiếp, không phải là BT SCO
- Nếu có thiết bị, hãy thêm BT A2DP
Chọn thiết bị trên bus
- Nếu có thiết bị trên bus
- Nếu địa chỉ là BUS00_MEDIA
Chọn thiết bị đầu ra mặc định nếu không

Để tạo tệp XML công cụ chính sách có thể định cấu hình tương ứng, hãy chạy các tệp parameter-framework (PFW) thông qua hệ thống xây dựng bằng cách xác định một quy tắc xây dựng theo các bước sau:

Trong tệp Android.bp, hãy tạo một filegroup cho tệp:

filegroup {
    name: ":device_for_product_strategies.pfw",
    srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
}

Thêm tệp này vào các tệp PfW khác (nếu có).

filegroup {
    name: "edd_files",
    srcs: [
        ":device_for_input_source.pfw",
        ":volumes.pfw",
        ":device_for_product_strategyies.pfw",
    ],
}

Tạo quy tắc tạo miền tương ứng:

genrule {
    name: "domaingeneratorpolicyrule_gen",
    defaults: ["domaingeneratorpolicyrule"],
    srcs: [
        ":audio_policy_engine_criterion_types",
        ":audio_policy_pfw_structure_files",
        ":audio_policy_pfw_toplevel",
        ":edd_files",
    ],
}

Trong đó, domaingeneratorpolicyrule là một quy tắc tạo do khung cung cấp để tạo tệp PolicyConfigurableDomains.xml. Các tệp nguồn khác (scrs) có trong các quy tắc tạo miền như sau:

Nguồn	Mô tả
`audio_policy_pfw_toplevel`	Tệp cấu hình cấp cao nhất của khung tham số.
`audio_policy_pfw_structure_files`	Các tệp cấu trúc tạo miền được dùng để tạo tệp cấu hình.
`audio_policy_engine_criterion_types`	Tệp XML về các loại tiêu chí, mô tả các tiêu chí được dùng trong quá trình tạo.
`edd_files`	Danh sách các tệp miền đơn lẻ (mỗi tệp chứa một thẻ <ConfigurableDomain>).

Sau khi chạy quy tắc tạo trong bản dựng, PolicyConfigurableDomains.xml sẽ được tạo cùng với tất cả các miền. Sau đây là một đoạn trích từ tệp được tạo bằng ví dụ về các quy tắc PfW:

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

Gỡ lỗi CAP

Bạn có thể sử dụng remote-process để kết xuất các cấu hình CAP:

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

Thao tác này sẽ cho thấy tất cả các miền và cấu hình, bao gồm cả các điều kiện áp dụng. Sau đây là một đoạn trích từ thiết bị ô tô Cuttlefish bằng cách sử dụng Bluetooth A2DP, thiết bị bus và cấu hình mặc định. Xem phần Cấu hình:

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

Để biết thêm thông tin về các lệnh khác có sẵn để gỡ lỗi khung tham số CAP, hãy sử dụng công cụ này:

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

Để sử dụng công cụ này, nhà sản xuất OEM phải cho phép điều chỉnh trên thiết bị. Để xác minh xem thiết bị có cho phép điều chỉnh hay không, hãy dùng lệnh sau:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

Trong Android 15 trở xuống, tệp có thể khác, vì vậy hãy dùng lệnh sau:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

Tệp này phải chứa TuningAllowed="true" cùng với cổng máy chủ tương ứng:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

Tệp này được tạo tự động theo loại hình ảnh bản dựng (hoặc sử dụng một tệp khác cho bản phát hành hoặc gỡ lỗi cho bản dựng cũ). Bản phát hành đặt TuningAllowed thành false mà không có cổng socket (các socket bị cấm đối với bản phát hành). Các bản dựng kỹ thuật và userdebug đặt giá trị này thành true bằng cổng ổ cắm được dùng. Xin lưu ý rằng đây là tệp mà audio_policy_pfw_toplevel tham chiếu đến. Công cụ quy trình từ xa cũng phải có trong tệp make hoặc tệp bản dựng của thiết bị:

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

Bạn cũng phải thêm chính sách SELinux tương ứng để cho phép các socket. Điều này chỉ hoạt động ở chế độ gỡ lỗi vì chế độ phát hành không cho phép sử dụng các socket:

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Di chuyển CAP trong Android 16

Do những thay đổi lớn mà công cụ CAP HAL âm thanh AIDL và các phiên bản trước mang lại, bạn nên cân nhắc nhiều trường hợp chuyển đổi thiết bị. Phần này đề cập đến những tình huống chuyển đổi nổi bật nhất và đưa ra các đề xuất về việc cần làm để bật cấu hình công cụ CAP.

Trường hợp 1: Thiết bị mới sử dụng Android 16 trở lên, không có nguồn nào trước đó cho cấu hình CAP của thiết bị

Thiết bị mới phải khởi động bằng mã Android 16 trở lên trên phân vùng vendor. Điều đó có nghĩa là HAL âm thanh phải hiển thị cấu hình công cụ chính sách âm thanh có thể định cấu hình thông qua giao diện AIDL. Bạn nên sao chép cấu hình công cụ CAP của thiết bị từ các ví dụ. Không nên có định nghĩa miền PfW CAP trên phân vùng vendor.

Hình ảnh hệ thống dùng cho thiết bị là Android 16 trở lên. Khung dịch vụ âm thanh phát hiện cấu hình CAP thông qua giao diện AIDL HAL âm thanh, vì vậy, khung này sẽ khởi tạo PfW bằng định nghĩa miền PfW CAP từ hình ảnh hệ thống và tải cấu hình CAP của thiết bị nhận được thông qua AIDL.

Để xem ví dụ, hãy xem thiết bị ảo Cuttlefish dành cho ô tô. Thiết bị này được giới thiệu trong thay đổi này và có thể được tham chiếu cho các tệp bắt buộc, quy tắc xây dựng và tạo các tệp bắt buộc để thiết lập các tệp cấu hình bắt buộc. Điều này hoạt động với các trình tải được cung cấp trong HAL âm thanh AIDL mặc định.

Trường hợp 2: Thiết bị mới dùng Android 16 trở lên, từ một thiết bị cũ dùng CAP

Thiết bị mới phải khởi động bằng mã Android 16 trở lên trên phân vùng vendor. Tuy nhiên, vì OEM có cấu hình công cụ CAP của thiết bị có thể sử dụng, nên OEM sẽ muốn sử dụng cấu hình này làm điểm bắt đầu (hoặc sử dụng lại hoàn toàn). Phiên bản AIDL của cấu hình CAP có một số thay đổi so với phiên bản Android 15 trở xuống, vì vậy, nhà cung cấp phải chuyển đổi cấu hình hiện có sang AIDL. Hãy xem phần thảo luận trong Chiến lược sản phẩm để biết những thay đổi giữa Android 16 và các phiên bản thấp hơn đối với những thay đổi bắt buộc. Nhìn chung, khung âm thanh sẽ phát hiện và tải cấu hình CAP theo cách tương tự như trong Tình huống 1.

Trường hợp 3: Thiết bị hiện có có CAP chỉ cập nhật phân vùng hệ thống lên Android 16

Trong trường hợp này, phân vùng vendor chứa cấu hình CAP của thiết bị Android 15 trở xuống và định nghĩa miền CAP PfW. Phân vùng vendor không bị ảnh hưởng, nên vẫn dùng HIDL HAL. Khung này tuân theo kịch bản Android 15 trở xuống và tải tất cả cấu hình liên quan đến CAP từ phân vùng vendor.

Trường hợp 4: Thiết bị hiện có được phát hành trên Android 15, có CAP

CAP không được hỗ trợ trong AIDL trên Android 15, vì vậy, một số nhà cung cấp đã phát hành thiết bị mới có AIDL Audio HAL và CAP, được khung âm thanh tải. Chế độ kết hợp này không chính thức nhưng có trong Android 16. Xin lưu ý rằng bạn không được dùng chế độ này để phát hành thiết bị mới trên Android 16, mà chỉ dùng để cho phép các thiết bị hiện có có nhà cung cấp Android 15 được cập nhật lên Android 16 (bản cập nhật phân vùng system).

Khung âm thanh sẽ phát hiện cấu hình âm thanh HAL AIDL mà không có cấu hình CAP. Đối với cấu hình CAP, dịch vụ chính sách âm thanh (khung âm thanh) sẽ quay lại tải cấu hình CAP từ phân vùng vendor. Trong trường hợp này, cả định nghĩa miền PfW CAP và cấu hình CAP của thiết bị đều phải được tải từ phân vùng vendor.

Tóm tắt quá trình di chuyển CAP

Bảng sau đây tóm tắt các yêu cầu và cấu hình hệ thống và nhà cung cấp tương thích đối với cấu hình CAP:

Phân vùng hệ thống	Trường hợp	Phiên bản mã phân vùng của nhà cung cấp	Loại HAL âm thanh chính	Vị trí định nghĩa miền PfW CAP	Cấu hình CAP của thiết bị
Android 15	4	Android 14 trở xuống	HIDL	`vendor`	Phiên bản HIDL
Android 16	3	Android 14 trở xuống	HIDL	`vendor`	Phiên bản HIDL
Android 16	4	Android 15	AIDL	`vendor`	Phiên bản HIDL
Android 16	2	Android 16	AIDL	`system`	Phiên bản AIDL được chuyển đổi từ HIDL
Android 16	1	Android 16	AIDL	`system`	Phiên bản AIDL trong ví dụ