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

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

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

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

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

बैकग्राउंड

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

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

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

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

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

आंकड़े में दिखाए गए तरीके से, CAP इंजन कॉन्फ़िगरेशन को ऑडियो नीति सेवा से हासिल किया जाता है. इसके लिए, vendor पार्टीशन में मौजूद audio_policy_engine_configuration.xml फ़ाइल से जानकारी पार्स की जाती है. CAP इंजन कॉन्फ़िगरेशन फ़ाइल, ज़रूरी जानकारी पाने के लिए 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 से, AIDL Audio HAL API की परिभाषा को ऑडियो पॉलिसी इंजन कॉन्फ़िगरेशन, AudioHalCapConfiguration.aidl के साथ बढ़ाया गया है. नीचे दी गई इमेज में, Android 16 के हिसाब से CAP इंजन के कॉन्फ़िगरेशन मैनेजमेंट के बारे में खास जानकारी दी गई है:

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

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

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

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

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

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

पांचवी इमेज. AIDL ऑडियो HAL API.

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

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

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

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

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

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

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

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

AIDL कॉन्फ़िगरेशन में स्ट्रक्चर

Android 16 और इसके बाद के वर्शन में, ऑडियो पॉलिसी सेवा, स्ट्रक्चर की जानकारी पाने के लिए ParameterFrameworkConfigurationCap.xml को पढ़ती है और पार्स करती है [file](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 इंजन कॉन्फ़िगरेशन को पैरामीटर के लिए पहले से तय किया गया नाम इस्तेमाल करना चाहिए. प्रॉडक्ट की रणनीतियों के लिए, स्ट्रक्चर 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) पर पड़ता है. खास तौर पर, प्रॉडक्ट की रणनीति से जुड़े सभी रेफ़रंस के नाम बदलकर नए नाम इस्तेमाल किए जाने चाहिए. उदाहरण के लिए:

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

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

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

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

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

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

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

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

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

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

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>

पिन कोड डीबग करना

CAP कॉन्फ़िगरेशन डंप करने के लिए, इस कमांड का इस्तेमाल करें: remote-process

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

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

# 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 में CAP माइग्रेशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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