في نظام التشغيل 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 والإصدارات الأحدث:
الشكل 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.
الشكل 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:
الشكل 3. إدارة إعدادات محرك CAP اعتبارًا من Android 16
تحصل خدمة سياسة الصوت على معلومات محرك CAP باستخدام واجهات برمجة تطبيقات AIDL Audio HAL مباشرةً بدلاً من تحليل المعلومات من ملفات XML في قسم المورّد بالجهاز.
في هذا الإعداد، لا يزال يتم تحميل بنية إطار المَعلمات بواسطة محرك CAP على مستوى خادم الصوت.
الشكل 4. بنية محرك CAP
في جميع الحالات، يجب أن يحدّد الإعداد بشكل كامل المعلومات المتعلّقة باستراتيجيات المنتجات ومجموعات عدد الزيارات والمعايير.
يوضّح الشكل التالي نظرة عامة عالية المستوى على واجهات برمجة التطبيقات الخاصة بطبقة تجريد الأجهزة (HAL) للصوت المستندة إلى AIDL والتي تستخدمها خدمة سياسة الصوت للحصول على إعدادات محرك 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) من خلال نظام الإنشاء، عن طريق تحديد قاعدة إنشاء باستخدام الخطوات التالية:
في ملف
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 للسيارات باستخدام 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 من المثال |