Mesin kebijakan audio yang dapat dikonfigurasi

Di Android 14, Sistem Operasi Android Automotive (AAOS) memanfaatkan mesin kebijakan audio yang dapat dikonfigurasi (CAP) untuk pengelolaan audio mobil dalam zona audio utama. Secara khusus, mesin CAP memungkinkan AAOS mengontrol hanya perutean audio, hanya volume audio, atau perutean dan volume secara bersamaan. Flag berikut dapat digunakan untuk mengontrol perilaku:

• Gunakan tanda useCoreAudioVolume untuk mengaktifkan pengelolaan volume CAP. Jika nilai ini adalah true, layanan audio mobil menggunakan audio manager API untuk mengelola grup volume.

• Gunakan tanda useCoreAudioRouting untuk mengaktifkan pengelolaan perutean audio CAP. Jika nilai ini adalah true, layanan audio mobil menggunakan perutean kebijakan audio yang dapat dikonfigurasi untuk mengelola perutean audio.

Mesin kebijakan audio juga didukung di Android secara default dalam bentuk mesin kebijakan audio default.

Latar belakang

Mesin CAP didasarkan pada framework parameter Intel, yang merupakan framework berbasis plugin dan berbasis aturan untuk menangani parameter. Khusus untuk pengelolaan audio Android, mesin CAP memperkenalkan kemampuan untuk menentukan aturan file XML guna menentukan hal berikut:

• Strategi produk audio
• Aturan untuk pemilihan perangkat output audio
• Aturan untuk pemilihan perangkat input audio
• Aturan untuk mengelola volume dan membisukan audio bersama dengan tabel volume

Inisialisasi CAP sebelum Android 16

Gambar berikut menunjukkan ringkasan tingkat tinggi pengelolaan konfigurasi mesin kebijakan audio yang dapat dikonfigurasi pada Android 6:

Gambar 1. Pengelolaan konfigurasi mesin CAP mulai dari Android 6.

Seperti yang ditunjukkan pada gambar, konfigurasi mesin CAP diperoleh oleh layanan kebijakan audio dengan mem-parsing informasi dari file audio_policy_engine_configuration.xml di partisi vendor. File konfigurasi mesin CAP menggunakan skema yang ditentukan dalam audio_policy_engine_configuration.xsd untuk mendapatkan informasi yang diperlukan. audio_policy_engine_configuration.xml adalah contoh untuk otomotif. Contoh serupa untuk faktor bentuk lainnya ada di folder frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

Gambar berikut menunjukkan informasi yang lebih mendetail tentang cara informasi mesin kebijakan audio yang dapat dikonfigurasi dimuat dalam layanan kebijakan audio. Dalam hal ini, framework parameter memuat struktur dan setelan dari file XML.

Gambar 2. Informasi CAP dimuat dalam layanan kebijakan audio.

File struktur CAP di Android 15 dan yang lebih rendah

Untuk mendapatkan struktur dan setelan, layanan kebijakan audio membaca file ParameterFrameworkConfigurationPolicy.xml. Ini mereferensikan informasi struktur melalui lokasi file deskripsi struktur:

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

Ini mengarah ke informasi struktur dalam file:

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

Struktur kerangka disediakan di Android . Informasi struktur memerlukan informasi struktur strategi produk, sehingga Android menyediakan buildStrategiesStructureFile.py alat pembuatan, yang dapat membuat informasi dari file XML strategi produk yang tersedia. Hal ini dapat direferensikan melalui default genrule buildstrategiesstructurerule sebagai berikut:

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

Dengan audio_policy_engine_configuration_files adalah file konfigurasi mesin kebijakan audio. Contoh untuk otomotif ini mereferensikan file konfigurasi kebijakan audio di folder otomotif. Contoh lain menunjukkan cara mengonfigurasi build untuk mengirim file di partisi vendor perangkat.

File setelan CAP di Android 15 dan yang lebih rendah

Mirip dengan struktur, informasi setelan, yang merepresentasikan aturan dan nilai parameter, dirujuk dalam file ParameterFrameworkConfigurationPolicy.xml sebagai:

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

Android juga menyediakan alat build untuk membuat informasi ini menggunakan konfigurasi mesin kebijakan audio dan file framework parameter. Lihat Konfigurasi untuk mengetahui informasi selengkapnya.

Inisialisasi CAP HAL audio AIDL

Mulai Android 16, definisi AIDL Audio HAL API diperluas dengan konfigurasi mesin kebijakan audio, AudioHalCapConfiguration.aidl. Gambar berikut menunjukkan ringkasan tingkat tinggi pengelolaan konfigurasi mesin CAP per Android 16:

Gambar 3. Pengelolaan konfigurasi mesin CAP mulai dari Android 16.

Layanan kebijakan audio mendapatkan info mesin CAP menggunakan AIDL Audio HAL API secara langsung, bukan mengurai informasi dari file XML di partisi vendor perangkat.

Dalam konfigurasi ini, struktur framework parameter masih dimuat oleh mesin CAP di sisi server audio.

Gambar 4. Struktur mesin CAP.

Dalam semua kasus, konfigurasi harus sepenuhnya menentukan informasi yang berkaitan dengan strategi produk, grup volume, dan kriteria.

Gambar berikut menunjukkan ringkasan tingkat tinggi dari API HAL audio AIDL yang digunakan oleh layanan kebijakan audio untuk mendapatkan konfigurasi mesin CAP:

Gambar 5. API HAL audio AIDL.

Dalam penyiapan ini, layanan kebijakan audio mendapatkan informasi berikut dari HAL audio AIDL:

• Konfigurasi
• Strategi
• Volume
• Kriteria
• Setelan

Pemuat HAL Audio AIDL default

Untuk mempermudah transisi dari HIDL ke AIDL, HAL Audio AIDL audio default menyediakan pemuat mesin CAP XML. Vendor dapat menggunakan loader ini secara langsung dengan memperluas HAL audio mereka dengan HAL audio default atau mereferensikan library libaudioserviceexampleimpl.

Loader HAL audio AIDL default menggunakan audio_policy_engine_configuration.xml untuk mendapatkan informasi berikut:

• Konfigurasi
• Strategi
• Volume
• Kriteria

Informasi struktur diperoleh dari file PolicyConfigurableDomains.xml. Perbedaan utama dari mekanisme sebelumnya adalah informasi struktur juga diperoleh oleh HAL audio AIDL, bukan framework parameter di layanan kebijakan audio.

Vendor dapat menggunakan alat domaingeneratorpolicyrule untuk membuat domain yang dapat dikonfigurasi menggunakan informasi dari konfigurasi mesin kebijakan audio. Contoh perangkat virtual Cuttlefish otomotif dapat digunakan sebagai referensi.

Struktur dalam konfigurasi AIDL

Di Android 16 dan yang lebih tinggi, layanan kebijakan audio mendapatkan informasi struktur dengan membaca dan mengurai ParameterFrameworkConfigurationCap.xml[file](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). Secara khusus, informasi ini diperoleh dari file deskripsi struktur:

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

Framework akan melepaskan file yang diperlukan ke folder /etc/parameter-framework/ dengan informasi yang diperlukan.

Struktur ini merepresentasikan parameter yang harus dikontrol, sehingga parameter tersebut harus dirujuk dalam konfigurasi atau domain. Untuk itu, konfigurasi mesin AIDL harus menggunakan nama yang telah ditentukan sebelumnya untuk parameter. Untuk strategi produk, struktur dikonfigurasi di CapProductStrategies.xml.

Strategi produk default

Dimulai dengan nilai default yang disediakan di default engine, strategi produk dimulai dengan awalan STRATEGY_:

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Format ini disediakan untuk mempermudah transisi dari HIDL ke AIDL bagi perangkat yang menggunakan strategi default. Perubahan format ini memiliki beberapa implikasi untuk file yang ada (misalnya, PfW, XML) yang digunakan untuk mengonfigurasi mesin. Khususnya, semua referensi strategi produk harus diubah untuk menggunakan nama baru, misalnya:

Strategi produk yang ditentukan OEM

Mesin yang dapat dikonfigurasi memungkinkan OEM mengubah definisi strategi produk. Untuk terus mendukung hal ini, file strategi produk CapProductStrategies.xml juga menyediakan 40 strategi produk yang dapat diperluas vendor dari vx_1000 hingga vx_1039 . Semua ekstensi vendor harus dimulai dengan awalan vx_ dan diikuti dengan angka yang merepresentasikan ID strategi produk dalam definisi strategi produk HAL audio AIDL. Definisi lainnya (misalnya, grup atribut audio, nama) diperoleh dari objek AudioHALProductStrategy dalam konfigurasi mesin HAL audio.

Mirip dengan strategi produk default, referensi OEM yang ditentukan vendor juga harus disesuaikan antara konfigurasi non-AIDL dan konfigurasi AIDL, misalnya:

Strategi produk

Strategi produk memberikan cara untuk menyesuaikan pengelompokan dan pengategorian streaming audio. Hal ini memungkinkan fleksibilitas yang lebih besar dalam mengonfigurasi perangkat audio, termasuk cara peruteannya dan cara pengelolaan volumenya. Setiap strategi produk dapat memiliki satu atau beberapa grup atribut audio, yang mengidentifikasi streaming yang harus dikaitkan dengan strategi produk tersebut. Grup atribut audio ini memungkinkan pendekatan yang lebih terperinci untuk mengategorikan audio dan dapat berupa campuran dari jenis berikut:

• Jenis penggunaan menjelaskan alasan suara diputar (yaitu, media, notifikasi, panggilan).
• Jenis Jenis konten menjelaskan apa yang sedang diputar (yaitu, musik, ucapan, video, sonifikasi).
• Jenis flag menentukan perilaku atau permintaan yang berbeda terkait dengan aliran.
• Jenis Tag mendukung daftar nilai string vendor arbitrer.
  • Setiap string harus diawali dengan VX_ yang diikuti dengan string alfanumerik (misalnya, 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>

Kutipan ini menunjukkan contoh strategi produk yang digunakan dalam emulator mobil. Contoh ini berisi dua atribut audio dengan media penggunaan audio dan game. Strategi produk ini cocok dengan konteks audio MUSIC yang digunakan dalam layanan audio mobil, tetapi tidak ada persyaratan untuk kecocokan tersebut. Salah satu utilitas utama bagi OEM yang menggunakan CAP bersama dengan Android adalah untuk memungkinkan definisi pengelompokan audio yang lebih fleksibel.

Grup volume

Selain itu, setiap grup atribut audio harus memiliki grup volume terkait. Grup volume ini dikaitkan dengan stream apa pun yang cocok dengan atribut audio yang termasuk dalam grup atribut audio. Contoh strategi produk musik di bagian Strategi produk memiliki grup volume media, dan definisi grup volume media adalah sebagai berikut:

<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>

Dalam definisi ini, grup volume berisi:

• Nama grup
• Indeks minimum grup
• Indeks maksimum grup
• Kurva grup volume

Kurva grup volume berisi pemetaan pointwise antara indeks grup volume dan peningkatan volume dalam milibel. Titik yang diberikan digunakan untuk menginterpolasi secara linear perolehan yang paling cocok saat volume dikelola. Setiap kurva grup volume dikaitkan dengan kategori jenis perangkat (misalnya, headset, speaker, media eksternal).

Grup volume mengelola volume untuk aliran yang merupakan bagian dari grup atribut audio. Misalnya, saat streaming dengan atribut audio yang berisi musik atau game dimulai, indeks volume yang terakhir ditetapkan untuk grup volume media akan digunakan. Dalam hal ini, kurva kategori perangkat yang sesuai dipilih berdasarkan perangkat yang dipilih dan gain yang sesuai ditetapkan saat streaming dimulai.

Konfigurasi

Di mesin CAP, konfigurasi digunakan untuk menentukan kondisi atau aturan yang menentukan perilaku audio. Konfigurasi ini dievaluasi saat runtime untuk memilih aturan yang sesuai untuk diterapkan, bergantung pada status sistem audio saat ini.

Seperti yang ditunjukkan pada gambar 5, API berisi beberapa domain, yang masing-masing domainnya bertujuan untuk membagi logika menjadi masalah perutean yang lebih kecil untuk dipecahkan (misalnya, perangkat 1, perangkat 2).

Setiap domain memiliki konfigurasi, dan setiap konfigurasi memiliki serangkaian aturan. Aturan dibuat berdasarkan kriteria yang diberikan oleh AudioPolicyManager:

• Mode audio
• Perangkat input dan output yang tersedia
• Alamat perangkat input dan output yang tersedia
• Gunakan untuk
  • Media
  • Komunikasi
  • Merekam
  • Dok
  • Sistem
  • Audio sistem HDMI
  • Surround yang dienkode
  • Getar saat berdering

Setiap domain berisi konfigurasi yang menentukan aturan yang akan memengaruhi perilaku. Perhatikan bahwa urutan konfigurasi penting dan Anda harus memastikan konfigurasi berada dalam urutan yang diperlukan. Setelah aturan untuk konfigurasi divalidasi, konfigurasi akan dipilih.

Kode berikut menunjukkan contoh kutipan file framework parameter, yang dapat digunakan untuk membuat file XML yang diperlukan untuk mengonfigurasi domain yang dapat dikonfigurasi:

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

Domain DeviceForProductStrategies menentukan cara penerapan berbagai aturan saat menangani pemilihan perangkat strategi produk. Bagian biru menjelaskan aturan yang harus dipertimbangkan dan bagian hijau adalah konfigurasi yang diterapkan. Contoh khusus ini berisi konfigurasi berikut:

• Pilih perangkat A2DP Bluetooth untuk strategi produk musik (ID 1000, vx_1000)
  • Jika digunakan untuk media, tidak mengecualikan A2DP
  • Jika digunakan untuk komunikasi, bukan BT SCO
  • Jika perangkat yang tersedia mencakup BT A2DP
• Pilih perangkat bus
  • Jika perangkat bus tersedia
  • Jika alamatnya adalah BUS00_MEDIA
• Pilih perangkat output default

Untuk membuat file XML mesin kebijakan yang dapat dikonfigurasi yang sesuai, jalankan file parameter-framework (PFW) melalui sistem build, dengan menentukan aturan build menggunakan langkah-langkah berikut:

1. Di file Android.bp, buat grup file untuk file:

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

2. Tambahkan file ke file PfW lainnya (jika ada).

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

3. Buat aturan pembuatan domain yang sesuai:

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

   Dengan domaingeneratorpolicyrule adalah aturan pembuatan yang disediakan oleh framework untuk membuat file PolicyConfigurableDomains.xml. File sumber lainnya (scrs) yang disertakan dalam aturan pembuatan domain adalah sebagai berikut:

   Sumber	Deskripsi
   audio_policy_pfw_toplevel	File konfigurasi framework parameter tingkat teratas.
   audio_policy_pfw_structure_files	File struktur pembuatan domain, yang digunakan untuk membuat file konfigurasi.
   audio_policy_engine_criterion_types	File XML jenis kriteria, yang menjelaskan kriteria yang digunakan selama pembuatan.
   edd_files	Daftar file domain tunggal (masing-masing berisi satu tag <ConfigurableDomain>).

Setelah menjalankan aturan pembuatan di build, PolicyConfigurableDomains.xml akan dibuat dengan semua domain. Berikut adalah kutipan dari file yang dihasilkan menggunakan contoh aturan 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>

Proses debug CAP

Anda dapat menggunakan remote-process untuk mengekspor konfigurasi CAP:

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

Tindakan ini akan menampilkan semua domain dan konfigurasi, termasuk kondisi penerapan. Berikut ini menunjukkan kutipan dari perangkat otomotif Cuttlefish menggunakan Bluetooth A2DP, perangkat bus, dan konfigurasi default. Lihat Konfigurasi:

- 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

Untuk mengetahui informasi lebih lanjut tentang perintah lain yang tersedia untuk men-debug framework parameter CAP, gunakan alat ini:

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

Untuk menggunakan alat ini, produsen OEM harus mengizinkan penyetelan di perangkat. Untuk memverifikasi apakah perangkat mengizinkan penyetelan, gunakan perintah berikut:

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

Di Android 15 dan yang lebih lama, file mungkin berbeda, jadi gunakan perintah berikut:

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

File harus berisi TuningAllowed="true" beserta port server yang sesuai:

<?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>

File ini dibuat secara otomatis sesuai dengan jenis image build (atau gunakan file yang berbeda untuk rilis atau debug untuk build lama). Build rilis menyetel TuningAllowed ke false tanpa port soket (soket dilarang untuk build rilis ini). Build Engineering dan userdebug menetapkannya ke true dengan port soket yang digunakan. Perhatikan bahwa ini adalah file yang dirujuk oleh audio_policy_pfw_toplevel. Alat remote-process juga harus disertakan dalam file build atau pembuatan perangkat:

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

Kebijakan SELinux yang sesuai untuk mengizinkan soket juga harus disertakan. Ini hanya berfungsi untuk mode debug karena mode rilis secara eksplisit tidak mengizinkan soket:

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

Migrasi CAP di Android 16

Mengingat perubahan besar yang dibawa oleh mesin CAP HAL audio AIDL dan versi sebelumnya, ada berbagai skenario transisi perangkat yang harus Anda pertimbangkan. Bagian ini mencakup skenario transisi yang paling penting dan memberikan rekomendasi untuk pekerjaan yang memungkinkan konfigurasi mesin CAP.

Skenario 1: Perangkat baru yang menggunakan Android 16 atau yang lebih tinggi, tidak ada sumber sebelumnya untuk konfigurasi CAP perangkat

Perangkat baru harus diluncurkan dengan kode Android 16 atau yang lebih tinggi di partisi vendor. Artinya, konfigurasi mesin kebijakan audio yang dapat dikonfigurasi harus diekspos melalui antarmuka HAL audio AIDL. Konfigurasi mesin CAP Device harus disalin dari contoh. Tidak boleh ada definisi domain CAP PfW di partisi vendor.

Image sistem yang digunakan untuk perangkat adalah Android 16 atau yang lebih tinggi. Framework layanan audio menemukan konfigurasi CAP melalui antarmuka HAL audio AIDL, sehingga menginisialisasi PfW menggunakan definisi domain CAP PfW dari image sistem dan memuat konfigurasi CAP perangkat yang diterima melalui AIDL.

Untuk contoh, lihat perangkat virtual Cuttlefish otomotif, yang diperkenalkan dalam perubahan ini dan dapat dirujuk untuk file yang diperlukan, aturan build, dan file make yang diperlukan untuk menyiapkan file konfigurasi yang diperlukan. Hal ini berfungsi dengan pemuat yang disediakan di HAL audio AIDL default.

Skenario 2: Perangkat baru menggunakan Android 16 atau yang lebih tinggi, dari perangkat sebelumnya yang menggunakan CAP

Perangkat baru harus diluncurkan dengan kode Android 16 atau yang lebih tinggi di partisi vendor. Namun, karena OEM memiliki konfigurasi mesin CAP perangkat yang dapat digunakan, OEM akan ingin menggunakannya sebagai titik awal (atau menggunakannya kembali sepenuhnya). Konfigurasi CAP versi AIDL memiliki beberapa perubahan dibandingkan dengan versi Android 15 dan yang lebih rendah, sehingga vendor harus mengonversi konfigurasi yang ada ke AIDL. Lihat diskusi di Strategi produk untuk mengetahui perubahan antara Android 16 dan versi yang lebih rendah untuk perubahan yang diperlukan. Secara umum, framework audio menemukan dan memuat konfigurasi CAP dengan cara yang sama seperti pada Skenario 1.

Skenario 3: Perangkat lama dengan CAP yang diupdate ke Android 16 hanya pada partisi sistem

Dalam skenario ini, partisi vendor berisi konfigurasi CAP perangkat versi Android 15 dan yang lebih rendah, serta definisi domain CAP PfW. Partisi vendor tidak berubah, sehingga masih menggunakan HIDL HAL. Framework mengikuti skenario Android 15 dan yang lebih rendah serta memuat semua konfigurasi terkait CAP dari partisi vendor.

Skenario 4: Perangkat lama dirilis di Android 15, dengan CAP

CAP tidak didukung di AIDL pada Android 15, sehingga beberapa vendor merilis perangkat baru dengan AIDL Audio HAL dan CAP, yang dimuat oleh framework audio. Mode hybrid ini tidak resmi, tetapi disertakan dalam Android 16. Perhatikan bahwa mode ini tidak boleh digunakan untuk merilis perangkat baru di Android 16, tetapi untuk memungkinkan perangkat yang ada dengan vendor Android 15 diupdate ke Android 16 (update partisi system).

Framework audio menemukan konfigurasi audio HAL AIDL tanpa konfigurasi CAP. Untuk konfigurasi CAP, layanan kebijakan audio (framework audio) akan memuat konfigurasi CAP dari partisi vendor. Dalam hal ini, definisi domain CAP PfW dan konfigurasi CAP perangkat harus dimuat dari partisi vendor.

Ringkasan migrasi CAP

Tabel berikut merangkum konfigurasi dan persyaratan sistem dan vendor yang kompatibel untuk konfigurasi CAP: