إتاحة سياسة الصوت القابلة للضبط في AIDL HAL

بدءًا من Android 16، تتيح واجهة AIDL Audio HAL إمكانية استخدام "سياسة الصوت القابلة للضبط" (CAP) بشكل كامل.

تقدّم هذه الصفحة معلومات فنية أساسية لمساعدة الشركاء ومورّدي نظام التشغيل على الرقاقة (SoC) في نقل إعدادات سياسات الصوت.

إطار عمل المَعلمات

يستند تنفيذ CAP إلى إطار عمل معلَمات Intel. تم طرح CAP في نظام التشغيل Android 6. يتيح إطار عمل المَعلمات (PfW) وصف نظام من خلال المَعلمات. باستخدام ملف XML للإعداد، يربط PfW المَعلمات بالإجراءات باستخدام المكوّنات الإضافية، ويوفّر قواعد لتغيير المَعلمات وفقًا للمعايير الحالية.

بنية CAP في HIDL

في HIDL، تم تحديد جميع إعدادات CAP بتنسيق XML. لمزيد من المعلومات، راجِع إطار عمل المَعلمات والإعداد باستخدام إطار عمل المَعلمات. تم استخدام ملفات XML لتحديد ما يلي:

  • وصف لبنية المَعلمات (أي وصف لمجال الصوت في PfW)
  • تعريفات المعايير
  • قواعد استراتيجيات التوجيه (اختيار أجهزة الإدخال والإخراج)
  • مواصفات جداول الحجم

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

بنية CAP في AIDL

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

تتم إضافة هياكل بيانات CAP إلى أنواع البيانات الثابتة الشائعة، وتشمل ما يلي من العناصر القابلة للتسلسل:

نقطة الدخول لإعدادات CAP هي في بنية AudioHalEngineConfig.CapSpecificConfig اطّلِع على التعليقات في AudioHalCapConfiguration.aidl للحصول على رسم بياني لبُنى بيانات CAP.

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

سيناريوهات نقل البيانات

يمكن للشركاء مراعاة الخيارات المدرَجة في هذا القسم، استنادًا إلى ما إذا كان ذلك هو الإطلاق الأول لمنتج لم يكن يستخدم CAP من قبل، أو نقل بيانات منتج حالي.

منتج جديد

بالنسبة إلى منتج جديد يبدأ في استخدام CAP لتنفيذ سياسة الصوت، يمكن لمصنّع المعدات الأصلية اختيار استخدام XML لتخزين إعدادات CAP على جهة المورّد.

تتمثّل فائدة استخدام XML في توفّر مجموعة من أدوات البرمجة النصية التي تسهّل إنشاء الإعدادات من وصف عالي المستوى.

إذا قرر المصنّع الأصلي للجهاز استخدام XML لتخزين إعدادات CAP في قسم المورّد، يُنصح باستخدام التنفيذ التلقائي لمحلّل XML لتحويل الإعدادات إلى AIDL.

تحديث للمنتج الحالي

إذا كان المنتج يستخدم CAP وبالتالي يتضمّن إعدادات XML، يمكنك مواصلة استخدام CAP الحالي مع إصدار AIDL من HAL.

يختلف أسلوب التسمية الخاص باستراتيجيات المنتجات في إصدارَي HIDL وAIDL من إعدادات CAP. في HIDL، تستخدم الاستراتيجيات المضمّنة (القديمة) أسماء قصيرة بأحرف صغيرة، مثل media، بينما تستخدم الاستراتيجيات المضمّنة في AIDL أسماء بأحرف كبيرة مسبوقة بـ STRATEGY_، مثل STRATEGY_MEDIA. يمكنك الاطّلاع على قائمة الاستراتيجيات المضمّنة في CapProductStrategies.xml. يحدّد الملف نفسه معرّفات "مخصّصة مسبقًا" للاستراتيجيات الخاصة بمصنّع المعدات الأصلية (OEM) والتي تتّبع نمط التسمية vx_10xx مع أرقام من 1000 إلى 1039.

المنتج القديم

إذا لم يتم تحديث قسم المورّد للمنتج الذي يعتمد على CAP وظلّ على HIDL، يمكنك تحديث قسم النظام إلى Android 16. يبقى إطار العمل متوافقًا مع إعدادات CAP القديمة.

مثال على عملية التنفيذ

لمساعدة الشركاء في تنفيذ CAP على منصاتهم، يتضمّن مشروع AOSP مثالاً على إصدار "السيارات" من جهاز Cuttlefish الافتراضي الذي يستخدم CAP مع AIDL HAL. يقع الإعداد الخاص بالجهاز في device/google/cuttlefish/shared/auto/audio/policy/engine، ويحمل اسم الهدف lunch وهو aosp_cf_x86_64_auto. يمكن استخدام ملف Android.bp كمرجع لإنشاء المجموعة الكاملة من ملفات مورّدي CAP.