เครื่องมือนโยบายเสียงที่กำหนดค่าได้

ใน Android 14 ระบบปฏิบัติการ Android Automotive (AAOS) จะใช้ประโยชน์จากเครื่องมือ นโยบายเสียงที่กำหนดค่าได้ (CAP) ในการจัดการเสียงของรถยนต์ภายใน โซนเสียงหลัก โดยเฉพาะอย่างยิ่ง เครื่องมือ CAP จะอนุญาตให้ AAOS ควบคุมเฉพาะการกำหนดเส้นทางเสียง เฉพาะระดับเสียง หรือทั้งการกำหนดเส้นทางและระดับเสียงพร้อมกัน คุณใช้แฟล็กต่อไปนี้เพื่อควบคุมลักษณะการทำงานได้

  • ใช้useCoreAudioVolumeเพื่อเปิดใช้การจัดการปริมาณ CAP เมื่อค่านี้เป็น true บริการเสียงในรถจะใช้ Audio Manager API เพื่อจัดการกลุ่มระดับเสียง

  • ใช้useCoreAudioRoutingเพื่อเปิดใช้การจัดการการกำหนดเส้นทางเสียง CAP เมื่อค่านี้เป็น true บริการเสียงในรถยนต์จะใช้การกำหนดเส้นทางนโยบายเสียงที่กำหนดค่าได้เพื่อจัดการการกำหนดเส้นทางเสียง

นอกจากนี้ Android ยังรองรับเครื่องมือนโยบายเสียงโดยค่าเริ่มต้นในรูปแบบของเครื่องมือนโยบายเสียงเริ่มต้น

ฉากหลัง

เครื่องมือ CAP อิงตามเฟรมเวิร์กพารามิเตอร์ของ Intel ซึ่งเป็นเฟรมเวิร์กแบบปลั๊กอินและแบบอิงตามกฎสำหรับการจัดการพารามิเตอร์ สำหรับระบบจัดการเสียงของ Android โดยเฉพาะ เครื่องมือ CAP ได้เปิดตัวความสามารถในการกำหนดกฎไฟล์ XML เพื่อระบุสิ่งต่อไปนี้

  • กลยุทธ์ผลิตภัณฑ์เสียง
  • กฎสำหรับการเลือกอุปกรณ์เอาต์พุตเสียง
  • กฎสำหรับการเลือกอุปกรณ์อินพุตเสียง
  • กฎในการจัดการระดับเสียงและการปิดเสียงพร้อมกับตารางระดับเสียง

การเริ่มต้น CAP ก่อน Android 16

รูปภาพต่อไปนี้แสดงภาพรวมระดับสูงของการจัดการการกำหนดค่าเครื่องมือเสียง ที่กำหนดค่าได้ตามนโยบายใน Android 6

สถาปัตยกรรมเครื่องมือ CAP ก่อน Android 16

รูปที่ 1 การจัดการการกำหนดค่าเครื่องมือ CAP ตั้งแต่ Android 6

ดังที่แสดงในรูป การกำหนดค่าเครื่องมือ CAP จะ ได้จากบริการนโยบายเสียง โดยการแยกวิเคราะห์ข้อมูลจากaudio_policy_engine_configuration.xml ไฟล์ ในพาร์ติชัน vendor ไฟล์การกำหนดค่าเครื่องมือ CAP ใช้สคีมาที่กำหนดไว้ใน audio_policy_engine_configuration.xsd เพื่อรับข้อมูลที่จำเป็น audio_policy_engine_configuration.xml เป็นตัวอย่างสำหรับยานยนต์ ตัวอย่างที่คล้ายกันสำหรับรูปแบบอื่นๆ อยู่ในโฟลเดอร์ frameworks/av/services/audiopolicy/engineconfigurable/config/example/

รูปที่ต่อไปนี้แสดงข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับวิธีโหลดข้อมูลเครื่องมือนโยบายเสียงที่กำหนดค่าได้ภายในบริการนโยบายเสียง ในกรณีนี้ เฟรมเวิร์กพารามิเตอร์จะโหลดโครงสร้างและการตั้งค่าจากไฟล์ XML

เส้นทางการโหลดเครื่องมือ CAP ก่อน Android 16

รูปที่ 2 ข้อมูล CAP ที่โหลดภายในบริการนโยบายเสียง

ไฟล์โครงสร้าง CAP ใน Android 15 และต่ำกว่า

บริการนโยบายเสียง จะอ่านไฟล์ ParameterFrameworkConfigurationPolicy.xml เพื่อรับโครงสร้างและการตั้งค่า ซึ่งอ้างอิงถึง ข้อมูลโครงสร้างผ่านตำแหน่งไฟล์คำอธิบายโครงสร้าง

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

ซึ่งจะชี้ไปยังข้อมูลโครงสร้างในไฟล์

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

โครงสร้างโครงร่างมีให้ใช้งานใน Android ข้อมูลโครงสร้างต้องมีข้อมูลโครงสร้างกลยุทธ์ผลิตภัณฑ์ ดังนั้น Android จึงมีbuildStrategiesStructureFile.py เครื่องมือสร้าง ซึ่งสร้างข้อมูลจากไฟล์ XML กลยุทธ์ผลิตภัณฑ์ที่มีอยู่ได้ ซึ่งอ้างอิงได้ผ่าน ค่าเริ่มต้นของ genrule buildstrategiesstructurerule ดังนี้

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

โดย audio_policy_engine_configuration_files คือไฟล์การกำหนดค่าของเครื่องมือจัดการนโยบายเสียง ตัวอย่างสำหรับยานยนต์ นี้อ้างอิงไฟล์การกำหนดค่านโยบายเสียงใน โฟลเดอร์ยานยนต์ ตัวอย่างอื่นๆ แสดงวิธีกำหนดค่าบิลด์เพื่อพุชไฟล์ในพาร์ติชันของผู้ให้บริการของอุปกรณ์

ไฟล์การตั้งค่า CAP ใน Android 15 และต่ำกว่า

เช่นเดียวกับโครงสร้าง ข้อมูลการตั้งค่าซึ่งแสดงถึงกฎและค่าของพารามิเตอร์จะอ้างอิงในไฟล์ ParameterFrameworkConfigurationPolicy.xml ดังนี้

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

นอกจากนี้ Android ยังมีเครื่องมือบิลด์เพื่อสร้างข้อมูลนี้โดยใช้การกำหนดค่าเครื่องมือเสียง และไฟล์เฟรมเวิร์กพารามิเตอร์ ดูข้อมูลเพิ่มเติมได้ที่ การกำหนดค่า

การเริ่มต้น CAP ของ HAL เสียง AIDL

ตั้งแต่ Android 16 เป็นต้นไป คำจำกัดความของ AIDL Audio HAL API จะขยายออกไปพร้อมกับการกำหนดค่าเครื่องมือนโยบายเสียง AudioHalCapConfiguration.aidl รูปภาพต่อไปนี้แสดงภาพรวมระดับสูงของการจัดการการกำหนดค่าเครื่องมือ CAP ณ Android 16

สถาปัตยกรรม AIDL ของเครื่องมือ CAP

รูปที่ 3 การจัดการการกำหนดค่าเครื่องมือ CAP ตั้งแต่ Android 16 เป็นต้นไป

บริการนโยบายเสียงจะรับข้อมูลเครื่องมือ CAP โดยใช้ AIDL Audio HAL APIs โดยตรงแทนที่จะแยกวิเคราะห์ข้อมูลจากไฟล์ XML ในพาร์ติชันของผู้ให้บริการของอุปกรณ์

ในการกำหนดค่านี้ เครื่องมือ CAP จะยังคงโหลดโครงสร้างของเฟรมเวิร์กพารามิเตอร์ ที่ฝั่งเซิร์ฟเวอร์เสียง

เส้นทางการโหลด AIDL ของเครื่องมือ CAP

รูปที่ 4 โครงสร้างเครื่องมือ CAP

ในทุกกรณี การกำหนดค่าต้องระบุข้อมูลที่เกี่ยวข้องกับกลยุทธ์ผลิตภัณฑ์ กลุ่มปริมาณ และเกณฑ์อย่างครบถ้วน

รูปที่ 1 แสดงภาพรวมระดับสูงของ API ของ HAL เสียง AIDL ที่ ใช้โดยบริการนโยบายเสียงเพื่อรับการกำหนดค่าเครื่องมือ CAP

API ของ AIDL ของเครื่องมือ CAP รูปที่ 5 API ของ AIDL Audio HAL

ในการตั้งค่านี้ บริการนโยบายเสียงจะได้รับข้อมูลต่อไปนี้จาก HAL เสียง AIDL

  • การกำหนดค่า
  • กลยุทธ์
  • ชุด
  • เกณฑ์
  • การตั้งค่า

โปรแกรมโหลด HAL เสียง AIDL เริ่มต้น

Audio HAL ของ AIDL สำหรับเสียงเริ่มต้น มีโปรแกรมโหลดเครื่องมือ CAP ในรูปแบบ XML เพื่อให้การเปลี่ยนจาก HIDL ไปเป็น AIDL เป็นไปอย่างราบรื่น ผู้ให้บริการสามารถใช้โปรแกรมโหลดนี้ได้โดยตรงด้วยการขยาย HAL เสียงด้วย HAL เสียงเริ่มต้นหรืออ้างอิงไลบรารี libaudioserviceexampleimpl

โปรแกรมโหลด HAL เสียง AIDL เริ่มต้น ใช้ audio_policy_engine_configuration.xml เพื่อรับข้อมูลต่อไปนี้

  • การกำหนดค่า
  • กลยุทธ์
  • ชุด
  • เกณฑ์

ระบบจะดึงข้อมูลโครงสร้างจากไฟล์ PolicyConfigurableDomains.xml ความแตกต่างที่สำคัญจากกลไกก่อนหน้าคือ AIDL audio HAL จะเป็นผู้รับข้อมูลโครงสร้าง แทนเฟรมเวิร์กพารามิเตอร์ ที่บริการนโยบายเสียง

ผู้ให้บริการสามารถใช้เครื่องมือ domaingeneratorpolicyrule เพื่อสร้างโดเมนที่กำหนดค่าได้โดยใช้ข้อมูลจากการกำหนดค่าเครื่องมือตรวจสอบนโยบายเสียง คุณสามารถใช้ตัวอย่างอุปกรณ์เสมือน Cuttlefish สำหรับยานยนต์ เป็นข้อมูลอ้างอิงได้

โครงสร้างในการกำหนดค่า AIDL

ใน Android 16 ขึ้นไป บริการนโยบายเสียง จะรับข้อมูลโครงสร้างโดยการอ่านและแยกวิเคราะห์ ParameterFrameworkConfigurationCap.xml [ไฟล์](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

) โดยเฉพาะอย่างยิ่งจะได้รับข้อมูลจากไฟล์คำอธิบายโครงสร้าง

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

เฟรมเวิร์กจะวางไฟล์ที่จำเป็นลงใน/etc/parameter-framework/ โฟลเดอร์ที่มีข้อมูลที่จำเป็น

โครงสร้างแสดงถึงพารามิเตอร์ที่ควรควบคุม ดังนั้นจึงควรมีการอ้างอิงในค่ากำหนดหรือโดเมน โดยเครื่องมือ AIDL config ควรใช้ชื่อที่กำหนดไว้ล่วงหน้าสำหรับพารามิเตอร์ สำหรับกลยุทธ์ผลิตภัณฑ์ จะมีการกำหนดค่าโครงสร้างใน CapProductStrategies.xml

กลยุทธ์ผลิตภัณฑ์เริ่มต้น

เริ่มต้นด้วยค่าเริ่มต้นที่ระบุไว้ในเครื่องมือเริ่มต้น กลยุทธ์ผลิตภัณฑ์จะเริ่มต้นด้วยคำนำหน้า STRATEGY_

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

เราจัดรูปแบบนี้ไว้เพื่อช่วยให้การเปลี่ยนจาก HIDL เป็น AIDL สำหรับ อุปกรณ์ที่ใช้กลยุทธ์เริ่มต้นเป็นไปอย่างราบรื่น การเปลี่ยนแปลงรูปแบบนี้มีผลกับไฟล์ที่มีอยู่ (เช่น PfW, XML) ที่ใช้ในการกำหนดค่าเครื่องมือค้นหา โดยเฉพาะอย่างยิ่ง การอ้างอิงกลยุทธ์ผลิตภัณฑ์ทั้งหมดควร เปลี่ยนไปใช้ชื่อใหม่ เช่น

ชื่อพารามิเตอร์การกำหนดค่าที่ไม่ใช่ AIDL
/Policy/policy/product_strategies/media/device_address
/Policy/policy/product_strategies/media/selected_output_devices/mask
ชื่อพารามิเตอร์การกำหนดค่า AIDL
/Policy/policy/product_strategies/STRATEGY_MEDIA/device_address
/Policy/policy/product_strategies/STRATEGY_MEDIA/selected_output_devices/mask
กลยุทธ์ผลิตภัณฑ์ที่ OEM กำหนด

เครื่องมือที่กำหนดค่าได้ช่วยให้ OEM เปลี่ยนคำจำกัดความของกลยุทธ์ผลิตภัณฑ์ได้ ไฟล์กลยุทธ์ผลิตภัณฑ์ CapProductStrategies.xml ยังมีกลยุทธ์ผลิตภัณฑ์ที่ขยายได้ของผู้ให้บริการ 40 รายจาก vx_1000 ถึง vx_1039 เพื่อรองรับการดำเนินการนี้ต่อไป ส่วนขยายของผู้ให้บริการทั้งหมดต้องขึ้นต้นด้วยคำนำหน้า vx_ และตามด้วยหมายเลขที่แสดงรหัสกลยุทธ์ผลิตภัณฑ์ ในคำจำกัดความกลยุทธ์ผลิตภัณฑ์ HAL ของเสียง AIDL ส่วนคำจำกัดความที่เหลือ (เช่น กลุ่มแอตทริบิวต์เสียง ชื่อ) จะได้จากออบเจ็กต์ AudioHALProductStrategy ใน การกำหนดค่าเครื่องมือเสียง HAL

เช่นเดียวกับกลยุทธ์ผลิตภัณฑ์เริ่มต้น การอ้างอิง OEM ที่ผู้ให้บริการกำหนด จะต้องได้รับการปรับเปลี่ยนระหว่างการกำหนดค่าที่ไม่ใช่ AIDL กับการกำหนดค่า AIDL ด้วย เช่น

ชื่อพารามิเตอร์การกำหนดค่าที่ไม่ใช่ AIDL
/Policy/policy/product_strategies/oem_extension_strategy/device_address
/Policy/policy/product_strategies/oem_extension_strategy/selected_output_devices/mask
ชื่อพารามิเตอร์การกำหนดค่า AIDL
/Policy/policy/product_strategies/vx_1037/device_address
/Policy/policy/product_strategies/vx_1037/selected_output_devices/mask

กลยุทธ์ผลิตภัณฑ์

กลยุทธ์ผลิตภัณฑ์ช่วยให้คุณปรับแต่งวิธีจัดหมวดหมู่และจัดกลุ่มสตรีมเสียงได้ ซึ่งจะช่วยให้กำหนดค่าอุปกรณ์เสียงได้อย่างยืดหยุ่นมากขึ้น รวมถึงวิธีกำหนดเส้นทางและวิธีจัดการระดับเสียง กลยุทธ์ผลิตภัณฑ์แต่ละรายการมีกลุ่มแอตทริบิวต์เสียงได้ตั้งแต่ 1 กลุ่มขึ้นไป ซึ่งจะระบุสตรีมที่ควรเชื่อมโยงกับกลยุทธ์ผลิตภัณฑ์นั้น กลุ่มแอตทริบิวต์เสียงเหล่านี้ช่วยให้สามารถใช้แนวทางที่ละเอียดยิ่งขึ้นในการจัดหมวดหมู่เสียง และอาจเป็นการผสมผสานของประเภทต่อไปนี้

  • ประเภทการใช้งาน อธิบายเหตุผลที่เล่นเสียง (เช่น สื่อ การแจ้งเตือน การโทร)
  • ประเภทเนื้อหา ประเภทจะอธิบายสิ่งที่กำลังเล่นอยู่ (เช่น เพลง คำพูด วิดีโอ การแปลงข้อมูลเป็นเสียง)
  • ประเภทFlag กำหนดลักษณะการทำงานหรือคำขอที่แตกต่างกันเกี่ยวกับสตรีม
  • ประเภทแท็กรองรับ รายการค่าสตริงของผู้ให้บริการที่กำหนดเอง
    • สตริงแต่ละรายการต้องขึ้นต้นด้วย VX_ ตามด้วยสตริงที่เป็นตัวอักษรและตัวเลขคละกัน (เช่น 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>

ข้อความที่ตัดตอนนี้แสดงตัวอย่างกลยุทธ์ผลิตภัณฑ์ที่ใช้ในโปรแกรมจำลองรถยนต์ โดยมีแอตทริบิวต์เสียง 2 รายการที่มีสื่อการใช้งานเสียงและเกมตามลำดับ กลยุทธ์ผลิตภัณฑ์นี้ตรงกับบริบทเสียงของ MUSIC ที่ใช้ในบริการเสียงในรถยนต์ แต่ไม่จำเป็นต้องจับคู่ หนึ่งในยูทิลิตีหลักสำหรับ OEM ที่ใช้ CAP ร่วมกับ Android คือการอนุญาตให้มี คำจำกัดความการจัดกลุ่มเสียงที่ยืดหยุ่นมากขึ้น

กลุ่มระดับเสียง

นอกจากนี้ กลุ่มแอตทริบิวต์เสียงแต่ละกลุ่มต้องมีกลุ่มระดับเสียงที่เชื่อมโยงกัน กลุ่มระดับเสียงนี้เชื่อมโยงกับสตรีมที่มีแอตทริบิวต์เสียงตรงกัน ซึ่งอยู่ในกลุ่มแอตทริบิวต์เสียง ตัวอย่างกลยุทธ์ผลิตภัณฑ์เพลงในส่วนกลยุทธ์ผลิตภัณฑ์มีกลุ่มปริมาณ media และคำจำกัดความของกลุ่มปริมาณสื่อมีดังนี้

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

ในคำจำกัดความนี้ กลุ่มวอลุ่มประกอบด้วย

  • ชื่อกลุ่ม
  • ดัชนีขั้นต่ำของกลุ่ม
  • ดัชนีสูงสุดของกลุ่ม
  • เส้นโค้งกลุ่มวอลุ่ม

เส้นโค้งของกลุ่มระดับเสียงมีการแมประหว่างดัชนีกลุ่มระดับเสียงกับ การเพิ่มระดับเสียงเป็นมิลลิเบล ระบบจะใช้จุดที่ระบุเพื่อประมาณค่าแบบเชิงเส้น อัตราขยายที่ตรงกันดีที่สุดเมื่อมีการจัดการระดับเสียง เส้นโค้งของกลุ่มระดับเสียงแต่ละเส้นจะเชื่อมโยงกับหมวดหมู่ประเภทอุปกรณ์ (เช่น ชุดหูฟัง ลำโพง สื่อภายนอก)

กลุ่มระดับเสียงจะจัดการระดับเสียงสำหรับสตรีมที่เป็นส่วนหนึ่งของกลุ่มแอตทริบิวต์เสียง เช่น เมื่อเริ่มสตรีมที่มีแอตทริบิวต์เสียงซึ่งมีเพลงหรือเกม ระบบจะใช้ดัชนีระดับเสียงที่ตั้งค่าล่าสุดสำหรับกลุ่มระดับเสียงสื่อ ในกรณีนี้ ระบบจะเลือกเส้นโค้งหมวดหมู่อุปกรณ์ที่เกี่ยวข้องตาม อุปกรณ์ที่เลือก และจะตั้งค่าเกนที่เกี่ยวข้องเมื่อเริ่มสตรีม

การกำหนดค่า

ในเครื่องมือ CAP จะใช้การกำหนดค่าเพื่อกำหนด เงื่อนไขหรือกฎที่กำหนดลักษณะการทำงานของเสียง ระบบจะประเมินการกำหนดค่าเหล่านี้ในขณะรันไทม์เพื่อเลือกกฎที่เหมาะสมที่จะใช้โดยขึ้นอยู่กับสถานะปัจจุบันของระบบเสียง

ดังที่แสดงในรูปที่ 5 API มีหลายโดเมน โดยเป้าหมายของแต่ละโดเมน คือการแยกตรรกะออกเป็นปัญหาการกำหนดเส้นทางที่เล็กลงเพื่อแก้ไข (เช่น อุปกรณ์ 1, อุปกรณ์ 2)

แต่ละโดเมนมีการกำหนดค่า และการกำหนดค่าแต่ละรายการมีชุดกฎ กฎ จะสร้างขึ้นตามเกณฑ์ที่ AudioPolicyManager ระบุไว้ ดังนี้

  • โหมดเสียง
  • อุปกรณ์อินพุตและเอาต์พุตที่พร้อมใช้งาน
  • ที่อยู่อุปกรณ์อินพุตและเอาต์พุตที่พร้อมใช้งาน
  • ใช้สำหรับ
    • สื่อ
    • การสื่อสาร
    • กำลังบันทึก
    • แท่นชาร์จ
    • ระบบ
    • เสียงของระบบ HDMI
    • เสียงเซอร์ราวด์ที่เข้ารหัส
    • การสั่นเมื่อมีเสียงเรียกเข้า

แต่ละโดเมนมีการกำหนดค่าที่กำหนดกฎซึ่งควรส่งผลต่อลักษณะการทำงาน โปรดทราบว่าลำดับการกำหนดค่ามีความสำคัญ และคุณต้องตรวจสอบว่าการกำหนดค่าอยู่ในลำดับที่ต้องการ หลังจากตรวจสอบกฎสำหรับ การกำหนดค่าแล้ว ระบบจะเลือกการกำหนดค่า

โค้ดต่อไปนี้แสดงตัวอย่างส่วนย่อของไฟล์เฟรมเวิร์กพารามิเตอร์ ซึ่ง สามารถใช้เพื่อสร้างไฟล์ XML ที่จำเป็นสำหรับการกำหนดค่าโดเมนที่กำหนดค่าได้


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

โดเมน DeviceForProductStrategies จะกำหนดวิธีใช้กฎต่างๆ เมื่อจัดการกลยุทธ์ผลิตภัณฑ์และการเลือกอุปกรณ์ ส่วนสีน้ำเงิน อธิบายกฎที่ควรพิจารณา และส่วนสีเขียวคือ การกำหนดค่าที่ใช้ ตัวอย่างนี้มีการกำหนดค่าต่อไปนี้

  • เลือกอุปกรณ์ A2DP บลูทูธสำหรับกลยุทธ์ผลิตภัณฑ์เพลง (รหัส 1000, vx_1000)
    • หากใช้กับสื่อ จะไม่รวม A2DP
    • หากใช้สำหรับการสื่อสาร ไม่ใช่ BT SCO
    • หากมีอุปกรณ์ ให้รวม BT A2DP
  • เลือกอุปกรณ์บัส
    • หากอุปกรณ์บัสพร้อมใช้งาน
    • หากที่อยู่คือ BUS00_MEDIA
  • เลือกอุปกรณ์เอาต์พุตเริ่มต้น

หากต้องการสร้างไฟล์ XML ของเครื่องมือนโยบายที่กำหนดค่าได้ที่เกี่ยวข้อง ให้เรียกใช้ไฟล์ parameter-framework (PFW) ผ่านระบบบิลด์ โดยกำหนดกฎบิลด์โดยใช้ขั้นตอนต่อไปนี้

  1. ในไฟล์ Android.bp ให้สร้างกลุ่มไฟล์สำหรับไฟล์

    filegroup {
        name: ":device_for_product_strategies.pfw",
        srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
    }
    
  2. เพิ่มไฟล์ลงในไฟล์ PfW อื่นๆ (หากมี)

    filegroup {
        name: "edd_files",
        srcs: [
            ":device_for_input_source.pfw",
            ":volumes.pfw",
            ":device_for_product_strategyies.pfw",
        ],
    }
    
  3. สร้างกฎการสร้างโดเมนที่เกี่ยวข้อง

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

    โดย domaingeneratorpolicyrule คือกฎ การสร้าง ที่เฟรมเวิร์กจัดเตรียมไว้เพื่อสร้างไฟล์ PolicyConfigurableDomains.xml ไฟล์แหล่งที่มาอื่นๆ (scrs) ที่รวมอยู่ในกฎการสร้างโดเมน มีดังนี้

    แหล่งที่มา คำอธิบาย
    audio_policy_pfw_toplevel ไฟล์การกำหนดค่าเฟรมเวิร์กพารามิเตอร์ระดับบนสุด
    audio_policy_pfw_structure_files ไฟล์โครงสร้างการสร้างโดเมน ซึ่งใช้เพื่อสร้างไฟล์การกำหนดค่า
    audio_policy_engine_criterion_types ไฟล์ XML ของประเภทเกณฑ์ ซึ่งอธิบายเกณฑ์ที่ใช้ในระหว่างการสร้าง
    edd_files รายการไฟล์โดเมนเดียว (แต่ละไฟล์มีแท็ก <ConfigurableDomain> เดียว)

หลังจากเรียกใช้กฎการสร้างในบิลด์แล้ว ระบบจะสร้าง PolicyConfigurableDomains.xml พร้อมโดเมนทั้งหมด ข้อมูลต่อไปนี้ แสดงตัวอย่างจากไฟล์ที่สร้างขึ้นโดยใช้กฎตัวอย่าง 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>

การแก้ไขข้อบกพร่องของ CAP

คุณใช้ remote-process เพื่อส่งออกการกำหนดค่า CAP ได้ดังนี้

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

ซึ่งจะแสดงโดเมนและการกำหนดค่าทั้งหมด รวมถึงเงื่อนไขความเกี่ยวข้อง ต่อไปนี้เป็นตัวอย่างจากอุปกรณ์ยานยนต์ Cuttlefish ที่ใช้ การกำหนดค่า Bluetooth A2DP, อุปกรณ์บัส และการกำหนดค่าเริ่มต้น ดูการกำหนดค่า

- 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

ดูข้อมูลเพิ่มเติมเกี่ยวกับคำสั่งอื่นๆ ที่ใช้ในการแก้ไขข้อบกพร่องของพารามิเตอร์ CAP framework ได้โดยใช้เครื่องมือนี้

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

หากต้องการใช้เครื่องมือนี้ ผู้ผลิต OEM ต้องอนุญาตการปรับแต่งในอุปกรณ์ หากต้องการ ยืนยันว่าอุปกรณ์อนุญาตการปรับแต่งหรือไม่ ให้ใช้คำสั่งต่อไปนี้

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

ใน Android 15 และเวอร์ชันต่ำกว่า ไฟล์อาจแตกต่างกัน ดังนั้นให้ใช้คำสั่งต่อไปนี้

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

ไฟล์ควรมี TuningAllowed="true" พร้อมกับพอร์ตเซิร์ฟเวอร์ที่เกี่ยวข้อง

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

ระบบจะสร้างไฟล์นี้โดยอัตโนมัติ ตามประเภทของอิมเมจบิลด์ (หรือใช้ไฟล์อื่นสำหรับ รีลีส หรือ ดีบัก สำหรับบิลด์เดิม) บิลด์รีลีสจะตั้งค่า TuningAllowed เป็น false โดยไม่มี พอร์ตซ็อกเก็ต (ไม่อนุญาตให้ใช้ซ็อกเก็ตในบิลด์รีลีส) วิศวกรรมและ userdebug builds set it to true with the socket port used. โปรดทราบว่านี่คือ ไฟล์ที่audio_policy_pfw_toplevelอ้างอิง เครื่องมือกระบวนการระยะไกล ต้องรวมอยู่ในการสร้างอุปกรณ์ หรือไฟล์บิลด์ด้วย

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

นอกจากนี้ คุณต้องระบุนโยบาย SELinux ที่เกี่ยวข้อง เพื่ออนุญาตซ็อกเก็ตด้วย ซึ่งใช้ได้กับโหมดแก้ไขข้อบกพร่องเท่านั้นเนื่องจาก โหมดรีลีสไม่อนุญาตให้ใช้ซ็อกเก็ตอย่างชัดแจ้ง

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

การย้ายข้อมูล CAP ใน Android 16

เนื่องจากการเปลี่ยนแปลงที่สำคัญซึ่งเกิดจากเครื่องมือ CAP ของ HAL เสียง AIDL และเวอร์ชันก่อนหน้า จึงมีสถานการณ์การเปลี่ยนอุปกรณ์ต่างๆ ที่คุณควรพิจารณา ส่วนนี้ครอบคลุมสถานการณ์การเปลี่ยนผ่านที่โดดเด่นที่สุด และให้คำแนะนำในการดำเนินการเพื่อเปิดใช้การกำหนดค่าเครื่องมือ CAP

สถานการณ์ที่ 1: อุปกรณ์ใหม่ที่ใช้ Android 16 ขึ้นไป และไม่มีแหล่งที่มาเดิมสำหรับการกำหนดค่า CAP ของอุปกรณ์

อุปกรณ์ใหม่ต้องเปิดตัวด้วย Android 16 ขึ้นไป โค้ดในพาร์ติชัน vendor ซึ่งหมายความว่าต้องเปิดเผยการกำหนดค่าเครื่องมือนโยบายเสียงที่กำหนดค่าได้ผ่านอินเทอร์เฟซ AIDL Audio HAL ควรกำหนดค่าเครื่องมือ CAP ของอุปกรณ์ โดยคัดลอกจากตัวอย่าง ไม่ควรมีคำจำกัดความโดเมน PfW CAP ในพาร์ติชัน vendor

อิมเมจระบบที่ใช้สำหรับอุปกรณ์คือ Android 16 ขึ้นไป เฟรมเวิร์กบริการเสียงจะค้นหาการกำหนดค่า CAP ผ่านอินเทอร์เฟซ HAL เสียงของ AIDL จึงเริ่มต้น PfW โดยใช้คำจำกัดความโดเมน PfW CAP จากอิมเมจระบบ และโหลดการกำหนดค่า CAP ของอุปกรณ์ที่ได้รับผ่าน AIDL

ดูตัวอย่างได้ในอุปกรณ์เสมือน Cuttlefish สำหรับยานยนต์ ซึ่งเปิดตัวในการเปลี่ยนแปลงนี้ และสามารถใช้อ้างอิงสำหรับไฟล์ที่จำเป็น กฎการสร้าง และสร้างไฟล์ ที่จำเป็นสำหรับการตั้งค่าไฟล์การกำหนดค่าที่จำเป็น ซึ่งจะทำงานร่วมกับตัวโหลดที่ระบุไว้ใน HAL เสียง AIDL เริ่มต้น

สถานการณ์ที่ 2: อุปกรณ์ใหม่ที่ใช้ Android 16 ขึ้นไปจากอุปกรณ์เครื่องก่อนที่ใช้ CAP

อุปกรณ์ใหม่ต้องเปิดตัวด้วย Android 16 ขึ้นไป โค้ดในพาร์ติชัน vendor อย่างไรก็ตาม เนื่องจาก OEM มีการกำหนดค่าเครื่องมือ CAP ที่ใช้ได้ OEM จึงต้องการใช้การกำหนดค่าดังกล่าวเป็นจุดเริ่มต้น (หรือนำกลับมาใช้ใหม่ทั้งหมด) การกำหนดค่า CAP เวอร์ชัน AIDL มีการเปลี่ยนแปลงบางอย่าง เมื่อเทียบกับ Android 15 และเวอร์ชันที่ต่ำกว่า ดังนั้น ผู้ให้บริการต้องแปลงการกำหนดค่าที่มีอยู่เป็น AIDL ดูการสนทนาในกลยุทธ์ผลิตภัณฑ์เกี่ยวกับการเปลี่ยนแปลงระหว่าง Android 16 และเวอร์ชันที่ต่ำกว่าสำหรับการเปลี่ยนแปลงที่จำเป็น โดยทั่วไปแล้ว เฟรมเวิร์กเสียงจะค้นหาและโหลดการกำหนดค่า CAP ในลักษณะเดียวกับในสถานการณ์ที่ 1

สถานการณ์ที่ 3: อุปกรณ์ที่มีอยู่ซึ่ง CAP อัปเดตเป็น Android 16 เฉพาะพาร์ติชันระบบ

ในสถานการณ์นี้ พาร์ติชัน vendor มีการกำหนดค่า CAP ของอุปกรณ์ Android 15 และเวอร์ชันที่ต่ำกว่า รวมถึงคำจำกัดความโดเมน CAP ของ PfW vendor พาร์ติชันยังคงเหมือนเดิม จึงยังคงใช้ HIDL HAL เฟรมเวิร์กจะทำตามสถานการณ์ใน Android 15 และต่ำกว่า และโหลดการกำหนดค่าทั้งหมดที่เกี่ยวข้องกับ CAP จากพาร์ติชัน vendor

สถานการณ์ที่ 4: อุปกรณ์ที่มีอยู่ซึ่งเปิดตัวใน Android 15 พร้อม CAP

Android 15 ไม่รองรับ CAP ใน AIDL ผู้ให้บริการบางรายจึงเปิดตัวอุปกรณ์ใหม่ที่มี AIDL Audio HAL และ CAP ซึ่งเฟรมเวิร์กเสียงโหลด โหมดไฮบริดนี้เป็นโหมดที่ไม่เป็นทางการ แต่รวมอยู่ใน Android 16 โปรดทราบว่าห้ามใช้โหมดนี้เพื่อ เปิดตัวอุปกรณ์ใหม่ใน Android 16 แต่ควรใช้เพื่อ เปิดใช้อุปกรณ์ที่มีอยู่ซึ่งมีผู้ให้บริการ Android 15 เพื่อ อัปเดตเป็น Android 16 (การอัปเดตพาร์ติชัน system)

เฟรมเวิร์กเสียงจะค้นหาการกำหนดค่าเสียง HAL ของ AIDL โดยไม่มีการกำหนดค่า CAP สำหรับการกำหนดค่า CAP บริการนโยบายเสียง (audio framework) จะกลับไปโหลดการกำหนดค่า CAP จากพาร์ติชัน vendor ในกรณีนี้ ทั้งคำจำกัดความโดเมน PfW CAP และการกำหนดค่า CAP ของอุปกรณ์ ต้องโหลดจากพาร์ติชัน vendor

สรุปการย้ายข้อมูล CAP

ตารางต่อไปนี้สรุปการกำหนดค่าระบบและผู้ให้บริการที่เข้ากันได้ รวมถึงข้อกำหนดในการกำหนดค่า CAP

พาร์ติชันระบบ สถานการณ์ เวอร์ชันรหัสพาร์ติชันของผู้ให้บริการ ประเภท HAL ของเสียงหลัก ตำแหน่งคำจำกัดความของโดเมน PfW CAP การกำหนดค่า CAP ของอุปกรณ์
Android 15 4 Android 14 หรือต่ำกว่า HIDL vendor เวอร์ชัน HIDL
Android 16 3 Android 14 หรือต่ำกว่า HIDL vendor เวอร์ชัน HIDL
Android 16 4 Android 15 AIDL vendor เวอร์ชัน HIDL
Android 16 2 Android 16 AIDL system เวอร์ชัน AIDL ที่แปลงจาก HIDL
Android 16 1 Android 16 AIDL system เวอร์ชัน AIDL จากตัวอย่าง