לפני הפעלת מקור נתונים לוגי, אפליקציה מבקשת מיקוד שמע באמצעות אותם מאפייני שמע שמשמשים למקור הנתונים הלוגי. האפליקציה צריכה להתייחס לשינויים במיקוד כדי לפעול כצפוי בתרחישי שימוש ברכב.
מומלץ לשלוח בקשה להעברת המיקוד, אבל המערכת לא מחייבת זאת. לכן, כדאי להתייחס למיקוד כאמצעי לשליטה עקיפה במצב של חוסר התאמה במהלך ההפעלה, ולא כמנגנון ראשי לשליטה באודיו. הפעולה של מערכת המשנה של האודיו ברכב לא צריכה להיות תלויה במערכת המיקוד.
אינטראקציות עם מיקוד
כדי לתמוך ב-AAOS, בקשות למיקוד אודיו מטופלות על סמך אינטראקציות מוגדרות מראש בין CarAudioContext
של הבקשה לבין של בעלי המיקוד הנוכחיים. יש שלושה סוגים של אינטראקציות:
- בלעדי
- דחייה
- בו-זמנית
אינטראקציה בלעדית
זהו מודל האינטראקציה הנפוץ ביותר ב-Android.
באינטראקציות בלעדיות, רק אפליקציה אחת יכולה להיות במרכז בכל פעם.
לכן, בקשת פוקוס נכנסת מקבלת פוקוס, בעוד שהרכיב הקיים שמחזיק בפוקוס מאבד אותו. מכיוון ששתי האפליקציות מפעילות מדיה, רק לאחת מהן מותר להחזיק במיקוד. כתוצאה מכך, בקשת המיקוד של האפליקציה שהופעלה לאחרונה מוחזרת עם
AUDIOFOCUS_REQUEST_GRANTED
, ואילו אפליקציית המוזיקה שפועלת כרגע מקבלת אירוע של שינוי המיקוד עם סטטוס של אובדן שמתאים לסוג הבקשה שהוגשה.
דחיית האינטראקציה
באינטראקציות מסוג דחייה, הבקשה הנכנסת תמיד נדחית. לדוגמה, כשמנסים להפעיל מוזיקה בזמן שיחה. במקרה הזה, אם לאפליקציית חייגן יש מיקוד אודיו לשיחה ואפליקציה שנייה מבקשת מיקוד כדי להפעיל מוזיקה, אפליקציית המוזיקה מקבלת AUDIOFOCUS_REQUEST_FAILED
בתגובה לבקשה. מאחר שבקשת הפוקוס נדחית, לא מתבצעת שליחה של אובדן פוקוס לבעלים הנוכחי של הפוקוס.
אינטראקציה בו-זמנית
תכונה ייחודית ל-AAOS היא אינטראקציות בו-זמניות. כך אפליקציות שמבקשות מיקוד שמע ברכב יכולות להחזיק במיקוד במקביל לאפליקציות אחרות. כדי שאינטראקציה תתבצע בו-זמנית, צריכים להתקיים התנאים הבאים. ה:
בקשת המיקוד הנכנסת צריכה לבקש AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK
המשתמש הנוכחי שמחזיק במיקוד לא setPauseWhenDucked(true)
המשתמש הנוכחי שמחזיק במיקוד בוחר לא לקבל אירועים של הנמכת עוצמת קול של אודיו
אם הקריטריונים האלה מתקיימים, הבקשה להעברת המיקוד מוחזרת עם AUDIOFOCUS_REQUEST_GRANTED
, והמיקוד של מי שמחזיק בו כרגע לא משתנה. עם זאת, אם מי שמחזיק כרגע במיקוד בוחר לקבל אירועי הנמכה או להשהות את עצמו כשהוא מונמך, הוא מאבד את המיקוד, כמו שקורה באינטראקציה בלעדית.
טיפול בשידורים חיים בו-זמניים
לאינטראקציה בו-זמנית יש שימושים רבים, אבל צריך להיזהר כשמערבבים ומנמיכים את עוצמת הקול ברמת החומרה במכשירי פלט שונים. מומלץ מאוד להפנות מופעים של CarAudioContext
שמורשים להפעלה בו-זמנית למכשירי פלט שונים.
השימוש במכשירי פלט נפרדים לשידורים מקבילים מאפשר ל-HAL להנמיך את אחד השידורים לפני המיזוג שלהם, או לנתב את השידורים הפיזיים לרמקולים שונים ברכב. אם הזרמים הלוגיים מעורבבים ב-Android, עוצמת הקול לא משתנה והם מועברים כחלק מאותו זרם פיזי.
לדוגמה, כשמפעילים ניווט ומדיה בו-זמנית, יכול להיות שההגברה של זרם המדיה תופחת זמנית (או תונמך) כדי שאפשר יהיה לשמוע את הוראות הניווט בצורה ברורה יותר. לחלופין, אפשר להפנות את זרם הניווט לרמקולים בצד הנהג, בזמן שהמדיה ממשיכה לפעול בכל שאר תא הנוסעים.
מטריצת אינטראקציות
בטבלה הזו מוצגת מטריצת האינטראקציות כפי שהוגדרה על ידי CarAudioService
.
כל שורה מייצגת את CarAudioContext
של בעל המיקוד הנוכחי, וכל עמודה מייצגת את CarAudioContext
של הבקשה הנכנסת.
לדוגמה, אם אפליקציית מדיה של מוזיקה נמצאת במוקד ואפליקציית ניווט מבקשת את המוקד, המטריצה מציינת שאפשר להפעיל את שתי האינטראקציות בו-זמנית, בהנחה שמתקיימים הקריטריונים האחרים לאינטראקציות בו-זמניות.
בגלל האינטראקציות המקבילות, יכול להיות שיותר מרכיב אחד יקבל את המיקוד. במקרה כזה, בקשת מיקוד נכנסת מושווית לכל אחד מהרכיבים שמחזיקים כרגע במיקוד, לפני שנקבעת האינטראקציה שתופעל. במקרה הזה, האינטראקציה הכי שמרנית היא זו שתקבע. דחייה, לאחר מכן בלעדיות ולבסוף בו-זמניות.
איור 1. מטריצת אינטראקציות של מיקוד אודיו.
ניווט במהלך שיחות טלפון
ב-Android 11, נוספה הגדרת משתמש חדשה שמאפשרת למשתמשים לשנות את התנהגות האינטראקציה בין הניווט לבין שיחות טלפון. אם המאפיין מוגדר, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL
משנה את האינטראקציה בין בקשות נכנסות למיקוד NAVIGATION
לבין בעלי המיקוד הנוכחיים CALL
ממקבילות לדחייה. אם משתמש מעדיף שהוראות הניווט לא יקטעו את השיחה, הוא יכול להפעיל את ההגדרה. ההגדרה הזו נשמרת עבור המשתמש, ואפשר להגדיר אותה באופן דינמי כך שבקשות מיקוד עוקבות יתחשבו בהגדרה החדשה.
הרשאת אודיו עם השהיה
ב-Android 11, AAOS הוסיפה תמיכה בבקשת פוקוס אודיו עם השהיה. כך אפשר לדחות בקשות מיקוד לא זמניות, אם האינטראקציה שלהן עם בעלי המיקוד הנוכחיים בדרך כלל תוביל לדחייה שלהן. אם שינוי המיקוד יוביל למצב שבו הבקשה המושהית תוכל לקבל מיקוד, הבקשה תאושר.
כללים לבקשות מושהות למיקוד אודיו
רק בקשות לא זמניות. אפשר להגיש בקשה להשהיה רק לגבי מקורות לא זמניים, כדי למנוע מצב שבו צליל זמני יושמע הרבה אחרי שהוא כבר לא רלוונטי.
אפשר לדחות רק בקשה אחת בכל פעם. אם מתקבלת בקשה שאפשר לדחות בזמן שיש כבר בקשה שנדחתה, הבקשה המקורית שנדחתה מקבלת אירוע שינוי
AUDIOFOCUS_LOSS
והבקשה החדשה מקבלת תשובה סינכרונית שלAUDIOFOCUS_REQUEST_DELAYED
.בקשות שאפשר לדחות צריכות לכלול את
OnAudioFocusChangeListener
. אחרי שהבקשה מתעכבת, נעשה שימוש ב-listener כדי להודיע לשולח הבקשה כשהבקשה מאושרת בסופו של דבר (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; }
כשהבקשה מתעכבת, מאזין המיקוד מטפל בשינויים במיקוד:
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
הנמכה אוטומטית של עוצמת הקול
ב-Android 15, נוסף אפקט הדהייה של האודיו ב-AAOS. ב-Android, המערכת לא אוכפת את המיקוד באודיו. לכן, למרות שמפתחי אפליקציות מעודדים לפעול בהתאם להנחיות בנושא מיקוד אודיו, אם אפליקציה ממשיכה להשמיע אודיו בעוצמה גבוהה גם אחרי שהיא מאבדת את מיקוד האודיו, המערכת לא יכולה למנוע זאת.
בסביבות רכב שבהן הבטיחות היא קריטית, הקפדה על מיקוד האודיו חיונית כדי למזער את הסחת הדעת של הנהג. התכונה הזו מאפשרת למסגרת האודיו להנמיך באופן אוטומטי את עוצמת הקול באפליקציות שאיבדו את מיקוד האודיו, כדי ליצור חוויית אודיו צפויה ומבוקרת יותר.
השיפור הזה עוזר לוודא שהאפליקציות פועלות בהתאם להחלטה לגבי אובדן המיקוד של האודיו, כפי שמוגדר במטריצת האינטראקציות, וכך למנוע קונפליקטים בהפעלת אודיו.
עיצוב ברמה גבוהה
באיור הבא מוצג העיצוב הכללי והתמיכה בתכונה של איבוד הפוקוס במכוניות:
איור 2. עיצוב כללי של תכונת ההנמכה שנאכפת על ידי המערכת.
- הנמכה ממוקדת: האכיפה של הנמכה במערכת ב-Android 15 מיועדת במיוחד למצבים שבהם אפליקציה מאבדת את פוקוס האודיו אבל ממשיכה להפעיל אודיו.
- מנגנון ההנמכה: כשאפליקציה מאבדת את המיקוד באודיו לטובת אפליקציה חדשה שמבקשת אותו:
- מסגרת האודיו מחלישה אוטומטית את האודיו של האפליקציה שהפסידה.
- אחרי ההנמכה, המערכת משתיקה את זרם האודיו.
- האפליקציה מקבלת התראה על אובדן המיקוד של האודיו.
- אפליקציות שמתנהגות בצורה לא תקינה מושתקות עד שהן מקבלות שוב את המיקוד באודיו.
- לוגיקת ברירת המחדל היא להחזיר את האפליקציות שהוצגו בצורה מטושטשת אחרי 2 שניות. עם זאת, יצרני ציוד מקורי יכולים להגדיר כל ערך של זמן קצוב לפעילות.
- מסגרת האודיו משתמשת בהגדרות OEM גם לפעולות של הנמכה הדרגתית וגם לפעולות של הגברה הדרגתית.
קובץ הגדרות של יצרן ציוד מקורי (OEM): ב-Android 15 יש קובץ הגדרות חדש,
car_audio_fade_configuration.xml
:- הקובץ הזה מאפשר ליצרני ציוד מקורי (OEM) להגדיר קריטריונים שלפיהם המערכת תחיל את ההגדרה של העברת פוקוס האודיו על אפליקציה שהפסידה את הפוקוס.
- מסגרת האודיו אוכפת את ההנמכה וההשתקה רק אם האפליקציה המפסידה תואמת לכללים שהוגדרו על ידי יצרן הציוד המקורי בקובץ ה-XML הזה.
- כך יצרני ציוד מקורי יכולים להתאים אישית את התנהגות התכונה על סמך מאפייני האפליקציה או סוגי השימוש באודיו.
שליטה בתכונה באמצעות RRO: הוספנו דגל תכונה חדש של שכבת-על של משאב בזמן ריצה (RRO),
audioUseFadeManagerConfiguration
, כדי להפעיל או להשבית את התכונה הזו:- התכונה מושבתת כברירת מחדל.
- כדי להפעיל את אובדן המיקוד באודיו שנאכף על ידי המערכת, יצרני ציוד מקורי (OEM) צריכים להגדיר את הדגל הזה לערך
true
. - למרות שמסגרת האודיו לרכב מצפה להגדרות תקפות של דעיכה כשהדגל מופעל, היעדר הגדרות כאלה לא גורם באופן אוטומטי לחריגה חמורה.
- כל האפליקציות של הגדרות ההחלקה צריכות לכלול הגדרות החלקה תואמות. זו שגיאה חמורה לקרוא להגדרת דעיכה (לפי השם שלה) כחלק מהגדרת האודיו ברכב בלי לספק הגדרה תקינה.
- כשהדגל מושבת, המערכת מתעלמת מכל ההגדרות של האפקט ומכל ההפניות להגדרות.
הגדרת מנהל המעברים
במסגרת האודיו של Android 15 מוצג FadeManagerConfiguration
מאוחד כדי לספק ליצרני ציוד מקורי (OEM) שליטה מפורטת בהתנהגות של הנמכת עוצמת הקול. המסגרת הזו
מוצגת באיור 3:
איור 3. הגדרת מנהל המעברים.
ההגדרה הזו כוללת:
- מאפייני מעבר של הדהייה: הגדרות של הדהייה החוצה והדהייה פנימה.
- אפשר להגדיר אותו עם שימושים או מאפיינים ספציפיים של אודיו.
- מאפשרת להגדיר משך זמן בהתאמה אישית.
- ההגדרות האלה משמשות ליצירת
VolumeShaper.Configuration
.
- מדיניות לגבי הדהייה: כללים שקובעים מתי מתרחשת הדהייה.
- מתג גלובלי להפעלה או להשבתה של ההנמכה.
- רשימה ניתנת להגדרה של שימושים באודיו שאפשר להנמיך (אם הם מאבדים את המיקוד).
- רשימות החרגות (שאי אפשר להחליש) מונעות החלשה של מקורות אודיו קריטיים או ייעודיים. הרשימות האלה יכולות להתבסס על:
- סוגי תוכן
- מאפייני אודיו
- מזהי UID של אפליקציות (אפשר להגדיר רק במהלך זמן הריצה)
הגדרות OEM
בקטע הזה נסקור את ההתאמות האישיות הזמינות של יצרני ציוד מקורי (OEM).
קובץ XML של הגדרות ההנחתה של האודיו ברכב
ב-Android 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 להגדרת האודיו של הרכב
ב-Android 15 מוצג קובץ car_audio_configuration.xml
מעודכן, עכשיו בגרסה 4, שכולל תגי applyFadeConfigs
ו-fadeConfig
חדשים.
התג applyFadeConfigs
יכול להכיל כמה הגדרות של fadeConfig
, וכך מאפשר הגדרה גמישה של האפקט. כל הגדרה:
- חייב לכלול
fadeConfig
אחד שמוגדר כברירת מחדל באמצעותisDefault = true
. - יכול לכלול כמה הגדרות זמניות של
fadeConfig
. ההגדרות הזמניות האלה חלות באופן ספציפי במהלך אינטראקציות של איבוד מיקוד האודיו, ורק כשאפליקציית ההשגה של מיקוד האודיו תואמת לקריטריונים שמוגדרים בהגדרה הזמנית.
הנחיות מעשיות להטמעה מופיעות בהגדרות לדוגמה של האמולטור בכתובת device/generic/car/emulator/audio/car_audio_configuration.xml
.
תוסף שירות למיקוד אודיו של OEM
יצרני ציוד מקורי שמטמיעים שירות מותאם אישית למיקוד באודיו ברכב יכולים להגדיר את ההגדרות של הנמכת עוצמת הקול באודיו על ידי הכללתן ב-OemCarAudioFocusResult
.
אפשר לעשות זאת באמצעות שיטת ה-builder setAudioAttributesToCarAudioFadeConfigurationMap()
:
/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}
חשוב לציין שיצרני ציוד מקורי יכולים לבחור להשתמש בהגדרות מוגדרות מראש של דעיכה בזמן האתחול או להחיל הגדרות באופן דינמי באמצעות שירות המיקוד באודיו בהתאמה אישית שלהם, וכך להציע שליטה שניתנת להתאמה.
תרשים רצף
בתרשים הרצף הזה מוצגת ההתנהגות אחרי שניתן מיקוד אודיו לאפליקציה App2
ואחרי שאפליקציה App1
איבדה את מיקוד האודיו:
- כששירות האודיו של הרכב שולח את איבוד המיקוד באודיו אל
App1
, ההפעלה מנגןApp1
עוברת דעיכה בהתאם לFadeManagerConfiguration
הפעילים. אחרי שהפעולה של ההנמכה מסתיימת,App1
מקבל קריאה חוזרת רגילה של איבוד מיקוד האודיו. - אופציונלי: אפשר להגדיר שהאודיו של
App1
יחזור בהדרגה אחרי פרק זמן שניתן להגדרה. יצרני ציוד מקורי יכולים להגדיר את משך הזמן הזה באמצעות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
החל מ-Android 11, HAL מופעל כדי לבקש מיקוד בשם זרמים חיצוניים. השימוש בממשקי ה-API האלה הוא אופציונלי, אבל מומלץ מאוד כדי לאפשר לצלילים חיצוניים להשתלב בצורה אופטימלית במערכת האקולוגית של Android ולספק חוויית משתמש חלקה.
ה-HAL קובע סופית אילו צלילים צריכים לקבל עדיפות. לכן, צריך להשמיע צלילים קריטיים של בטיחות ומקרי חירום בלי קשר לשאלה אם HAL קיבל את פוקוס האודיו, ולהמשיך להשמיע אותם לפי הצורך גם אם HAL מאבד את פוקוס האודיו. הדבר נכון גם לגבי צלילים שנדרשים על פי תקנות ממשלתיות.
שכבת ה-HAL צריכה להשתיק באופן יזום את הזרמים ב-Android לפי הצורך, כשמושמעים צלילים של מצבי חירום או צלילים שקריטיים לבטיחות, כדי לוודא שהם נשמעים בבירור.
AudioControl@2.0
בגרסה 2.0 של AudioControl HAL נוספו ממשקי ה-API החדשים הבאים:
API | מטרה |
---|---|
IAudioControl#registerFocusListener |
רישום מופע של IFocusListener ב-HAL של AudioControl. המאזין הזה מאפשר ל-HAL לבקש ולבטל את המיקוד באודיו. ה-HAL מספק מופע ICloseHandle לשימוש על ידי
Android כדי לבטל את הרישום של מאזין. |
IAudioControl#onAudioFocusChange |
הודעה ל-HAL על שינויים בסטטוס של בקשות למיקוד שהוגשו על ידי HAL דרך IFocusListener , כולל תגובות לבקשות מיקוד ראשוניות. |
IFocusListener#requestAudioFocus |
הבקשות מתמקדות בשם HAL בשימוש ספציפי, במזהה אזור ובסוג של שיפור המיקוד. |
IFocusListener#abandonAudioFocus |
מבטל בקשות קיימות של HAL למיקוד בשימוש ובאזור שצוינו. Id. |
יכולות להיות כמה בקשות מיקוד בו-זמנית ב-HAL, אבל יש הגבלה של בקשה אחת לכל שימוש וצימוד של מזהה אזור. מערכת Android מניחה ש-HAL מתחיל להשמיע צלילים לשימוש מסוים מיד אחרי שמתקבלת בקשה, וממשיך לעשות זאת עד שהוא מפסיק להתמקד.
מלבד registerFocusListener
, הבקשות האלה הן oneway
כדי להבטיח שמערכת Android לא תעכב את HAL בזמן עיבוד בקשת המיקוד. שכבת ה-HAL לא צריכה להמתין עד שהפוקוס יחזור אליה לפני השמעת צלילים שקריטיים לבטיחות. ה-HAL לא חייב להאזין לשינויים במיקוד האודיו ולהגיב להם באמצעות IAudioControl#onAudioFocusChange
.
שירות OEM להרשאת אודיו ברכב
ב-Android 14, AAOS הציגה את שירותי הפלאגין של יצרן הרכב המקורי כדי לאפשר הגדרה של רכיבים מסוימים ברכב. במקרה של Car Audio Plugin Service, שירות הפלאגין מאפשר ליצרני ציוד מקורי לנהל בקשות למיקוד שנחטפות על ידי שירות האודיו ברכב. כך יצרני ציוד מקורי (OEM) יכולים לנהל את המיקוד בצורה גמישה יותר, בהתאם לדרישות הכללים והתקנות. לכן, האינטראקציה של מיקוד האודיו עשויה להיות שונה בין יצרנים שונים, ובין אזורים שונים. ההנחה הבסיסית לגבי מיקוד אודיו עדיין תקפה: אפליקציות צריכות לבקש מיקוד כדי לנהל טוב יותר את האודיו ולשפר את חוויית המשתמש. באופן כללי, יש כללים מסוימים שעדיין חלים על בקשות למיקוד אודיו שנשלחות על ידי אפליקציות:
אפליקציות צריכות להיות מסוגלות לקבל פוקוס אודיו באופן זמני או קבוע, אלא אם יש פוקוס אודיו בעדיפות גבוהה (כולל שיחת טלפון, התרעה על מקרה חירום או התראה על בטיחות).
בזמן שמופעל מיקוד במדיה:
אפליקציות שמבקשות להתמקד בשימוש בשיחות צריכות להיות מסוגלות לקבל את השיחה במקביל או באופן בלעדי.
אפליקציות שמבקשות התמקדות בשימוש בניווט צריכות להיות מסוגלות לקבל התמקדות בניווט באופן בלעדי או במקביל.
אפליקציות שמבקשות להתמקד בשימוש בעוזר הדיגיטלי צריכות להיות מסוגלות לקבל את המיקוד בשימוש במקביל או באופן בלעדי.
בזמן שאפליקציות עם עדיפות גבוהה למיקוד אודיו (כולל שיחת טלפון, התראת חירום או התראה על בטיחות) פעילות, צריך לאשר כל בקשה נכנסת למיקוד אודיו שנדחית או נדחית לפי הצורך.
ההצעות האלה לא ממצות את כל האפשרויות, אבל הן יכולות לעזור לאפליקציות שמבקשות להתמקד, אם אין צלילים פעילים בעדיפות גבוהה. גם בזמן שצלילים בעדיפות גבוהה פועלים, צריך לכבד בקשות להשהיית המיקוד ולאפשר את המיקוד כשצליל בעדיפות גבוהה מפסיק.