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

ב-Android 14, מערכת ההפעלה Android Automotive‏ (AAOS) משתמשת במנוע של מדיניות אודיו שניתנת להגדרה (CAP) לניהול אודיו ברכב באזור האודיו הראשי. ב-Android 16, מנוע ה-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 במחיצת הספק של המכשיר. ההגדרה הזו מסירה את ניתוח ה-XML מהמסגרת. בנוסף, לא נדרש ניתוח של ה-XML ב-Audio HAL עצמו. במקום זאת, היא צריכה לספק את נתוני ההגדרה באמצעות AIDL, שאפשר לאחזר מכל מקור. לנוחותכם, הטמעת ברירת המחדל של AOSP של Audio HAL מספקת ממיר XML ‏ (EngineConfigXmlConverter.cpp) כדי לנתח את הגדרת ה-XML הרגילה ולאכלס את אובייקטי AIDL ‏AudioHalEngineConfig באופן מקורי.

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

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

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

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

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

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

• הגדרות אישיות
• אסטרטגיות
• נפחי אחסון
• קריטריונים
• הגדרות

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

כדי להקל על המעבר מ-HIDL ל-AIDL, ‏ default audio AIDL Audio HAL מספק CAP engine loader בפורמט 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. לדוגמה:

ניתוב אודיו רב-אזורי

ב-Android מגרסה 16 ואילך, סכימת ה-CAP משולבת בהגדרות האודיו הרב-אזורי של Android Automotive.

במנוע CAP, מאפיין zoneId אופציונלי ב-ProductStrategy משמש כקריטריון להתאמת מקור, ומסנן את הסטרימינג על סמך אזור המקור שממנו מתבצעת ההפעלה.

1. התאמה למקור (zoneId): כש-CarAudioService רושם מיפויים של משתמשים לאזורים באמצעות setProductStrategiesZoneIdForUser, מנוע ה-CAP משתמש ב-zoneId כפרמטר התאמה כדי לבחור את ProductStrategy המתאים לסטרימינג של האזור הזה.
2. ניתוב ליעד (נקודות קצה של המכשיר): כשמקבצים את ההגדרות לאסטרטגיות, הגדרת ניתוב האודיו מגדירה את המיפוי בין אסטרטגיות המוצר האלה לבין מכשירי הפלט, לדוגמה, מכשיר אוטובוס כמו bus100_media_out לאזור 1.

באסטרטגיות למוצרים ב-<ProductStrategies> אפשר לציין את zoneId שמתאים לאזור התפוסה (נהג או נוסע):

<ProductStrategies>
    <!-- General Primary Zone Media -->
    <ProductStrategy name="music_primary" id="1000" zoneId="0">
        <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media_vol_primary">
            <Attributes>
                <Usage value="AUDIO_USAGE_MEDIA"/>
            </Attributes>
        </AttributesGroup>
    </ProductStrategy>

    <!-- Secondary Zone Media Endpoint -->
    <ProductStrategy name="music_rear_seat" id="1002" zoneId="1">
        <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media_vol_rear">
            <Attributes>
                <!-- Rear seat entertainment attribute mapping via bundle tags -->
                <Usage value="AUDIO_USAGE_MEDIA"/>
                <Bundle key="VX_OEM" value="REAR_SEAT"/>
            </Attributes>
        </AttributesGroup>
    </ProductStrategy>
</ProductStrategies>

שיטות בידינג

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

• סוגי השימוש מתארים למה מושמע צליל (כלומר, מדיה, התראה, שיחה).
• סוג התוכן הסוגים מתארים את התוכן שמופעל (כלומר, מוזיקה, דיבור, סרטון, המרת נתונים לאודיו).
• סוגי הדגלים מגדירים התנהגויות או בקשות שונות ביחס לסטרימינג. שימו לב שאם יש כמה דגלים, צריך להזין אותם כמחרוזת מופרדת ברווחים, למשל, <Flags value="AUDIO_FLAG_SCO AUDIO_FLAG_BEACON"/>.
• סוגי התגים תומכים בכל רשימה שרירותית של ערכי מחרוזות של ספקים. כדי להגדיר תג בהגדרה, צריך להשתמש ברכיב <Bundle>.
  • כל מפתח של חבילה חייב להתחיל בקידומת VX_ ואחריה מחרוזת אלפאנומרית, לדוגמה, <Bundle key="VX_OEM" value="REAR_SEAT"/>.

<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>

בקטע הזה מוצגת דוגמה לשימוש באסטרטגיית מוצר באמולטורים של מכוניות. הוא מכיל שני מאפייני אודיו עם מדיה ומשחק של שימוש באודיו בהתאמה. שימו לב שאסטרטגיות המוצרים של הספק שמוגדרות ב-XML חייבות לכלול במפורש מאפיין id (לדוגמה, id="1008" בקטע הקוד שלמעלה), שממופה ישירות למזהה האסטרטגיה הסטנדרטי שנדרש על ידי Audio HAL. אם ספק id מושמט, ההגדרה מפעילה התנהגות מסוכנת של חזרה למצב קודם במהלך הניתוח.

אסטרטגיית המוצר הזו תואמת להקשר האודיו שמשמש בשירות האודיו ברכב, 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 כדי ליצור dump של הגדרות ה-CAP:

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

כאן מוצגים כל הדומיינים וההגדרות, כולל תנאי החלות. בדוגמה הבאה מוצג קטע ממכשיר Cuttlefish Automotive שבו נעשה שימוש ב-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 להפצה, הערך של 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 או גרסה מתקדמת יותר. ה-framework של שירות האודיו מגלה את הגדרת ה-CAP דרך ממשק ה-HAL של האודיו ב-AIDL, ולכן הוא מאתחל את PfW באמצעות הגדרת תחום ה-CAP של PfW מקובץ אימג' של המערכת, וטוען את הגדרת ה-CAP של המכשיר שהתקבלה דרך AIDL.

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

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

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

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

בתרחיש הזה, המחיצה vendor מכילה את הגרסה Android 15 ומטה של הגדרת ה-CAP של המכשיר, ואת ההגדרה של תחום ה-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. במקרה כזה, צריך לטעון את הגדרת הדומיין של PfW CAP ואת הגדרת ה-CAP של המכשיר ממחיצת vendor.

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

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