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

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

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

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

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

ฉากหลัง

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

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

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

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

รูปที่ 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

รูปที่ 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 default 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 ของ AIDL Audio HAL

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

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

บริการนโยบายเสียงจะรับข้อมูลเครื่องมือ CAP โดยใช้ AIDL Audio HAL API โดยตรงแทนที่จะแยกวิเคราะห์ข้อมูลจากไฟล์ XML ในพาร์ติชันของผู้ให้บริการของอุปกรณ์ การตั้งค่านี้จะนำการแยกวิเคราะห์ XML ออกจากเฟรมเวิร์ก นอกจากนี้ Audio HAL เองก็ไม่จำเป็นต้องแยกวิเคราะห์ XML อย่างเคร่งครัด แต่ต้องระบุข้อมูลการกำหนดค่าผ่าน AIDL ซึ่งเรียกข้อมูลได้จากแหล่งที่มาใดก็ได้ เพื่อความสะดวก การใช้งาน Audio HAL เริ่มต้นของ AOSP มีตัวแปลง XML (EngineConfigXmlConverter.cpp) เพื่อแยกวิเคราะห์การกำหนดค่า XML มาตรฐานและสร้างออบเจ็กต์ AIDL AudioHalEngineConfig โดยตรง

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

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

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

รูปภาพต่อไปนี้แสดงภาพรวมระดับสูงของ AIDL Audio HAL API ที่ ใช้โดยบริการนโยบายเสียงเพื่อรับการกำหนดค่าเครื่องมือ 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) ที่ใช้ในการกำหนดค่าเครื่องมือค้นหา โดยเฉพาะอย่างยิ่ง การอ้างอิงกลยุทธ์ผลิตภัณฑ์ทั้งหมดควร เปลี่ยนไปใช้ชื่อใหม่ เช่น

กลยุทธ์ผลิตภัณฑ์ที่ OEM กำหนด

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

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

การกำหนดเส้นทางเสียงแบบหลายโซน

ใน Android 16 ขึ้นไป สคีมา CAP จะผสานรวมกับคำจำกัดความเสียงแบบหลายโซนของ Android Automotive

ในเครื่องมือ CAP zoneIdแอตทริบิวต์ที่ไม่บังคับใน ProductStrategy จะทำหน้าที่เป็นเกณฑ์การจับคู่ต้นทาง โดยจะกรองสตรีมตามโซนต้นทางที่การเล่นเริ่มต้น

1. การจับคู่ต้นทาง (zoneId): เมื่อ CarAudioService ลงทะเบียน การแมปผู้ใช้กับโซนโดยใช้ setProductStrategiesZoneIdForUser เครื่องมือ CAP จะใช้ zoneId เป็นพารามิเตอร์การจับคู่เพื่อเลือก ProductStrategy ที่เหมาะสม สำหรับสตรีมของโซนนั้น
2. การกำหนดเส้นทางปลายทาง (ปลายทางของอุปกรณ์): เมื่อจัดกลุ่มเป็นกลยุทธ์ การกำหนดค่าการกำหนดเส้นทางเสียงจะกำหนดการแมประหว่างกลยุทธ์ผลิตภัณฑ์เหล่านี้ และอุปกรณ์เอาต์พุต เช่น อุปกรณ์บัสอย่าง bus100_media_out สำหรับโซน 1

กลยุทธ์ผลิตภัณฑ์ใน <ProductStrategies> สามารถระบุzoneId ที่สอดคล้องกับโซนการเข้าพัก (คนขับหรือผู้โดยสาร) ได้ดังนี้

<ProductStrategies>
    <!-- General Primary Zone Media -->
    <ProductStrategy name="music_primary" id="1000" zoneId="0">
        <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media_vol_primary">
            <Attributes>
                <Usage value="AUDIO_USAGE_MEDIA"/>
            </Attributes>
        </AttributesGroup>
    </ProductStrategy>

    <!-- Secondary Zone Media Endpoint -->
    <ProductStrategy name="music_rear_seat" id="1002" zoneId="1">
        <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media_vol_rear">
            <Attributes>
                <!-- Rear seat entertainment attribute mapping via bundle tags -->
                <Usage value="AUDIO_USAGE_MEDIA"/>
                <Bundle key="VX_OEM" value="REAR_SEAT"/>
            </Attributes>
        </AttributesGroup>
    </ProductStrategy>
</ProductStrategies>

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

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

• ประเภทการใช้งาน อธิบายเหตุผลที่เล่นเสียง (เช่น สื่อ การแจ้งเตือน การโทร)
• ประเภทเนื้อหา ประเภทจะอธิบายสิ่งที่กำลังเล่นอยู่ (เช่น เพลง คำพูด วิดีโอ การแปลงข้อมูลเป็นเสียง)
• ประเภทFlag กำหนดลักษณะการทำงานหรือคำขอที่แตกต่างกันเกี่ยวกับสตรีม โปรดทราบว่าต้องระบุแฟล็กหลายรายการเป็นสตริงที่คั่นด้วยช่องว่าง เช่น <Flags value="AUDIO_FLAG_SCO AUDIO_FLAG_BEACON"/>
• ประเภทแท็กรองรับ รายการค่าสตริงของผู้ให้บริการที่กำหนดเอง หากต้องการกําหนดแท็กในการกําหนดค่า คุณต้องใช้องค์ประกอบ <Bundle>
  • คีย์กลุ่มแต่ละรายการต้องขึ้นต้นด้วยคำนำหน้า VX_ ตามด้วยสตริงที่เป็นตัวอักษรและตัวเลขคละกัน เช่น <Bundle key="VX_OEM" value="REAR_SEAT"/>

<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 รายการที่มีสื่อการใช้งานเสียงและเกมตามลำดับ โปรดทราบว่ากลยุทธ์ผลิตภัณฑ์ของผู้ให้บริการที่กำหนดไว้ใน XML ต้องมีแอตทริบิวต์ id อย่างชัดเจน (เช่น id="1008" ในข้อมูลโค้ดด้านบน) ซึ่งแมปโดยตรงกับตัวระบุกลยุทธ์มาตรฐานที่ Audio HAL กำหนด หากไม่มีผู้ให้บริการ id การกำหนดค่าจะทริกเกอร์ลักษณะการทำงานสำรองที่เป็นอันตรายในระหว่างการแยกวิเคราะห์

กลยุทธ์ผลิตภัณฑ์นี้สอดคล้องกับบริบทเสียงของ 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 สร้างชุดเป็น true โดยใช้พอร์ตซ็อกเก็ต โปรดทราบว่านี่คือ ไฟล์ที่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 ซึ่งหมายความว่าต้องเปิดเผยการกำหนดค่าเครื่องมือนโยบายเสียงที่กำหนดค่าได้ผ่านอินเทอร์เฟซ HAL เสียงของ AIDL ควรคัดลอกการกำหนดค่าเครื่องมือ CAP ของอุปกรณ์จากตัวอย่าง ไม่ควรมีคำจำกัดความโดเมน PfW CAP ในพาร์ติชัน vendor

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

ดูตัวอย่างได้ในอุปกรณ์เสมือน Cuttlefish สำหรับยานยนต์ ซึ่งเปิดตัวในการเปลี่ยนแปลงนี้ และสามารถใช้อ้างอิงสำหรับไฟล์ที่จำเป็น กฎการสร้าง และไฟล์ Make ที่จำเป็นสำหรับการตั้งค่าไฟล์การกำหนดค่าที่จำเป็น ซึ่งจะทำงานร่วมกับ โปรแกรมโหลดที่ระบุไว้ใน 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 และเวอร์ชันที่ต่ำกว่า รวมถึงคำจำกัดความโดเมน PfW CAP 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