اجرای سلامت 2.1

در اندروید 11، تمام کدهای healthd به libhealthloop و libhealth2impl بازسازی می‌شوند، سپس برای پیاده‌سازی Health@2.1 HAL اصلاح می‌شوند. این دو کتابخانه به صورت ایستا توسط health@2.0-impl-2.1 ، اجرای گذرا Health 2.1 به هم مرتبط شده اند. کتابخانه‌های مرتبط استاتیک health@2.0-impl-2.1 2.1 را قادر می‌سازد تا همان کار healthd را انجام دهد، مانند اجرای healthd_mainloop و polling. در init، سرویس health@2.1-service پیاده سازی رابط IHealth را برای hwservicemanager ثبت می کند. هنگام ارتقای دستگاه‌هایی با تصویر فروشنده Android 8.x یا 9 و چارچوب Android 11، ممکن است تصویر فروشنده سرویس health@2.1 را ارائه ندهد. سازگاری به عقب با تصاویر فروشنده قدیمی توسط برنامه منسوخ شدن اعمال می شود.

برای اطمینان از سازگاری به عقب:

  1. healthd IHealth به hwservicemanager ثبت می‌کند، علیرغم اینکه یک شبح سیستم است. IHealth با نام نمونه "پشتیبان" به مانیفست سیستم اضافه می شود.
  2. فریمورک و storaged به جای binder از طریق hwbinder با healthd ارتباط برقرار می کنند.
  3. کد چارچوب و storaged برای واکشی نمونه «پیش‌فرض» در صورت موجود بودن، و سپس «پشتیبان‌گیری» تغییر می‌کند.
    • کد مشتری C++ از منطق تعریف شده در libhealthhalutils استفاده می کند.
    • کد مشتری جاوا از منطق تعریف شده در 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 را پیاده سازی کنید

برای اطلاعات در مورد اجرای سرویس 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 را خواند.

    به عنوان یک ملاحظات امنیتی، برنامه‌ها اجازه ندارند مستقیماً با Health HAL تماس بگیرند. در اندروید 9 و بالاتر، سرویس کلاسور IBatteryPropertiesRegistrar به جای healthd توسط BatteryService ارائه می شود. BatteryService تماس را به Health 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 (افزوده شده در 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 استفاده می‌کند به طور پیش‌فرض به این رابط‌های هسته دسترسی دارد، مگر اینکه در سازنده کلاس اجرای سلامت لغو شود.

اگر این فایل‌ها گم شده باشند یا از healthd یا سرویس پیش‌فرض غیرقابل دسترسی باشند (برای مثال، فایل یک پیوند نمادین به یک پوشه خاص فروشنده است که به دلیل پیکربندی نادرست خط‌مشی SELinux، دسترسی را رد می‌کند)، ممکن است به درستی کار نکنند. بنابراین ممکن است تغییرات اضافی SELinux مخصوص فروشنده ضروری باشد حتی اگر از پیاده سازی پیش فرض استفاده شود.

برخی از رابط های هسته مورد استفاده در Health 2.1، مانند /sys/class/power_supply/*/capacity_level و /sys/class/power_supply/*/time_to_full_now ممکن است اختیاری باشند. با این حال، برای جلوگیری از رفتارهای نادرست چارچوب ناشی از از دست رفتن رابط های هسته، توصیه می شود قبل از ساخت سرویس Health HAL 2.1، CL 1398913 را انتخاب کنید.

تست کردن

اندروید 11 شامل تست های جدید VTS است که به طور خاص برای health@2.1 HAL نوشته شده است. اگر دستگاهی Health@2.1 HAL را در مانیفست دستگاه اعلام کند، باید تست‌های VTS مربوطه را بگذراند. تست‌ها هم برای نمونه پیش‌فرض (برای اطمینان از اجرای صحیح HAL) و هم برای نمونه پشتیبان (برای اطمینان از اینکه healthd قبل از حذف به درستی کار می‌کند) نوشته شده‌اند.

اطلاعات مورد نیاز باتری

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

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

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