Mesin kebijakan audio yang dapat dikonfigurasi

Di Android 14, Android Automotive Operating System (AAOS) memanfaatkan pengelolaan audio mobil mesin kebijakan audio yang dapat dikonfigurasi (CAP) dalam zona audio utama. Secara khusus, mesin CAP memungkinkan AAOS hanya mengontrol 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 akan menggunakan API pengelola audio untuk mengelola grup volume.

• Gunakan tanda useCoreAudioRouting untuk mengaktifkan pengelolaan pemilihan rute audio CAP. Jika nilai ini adalah true, layanan audio mobil akan 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 beserta tabel volume

Inisialisasi CAP sebelum Android 16

Gambar berikut menunjukkan ringkasan umum pengelolaan konfigurasi mesin kebijakan audio yang dapat dikonfigurasi mulai Android 6:

Gambar 1. Pengelolaan konfigurasi mesin CAP mulai Android 6.

Seperti yang ditunjukkan pada gambar, konfigurasi mesin CAP diperoleh oleh layanan kebijakan audio dengan mengurai informasi dari file audio_policy_engine_configuration.xml di partisi vendor. File konfigurasi mesin CAP menggunakan skema yang ditentukan di 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 yang dimuat dalam layanan kebijakan audio.

File struktur CAP di Android 15 dan yang lebih lama

Untuk mendapatkan struktur dan setelan, layanan kebijakan audio akan 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 alat pembuatan buildStrategiesStructureFile.py, yang dapat menghasilkan informasi dari file XML strategi produk yang tersedia. 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 lainnya menunjukkan cara mengonfigurasi build untuk mengirim file di partisi vendor perangkat.

File setelan CAP di Android 15 dan yang lebih lama

Serupa dengan struktur, informasi setelan, yang mewakili aturan dan nilai parameter, direferensikan dalam file ParameterFrameworkConfigurationPolicy.xml sebagai:

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

Android juga menyediakan alat build untuk menghasilkan 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 umum pengelolaan konfigurasi mesin CAP mulai Android 16:

Gambar 3. Pengelolaan konfigurasi mesin CAP mulai 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 umum 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

Loader HAL Audio AIDL default

Untuk memperlancar transisi dari HIDL ke AIDL, HAL Audio AIDL audio default menyediakan loader 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 utamanya 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 baru, layanan kebijakan audio mendapatkan informasi struktur dengan membaca dan mengurai file ParameterFrameworkConfigurationCap.xml. Secara khusus, file ini mendapatkan informasi dari file deskripsi struktur:

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

Framework ini menempatkan file yang diperlukan ke folder /etc/parameter-framework/ dengan informasi yang diperlukan.

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

Strategi produk default

Dimulai dengan default yang disediakan di mesin default, 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 meringankan transisi dari HIDL ke AIDL untuk perangkat yang menggunakan strategi default. Perubahan format ini memiliki beberapa implikasi untuk file yang ada (misalnya, PfW, XML) yang digunakan untuk mengonfigurasi mesin. Secara khusus, semua referensi strategi produk harus diubah untuk menggunakan nama baru, misalnya contoh:

Strategi produk yang ditentukan OEM

Mesin yang dapat dikonfigurasi memberikan kemampuan bagi OEM untuk 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 ke vx_1039 . Semua ekstensi vendor harus dimulai dengan awalan vx_ dan diikuti dengan angka yang mewakili 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.

Serupa 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 cara streaming audio dikategorikan dan dikelompokkan. Hal ini memungkinkan fleksibilitas yang lebih besar dalam mengonfigurasi perangkat audio termasuk cara perangkat dirutekan dan cara volumenya dikelola. 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 sehubungan dengan streaming.
• Jenis Tag mendukung daftar nilai string vendor arbitrer.
  • Setiap string harus diawali dengan VX_, 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>

Cuplikan ini menunjukkan contoh strategi produk yang digunakan di emulator mobil. File ini berisi dua atribut audio dengan media penggunaan audio dan game. Strategi produk ini cocok dengan konteks audio MUSIC yang digunakan di layanan audio mobil, tetapi tidak ada persyaratan untuk pencocokan tersebut. Salah satu utilitas utama untuk 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 titik per titik antara indeks grup volume dan gain volume dalam mB. Titik yang diberikan digunakan untuk melakukan interpolasi linear pada gain pencocokan terbaik saat volume dikelola. Setiap kurva grup volume dikaitkan dengan kategori jenis perangkat (misalnya, headset, speaker, media eksternal).

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

Konfigurasi

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

Seperti yang ditunjukkan pada gambar 5, API berisi beberapa domain, tujuan setiap domain adalah membagi logika menjadi masalah pemilihan rute yang lebih kecil untuk dipecahkan (misalnya, perangkat 1, perangkat 2).

Setiap domain memiliki konfigurasi, dan setiap konfigurasi memiliki kumpulan aturan. Aturan ditetapkan berdasarkan kriteria yang disediakan 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 berdering

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

Kode berikut menunjukkan contoh cuplikan 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:

• Memilih 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 tersedia, sertakan BT A2DP
• Pilih perangkat bus
  • Jika perangkat bus tersedia
  • Jika alamatnya adalah BUS00_MEDIA
• Pilih perangkat output default jika tidak

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. Dalam 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 dalam build, PolicyConfigurableDomains.xml akan dibuat dengan semua domain. Berikut adalah kutipan dari file yang dihasilkan menggunakan contoh PfW aturan:

---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 membuang 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 adalah cuplikan dari perangkat otomotif Cuttlefish yang menggunakan konfigurasi default, perangkat bus, dan Bluetooth A2DP. 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 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 penyesuaian di perangkat. Untuk memverifikasi apakah perangkat mengizinkan penyesuaian, 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 lain untuk rilis atau debug untuk build lama). Build rilis menetapkan TuningAllowed ke false tanpa port soket (soket dilarang untuk hal ini dalam build rilis). 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 proses jarak jauh 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 HAL CAP audio AIDL dan versi sebelumnya, ada berbagai skenario transisi perangkat yang harus Anda pertimbangkan. Bagian ini membahas skenario transisi yang paling penting dan memberikan rekomendasi untuk pekerjaan guna mengaktifkan konfigurasi mesin CAP.

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

Perangkat baru harus diluncurkan dengan kode Android 16 atau yang lebih tinggi di partisi vendor. Artinya, aplikasi ini harus mengekspos konfigurasi mesin kebijakan audio yang dapat dikonfigurasi melalui antarmuka HAL audio AIDL. Konfigurasi mesin CAP perangkat harus disalin dari contoh. Tidak boleh ada definisi domain PfW CAP 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.

Sebagai contoh, lihat perangkat virtual Cuttlefish otomotif, yang diperkenalkan dalam perubahan ini dan dapat direferensikan untuk file yang diperlukan, aturan build, dan membuat file yang diperlukan untuk menyiapkan file konfigurasi yang diperlukan. Hal ini berfungsi dengan loader yang disediakan di HAL audio AIDL default.

Skenario 2: Perangkat baru menggunakan Android 16 atau yang lebih baru, 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 ingin menggunakannya sebagai titik awal (atau menggunakannya kembali sepenuhnya). Versi AIDL dari konfigurasi CAP memiliki beberapa perubahan dibandingkan dengan Android 15 dan versi 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 lama untuk mengetahui perubahan yang diperlukan. Secara umum, framework audio menemukan dan memuat konfigurasi CAP dengan cara yang sama seperti dalam Skenario 1.

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

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

Skenario 4: Perangkat lama yang 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 campuran 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 audio AIDL tanpa konfigurasi CAP. Untuk konfigurasi CAP, layanan kebijakan audio (framework audio) kembali 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 dengan konfigurasi CAP: