فوکوس صوتی

قبل از شروع یک جریان منطقی، یک برنامه فوکوس صوتی را با استفاده از همان ویژگی های صوتی که برای جریان منطقی استفاده می شود درخواست می کند. برنامه باید به تلفات تمرکز احترام بگذارد تا مطابق انتظار در موارد استفاده از خودرو عمل کند.

در حالی که ارسال درخواست فوکوس توصیه می شود، توسط سیستم اجرا نمی شود. بنابراین، تمرکز را به‌عنوان وسیله‌ای برای کنترل غیرمستقیم و جلوگیری از تضاد در حین پخش به‌جای مکانیزم کنترل صوتی اولیه در نظر بگیرید. خودرو نباید برای عملکرد زیرسیستم صوتی به سیستم فوکوس وابسته باشد.

بر تعاملات تمرکز کنید

برای پشتیبانی از AAOS، درخواست‌های فوکوس صوتی بر اساس تعاملات از پیش تعریف‌شده بین CarAudioContext درخواست و دارندگان فوکوس فعلی انجام می‌شوند. سه نوع تعامل وجود دارد:

  • انحصاری
  • رد کردن
  • همزمان

تعامل انحصاری

این مدل تعاملی است که بیشتر در اندروید استفاده می شود.

در فعل و انفعالات انحصاری ، فقط یک برنامه مجاز است هر بار فوکوس را حفظ کند. بنابراین، به درخواست فوکوس دریافتی، فوکوس اعطا می شود در حالی که دارنده فوکوس موجود تمرکز خود را از دست می دهد. از آنجایی که هر دو برنامه رسانه پخش می کنند، فقط یک برنامه مجاز است فوکوس را حفظ کند. در نتیجه، درخواست تمرکز برنامه تازه راه‌اندازی شده با AUDIOFOCUS_REQUEST_GRANTED برگردانده می‌شود، در حالی که برنامه موسیقی در حال پخش فعلی یک رویداد تغییر تمرکز با وضعیت از دست دادن دریافت می‌کند که مطابق با نوع درخواستی است که انجام شده است.

تعامل را رد کنید

با تعاملات رد ، درخواست ورودی همیشه رد می شود. به عنوان مثال، هنگام تلاش برای پخش موسیقی در حالی که تماس در حال انجام است. در این حالت، اگر شماره‌گیر فوکوس صوتی را برای تماس نگه می‌دارد و برنامه دوم فوکوس را برای پخش موسیقی درخواست کند، برنامه موسیقی در پاسخ به درخواست AUDIOFOCUS_REQUEST_FAILED دریافت می‌کند. از آنجایی که درخواست فوکوس رد می شود، هیچ از دست دادن فوکوس به دارنده فوکوس فعلی ارسال نمی شود.

تعامل همزمان

منحصر به فرد AAOS تعاملات همزمان هستند. این به برنامه‌هایی که فوکوس صوتی را در خودرو درخواست می‌کنند، این توانایی را می‌دهد که فوکوس را همزمان با سایر برنامه‌ها حفظ کنند. برای انجام یک تعامل همزمان، شرایط زیر باید رعایت شود. :

اگر این معیارها برآورده شوند، درخواست فوکوس با AUDIOFOCUS_REQUEST_GRANTED برمی‌گردد در حالی که دارنده فوکوس فعلی تغییری در فوکوس ندارد. با این حال، اگر نگهدارنده فوکوس فعلی تصمیم بگیرد که رویدادهای اردک را دریافت کند یا در هنگام توقف مکث کند، دارنده فوکوس فعلی تمرکز را از دست می‌دهد، همانطور که در یک تعامل انحصاری اتفاق می‌افتد.

مدیریت جریان های همزمان

در حالی که تعامل همزمان کاربردهای متعددی دارد، در اختلاط و اتصال در سطح سخت افزار در دستگاه های خروجی مراقب باشید. ما قویاً توصیه می کنیم که نمونه هایی از CarAudioContext که اجازه پخش همزمان دارند باید به دستگاه های خروجی مختلف هدایت شوند.

با داشتن دستگاه‌های خروجی مجزا برای جریان‌های همزمان، این HAL را قادر می‌سازد تا یکی از جریان‌ها را قبل از اختلاط آن‌ها بکارد یا جریان‌های فیزیکی را به بلندگوهای مختلف خودرو هدایت کند. اگر جریان‌های منطقی در Android ترکیب شوند، سودها بدون تغییر می‌شوند و به عنوان بخشی از همان جریان فیزیکی ارائه می‌شوند.

به عنوان مثال، هنگامی که ناوبری و رسانه به طور همزمان ارائه می شوند، بهره برای جریان رسانه می تواند به طور موقت کاهش یابد (یا کاهش یابد) تا دستورالعمل های ناوبری با وضوح بیشتری شنیده شوند. از طرف دیگر، جریان ناوبری می تواند به بلندگوهای سمت راننده هدایت شود در حالی که پخش رسانه در بقیه کابین ادامه دارد.

ماتریس تعامل

این جدول ماتریس تعامل را همانطور که توسط CarAudioService تعریف شده است نشان می دهد. هر ردیف نشان دهنده CarAudioContext دارنده تمرکز فعلی و هر ستون نشان دهنده درخواست ورودی است.

به عنوان مثال، هنگامی که یک برنامه رسانه موسیقی فوکوس را به عنوان یک برنامه ناوبری درخواست فوکوس می کند، ماتریس نشان می دهد که دو تعامل می توانند همزمان پخش شوند، با فرض اینکه سایر معیارهای تعامل همزمان برآورده شده باشند.

به دلیل تعاملات همزمان، امکان داشتن بیش از یک نگهدارنده فوکوس وجود دارد. در این مورد، یک درخواست فوکوس دریافتی با هر یک از دارندگان تمرکز فعلی قبل از تعیین اینکه چه تعاملی باید اعمال شود، مقایسه می‌شود. در این حالت محافظه کارانه ترین تعامل برنده می شود. رد، سپس انحصاری، و در نهایت همزمان.

ماتریس تعامل فوکوس صوتی

شکل 1. ماتریس تعامل فوکوس صوتی.

در اندروید 11، تنظیمات کاربری جدیدی معرفی شد که به کاربران اجازه می‌دهد رفتار تعامل بین ناوبری و تماس‌های تلفنی را تغییر دهند. وقتی تنظیم شود، android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL تعامل بین درخواست‌های فوکوس NAVIGATION ورودی و دارندگان تمرکز CALL فعلی را از همزمان به رد تغییر می‌دهد. اگر کاربر ترجیح می‌دهد که دستورالعمل‌های ناوبری تماس را قطع نکند، می‌تواند تنظیمات را فعال کند. این برای کاربر ادامه دارد و می‌تواند به‌صورت پویا تنظیم شود تا درخواست‌های فوکوس بعدی به تنظیمات جدید احترام بگذارند.

فوکوس صوتی با تاخیر

در اندروید 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
    

سیستم محو شد

اندروید 15 محو شدن صدای سیستم را در AAOS معرفی می کند. در اندروید، فوکوس صوتی توسط سیستم اعمال نمی شود. بنابراین، در حالی که توسعه‌دهندگان برنامه تشویق می‌شوند از دستورالعمل‌های فوکوس صوتی پیروی کنند، اگر برنامه‌ای حتی پس از از دست دادن فوکوس صوتی به پخش با صدای بلند ادامه دهد، سیستم نمی‌تواند از آن جلوگیری کند.

در محیط‌های ایمنی حیاتی خودرو، رعایت فوکوس صوتی برای به حداقل رساندن حواس‌پرتی راننده ضروری است. با این ویژگی، چارچوب صوتی اکنون به طور خودکار برنامه هایی را که فوکوس صوتی را از دست می دهند، محو می کند تا تجربه صوتی کنترل شده و قابل پیش بینی بیشتری داشته باشد.

این بهبود کمک می‌کند تا اطمینان حاصل شود که برنامه‌ها به تصمیم کاهش فوکوس صوتی که توسط ماتریس تعامل تعریف شده است، پایبند هستند و از تداخل پخش صدا جلوگیری می‌کند.

طراحی سطح بالا

شکل زیر طراحی سطح بالا و پشتیبانی از ویژگی کاهش فوکوس را در خودروها نشان می دهد:

طراحی سطح بالا برای ویژگی محو شدن سیستم

شکل 2. طراحی سطح بالا برای ویژگی محو شدن سیستم.

  • محو شدن هدفمند: اجرای سیستم محو شدن در اندروید 15 به طور خاص برای موقعیت هایی طراحی شده است که برنامه فوکوس صوتی را از دست می دهد اما به پخش صدا ادامه می دهد.
  • مکانیسم محو شدن: زمانی که یک برنامه فوکوس صوتی را به یک برنامه درخواستی جدید از دست می دهد:
    • چارچوب صوتی به طور خودکار صدای برنامه از دست رفته را محو می کند.
    • پس از خاموش شدن، جریان صوتی توسط سیستم خاموش می شود.
    • سپس برنامه یک اعلان از دست دادن فوکوس صوتی دریافت می کند.
    • برنامه‌های دارای عملکرد نادرست تا زمانی که فوکوس صوتی را دوباره به دست آورند، بی‌صدا می‌شوند.
    • منطق پیش فرض محو شدن در برنامه هایی است که پس از 2 ثانیه محو می شوند. با این حال، OEM ها می توانند این را برای هر مقدار زمان بندی پیکربندی کنند.
    • چارچوب صوتی از تنظیمات OEM برای عملیات محو شدن و محو شدن استفاده می کند.
  • فایل پیکربندی OEM: Android 15 شامل یک فایل پیکربندی جدید، car_audio_fade_configuration.xml است:

    • این فایل به OEM ها اجازه می دهد تا معیارهایی را برای زمانی که اعمال فوکوس صوتی سیستم روی یک برنامه بازنده اعمال می شود، تعریف کنند.
    • چارچوب صوتی تنها در صورتی محو و خاموش شدن را اعمال می کند که برنامه بازنده با قوانین تعریف شده OEM در این فایل XML مطابقت داشته باشد.
    • این مکانیسمی را برای OEM ها فراهم می کند تا رفتار ویژگی را بر اساس ویژگی های برنامه یا انواع استفاده از صدا سفارشی کنند.
  • کنترل ویژگی با RRO: یک پرچم ویژگی جدید پوشش منبع زمان اجرا (RRO)، audioUseFadeManagerConfiguration ، برای فعال یا غیرفعال کردن این ویژگی معرفی شده است:

    • این ویژگی به طور پیش فرض غیرفعال است.
    • برای فعال کردن از دست دادن فوکوس صوتی توسط سیستم، OEM ها باید این پرچم را روی true تنظیم کنند.
    • اگر چه فریم ورک صوتی خودرو زمانی که پرچم فعال می‌شود، انتظار دارد که تنظیمات پیکربندی محو معتبر وجود داشته باشد، اما عدم وجود چنین تعاریفی به‌طور خودکار منجر به استثنای مرگ‌بار نمی‌شود.
    • همه برنامه‌های تنظیمات محو باید دارای تعاریف محو منطبق باشند. فراخوانی یک پیکربندی محو (با نام آن) به عنوان بخشی از پیکربندی صدای خودرو بدون ارائه تعریف معتبر، یک خطای مرگبار است.
    • هنگامی که پرچم غیرفعال است، تمام تعاریف پیکربندی محو شده و هر مرجع پیکربندی نادیده گرفته می شود.

پیکربندی مدیر محو شدن

چارچوب صوتی Android 15 یک پیکربندی یکپارچه FadeManagerConfiguration معرفی می کند تا OEM ها را با کنترل دانه ای بر رفتار محو شدن صدا ارائه دهد. این چارچوب در شکل 3 نشان داده شده است:

پیکربندی مدیر محو شدن

شکل 3. پیکربندی مدیر محو شدن.

این پیکربندی شامل:

  • ویژگی‌های انتقال محو شدن: تنظیمات هم برای محو شدن و هم برای محو شدن.
    • را می توان با کاربردها یا ویژگی های صوتی خاص تعریف کرد.
    • به تنظیمات مدت زمان سفارشی اجازه می دهد.
    • این تنظیمات برای ساخت VolumeShaper.Configuration استفاده می شود.
  • خط‌مشی‌های محو شدن: قوانینی که هنگام رخ دادن محو شدن، حاکم هستند.
    • یک کلید جهانی برای فعال یا غیرفعال کردن محو شدن.
    • فهرست قابل تنظیمی از موارد استفاده صوتی محو شونده (واجد شرایط برای محو شدن در صورت از دست دادن تمرکز).
    • لیست های حذف (غیرقابل محو شدن) از محو شدن منابع صوتی مهم یا تعیین شده جلوگیری می کند. این لیست ها را می توان بر اساس:
      • انواع محتوا
      • ویژگی های صوتی
      • UID های برنامه (فقط در زمان اجرا قابل تنظیم هستند)

تنظیمات OEM

در این بخش، ما به سفارشی سازی های OEM موجود نگاه می کنیم.

فایل XML پیکربندی محو صدای خودرو

اندروید 15 یک فایل پیکربندی جدید به نام car_audio_fade_configuration.xml را معرفی می‌کند که امکان سفارشی‌سازی گسترده OEM رفتار محو صدا را در هنگام از دست دادن فوکوس فراهم می‌کند.

  • این فایل XML امکان تعریف چندین پیکربندی محو متمایز را فراهم می کند، که هر کدام به یک نام منحصر به فرد برای ارجاع متقابل در car_audio_configuration.xml نیاز دارند.
  • این تنظیمات را می توان به طور انعطاف پذیر در مناطق مختلف صوتی و تنظیمات منطقه اعمال کرد.
  • قابل ذکر است، هر پیکربندی محو صرفاً مقادیر مدت زمان را بر حسب میلی ثانیه می پذیرد، که سپس سیستم از آن برای تولید داخلی VolumeShaper.Configuration مربوطه استفاده می کند.

برای راهنمایی پیاده سازی عملی، به نمونه پیکربندی های ارائه شده برای شبیه ساز واقع در device/generic/car/emulator/audio/car_audio_fade_configuration.xml مراجعه کنید.

فایل XML پیکربندی صوتی خودرو

اندروید 15 یک فایل car_audio_configuration.xml به روز شده را معرفی می کند که اکنون در نسخه 4 است، که دارای برچسب های applyFadeConfigs و fadeConfig جدید است. تگ applyFadeConfigs می‌تواند شامل چندین تعاریف fadeConfig باشد که امکان پیکربندی fade انعطاف‌پذیر را فراهم می‌کند. هر تعریف:

  • باید شامل یک fadeConfig پیش فرض باشد که با isDefault = true تعیین شده است.
  • می تواند شامل چندین تعریف fadeConfig گذرا باشد. این پیکربندی‌های گذرا به‌طور خاص در طول فعل و انفعالات از دست دادن فوکوس صوتی اعمال می‌شوند، و تنها زمانی که برنامه دریافت فوکوس صوتی با معیارهای تعریف شده در پیکربندی گذرا مطابقت داشته باشد.

برای راهنمایی پیاده سازی عملی، به نمونه پیکربندی های ارائه شده برای شبیه ساز واقع در device/generic/car/emulator/audio/car_audio_configuration.xml مراجعه کنید.

پسوند سرویس فوکوس صوتی OEM

OEM هایی که سرویس فوکوس صوتی خودروی سفارشی را اجرا می کنند، انعطاف پذیری دارند تا تنظیمات محو صدا را با گنجاندن آنها در OemCarAudioFocusResult پیکربندی کنند. این را می توان با استفاده از متد سازنده setAudioAttributesToCarAudioFadeConfigurationMap() بدست آورد:

/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
        Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}

قابل ذکر است، OEM ها می توانند از تنظیمات محو شدن زمان راه اندازی از پیش پیکربندی شده استفاده کنند یا به صورت پویا تنظیمات را از طریق سرویس فوکوس صوتی سفارشی خود اعمال کنند و کنترل قابل تطبیق را ارائه دهند.

نمودار توالی

این نمودار دنباله ای رفتار زیر را نشان می دهد که فوکوس صوتی به App2 اعطا می شود و متعاقباً از دست رفتن فوکوس صوتی توسط App1 :

  • هنگامی که سرویس صوتی خودرو از دست دادن فوکوس صوتی را به App1 ارسال می کند، پخش از پخش کننده App1 طبق تعریف FadeManagerConfiguration فعال، محو می شود. هنگامی که عملیات محو کردن کامل شد، App1 پاسخ تماس استاندارد از دست دادن فوکوس صوتی را دریافت می کند.
  • به صورت اختیاری، صدای App1 را می توان پس از یک مدت زمان قابل تنظیم دوباره محو کرد. OEM ها این انعطاف پذیری را دارند که این مدت زمان را از طریق Builder#setFadeInDurationForUsage(int, long) با توجه به نیازهای محصول خاص خود تنظیم کنند.

نمودار توالی برای ویژگی محو صدای خودرو

شکل 4. نمودار توالی برای ویژگی محو صدای خودرو.

مدیریت فوکوس چند منطقه ای

برای وسایل نقلیه با چندین منطقه صوتی، فوکوس صوتی به طور مستقل برای هر منطقه مدیریت می شود. به این ترتیب، درخواست به یک منطقه، آنچه را که در مناطق دیگر فوکوس می‌کند، در نظر نمی‌گیرد، و همچنین باعث می‌شود که دارندگان فوکوس در مناطق دیگر تمرکز خود را از دست بدهند. با این کار، می‌توان فوکوس کابین اصلی را به‌طور جداگانه از سیستم سرگرمی صندلی‌های عقب مدیریت کرد، در نتیجه پخش صدا در یک منطقه با تغییرات ایجاد شده در فوکوس به منطقه دیگر قطع نمی‌شود.

برای همه برنامه ها، 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

این پارامتر بسته به درخواست‌کننده اجازه می‌دهد تا نگاشت‌های منطقه صوتی خودکار را لغو کند تا در عوض از شناسه منطقه مشخص‌شده استفاده کند. بنابراین، یک برنامه می تواند درخواست های جداگانه ای برای مناطق مختلف صوتی صادر کند.

فوکوس صوتی HAL

با شروع اندروید 11، HAL برای درخواست تمرکز از طرف جریان‌های خارجی فعال است. در حالی که اختیاری است، استفاده از این APIها برای فعال کردن صداهای خارجی برای مشارکت بهینه در اکوسیستم اندروید و ارائه یک تجربه کاربری یکپارچه بسیار تشویق می شود.

HAL تعیین نهایی را انجام می دهد که کدام صداها باید اولویت داشته باشند. در این حد، صداهای بحرانی اضطراری و ایمنی باید بدون توجه به اینکه آیا HAL فوکوس صوتی دارد یا خیر پخش شود و حتی اگر HAL فوکوس صوتی را از دست بدهد باید به همان اندازه پخش شود. همین امر برای هر صدایی که توسط مقررات دولتی لازم است صادق است.

هنگام پخش صداهای اضطراری یا حیاتی ایمنی، HAL باید به طور فعال جریان‌های Android را قطع کند تا مطمئن شود که به وضوح شنیده می‌شوند.

AudioControl@2.0

نسخه 2.0 AudioControl HAL این API های جدید را معرفی می کند:

API هدف
IAudioControl#registerFocusListener یک نمونه از IFocusListener را با AudioControl HAL ثبت می کند. این شنونده HAL را قادر می سازد تا فوکوس صوتی را درخواست کند و از آن صرف نظر کند. HAl یک نمونه ICloseHandle را برای استفاده توسط Android برای لغو ثبت شنونده ارائه می دهد.
IAudioControl#onAudioFocusChange HAL را از تغییرات وضعیت درخواست‌های فوکوس که توسط HAL از طریق IFocusListener انجام می‌شود، از جمله پاسخ‌ها به درخواست‌های تمرکز اولیه، مطلع می‌کند.
IFocusListener#requestAudioFocus برای استفاده مشخص، شناسه منطقه و نوع فوکوس فوکوس از طرف HAL ​​درخواست می کند.
IFocusListener#abandonAudioFocus درخواست‌های فوکوس HAL موجود برای استفاده مشخص شده و شناسه منطقه را رها می‌کند.

HAL می‌تواند چندین درخواست فوکوس را همزمان داشته باشد، اما به یک درخواست در هر استفاده و جفت‌سازی شناسه منطقه محدود می‌شود. Android فرض می کند که HAL بلافاصله پس از درخواست، شروع به پخش صداها برای استفاده می کند و این کار را تا زمانی که تمرکز را رها کند، ادامه می دهد.

به غیر از registerFocusListener ، این درخواست‌ها برای اطمینان از عدم تأخیر HAL در هنگام پردازش درخواست تمرکز، oneway هستند. HAL نباید منتظر بماند تا قبل از پخش صداهای مهم ایمنی، تمرکز کند. برای HAL اختیاری است که از طریق IAudioControl#onAudioFocusChange به تغییرات فوکوس صوتی گوش دهد و به آنها پاسخ دهد.

خدمات فوکوس صوتی خودرو OEM

در اندروید 14، AAOS خدمات پلاگین OEM خودرو را برای فعال کردن پیکربندی برای برخی از اجزای خودرو معرفی کرد. برای سرویس پلاگین صدای خودرو ، سرویس پلاگین به OEM ها اجازه می دهد تا درخواست های فوکوس رهگیری شده توسط سرویس صوتی خودرو را مدیریت کنند. این به OEM ها از نظر مدیریت تمرکز مطابق با قوانین و مقررات انعطاف بیشتری می دهد. به این ترتیب، تعامل فوکوس صوتی ممکن است بین سازنده ها و از منطقه ای به منطقه دیگر متفاوت باشد. فرض اصلی برای فوکوس صوتی همچنان پابرجاست، این که برنامه ها همچنان باید برای مدیریت بهتر صدا برای بهبود تجربه کاربر، فوکوس را درخواست کنند. به طور کلی، قوانین خاصی همچنان برای درخواست فوکوس صوتی توسط برنامه ها اعمال می شود:

  • برنامه‌های بدون فوکوس صوتی با اولویت بالا (از جمله تماس تلفنی، هشدار اضطراری یا اعلان ایمنی) باید بتوانند فوکوس صوتی را به‌طور موقت یا دائم به دست آورند.

  • در حالی که تمرکز رسانه فعال است:

    • برنامه‌هایی که فوکوس استفاده از تماس را درخواست می‌کنند باید بتوانند تماس را به صورت همزمان یا انحصاری دریافت کنند.

    • برنامه‌هایی که فوکوس استفاده از ناوبری را درخواست می‌کنند باید بتوانند فوکوس ناوبری را به صورت همزمان یا انحصاری دریافت کنند.

    • برنامه‌هایی که فوکوس استفاده از دستیار را درخواست می‌کنند باید بتوانند فوکوس استفاده را همزمان یا انحصاری دریافت کنند.

  • در حالی که برنامه‌های فوکوس صوتی با اولویت بالا (از جمله تماس تلفنی، هشدار اضطراری یا اعلان ایمنی) فعال هستند، هر درخواست فوکوس صوتی تاخیری دریافتی باید در صورت نیاز اعطا یا به تعویق بیفتد.

اگرچه این پیشنهادات جامع نیستند، اما می‌توانند به برنامه‌هایی که فوکوس را درخواست می‌کنند کمک کنند تا در صورت عدم وجود صداهای با اولویت بالا، فوکوس را به دست آورند. حتی زمانی که صداهای با اولویت بالا فعال هستند، درخواست‌های فوکوس تأخیری همچنان باید رعایت شوند و زمانی که صدای اولویت بالا متوقف می‌شود، باید بتوان فوکوس را به دست آورد.