محرّك قابل للضبط لسياسة الصوت

في نظام التشغيل Android 14، يستفيد نظام التشغيل Android Automotive (AAOS) من محرك "سياسة الصوت القابلة للضبط" (CAP) لإدارة الصوت في السيارة ضمن منطقة الصوت الأساسية. على وجه التحديد، يتيح محرك CAP لنظام التشغيل AAOS التحكّم في توجيه الصوت فقط أو مستوى الصوت فقط أو كليهما في الوقت نفسه. يمكن استخدام العلامات التالية للتحكّم في السلوك:

  • استخدِم العلامة useCoreAudioVolume لتفعيل إدارة مستوى صوت CAP. عندما تكون هذه القيمة true، تستخدم خدمة الصوت في السيارة واجهات برمجة تطبيقات "مدير الصوت" لإدارة مجموعات مستوى الصوت.

  • استخدِم العلامة useCoreAudioRouting لتفعيل إدارة توجيه الصوت في CAP. عندما تكون هذه القيمة true، تستخدم خدمة الصوت في السيارة توجيه سياسة الصوت القابل للضبط لإدارة توجيه الصوت.

يتوافق نظام التشغيل Android أيضًا مع "محرك سياسات الصوت" تلقائيًا في شكل محرك سياسات الصوت التلقائي.

خلفية

تستند آلية CAP إلى إطار المَعلمات من Intel، وهو إطار عمل يستند إلى المكوّنات الإضافية والقواعد للتعامل مع المَعلمات. في ما يتعلق بإدارة الصوت على أجهزة Android على وجه الخصوص، أتاحت آلية CAP إمكانية تحديد قواعد ملفات XML لتحديد ما يلي:

  • استراتيجية المنتجات الصوتية
  • قواعد اختيار مصدر إخراج الصوت
  • قواعد اختيار جهاز إدخال الصوت
  • قواعد لإدارة مستوى الصوت وكتمه بالإضافة إلى جداول مستوى الصوت

تهيئة CAP قبل الإصدار 16 من نظام التشغيل Android

يوضّح الشكل التالي نظرة عامة عالية المستوى على إدارة إعدادات محرك سياسات الصوت القابلة للضبط في نظام التشغيل Android 6 والإصدارات الأحدث:

بنية محرّك CAP قبل الإصدار 16 من نظام التشغيل Android

الشكل 1: إدارة إعدادات محرك CAP اعتبارًا من الإصدار 6 من نظام التشغيل Android

كما هو موضّح في الشكل، يتم الحصول على إعدادات محرك 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 قبل الإصدار 16 من نظام التشغيل Android

الشكل 2: يتم تحميل معلومات CAP ضمن خدمة سياسة الصوت.

ملفات بنية CAP في الإصدار 15 من نظام التشغيل Android والإصدارات الأقدم

للحصول على البنية والإعدادات، تقرأ خدمة سياسة الصوت ملف ParameterFrameworkConfigurationPolicy.xml. يشير ذلك إلى معلومات البنية من خلال موقع ملف وصف البنية:

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

يشير ذلك إلى معلومات البنية في الملف:

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

يتم توفير بنية أساسية في Android . تتطلّب معلومات البنية معلومات بنية استراتيجية المنتج، لذا يوفّر نظام التشغيل Android buildStrategiesStructureFile.py أداة إنشاء، يمكنها إنشاء معلومات من ملف XML المتاح لاستراتيجية المنتج. يمكن الرجوع إلى ذلك من خلال الإعداد التلقائي لقاعدة genrule buildstrategiesstructurerule على النحو التالي:

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

يمثّل audio_policy_engine_configuration_files ملفات إعدادات محرك سياسات الصوت. يشير هذا المثال الخاص بالسيارات إلى ملفات إعدادات سياسة الصوت في مجلد السيارات. توضّح أمثلة أخرى كيفية ضبط إصدار لدفع الملفات في قسم المورّد بالجهاز.

ملفات إعدادات CAP في الإصدار 15 من نظام التشغيل Android والإصدارات الأقدم

على غرار البنية، تتم الإشارة إلى معلومات الإعدادات التي تمثّل القواعد وقيم المَعلمات في الملف ParameterFrameworkConfigurationPolicy.xml على النحو التالي:

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

يوفّر Android أيضًا أدوات إنشاء لإنشاء هذه المعلومات باستخدام إعدادات محرك سياسة الصوت وملفات إطار عمل المَعلمات. يمكنك الاطّلاع على الإعدادات لمزيد من المعلومات.

تهيئة إمكانات واجهة HAL الصوتية المستندة إلى AIDL

بدءًا من Android 16، تم توسيع تعريف واجهة برمجة التطبيقات AIDL Audio HAL API ليشمل إعدادات محرك سياسة الصوت، AudioHalCapConfiguration.aidl. يوضّح الشكل التالي نظرة عامة على مستوى عالٍ حول إدارة إعدادات محرّك CAP في Android 16:

بنية AIDL لمحرك CAP

الشكل 3: إدارة إعدادات محرك CAP اعتبارًا من Android 16

تحصل خدمة سياسة الصوت على معلومات محرك CAP باستخدام واجهات برمجة تطبيقات AIDL Audio HAL مباشرةً بدلاً من تحليل المعلومات من ملفات XML في قسم المورّد على الجهاز.

في هذا الإعداد، لا يزال محرّك CAP يحمّل بنية إطار المَعلمات من جهة خادم الصوت.

مسار تحميل AIDL الخاص بمحرك CAP

الشكل 4. بنية محرك CAP

في جميع الحالات، يجب أن يحدّد الإعداد بشكل كامل المعلومات المتعلّقة باستراتيجيات المنتجات ومجموعات عدد مرات الظهور والمعايير.

يوضّح الشكل التالي نظرة عامة على مستوى عالٍ لواجهات برمجة التطبيقات الخاصة بطبقة تجريد الأجهزة (HAL) للصوت المستندة إلى لغة تعريف واجهة Android (AIDL) والتي تستخدمها خدمة سياسة الصوت للحصول على إعدادات محرك CAP:

واجهات AIDL لواجهة CAP الشكل 5. واجهات برمجة تطبيقات AIDL لطبقة تجريد الأجهزة (HAL) الخاصة بالصوت

في عملية الإعداد هذه، تحصل خدمة سياسة الصوت على المعلومات التالية من AIDL Audio HAL:

  • الإعداد
  • الاستراتيجيات
  • المجلدات
  • المعايير
  • الإعدادات

برنامج التحميل التلقائي لطبقة تجريد أجهزة الصوت (HAL) في AIDL

لتسهيل عملية الانتقال من HIDL إلى AIDL، يوفّر برنامج تشغيل محرك CAP بتنسيق XML في طبقة تجريد أجهزة الصوت التلقائية في AIDL. يمكن للمورّدين استخدام أداة التحميل هذه مباشرةً من خلال توسيع طبقة تجريد الأجهزة الصوتية (HAL) لتشمل طبقة تجريد الأجهزة الصوتية التلقائية أو الإشارة إلى مكتبة libaudioserviceexampleimpl.

يستخدم محمّل HAL التلقائي للصوت في AIDL audio_policy_engine_configuration.xml للحصول على المعلومات التالية:

  • الإعداد
  • الاستراتيجيات
  • المجلدات
  • المعايير

يتم الحصول على معلومات البنية من ملف PolicyConfigurableDomains.xml. ويكمن الاختلاف الرئيسي عن الآلية السابقة في أنّ معلومات البنية يتم الحصول عليها أيضًا من خلال AIDL Audio HAL بدلاً من إطار عمل المَعلمات في خدمة سياسة الصوت.

يمكن للمورّدين استخدام أداة domaingeneratorpolicyrule لإنشاء النطاقات القابلة للإعداد باستخدام المعلومات الواردة من إعدادات محرّك سياسة الصوت. يمكن استخدام مثال جهاز Cuttlefish الافتراضي للسيارات كمرجع.

البنية في إعدادات AIDL

في الإصدار 16 من نظام التشغيل Android والإصدارات الأحدث، تحصل خدمة سياسة الصوت على معلومات البنية من خلال قراءة وتحليل 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
استراتيجيات المنتجات التي يحدّدها المصنّع الأصلي للأجهزة

يتيح المحرّك القابل للضبط للمصنّعين الأصليين للأجهزة تغيير تعريفات استراتيجيات المنتجات. لإتاحة ذلك، يوفّر ملف استراتيجية المنتج CapProductStrategies.xml أيضًا 40 استراتيجية منتج قابلة للتوسيع من المورِّد من vx_1000 إلى vx_1039 . يجب أن تبدأ جميع إضافات المورّد بالبادئة vx_، ويليها رقم يمثّل معرّف استراتيجية المنتج في تعريف استراتيجية المنتج في AIDL Audio HAL. يتم الحصول على بقية التعريفات (مثل مجموعات سمات الصوت والاسم) من عنصر AudioHALProductStrategy في إعداد محرك Audio HAL.

على غرار استراتيجيات المنتجات التلقائية، يجب أيضًا تعديل مراجع الشركات المصنّعة للمعدات الأصلية التي يحدّدها المورّد بين الإعداد غير المتوافق مع 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 المستخدَم في خدمة الصوت في السيارة، ولكن لا يُشترط هذا التطابق. من بين الاستخدامات الرئيسية التي تتيحها واجهة برمجة التطبيقات CAP لمصنّعي المعدات الأصلية إلى جانب نظام التشغيل Android، إمكانية تحديد تعريفات أكثر مرونة لتجميع الصوت.

مجموعات مستوى الصوت

بالإضافة إلى ذلك، يجب أن تحتوي كل مجموعة سمات صوت على مجموعة مستوى صوت مرتبطة بها. ترتبط مجموعة مستوى الصوت هذه بأي بث يتطابق مع سمات الصوت التابعة لمجموعة سمات الصوت. تتضمّن استراتيجية منتج الموسيقى النموذجية في قسم استراتيجيات المنتجات مجموعة مستوى الصوت 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:

  • وضع الصوت
  • أجهزة الإدخال والإخراج المتاحة
  • عناوين أجهزة الإدخال والإخراج المتاحة
  • الاستخدام مع
    • الوسائط
    • التواصل
    • جارٍ التسجيل
    • رصيف
    • النظام
    • صوت النظام عبر 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 كيفية تطبيق القواعد المختلفة عند التعامل مع اختيار الأجهزة لاستراتيجيات المنتجات. تصف الأجزاء الزرقاء القواعد التي يجب أخذها في الاعتبار، بينما يمثّل الجزء الأخضر الإعدادات التي تم تطبيقها. يحتوي هذا المثال تحديدًا على الإعدادات التالية:

  • اختَر جهاز Bluetooth A2DP لاستراتيجية منتج الموسيقى (المعرّف 1000، vx_1000)
    • إذا تم استخدامه للوسائط، لا يستبعد A2DP
    • إذا تم استخدامه للتواصل، لن يكون BT SCO
    • إذا كانت الأجهزة المتاحة تتضمّن A2DP عبر البلوتوث
  • اختيار جهاز الحافلة
    • في حال توفّر أجهزة الحافلة
    • إذا كان العنوان BUS00_MEDIA
  • اختَر جهاز الإخراج التلقائي

لإنشاء ملفّ XML الخاص بمحرّك السياسات القابل للضبط، شغِّل ملفات parameter-framework (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

يمكنك استخدام remote-process لتفريغ إعدادات CAP:

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

يعرض هذا القسم جميع النطاقات والإعدادات، بما في ذلك شروط التطبيق. يوضّح ما يلي مقتطفًا من جهاز Cuttlefish للسيارات باستخدام Bluetooth 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

لاستخدام الأداة، يجب أن يسمح المصنّعون الأصليون للأجهزة بضبطها في الجهاز. للتحقّق مما إذا كان الجهاز يسمح بضبط التردد، استخدِم الأمر التالي:

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

نقل بيانات CAP في Android 16

نظرًا للتغييرات الكبيرة التي أحدثها محرك AIDL الصوتي HAL CAP والإصدارات السابقة، هناك سيناريوهات مختلفة لنقل البيانات بين الأجهزة يجب أخذها في الاعتبار. يتناول هذا القسم أبرز سيناريوهات الانتقال ويقدّم اقتراحات بشأن العمل اللازم لتفعيل إعداد محرك CAP.

السيناريو 1: جهاز جديد يعمل بالإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث، وليس هناك مصدر سابق لإعدادات CAP للجهاز

يجب أن يتضمّن الجهاز الجديد الإصدار 16 من نظام التشغيل Android أو إصدارًا أحدث في قسم vendor عند إطلاقه. وهذا يعني أنّه يجب أن يتيح إمكانية ضبط إعدادات محرك سياسة الصوت من خلال واجهة AIDL الصوتية HAL. يجب نسخ إعدادات محرّك CAP الخاص بالجهاز من الأمثلة. يجب ألا يكون هناك تعريف لنطاق PfW CAP في القسم vendor.

صورة النظام المستخدَمة على الجهاز هي Android 16 أو إصدار أحدث. يكتشف إطار عمل خدمة الصوت إعدادات CAP من خلال واجهة AIDL الصوتية لطبقة HAL، لذا يبدأ PfW باستخدام تعريف نطاق PfW CAP من صورة النظام ويحمّل إعدادات CAP للجهاز التي تم تلقّيها من خلال AIDL.

للاطّلاع على مثال، راجِع جهاز Cuttlefish الافتراضي للسيارات، الذي تم تقديمه في هذا التغيير، ويمكن الرجوع إليه للحصول على الملفات المطلوبة وقواعد الإنشاء وملفات الإنشاء المطلوبة لإعداد ملفات الإعداد المطلوبة. تعمل هذه الميزة مع أدوات التحميل المتوفّرة في طبقة تجريد أجهزة الصوت التلقائية المستندة إلى لغة تعريف واجهة Android.

السيناريو 2: جهاز جديد يعمل بالإصدار 16 من نظام التشغيل Android أو إصدار أحدث، من جهاز سابق يستخدم CAP

يجب أن يتضمّن الجهاز الجديد الإصدار 16 من نظام التشغيل Android أو إصدارًا أحدث في قسم vendor عند إطلاقه. ومع ذلك، بما أنّ المصنّع الأصلي للجهاز لديه إعدادات محرك CAP قابلة للاستخدام، سيريد المصنّع الأصلي للجهاز استخدامها كنقطة بداية (أو إعادة استخدامها بالكامل). يتضمّن إصدار AIDL من إعدادات CAP بعض التغييرات مقارنةً بالإصدار 15 من نظام Android والإصدارات الأقدم، لذا على المورّد تحويل الإعدادات الحالية إلى AIDL. راجِع المناقشة في استراتيجيات المنتجات لمعرفة التغييرات بين الإصدار 16 من نظام التشغيل Android والإصدارات الأقدم بشأن التغييرات المطلوبة. بشكل عام، يكتشف إطار عمل الصوت ويحمّل إعدادات CAP بالطريقة نفسها كما في السيناريو 1.

السيناريو 3: جهاز حالي مزوّد بميزة "تحديث التطبيقات بدون إعادة التشغيل" يتم تحديث قسم النظام فقط إلى Android 16

في هذا السيناريو، يحتوي القسم vendor على إصدار Android 15 والإصدارات الأقدم من إعدادات CAP للجهاز، وتعريف نطاق CAP الخاص بـ "العمل في الملف الشخصي". لم يتم تعديل القسم vendor، لذا سيظل يستخدم HIDL HAL. يتّبع إطار العمل سيناريو Android 15 والإصدارات الأقدم، ويحمّل جميع إعدادات CAP ذات الصلة من القسم vendor.

السيناريو 4: جهاز حالي تم إصداره على Android 15، مع توفُّر ميزة "التحقّق من صحة التطبيق"

لم يكن CAP متوافقًا مع AIDL على Android 15، لذا طرح بعض المورّدين أجهزة جديدة تتضمّن AIDL Audio HAL وCAP، وقد تم تحميلها من خلال إطار عمل الصوت. كان هذا الوضع المختلط غير رسمي، ولكن تم تضمينه في Android 16. يُرجى العِلم أنّه يجب عدم استخدام هذا الوضع لإصدار أجهزة جديدة تعمل بنظام التشغيل Android 16، بل يجب استخدامه لإتاحة تحديث الأجهزة الحالية التي تعمل بنظام التشغيل Android 15 إلى Android 16 (تحديث قسم system).

يكتشف إطار عمل الصوت إعدادات الصوت في AIDL Audio HAL بدون إعدادات CAP. بالنسبة إلى إعدادات CAP، تعود خدمة سياسة الصوت (إطار عمل الصوت) إلى تحميل إعدادات CAP من القسم vendor. في هذه الحالة، يجب تحميل تعريف نطاق PfW CAP وإعدادات CAP للجهاز من القسم vendor.

ملخّص عملية نقل بيانات CAP

يلخّص الجدول التالي عمليات الضبط المتوافقة للنظام والمورّدين ومتطلبات عملية ضبط CAP:

قسم النظام السيناريو إصدار رمز القسم الخاص بالمورّد نوع Core audio HAL موقع تعريف نطاق PfW CAP إعدادات CAP على الجهاز
Android 15 4 الإصدار 14 من Android أو الإصدارات الأقدم HIDL vendor إصدار HIDL
Android 16 3 الإصدار 14 من Android أو الإصدارات الأقدم HIDL vendor إصدار HIDL
Android 16 4 Android 15 AIDL vendor إصدار HIDL
Android 16 2 Android 16 AIDL system إصدار AIDL الذي تم تحويله من HIDL
Android 16 1 Android 16 AIDL system إصدار AIDL من المثال