پیاده‌سازی Health 2.1

در Android 11، همه کد healthd به libhealthloop و libhealth2impl تغییر می‌کند، سپس برای پیاده‌سازی health@2.1 HAL اصلاح می‌شود. این دو کتابخانه به‌صورت ایستا توسط 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 8.x یا 9 و چارچوب Android 11، ممکن است تصویر فروشنده سرویس health@2.1 را ارائه ندهد. برنامه زمانی منسوخ شدن سازگاری با نسخه قدیمی تصاویر فروشنده را اعمال می‌کند.

برای اطمینان از سازگاری با نسخه‌های قدیمی:

  1. ‫healthd بااینکه یک دیمون سیستم است، IHealth را در hwservicemanager ثبت می‌کند. ‫IHealth به مانیفست سیستم اضافه می‌شود، با نام نمونه «backup».
  2. چارچوب و storaged ازطریق hwbinder به‌جای binder با healthd ارتباط برقرار می‌کنند.
  3. کد چارچوب و storaged تغییر کرده است تا نمونه «پیش‌فرض» را درصورت وجود، و سپس «پشتیبان» را واکشی کند.
    • کد مشتری C++‎ از منطق تعریف‌شده در libhealthhalutils استفاده می‌کند.
    • کد کارخواه Java از منطق تعریف‌شده در HealthServiceWrapper استفاده می‌کند.
  4. پس‌از اینکه IHealth/default به‌طور گسترده دردسترس قرار گرفت و تصاویر فروشنده Android 8.1 منسوخ شد، IHealth/backup و healthd می‌توانند منسوخ شوند.

متغیرهای ساخت مخصوص برد برای healthd

‫BOARD_PERIODIC_CHORES_INTERVAL_* متغیرهای مختص برد هستند که برای ساختن healthd استفاده می‌شوند. به‌عنوان بخشی از تقسیم ساخت سیستم/فروشنده، مقادیر خاص برد نمی‌تواند برای واحدهای سیستم تعریف شود. این مقادیر قبلاً در تابع منسوخ‌شده healthd_board_init ملغی می‌شد.

در health@2.1، فروشندگان می‌توانند این دو مقدار فاصله کارهای دوره‌ای را در ساختار healthd_config قبل‌از گذراندن به سازنده کلاس پیاده‌سازی سلامت ملغی کنند. کلاس پیاده‌سازی سلامت باید از android::hardware::health::V2_1::implementation::Health ارث ببرد.

پیاده‌سازی سرویس Health 2.1

برای اطلاعات درباره پیاده‌سازی سرویس «سلامت ۲.۱»، به hardware/interfaces/health/2.1/README.md مراجعه کنید.

مشتریان سلامت

‫health@2.x مشتریان زیر را دارد:

  • شارژر را وصل کنید. استفاده از libbatterymonitor و کد healthd_common در health@2.0-impl پیچیده شده است.
  • بازیابی. پیوند به libbatterymonitor در health@2.0-impl پیچیده شده است. همه تماس‌ها با BatteryMonitor با تماس‌های کلاس پیاده‌سازی Health جایگزین می‌شوند.

  • BatteryManager. BatteryManager.queryProperty(int id) تنها مشتری IBatteryPropertiesRegistrar.getProperty بود. ‫IBatteryPropertiesRegistrar.getProperty توسط healthd ارائه شده است و /sys/class/power_supply مستقیماً آن را می‌خواند.

    به‌دلیل ملاحظات امنیتی، برنامه‌ها مجاز نیستند مستقیماً با لایه انتزاع سخت‌افزار سلامت تماس بگیرند. در Android 9 و بالاتر، سرویس پیونددهنده IBatteryPropertiesRegistrar به‌جای healthd توسط BatteryService ارائه می‌شود. BatteryService تماس را به HAL سلامت واگذار می‌کند تا اطلاعات درخواستی را بازیابی کند.

  • BatteryService. در Android 9 و بالاتر، BatteryService از HealthServiceWrapper استفاده می‌کند تا تعیین کند از نمونه سرویس سلامت پیش‌فرض از vendor استفاده کند یا از نمونه سرویس سلامت پشتیبان از healthd استفاده کند. سپس BatteryService ازطریق IHealth.registerCallback به رویدادهای سلامتی گوش می‌دهد.

  • ذخیره‌شده. در Android 9 و بالاتر، storaged از libhealthhalutils برای تعیین اینکه از نمونه سرویس سلامت پیش‌فرض vendor استفاده کند یا از نمونه سرویس سلامت پشتیبان healthd استفاده کند استفاده می‌کند. سپس storaged ازطریق IHealth.registerCallback به رویدادهای سلامتی گوش می‌دهد و اطلاعات ذخیره‌سازی را بازیابی می‌کند.

تغییرات SELinux

‫health@2.1 HAL شامل تغییرات 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 (در «سلامت» نسخه ۲.۱ اضافه شده است)
  • /sys/class/power_supply/*/capacity
  • /sys/class/power_supply/*/charge_counter
  • /sys/class/power_supply/*/charge_full
  • ‫/sys/class/power_supply/*/charge_full_design (در «سلامت» نسخه ۲.۱ اضافه شده است)
  • /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 (در «سلامت» نسخه ۲.۱ اضافه شده است)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

هر پیاده‌سازی HAL سلامت مختص دستگاه که از libbatterymonitor استفاده می‌کند، به‌طور پیش‌فرض به این میاناهای هسته دسترسی دارد، مگراینکه در سازنده کلاس پیاده‌سازی سلامت لغو شده باشد.

اگر این فایل‌ها وجود نداشته باشند یا از 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 جدیدی است که به‌طور خاص برای health@2.1 HAL نوشته شده است. اگر دستگاهی health@2.1 HAL را در مانیفست دستگاه اعلام کند، باید آزمون‌های VTS مربوطه را با موفقیت بگذراند. آزمایش‌ها هم برای نمونه پیش‌فرض (برای اطمینان از اینکه دستگاه «لایه انتزاع سخت‌افزار» را به‌درستی پیاده‌سازی می‌کند) و هم برای نمونه پشتیبان (برای اطمینان از اینکه healthd قبل‌از برداشته شدن همچنان به‌درستی کار می‌کند) نوشته می‌شوند.

الزامات اطلاعات باتری

Health 2.0 HAL مجموعه‌ای از الزامات را در رابط HAL بیان می‌کند، اما آزمایش‌های VTS مربوطه در اجرای آن‌ها نسبتاً آسان‌گیر هستند. در Android 11، آزمایش‌های VTS جدیدی اضافه شده است تا الزامات زیر را در دستگاه‌هایی که با Android 11 و بالاتر راه‌اندازی می‌شوند اعمال کند:

  • واحد جریان باتری لحظه‌ای و میانگین باید میکروآمپر (μA) باشد.
  • علامت جریان باتری لحظه‌ای و متوسط باید صحیح باشد. به‌طور مشخص:
    • وقتی وضعیت باتری UNKNOWN است، مقدار فعلی برابر با ۰ است
    • جریان > ۰ وقتی وضعیت باتری CHARGING است
    • وقتی وضعیت باتری NOT_CHARGING است، جریان <= ۰ است
    • وقتی وضعیت باتری DISCHARGING است، جریان < ۰ است
    • وقتی وضعیت باتری FULL باشد اعمال نمی‌شود
  • وضعیت باتری باید با متصل بودن یا نبودن منبع برق مطابقت داشته باشد. به‌طور خاص:
    • وضعیت باتری باید یکی از 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 را بر ۱۰۰۰ تقسیم می‌کند و مقادیر را برحسب میلی‌ولت (mV) گزارش می‌کند. به @1.0::HealthInfo مراجعه کنید.

برای جزئیات، کلاس منبع تغذیه Linux را ببینید.