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

في نظام التشغيل 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 لتشمل إعدادات محرك سياسة الصوت، AudioHalCapConfiguration.aidl. يوضّح الشكل التالي نظرة عامة عالية المستوى على إدارة إعدادات محرّك CAP اعتبارًا من Android 16:

بنية AIDL لمحرك CAP

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

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

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

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

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

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

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

واجهات AIDL API الخاصة بمحرّك CAP الشكل 5. واجهات برمجة تطبيقات طبقة تجريد الأجهزة الصوتية (HAL) المستندة إلى AIDL

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

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

أداة تحميل AIDL Audio HAL التلقائية

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

يستخدم محمّل 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 الصوتي HAL. يتم الحصول على بقية التعريفات (مثل مجموعات سمات الصوت والاسم) من عنصر AudioHALProductStrategy في إعداد محرك 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 audio 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 الافتراضي للسيارات الذي تم تقديمه في هذا التغيير، ويمكن الرجوع إليه للحصول على الملفات المطلوبة وقواعد الإنشاء وملفات Make المطلوبة لإعداد ملفات الإعداد المطلوبة. تعمل هذه الميزة مع أدوات التحميل المتوفّرة في طبقة تجريد أجهزة الصوت التلقائية المستندة إلى لغة تعريف واجهة 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. يتّبع إطار العمل سيناريو الإصدار 15 من نظام التشغيل Android والإصدارات الأقدم، ويحمّل جميع إعدادات CAP ذات الصلة من القسم vendor.

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

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

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

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

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

قسم النظام سيناريوهات إصدار رمز القسم الخاص بالمورّد نوع HAL الأساسي للصوت موقع تعريف نطاق PfW CAP إعدادات CAP للجهاز
Android 15 4 ‫Android 14 أو الإصدارات الأقدم HIDL vendor إصدار HIDL
Android 16 3 ‫Android 14 أو الإصدارات الأقدم 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 من المثال