שירות תוסף שמע לרכב

שירותי תוסף OEM חדשים לרכב באנדרואיד 14 מאפשרים להגדיר כמה רכיבי רכב. עבור אודיו ספציפית, מוצגים שלושה שירותי פלאגין חדשים, המאפשרים ליצרני OEM להגדיר בצורה גמישה את ניהול האודיו במכשירי AAOS:

  • בקרת מיקוד אודיו
  • עוצמת השמע והשתקה
  • בקרת Audio Ducking

ארכיטקטורת שירות תוסף לרכב

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

תמונה

שירות רכב מתחיל את שירות הרכב OEM על ידי מציאת הרכיב המוגדר ב- config_oemCarService . אם התצורה ריקה, שירות OEM לא קיים ולא הופעל שירות. הרכיב חייב להרחיב את OemCarService . שירות האודיו לרכב חייב להחליף את ממשקי ה-API לרכישת שירות OEM של אודיו לרכב:

public final class OemCarServiceImp extends OemCarService {
    @Override
    public OemCarAudioFocusService getOemAudioFocusService();

    @Override
    public OemCarAudioDuckingService getOemAudioDuckingService();

    @Override
    public OemCarAudioVolumeService getOemAudioVolumeService();
}

לדוגמה , ראה את אפליקציית בדיקת העזר המוגדרת packages/services/Car/tests/OemCarServiceTestApp .

למרות שהשירות מופעל על ידי שירות רכב, הוא אינו יורש אוטומטית את ההרשאות הזמינות לשירות אודיו לרכב. לפיכך, כל הרשאה הנדרשת על ידי שירותי OEM צריכה להירכש במנגנון המתאים. לדוגמה, ראה packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml .

שירות שמע לרכב עם ארכיטקטורת שירות OEM

ב-AAOS, שירות אודיו לרכב מנהל את הפעולות הבאות:

  • ניתוב אודיו
  • מיקוד אודיו
  • אודיו דאקינג
  • עוצמת קול והשתקה

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

  • מיקוד אודיו
  • אודיו דאקינג
  • עוצמת קול והשתקה

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

תמונה

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

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

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

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

הגדרות שירותי שמע לרכב OEM

שירות מיקוד שמע לרכב OEM

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

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

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

  • דחה אינטראקציה. בקשת מיקוד נכנסת נדחתה בהתבסס על בעל המיקוד הנוכחי.

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

public interface OEmCarAudioFocusService {
    OemCarAuddioFocusResults evaluateAudioFocusRequest(
        OemCarAudioFocusEvaluationRequest request);
    
    void notifyAudioFocusChange(
        List<AudioFocusEntry> holder,
        List<AudioFocusEntry> losers, int zoneId);
}

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

ניתן להשתמש במידע זה כדי להעריך את newFocusRequest בהשוואה לבעלי המיקוד הנוכחיים ב- focusHolders ולמפסידי המיקוד הנוכחיים ב- focusLosers . ה-API אמור להחזיר את התוצאות:

class OemCarAudioFocusResult {
    int audioZoneId;
    int audioFocusEvaluationResults;
    AudioFocusEntry focusResult;
    List<AudioFocusEntry> newLosers;
    List<AudioFocusEntry> newlyBlocked;
}

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

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

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

ה-API השני, notifyAudioFocusChange , הוא דרך אחת הנקראת בכל בקשה או נטישה של מיקוד אודיו. ה-API משמש בעיקר כדי ליידע את שירות ה-OEM על שינויים במיקוד, שעשויים להשפיע על ההתנהגות של שירות האודיו לרכב OEM.

הנחיות להערכת מיקוד

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

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

  • בעוד מיקוד מדיה פעיל, אפליקציות המבקשות:

    • מיקוד שימוש בשיחות, אמור להיות מסוגל לקבל מיקוד במקביל או בלעדי.

    • מיקוד שימוש בניווט, אמור להיות מסוגל לקבל פוקוס במקביל או בלעדי.

    • מיקוד שימוש ב-Assistant, אמור להיות מסוגל לקבל מיקוד במקביל או בלעדי.

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

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

שירות נפח רכב OEM

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

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

  1. ניווט
  2. שִׂיחָה
  3. מוּסִיקָה
  4. הַכרָזָה
  5. פקודה קולית
  6. צלצול שיחה
  7. צליל מערכת
  8. בְּטִיחוּת
  9. אזעקה
  10. הוֹדָעָה
  11. מצב הרכב
  12. חירום

כדי להפוך את ניהול אירועי מפתח עוצמת הקול לפחות מורכב, לשירות האודיו לרכב יש רשימת עדיפות שנייה של הקשר אודיו:

  1. שִׂיחָה
  2. כְּלֵי תִקְשׁוֹרֶת
  3. הַכרָזָה
  4. פקודה קולית

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

ניתן להגדיר את הגרסה בפועל של עוצמת הקול עם תצורת audioVolumeAdjustmentContextsVersion . ניתן להגדיר את התצורה ל 1 או 2 ( 2 היא ברירת המחדל).

כדי לספק גמישות רבה יותר לניהול נפח, OemCarAudioVolumeService מוצג באנדרואיד 14:

public interface OemCarAudioVolumeService {
    OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}

לשירות עוצמת הקול של OEM לרכב יש שיטה אחת, שמקבלת volumeAdjustment ו- OemCarAudioVolumeRequest :

class OemCarAudioVolumeRequest {
    int audioZoneId;
    int callState;
    List<AudioAttributes> activePlaybackAttributes;
    List<AudioAttributes> duckedAttributes;
    List<CarVolumeGroupInfo> volumeGroupState;
}

ל- activePlaybackAttributes של הבקשה יש את תכונות האודיו הפעילות. ה- duckedAttributes הם כולן תכונות האודיו שהורדו כרגע. ל- volumeGroupState יש את המצב הנוכחי של קבוצת אמצעי האחסון. הבקשה מייצגת את המצב הנוכחי של ערימת השמע וניתן להשתמש בה כדי לקבוע איזו קבוצת עוצמת הקול יש לשנות. יש להחזיר את התוצאות ב- OemCarVolumeChangeInfo :

class OemCarVolumeChangeInfo {
    boolean change;
    CarVolumeGroupInfo volumeGroupChanged;
}

change בוליאני מציין אם נפח כלשהו השתנה, true מציין שיש שינוי ויש לעדכן את קבוצת עוצמת הקול. volumeGroupChanged היא קבוצת אמצעי האחסון בפועל שיש לשנות. יש לשנות קבוצה זו בהתאם לפרמטר volumeAdjustment המקורי שהועבר ל-API. לדוגמה, אם התוצאות מצביעות על כך שיש להשתיק את קבוצת עוצמת הקול של הניווט, הערך הבולאלי יהיה true וקבוצת הנפח המוחזר צריכה להיות זו של הניווט.

שירות ברווז לרכב OEM

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

  • צלילי חירום דוחים הכל חוץ מצלילי שיחה
  • בטיחות מבטל הכל חוץ מצלילי חירום
  • ניווט מבטל הכל פרט לקולות בטיחות וחירום
  • תקראו לברווזים הכל חוץ מצלילי בטיחות, חירום וניווט
  • קול ברווזים צלצול צלצול
  • מוזיקה והכרזות צריכים להשתחרר מהכל

כללים אלה אינם ממצים ויצרני OEM נשארים אחראים לקביעה כיצד יש לשלול צלילים בהתבסס על הנחיות אלו. יצרני OEM יכולים לשלוט בהמלצות אלו בצורה פעילה יותר בהתבסס על הדרישות הזמינות. OemCarDuckingService מוצג באנדרואיד 14:

class OemCarAudioDuckingService {
List<AudioAttributes>   evaluateAttributesToDuck(
        OemCarAudioVolumeRequest request);
}

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

  • תכונת אודיו שהושגה כעת:

    • ברשימה, ממשיך להתחמק
    • לא ברשימה, הברווז כבוי

  • מאפיין האודיו לא מנוצל כעת:

    • ברשימה, התכופף
    • לא ברשימה, הברווז כבוי

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

האיור שלהלן מציג דיאגרמת רצף מפושטת של בקרת ה-Ducking האודיו עבור בקשת מיקוד כאשר נעשה שימוש בשירות ה-Ducking OEM:

תמונה

הרצף מתחיל כאשר אפליקציה מבקשת ניהול מיקוד שמע באמצעות ממשקי API של מנהל שמע ציבוריים. הבקשה מועברת לשירות האודיו לרכב כדי לקבוע את התוצאות. כאשר מחליטים על מיקוד אודיו, בדיקת האודיו מוערכת על ידי שירות האודיו לרכב הקורא ל- OemCarAudioDuckingService כדי להעריך אילו תכונות אודיו יש לבטל. לאחר שהתוצאות מוחזרות מ-API של evaluateAttributesToDuck , מחושבים מכשירי האודיו ל-Duck, ולבסוף המידע נשלח ל- AudioControl כדי להחיל דאק על חומרת האודיו.

יישום שירותי שמע לרכב OEM

AAOS מספקת יישום ייחוס של שירות המכוניות OEM packages/services/Car/tests/OemCarServiceTestApp , המיישמת את ה- OemCarService , יחד עם OemCarAudioFocusService , OemCarAudioDuckingService וה- OemCarAudioVolumeService . עבור האחרונים, כל שירות משתמש בקובץ XML כדי לטעון התנהגות סטטית. לדוגמה, OemCarAudioFocusServiceImp טוען את הקובץ oem_focus_config.xml , המכיל מטריצת אינטראקציה. המטריצה ​​משמשת להערכת בקשת המיקוד כאשר קוראים ל- evaluateAudioFocusRequest .

איתור באגים באפליקציה לבדיקת התייחסות

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

<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>

כדי לאמת את שירות ה-OEM לרכב משתמש בפקודה dump service car עבור שירות OEM:

adb shell dumpsys car_service --oem-service

התוצאות עשויות להיות דומות לפלט שלהלן:

***CarOemProxyService dump***
  mIsFeatureEnabled: true
  mIsOemServiceBound: true
  mIsOemServiceReady: true
  mIsOemServiceConnected: true
  mInitComplete: true
  OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
  OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
  mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl

כל בוליאן בכל אצווה של מידע dump קובע את מצב התכונה והשירות. לדוגמה, מידע ה-dump mIsOemServiceReady מציין אם השירות מוכן לשימוש, כאשר true מציין שהוא מוכן ו- false מציין שהוא לא מוכן.