תמיכה במדיניות אודיו שניתן להגדרה ב-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, הגרסאות של HAL API צריכות להישאר תואמות לאחור (במונחים של 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 שמשתמש ב-CAP עם AIDL HAL. ההגדרה הספציפית למכשיר נמצאת ב-device/google/cuttlefish/shared/auto/audio/policy/engine, עם שם היעד lunch של aosp_cf_x86_64_auto. אפשר להשתמש בקובץ Android.bp כהפניה ליצירת קבוצה מלאה של קבצים של ספקי CAP.