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

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

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

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

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

רקע

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

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

איפוס CAP לפני Android 16

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

איור 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 default buildstrategiesstructurerule באופן הבא:

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

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

קובצי הגדרות CAP ב-Android מגרסה 15 ומטה

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

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

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

AIDL audio HAL CAP initialization

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

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

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

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

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

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

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

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

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

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

מעבד AIDL Audio HAL להפעלה כברירת מחדל

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

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

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

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

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

המבנה בהגדרת AIDL

ב-Android מגרסה 16 ואילך, שירות מדיניות האודיו מקבל את פרטי המבנה על ידי קריאה וניתוח של הקובץ ParameterFrameworkConfigurationCap.xml. באופן ספציפי, המידע מגיע מקובץ תיאור המבנה:

<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_ ולאחר מכן מספר שמייצג את מזהה אסטרטגיית המוצר בהגדרת אסטרטגיית המוצר של HAL אודיו ב-AIDL. שאר ההגדרות (לדוגמה, קבוצות של מאפייני אודיו, שם) מתקבלות מהאובייקט AudioHALProductStrategy בהגדרת מנוע HAL של האודיו.

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

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

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

• סוגי השימוש מתארים למה הצליל מופעל (כלומר, מדיה, התראה, שיחה).
• סוגי סוג התוכן מתארים את מה שמופעל (כלומר, מוזיקה, דיבור, וידאו, סאונדפיקציה).
• סוגי דגלים מגדירים התנהגות או בקשות שונות בנוגע לסטרימינג.
• סוגי Tags תומכים בכל רשימה שרירותית של ערכים של מחרוזות של ספקים.
  • כל מחרוזת חייבת להתחיל ב-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 ל-OEMs שמשתמשים ב-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. הגדרות:

- 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 (או משתמשים בקובץ אחר ל-release או ל-debug בגרסאות build קודמות). בגרסת build למהדורה מוגדרת הערך TuningAllowed ל-false ללא יציאת שקע (אסור להשתמש בשקעים לצורך כך בגרסת build למהדורה). ב-builds של מהנדסים ו-userdebug, הערך מוגדר ל-true עם יציאת ה-socket שבה נעשה שימוש. שימו לב: זהו הקובץ שאליו מפנה השדה audio_policy_pfw_toplevel. כלי העיבוד מרחוק צריך להיכלל גם בקובץ make או בקובץ ה-build של המכשיר:

# 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. כלומר, הוא צריך לחשוף את ההגדרה של מנוע מדיניות האודיו שניתן לשינוי דרך ממשק ה-HAL של האודיו ב-AIDL. צריך להעתיק את ההגדרות של מנוע Device CAP מהדוגמאות. אסור שתהיה הגדרה של דומיין PfW CAP במחיצה vendor.

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

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

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

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

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

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

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

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

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

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

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