שירות פלאגין של אודיו ברכב

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

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

ארכיטקטורת השירות של הפלאגין לרכב

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

תמונה

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

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, הפעולות הבאות מנוהלות באמצעות שירות האודיו לרכב:

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

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

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

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

תמונה

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

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

כדי לבצע פעולות, שירות האודיו לרכב מתקשר לשירותי הרכב של ה-OEM. השיחות האלה מתבצעות בתהליכים שונים, שמחייבת תקשורת בין תהליכים (IPC). IPC מוסיף זמן אחזור לכל שיחה. חשוב לצמצם את זמן האחזור שירות 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 מכילה רשומות שהיו בעבר במצב של אובדן הפוקוס אך כעת הם חסומים על ידי הרשומה החדשה. החסימה יכולה להיות קבועה או זמני, אם המיקוד הקבוע חסום, הרשומה תוסר מהמקבץ ואובדן הריכוז יישלח למאזינים של הפוקוס. במקרה של אובדן מיקוד זמני: הרשומה תישאר בערימת ה-FOS, אבל חוסם מיקוד חדש נוסף לרשימת החסימות שלו, לא יישלח אובדן מיקוד כמו קודם נשלחה בפעם הראשונה שנחסמה. חסימת הבקשה תבוטל בסופו של דבר כשכל החוסם הנוכחי יוסר, או שהוא יוסר מהמקבץ אם המיקוד ננטש.

ממשק ה-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. פקודה קולית

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

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

כדי לספק יותר גמישות בניהול עוצמת הקול, ההשקה של OemCarAudioVolumeService מתבצעת ב-Android 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)

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

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

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

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

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

  • מאפיין האודיו שכבר לא מוגדר:

    • ברשימה ממשיך להיות מכובד
    • לא ברשימה, הנמכה מושבתת

  • מאפיין האודיו לא מוגבל כרגע:

    • ברשימה, מכווצת
    • לא ברשימה, הנמכה מושבתת

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

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

תמונה

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

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

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

ניפוי באגים באפליקציה לבדיקות

אפליקציית הבדיקה של שירות הרכב של ה-OEM (יצרן הציוד המקורי) היא חלק מקוד המקור של ה-AOSP. יצרני ציוד מקורי יכולים ליצור משתנה בהתאם לצרכים שלהם. לניפוי באגים, אפשר להשתמש בפונקציה 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 של שירות לרכב עבור שירות 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 מציין שהוא לא מוכן.