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

در Android 14، سیستم عامل Android Automotive (AAOS) از مدیریت صدای موتور قابل تنظیم خط مشی صوتی (CAP) در منطقه صوتی اولیه استفاده می کند. به طور خاص، موتور CAP به AAOS اجازه می دهد تا فقط مسیریابی صدا، فقط حجم صدا، یا هر دو مسیریابی و حجم صدا را به طور همزمان کنترل کند. برای کنترل رفتار می توان از پرچم های زیر استفاده کرد:

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

• از پرچم useCoreAudioRouting برای فعال کردن مدیریت مسیریابی صوتی CAP استفاده کنید. وقتی این مقدار true باشد، سرویس صوتی خودرو از مسیریابی خط مشی صوتی قابل تنظیم برای مدیریت مسیریابی صدا استفاده می کند.

موتور خط مشی صوتی نیز در اندروید به صورت پیش فرض در قالب موتور خط مشی صوتی پیش فرض پشتیبانی می شود.

پس زمینه

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

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

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

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

شکل 1. مدیریت پیکربندی موتور CAP در اندروید 6.

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

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

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

فایل های ساختار CAP در اندروید 15 و پایین تر

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

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

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

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

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

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

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

فایل های تنظیمات CAP در اندروید 15 و پایین تر

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

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

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

راه اندازی HAL CAP صوتی AIDL

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

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

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

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

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

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

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

شکل 5. API های HAL صوتی AIDL.

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

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

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

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

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

• پیکربندی
• استراتژی ها
• حجم ها
• معیارها

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

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

ساختار در پیکربندی AIDL

در اندروید 16 و بالاتر، سرویس خط‌مشی صوتی اطلاعات ساختار را با خواندن و تجزیه فایل ParameterFrameworkConfigurationCap.xml به دست می‌آورد. به ویژه اطلاعات را از فایل توضیحات ساختار دریافت می کند:

<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 همچنین 40 استراتژی محصول قابل توسعه فروشنده از vx_1000 تا vx_1039 را ارائه می دهد. همه برنامه های افزودنی فروشنده باید با پیشوند vx_ شروع شوند و با عددی دنبال شوند که نشان دهنده شناسه استراتژی محصول در تعریف استراتژی محصول صوتی HAL AIDL است. بقیه تعاریف (به عنوان مثال، گروه های ویژگی صوتی، نام) از شی AudioHALProductStrategy در پیکربندی موتور HAL صوتی به دست می آیند.

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

همانطور که در شکل 5 نشان داده شده است، API شامل چندین دامنه است، هدف هر دامنه تقسیم منطق به مشکلات مسیریابی کوچکتر برای حل است (به عنوان مثال، دستگاه 1، دستگاه 2).

هر دامنه دارای تنظیماتی است و هر پیکربندی دارای مجموعه ای از قوانین است. قوانین بر اساس معیارهایی که توسط AudioPolicyManager ارائه شده است، ایجاد شده است:

• حالت صوتی
• دستگاه های ورودی و خروجی موجود
• آدرس های دستگاه های ورودی و خروجی موجود
• استفاده کنید برای
  • رسانه ها
  • ارتباط
  • در حال ضبط
  • بارانداز
  • سیستم
  • سیستم صوتی hdmi
  • فراگیر رمزگذاری شده
  • زنگ ارتعاشی

هر دامنه شامل پیکربندی هایی است که قوانینی را که باید بر رفتار تأثیر بگذارد را دیکته می کند. توجه داشته باشید که ترتیب پیکربندی مهم است و مهم است که مطمئن شوید تنظیمات به ترتیب مورد نیاز هستند. پس از تأیید قوانین یک پیکربندی، پیکربندی انتخاب می شود.

کد زیر نمونه گزیده ای از فایل چارچوب پارامتر را نشان می دهد که می تواند برای تولید فایل XML مورد نیاز برای پیکربندی دامنه های قابل تنظیم استفاده شود:

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

دامنه DeviceForProductStrategies تعریف می کند که چگونه قوانین مختلف باید هنگام مدیریت استراتژی های محصول انتخاب دستگاه اعمال شود. قسمت های آبی قوانینی را که باید در نظر گرفته شوند و قسمت سبز پیکربندی اعمال شده را توصیف می کند. این مثال خاص شامل تنظیمات زیر است:

• دستگاه بلوتوث A2DP را برای استراتژی محصول موسیقی انتخاب کنید (ID 1000, vx_1000 )
  • اگر برای رسانه استفاده می شود، A2DP را استثنا نمی کند
  • اگر برای ارتباط استفاده می شود، BT SCO نیست
  • در صورت موجود بودن دستگاه، 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	انواع معیارها فایل 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

برای حذف تنظیمات CAP می‌توانید از 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

در اندروید 15 و پایین تر، فایل ممکن است متفاوت باشد، بنابراین از دستور زیر استفاده کنید:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

فایل باید حاوی TuningAllowed="true" به همراه پورت سرور مربوطه باشد:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

این فایل با توجه به نوع تصویر ساخت به طور خودکار تولید می شود (یا از فایل دیگری برای انتشار یا اشکال زدایی برای ساخت قدیمی استفاده کنید). یک نسخه انتشار TuningAllowed بدون درگاه سوکت روی false تنظیم می‌کند (سوکت‌ها برای این کار در نسخه‌های انتشار ممنوع هستند). مهندسی و ساخت‌های userdebug آن را با پورت سوکت استفاده شده روی true تنظیم می‌کنند. توجه داشته باشید که این فایلی است که audio_policy_pfw_toplevel به آن ارجاع داده است. ابزار پردازش از راه دور نیز باید در فایل ساخت یا ساخت دستگاه گنجانده شود:

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

خط مشی مربوطه SELinux برای اجازه دادن به سوکت ها نیز باید گنجانده شود. این فقط برای حالت اشکال زدایی کار می کند زیرا حالت انتشار به صراحت سوکت ها را مجاز نمی داند:

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

مهاجرت CAP در اندروید 16

با توجه به تغییرات عمده ای که موتور HAL CAP صوتی AIDL و نسخه های قبلی ایجاد کرده است، سناریوهای مختلف انتقال دستگاه وجود دارد که باید در نظر بگیرید. این بخش برجسته ترین سناریوهای انتقال را پوشش می دهد و توصیه هایی برای کار برای فعال کردن پیکربندی موتور CAP ارائه می دهد.

سناریو 1: دستگاه جدید با استفاده از Android 16 یا بالاتر، بدون منبع قبلی برای پیکربندی CAP دستگاه

یک دستگاه جدید باید با کد Android 16 یا بالاتر در پارتیشن vendor راه اندازی شود. این بدان معناست که باید پیکربندی موتور خط مشی صوتی قابل تنظیم را از طریق رابط صوتی AIDL HAL نشان دهد. پیکربندی موتور CAP دستگاه باید از نمونه ها کپی شود. در پارتیشن vendor نباید تعریف دامنه PfW CAP وجود داشته باشد.

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

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

سناریو 2: دستگاه جدید با استفاده از Android 16 یا بالاتر، از دستگاه قبلی با استفاده از CAP

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

سناریو 3: دستگاه موجود با CAP به روز رسانی به اندروید 16 فقط پارتیشن سیستم

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

سناریو 4: دستگاه موجود در اندروید 15 با CAP منتشر شده است

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

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

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

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