מנוע מדיניות אודיו שניתן להתאמה אישית

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

• משתמשים בדגל useCoreAudioVolume כדי להפעיל ניהול עוצמת קול של CAP. אם הערך הזה הוא true, שירות האודיו ברכב משתמש בממשקי API של מנהל האודיו כדי לנהל את קבוצות עוצמת הקול.

• משתמשים בדגל useCoreAudioRouting כדי להפעיל ניהול של ניתוב אודיו ב-CAP. כשהערך הוא true, שירות האודיו ברכב משתמש בהגדרה של ניתוב מדיניות האודיו כדי לנהל את ניתוב האודיו.

מנוע מדיניות האודיו נתמך גם ב-Android כברירת מחדל, בצורה של מנוע מדיניות האודיו שמוגדר כברירת מחדל.

רקע

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

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

אתחול CAP לפני Android 16

באיור הבא מוצגת סקירה כללית של ניהול ההגדרות של מנוע מדיניות האודיו שניתן להגדרה ב-Android 6:

איור 1. ניהול הגדרות של מנוע CAP החל מ-Android 6.

כפי שמוצג באיור, התצורה של מנוע ה-CAP מתקבלת על ידי שירות מדיניות האודיו על ידי ניתוח המידע מaudio_policy_engine_configuration.xml הקובץ במחיצה vendor. קובץ ההגדרה של מנוע ה-CAP משתמש בסכימה שמוגדרת ב-audio_policy_engine_configuration.xsd כדי לקבל את המידע הנדרש. audio_policy_engine_configuration.xml היא דוגמה לתחום הרכב. דוגמאות דומות לפורמטים אחרים נמצאות בתיקייה frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

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

איור 2. פרטי CAP נטענים בשירות מדיניות האודיו.

קבצים של מבנה CAP ב-Android מגרסה 15 ומטה

כדי לקבל את המבנה וההגדרות, שירות מדיניות האודיו קורא את הקובץ ParameterFrameworkConfigurationPolicy.xml. ההפניה הזו מתייחסת למידע על המבנה דרך המיקום של קובץ תיאור המבנה:

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

המידע הזה מצביע על מבנה הקובץ:

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

מבנה בסיסי מסופק ב-Android. כדי לקבל את פרטי המבנה, צריך את פרטי המבנה של אסטרטגיית המוצר, ולכן מערכת Android מספקת buildStrategiesStructureFile.py כלי ליצירת מידע, שיכול ליצור מידע מקובץ ה-XML של אסטרטגיית המוצר שזמין. אפשר להפנות אליו דרך ברירת המחדל של genrule‏ buildstrategiesstructurerule באופן הבא:

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

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

קבצים של הגדרות CAP ב-Android 15 ובגרסאות קודמות

בדומה למבנה, המידע על ההגדרה, שמייצג כללים וערכים של הפרמטרים, מופיע בקובץ ParameterFrameworkConfigurationPolicy.xml באופן הבא:

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

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

הפעלה של AIDL audio HAL CAP

החל מ-Android 16, הגדרת ה-API של AIDL Audio HAL מורחבת עם ההגדרות של מנוע מדיניות האודיו, AudioHalCapConfiguration.aidl. באיור הבא מוצגת סקירה כללית של ניהול ההגדרות של מנוע ה-CAP ב-Android 16:

איור 3. ניהול הגדרות של מנוע CAP החל מ-Android 16.

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

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

איור 4. מבנה מנוע ה-CAP.

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

באיור הבא מוצג סקירה כללית של ממשקי ה-API של AIDL audio HAL שמשמשים את שירות מדיניות האודיו כדי לקבל את ההגדרה של מנוע ה-CAP:

איור 5. ממשקי AIDL audio HAL API.

במסגרת ההגדרה הזו, שירות מדיניות האודיו מקבל את המידע הבא מ-AIDL audio HAL:

• הגדרות אישיות
• אסטרטגיות
• עוצמות קול
• קריטריונים
• הגדרות

טוען ברירת המחדל של AIDL Audio HAL

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

טוען ברירת המחדל של AIDL audio HAL משתמש ב-audio_policy_engine_configuration.xml כדי לקבל את המידע הבא:

• הגדרות אישיות
• אסטרטגיות
• עוצמות קול
• קריטריונים

המידע על המבנה מתקבל מהקובץ PolicyConfigurableDomains.xml. ההבדל העיקרי מהמנגנון הקודם הוא שגם מידע המבנה מתקבל על ידי AIDL audio HAL במקום על ידי מסגרת הפרמטרים בשירות מדיניות האודיו.

ספקים יכולים להשתמש בכלי domaingeneratorpolicyrule כדי ליצור את הדומיינים הניתנים להגדרה באמצעות המידע מההגדרה של מנוע מדיניות האודיו. אפשר להשתמש בדוגמה של מכשיר וירטואלי לרכב ב-Cuttlefish כהפניה.

מבנה בהגדרת AIDL

ב-Android מגרסה 16 ואילך, שירות מדיניות האודיו מקבל את פרטי המבנה על ידי קריאה וניתוח של ParameterFrameworkConfigurationCap.xml[הקובץ](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). בפרט, הוא מקבל את המידע מקובץ תיאור המבנה:

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

המסגרת משחררת את הקבצים הנדרשים לתיקייה /etc/parameter-framework/ עם המידע הדרוש.

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

אסטרטגיות ברירת מחדל למוצרים

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

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

הפורמט הזה נועד להקל על המעבר מ-HIDL ל-AIDL במכשירים שהשתמשו בשיטות ברירת מחדל. לשינוי הפורמט הזה יש השלכות על הקבצים הקיימים (לדוגמה, PfW, ‏ XML) שמשמשים להגדרת המנוע. בפרט, צריך לשנות את כל ההפניות לשיטות הבידינג לשימוש בשמות החדשים. לדוגמה:

אסטרטגיות מוצרים שהוגדרו על ידי יצרן הציוד המקורי

מנוע ההגדרות מאפשר ליצרני ציוד מקורי (OEM) לשנות את ההגדרה של אסטרטגיות המוצרים. כדי להמשיך לתמוך בזה, קובץ אסטרטגיית המוצר CapProductStrategies.xml מספק גם 40 אסטרטגיות מוצר שניתנות להרחבה על ידי ספקים מ-vx_1000 עד vx_1039. כל התוספים של הספק חייבים להתחיל בקידומת vx_ ולהמשיך במספר שמייצג את מזהה אסטרטגיית המוצר בהגדרת אסטרטגיית המוצר של AIDL audio HAL. שאר ההגדרות (לדוגמה, קבוצות מאפייני אודיו, שם) מתקבלות מהאובייקט AudioHALProductStrategy בהגדרת מנוע ה-HAL של האודיו.

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

אסטרטגיות למוצרים

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

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

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

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

קבוצות של עוצמת קול

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

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

בהגדרה הזו, קבוצת עוצמת הקול מכילה:

• שם הקבוצה
• מדד מינימלי של קבוצה
• האינדקס המקסימלי של הקבוצה
• עקומות של קבוצות נפח

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

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

הגדרות אישיות

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

כפי שמוצג באיור 5, ה-API מכיל כמה דומיינים. המטרה של כל דומיין היא לפצל את הלוגיקה לבעיות ניתוב קטנות יותר כדי לפתור אותן (לדוגמה, מכשיר 1, מכשיר 2).

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

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

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

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

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

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

• בחירת מכשיר Bluetooth A2DP לאסטרטגיית מוצר מוזיקה (מזהה 1000, ‏ vx_1000)
  • אם משתמשים בו למדיה, הוא לא מחריג את A2DP
  • אם משתמשים בו לתקשורת, הוא לא BT SCO
  • אם יש מכשירים זמינים, כוללים BT A2DP
• בחירת מכשיר באפיק
  • אם האפשרות 'מכשירי אוטובוס' זמינה
  • אם הכתובת היא BUS00_MEDIA
• אחרת, בוחרים מכשיר פלט שיוגדר כברירת המחדל

כדי ליצור את קובץ ה-XML של מנוע המדיניות המתאים שאפשר להגדיר, מריצים את קובצי parameter-framework ‏ (PFW) דרך מערכת ה-build, על ידי הגדרת כלל build באמצעות השלבים הבאים:

1. בקובץ Android.bp, יוצרים קבוצת קבצים לקובץ:

   filegroup {
       name: ":device_for_product_strategies.pfw",
       srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
   }
   

2. מוסיפים את הקובץ לקבצים אחרים של PfW (אם יש כאלה).

   filegroup {
       name: "edd_files",
       srcs: [
           ":device_for_input_source.pfw",
           ":volumes.pfw",
           ":device_for_product_strategyies.pfw",
       ],
   }
   

3. יוצרים את הכלל המתאים ליצירת דומיין:

   genrule {
       name: "domaingeneratorpolicyrule_gen",
       defaults: ["domaingeneratorpolicyrule"],
       srcs: [
           ":audio_policy_engine_criterion_types",
           ":audio_policy_pfw_structure_files",
           ":audio_policy_pfw_toplevel",
           ":edd_files",
       ],
   }
   

   ‫domaingeneratorpolicyrule הוא כלל יצירה שסופק על ידי המסגרת כדי ליצור את הקובץ PolicyConfigurableDomains.xml. קבצי המקור האחרים (scrs) שנכללים בכללי יצירת הדומיין הם:

   מקור	תיאור
   audio_policy_pfw_toplevel	קובץ הגדרות של מסגרת הפרמטרים ברמה העליונה.
   audio_policy_pfw_structure_files	קובצי מבנה ליצירת דומיין, שמשמשים ליצירת קובצי ההגדרות.
   audio_policy_engine_criterion_types	קובץ XML של סוגי קריטריונים, שמתאר את הקריטריונים שנעשה בהם שימוש במהלך היצירה.
   edd_files	רשימה של קבצים של דומיין יחיד (כל אחד מכיל תג <ConfigurableDomain> יחיד).

אחרי שמריצים את כלל היצירה ב-build, נוצרת רשימת PolicyConfigurableDomains.xml עם כל הדומיינים. הקטע הבא מציג קטע מהקובץ שנוצר באמצעות הדוגמה של כללי PfW:

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

ניפוי באגים ב-CAP

אפשר להשתמש בפקודה remote-process כדי להציג את הגדרות ה-CAP:

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

כאן מוצגים כל הדומיינים וההגדרות, כולל תנאי החלות. בדוגמה הבאה מוצג קטע מתוך מכשיר רכב של Cuttlefish שמשתמש ב-Bluetooth A2DP, במכשיר bus ובהגדרות ברירת מחדל. הגדרות

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

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

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

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

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

ב-Android 15 ובגרסאות מוקדמות יותר, יכול להיות שהקובץ יהיה שונה, ולכן צריך להשתמש בפקודה הבאה:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

הקובץ צריך להכיל את TuningAllowed="true" יחד עם יציאת השרת המתאימה:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

הקובץ הזה נוצר אוטומטית בהתאם לסוג של קובץ האימג' של ה-build (או שמשתמשים בקובץ אחר לגרסת הפצה או לניפוי באגים בגרסת build מדור קודם). בגרסת build של אפליקציה שמוכנה להפצה, הערך של TuningAllowed מוגדר ל-false בלי יציאת socket (אסור להשתמש ב-sockets בגרסאות build של אפליקציות שמוכנות להפצה). בגרסאות הנדסיות ובגרסאות userdebug, הערך מוגדר ל-true עם יציאת השקע שבה נעשה שימוש. שימו לב: זהו הקובץ שאליו מתייחס audio_policy_pfw_toplevel. הכלי של התהליך המרוחק צריך להיכלל גם ביצרן המכשיר או בקובץ הבנייה:

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

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

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

העברת CAP ב-Android 16

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

תרחיש 1: מכשיר חדש עם Android מגרסה 16 ואילך, ללא מקור קודם להגדרת CAP של המכשיר

מכשיר חדש צריך להיות מושק עם קוד Android מגרסה 16 ואילך במחיצה vendor. כלומר, הוא צריך לחשוף את ההגדרה של מנוע מדיניות האודיו שניתנת להגדרה דרך ממשק AIDL audio HAL. צריך להעתיק את ההגדרה של מנוע CAP של המכשיר מהדוגמאות. לא אמורה להיות הגדרה של דומיין PfW CAP במחיצה vendor.

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

לדוגמה, אפשר לעיין במכשיר וירטואלי של Cuttlefish לרכב, שהוצג בשינוי הזה, כדי לראות את הקבצים הנדרשים, כללי הבנייה וקבצי ה-make שנדרשים להגדרת קובצי ההגדרה הנדרשים. האפשרות הזו פועלת עם טועני הנתונים שמופיעים ב-default AIDL audio HAL.

תרחיש 2: מכשיר חדש עם Android מגרסה 16 ומעלה, ממכשיר קודם עם CAP

מכשיר חדש צריך להיות מושק עם קוד Android מגרסה 16 ואילך במחיצה vendor. עם זאת, מכיוון שיצרן הציוד המקורי יכול להשתמש בהגדרות של מנוע CAP במכשיר, הוא ירצה להשתמש בהן כנקודת התחלה (או לעשות בהן שימוש חוזר מלא). בגרסת AIDL של הגדרת CAP יש כמה שינויים בהשוואה לגרסה של Android 15 וגרסאות קודמות, ולכן הספק צריך להמיר את ההגדרה הקיימת ל-AIDL. בקטע Product strategies מוסבר אילו שינויים נדרשים בגרסה Android 16 ובגרסאות קודמות. באופן כללי, מסגרת האודיו מגלה וטוענת את הגדרות ה-CAP באותה דרך כמו בתרחיש 1.

תרחיש 3: מכשיר קיים עם CAP שעובר עדכון ל-Android 16 רק במחיצת המערכת

בתרחיש הזה, המחיצה vendor מכילה את הגרסה של תצורת ה-CAP של המכשיר ב-Android 15 ובגרסאות קודמות, ואת ההגדרה של תחום ה-CAP של PfW. המחיצה vendor לא משתנה, ולכן היא עדיין משתמשת ב-HIDL HAL. המסגרת פועלת לפי התרחיש של Android 15 ומטה, וטוענת את כל ההגדרות שקשורות ל-CAP ממחיצת vendor.

תרחיש 4: מכשיר קיים ששוחרר עם Android 15, עם CAP

‫CAP לא נתמך ב-AIDL ב-Android 15, ולכן חלק מהספקים השיקו מכשירים חדשים עם AIDL Audio HAL ו-CAP, שנטענו על ידי מסגרת האודיו. המצב המשולב הזה לא היה רשמי, אבל הוא נכלל ב-Android 16. חשוב לשים לב שאסור להשתמש במצב הזה להשקת מכשירים חדשים ב-Android 16, אלא כדי לאפשר למכשירים קיימים עם ספק Android 15 להתעדכן ל-Android 16 (עדכון המחיצה system).

מסגרת האודיו מגלה את הגדרות האודיו של AIDL audio HAL בלי הגדרות CAP. במקרה של הגדרת CAP, שירות מדיניות האודיו (מסגרת האודיו) חוזר לטעינת הגדרת ה-CAP מהמחיצה vendor. במקרה כזה, גם ההגדרה של דומיין ה-CAP של PfW וגם הגדרת ה-CAP של המכשיר צריכות להיטען מהמחיצה vendor.

סיכום ההעברה של CAP

בטבלה הבאה מפורטות דרישות המערכת והספק שמתאימות להגדרת CAP: