ב-Android 11, כל הקוד של healthd
עובר עיבוד מחדש ל-libhealthloop
ול-libhealth2impl
, ולאחר מכן משתנה כדי להטמיע את ה-HAL של health@2.1. שתי הספריות האלה מקושרות באופן סטטי באמצעות health@2.0-impl-2.1
, הטמעת ההעברה של Health 2.1. הספריות המקושרות באופן סטטי מאפשרות ל-health@2.0-impl-2.1
לבצע את אותן משימות כמו healthd
, כמו הפעלת healthd_mainloop
ובדיקת סטטוס. ב-init, ה-health@2.1-service
רושם הטמעה של הממשק IHealth
ל-hwservicemanager
. כשמשדרגים מכשירי Android עם קובץ אימג' של ספק עם Android 8.x או 9 ו-Android Framework 11, יכול להיות שקובץ האימג' של הספק לא יספק את השירות health@2.1. התאימות לאחור לתמונות ישנות של ספקים נאכפת באמצעות לוח הזמנים להוצאה משימוש.
כדי להבטיח תאימות לאחור:
healthd
רושם אתIHealth
ב-hwservicemanager
למרות שהוא דימון מערכת.IHealth
מתווסף למניפסט המערכת, עם שם המכונה 'backup'.- המסגרת ו-
storaged
מתקשרים עםhealthd
דרךhwbinder
במקוםbinder
. - הקוד של framework ו-
storaged
משתנה כדי לאחזר את המכונה 'default' אם היא זמינה, ואז את המכונה 'backup'.- קוד הלקוח של C++ משתמש בלוגיקה שהוגדרה ב-
libhealthhalutils
. - קוד הלקוח ב-Java משתמש בלוגיקה שהוגדרה ב-
HealthServiceWrapper
.
- קוד הלקוח של C++ משתמש בלוגיקה שהוגדרה ב-
- אחרי שהאפליקציה IHealth/default זמינה לכולם, ותמונות של ספקי Android 8.1 הוצאו משימוש, אפשר להוציא את IHealth/backup ו-
healthd
. לפרטים נוספים, ראו הוצאה משימוש של Health@1.0.
משתני build ספציפיים ללוח ל-healthd
BOARD_PERIODIC_CHORES_INTERVAL_*
הם משתנים ספציפיים ללוח המשמשים ליצירת healthd
. כחלק מהחלוקה של גרסאות build למערכת ולספק, אי אפשר להגדיר ערכים ספציפיים ללוח למודול המערכת. בעבר, אפשר היה לשנות את הערכים האלה בפונקציה healthd_board_init
שהוצאה משימוש.
ב-Health@2.1, ספקים יכולים לשנות את שני הערכים של מרווחי הזמן התקופתיים האלה במבנה healthd_config
לפני שהם עוברים ל-constructor של סיווג הבריאות. מחלקת ההטמעה של בדיקת התקינות צריכה לרשת מ-android::hardware::health::V2_1::implementation::Health
.
הטמעת השירות Health 2.1
למידע על הטמעת שירות Health 2.1, אפשר לעיין במאמר hardware/interfaces/health/2.1/README.md.
לקוחות בתחום הבריאות
ל-health@2.x יש את הלקוחות הבאים:
- charger השימוש בקוד
libbatterymonitor
ובקודhealthd_common
מוקף ב-health@2.0-impl
. - recovery. הקישור אל
libbatterymonitor
עטוף ב-health@2.0-impl
. כל הקריאות ל-BatteryMonitor
מוחלפות בקריאות למחלקת ההטמעהHealth
. BatteryManager
BatteryManager.queryProperty(int id)
היה הלקוח היחיד שלIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
סופק על ידיhealthd
ונקרא ישירות על ידי/sys/class/power_supply
.מטעמי אבטחה, אפליקציות לא מורשות לבצע קריאה ישירה ל-HAL של בריאות. ב-Android מגרסה 9 ואילך, שירות ה-binder
IBatteryPropertiesRegistrar
מסופק על ידיBatteryService
במקום על ידיhealthd
.BatteryService
מעביר את הקריאה ל-HAL של שירותי הבריאות כדי לאחזר את המידע המבוקש.BatteryService ב-Android 9 ואילך,
BatteryService
משתמש ב-HealthServiceWrapper
כדי לקבוע אם להשתמש במכונה של שירות הבריאות שמוגדרת כברירת מחדל ב-vendor
או במכונה של שירות הבריאות שמוגדרת לגיבוי ב-healthd
. לאחר מכן,BatteryService
מקשיב לאירועי בריאות דרךIHealth.registerCallback
.אחסון ב-Android 9 ואילך,
storaged
משתמש ב-libhealthhalutils
כדי לקבוע אם להשתמש במכונה של שירות הבריאות שמוגדרת כברירת מחדל ב-vendor
או במכונה של שירות הבריאות שמוגדרת לגיבוי ב-healthd
. לאחר מכן,storaged
מקשיב לאירועי בריאות דרךIHealth.registerCallback
ומאחזר את פרטי האחסון.
שינויים ב-SELinux
ה-HAL של health@2.1 כולל את השינויים הבאים ב-SELinux בפלטפורמה:
- הוספה של
android.hardware.health@2.1-service
אלfile_contexts
.
במכשירים עם הטמעה משלהם, יכול להיות שיהיה צורך לבצע שינויים מסוימים ב-SELinux של הספק. דוגמה:
# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.
ממשקי ליבה
healthd
הדימון ויישום ברירת המחדל android.hardware.health@2.0-impl-2.1
ניגשים לממשקי הליבה הבאים כדי לאחזר מידע על הסוללה:
/sys/class/power_supply/*/capacity_level
(נוסף ב-Health 2.1)/sys/class/power_supply/*/capacity
/sys/class/power_supply/*/charge_counter
/sys/class/power_supply/*/charge_full
/sys/class/power_supply/*/charge_full_design
(נוסף ב-Health 2.1)/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
/sys/class/power_supply/*/cycle_count
/sys/class/power_supply/*/health
/sys/class/power_supply/*/online
/sys/class/power_supply/*/present
/sys/class/power_supply/*/status
/sys/class/power_supply/*/technology
/sys/class/power_supply/*/temp
/sys/class/power_supply/*/time_to_full_now
(נוסף ב-Health 2.1)/sys/class/power_supply/*/type
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
כל הטמעה ספציפית למכשיר של HAL לבריאות שמשתמשת ב-libbatterymonitor
מקבלת גישה לממשקי הליבה האלה כברירת מחדל, אלא אם הוגדר שינוי ב-constructor של מחלקת הטמעת הבריאות.
אם הקבצים האלה חסרים או שאין גישה אליהם מ-healthd
או מהשירות שמוגדר כברירת מחדל (לדוגמה, הקובץ הוא קישור סימלי לתיקייה ספציפית לספק שמסרב לתת גישה בגלל הגדרה שגויה של מדיניות SELinux), יכול להיות שהם לא יפעלו כמו שצריך. לכן, יכול להיות שיהיה צורך בשינויים נוספים ב-SELinux ספציפיים לספק, גם אם נעשה שימוש בהטמעה שמוגדרת כברירת מחדל.
יכול להיות שחלק מממשקי הליבה שבהם נעשה שימוש ב-Health 2.1, כמו /sys/class/power_supply/*/capacity_level
ו-/sys/class/power_supply/*/time_to_full_now
, יהיו אופציונליים. עם זאת, כדי למנוע התנהגות שגויה של המסגרת כתוצאה מממשקי ליבה חסרים, מומלץ לבחור את CL 1398913 לפני שמפתחים את השירות Health HAL 2.1.
בדיקה
Android 11 כולל בדיקות VTS חדשות שנכתבו במיוחד עבור ה-HAL של health@2.1. אם מכשיר מצהיר על HAL של health@2.1 במניפסט של המכשיר, הוא חייב לעבור את בדיקות ה-VTS המתאימות.
הבדיקות נכתבות גם במופע ברירת המחדל (כדי לוודא שהמכשיר מטמיע את ה-HAL בצורה נכונה) וגם במכונה לגיבוי (כדי לוודא ש-healthd
ימשיך לפעול כראוי לפני שמסירים אותו).
דרישות לגבי פרטי הסוללה
ב-HAL של Health 2.0 מפורטות כמה דרישות לממשק ה-HAL, אבל בדיקות ה-VTS התואמות לא מקפידות על אכיפתן. ב-Android 11 נוספו בדיקות VTS חדשות כדי לאכוף את הדרישות הבאות במכשירים שמושקעים עם Android מגרסה 11 ואילך:
- היחידות של זרם הסוללה המיידי והממוצע חייבות להיות מיקרו-אמפר (μA).
- הסימן של זרם הסוללה המיידי והממוצע חייב להיות נכון.
באופן ספציפי:
- current == 0 כאשר סטטוס הסוללה הוא
UNKNOWN
- current > 0 כשסטטוס הסוללה הוא
CHARGING
- הערך הנוכחי <= 0 כשסטטוס הסוללה הוא
NOT_CHARGING
- current < 0 כאשר סטטוס הסוללה הוא
DISCHARGING
- לא נאכף כשמצב הסוללה הוא
FULL
- current == 0 כאשר סטטוס הסוללה הוא
- סטטוס הסוללה צריך להיות נכון בהתאם למצב שבו מקור החשמל מחובר או לא מחובר. באופן ספציפי:
- סטטוס הסוללה חייב להיות אחד מהערכים
CHARGING
,NOT_CHARGING
אוFULL
אם ורק אם מקור חשמל מחובר. - סטטוס הסוללה חייב להיות
DISCHARGING
אם ורק אם מקור החשמל מנותק.
- סטטוס הסוללה חייב להיות אחד מהערכים
אם משתמשים ב-libbatterymonitor
בהטמעה ומעבירים ערכים מממשקי הליבה, צריך לוודא שהצומתים של sysfs מדווחים על ערכים נכונים:
- יש לוודא שרמת הטעינה של הסוללה מדווחת באמצעות הסימנים והיחידות הנכונים. הרשימה כוללת את צמת ה-sysfs הבאים:
/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
- ערכים חיוביים מציינים זרם נכנס לסוללה.
- הערכים צריכים להיות מיקרו-אמפר (μA).
- מוודאים שמתח הסוללה מדווח במיקרו-וולט (μV). הם כוללים את צמת ה-sysfs הבאים:
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
- שימו לב שההטמעה שמוגדרת כברירת מחדל ב-HAL מחלקת את הערך
voltage_now
ב-1000 ומדווחת על ערכים במיליוולט (mV). למידע נוסף: @1.0::HealthInfo.
למידע נוסף, ראו סיווג ספק החשמל של Linux.