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

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

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

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

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

המבנה של CAP ב-HIDL

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

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

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

המבנה של CAP ב-AIDL

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

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

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

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

תרחישים להעברה

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

מוצר חדש

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

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

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

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

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

נוהל השמות של אסטרטגיות המוצרים שונה בגרסאות HIDL ו-AIDL של הגדרת CAP. ב-HIDL, לשיטות המובנות ('קוד מדור קודם') היו שמות קצרים עם אותיות קטנות, כמו media. לעומת זאת, ב-AIDL, לשיטות המובנות היו שמות עם אותיות רישיות עם התחילית STRATEGY_, למשל STRATEGY_MEDIA. רשימת השיטות המובנות מופיעה במאמר CapProductStrategies.xml. באותו קובץ מוגדרים מזהים 'שהוקצתה להם עדיפות מראש' לשיטות ספציפיות ליצרני ציוד מקורי, לפי תבנית השמות 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.