কনফিগারযোগ্য অডিও নীতি ইঞ্জিন

অ্যান্ড্রয়েড ১৪-এ, অ্যান্ড্রয়েড অটোমোটিভ অপারেটিং সিস্টেম (AAOS) প্রাইমারি অডিও জোনের মধ্যে গাড়ির অডিও ব্যবস্থাপনার জন্য কনফিগারেবল অডিও পলিসি (CAP) ইঞ্জিন ব্যবহার করে। বিশেষত, CAP ইঞ্জিন AAOS-কে শুধুমাত্র অডিও রাউটিং, শুধুমাত্র অডিও ভলিউম, অথবা একই সাথে রাউটিং এবং ভলিউম উভয়ই নিয়ন্ত্রণ করার সুযোগ দেয়। এর আচরণ নিয়ন্ত্রণ করতে নিম্নলিখিত ফ্ল্যাগগুলো ব্যবহার করা যেতে পারে:

• CAP ভলিউম ম্যানেজমেন্ট চালু করতে useCoreAudioVolume ফ্ল্যাগটি ব্যবহার করুন। যখন এই মানটি true হয়, তখন গাড়ির অডিও পরিষেবা ভলিউম গ্রুপগুলি পরিচালনা করার জন্য অডিও ম্যানেজার API ব্যবহার করে।

• CAP অডিও রাউটিং ম্যানেজমেন্ট সক্রিয় করতে useCoreAudioRouting ফ্ল্যাগটি ব্যবহার করুন। যখন এই মানটি true হয়, তখন গাড়ির অডিও পরিষেবাটি অডিও রাউটিং পরিচালনা করার জন্য কনফিগারযোগ্য অডিও পলিসি রাউটিং ব্যবহার করে।

অ্যান্ড্রয়েডে ডিফল্ট অডিও পলিসি ইঞ্জিন হিসেবেও এটি ডিফল্টরূপে সমর্থিত।

পটভূমি

CAP ইঞ্জিনটি ইন্টেলের প্যারামিটার ফ্রেমওয়ার্কের উপর ভিত্তি করে তৈরি, যা প্যারামিটার পরিচালনার জন্য একটি প্লাগইন-ভিত্তিক এবং নিয়ম-ভিত্তিক ফ্রেমওয়ার্ক। বিশেষ করে অ্যান্ড্রয়েড অডিও ব্যবস্থাপনার জন্য, CAP ইঞ্জিনটি নিম্নলিখিত বিষয়গুলো নির্দিষ্ট করতে XML ফাইলের নিয়ম সংজ্ঞায়িত করার ক্ষমতা চালু করেছে:

• অডিও পণ্য কৌশল
• অডিও আউটপুট ডিভাইস নির্বাচনের নিয়মাবলী
• অডিও ইনপুট ডিভাইস নির্বাচনের নিয়মাবলী
• ভলিউম টেবিলের সাথে ভলিউম এবং মিউট পরিচালনা করার নিয়মাবলী

অ্যান্ড্রয়েড ১৬ এর আগে CAP প্রারম্ভিকীকরণ

নিম্নলিখিত চিত্রে অ্যান্ড্রয়েড ৬ অনুযায়ী কনফিগারযোগ্য অডিও পলিসি ইঞ্জিন কনফিগারেশন ব্যবস্থাপনার একটি উচ্চ-স্তরের সংক্ষিপ্ত বিবরণ দেখানো হয়েছে:

চিত্র ১. অ্যান্ড্রয়েড ৬ অনুযায়ী CAP ইঞ্জিনের কনফিগারেশন ব্যবস্থাপনা।

চিত্রে যেমন দেখানো হয়েছে, অডিও পলিসি সার্ভিস vendor পার্টিশনে থাকা audio_policy_engine_configuration.xml ফাইল থেকে তথ্য পার্স করে CAP ইঞ্জিন কনফিগারেশন সংগ্রহ করে। CAP ইঞ্জিন কনফিগারেশন ফাইলটি প্রয়োজনীয় তথ্য পাওয়ার জন্য audio_policy_engine_configuration.xsd এ সংজ্ঞায়িত স্কিমা ব্যবহার করে। audio_policy_engine_configuration.xml হলো অটোমোটিভের জন্য একটি উদাহরণ। অন্যান্য ফর্ম ফ্যাক্টরের জন্য অনুরূপ উদাহরণ frameworks/av/services/audiopolicy/engineconfigurable/config/example/ ফোল্ডারে রয়েছে।

নিম্নলিখিত চিত্রটি দেখায় যে, অডিও পলিসি সার্ভিসের মধ্যে কীভাবে কনফিগারযোগ্য অডিও পলিসি ইঞ্জিনের তথ্য লোড করা হয়। এক্ষেত্রে, প্যারামিটার ফ্রেমওয়ার্কটি XML ফাইলগুলো থেকে কাঠামো এবং সেটিংস লোড করে।

চিত্র ২. অডিও পলিসি সার্ভিসের মধ্যে লোড করা CAP তথ্য।

অ্যান্ড্রয়েড ১৫ এবং তার নিচের সংস্করণগুলিতে CAP স্ট্রাকচার ফাইল

কাঠামো এবং সেটিংস পেতে, অডিও পলিসি সার্ভিসটি ParameterFrameworkConfigurationPolicy.xml ফাইলটি পড়ে। এটি স্ট্রাকচার ডেসক্রিপ্ট ফাইলের অবস্থানের মাধ্যমে কাঠামোগত তথ্য উল্লেখ করে:

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

এটি ফাইলের গঠনগত তথ্য নির্দেশ করে:

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

অ্যান্ড্রয়েডে একটি স্কেলেটন স্ট্রাকচার প্রদান করা আছে। এই স্ট্রাকচার তথ্যের জন্য প্রোডাক্ট স্ট্র্যাটেজি স্ট্রাকচার তথ্যের প্রয়োজন হয়, তাই অ্যান্ড্রয়েড ` buildStrategiesStructureFile.py জেনারেশন টুল সরবরাহ করে, যা উপলব্ধ প্রোডাক্ট স্ট্র্যাটেজি XML ফাইল থেকে তথ্য তৈরি করতে পারে। এটিকে `genrule default buildstrategiesstructurerule এর মাধ্যমে নিম্নোক্তভাবে রেফারেন্স করা যেতে পারে:

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

যেখানে audio_policy_engine_configuration_files হলো অডিও পলিসি ইঞ্জিন কনফিগারেশন ফাইলসমূহ। অটোমোটিভ-এর জন্য এই উদাহরণটি automotive ফোল্ডারে থাকা অডিও পলিসি কনফিগারেশন ফাইলগুলোকে রেফারেন্স করে। অন্যান্য উদাহরণে দেখানো হয়েছে কীভাবে ডিভাইসের ভেন্ডর পার্টিশনে ফাইলগুলো পুশ করার জন্য একটি বিল্ড কনফিগার করতে হয়।

অ্যান্ড্রয়েড ১৫ এবং তার নিচের সংস্করণগুলিতে CAP সেটিংস ফাইল

কাঠামোর মতোই, সেটিং তথ্য, যা প্যারামিটারগুলির নিয়ম এবং মান উপস্থাপন করে, ParameterFrameworkConfigurationPolicy.xml ফাইলে নিম্নরূপে উল্লেখ করা হয়:

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

অ্যান্ড্রয়েড অডিও পলিসি ইঞ্জিন কনফিগারেশন এবং প্যারামিটার ফ্রেমওয়ার্ক ফাইল ব্যবহার করে এই তথ্য তৈরি করার জন্য বিল্ড টুলও সরবরাহ করে। আরও তথ্যের জন্য কনফিগারেশন দেখুন।

AIDL অডিও HAL CAP প্রারম্ভিকীকরণ

অ্যান্ড্রয়েড ১৬ থেকে, AIDL অডিও HAL API-এর সংজ্ঞাটি AudioHalCapConfiguration.aidl নামক অডিও পলিসি ইঞ্জিন কনফিগারেশন দ্বারা সম্প্রসারিত করা হয়েছে। নিচের চিত্রটিতে অ্যান্ড্রয়েড ১৬ অনুযায়ী CAP ইঞ্জিন কনফিগারেশন ব্যবস্থাপনার একটি উচ্চ-স্তরের সংক্ষিপ্ত বিবরণ দেখানো হয়েছে:

চিত্র ৩. অ্যান্ড্রয়েড ১৬ অনুযায়ী CAP ইঞ্জিন কনফিগারেশন ব্যবস্থাপনা।

অডিও পলিসি সার্ভিসটি ডিভাইসের ভেন্ডর পার্টিশনে থাকা XML ফাইল থেকে তথ্য পার্স করার পরিবর্তে সরাসরি AIDL Audio HAL API ব্যবহার করে CAP ইঞ্জিনের তথ্য সংগ্রহ করে।

এই কনফিগারেশনে, প্যারামিটার ফ্রেমওয়ার্কের কাঠামোটি এখনও অডিও সার্ভার প্রান্তে CAP ইঞ্জিন দ্বারা লোড করা হয়।

চিত্র ৪. সিএপি ইঞ্জিনের গঠন।

সকল ক্ষেত্রে, কনফিগারেশনে অবশ্যই পণ্য কৌশল, ভলিউম গ্রুপ এবং মানদণ্ড সম্পর্কিত তথ্য সম্পূর্ণরূপে নির্দিষ্ট করতে হবে।

নিম্নলিখিত চিত্রে AIDL অডিও HAL API-গুলির একটি উচ্চ-স্তরের সংক্ষিপ্ত বিবরণ দেখানো হয়েছে, যেগুলি অডিও পলিসি পরিষেবা CAP ইঞ্জিন কনফিগারেশন পেতে ব্যবহার করে:

চিত্র ৫. AIDL অডিও HAL API-সমূহ।

এই সেটআপে, অডিও পলিসি সার্ভিসটি AIDL অডিও HAL থেকে নিম্নলিখিত তথ্যগুলো সংগ্রহ করে:

• কনফিগারেশন
• কৌশল
• ভলিউম
• মানদণ্ড
• সেটিংস

ডিফল্ট AIDL অডিও HAL লোডার

HIDL থেকে AIDL-এ রূপান্তর সহজ করার জন্য, ডিফল্ট AIDL অডিও HAL একটি XML CAP ইঞ্জিন লোডার প্রদান করে। ভেন্ডররা ডিফল্ট অডিও HAL দিয়ে তাদের অডিও HAL এক্সটেন্ড করে অথবা libaudioserviceexampleimpl লাইব্রেরি রেফারেন্স করে সরাসরি এই লোডারটি ব্যবহার করতে পারেন।

ডিফল্ট AIDL অডিও HAL লোডার নিম্নলিখিত তথ্যগুলো সংগ্রহ করার জন্য audio_policy_engine_configuration.xml ব্যবহার করে:

• কনফিগারেশন
• কৌশল
• ভলিউম
• মানদণ্ড

কাঠামোগত তথ্য PolicyConfigurableDomains.xml ফাইল থেকে সংগ্রহ করা হয়। পূর্ববর্তী পদ্ধতির সাথে মূল পার্থক্য হলো, অডিও পলিসি সার্ভিসের প্যারামিটার ফ্রেমওয়ার্কের পরিবর্তে AIDL অডিও HAL-এর মাধ্যমেও কাঠামোগত তথ্য সংগ্রহ করা হয়।

বিক্রেতারা অডিও পলিসি ইঞ্জিন কনফিগারেশনের তথ্য ব্যবহার করে কনফিগারযোগ্য ডোমেইনগুলো তৈরি করতে domaingeneratorpolicyrule টুলটি ব্যবহার করতে পারেন। এক্ষেত্রে অটোমোটিভ কাটলফিশ ভার্চুয়াল ডিভাইসের উদাহরণটি রেফারেন্স হিসেবে ব্যবহার করা যেতে পারে।

AIDL কনফিগারেশনে কাঠামো

অ্যান্ড্রয়েড ১৬ এবং তার পরবর্তী সংস্করণগুলিতে, অডিও পলিসি সার্ভিস 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 ইঞ্জিন কনফিগে প্যারামিটারগুলোর জন্য একটি পূর্বনির্ধারিত নাম ব্যবহার করা উচিত। প্রোডাক্ট স্ট্র্যাটেজিগুলোর জন্য, কাঠামোটি 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 প্রোডাক্ট স্ট্র্যাটেজি ফাইলটি vx_1000 থেকে vx_1039 পর্যন্ত ৪০টি ভেন্ডর এক্সটেন্ডেবল প্রোডাক্ট স্ট্র্যাটেজিও প্রদান করে। সমস্ত ভেন্ডর এক্সটেনশন অবশ্যই vx_ প্রিফিক্স দিয়ে শুরু হতে হবে এবং এর পরে একটি সংখ্যা থাকতে হবে, যা AIDL অডিও HAL প্রোডাক্ট স্ট্র্যাটেজি সংজ্ঞায় প্রোডাক্ট স্ট্র্যাটেজি আইডি-কে প্রতিনিধিত্ব করে। বাকি সংজ্ঞাগুলো (উদাহরণস্বরূপ, অডিও অ্যাট্রিবিউট গ্রুপ, নাম) অডিও HAL ইঞ্জিন কনফিগারেশনে থাকা AudioHALProductStrategy অবজেক্ট থেকে পাওয়া যায়।

ডিফল্ট প্রোডাক্ট স্ট্র্যাটেজিগুলোর মতোই, ভেন্ডর দ্বারা সংজ্ঞায়িত OEM রেফারেন্সগুলোও নন-AIDL কনফিগারেশন এবং AIDL কনফিগারেশনের মধ্যে অভিযোজিত করতে হবে, উদাহরণস্বরূপ:

পণ্য কৌশল

প্রোডাক্ট স্ট্র্যাটেজি অডিও স্ট্রিমগুলোকে কীভাবে শ্রেণিবদ্ধ ও গ্রুপ করা হবে, তা কাস্টমাইজ করার একটি উপায় প্রদান করে। এর ফলে অডিও ডিভাইস কনফিগার করার ক্ষেত্রে আরও বেশি নমনীয়তা পাওয়া যায়, যার মধ্যে রয়েছে ডিভাইসগুলো কীভাবে রাউট করা হবে এবং সেগুলোর ভলিউম কীভাবে পরিচালনা করা হবে। প্রতিটি প্রোডাক্ট স্ট্র্যাটেজির এক বা একাধিক অডিও অ্যাট্রিবিউট গ্রুপ থাকতে পারে, যা সেইসব স্ট্রিমকে শনাক্ত করে যেগুলো ওই প্রোডাক্ট স্ট্র্যাটেজির সাথে যুক্ত হওয়া উচিত। এই অডিও অ্যাট্রিবিউট গ্রুপগুলো অডিওকে শ্রেণিবদ্ধ করার জন্য আরও সূক্ষ্ম একটি পদ্ধতি প্রদান করে এবং এগুলো নিম্নলিখিত প্রকারগুলোর মিশ্রণ হতে পারে:

• ব্যবহারের ধরণগুলো বর্ণনা করে কেন একটি শব্দ বাজানো হচ্ছে (যেমন, মিডিয়া, নোটিফিকেশন, কল)।
• কন্টেন্ট টাইপ বর্ণনা করে কী বাজানো হচ্ছে (যেমন, সঙ্গীত, বক্তৃতা, ভিডিও, সনিফিকেশন)।
• ফ্ল্যাগ টাইপগুলো স্ট্রিমের সাপেক্ষে বিভিন্ন আচরণ বা অনুরোধ নির্ধারণ করে।
• ট্যাগ টাইপগুলো ভেন্ডর স্ট্রিং ভ্যালুর যেকোনো যথেচ্ছ তালিকা সমর্থন করে।
  • প্রতিটি স্ট্রিং অবশ্যই 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 অডিও কনটেক্সটের সাথে মেলে, কিন্তু এই ধরনের মিল থাকার কোনো বাধ্যবাধকতা নেই। অ্যান্ড্রয়েডের সাথে 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 ইঞ্জিনে, অডিওর আচরণ কেমন হবে তা নির্ধারণকারী শর্ত বা নিয়মগুলো সংজ্ঞায়িত করতে কনফিগারেশন ব্যবহার করা হয়। অডিও সিস্টেমের বর্তমান অবস্থার উপর নির্ভর করে প্রয়োগ করার জন্য উপযুক্ত নিয়মগুলো নির্বাচন করতে এই কনফিগারেশনগুলো রান টাইমে মূল্যায়ন করা হয়।

চিত্র ৫-এ যেমন দেখানো হয়েছে, এপিআই-টিতে একাধিক ডোমেইন রয়েছে, প্রতিটি ডোমেইনের লক্ষ্য হলো লজিককে ছোট ছোট রাউটিং সমস্যায় বিভক্ত করে সমাধান করা (উদাহরণস্বরূপ, ডিভাইস ১, ডিভাইস ২)।

প্রতিটি ডোমেইনের কনফিগারেশন থাকে এবং প্রতিটি কনফিগারেশনের কিছু নিয়ম থাকে। AudioPolicyManager কর্তৃক প্রদত্ত মানদণ্ডের উপর ভিত্তি করে নিয়মগুলো প্রতিষ্ঠিত হয়।

• অডিও মোড
• উপলব্ধ ইনপুট এবং আউটপুট ডিভাইস
• উপলব্ধ ইনপুট এবং আউটপুট ডিভাইস ঠিকানা
• ব্যবহারের জন্য
  • মিডিয়া
  • যোগাযোগ
  • রেকর্ডিং
  • ডক
  • সিস্টেম
  • এইচডিএমআই সিস্টেম অডিও
  • এনকোডেড সারাউন্ড
  • কম্পন রিং

প্রতিটি ডোমেইনে এমন কনফিগারেশন থাকে যা আচরণকে প্রভাবিত করবে এমন নিয়মগুলো নির্ধারণ করে। মনে রাখবেন যে কনফিগারেশনের ক্রম গুরুত্বপূর্ণ এবং কনফিগারেশনগুলো প্রয়োজনীয় ক্রমে আছে কিনা তা নিশ্চিত করা জরুরি। কোনো কনফিগারেশনের নিয়মগুলো যাচাই করার পর, কনফিগারেশনটি নির্বাচিত হয়।

নিম্নলিখিত কোডটি একটি প্যারামিটার ফ্রেমওয়ার্ক ফাইলের নির্বাচিত উদাহরণ দেখাচ্ছে, যা কনফিগারযোগ্য ডোমেইনগুলো কনফিগার করার জন্য প্রয়োজনীয় 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 ডোমেইনটি নির্ধারণ করে যে প্রোডাক্ট স্ট্র্যাটেজি ডিভাইস সিলেকশন পরিচালনা করার সময় বিভিন্ন নিয়ম কীভাবে প্রয়োগ করা উচিত। নীল অংশগুলো সেই নিয়মগুলো বর্ণনা করে যা বিবেচনা করা উচিত এবং সবুজ অংশটি হলো প্রয়োগ করা কনফিগারেশন। এই নির্দিষ্ট উদাহরণটিতে নিম্নলিখিত কনফিগারেশনগুলো রয়েছে:

• মিউজিক প্রোডাক্ট স্ট্র্যাটেজির (ID 1000, vx_1000 ) জন্য ব্লুটুথ A2DP ডিভাইস নির্বাচন করুন
  • মিডিয়ার জন্য ব্যবহার করা হলে, A2DP বাদ দেওয়া হয় না।
  • যোগাযোগের জন্য ব্যবহার করা হলে, বিটি এসসিও কি নয়?
  • ডিভাইস উপলব্ধ থাকলে, BT A2DP অন্তর্ভুক্ত করুন।
• বাস ডিভাইস নির্বাচন করুন
  • যদি বাস ডিভাইস উপলব্ধ থাকে
  • যদি ঠিকানা BUS00_MEDIA হয়
• অন্যথায় ডিফল্ট আউটপুট ডিভাইস নির্বাচন করুন

সংশ্লিষ্ট কনফিগারযোগ্য পলিসি ইঞ্জিন XML ফাইলটি তৈরি করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করে একটি বিল্ড রুল নির্ধারণ করার মাধ্যমে প্যারামিটার-ফ্রেমওয়ার্ক (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>

CAP ডিবাগিং

আপনি remote-process ব্যবহার করে CAP কনফিগারেশনগুলো ডাম্প করতে পারেন:

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

এটি প্রযোজ্যতার শর্তাবলী সহ সমস্ত ডোমেইন এবং কনফিগারেশন দেখায়। নিম্নলিখিত অংশে ব্লুটুথ 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

অ্যান্ড্রয়েড ১৫ এবং এর নিচের সংস্করণগুলোতে ফাইলটি ভিন্ন হতে পারে, তাই নিম্নলিখিত কমান্ডটি ব্যবহার করুন:

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 বা build ফাইলে remote-process টুলটিও অবশ্যই অন্তর্ভুক্ত থাকতে হবে:

# 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 মাইগ্রেশন

AIDL অডিও HAL CAP ইঞ্জিন এবং এর পূর্ববর্তী সংস্করণগুলোর আনা বড় ধরনের পরিবর্তনের পরিপ্রেক্ষিতে, বিভিন্ন ডিভাইস ট্রানজিশন সিনারিও রয়েছে যা আপনার বিবেচনা করা উচিত। এই বিভাগে সবচেয়ে উল্লেখযোগ্য ট্রানজিশন সিনারিওগুলো আলোচনা করা হয়েছে এবং CAP ইঞ্জিন কনফিগারেশন সক্রিয় করার কাজের জন্য সুপারিশ দেওয়া হয়েছে।

দৃশ্যকল্প ১: অ্যান্ড্রয়েড ১৬ বা তার উচ্চতর সংস্করণ ব্যবহৃত নতুন ডিভাইস, ডিভাইসটির CAP কনফিগারেশনের জন্য কোনো পূর্ববর্তী উৎস নেই

একটি নতুন ডিভাইসকে অবশ্যই vendor পার্টিশনে অ্যান্ড্রয়েড ১৬ বা তার উচ্চতর কোড দিয়ে চালু করতে হবে। এর মানে হলো, এটিকে অবশ্যই AIDL অডিও HAL ইন্টারফেসের মাধ্যমে কনফিগারযোগ্য অডিও পলিসি ইঞ্জিন কনফিগারেশন প্রকাশ করতে হবে। ডিভাইসের CAP ইঞ্জিন কনফিগারেশন উদাহরণগুলো থেকে কপি করতে হবে। vendor পার্টিশনে কোনো PfW CAP ডোমেইন ডেফিনিশন থাকা উচিত নয়।

ডিভাইসটির জন্য ব্যবহৃত সিস্টেম ইমেজটি অ্যান্ড্রয়েড ১৬ বা তার উচ্চতর সংস্করণ। অডিও সার্ভিস ফ্রেমওয়ার্কটি AIDL অডিও HAL ইন্টারফেসের মাধ্যমে CAP কনফিগারেশনটি খুঁজে বের করে, তাই এটি সিস্টেম ইমেজ থেকে PfW CAP ডোমেইন ডেফিনিশন ব্যবহার করে PfW ইনিশিয়ালাইজ করে এবং AIDL-এর মাধ্যমে প্রাপ্ত ডিভাইস CAP কনফিগারেশনটি লোড করে।

উদাহরণস্বরূপ, অটোমোটিভ কাটলফিশ ভার্চুয়াল ডিভাইসটি দেখুন, যা এই পরিবর্তনের সাথে চালু করা হয়েছে এবং প্রয়োজনীয় কনফিগারেশন ফাইলগুলো সেট আপ করার জন্য প্রয়োজনীয় ফাইল, বিল্ড রুল এবং মেক ফাইলের জন্য এটিকে রেফারেন্স হিসেবে ব্যবহার করা যেতে পারে। এটি ডিফল্ট AIDL অডিও HAL- এ প্রদত্ত লোডারগুলোর সাথে কাজ করে।

দৃশ্যকল্প ২: পূর্ববর্তী CAP ব্যবহৃত ডিভাইস থেকে নতুন ডিভাইসে Android 16 বা তার উচ্চতর সংস্করণ ব্যবহার।

একটি নতুন ডিভাইসকে vendor পার্টিশনে অ্যান্ড্রয়েড ১৬ বা তার উচ্চতর কোড দিয়ে চালু করতে হবে। তবে, যেহেতু OEM-এর কাছে একটি ব্যবহারযোগ্য ডিভাইস CAP ইঞ্জিন কনফিগারেশন থাকে, তাই OEM সেটিকে একটি সূচনা বিন্দু হিসেবে ব্যবহার করতে (বা সম্পূর্ণরূপে পুনরায় ব্যবহার করতে) চাইবে। CAP কনফিগারেশনের AIDL সংস্করণে অ্যান্ড্রয়েড ১৫ এবং তার নিম্নতর সংস্করণের তুলনায় কিছু পরিবর্তন রয়েছে, তাই ভেন্ডরকে অবশ্যই বিদ্যমান কনফিগারেশনটিকে AIDL-এ রূপান্তর করতে হবে। প্রয়োজনীয় পরিবর্তনগুলোর জন্য অ্যান্ড্রয়েড ১৬ এবং তার নিম্নতর সংস্করণগুলোর মধ্যে পরিবর্তন সংক্রান্ত প্রোডাক্ট স্ট্র্যাটেজিস- এর আলোচনা দেখুন। সাধারণভাবে, অডিও ফ্রেমওয়ার্ক সিনারিও ১-এর মতোই CAP কনফিগারেশনটি খুঁজে বের করে এবং লোড করে।

দৃশ্যকল্প ৩: CAP সহ বিদ্যমান ডিভাইসটির শুধুমাত্র সিস্টেম পার্টিশন অ্যান্ড্রয়েড ১৬-এ আপডেট করা হচ্ছে

এই ক্ষেত্রে, vendor পার্টিশনে অ্যান্ড্রয়েড ১৫ ও তার নিম্ন সংস্করণের ডিভাইসের CAP কনফিগারেশন এবং PfW CAP ডোমেইন ডেফিনিশন থাকে। vendor পার্টিশনটি অপরিবর্তিত থাকে, তাই এটি এখনও HIDL HAL ব্যবহার করে। ফ্রেমওয়ার্কটি অ্যান্ড্রয়েড ১৫ ও তার নিম্ন সংস্করণের সিনারিও অনুসরণ করে এবং vendor পার্টিশন থেকে CAP সম্পর্কিত সমস্ত কনফিগারেশন লোড করে।

দৃশ্যকল্প ৪: বিদ্যমান ডিভাইসটি CAP সহ Android 15-এ রিলিজ করা হয়েছে

অ্যান্ড্রয়েড ১৫-এ AIDL-এ CAP সমর্থিত ছিল না, তাই কিছু ভেন্ডর AIDL Audio HAL এবং CAP সহ নতুন ডিভাইস প্রকাশ করেছিল, যা অডিও ফ্রেমওয়ার্ক দ্বারা লোড করা হতো। এই হাইব্রিড মোডটি অনানুষ্ঠানিক ছিল, কিন্তু অ্যান্ড্রয়েড ১৬-এ এটি অন্তর্ভুক্ত করা হয়েছে। মনে রাখবেন যে, অ্যান্ড্রয়েড ১৬-এ নতুন ডিভাইস প্রকাশের জন্য এই মোডটি ব্যবহার করা উচিত নয়, বরং অ্যান্ড্রয়েড ১৫ ভেন্ডরের বিদ্যমান ডিভাইসগুলোকে অ্যান্ড্রয়েড ১৬-এ আপডেট ( system পার্টিশন আপডেট) করার জন্য এটি ব্যবহার করতে হবে।

অডিও ফ্রেমওয়ার্কটি CAP কনফিগারেশন ছাড়াই AIDL অডিও HAL অডিও কনফিগারেশনটি খুঁজে বের করে। CAP কনফিগারেশনের জন্য, অডিও পলিসি সার্ভিস (অডিও ফ্রেমওয়ার্ক) vendor পার্টিশন থেকে CAP কনফিগারেশন লোড করার জন্য ফিরে যায়। এই ক্ষেত্রে, PfW CAP ডোমেইন ডেফিনিশন এবং ডিভাইস CAP কনফিগারেশন উভয়ই vendor পার্টিশন থেকে লোড করতে হবে।

CAP মাইগ্রেশন সারাংশ

নিম্নলিখিত সারণিতে CAP কনফিগারেশনের সাথে সামঞ্জস্যপূর্ণ সিস্টেম ও ভেন্ডর কনফিগারেশন এবং প্রয়োজনীয়তাগুলোর সারসংক্ষেপ দেওয়া হলো: