מיקוד אודיו

לפני שמתחילים שידור לוגי, האפליקציה מבקשת להתמקד באודיו באמצעות אותם מאפייני אודיו שמשמשים לשידור הלוגי. האפליקציה צריכה להתייחס למצבים שבהם המשתמש מפסיק להתמקד בה כדי לפעול כצפוי בתרחישי השימוש ברכב.

מומלץ לשלוח בקשה להתמקד בכם, אבל המערכת לא אוכפת זאת. לכן, מומלץ להשתמש בפוקוס כדרך לשלוט באופן עקיף במהלך ההפעלה ולהימנע מהתנגשויות, במקום כמנגנון ראשי לשליטה באודיו. הרכב לא צריך להסתמך על מערכת המיקוד כדי להפעיל את מערכת האודיו המשנית.

אינטראקציות עם מיקוד

כדי לתמוך ב-AAOS, המערכת מטפלת בבקשות להעברת המיקוד של האודיו על סמך אינטראקציות מוגדרות מראש בין הערך של CarAudioContext בבקשה לבין הערך של CarAudioContext בבעלים הנוכחיים של המיקוד. יש שלושה סוגים של אינטראקציות:

  • בלעדי
  • דחייה
  • בו-זמנית

אינטראקציה בלעדית

זהו מודל האינטראקציה הנפוץ ביותר ב-Android.

באינטראקציות בלעדיות, רק אפליקציה אחת יכולה להיות במוקד בכל פעם. לכן, בקשת מיקוד נכנסת מקבלת את המיקוד, בעוד שרכיב המיקוד הקיים מאבד את המיקוד. מכיוון ששתי האפליקציות מפעילות מדיה, רק אפליקציה אחת יכולה להיות במוקד. כתוצאה מכך, בקשת המיקוד של האפליקציה שהתחילה לפעול מחדש תוחזר עם הערך AUDIOFOCUS_REQUEST_GRANTED, ואילו אפליקציית המוזיקה שפועלת כרגע תקבל אירוע שינוי מיקוד עם סטטוס אובדן שתואם לסוג הבקשה שהוגשה.

דחיית אינטראקציה

באינטראקציות מסוג דחייה, הבקשה הנכנסת תמיד נדחית. לדוגמה, כשמנסים להפעיל מוזיקה בזמן שיחה. במקרה כזה, אם Dialer שומר על המיקוד באודיו לשיחה ואפליקציה שנייה מבקשת להתמקד בה כדי להפעיל מוזיקה, אפליקציית המוזיקה מקבלת את הערך AUDIOFOCUS_REQUEST_FAILED בתגובה לבקשה. מאחר שבקשת המיקוד נדחתה, לא נשלח אירוע של אובדן מיקוד לבעל המיקוד הנוכחי.

אינטראקציה בו-זמנית

אינטראקציות בו-זמניות הן ייחודיות ל-AAOS. כך אפליקציות שמבקשות להתמקד באודיו ברכב יכולות להמשיך להתמקד בו במקביל לאפליקציות אחרות. כדי שתתבצע אינטראקציה בו-זמנית, צריכים להתקיים התנאים הבאים. ה:

אם הקריטריונים האלה מתקיימים, הבקשה להעברת המיקוד תוחזר עם הערך AUDIOFOCUS_REQUEST_GRANTED, ואין שינוי במיקוד של בעל המיקוד הנוכחי. עם זאת, אם בעל המיקוד הנוכחי בוחר לקבל אירועי דחק או להשהות את הפעילות כשמתבצעת דחיפת צד, הוא מאבד את המיקוד, כמו שקורה באינטראקציה בלעדית.

טיפול בשידורים חיים בו-זמניים

יש אינטראקציות רבות שאפשר לבצע בו-זמנית, אבל חשוב להיזהר כשמערבבים ומשתמשים ב-ducking ברמת החומרה במכשירי הפלט השונים. מומלץ מאוד לנתב מכונות של CarAudioContext שמותר להפעיל בו-זמנית למכשירי פלט שונים.

כשיש מכשירי פלט נפרדים לשידורים בו-זמניים, ה-HAL יכול להשתיק את אחד מהשידורים לפני שמערבב אותם, או לנתב את השידורים הפיזיים לרמקולים שונים ברכב. אם ההזרמות הלוגיות מעורבות ב-Android, הרווחים לא משתנים ונשלחים כחלק מאותה ההזרמה הפיזית.

לדוגמה, כשהניווט והמדיה מועברים בו-זמנית, יכול להיות שהשיפור של מקור הקול של המדיה יופחת באופן זמני (או ייפסק) כדי שאפשר יהיה לשמוע בבירור את הוראות הניווט. לחלופין, אפשר לנתב את שידור הניווט לרמקולים בצד הנהג בזמן שהמדיה ממשיכה לפעול בשאר תא הנוסעים.

מטריצה של אינטראקציות

בטבלה הזו מוצגת מטריצת האינטראקציה כפי שמוגדרת על ידי CarAudioService. כל שורה מייצגת את CarAudioContext של בעל המיקוד הנוכחי, וכל עמודה מייצגת את CarAudioContext של הבקשה הנכנסת.

לדוגמה, כשאפליקציית מדיה של מוזיקה מחזיקה את המיקוד בזמן שאפליקציית ניווט מבקשת את המיקוד, המטריצה מציינת ששתי האינטראקציות יכולות לפעול בו-זמנית, בהנחה שהקריטריונים האחרים לאינטראקציות בו-זמניות מתקיימים.

בגלל האינטראקציות בו-זמניות, יכול להיות יותר מאדם אחד שיהיה מוקד. במקרה כזה, בקשת התמקדות נכנסת תוצג לכל אחד מבעלי המיקוד הנוכחיים לפני שנקבע איזו אינטראקציה תחול. במקרה כזה, האינטראקציה השמרנית ביותר מנצחת. דחייה, לאחר מכן בלעדית ולבסוף בו-זמנית.

מטריצת האינטראקציה של הרשאת האודיו

איור 1. מטריצה של אינטראקציות עם הרשאת אודיו.

ב-Android 11 הוספנו הגדרת משתמש חדשה שמאפשרת למשתמשים לשנות את התנהגות האינטראקציה בין הניווט לשיחות טלפון. כשהערך של android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL מוגדר, האינטראקציה בין בקשות NAVIGATION נכנסות ל-focus לבין בעלי ה-focus הנוכחיים מסוג 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
    

מערכת לאכיפת דהייה

ב-Android 15 נוספה ל-AAOS התכונה 'העלאת עוצמת הקול בהדרגה', שמופעלת על ידי המערכת. ב-Android, המערכת לא אוכפת את המיקוד האודיו. לכן, למרות שמפתחי האפליקציות מומלצים לפעול בהתאם להנחיות בנושא התמקדות באודיו, אם אפליקציה ממשיכה לפעול בעוצמה גבוהה גם אחרי שהיא מפסיקה להיות מוגדרת כממוקדת באודיו, המערכת לא יכולה למנוע זאת.

בסביבות רכב קריטיות לבטיחות, חשוב מאוד להקפיד על התמקדות באודיו כדי למזער את הסחות הדעת של הנהג. בעזרת התכונה הזו, מסגרת האודיו עכשיו מפחיתה באופן אוטומטי את עוצמת האודיו של אפליקציות שאין להן עדיפות, כדי לספק חוויית אודיו ניתנת לשליטה וצפויה יותר.

השיפור הזה עוזר לוודא שהאפליקציות פועלות בהתאם להחלטה על אובדן המיקוד של האודיו, כפי שמוגדרת במטריצה של האינטראקציות, וכך למנוע התנגשויות בהפעלת אודיו.

העיצוב הכללי

בתרשים הבא מוצגים העיצוב הכללי והתמיכה בתכונה של אובדן המיקוד ברכב:

תכנון כללי של תכונת ההעלמה בכפייה על ידי המערכת

איור 2. תכנון ברמה גבוהה של תכונת ההעלמה בכפייה על ידי המערכת.

  • השהיה ממוקדת: אכיפת ההשהיה במערכת ב-Android 15 תוכננה במיוחד למצבים שבהם האפליקציה מאבדת את המיקוד באודיו אבל ממשיכה להשמיע אודיו.
  • מנגנון הדעיכה: כשאפליקציה מאבדת את המיקוד של האודיו לאפליקציה חדשה שמבקשת:
    • מסגרת האודיו מאזנת באופן אוטומטי את האודיו של האפליקציה שמפסיקה לפעול.
    • לאחר היציאה משימוש, המערכת משתקת את מקור האודיו.
    • לאחר מכן, האפליקציה מקבלת התראה על אובדן המיקוד האודיו.
    • אפליקציות שמפיעות התנהגות לא הולמת יושתקו עד שהן יקבלו שוב את המיקוד של האודיו.
    • הלוגיקה שמוגדרת כברירת מחדל היא להציג את האפליקציות בהדרגה אחרי 2 שניות. עם זאת, יצרני ציוד מקורי יכולים להגדיר את הערך הזה לכל ערך של זמן קצוב לתפוגה.
    • מסגרת האודיו משתמשת בהגדרות של יצרן הציוד המקורי גם לפעולות של יציאה משימוש וגם לפעולות של כניסה משימוש.
  • קובץ תצורה של יצרן ציוד מקורי: Android 15 כולל קובץ תצורה חדש, car_audio_fade_configuration.xml:

    • הקובץ הזה מאפשר ליצרני ציוד מקורי להגדיר קריטריונים למקרה שבו אכיפת המיקוד באודיו של המערכת תחול על האפליקציה שאיבדה את המיקוד.
    • מסגרת האודיו אוכפת את ההעלמה וההשתקה רק אם האפליקציה המפסידה תואמת לכללים שהוגדרו על ידי יצרן הציוד המקורי בקובץ ה-XML הזה.
    • כך יצרני ציוד מקורי יכולים להתאים אישית את התנהגות התכונה על סמך מאפייני האפליקציה או סוגי השימוש באודיו.
  • שליטה בתכונות באמצעות RRO: הוספנו את הדגל החדש audioUseFadeManagerConfiguration של תכונה של שכבת-על של משאבים בסביבת זמן ריצה (RRO) כדי להפעיל או להשבית את התכונה הזו:

    • התכונה מושבתת כברירת מחדל.
    • כדי להפעיל אובדן של מוקד האודיו בכפייה על ידי המערכת, יצרני ציוד מקורי צריכים להגדיר את הדגל הזה ל-true.
    • אמנם מסגרת האודיו ברכב מצפה להגדרות תקינות של תצורת הדעיכה כשהדגל מופעל, אבל היעדר ההגדרות האלה לא מוביל באופן אוטומטי לחריגה קטלנית.
    • כל האפליקציות של הגדרות ההעלאה צריכות לכלול הגדרות תואמות של העלאה. זוהי שגיאה קטלנית להפעיל הגדרת עמעום (לפי השם שלה) כחלק מהגדרת האודיו ברכב בלי לספק הגדרה תקינה.
    • כשהדגל מושבת, המערכת מתעלמת מכל ההגדרות של תצורת ההעלמה ומכל ההפניות לתצורה.

הגדרת מנהל ההעלאה

במסגרת האודיו של Android 15 מוצג FadeManagerConfiguration מאוחד כדי לספק ליצרני ציוד מקורי שליטה מפורטת על התנהגות הדהייה של האודיו. התרשים הזה מתואר באיור 3:

הגדרת מנהל ההעלאה

איור 3. הגדרת מנהל ההעלאה.

ההגדרה הזו כוללת:

  • מאפייני מעבר של דהייה: הגדרות גם לדהייה החוצה וגם לדהייה פנימה.
    • אפשר להגדיר אותו באמצעות מאפיינים או שימושים ספציפיים של אודיו.
    • מאפשרת להגדיר משך זמן מותאם אישית.
    • ההגדרות האלה משמשות ליצירת VolumeShaper.Configuration.
  • מדיניות הדעיכה: כללים שקובעים מתי תתרחש הדעיכה.
    • מתג גלובלי להפעלה או להשבתה של הדעיכה.
    • רשימה של שימושים באודיו שניתן להגדיר את עוצמת הקול שלהם (ניתנים להוצאה משימוש בהדרגה כשהמשתמשים מפסיקים להתמקד בהם).
    • רשימות החרגות (לא ניתן להפחית את עוצמת הקול שלהן) מונעות הפחתת עוצמת הקול של מקורות אודיו קריטיים או שהוגדרו ככאלה. הרשימות האלה יכולות להתבסס על:
      • סוגי תוכן
      • מאפייני אודיו
      • מזהי UID של אפליקציות (ניתן להגדיר אותם במהלך זמן הריצה בלבד)

הגדרות OEM

בקטע הזה נסקור את ההתאמות האישיות הזמינות ליצרני ציוד מקורי (OEM).

קובץ XML של הגדרת העמעום של אודיו ברכב

ב-Android 15 נוסף קובץ תצורה חדש, car_audio_fade_configuration.xml, שמאפשר ליצרני ציוד מקורי להתאים אישית באופן נרחב את אופן ההעלמה של האודיו כשהמצלמה לא ממוקדת.

  • קובץ ה-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 הולכת ונחלשת בהתאם ל-FadeManagerConfigurations הפעילים. אחרי שהפעולה של הדעיכה החוזרת תושלם, App1 יקבל את הקריאה החוזרת הרגילה על אובדן המיקוד של האודיו.
  • אפשר גם להגדיר את משך הזמן שבו האודיו של App1 ייעלם ואז יחזור. יצרני ציוד מקורי יכולים להגדיר את משך הזמן הזה באמצעות Builder#setFadeInDurationForUsage(int, long) בהתאם לדרישות הספציפיות של המוצר שלהם.

תרשים רצף של התכונה &#39;השהיית אודיו ברכב&#39;

איור 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 צריך להשתיק באופן יזום את הסטרימינג של 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 הקיימות ל-focus עבור מזהה השימוש והתחום שצוינו.

ל-HAL יכולות להיות כמה בקשות להתמקד באותו זמן, אבל הוא מוגבל לבקשה אחת לכל התאמה של מזהה שימוש ומזהה תחום. מערכת Android מניחה שה-HAL מתחיל להשמיע צלילים לשימוש ברגע שהבקשה נשלחת, וממשיך לעשות זאת עד שהוא מפסיק להתמקד בבקשה.

מלבד registerFocusListener, הבקשות האלה הן oneway כדי לוודא שמערכת Android לא מעכבת את HAL בזמן עיבוד בקשת התמקדות. ה-HAL לא צריך להמתין לקבלת המיקוד לפני הפעלת צלילים שקשורים לבטיחות. ה-HAL יכול להאזין לשינויים במיקוד האודיו דרך IAudioControl#onAudioFocusChange ולהגיב להם.

שירות של יצרן ציוד מקורי להרשאת אודיו ברכב

ב-Android 14, הוספנו ל-AAOS את שירותי הפלאגין של יצרני הרכב המקוריים (OEM) כדי לאפשר הגדרה של חלק מרכיבי הרכב. בשירות הפלאגין של אודיו ברכב, שירות הפלאגין מאפשר ליצרני ציוד מקורי לנהל בקשות להתמקד ששירות האודיו ברכב תיקל עליה. כך יצרני ציוד מקורי יכולים לנהל את המיקוד בצורה גמישה יותר, בהתאם לכללים ותקנות. לכן, האינטראקציה עם התכונה 'מיקוד אודיו' עשויה להשתנות בין יצרנים ומאזור לאזור. ההנחה הבסיסית לגבי התמקדות באודיו עדיין בתוקף: אפליקציות עדיין צריכות לבקש התמקדות כדי לנהל את האודיו בצורה טובה יותר ולשפר את חוויית המשתמש. באופן כללי, עדיין חלים כללים מסוימים על בקשות של אפליקציות להתמקד באודיו:

  • ללא התמקדות אודיו קבועה בעדיפות גבוהה (כולל שיחת טלפון, התראה על חירום או התראה בנושא בטיחות), אפליקציות אמורות להיות מסוגלות לקבל התמקדות אודיו באופן זמני או קבוע.

  • כשהמיקוד במדיה פעיל:

    • אפליקציות שמבקשות להתמקד בשימוש בשיחות צריכות להיות מסוגלות לקבל את השיחה בו-זמנית או באופן בלעדי.

    • אפליקציות שמבקשות התמקדות ברכיב ממשק לניווט צריכות להיות מסוגלות לקבל התמקדות ברכיב ממשק לניווט בו-זמנית או באופן בלעדי.

    • אפליקציות שמבקשות להתמקד בשימוש במסגרת העוזרת צריכות להיות מסוגלות לקבל את המיקוד בשימוש בו-זמנית או באופן בלעדי.

  • כשאפליקציות עם עדיפות גבוהה לשימוש באודיו (כולל שיחת טלפון, התראת חירום או התראה בטיחותית) פעילות, כל בקשה נכנסת להשהיית שימוש באודיו צריכה להתקבל או להתעכב לפי הצורך.

ההצעות האלה לא מקיפות, אבל הן יכולות לעזור לאפליקציות שמבקשות להתמקד לקבל את המיקוד אם אין צלילים פעילים בעדיפות גבוהה. גם כשצלילים בעדיפות גבוהה פועלים, בקשות מושהות להעברת המיקוד עדיין צריכות להישמר, והן אמורות לקבל את המיקוד כשהצליל בעדיפות גבוהה מפסיק.