التركيز على الصوت

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

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

تفاعلات التركيز

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

  • حصري
  • يرفض
  • منافس

تفاعل حصري

هذا هو نموذج التفاعل الأكثر استخدامًا مع Android.

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

رفض التفاعل

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

التفاعل المتزامن

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

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

التعامل مع التدفقات المتزامنة

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

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

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

مصفوفة التفاعل

يوضح الجدول أدناه مصفوفة التفاعل كما حددتها CarAudioService . يمثل كل صف CarAudioContext لصاحب التركيز الحالي ويمثل كل عمود الطلب الوارد.

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

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

مصفوفة تفاعل التركيز الصوتي

الشكل 1. مصفوفة تفاعل تركيز الصوت.

في Android 11، تم تقديم إعداد مستخدم جديد للسماح للمستخدمين بتغيير سلوك التفاعل بين التنقل والمكالمات الهاتفية. عند التعيين، يقوم android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL بتغيير التفاعل بين طلبات تركيز NAVIGATION الواردة وحاملي تركيز CALL الحاليين من المتزامنة إلى المرفوضة . إذا كان المستخدم يفضل ألا تؤدي تعليمات التنقل إلى مقاطعة المكالمة، فيمكنه تمكين الإعداد. ويستمر هذا بالنسبة للمستخدم، ويمكن ضبطه ديناميكيًا بحيث تحترم طلبات التركيز اللاحقة الإعداد الجديد.

تأخير التركيز الصوتي

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

قواعد طلبات التركيز الصوتي المتأخرة

  • الطلبات غير العابرة فقط. لا يمكن إجراء طلب مؤجل إلا للمصادر غير العابرة لتجنب تشغيل الصوت العابر لفترة طويلة بعد أن يصبح ذا صلة.

  • يمكن تأخير طلب واحد فقط في كل مرة. إذا تم إجراء طلب قابل للتأخير بينما يوجد طلب مؤجل بالفعل، فسيتلقى الطلب المؤجل الأصلي حدث تغيير AUDIOFOCUS_LOSS ويتلقى الطلب الجديد استجابة متزامنة لـ AUDIOFOCUS_REQUEST_DELAYED .

  • يجب أن تحتوي الطلبات المؤجلة على OnAudioFocusChangeListener بمجرد تأخير الطلب، يتم استخدام المستمع لإعلام الطالب عندما يتم قبول الطلب في النهاية ( AUDIOFOCUS_GAIN )، أو إذا تم رفضه لاحقًا ( AUDIOFOCUS_LOSS ).

طلب التركيز المؤجل

لإنشاء طلب يمكن تأخيره:

  1. استخدم AudioFocusRequest.Builder#setAcceptsDelayedFocusGain .

    mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener();

mDelayedFocusRequest = new AudioFocusRequest
     .Builder(AudioManager.AUDIOFOCUS_GAIN)
     .setAudioAttributes(mMusicAudioAttrib)
     .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener)
     .setForceDucking(false)
     .setWillPauseWhenDucked(false)
     .setAcceptsDelayedFocusGain(true)
     .build();

  2. عند تقديم الطلب، تعامل مع الاستجابة AUDIOFOCUS_REQUEST_DELAYED :

    int delayedFocusRequestResults = mAudioManager.requestAudioFocus(mDelayedFocusRequest);
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
    // start audio playback
    return;
}
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_DELAYED) {
     // audio playback delayed to audio focus listener
     return;
}

  3. عندما يتأخر الطلب، يعالج مستمع التركيز التغييرات في التركيز:

    private final class MediaWithDelayedFocusListener implements
OnAudioFocusChangeListener {
       @Override
       public void onAudioFocusChange(int focusChange) {
           synchronized (mLock) {
               switch (focusChange) {
                   case AudioManager.AUDIOFOCUS_GAIN:
                       … // Start focus playback
                   case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT:
                       … // Pause media transiently
                   case AudioManager.AUDIOFOCUS_LOSS:
                       … // Stop media

إدارة التركيز متعدد المناطق

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

بالنسبة لجميع التطبيقات، تقوم CarAudioService بإدارة التركيز تلقائيًا. يتم تحديد المنطقة الصوتية لطلب التركيز من خلال UserId أو UID المرتبط بها (لمزيد من التفاصيل، راجع توجيه الصوت ).

طلب الصوت من مناطق متعددة في وقت واحد

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

//Create attribute with bundle and AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
Bundle bundle = new Bundle();
bundle.putInt(CarAudioManager.AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID,
               zoneId);

AudioAttributes attributesWithZone = new AudioAttributes.Builder()
     .setUsage(AudioAttributes.USAGE_MEDIA)
     .addBundle(bundle)
     .build();

//Create focus request using built attributesWithZone

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

هال الصوت التركيز

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

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

يجب على HAL كتم صوت تدفقات Android بشكل استباقي حسب الاقتضاء عند تشغيل أصوات الطوارئ أو الأصوات الحرجة للسلامة لضمان سماعها بوضوح.

التحكم بالصوت@2.0

يقدم الإصدار 2.0 من AudioControl HAL واجهات برمجة التطبيقات الجديدة هذه:

واجهة برمجة التطبيقات غاية
IAudioControl#registerFocusListener تسجيل مثيل لـ IFocusListener باستخدام AudioControl HAL. يقوم هذا المستمع بتمكين HAL من طلب التركيز الصوتي والتخلي عنه. يوفر HAl مثيل ICloseHandle ليستخدمه Android لإلغاء تسجيل المستمع.
IAudioControl#onAudioFocusChange يقوم بإعلام HAL بالتغييرات في حالة طلبات التركيز التي تم إجراؤها بواسطة HAL من خلال IFocusListener ، بما في ذلك الاستجابات لطلبات التركيز الأولية.
IFocusListener#requestAudioFocus يطلب التركيز نيابةً عن HAL لاستخدام محدد ومعرف المنطقة ونوع اكتساب التركيز.
IFocusListener#abandonAudioFocus التخلي عن طلبات التركيز الموجودة على HAL للاستخدام المحدد ومعرف المنطقة.

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

بخلاف registerFocusListener ، تعد هذه الطلبات oneway لضمان عدم تأخير Android لـ HAL أثناء معالجة طلب التركيز. يجب ألا ينتظر HAL للحصول على التركيز قبل تشغيل الأصوات المهمة للسلامة. إنه أمر اختياري لـ HAL للاستماع إلى التغييرات في التركيز الصوتي والاستجابة لها من خلال IAudioControl#onAudioFocusChange .

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

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

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

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

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

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

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

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

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