اجرای سلامت 2.1

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

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

  1. healthd با وجود اینکه IHealth یک سرویس سیستم است، آن را در hwservicemanager ثبت می‌کند. IHealth با نام نمونه "backup" به مانیفست سیستم اضافه می‌شود.
  2. فریم‌ورک و storaged به جای binder از طریق hwbinder با healthd ارتباط برقرار می‌کنند.
  3. کد مربوط به framework و storaged طوری تغییر داده می‌شود که در صورت وجود، نمونه‌ی "default" و سپس "backup" را دریافت کند.
    • کد کلاینت C++ از منطق تعریف‌شده در libhealthhalutils استفاده می‌کند.
    • کد کلاینت جاوا از منطق تعریف شده در HealthServiceWrapper استفاده می‌کند.
  4. پس از اینکه IHealth/default به طور گسترده در دسترس قرار گرفت و ایمیج‌های فروشندگان اندروید ۸.۱ منسوخ شدند، IHealth/backup و healthd نیز می‌توانند منسوخ شوند.

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

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

در health@2.1، فروشندگان می‌توانند این دو مقدار فاصله زمانی دوره‌ای chores را در ساختار healthd_config قبل از ارسال به سازنده کلاس پیاده‌سازی health، بازنویسی کنند. کلاس پیاده‌سازی health باید از 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 BatteryManager.queryProperty(int id) تنها کلاینت IBatteryPropertiesRegistrar.getProperty بود. IBatteryPropertiesRegistrar.getProperty توسط healthd ارائه شده بود و مستقیماً /sys/class/power_supply می‌خواند.

    به عنوان یک ملاحظه امنیتی، برنامه‌ها مجاز به فراخوانی مستقیم health HAL نیستند. در اندروید ۹ و بالاتر، سرویس binder به نام IBatteryPropertiesRegistrar به جای healthd توسط BatteryService ارائه می‌شود. BatteryService فراخوانی را به health HAL محول می‌کند تا اطلاعات درخواستی را بازیابی کند.

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

  • Storaged. در اندروید ۹ و بالاتر، 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 را انتخاب کنید.

آزمایش

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

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

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

  • واحدهای جریان باتری لحظه‌ای و متوسط ​​باید میکروآمپر (μ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 بر ۱۰۰۰ تقسیم می‌کند و مقادیر را بر حسب میلی‌ولت (mV) گزارش می‌دهد. به @1.0::HealthInfo مراجعه کنید.

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