תמיכה במדיניות אודיו שניתן להגדרה ב-HAL של AIDL

החל מ-Android 16, ממשק AIDL Audio HAL תומך באופן מלא במדיניות אודיו שניתנת להגדרה (CAP).

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

מסגרת הפרמטרים

ההטמעה של CAP מבוססת על Intel Parameter Framework. התכונה CAP הושקה ב-Android 6. ה-Parameter Framework ‏ (PfW) מאפשר לתאר מערכת במונחים של פרמטרים. באמצעות קובץ XML של הגדרות, PfW קושר את הפרמטרים לפעולות באמצעות תוספים, ומספק כללים לשינוי הפרמטרים בהתאם לקריטריונים הנוכחיים.

מבנה CAP ב-HIDL

ב-HIDL, כל ההגדרה של ה-CAP צוינה ב-XML. מידע נוסף זמין במאמרים Parameter Framework וConfiguration using Parameter Framework. קובצי XML שימשו לציון הפרטים הבאים:

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

בעזרת HIDL, מסגרת Android הצליחה לטעון את קובצי ה-XML האלה ישירות ממחיצת הספק. הפעולה הזו אושרה כי הוגדרה סכימת XSD כחלק מ-HAL API עבור קובצי ה-XML האלה. לכל גרסה ראשית של HIDL HAL הייתה סכימת XSD תואמת. בגרסאות ראשיות לא נדרשה תאימות לאחור.

המבנה של CAP ב-AIDL

במעבר ל-AIDL, גרסאות ה-API של HAL צריכות להישאר תואמות לאחור (במונחים של HIDL, כל גרסה של AIDL HAL היא עדכון 'משני'). אי אפשר יותר להשתמש בסכימות XSD כחלק מממשקי HAL API, כי אין דרך מוגדרת לעדכן את הסכימות כך שהן יהיו תואמות לאחור. לכן, את ההגדרה שהוגדרה בעבר בקובצי XML צריך לספק עכשיו באמצעות ממשקי AIDL API של HAL. כדי לעשות את זה, המבנה של הגדרות ה-CAP מומר ל-AIDL, בדומה לקובצי ה-XML של הגדרות מדיניות האודיו ב-AIDL Audio HAL ב-Android 15.

מבני הנתונים של ה-CAP מתווספים לסוגי נתונים יציבים נפוצים וכוללים את האובייקטים הבאים שניתן להעביר:

נקודת הכניסה להגדרת ה-CAP נמצאת במבנה AudioHalEngineConfig.CapSpecificConfig. בAudioHalCapConfiguration.aidl אפשר לראות תרשים של מבני נתונים של CAP.

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

תרחישי העברה

שותפים יכולים לשקול את האפשרויות שמפורטות בקטע הזה, בהתאם למצב: השקה ראשונה של מוצר שלא נעשה בו שימוש ב-CAP בעבר, או העברה של מוצר קיים.

מוצר חדש

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

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

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

עדכון למוצר קיים

אם המוצר כבר משתמש ב-CAP ולכן יש לו הגדרת XML, אפשר להמשיך להשתמש ב-CAP הקיים עם גרסת ה-AIDL של ה-HAL.

מוסכמות השמות של אסטרטגיות המוצרים שונות בגרסאות HIDL ו-AIDL של הגדרת ה-CAP. ב-HIDL, שיטות הבידינג המובנות ('שיטות קודמות') משתמשות בשמות קצרים באותיות קטנות, כמו media, ואילו ב-AIDL, שיטות הבידינג המובנות משתמשות בשמות באותיות רישיות עם הקידומת STRATEGY_, לדוגמה STRATEGY_MEDIA. אפשר לעיין ברשימת האסטרטגיות המובנות ב-CapProductStrategies.xml. באותו קובץ מוגדרים מזהים 'שהוקצו מראש' לשיטות ספציפיות ליצרני ציוד מקורי (OEM) ששמותיהן תואמים לתבנית vx_10xx עם מספרים מ-1000 עד 1039.

מוצר מדור קודם

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

דוגמה להטמעה

כדי לעזור לשותפים להטמיע CAP בפלטפורמות שלהם, ב-AOSP יש דוגמה לגרסה של המכשיר הווירטואלי Cuttlefish שנקראת automotive (רכב) ומשתמשת ב-CAP עם AIDL HAL. ההגדרה הספציפית למכשיר נמצאת ב-device/google/cuttlefish/shared/auto/audio/policy/engine, עם שם היעד lunch של aosp_cf_x86_64_auto. אפשר להשתמש בקובץ Android.bp כהפניה ליצירת קבוצה מלאה של קבצים של ספק CAP.