از سال ۲۰۲۶، برای همسو شدن با مدل توسعه پایدار ترانک و تضمین پایداری پلتفرم برای اکوسیستم، کد منبع را در سه‌ماهه دوم و چهارم در AOSP منتشر خواهیم کرد. برای ساخت و مشارکت در AOSP، android-latest-release استفاده کنید. شاخه مانیفست android-latest-release همیشه به جدیدترین نسخه منتشر شده در AOSP ارجاع می‌دهد. برای اطلاعات بیشتر، به تغییرات در AOSP مراجعه کنید.

این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

موتور سیاست صوتی قابل تنظیم

در اندروید ۱۴، سیستم عامل اندروید اتوموبیل (AAOS) از مدیریت صدای خودرو با موتور CAP (سیاست صوتی قابل تنظیم) در منطقه صوتی اصلی بهره می‌برد. به طور خاص، موتور CAP به AAOS اجازه می‌دهد تا فقط مسیریابی صدا، فقط میزان صدا یا مسیریابی و میزان صدا را به طور همزمان کنترل کند. از پرچم‌های زیر می‌توان برای کنترل رفتار استفاده کرد:

از پرچم useCoreAudioVolume برای فعال کردن مدیریت حجم CAP استفاده کنید. وقتی این مقدار true باشد، سرویس صوتی خودرو از APIهای مدیریت صدا برای مدیریت گروه‌های حجم استفاده می‌کند.
از پرچم useCoreAudioRouting برای فعال کردن مدیریت مسیریابی صوتی CAP استفاده کنید. وقتی این مقدار true باشد، سرویس صوتی خودرو از مسیریابی سیاست صوتی قابل تنظیم برای مدیریت مسیریابی صوتی استفاده می‌کند.

موتور سیاست صوتی همچنین به طور پیش‌فرض در اندروید در قالب موتور سیاست صوتی پیش‌فرض پشتیبانی می‌شود.

پیشینه

موتور CAP مبتنی بر چارچوب پارامتر اینتل است که یک چارچوب مبتنی بر افزونه و مبتنی بر قانون برای مدیریت پارامترها است. به طور خاص برای مدیریت صدای اندروید، موتور CAP قابلیت تعریف قوانین فایل‌های XML را برای مشخص کردن موارد زیر معرفی کرد:

استراتژی محصول صوتی
قوانین انتخاب دستگاه خروجی صدا
قوانین انتخاب دستگاه ورودی صدا
قوانینی برای مدیریت صدا و قطع صدا به همراه جداول صدا

مقداردهی اولیه CAP قبل از اندروید ۱۶

شکل زیر نمای کلی سطح بالایی از مدیریت پیکربندی موتور سیاست صوتی قابل تنظیم را از اندروید ۶ نشان می‌دهد:

معماری موتور CAP قبل از اندروید ۱۶

شکل ۱. مدیریت پیکربندی موتور CAP از اندروید ۶.

همانطور که در شکل نشان داده شده است، پیکربندی موتور CAP توسط سرویس سیاست صوتی با تجزیه اطلاعات از فایل audio_policy_engine_configuration.xml در پارتیشن vendor به دست می‌آید. فایل پیکربندی موتور CAP از طرحواره تعریف شده در audio_policy_engine_configuration.xsd برای دریافت اطلاعات مورد نیاز استفاده می‌کند. audio_policy_engine_configuration.xml مثالی برای خودرو است. مثال‌های مشابه برای سایر عوامل فرم در پوشه frameworks/av/services/audiopolicy/engineconfigurable/config/example/ قرار دارند.

شکل زیر، اطلاعات دقیق‌تری در مورد نحوه‌ی بارگذاری اطلاعات موتور سیاست صوتی قابل تنظیم در سرویس سیاست صوتی نشان می‌دهد. در این حالت، چارچوب پارامتر، ساختار و تنظیمات را از فایل‌های XML بارگذاری می‌کند.

مسیر بارگذاری موتور CAP قبل از اندروید ۱۶

شکل ۲. اطلاعات CAP بارگذاری شده در سرویس سیاست صوتی.

فایل‌های ساختار CAP در اندروید ۱۵ و پایین‌تر

برای به دست آوردن ساختار و تنظیمات، سرویس سیاست صوتی فایل ParameterFrameworkConfigurationPolicy.xml را می‌خواند. این فایل از طریق موقعیت فایل توصیف ساختار، به اطلاعات ساختار ارجاع می‌دهد:

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

این به اطلاعات ساختاری در فایل اشاره دارد:

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

یک ساختار اسکلتی در اندروید ارائه شده است. اطلاعات ساختار به اطلاعات ساختار استراتژی محصول نیاز دارد، بنابراین اندروید ابزار تولید buildStrategiesStructureFile.py را ارائه می‌دهد که می‌تواند اطلاعات را از فایل XML استراتژی محصول موجود تولید کند. این اطلاعات را می‌توان از طریق genrule پیش‌فرض buildstrategiesstructurerule به صورت زیر ارجاع داد:

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

که در آن audio_policy_engine_configuration_files فایل‌های پیکربندی موتور سیاست صوتی است. این مثال برای automotive به فایل‌های پیکربندی سیاست صوتی در پوشه automotive اشاره دارد. مثال‌های دیگر نحوه پیکربندی یک build را برای ارسال فایل‌ها به پارتیشن vendor دستگاه نشان می‌دهند.

فایل‌های تنظیمات CAP در اندروید ۱۵ و پایین‌تر

مشابه ساختار، اطلاعات تنظیمات، که نشان دهنده قوانین و مقادیر پارامترها است، در فایل ParameterFrameworkConfigurationPolicy.xml به صورت زیر ارجاع داده می‌شود:

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

اندروید همچنین ابزارهای ساختی را برای تولید این اطلاعات با استفاده از پیکربندی موتور سیاست صوتی و فایل‌های چارچوب پارامتر ارائه می‌دهد. برای اطلاعات بیشتر به بخش پیکربندی‌ها مراجعه کنید.

مقداردهی اولیه HAL CAP صوتی AIDL

از اندروید ۱۶ به بعد، تعریف AIDL Audio HAL API با پیکربندی‌های موتور سیاست صوتی، AudioHalCapConfiguration.aidl ، گسترش یافته است. شکل زیر نمای کلی سطح بالایی از مدیریت پیکربندی موتور CAP را از اندروید ۱۶ نشان می‌دهد:

معماری کمکی موتور CAP

شکل ۳. مدیریت پیکربندی موتور CAP از اندروید ۱۶.

سرویس سیاست صوتی، اطلاعات موتور CAP را مستقیماً با استفاده از APIهای AIDL Audio HAL به دست می‌آورد، به جای اینکه اطلاعات را از فایل‌های XML موجود در پارتیشن فروشنده دستگاه تجزیه کند.

در این پیکربندی، ساختار چارچوب پارامتر همچنان توسط موتور CAP در سمت سرور صوتی بارگذاری می‌شود.

مسیر بار کمکی موتور CAP

شکل ۴. ساختار موتور CAP.

در تمام موارد، پیکربندی باید اطلاعات مربوط به استراتژی‌های محصول، گروه‌های حجمی و معیارها را به طور کامل مشخص کند.

شکل زیر یک نمای کلی سطح بالا از APIهای HAL صوتی AIDL را نشان می‌دهد که توسط سرویس سیاست صوتی برای به دست آوردن پیکربندی موتور CAP استفاده می‌شوند:

رابط‌های برنامه‌نویسی AIDL موتور CAP شکل 5. رابط‌های برنامه‌نویسی کاربردی HAL صوتی AIDL.

در این تنظیمات، سرویس سیاست صوتی اطلاعات زیر را از HAL صوتی AIDL دریافت می‌کند:

پیکربندی
استراتژی‌ها
جلدها
معیارها
تنظیمات

لودر پیش‌فرض AIDL Audio HAL

برای روان‌تر کردن انتقال از HIDL به AIDL، فایل صوتی پیش‌فرض AIDL Audio HAL یک بارگذار موتور XML CAP ارائه می‌دهد. فروشندگان می‌توانند با گسترش فایل صوتی HAL خود با فایل صوتی پیش‌فرض HAL یا ارجاع به کتابخانه libaudioserviceexampleimpl ، مستقیماً از این بارگذار استفاده کنند.

لودر پیش‌فرض HAL audio در AIDL از audio_policy_engine_configuration.xml برای دریافت اطلاعات زیر استفاده می‌کند:

پیکربندی
استراتژی‌ها
جلدها
معیارها

اطلاعات ساختار از فایل PolicyConfigurableDomains.xml به دست می‌آید. تفاوت کلیدی با مکانیزم قبلی این است که اطلاعات ساختار نیز به جای چارچوب پارامتر در سرویس سیاست صوتی، توسط AIDL audio HAL به دست می‌آید.

فروشندگان می‌توانند از ابزار domaingeneratorpolicyrule برای تولید دامنه‌های قابل پیکربندی با استفاده از اطلاعات پیکربندی موتور سیاست صوتی استفاده کنند. مثال دستگاه مجازی Cuttlefish خودرو می‌تواند به عنوان مرجع استفاده شود.

ساختار در پیکربندی 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) که برای پیکربندی موتور استفاده می‌شوند، دارد. به طور خاص، تمام مراجع استراتژی محصول باید برای استفاده از نام‌های جدید تغییر کنند، به عنوان مثال :

نام پارامتر پیکربندی غیر AIDL
`/Policy/policy/product_strategies/ media /device_address` `/Policy/policy/product_strategies/ media /selected_output_devices/mask`

نام پارامتر پیکربندی AIDL
`/Policy/policy/product_strategies/ STRATEGY_MEDIA /device_address` `/Policy/policy/product_strategies/ STRATEGY_MEDIA /selected_output_devices/mask`

استراتژی‌های محصول تعریف‌شده توسط تولیدکننده اصلی (OEM)

موتور قابل پیکربندی، امکان تغییر تعریف استراتژی‌های محصول را برای تولیدکنندگان اصلی تجهیزات (OEM) فراهم می‌کند. برای ادامه پشتیبانی از این قابلیت، فایل استراتژی محصول CapProductStrategies.xml همچنین ۴۰ استراتژی محصول قابل توسعه توسط فروشنده از vx_1000 تا vx_1039 را ارائه می‌دهد. همه افزونه‌های فروشنده باید با پیشوند vx_ شروع شوند و پس از آن عددی قرار گیرد که نشان دهنده شناسه استراتژی محصول در تعریف استراتژی محصول AIDL audio HAL است. بقیه تعاریف (به عنوان مثال، گروه‌های ویژگی صوتی، نام) از شیء AudioHALProductStrategy در پیکربندی موتور صوتی HAL به دست می‌آیند.

مشابه استراتژی‌های پیش‌فرض محصول، مراجع OEM تعریف‌شده توسط فروشنده نیز باید بین پیکربندی غیر AIDL و پیکربندی AIDL تطبیق داده شوند، برای مثال:

نام پارامتر پیکربندی غیر AIDL
`/Policy/policy/product_strategies/ oem_extension_strategy /device_address` `/Policy/policy/product_strategies/ oem_extension_strategy /selected_output_devices/mask`

نام پارامتر پیکربندی AIDL
`/Policy/policy/product_strategies/ vx_1037 /device_address` `/Policy/policy/product_strategies/ vx_1037 /selected_output_devices/mask`

استراتژی‌های محصول

استراتژی‌های محصول راهی برای سفارشی‌سازی نحوه طبقه‌بندی و گروه‌بندی جریان‌های صوتی ارائه می‌دهند. این امر انعطاف‌پذیری بیشتری را در پیکربندی دستگاه‌های صوتی، از جمله نحوه مسیریابی و نحوه مدیریت حجم صدای آنها، فراهم می‌کند. هر استراتژی محصول می‌تواند یک یا چند گروه ویژگی صوتی داشته باشد که جریان‌هایی را که باید با آن استراتژی محصول مرتبط باشند، شناسایی می‌کنند. این گروه‌های ویژگی صوتی، رویکردی جزئی‌تر برای دسته‌بندی صدا ارائه می‌دهند و می‌توانند ترکیبی از انواع زیر باشند:

انواع استفاده توضیح می‌دهند که چرا یک صدا پخش می‌شود (یعنی رسانه، اعلان، تماس).
انواع نوع محتوا ، آنچه را که پخش می‌شود (یعنی موسیقی، گفتار، ویدئو، صوت‌سازی) توصیف می‌کنند.
انواع پرچم، رفتار یا درخواست‌های متفاوتی را در رابطه با جریان تعریف می‌کنند.
انواع برچسب‌ها از هر لیست دلخواهی از مقادیر رشته‌ای فروشنده پشتیبانی می‌کنند.
- هر رشته باید با 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 مورد استفاده در سرویس صوتی خودرو مطابقت دارد، اما نیازی به چنین تطابقی نیست. یکی از کاربردهای اصلی برای تولیدکنندگان اصلی تجهیزات (OEM) که از 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، از پیکربندی‌ها برای تعریف شرایط یا قوانینی استفاده می‌شود که نحوه رفتار صدا را تعیین می‌کنند. این پیکربندی‌ها در زمان اجرا ارزیابی می‌شوند تا قوانین مناسب برای اعمال بسته به وضعیت فعلی سیستم صوتی انتخاب شوند.

همانطور که در شکل ۵ نشان داده شده است، API شامل چندین دامنه است که هدف هر دامنه، تقسیم منطق به مسائل مسیریابی کوچکتر برای حل کردن است (برای مثال، دستگاه ۱، دستگاه ۲).

هر دامنه دارای پیکربندی‌هایی است و هر پیکربندی مجموعه‌ای از قوانین دارد. قوانین بر اساس معیارهایی که توسط 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 نحوه اعمال قوانین مختلف هنگام مدیریت استراتژی‌های محصول، انتخاب دستگاه را تعریف می‌کند. قسمت‌های آبی قوانینی را که باید در نظر گرفته شوند شرح می‌دهند و قسمت سبز پیکربندی اعمال شده است. این مثال خاص شامل پیکربندی‌های زیر است:

دستگاه بلوتوث A2DP را برای استراتژی محصول موسیقی انتخاب کنید (ID 1000، vx_1000 )
- اگر برای رسانه استفاده شود، A2DP را حذف نمی‌کند
- اگر برای ارتباط استفاده می‌شود، آیا BT SCO نیست؟
- در صورت وجود دستگاه، بلوتوث و A2DP را نیز فعال کنید
دستگاه اتوبوس را انتخاب کنید
- اگر دستگاه‌های باس در دسترس باشند
- اگر آدرس BUS00_MEDIA باشد
در غیر این صورت، دستگاه خروجی پیش‌فرض را انتخاب کنید

برای تولید فایل XML موتور سیاست قابل تنظیم مربوطه، فایل‌های parameter-frame (PFW) را از طریق سیستم ساخت ، با تعریف یک قانون ساخت با استفاده از مراحل زیر، اجرا کنید:

در فایل Android.bp ، یک گروه فایل برای فایل ایجاد کنید:

filegroup {
    name: ":device_for_product_strategies.pfw",
    srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
}

فایل را به سایر فایل‌های PfW (در صورت وجود) اضافه کنید.

filegroup {
    name: "edd_files",
    srcs: [
        ":device_for_input_source.pfw",
        ":volumes.pfw",
        ":device_for_product_strategyies.pfw",
    ],
}

قانون تولید دامنه مربوطه را ایجاد کنید:

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 با استفاده از بلوتوث 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 به آن ارجاع داده می‌شود. ابزار 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 audio HAL CAP و نسخه‌های قبلی ایجاد کرده‌اند، سناریوهای مختلفی برای گذار دستگاه وجود دارد که باید در نظر بگیرید. این بخش برجسته‌ترین سناریوهای گذار را پوشش می‌دهد و توصیه‌هایی برای فعال‌سازی پیکربندی موتور CAP ارائه می‌دهد.

سناریو ۱: دستگاه جدید با اندروید ۱۶ یا بالاتر، بدون منبع قبلی برای پیکربندی CAP دستگاه

یک دستگاه جدید باید با کد اندروید ۱۶ یا بالاتر در پارتیشن vendor راه‌اندازی شود. این بدان معناست که باید پیکربندی موتور سیاست صوتی قابل تنظیم را از طریق رابط صوتی AIDL HAL در معرض نمایش قرار دهد. پیکربندی موتور CAP دستگاه باید از مثال‌ها کپی شود. نباید تعریف دامنه PfW CAP در پارتیشن vendor وجود داشته باشد.

ایمیج سیستم مورد استفاده برای دستگاه، اندروید ۱۶ یا بالاتر است. چارچوب سرویس صوتی، پیکربندی CAP را از طریق رابط صوتی HAL مربوط به AIDL کشف می‌کند، بنابراین PfW را با استفاده از تعریف دامنه PfW CAP از ایمیج سیستم، مقداردهی اولیه می‌کند و پیکربندی CAP دستگاه را که از طریق AIDL دریافت شده است، بارگذاری می‌کند.

برای مثال، به دستگاه مجازی Cuttlefish خودرو مراجعه کنید که در این تغییر معرفی شده است و می‌تواند برای فایل‌های مورد نیاز، قوانین ساخت و فایل‌های ساخت مورد نیاز برای تنظیم فایل‌های پیکربندی مورد نیاز، مورد ارجاع قرار گیرد. این با لودرهای ارائه شده در AIDL audio HAL پیش‌فرض کار می‌کند.

سناریو ۲: دستگاه جدید با اندروید ۱۶ یا بالاتر، از دستگاه قبلی با CAP

یک دستگاه جدید باید با کد اندروید ۱۶ یا بالاتر در پارتیشن vendor راه‌اندازی شود. با این حال، از آنجا که سازنده اصلی (OEM) پیکربندی موتور CAP دستگاه قابل استفاده‌ای دارد، سازنده اصلی (OEM) می‌خواهد از آن به عنوان نقطه شروع استفاده کند (یا آن را به طور کامل دوباره استفاده کند). نسخه AIDL پیکربندی CAP در مقایسه با نسخه اندروید ۱۵ و پایین‌تر تغییراتی دارد، بنابراین فروشنده باید پیکربندی موجود را به AIDL تبدیل کند. برای تغییرات مورد نیاز، به بحث در استراتژی‌های محصول برای تغییرات بین نسخه‌های اندروید ۱۶ و پایین‌تر مراجعه کنید. به طور کلی، چارچوب صوتی پیکربندی CAP را به همان روشی که در سناریو ۱ بود، کشف و بارگذاری می‌کند.

سناریو ۳: دستگاه موجود با CAP که فقط پارتیشن سیستم را به اندروید ۱۶ به‌روزرسانی می‌کند

در این سناریو، پارتیشن vendor شامل پیکربندی CAP دستگاه برای اندروید ۱۵ و نسخه‌های پایین‌تر و تعریف دامنه CAP مربوط به PfW است. پارتیشن vendor دست نخورده باقی می‌ماند، بنابراین همچنان از HIDL HAL استفاده می‌کند. این چارچوب از سناریوی اندروید ۱۵ و پایین‌تر پیروی می‌کند و تمام پیکربندی‌های مربوط به CAP را از پارتیشن vendor بارگذاری می‌کند.

سناریو ۴: دستگاه موجود با اندروید ۱۵ و CAP منتشر شده است

CAP در AIDL اندروید ۱۵ پشتیبانی نمی‌شد، بنابراین برخی از فروشندگان دستگاه‌های جدیدی را با AIDL Audio HAL و CAP منتشر کردند که توسط چارچوب صوتی بارگذاری می‌شد. این حالت ترکیبی غیررسمی بود، اما در اندروید ۱۶ گنجانده شده است. توجه داشته باشید که این حالت نباید برای انتشار دستگاه‌های جدید در اندروید ۱۶ استفاده شود، بلکه باید برای فعال کردن به‌روزرسانی دستگاه‌های موجود با فروشنده اندروید ۱۵ به اندروید ۱۶ (به‌روزرسانی پارتیشن system ) استفاده شود.

چارچوب صوتی، پیکربندی صوتی AIDL audio HAL را بدون پیکربندی CAP کشف می‌کند. برای پیکربندی CAP، سرویس سیاست صوتی (چارچوب صوتی) به بارگیری پیکربندی CAP از پارتیشن vendor بازمی‌گردد. در این حالت، هم تعریف دامنه PfW CAP و هم پیکربندی CAP دستگاه باید از پارتیشن vendor بارگیری شوند.

خلاصه مهاجرت CAP

جدول زیر خلاصه‌ای از پیکربندی‌های سازگار با سیستم و فروشنده و الزامات پیکربندی CAP را نشان می‌دهد:

پارتیشن سیستم	سناریو	نسخه کد پارتیشن فروشنده	نوع HAL صوتی اصلی	محل تعریف دامنه PfW CAP	پیکربندی CAP دستگاه
اندروید ۱۵	۴	اندروید ۱۴ یا پایین‌تر	هایدل	`vendor`	نسخه HIDL
اندروید ۱۶	۳	اندروید ۱۴ یا پایین‌تر	هایدل	`vendor`	نسخه HIDL
اندروید ۱۶	۴	اندروید ۱۵	آیدل	`vendor`	نسخه HIDL
اندروید ۱۶	۲	اندروید ۱۶	آیدل	`system`	نسخه AIDL تبدیل شده از HIDL
اندروید ۱۶	۱	اندروید ۱۶	آیدل	`system`	نسخه AIDL از مثال