قبل از شروع یک جریان منطقی، برنامه درخواست فوکوس صوتی را با استفاده از همان ویژگیهای صوتی که برای جریان منطقی استفاده میشود، میدهد. برنامه باید تلفات فوکوس را در نظر بگیرد تا مطابق انتظار در موارد استفاده خودرو عمل کند.
اگرچه ارسال درخواست فوکوس توصیه میشود، اما توسط سیستم اعمال نمیشود. بنابراین، فوکوس را به عنوان وسیلهای برای کنترل غیرمستقیم و جلوگیری از تداخل در طول پخش در نظر بگیرید، نه به عنوان یک مکانیسم کنترل صوتی اصلی. وسیله نقلیه نباید برای عملکرد زیرسیستم صوتی به سیستم فوکوس وابسته باشد.
تعاملات متمرکز
برای پشتیبانی از AAOS، درخواستهای فوکوس صوتی بر اساس تعاملات از پیش تعریفشده بین CarAudioContext درخواست و دارندگان فوکوس فعلی مدیریت میشوند. سه نوع تعامل وجود دارد:
- اختصاصی
- رد کردن
- همزمان
تعامل انحصاری
این مدل تعاملی است که معمولاً در اندروید استفاده میشود.
در تعاملات انحصاری ، فقط یک برنامه مجاز است که در یک زمان فوکوس را نگه دارد. بنابراین، به یک درخواست فوکوس ورودی، فوکوس اعطا میشود در حالی که دارنده فوکوس موجود، فوکوس را از دست میدهد. از آنجایی که هر دو برنامه رسانه پخش میکنند، فقط به یک برنامه اجازه داده میشود که فوکوس را نگه دارد. در نتیجه، درخواست فوکوس برنامه تازه شروع شده با AUDIOFOCUS_REQUEST_GRANTED برگردانده میشود در حالی که برنامه موسیقی در حال پخش فعلی، یک رویداد تغییر فوکوس با وضعیت از دست دادن که مطابق با نوع درخواست ارسال شده است، دریافت میکند.
رد تعامل
با تعاملات رد ، درخواست ورودی همیشه رد میشود. برای مثال، هنگام تلاش برای پخش موسیقی در حین تماس. در این حالت، اگر شمارهگیر فوکوس صوتی را برای یک تماس نگه دارد و برنامه دوم درخواست فوکوس برای پخش موسیقی را داشته باشد، برنامه موسیقی در پاسخ به درخواست، AUDIOFOCUS_REQUEST_FAILED دریافت میکند. از آنجایی که درخواست فوکوس رد میشود، هیچ گونه از دست دادن فوکوس به دارنده فوکوس فعلی ارسال نمیشود.
تعامل همزمان
تعاملات همزمان منحصر به فرد AAOS هستند. این به برنامههایی که درخواست فوکوس صوتی در خودرو را دارند، این امکان را میدهد که همزمان با سایر برنامهها، فوکوس را حفظ کنند. برای اینکه یک تعامل همزمان رخ دهد، باید شرایط زیر رعایت شود. موارد زیر:
درخواست فوکوس ورودی باید AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK را درخواست کند.
نگهدارندهی فوکوس فعلی ، setPauseWhenDucked(true) را انجام نمیدهد.
دارنده فعلی تمرکز، رویدادهای اردکی را دریافت نمیکند.
اگر این معیارها برآورده شوند، درخواست فوکوس با AUDIOFOCUS_REQUEST_GRANTED برمیگردد در حالی که دارنده فوکوس فعلی هیچ تغییری در فوکوس ندارد. با این حال، اگر دارنده فوکوس فعلی تصمیم بگیرد که رویدادهای duck را دریافت کند یا هنگام duck شدن مکث کند، دارنده فوکوس فعلی فوکوس را از دست میدهد، همانطور که در یک تعامل انحصاری اتفاق میافتد.
مدیریت جریانهای همزمان
اگرچه تعامل همزمان کاربردهای بیشماری دارد، اما در سطح سختافزاری در دستگاههای خروجی، در مورد ترکیب و ادغام بین آنها مراقب باشید. اکیداً توصیه میکنیم نمونههایی از CarAudioContext که مجاز به پخش همزمان هستند، به دستگاههای خروجی مختلف هدایت شوند.
با داشتن دستگاههای خروجی جداگانه برای جریانهای همزمان، این امر HAL را قادر میسازد تا قبل از ترکیب کردن یکی از جریانها، آنها را حذف کند، یا جریانهای فیزیکی را به بلندگوهای مختلف در وسیله نقلیه هدایت کند. اگر جریانهای منطقی در اندروید ترکیب شوند، بهرهها بدون تغییر باقی میمانند و به عنوان بخشی از همان جریان فیزیکی ارائه میشوند.
برای مثال، وقتی ناوبری و رسانه به طور همزمان ارائه میشوند، میتوان بهره جریان رسانه را موقتاً کاهش داد (یا کم کرد) تا دستورالعملهای ناوبری واضحتر شنیده شوند. از طرف دیگر، میتوان جریان ناوبری را به بلندگوهای سمت راننده هدایت کرد در حالی که رسانه همچنان در بقیه کابین پخش میشود.
ماتریس برهمکنش
این جدول ماتریس تعامل را همانطور که توسط CarAudioService تعریف شده است، نشان میدهد. هر سطر نشان دهنده CarAudioContext دارنده فوکوس فعلی و هر ستون نشان دهنده درخواست ورودی است.
برای مثال، وقتی یک برنامهی رسانهی موسیقی فوکوس را نگه میدارد در حالی که یک برنامهی ناوبری درخواست فوکوس میکند، ماتریس نشان میدهد که دو تعامل میتوانند همزمان پخش شوند، با فرض اینکه سایر معیارهای تعاملات همزمان برآورده شده باشند.
به دلیل تعاملات همزمان، میتوان بیش از یک دارنده تمرکز داشت. در این حالت، یک درخواست تمرکز ورودی قبل از تعیین اینکه چه تعاملی اعمال شود، با هر یک از دارندگان تمرکز فعلی مقایسه میشود. در این حالت، محافظهکارترین تعامل برنده میشود. رد، سپس انحصاری و در نهایت همزمان.
شکل ۱. ماتریس تعامل فوکوس صوتی.
ناوبری در طول تماسهای تلفنی
در اندروید ۱۱، یک تنظیم جدید برای کاربر معرفی شد که به کاربران اجازه میدهد رفتار تعامل بین ناوبری و تماسهای تلفنی را تغییر دهند. وقتی android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL تنظیم شود، تعامل بین درخواستهای فوکوس ورودی NAVIGATION و دارندگان فوکوس فعلی CALL را از همزمان به رد تغییر میدهد. اگر کاربری ترجیح میدهد دستورالعملهای ناوبری تماس را قطع نکنند، میتواند این تنظیم را فعال کند. این برای کاربر ثابت است و میتواند به صورت پویا تنظیم شود تا درخواستهای فوکوس بعدی از تنظیمات جدید پیروی کنند.
فوکوس صوتی با تأخیر
در اندروید ۱۱، AAOS پشتیبانی از درخواست فوکوس صوتی با تأخیر را اضافه کرد. این امر به درخواستهای فوکوس غیرگذرا اجازه میدهد تا زمانی که تعامل آنها با دارندگان فوکوس فعلی معمولاً منجر به رد آنها میشود، به تأخیر بیفتند. هنگامی که تغییر در فوکوس منجر به وضعیتی شود که درخواست تأخیر یافته بتواند فوکوس را به دست آورد، درخواست پذیرفته میشود.
قوانین مربوط به درخواستهای فوکوس صوتی با تأخیر
فقط درخواستهای غیرگذرا. درخواست با تأخیر فقط میتواند برای منابع غیرگذرا انجام شود تا از پخش صدای گذرا مدتها پس از مرتبط بودن آن جلوگیری شود.
فقط یک درخواست میتواند در یک زمان به تأخیر بیفتد. اگر یک درخواست با قابلیت تأخیر در حالی که از قبل یک درخواست با تأخیر وجود دارد، ارسال شود، درخواست با تأخیر اصلی یک رویداد تغییر
AUDIOFOCUS_LOSSدریافت میکند و درخواست جدید یک پاسخ همزمانAUDIOFOCUS_REQUEST_DELAYEDدریافت میکند.درخواستهای دارای تأخیر باید دارای
OnAudioFocusChangeListenerباشند. پس از تأخیر در یک درخواست، از شنونده برای اطلاعرسانی به درخواستکننده در مورد اعطای نهایی درخواست (AUDIOFOCUS_GAIN) یا در صورت رد شدن بعدی (AUDIOFOCUS_LOSS) استفاده میشود.
درخواست فوکوس با تأخیر
برای ایجاد درخواستی که میتوان آن را به تأخیر انداخت:
از
AudioFocusRequest.Builder#setAcceptsDelayedFocusGainاستفاده کنید.mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener(); mDelayedFocusRequest = new AudioFocusRequest .Builder(AudioManager.AUDIOFOCUS_GAIN) .setAudioAttributes(mMusicAudioAttrib) .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener) .setForceDucking(false) .setWillPauseWhenDucked(false) .setAcceptsDelayedFocusGain(true) .build();هنگام ارسال درخواست، پاسخ
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; }وقتی درخواست به تأخیر میافتد، شنوندهی focus تغییرات در focus را مدیریت میکند:
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
محو شدن اجباری سیستم
اندروید ۱۵ در AAOS قابلیت محو شدن صدا توسط سیستم را معرفی میکند. در اندروید، فوکوس صدا توسط سیستم اعمال نمیشود. بنابراین، اگرچه به توسعهدهندگان برنامه توصیه میشود که از دستورالعملهای فوکوس صدا پیروی کنند، اما اگر یک برنامه حتی پس از از دست دادن فوکوس صدا، همچنان با صدای بلند پخش شود، سیستم نمیتواند از آن جلوگیری کند.
در محیطهای حساس به ایمنی خودرو، پایبندی به تمرکز صوتی برای به حداقل رساندن حواسپرتی راننده حیاتی است. با این ویژگی، چارچوب صوتی اکنون به طور خودکار برنامههایی را که تمرکز صوتی خود را از دست میدهند، محو میکند تا تجربه صوتی کنترلشدهتر و قابل پیشبینیتری داشته باشید.
این بهبود به اطمینان از پایبندی برنامهها به تصمیم از دست دادن فوکوس صوتی، همانطور که توسط ماتریس تعامل تعریف شده است، کمک میکند و از تداخل پخش صدا جلوگیری میکند.
طراحی سطح بالا
شکل زیر طراحی سطح بالا و پشتیبانی از ویژگی از دست دادن فوکوس در خودروها را نشان میدهد:

شکل ۲. طراحی سطح بالا برای ویژگی محوشدگی اعمالشده توسط سیستم.
- محو شدن هدفمند: اعمال سیستمی محو شدن در اندروید ۱۵ بهطور خاص برای موقعیتهایی طراحی شده است که یک برنامه تمرکز صوتی را از دست میدهد اما همچنان به پخش صدا ادامه میدهد.
- مکانیزم محو شدن: وقتی یک برنامه تمرکز صوتی خود را به یک برنامه درخواست کننده جدید از دست میدهد:
- چارچوب صوتی به طور خودکار صدای برنامهی از دست رفته را محو میکند.
- پس از محو شدن، جریان صدا توسط سیستم خاموش میشود.
- سپس برنامه یک اعلان صوتی مبنی بر از دست دادن فوکوس دریافت میکند.
- برنامههای بدرفتار تا زمانی که فوکوس صوتی خود را بازیابند، بیصدا میشوند.
- منطق پیشفرض این است که برنامههایی که پس از ۲ ثانیه محو میشوند، محو شوند. با این حال، تولیدکنندگان اصلی تجهیزات (OEM) میتوانند این مقدار را روی هر مقدار زمان انتظاری پیکربندی کنند.
- چارچوب صوتی از پیکربندیهای OEM برای عملیات محو شدن و محو شدن استفاده میکند.
فایل پیکربندی OEM: اندروید ۱۵ شامل یک فایل پیکربندی جدید به نام
car_audio_fade_configuration.xmlاست:- این فایل به تولیدکنندگان اصلی تجهیزات (OEM) اجازه میدهد تا معیارهایی را برای زمان اعمال تمرکز صوتی سیستم بر روی یک برنامهی در حال از دست دادن تعریف کنند.
- چارچوب صوتی، محو شدن و بیصدا کردن را تنها در صورتی اعمال میکند که برنامهی بازنده با قوانین تعریفشده توسط OEM در این فایل XML مطابقت داشته باشد.
- این مکانیزمی را برای تولیدکنندگان اصلی تجهیزات (OEM) فراهم میکند تا رفتار این ویژگی را بر اساس ویژگیهای برنامه یا انواع استفاده از صدا سفارشیسازی کنند.
کنترل ویژگی با RRO: یک پرچم ویژگی جدید برای پوشش منابع زمان اجرا (RRO) با نام
audioUseFadeManagerConfigurationبرای فعال یا غیرفعال کردن این ویژگی معرفی شده است:- این ویژگی به طور پیشفرض غیرفعال است.
- برای فعال کردن فوکوس صوتی اعمالشده توسط سیستم، تولیدکنندگان اصلی تجهیزات (OEM) باید این پرچم را روی
trueتنظیم کنند. - اگرچه چارچوب صوتی خودرو هنگام فعال بودن پرچم، تعاریف پیکربندی محو معتبری را انتظار دارد، اما فقدان چنین تعاریفی به طور خودکار منجر به یک استثنای مهلک نمیشود.
- تمام برنامههای مربوط به تنظیمات محو شدن صدا باید تعاریف محو شدن منطبقی داشته باشند. فراخوانی یک پیکربندی محو شدن (با توجه به نامش) به عنوان بخشی از پیکربندی سیستم صوتی خودرو بدون ارائه تعریف معتبر، یک خطای مهلک است.
- وقتی پرچم غیرفعال باشد، تمام تعاریف پیکربندی محو شدن و هرگونه ارجاع پیکربندی نادیده گرفته میشوند.
پیکربندی مدیریت محو شدن
چارچوب صوتی اندروید ۱۵ یک FadeManagerConfiguration یکپارچه را معرفی میکند تا به تولیدکنندگان اصلی تجهیزات (OEM) کنترل دقیقی بر رفتار محو شدن صدا ارائه دهد. این چارچوب در شکل ۳ نشان داده شده است:

شکل ۳. پیکربندی مدیر محو شدن.
این پیکربندی شامل موارد زیر است:
- ویژگیهای گذار محو شدن: تنظیمات برای محو شدن تدریجی و محو شدن تدریجی.
- میتواند با کاربردها یا ویژگیهای صوتی خاص تعریف شود.
- امکان تنظیمات مدت زمان سفارشی را فراهم میکند.
- این تنظیمات برای ساخت
VolumeShaper.Configurationاستفاده میشوند.
- سیاستهای محو شدن: قوانینی که زمان وقوع محو شدن را کنترل میکنند.
- یک دکمهی سراسری برای فعال یا غیرفعال کردن محو شدن.
- فهرستی قابل تنظیم از کاربردهای صوتی محوشونده (که در صورت از دست دادن فوکوس، محو میشوند).
- لیستهای استثنا (غیرقابل محو شدن) از محو شدن منابع صوتی حیاتی یا تعیینشده جلوگیری میکنند. این لیستها میتوانند بر اساس موارد زیر باشند:
- انواع محتوا
- ویژگیهای صوتی
- شناسههای کاربری برنامه (فقط در زمان اجرا قابل تنظیم هستند)
پیکربندیهای OEM
در این بخش، به سفارشیسازیهای موجود برای OEMها نگاهی میاندازیم.
فایل XML پیکربندی محو شدن صدای خودرو
اندروید ۱۵ یک فایل پیکربندی جدید به نام car_audio_fade_configuration.xml معرفی میکند که امکان سفارشیسازی گسترده OEM از رفتار محو شدن صدا در هنگام از دست دادن فوکوس را فراهم میکند.
- این فایل XML امکان تعریف چندین پیکربندی محوشدگی مجزا را فراهم میکند که هر کدام برای ارجاع متقابل در
car_audio_configuration.xmlبه یک نام منحصر به فرد نیاز دارند. - این تنظیمات را میتوان به صورت انعطافپذیر در مناطق صوتی و پیکربندیهای منطقه مختلف اعمال کرد.
- نکته قابل توجه این است که هر پیکربندی محو شدن، صرفاً مقادیر مدت زمان را بر حسب میلیثانیه میپذیرد که سیستم سپس از آنها برای تولید داخلی
VolumeShaper.Configurationمربوطه استفاده میکند.
برای راهنمایی عملی در پیادهسازی، به پیکربندیهای نمونه ارائه شده برای شبیهساز واقع در device/generic/car/emulator/audio/car_audio_fade_configuration.xml مراجعه کنید.
فایل XML پیکربندی سیستم صوتی خودرو
اندروید ۱۵ فایل car_audio_configuration.xml بهروزرسانیشدهای را معرفی میکند که اکنون در نسخه ۴ قرار دارد و شامل تگهای جدید 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)مطابق با الزامات خاص محصول خود تنظیم کنند.

شکل ۴. نمودار توالی برای ویژگی محو شدن صدای خودرو.
مدیریت فوکوس چند منطقهای
برای خودروهایی که چندین ناحیه صوتی دارند، فوکوس صوتی برای هر ناحیه به طور مستقل مدیریت میشود. به این ترتیب، درخواست برای یک ناحیه، فوکوس نواحی دیگر را در نظر نمیگیرد و همچنین باعث نمیشود که دارندگان فوکوس در نواحی دیگر فوکوس را از دست بدهند. با این کار، فوکوس کابین اصلی میتواند جداگانه از سیستم سرگرمی صندلی عقب مدیریت شود و در نتیجه پخش صدا در یک ناحیه با تغییر فوکوس در ناحیه دیگر قطع نشود.
برای همه برنامهها، 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
این پارامتر bundle به درخواستکننده اجازه میدهد تا نگاشتهای خودکار منطقه صوتی را نادیده گرفته و از شناسه منطقه مشخصشده استفاده کند. بنابراین، یک برنامه میتواند درخواستهای جداگانهای برای مناطق صوتی مختلف صادر کند.
تمرکز صوتی HAL
با شروع از اندروید ۱۱، HAL قادر به درخواست فوکوس از طرف جریانهای خارجی است. اگرچه اختیاری است، استفاده از این APIها به شدت توصیه میشود تا صداهای خارجی بتوانند به عنوان مشارکتکنندگان بهینه در اکوسیستم اندروید عمل کنند و یک تجربه کاربری یکپارچه ارائه دهند.
HAL تصمیم نهایی را در مورد اینکه کدام صداها باید اولویت داشته باشند، میگیرد. تا این حد، صداهای اضطراری و ایمنی حیاتی باید صرف نظر از اینکه HAL دارای فوکوس صوتی باشد یا خیر، پخش شوند و حتی اگر HAL فوکوس صوتی خود را از دست بدهد، باید به پخش خود ادامه دهند. همین امر در مورد هر صدایی که طبق مقررات دولتی الزامی است نیز صادق است.
HAL باید هنگام پخش صداهای اضطراری یا حیاتی برای ایمنی، به طور فعال جریانهای اندروید را بیصدا کند تا از شنیده شدن واضح آنها اطمینان حاصل شود.
کنترل صوتی@2.0
نسخه ۲.۰ AudioControl HAL این APIهای جدید را معرفی میکند:
| رابط برنامهنویسی کاربردی | هدف |
|---|---|
IAudioControl#registerFocusListener | یک نمونه از IFocusListener با AudioControl HAL ثبت میکند. این شنونده، HAL را قادر میسازد تا فوکوس صوتی را درخواست و آن را لغو کند. HAl یک نمونه ICloseHandle ارائه میدهد تا اندروید از آن برای لغو ثبت شنونده استفاده کند. |
IAudioControl#onAudioFocusChange | تغییرات در وضعیت درخواستهای تمرکز انجام شده توسط HAL از طریق IFocusListener ، از جمله پاسخ به درخواستهای تمرکز اولیه، را به HAL اطلاع میدهد. |
IFocusListener#requestAudioFocus | درخواست تمرکز از طرف HAL برای یک کاربرد مشخص، شناسه منطقه و نوع افزایش تمرکز. |
IFocusListener#abandonAudioFocus | درخواستهای فوکوس HAL موجود را برای کاربرد و شناسه منطقه مشخصشده رها میکند. |
HAL میتواند همزمان چندین درخواست فوکوس داشته باشد، اما به یک درخواست برای هر بار استفاده و جفتسازی شناسه منطقه محدود میشود. اندروید فرض میکند که HAL بلافاصله پس از ارسال درخواست، شروع به پخش صدا برای یک استفاده میکند و تا زمانی که فوکوس را رها نکند، به این کار ادامه میدهد.
به غیر از registerFocusListener ، این درخواستها oneway هستند تا اطمینان حاصل شود که اندروید HAL را در حین پردازش درخواست فوکوس به تأخیر نمیاندازد. HAL نباید قبل از پخش صداهای حساس به ایمنی، منتظر دریافت فوکوس بماند. گوش دادن و پاسخ دادن به تغییرات در فوکوس صوتی از طریق IAudioControl#onAudioFocusChange برای HAL اختیاری است.
خدمات فوکوس صوتی خودرو OEM
در اندروید ۱۴، AAOS سرویسهای افزونهی خودرو OEM را معرفی کرد تا قابلیت پیکربندی برخی از اجزای خودرو را فراهم کند. برای سرویس افزونهی صدای خودرو ، سرویس افزونه به OEMها اجازه میدهد تا درخواستهای فوکوس دریافتشده توسط سرویس صدای خودرو را مدیریت کنند. این امر به OEMها انعطافپذیری بیشتری در زمینهی مدیریت فوکوس طبق قوانین و مقررات میدهد. به همین دلیل، تعامل فوکوس صوتی ممکن است بین تولیدکنندگان و از منطقهای به منطقهی دیگر متفاوت باشد. فرضیهی اصلی برای فوکوس صوتی همچنان پابرجاست، اینکه برنامهها باید برای مدیریت بهتر صدا و بهبود تجربهی کاربری، درخواست فوکوس کنند. به طور کلی، قوانین خاصی هنوز برای درخواست فوکوس صوتی توسط برنامهها اعمال میشود:
بدون هیچگونه توقف، برنامههای دارای اولویت بالای فوکوس صوتی (از جمله تماس تلفنی، هشدار اضطراری یا اعلان ایمنی) باید بتوانند فوکوس صوتی را به صورت گذرا یا دائمی به دست آورند.
در حالی که تمرکز رسانهای فعال است:
برنامههایی که درخواست تمرکز بر استفاده از تماس را دارند، باید بتوانند تماس را به صورت همزمان یا انحصاری دریافت کنند.
برنامههایی که درخواست تمرکز بر استفاده از ناوبری را دارند، باید بتوانند تمرکز بر ناوبری را به صورت همزمان یا انحصاری دریافت کنند.
برنامههایی که درخواست تمرکز بر استفاده از دستیار را دارند، باید بتوانند تمرکز بر استفاده را به صورت همزمان یا انحصاری دریافت کنند.
در حالی که برنامههای فوکوس صوتی با اولویت بالا (از جمله تماس تلفنی، هشدار اضطراری یا اعلان ایمنی) فعال هستند، هرگونه درخواست فوکوس صوتی با تأخیر ورودی باید در صورت لزوم پذیرفته یا به تأخیر بیفتد.
اگرچه این پیشنهادات جامع نیستند، اما میتوانند به برنامههایی که درخواست فوکوس میکنند کمک کنند تا در صورت عدم وجود صداهای با اولویت بالا، فوکوس را به دست آورند. حتی در حالی که صداهای با اولویت بالا فعال هستند، درخواستهای فوکوس با تأخیر همچنان باید رعایت شوند و باید بتوانند هنگام قطع صدای با اولویت بالا، فوکوس را به دست آورند.