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

Trong Android 14, Android Automotive Operating System (AAOS) tận dụng công cụ quản lý âm thanh trên ô tô 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ể sử 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ý dung lượng CAP. Khi giá trị này là true, dịch vụ âm thanh trên ô tô sẽ sử dụng các 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 tính năng đị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 trình bổ trợ và quy tắc để xử lý các tham số. Đối với việc quản lý âm thanh trên Android nói riêng, công cụ CAP đã giới thiệu khả năng xác định quy tắc tệp XML để chỉ định những nội dung sau:

• Chiến lược sản phẩm âm thanh
• Quy tắc lựa chọn thiết bị đầu ra âm thanh
• Quy tắc lựa chọn thiết bị đầu vào âm thanh
• Quy tắc quản lý âm lượng và tắt tiếng cùng với 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ề việc 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:

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

Như minh hoạ trong hình, dịch vụ chính sách âm thanh sẽ lấy cấu hình công cụ CAP 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ủa công cụ CAP sử dụng giản đồ được xác định trong audio_policy_engine_configuration.xsd để lấy thông tin bắt buộc. 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 tải thông tin công cụ chính sách âm thanh có thể định cấu hình 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.

Hình 2. Thông tin CAP được tải trong dịch vụ chính sách â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 đến 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"/>

Phần này trỏ đế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 công cụ tạo buildStrategiesStructureFile.py 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 giá trị này thông qua buildstrategiesstructurerule mặc định của genrule như sau:

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

Trong đó audio_policy_engine_configuration_files là 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 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 như sau:

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

Android cũng cung cấp các công cụ 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 AIDL audio HAL CAP

Kể từ Android 16, định nghĩa API HAL âm thanh AIDL được mở rộng bằng các cấu hình 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ề việc quản lý cấu hình công cụ CAP kể từ Android 16:

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 công cụ CAP bằng cách sử dụng trực tiếp API HAL âm thanh AIDL 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 tải bằng công cụ CAP ở phía máy chủ âm thanh.

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ản phẩm 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 sử dụng để lấy cấu hình công cụ CAP:

Hình 5. 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 AIDL Audio HAL mặc định

Để quá trình chuyển đổi từ HIDL sang AIDL diễn ra suôn sẻ, HAL âm thanh AIDL âm thanh mặc định cung cấp trình tải công cụ CAP XML. Nhà cung cấp có thể sử dụng trình tải này trực tiếp bằng cách mở rộng HAL âm thanh bằng HAL âm thanh mặc định hoặc tham chiếu 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 đó 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 trong ngành ô 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 cú pháp tệp ParameterFrameworkConfigurationCap.xml. Cụ thể, tệp này lấy thông tin từ tệp mô tả cấu trúc:

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

Khung này 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, các tham số này phải được tham chiếu trong cấu hình hoặc miền. Do đó, cấu hình công cụ AIDL phải sử dụng 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 sản phẩm mặc định

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 các thiết bị đang sử dụng chiến lược mặc định. Thay đổi định dạng này có một số tác động đối với các tệp hiện có (ví dụ: PfW, XML) 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 chiến lược sản phẩm để sử dụng tên mới, ví dụ:

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 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ả tiện ích của nhà cung cấp phải bắt đầu bằng tiền tố vx_, 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 HAL âm thanh AIDL. Phần còn lại của định nghĩa (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ệp tham chiếu 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ụ:

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 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 bạn 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:

• Loại Sử dụng mô tả lý do âm thanh đang phát (tức là nội dung nghe nhìn, thông báo, cuộc gọi).
• Loại Content-type mô tả nội dung đang phát (tức là nhạc, lời nói, video, âm thanh).
• 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.
• 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>

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

Nhóm phương tiện

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 khớp với thuộc tính âm thanh 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 của 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 phương tiện 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 mối liên kết theo từng điểm giữa chỉ mục nhóm âm lượng và mức tăng âm lượng tính bằng milibel. Các điểm được cung cấp được dùng để nội suy tuyến tính mức tăng phù hợp nhất khi quản lý âm lượng. 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 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ó cá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 sử dụng. Trong trường hợp này, đường cong danh mục thiết bị tương ứng được chọn dựa trên thiết bị đã chọn và độ lợi tương ứng được đặt khi bắt đầu luồng.

Cấu hình

Trong công cụ CAP, cấu hình được dùng để xác định các điều kiện hoặc quy tắc xác đị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 thích hợp á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 chứa nhiều miền, mục tiêu của mỗi miền là phân 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 có cấu hình và mỗi cấu hình có một bộ quy tắc. Các quy tắc được thiết lập dựa trên các tiêu chí do AudioPolicyManager cung cấp:

• Chế độ âm thanh
• Các thiết bị đầu vào và đầu ra có sẵn
• Địa chỉ 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 chỉ định các 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 rằng các cấu hình đó tuân theo thứ tự bắt buộc. Sau khi xác thực các quy tắc cho một cấu hình, cấu hình đó sẽ được chọn.

Mã sau đây cho thấy một ví dụ trích dẫn về tệp khung tham số. Tệp này có thể được dùng để tạo tệp XML bắt buộc 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ý lựa chọn thiết bị cho chiến lược sản phẩm. Các phần màu xanh dương mô tả các 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ã 1000, vx_1000)
  • Nếu dùng cho nội dung nghe nhìn, không loại trừ A2DP
  • Nếu được dùng để giao tiếp, thì BT SCO không phải là
  • Nếu có thiết bị, hãy thêm BT A2DP
• Chọn thiết bị bus (bus device)
  • Nếu có thiết bị bus
  • Nếu địa chỉ là BUS00_MEDIA
• Nếu không, hãy chọn thiết bị đầu ra mặc định

Để tạo tệp XML của 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 khung tham số (PFW) thông qua hệ thống xây dựng bằng cách xác định quy tắc bản dựng theo các bước sau:

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

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

2. 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",
       ],
   }
   

3. 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 quy tắc tạo miền như sau:

   Nguồn	Mô tả
   audio_policy_pfw_toplevel	Tệp cấu hình khung thông số cấp cao nhất.
   audio_policy_pfw_structure_files	Tệp cấu trúc tạo miền dùng để tạo tệp cấu hình.
   audio_policy_engine_criterion_types	Tệp XML về loại tiêu chí, mô tả các tiêu chí được sử dụng trong quá trình tạo.
   edd_files	Danh sách tệp miền đơn (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 với tất cả các miền. Sau đây là một phần trích dẫn từ tệp được tạo bằng ví dụ về 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ấu hình CAP:

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

Trang này hiển thị tất cả miền và cấu hình, bao gồm cả các điều kiện áp dụng. Phần sau đây cho thấy một đoạn trích từ thiết bị ô tô Cuttlefish sử dụng A2DP Bluetooth, thiết bị bus và cấu hình mặc định. Xem 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ó thể dùng để 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 thiết bị gốc (OEM) phải cho phép điều chỉnh trong thiết bị. Để xác minh xem thiết bị có cho phép điều chỉnh hay không, hãy sử 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 sử 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 bản 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 ổ cắm (ổ cắm bị cấm trong bản phát hành). Bản dựng kỹ thuật và userdebug đặt giá trị này thành true với cổng ổ cắm được sử dụng. Xin lưu ý rằng đây là tệp được audio_policy_pfw_toplevel tham chiếu. Công cụ xử lý từ xa cũng phải có trong tệp bản dựng hoặc tạo 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 đưa vào chính sách SELinux tương ứng để cho phép các ổ cắm. Điều này chỉ hoạt động đối với chế độ gỡ lỗi vì chế độ phát hành không cho phép các ổ cắm một cách rõ ràng:

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

Di chuyển CAP trong Android 16

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

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

Thiết bị mới phải khởi chạy bằng mã Android 16 trở lên trên phân vùng vendor. Điều đó có nghĩa là công cụ này 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 HAL âm thanh AIDL. Bạn nên sao chép cấu hình công cụ Device CAP từ các ví dụ. Không được có định nghĩa miền CAP PfW 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 khám phá cấu hình CAP thông qua giao diện HAL âm thanh AIDL, do đó, khung này sẽ khởi chạy PfW bằng cách sử dụng định nghĩa miền CAP PfW từ hình ảnh hệ thống và tải cấu hình CAP thiết bị nhận được thông qua AIDL.

Ví dụ: hãy xem thiết bị ảo Cuttlefish cho ô tô đượ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 tệp cần thiết để thiết lập các tệp cấu hình bắt buộc. Phương thức 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.

Tình huống 2: Thiết bị mới sử dụng Android 16 trở lên, từ một thiết bị cũ sử dụng CAP

Thiết bị mới phải khởi chạy bằng mã Android 16 trở lên trên phân vùng vendor. Tuy nhiên, vì nhà sản xuất thiết bị gốc (OEM) có cấu hình công cụ CAP thiết bị có thể sử dụng, nên họ muốn sử dụng cấu hình đó làm điểm xuất phát (hoặc sử dụng lại hoàn toàn cấu hình đó). 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 nội dung thảo luận trong phần Chiến lược sản phẩm để biết những thay đổi cần thiết giữa Android 16 và các phiên bản thấp hơn. Nhìn chung, khung âm thanh sẽ khám phá và tải cấu hình CAP giống như trong Tình huống 1.

Trường hợp 3: Thiết bị hiện có với 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 phiên bản Android 15 trở xuống của cấu hình CAP của thiết bị và định nghĩa miền CAP PfW. Phân vùng vendor không bị ảnh hưởng, vì vậy, phân vùng này vẫn sử dụng HIDL HAL. Khung này tuân theo trường hợp 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.

Tình huống 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 các thiết bị mới có AIDL Audio HAL và CAP do 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 sử dụng chế độ này để phát hành thiết bị mới trên Android 16, mà thay vào đó là để cho phép cập nhật các thiết bị hiện có của nhà cung cấp Android 15 lên Android 16 (bản cập nhật phân vùng system).

Khung âm thanh phát hiện cấu hình âm thanh HAL âm thanh 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, bạn phải tải cả định nghĩa miền CAP PfW và cấu hình CAP của thiết bị từ phân vùng vendor.

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

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