कॉन्फ़िगर किया जा सकने वाला ऑडियो नीति इंजन

Android 14 में, Android Automotive Operating System (AAOS), मुख्य ऑडियो ज़ोन में कॉन्फ़िगर किए जा सकने वाले ऑडियो नीति (सीएपी) इंजन कार ऑडियो मैनेजमेंट का फ़ायदा उठाता है. खास तौर पर, CAP इंजन की मदद से AAOS, सिर्फ़ ऑडियो रूटिंग, सिर्फ़ ऑडियो वॉल्यूम या रूटिंग और वॉल्यूम, दोनों को एक साथ कंट्रोल कर सकता है. व्यवहार को कंट्रोल करने के लिए, इन फ़्लैग का इस्तेमाल किया जा सकता है:

• सीएपी वॉल्यूम मैनेजमेंट की सुविधा चालू करने के लिए, useCoreAudioVolume फ़्लैग का इस्तेमाल करें. अगर यह वैल्यू true है, तो कार की ऑडियो सेवा, वॉल्यूम ग्रुप मैनेज करने के लिए ऑडियो मैनेजर एपीआई का इस्तेमाल करती है.

• सीएपी ऑडियो रूटिंग मैनेजमेंट की सुविधा चालू करने के लिए, useCoreAudioRouting फ़्लैग का इस्तेमाल करें. जब यह वैल्यू true होती है, तो कार की ऑडियो सेवा, ऑडियो रूटिंग को मैनेज करने के लिए, कॉन्फ़िगर की जा सकने वाली ऑडियो नीति रूटिंग का इस्तेमाल करती है.

ऑडियो नीति इंजन, Android में डिफ़ॉल्ट रूप से काम करता है. इसे डिफ़ॉल्ट ऑडियो नीति इंजन कहा जाता है.

बैकग्राउंड

सीएपी इंजन, Intel के पैरामीटर फ़्रेमवर्क पर आधारित है. यह पैरामीटर को मैनेज करने के लिए, प्लग इन और नियम पर आधारित फ़्रेमवर्क है. खास तौर पर, Android ऑडियो मैनेजमेंट के लिए, CAP इंजन ने एक्सएमएल फ़ाइलों के नियमों को तय करने की सुविधा शुरू की है. इससे, इनके बारे में जानकारी मिलती है:

• ऑडियो प्रॉडक्ट की रणनीति
• ऑडियो आउटपुट डिवाइस चुनने के नियम
• ऑडियो इनपुट डिवाइस चुनने के नियम
• वॉल्यूम टेबल के साथ-साथ, वॉल्यूम को मैनेज करने और म्यूट करने के नियम

Android 16 से पहले CAP को शुरू करना

इस इमेज में, Android 6 के तौर पर कॉन्फ़िगर की जा सकने वाली ऑडियो नीति इंजन कॉन्फ़िगरेशन मैनेजमेंट के बारे में खास जानकारी दी गई है:

पहली इमेज. Android 6 के हिसाब से, सीएपी इंजन कॉन्फ़िगरेशन मैनेजमेंट.

जैसा कि इस इलस्ट्रेशन में दिखाया गया है, ऑडियो नीति सेवा, vendor सेक्शन में मौजूद audio_policy_engine_configuration.xml फ़ाइल से जानकारी पार्स करके, सीएपी इंजन कॉन्फ़िगरेशन हासिल करती है. ज़रूरी जानकारी पाने के लिए, सीएपी इंजन कॉन्फ़िगरेशन फ़ाइल, audio_policy_engine_configuration.xsd में बताए गए स्कीमा का इस्तेमाल करती है. audio_policy_engine_configuration.xml, वाहन संबंधित कैटगरी का उदाहरण है. अन्य फ़ॉर्म फ़ैक्टर के लिए मिलते-जुलते उदाहरण, frameworks/av/services/audiopolicy/engineconfigurable/config/example/ फ़ोल्डर में मौजूद हैं.

नीचे दिए गए इलस्ट्रेशन में, इस बारे में ज़्यादा जानकारी दी गई है कि ऑडियो नीति इंजन की कॉन्फ़िगर की जा सकने वाली जानकारी को ऑडियो नीति सेवा में कैसे लोड किया जाता है. इस मामले में, पैरामीटर फ़्रेमवर्क, एक्सएमएल फ़ाइलों से स्ट्रक्चर और सेटिंग लोड करता है.

दूसरी इमेज. ऑडियो नीति सेवा में लोड की गई सीएपी की जानकारी.

Android 15 और उससे पहले के वर्शन में CAP स्ट्रक्चर फ़ाइलें

ऑडियो नीति सेवा, ParameterFrameworkConfigurationPolicy.xml फ़ाइल को पढ़कर स्ट्रक्चर और सेटिंग हासिल करती है. यह स्ट्रक्चर की जानकारी का रेफ़रंस देता है. यह जानकारी, स्ट्रक्चर की जानकारी वाली फ़ाइल की जगह से मिलती है:

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

यह फ़ाइल में स्ट्रक्चर की जानकारी दिखाता है:

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

Android में स्केलेटन स्ट्रक्चर दिया गया है. स्ट्रक्चर की जानकारी के लिए, प्रॉडक्ट की रणनीति के स्ट्रक्चर की जानकारी ज़रूरी है. इसलिए, Android buildStrategiesStructureFile.py जनरेट करने वाला टूल उपलब्ध कराता है. यह टूल, प्रॉडक्ट की रणनीति की उपलब्ध एक्सएमएल फ़ाइल से जानकारी जनरेट कर सकता है. इसका रेफ़रंस, genrule default buildstrategiesstructurerule के ज़रिए इस तरह दिया जा सकता है:

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

यहां audio_policy_engine_configuration_files, ऑडियो नीति इंजन की कॉन्फ़िगरेशन फ़ाइलें हैं. वाहन संबंधित ऐप्लिकेशन के लिए यह उदाहरण, वाहन संबंधित फ़ोल्डर में मौजूद ऑडियो नीति की कॉन्फ़िगरेशन फ़ाइलों का रेफ़रंस देता है. अन्य उदाहरणों में, डिवाइस के वेंडर पार्टिशन में फ़ाइलों को पुश करने के लिए, किसी बिल्ड को कॉन्फ़िगर करने का तरीका बताया गया है.

Android 15 और उससे पहले के वर्शन में CAP सेटिंग फ़ाइलें

स्ट्रक्चर की तरह ही, सेटिंग की जानकारी, ParameterFrameworkConfigurationPolicy.xml फ़ाइल में इस तरह रेफ़र की जाती है:

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

Android, ऑडियो नीति इंजन कॉन्फ़िगरेशन और पैरामीटर फ़्रेमवर्क फ़ाइलों का इस्तेमाल करके, यह जानकारी जनरेट करने के लिए बिल्ड टूल भी उपलब्ध कराता है. ज़्यादा जानकारी के लिए, कॉन्फ़िगरेशन देखें.

एआईडीएल ऑडियो एचएएल सीएपी को शुरू करना

Android 16 से, ऑडियो नीति इंजन कॉन्फ़िगरेशन, AudioHalCapConfiguration.aidl के साथ, एआईडीएल ऑडियो एचएएल एपीआई की परिभाषा को बड़ा किया गया है. इस इमेज में, Android 16 के हिसाब से सीएपी इंजन कॉन्फ़िगरेशन मैनेजमेंट के बारे में खास जानकारी दी गई है:

तीसरी इमेज. Android 16 के हिसाब से, सीएपी इंजन का कॉन्फ़िगरेशन मैनेजमेंट.

ऑडियो नीति सेवा, डिवाइस के वेंडर सेक्शन में मौजूद एक्सएमएल फ़ाइलों से जानकारी पार्स करने के बजाय, सीधे AIDL Audio HAL APIs का इस्तेमाल करके सीएपी इंजन की जानकारी हासिल करती है.

इस कॉन्फ़िगरेशन में, पैरामीटर फ़्रेमवर्क का स्ट्रक्चर अब भी ऑडियो सर्वर साइड पर, सीएपी इंजन से लोड किया जाता है.

चौथी इमेज. सीएपी इंजन का स्ट्रक्चर.

सभी मामलों में, कॉन्फ़िगरेशन में प्रॉडक्ट की रणनीतियों, वॉल्यूम ग्रुप, और शर्तों से जुड़ी पूरी जानकारी होनी चाहिए.

नीचे दी गई इमेज में, AIDL ऑडियो एचएएल एपीआई की खास जानकारी दी गई है. ऑडियो नीति सेवा, सीएपी इंजन कॉन्फ़िगरेशन पाने के लिए इन एपीआई का इस्तेमाल करती है:

पांचवीं इमेज. AIDL ऑडियो एचएएल एपीआई.

इस सेटअप में, ऑडियो नीति सेवा, AIDL ऑडियो एचएएल से यह जानकारी हासिल करती है:

• कॉन्फ़िगरेशन
• रणनीतियां
• अंक
• शर्तें
• सेटिंग

डिफ़ॉल्ट AIDL Audio HAL लोडर

HIDL से AIDL पर आसानी से स्विच करने के लिए, डिफ़ॉल्ट ऑडियो AIDL Audio HAL, एक्सएमएल CAP इंजन लोडर उपलब्ध कराता है. वेंडर, अपने ऑडियो एचएएल को डिफ़ॉल्ट ऑडियो एचएएल के साथ बढ़ाकर या libaudioserviceexampleimpl लाइब्रेरी का रेफ़रंस देकर, इस लोडर का सीधे तौर पर इस्तेमाल कर सकते हैं.

डिफ़ॉल्ट एआईडीएल ऑडियो एचएएल लोडर, audio_policy_engine_configuration.xml का इस्तेमाल करके यह जानकारी हासिल करता है:

• कॉन्फ़िगरेशन
• रणनीतियां
• अंक
• शर्तें

स्ट्रक्चर की जानकारी, PolicyConfigurableDomains.xml फ़ाइल से मिलती है. पिछले तरीके से मुख्य अंतर यह है कि ऑडियो नीति सेवा में पैरामीटर फ़्रेमवर्क के बजाय, AIDL ऑडियो एचएएल से भी स्ट्रक्चर की जानकारी मिलती है.

वेंडर, ऑडियो नीति इंजन कॉन्फ़िगरेशन की जानकारी का इस्तेमाल करके, कॉन्फ़िगर किए जा सकने वाले डोमेन जनरेट करने के लिए, domaingeneratorpolicyrule टूल का इस्तेमाल कर सकते हैं. ऑटोमोटिव Cuttlefish वर्चुअल डिवाइस के उदाहरण का इस्तेमाल रेफ़रंस के तौर पर किया जा सकता है.

एआईडीएल कॉन्फ़िगरेशन में स्ट्रक्चर

Android 16 और इसके बाद के वर्शन में, ऑडियो नीति सेवा, ParameterFrameworkConfigurationCap.xml फ़ाइल को पढ़कर और उसका विश्लेषण करके, स्ट्रक्चर की जानकारी हासिल करती है. खास तौर पर, यह जानकारी स्ट्रक्चर की जानकारी वाली फ़ाइल से मिलती है:

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

फ़्रेमवर्क, ज़रूरी जानकारी के साथ /etc/parameter-framework/ फ़ोल्डर में ज़रूरी फ़ाइलें डालता है.

स्ट्रक्चर उन पैरामीटर को दिखाता है जिन्हें कंट्रोल किया जाना चाहिए. इसलिए, उन्हें कॉन्फ़िगरेशन या डोमेन में रेफ़र किया जाना चाहिए. इसके लिए, एआईडीएल इंजन के कॉन्फ़िगरेशन में पैरामीटर के लिए पहले से तय किए गए नाम का इस्तेमाल किया जाना चाहिए. प्रॉडक्ट की रणनीतियों के लिए, स्ट्रक्चर को 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, एक्सएमएल) पर पड़ेगा. खास तौर पर, प्रॉडक्ट की रणनीति के सभी रेफ़रंस को नए नामों का इस्तेमाल करने के लिए बदला जाना चाहिए. उदाहरण के लिए:

OEM की तय की गई प्रॉडक्ट रणनीतियां

कॉन्फ़िगर किए जा सकने वाले इंजन की मदद से, OEM, प्रॉडक्ट की रणनीतियों की परिभाषा बदल सकते हैं. इस सुविधा को जारी रखने के लिए, प्रॉडक्ट की रणनीति वाली फ़ाइल CapProductStrategies.xml में भी वेंडर के लिए 40 प्रॉडक्ट की रणनीतियां उपलब्ध हैं. ये रणनीतियां vx_1000 से लेकर vx_1039 तक की हैं. सभी वेंडर एक्सटेंशन, vx_ प्रीफ़िक्स से शुरू होने चाहिए. इसके बाद, एक नंबर होना चाहिए, जो एआईडीएल ऑडियो एचएएल प्रॉडक्ट की रणनीति की परिभाषा में प्रॉडक्ट की रणनीति आईडी को दिखाता है. बाकी की परिभाषाएं (उदाहरण के लिए, ऑडियो एट्रिब्यूट ग्रुप, नाम) ऑडियो एचएएल इंजन कॉन्फ़िगरेशन में AudioHALProductStrategy ऑब्जेक्ट से मिलती हैं.

प्रॉडक्ट की डिफ़ॉल्ट रणनीतियों की तरह ही, वेंडर के तय किए गए OEM रेफ़रंस को भी नॉन-एआईडीएल कॉन्फ़िगरेशन और एआईडीएल कॉन्फ़िगरेशन के बीच अडैप्ट करना होगा. उदाहरण के लिए:

प्रॉडक्ट की रणनीतियां

प्रॉडक्ट की रणनीतियों की मदद से, ऑडियो स्ट्रीम को कैटगरी और ग्रुप में बांटने का तरीका अपने हिसाब से तय किया जा सकता है. इससे ऑडियो डिवाइसों को कॉन्फ़िगर करने में ज़्यादा सुविधा मिलती है. इसमें, यह तय करना भी शामिल है कि उन्हें कैसे रूट किया जाए और उनके वॉल्यूम को कैसे मैनेज किया जाए. हर प्रॉडक्ट रणनीति में एक या उससे ज़्यादा ऑडियो एट्रिब्यूट ग्रुप हो सकते हैं. इन ग्रुप से उन स्ट्रीम की पहचान होती है जिन्हें उस प्रॉडक्ट रणनीति से जोड़ा जाना चाहिए. ऑडियो एट्रिब्यूट के इन ग्रुप की मदद से, ऑडियो को अलग-अलग कैटगरी में बांटा जा सकता है. साथ ही, इनमें इनमें से किसी भी तरह के एट्रिब्यूट शामिल हो सकते हैं:

• इस्तेमाल के टाइप से यह पता चलता है कि आवाज़ क्यों चल रही है. जैसे, मीडिया, सूचना, कॉल.
• कॉन्टेंट टाइप से पता चलता है कि क्या चल रहा है. जैसे, संगीत, बोली, वीडियो, और साउंडफ़िकेशन.
• फ़्लैग टाइप, स्ट्रीम के लिए अलग-अलग व्यवहार या अनुरोध तय करते हैं.
• टैग टाइप, वेंडर स्ट्रिंग वैल्यू की किसी भी सूची के साथ काम करते हैं.
  • हर स्ट्रिंग 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>

इस टेक्स्ट में, कार इम्युलेटर में इस्तेमाल की गई प्रॉडक्ट रणनीति का उदाहरण दिया गया है. इसमें दो ऑडियो एट्रिब्यूट शामिल हैं. पहला, ऑडियो के इस्तेमाल के लिए मीडिया और दूसरा, गेम. यह प्रॉडक्ट रणनीति, कार की ऑडियो सेवा में इस्तेमाल किए गए MUSIC ऑडियो कॉन्टेक्स्ट से मेल खाती है. हालांकि, ऐसा करना ज़रूरी नहीं है. Android के साथ CAP का इस्तेमाल करने वाले OEM के लिए, ऑडियो ग्रुपिंग की परिभाषाओं को ज़्यादा आसानी से तय करने की सुविधा एक मुख्य सुविधा है.

वॉल्यूम ग्रुप

इसके अलावा, हर ऑडियो एट्रिब्यूट ग्रुप के लिए, एक वॉल्यूम ग्रुप होना चाहिए. यह वॉल्यूम ग्रुप, ऑडियो एट्रिब्यूट ग्रुप से जुड़े ऑडियो एट्रिब्यूट से मैच करने वाली किसी भी स्ट्रीम से जुड़ा होता है. प्रॉडक्ट की रणनीतियां सेक्शन में, संगीत प्रॉडक्ट की रणनीति के उदाहरण में वॉल्यूम ग्रुप 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 इंजन में, कॉन्फ़िगरेशन का इस्तेमाल उन शर्तों या नियमों को तय करने के लिए किया जाता है जिनसे यह तय होता है कि ऑडियो कैसा काम करे. ऑडियो सिस्टम की मौजूदा स्थिति के आधार पर लागू करने के लिए सही नियम चुनने के लिए, इन कॉन्फ़िगरेशन का आकलन रन टाइम पर किया जाता है.

जैसा कि पांचवें चित्र में दिखाया गया है, एपीआई में कई डोमेन होते हैं. हर डोमेन का लक्ष्य, लॉजिक को छोटी रूटिंग समस्याओं में बांटना होता है, ताकि उन्हें हल किया जा सके. उदाहरण के लिए, डिवाइस 1, डिवाइस 2.

हर डोमेन में कॉन्फ़िगरेशन होते हैं और हर कॉन्फ़िगरेशन में नियमों का एक सेट होता है. नियम, AudioPolicyManager की ओर से तय की गई शर्तों के आधार पर तय किए जाते हैं:

• ऑडियो मोड
• इनपुट और आउटपुट के लिए उपलब्ध डिवाइस
• इनपुट और आउटपुट डिवाइसों के उपलब्ध पते
• इसके लिए इस्तेमाल करें
  • मीडिया
  • कम्यूनिकेशन से जुड़ी सेटिंग
  • रिकॉर्डिंग
  • डॉक
  • सिस्टम
  • एचडीएमआई सिस्टम ऑडियो
  • एन्कोड किया गया सराउंड साउंड
  • कॉल आने पर वाइब्रेट हो

हर डोमेन में ऐसे कॉन्फ़िगरेशन होते हैं जो उन नियमों को तय करते हैं जिनका व्यवहार पर असर पड़ना चाहिए. ध्यान दें कि कॉन्फ़िगरेशन का क्रम ज़रूरी है. साथ ही, यह पक्का करना ज़रूरी है कि कॉन्फ़िगरेशन सही क्रम में हों. कॉन्फ़िगरेशन के नियमों की पुष्टि होने के बाद, कॉन्फ़िगरेशन चुना जाता है.

नीचे दिए गए कोड में, पैरामीटर फ़्रेमवर्क फ़ाइल का एक उदाहरण दिया गया है. इसका इस्तेमाल, कॉन्फ़िगर किए जा सकने वाले डोमेन को कॉन्फ़िगर करने के लिए ज़रूरी एक्सएमएल फ़ाइल जनरेट करने के लिए किया जा सकता है:

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 से यह तय होता है कि डिवाइस चुनने के लिए, प्रॉडक्ट की रणनीतियों को मैनेज करते समय अलग-अलग नियम कैसे लागू किए जाने चाहिए. नीले हिस्सों में उन नियमों के बारे में बताया गया है जिन पर ध्यान दिया जाना चाहिए. हरे हिस्से में, लागू किया गया कॉन्फ़िगरेशन दिखता है. इस उदाहरण में ये कॉन्फ़िगरेशन शामिल हैं:

• संगीत वाले प्रॉडक्ट की रणनीति (आईडी 1000, vx_1000) के लिए, ब्लूटूथ A2DP डिवाइस चुनें
  • अगर मीडिया के लिए इस्तेमाल किया जाता है, तो A2DP को शामिल नहीं किया जाता
  • अगर इसका इस्तेमाल कम्यूनिकेशन के लिए किया जाता है, तो यह BT SCO नहीं है
  • अगर उपलब्ध डिवाइसों में BT A2DP शामिल है, तो उसे शामिल करें
• बस डिवाइस चुनें
  • अगर बस डिवाइस उपलब्ध है
  • अगर पता BUS00_MEDIA है, तो
• अगर ऐसा नहीं है, तो डिफ़ॉल्ट आउटपुट डिवाइस चुनें

कॉन्फ़िगर की जा सकने वाली नीति इंजन एक्सएमएल फ़ाइल जनरेट करने के लिए, बिल्ड सिस्टम के ज़रिए पैरामीटर-फ़्रेमवर्क (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	शर्तों के टाइप की एक्सएमएल फ़ाइल, जिसमें जनरेट करने के दौरान इस्तेमाल की गई शर्तों के बारे में बताया गया है.
   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>

सीएपी डीबग करना

सीएपी कॉन्फ़िगरेशन को डंप करने के लिए, remote-process का इस्तेमाल किया जा सकता है:

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

इसमें सभी डोमेन और कॉन्फ़िगरेशन दिखते हैं. साथ ही, लागू होने की शर्तें भी दिखती हैं. यहां Cuttlefish वाहन वाले डिवाइस का एक हिस्सा दिखाया गया है. इसमें ब्लूटूथ 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 पैरामीटर फ़्रेमवर्क को डीबग करने के लिए उपलब्ध अन्य कमांड के बारे में ज़्यादा जानने के लिए, इस टूल का इस्तेमाल करें:

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 में रेफ़रंस दिया गया है. रिमोट-प्रोसेस टूल को डिवाइस के make या बिल्ड फ़ाइल में भी शामिल करना ज़रूरी है:

# 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

Android 16 में सीएपी माइग्रेशन

AIDL ऑडियो HAL CAP इंजन और पिछले वर्शन में किए गए बड़े बदलावों को देखते हुए, डिवाइस के ट्रांज़िशन की कई स्थितियां हैं जिन पर आपको ध्यान देना चाहिए. इस सेक्शन में, ट्रांज़िशन के सबसे अहम मामलों के बारे में बताया गया है. साथ ही, सीएपी इंजन कॉन्फ़िगरेशन को चालू करने के लिए, काम से जुड़े सुझाव भी दिए गए हैं.

पहला उदाहरण: Android 16 या इसके बाद के वर्शन का इस्तेमाल करने वाला नया डिवाइस, डिवाइस के सीएपी कॉन्फ़िगरेशन का कोई पिछला सोर्स नहीं

नए डिवाइस में vendor पार्टीशन पर, Android 16 या उसके बाद के वर्शन का कोड होना चाहिए. इसका मतलब है कि इसे कॉन्फ़िगर किए जा सकने वाले ऑडियो नीति इंजन कॉन्फ़िगरेशन को, AIDL ऑडियो एचएएल इंटरफ़ेस के ज़रिए दिखाना होगा. डिवाइस के लिए सीएपी इंजन का कॉन्फ़िगरेशन, उदाहरणों से कॉपी किया जाना चाहिए. vendor पार्टिशन पर, PfW CAP डोमेन की कोई परिभाषा नहीं होनी चाहिए.

डिवाइस के लिए इस्तेमाल की गई सिस्टम इमेज, Android 16 या इससे पहले के वर्शन की हो. ऑडियो सेवा फ़्रेमवर्क, एआईडीएल ऑडियो एचएएल इंटरफ़ेस की मदद से सीएपी कॉन्फ़िगरेशन का पता लगाता है. इसलिए, यह सिस्टम इमेज से PfW सीएपी डोमेन की परिभाषा का इस्तेमाल करके PfW को शुरू करता है और एआईडीएल से मिला डिवाइस सीएपी कॉन्फ़िगरेशन लोड करता है.

उदाहरण के लिए, ऑटोमोटिव Cuttlefish वर्चुअल डिवाइस देखें, जिसे इस बदलाव में पेश किया गया था. इस डिवाइस का रेफ़रंस, ज़रूरी फ़ाइलों, नियमों को बनाने, और ज़रूरी कॉन्फ़िगरेशन फ़ाइलों को सेट अप करने के लिए लिया जा सकता है. यह डिफ़ॉल्ट AIDL ऑडियो एचएएल में दिए गए लोडर के साथ काम करता है.

दूसरा उदाहरण: CAP का इस्तेमाल करने वाले पुराने डिवाइस से, Android 16 या इसके बाद के वर्शन वाले नए डिवाइस पर ट्रांसफ़र करना

नए डिवाइस में vendor पार्टीशन पर, Android 16 या उसके बाद के वर्शन का कोड होना चाहिए. हालांकि, ओईएम के पास इस्तेमाल किया जा सकने वाला डिवाइस कैप इंजन कॉन्फ़िगरेशन है. इसलिए, वह इसे शुरुआती बिंदु के तौर पर इस्तेमाल करना चाहेगा (या इसका पूरी तरह से फिर से इस्तेमाल करना चाहेगा). CAP कॉन्फ़िगरेशन के एआईडीएल वर्शन में, Android 15 और उससे पहले के वर्शन की तुलना में कुछ बदलाव किए गए हैं. इसलिए, वेंडर को मौजूदा कॉन्फ़िगरेशन को एआईडीएल में बदलना होगा. ज़रूरी बदलावों के लिए, Android 16 और इससे पहले के वर्शन के बीच हुए बदलावों के बारे में जानने के लिए, प्रॉडक्ट की रणनीतियों में दी गई चर्चा देखें. आम तौर पर, ऑडियो फ़्रेमवर्क, CAP कॉन्फ़िगरेशन को उसी तरह खोजता और लोड करता है जिस तरह से पहले मामले में किया गया था.

तीसरा उदाहरण: मौजूदा डिवाइस, जिसमें CAP की मदद से सिर्फ़ सिस्टम पार्टीशन को Android 16 पर अपडेट किया जा रहा है

इस स्थिति में, vendor पार्टीशन में डिवाइस के CAP कॉन्फ़िगरेशन का Android 15 और इससे पहले का वर्शन और PfW CAP डोमेन की परिभाषा शामिल होती है. vendor पार्टीशन में कोई बदलाव नहीं किया गया है, इसलिए यह अब भी HIDL HAL का इस्तेमाल करता है. यह फ़्रेमवर्क, Android 15 और उससे पहले के वर्शन के हिसाब से काम करता है. साथ ही, vendor पार्टीशन से CAP से जुड़े सभी कॉन्फ़िगरेशन लोड करता है.

चौथा उदाहरण: Android 15 पर रिलीज़ किया गया मौजूदा डिवाइस, जिसमें सीएपी है

Android 15 पर, AIDL में CAP काम नहीं करता था. इसलिए, कुछ वेंडर ने AIDL Audio HAL और CAP के साथ नए डिवाइस रिलीज़ किए. इन्हें ऑडियो फ़्रेमवर्क से लोड किया गया था. यह हाइब्रिड मोड अनौपचारिक था, लेकिन इसे Android 16 में शामिल किया गया है. ध्यान दें कि इस मोड का इस्तेमाल, Android 16 पर नए डिवाइस रिलीज़ करने के लिए नहीं किया जाना चाहिए. इसका इस्तेमाल, Android 15 वेंडर वाले मौजूदा डिवाइसों को Android 16 (system पार्टीशन अपडेट) पर अपडेट करने के लिए किया जाना चाहिए.

ऑडियो फ़्रेमवर्क, सीएपी कॉन्फ़िगरेशन के बिना, एआईडीएल ऑडियो एचएएल ऑडियो कॉन्फ़िगरेशन का पता लगाता है. सीएपी कॉन्फ़िगरेशन के लिए, ऑडियो नीति सेवा (ऑडियो फ़्रेमवर्क) vendor सेक्शन से सीएपी कॉन्फ़िगरेशन लोड करती है. इस मामले में, PfW CAP डोमेन डेफ़िनिशन और डिवाइस CAP कॉन्फ़िगरेशन, दोनों को vendor पार्टिशन से लोड किया जाना चाहिए.

सीएपी माइग्रेशन की खास जानकारी

यहां दी गई टेबल में, CAP कॉन्फ़िगरेशन के साथ काम करने वाले सिस्टम और वेंडर कॉन्फ़िगरेशन के बारे में खास जानकारी दी गई है. साथ ही, इस कॉन्फ़िगरेशन से जुड़ी ज़रूरी शर्तों के बारे में भी बताया गया है: