خدمة البرنامج المساعد للصوت السيارة

تتيح خدمات المكونات الإضافية الجديدة لتصنيع المعدات الأصلية للسيارة في Android 14 تكوين بعض مكونات السيارة. بالنسبة للصوت على وجه التحديد، تم تقديم ثلاث خدمات إضافية جديدة، والتي تمكن مصنعي المعدات الأصلية من تكوين إدارة الصوت بمرونة على أجهزة AAOS:

• التحكم في تركيز الصوت
• التحكم في مستوى الصوت وكتم الصوت
• التحكم في خفض الصوت

بنية خدمة البرنامج المساعد للسيارة

يقدم الشكل أدناه نظرة عامة على خدمات السيارات وعلاقتها بخدمة سيارات OEM. على غرار عمليات التطبيق وعملية خدمة السيارة، تشغل عملية خدمة السيارة OEM مساحة العملية الخاصة بها.

تبدأ خدمة السيارات خدمة سيارات OEM من خلال البحث عن المكون المحدد في config_oemCarService . إذا كان التكوين فارغًا، فهذا يعني أن خدمة OEM غير موجودة ولم يتم بدء تشغيل أي خدمة. يجب أن يمتد المكون OemCarService . يجب أن تحل خدمة الصوت في السيارة محل واجهات برمجة التطبيقات للحصول على خدمة OEM للصوت في السيارة:

public final class OemCarServiceImp extends OemCarService {
    @Override
    public OemCarAudioFocusService getOemAudioFocusService();

    @Override
    public OemCarAudioDuckingService getOemAudioDuckingService();

    @Override
    public OemCarAudioVolumeService getOemAudioVolumeService();
}

على سبيل المثال ، راجع تطبيق الاختبار المرجعي المحدد في packages/services/Car/tests/OemCarServiceTestApp .

على الرغم من أن الخدمة يتم تشغيلها بواسطة خدمة السيارة، إلا أنها لا ترث تلقائيًا الأذونات المتاحة لخدمة الصوت بالسيارة. وعلى هذا النحو، يجب الحصول على أي إذن تطلبه خدمات OEM باستخدام الآلية المناسبة. على سبيل المثال، راجع packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml .

خدمة صوت السيارة مع بنية خدمة OEM

في AAOS، تدير خدمة الصوت في السيارة هذه الإجراءات:

• توجيه الصوت
• التركيز الصوتي
• التغاضي عن الصوت
• حجم وكتم الصوت

قبل Android 14، كان هذا السلوك ثابتًا إلى حد كبير ولا يمكن تعديله إلا من خلال الإعدادات، وإن كان ذلك لمجموعة محدودة جدًا من الحالات. قدم Android 14 آلية لخدمة الصوت في السيارة للتواصل مع مكون محدد من قبل OEM والذي يدير:

• التركيز الصوتي
• التغاضي عن الصوت
• حجم وكتم الصوت

يوضح الشكل أدناه بنية مبسطة لخدمة الصوت في السيارة وخدمة OEM للسيارة. تحدد خدمة الصوت في السيارة خطافات مختلفة يمكنها الاتصال بخدمة صوت OEM للسيارة لإدارة سلوك الصوت. يحدث هذا الأخير فقط إذا تم تحديد مكون خدمة الصوت للسيارة OEM المقابل. وبخلاف ذلك، تستخدم خدمة الصوت في السيارة السلوك الافتراضي.

للتأكد من أن خدمة صوت السيارة وخدمة صوت OEM للسيارة متزامنتان دائمًا، لكل مكالمة، تقوم خدمة صوت السيارة بتمرير الأجزاء المطلوبة من الحالة الحالية لمكدس الصوت إلى خدمة صوت OEM للسيارة. على سبيل المثال، عندما تعترض خدمة صوت السيارة طلبًا لتقييم التركيز الصوتي، فإنها تمرر الحالة الحالية للمكدس إلى خدمة صوت OEM للسيارة. تتضمن الحالة الحالية حامل التركيز الحالي وخاسرين التركيز الحاليين. إن فقدان التركيز هو طلبات التركيز التي لا تزال جزءًا من المكدس ولكنها فقدت التركيز مؤقتًا.

يجب أن تدير خدمة الصوت في السيارة جميع الأنشطة الصوتية في السيارة. إذا لم تتمكن خدمة الصوت في السيارة من إدارة بعض أجزاء السلوك الصوتي، فإن المعلومات التي يتم عرضها على خدمة الصوت الخاصة بالشركة المصنعة الأصلية للسيارة تكون غير كاملة. على سبيل المثال، إذا قامت إحدى الشركات المصنعة للمعدات الأصلية بالكتابة فوق معالجة التركيز الصوتي في خدمة السيارة عن طريق تسجيل سياسة التركيز الصوتي الخاصة بها، فلن تتمكن خدمة الصوت في السيارة من توفير معلومات كاملة إلى خدمة الصوت الخاصة بالشركة المصنعة للسيارة. يمكن أن يؤثر هذا على قدرة خدمة الصوت OEM للسيارة على اتخاذ القرارات نظرًا لأنها قد تفتقر إلى معلومات غير مرئية لخدمة الصوت بالسيارة.

لاتخاذ الإجراءات، تقوم خدمة صوت السيارة باستدعاء خدمات السيارة OEM. يتم إجراء هذه الاستدعاءات عبر العمليات، الأمر الذي يتطلب الاتصال بين العمليات (IPC). يضيف IPC زمن الوصول لكل مكالمة. من المهم تقليل زمن الوصول في خدمة OEM.

نظرًا لحظر مكالمات خدمة صوت السيارة إلى خدمة OEM، يجب ألا تقوم خدمة OEM باستدعاء خدمة صوت السيارة على تقييمات API المباشرة. وبدلاً من ذلك، توفر خدمة الصوت في السيارة المعلومات الضرورية بحيث تنتقل المكالمات بين العمليتين في اتجاه واحد فقط.

تعريفات خدمة الصوت للسيارة OEM

خدمة التركيز الصوتي للسيارة OEM

تدير خدمة الصوت في السيارة طلبات التركيز الصوتي من التطبيقات عن طريق تسجيل مستمع التركيز على سياسة الصوت. تتمتع خدمة الصوت في السيارة بآلية لإدارة سلوك التركيز بناءً على مصفوفة التفاعل الثابتة. تحدد المصفوفة ثلاثة أنواع مختلفة من التفاعلات:

• التفاعل المتزامن يمكن لحاملي التركيز الحفاظ على التركيز في نفس الوقت.

• تفاعلات حصرية يأخذ طلب التركيز الوارد التركيز من حامل التركيز الحالي.

• رفض التفاعل. تم رفض طلب التركيز الوارد استنادًا إلى صاحب التركيز الحالي.

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

public interface OEmCarAudioFocusService {
    OemCarAuddioFocusResults evaluateAudioFocusRequest(
        OemCarAudioFocusEvaluationRequest request);
    
    void notifyAudioFocusChange(
        List<AudioFocusEntry> holder,
        List<AudioFocusEntry> losers, int zoneId);
}

يتم استدعاء API evaluateAudioFocusRequest من خدمة الصوت في السيارة في أي وقت يوجد طلب للتركيز الصوتي يحتاج إلى تقييم، وهو عبارة عن واجهة برمجة تطبيقات ثنائية الاتجاه تمنع ظهور النتائج. يحتوي الطلب على معلومات حول الحالة الحالية لمكدس الصوت:

يمكن استخدام هذه المعلومات لتقييم newFocusRequest مقارنة بأصحاب التركيز الحاليين في focusHolders وخاسرين التركيز الحاليين في focusLosers . يجب أن تقوم واجهة برمجة التطبيقات (API) بإرجاع النتائج:

class OemCarAudioFocusResult {
    int audioZoneId;
    int audioFocusEvaluationResults;
    AudioFocusEntry focusResult;
    List<AudioFocusEntry> newLosers;
    List<AudioFocusEntry> newlyBlocked;
}

يحتوي هذا على معلومات حول نتائج التقييم الفعلية في audioFocusEvaluationResults ، والتي تشير إلى ما إذا كان الطلب الحالي قد تم قبوله أو تأخيره أو فشله. يجب تعيين أي تغييرات على مكدس التركيز الحالي في الإدخالات newLosers والإدخالات newlyBlocked ، اعتمادًا على طبيعة تغيير المكدس.

حيث يحتوي newLosers على إدخالات كانت في السابق تحتجز التركيز ولكن يجب أن تفقد التركيز الآن، إما بشكل دائم أو مؤقت. ستتم إزالة فقدان التركيز الدائم من مجموعة التركيز الصوتي، وسيتم نقل فقدان التركيز العابر إلى مجموعة فقدان التركيز الحالية حتى يستعيدوا التركيز أو يتم التخلي عنهم من طالب التركيز الأصلي. بغض النظر، سوف يتلقى مستمع التركيز للطلبات التركيز المفقود.

تحتوي القائمة newlyBlocked على الإدخالات التي كانت موجودة مسبقًا في القائمة الخاسرة للتركيز ولكن تم حظرها الآن بواسطة الإدخال الجديد. يمكن أن تكون الكتلة دائمة أو عابرة، بالنسبة للتركيز الدائم المحظور، ستتم إزالة الإدخال من المكدس وسيتم إرسال فقدان التركيز إلى مستمعي التركيز. بالنسبة لفقدان التركيز العابر، سيظل الإدخال في مكدس التركيز الخاسر ولكن ستتم إضافة أداة حظر التركيز الجديدة إلى قائمة أدوات الحظر الخاصة به، ولن يتم إرسال فقدان التركيز كما تم إرساله مسبقًا عندما تم حظره لأول مرة. سيتم إلغاء حظر الطلب أخيرًا عند إزالة جميع أدوات الحظر الحالية، أو ستتم إزالته من المكدس إذا تم التخلي عن التركيز.

واجهة برمجة التطبيقات الثانية، notifyAudioFocusChange ، هي طريقة واحدة يتم استدعاؤها عند كل طلب تركيز صوتي أو التخلي عنه. يتم استخدام واجهة برمجة التطبيقات (API) في الغالب لإعلام خدمة OEM بتغييرات التركيز، مما قد يؤثر على سلوك خدمة الصوت الخاصة بالسيارة OEM.

المبادئ التوجيهية لتقييم التركيز

في AAOS، يتم استخدام التركيز الصوتي لإدارة تشغيل الصوت وتحديد التطبيق الذي يجب الالتزام به لتوفير تجربة مثالية للمستخدم. على هذا النحو، يجب أن تأخذ خدمة البرنامج الإضافي OEM في الاعتبار ما يلي عند إدارة طلب التركيز الصوتي:

• بدون أي تركيز صوتي ذي أولوية عالية (مثل مكالمة هاتفية أو الطوارئ أو السلامة)، يجب أن تكون التطبيقات قادرة على الحصول على التركيز الصوتي إما بشكل عابر أو دائم.

• عندما يكون التركيز على الوسائط نشطًا، تطلب التطبيقات ما يلي:

  • يجب أن يكون التركيز على استخدام المكالمات قادرًا على تلقي التركيز بشكل متزامن أو حصريًا.

  • يجب أن يكون تركيز استخدام التنقل قادرًا على تلقي التركيز بشكل متزامن أو حصريًا.

  • يجب أن يكون تركيز استخدام المساعد قادرًا على تلقي التركيز بشكل متزامن أو حصريًا.

• أثناء تشغيل تطبيقات التركيز الصوتي ذات الأولوية العالية (مثل مكالمة هاتفية أو تنبيه الطوارئ أو تنبيه السلامة) تكون التطبيقات نشطة، ويجب إما الموافقة على أي طلب تركيز صوتي متأخر وارد أو تأخيره حسب الحاجة.

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

خدمة حجم السيارة OEM

تدير خدمة الصوت في السيارة أحداث مفتاح مستوى الصوت إما عن طريق الاستماع إلى تعديلات مستوى الصوت من النظام الصوتي أو عن طريق الاستماع إلى أحداث مفتاح مستوى الصوت مباشرةً من خدمة إدخال السيارة. في كل حالة، يكون السلوك الافتراضي لخدمة الصوت في السيارة هو تحديد مجموعة الصوت التي سيتم تغييرها بناءً على مشغلات الصوت النشطة وقائمة أولويات سياق الصوت.

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

1. ملاحة
2. يتصل
3. موسيقى
4. إعلان
5. أمر صوتي
6. حلقة المكالمة
7. صوت النظام
8. أمان
9. إنذار
10. إشعار
11. حالة المركبة
12. طارئ

لجعل إدارة حدث مفتاح مستوى الصوت أقل تعقيدًا، تحتوي خدمة الصوت في السيارة على قائمة أولوية ثانية لسياق الصوت:

1. يتصل
2. وسائط
3. إعلان
4. أمر صوتي

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

يمكن تعيين الإصدار الفعلي لوحدة التخزين من خلال تكوين audioVolumeAdjustmentContextsVersion . يمكن ضبط التكوين على 1 أو 2 ( 2 هو الإعداد الافتراضي).

لتوفير المزيد من المرونة لإدارة الحجم، تم تقديم OemCarAudioVolumeService في Android 14:

public interface OemCarAudioVolumeService {
    OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}

تحتوي خدمة مستوى صوت السيارة OEM على طريقة واحدة، والتي تأخذ volumeAdjustment وطلب OemCarAudioVolumeRequest :

class OemCarAudioVolumeRequest {
    int audioZoneId;
    int callState;
    List<AudioAttributes> activePlaybackAttributes;
    List<AudioAttributes> duckedAttributes;
    List<CarVolumeGroupInfo> volumeGroupState;
}

تحتوي activePlaybackAttributes الخاصة بالطلب على سمات الصوت النشطة. إن duckedAttributes كلها سمات صوتية منخفضة حاليًا. يحتوي volumeGroupState على الحالة الحالية لمجموعة وحدات التخزين. يمثل الطلب الحالة الحالية لمكدس الصوت ويمكن استخدامه لتحديد مجموعة وحدات التخزين التي يجب تغييرها. يجب أن يتم إرجاع النتائج في OemCarVolumeChangeInfo :

class OemCarVolumeChangeInfo {
    boolean change;
    CarVolumeGroupInfo volumeGroupChanged;
}

يشير change المنطقي إلى ما إذا كان هناك أي تغيير في أي وحدة تخزين، ويشير true إلى أن هناك تغييرًا ويجب تحديث مجموعة المجلدات. إن volumeGroupChanged هي مجموعة الحجم الفعلية التي يجب تغييرها. يجب تغيير هذه المجموعة وفقًا لمعلمة volumeAdjustment الأصلية التي تم تمريرها إلى واجهة برمجة التطبيقات. على سبيل المثال، إذا كانت النتائج تشير إلى أنه يجب كتم صوت مجموعة وحدات تخزين التنقل، فسيكون القيمة المنطقية true ومجموعة وحدات التخزين التي تم إرجاعها يجب أن تكون مخصصة للتنقل.

خدمة التملص من السيارة OEM

تدير خدمة الصوت في السيارة عملية إبعاد الصوت عن طريق مراقبة تغييرات التركيز الصوتي وإرسال إشارة إلى AudioControl HAL حول الأجهزة الصوتية التي سيتم إبعادها. عندما يتغير التركيز، يتم تقييم جميع أصحاب التركيز النشطين لتحديد أي منهم يجب أن يتم تجنبه بناءً على هذه المجموعة من قواعد التهرب الثابتة:

• أصوات الطوارئ تبطل كل شيء باستثناء أصوات المكالمات
• يتجنب الأمان كل شيء باستثناء أصوات الطوارئ
• يقوم نظام الملاحة بإلغاء كل شيء باستثناء أصوات السلامة والطوارئ
• استدعاء البط كل شيء باستثناء أصوات السلامة والطوارئ والملاحة
• صوت البط يدعو أصوات الرنين
• يجب تجنب الموسيقى والإعلانات في كل شيء

هذه القواعد ليست شاملة ويظل مصنعو المعدات الأصلية مسؤولين عن تحديد كيفية تجنب الأصوات بناءً على هذه الإرشادات. يمكن لمصنعي المعدات الأصلية التحكم في هذه التوصيات بشكل أكثر فعالية بناءً على المتطلبات المتوفرة. تم تقديم OemCarDuckingService في Android 14:

class OemCarAudioDuckingService {
List<AudioAttributes>   evaluateAttributesToDuck(
        OemCarAudioVolumeRequest request);
}

يتم استدعاء واجهة برمجة التطبيقات (API) هذه من خدمة الصوت في السيارة عند تغيير التركيز الصوتي. فهو يعيد استخدام OemCarAudioVolumeRequest الذي تم تقديمه في خدمة حجم السيارة OEM ، ويحتوي على المعلومات ذات الصلة لاتخاذ القرار بشأن سمات البط. تتم مقارنة قائمة سمات الصوت الخاصة بالبطة من واجهة برمجة التطبيقات (API) بحالة الصوت الحالية:

• تم إخفاء سمة الصوت حاليًا:

  • في القائمة، لا يزال يتم تجنبه
  • ليس في القائمة، تم إيقاف التملص

• سمة الصوت لم يتم تجنبها حاليًا:

  • في القائمة، تفاديت
  • ليس في القائمة، تم إيقاف التملص

تحدد خدمة الصوت في السيارة بعد ذلك أجهزة إخراج الصوت التي تنتمي إليها سمات الصوت وتضيفها إلى قائمة أجهزة إخراج الصوت غير الموصولة أو قائمة أجهزة الصوت غير الموضحة، على التوالي. يتم إرسال هذا في النهاية إلى AudioControl HAL لإجراء عملية التنصت المطلوبة على مستوى الأجهزة.

يوضح الشكل أدناه مخططًا تسلسليًا مبسطًا للتحكم في خفض مستوى الصوت لطلب التركيز عند استخدام خدمة خفض مستوى الصوت من OEM:

يبدأ التسلسل عندما يطلب أحد التطبيقات إدارة التركيز الصوتي من خلال واجهات برمجة التطبيقات العامة لإدارة الصوت. يتم تحويل الطلب إلى خدمة الصوت بالسيارة لتحديد النتائج. عندما يتم تحديد تركيز الصوت، يتم تقييم التهرب من الصوت بواسطة خدمة صوت السيارة التي تستدعي OemCarAudioDuckingService لتقييم سمات الصوت التي يجب إبعادها. بمجرد إرجاع النتائج من واجهة برمجة تطبيقات evaluateAttributesToDuck ، يتم حساب أجهزة الصوت التي سيتم حذفها، وفي النهاية يتم إرسال المعلومات إلى AudioControl لتطبيق عملية خفض الصوت على أجهزة الصوت.

تنفيذ مرجع خدمة صوت السيارة OEM

يوفر AAOS تطبيقًا مرجعيًا لخدمة سيارات OEM في packages/services/Car/tests/OemCarServiceTestApp ، الذي ينفذ OemCarService ، جنبًا إلى جنب مع OemCarAudioFocusService و OemCarAudioDuckingService و OemCarAudioVolumeService . بالنسبة للأخيرة، تستخدم كل خدمة ملف XML لتحميل سلوك ثابت. على سبيل المثال، يقوم OemCarAudioFocusServiceImp بتحميل oem_focus_config.xml ، الذي يحتوي على مصفوفة تفاعل. يتم استخدام المصفوفة لتقييم طلب التركيز عند استدعاء evaluateAudioFocusRequest .

تصحيح أخطاء تطبيق الاختبار المرجعي

يعد تطبيق اختبار خدمة السيارات OEM جزءًا من كود مصدر AOSP. يمكن لمصنعي المعدات الأصلية إجراء تغييرات وفقًا لاحتياجاتهم. لتصحيح الأخطاء، استخدم تكوين config_oemCarService لتمكين تطبيق الاختبار.

<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>

للتحقق من أن خدمة السيارة OEM تستخدم أمر dump خدمة السيارة لخدمة OEM:

adb shell dumpsys car_service --oem-service

يمكن أن تكون النتائج مشابهة للإخراج أدناه:

***CarOemProxyService dump***
  mIsFeatureEnabled: true
  mIsOemServiceBound: true
  mIsOemServiceReady: true
  mIsOemServiceConnected: true
  mInitComplete: true
  OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
  OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
  mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl

تحدد كل قيمة منطقية في كل دفعة من معلومات dump حالة الميزة والخدمة. على سبيل المثال، تحدد معلومات التفريغ mIsOemServiceReady ما إذا كانت الخدمة جاهزة للاستخدام، حيث يشير true إلى أنها جاهزة ويشير false إلى أنها غير جاهزة.