اجرای Health 2.0

همه کد healthd به health@2.0-impl و libhealthservice تغییر داده شده است، سپس برای پیاده سازی health@2.0 HAL اصلاح شده است. این دو کتابخانه به صورت ایستا توسط health@2.0-service به هم مرتبط شده اند و به آن امکان می دهد کارهایی را که قبلا توسط healthd انجام شده بود انجام دهد (یعنی healthd_mainloop را اجرا کنید و نظرسنجی را انجام دهید). در init، سرویس health@2.0 پیاده سازی رابط IHealth را برای hwservicemanager ثبت می کند. هنگام ارتقای دستگاه‌هایی با تصویر فروشنده Android 8.x و چارچوب Android 9، ممکن است سرویس health@2.0 توسط تصویر فروشنده ارائه نشود. این توسط برنامه منسوخ شدن اجرا می شود.

برای حل این مشکل:

  1. healthd IHealth در hwservicemanager ثبت می‌کند (با وجود اینکه یک شبح سیستم است). IHealth با نام مثال "backup" به مانیفست سیستم اضافه می شود.
  2. فریم ورک و storaged از طریق hwbinder به جای binder با healthd ارتباط برقرار می کنند.
  3. کد برای چارچوب و storaged برای واکشی نمونه "default" در صورت وجود، و سپس "backup" تغییر می‌کند.
    • کد مشتری C++ از منطق تعریف شده در libhealthhalutils استفاده می کند.
    • کد مشتری جاوا از منطق تعریف شده در HealthServiceWrapper استفاده می کند.
  4. پس از اینکه IHealth/default به طور گسترده در دسترس قرار گرفت و تصاویر فروشنده Android 8.1 منسوخ شدند، IHealth/Backup و healthd می توانند منسوخ شوند. برای جزئیات بیشتر، Deprecating health@1.0 را ببینید.

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

BOARD_PERIODIC_CHORES_INTERVAL_* متغیرهای مخصوص تابلو هستند که برای ساخت healthd استفاده می‌شوند. به عنوان بخشی از تقسیم ساخت سیستم/فروشنده، مقادیر ویژه برد را نمی توان برای ماژول های سیستم تعریف کرد. در health@2.0، فروشندگان می توانند این دو مقدار را در healthd_mode_ops->init لغو کنند (با حذف وابستگی libhealthservice در health@2.0-service.<device> و اجرای مجدد این تابع).

کتابخانه پیاده سازی استاتیک

برخلاف سایر کتابخانه‌های پیاده‌سازی HAL، کتابخانه پیاده‌سازی health@2.0-impl یک کتابخانه ثابت است که health@2.0-service، شارژر، بازیابی، و legacy healthd به آن پیوند دارند.

health@2.0.impl IHealth همانطور که در بالا توضیح داده شد پیاده‌سازی می‌کند و هدف آن قرار دادن libbatterymonitor و libhealthd. BOARD . این کاربران health@2.0-impl نباید مستقیماً از BatteryMonitor یا توابع موجود در libhealthd استفاده کنند. در عوض، این تماس‌ها باید با تماس‌های کلاس Health جایگزین شوند، که یک پیاده‌سازی رابط IHealth است. برای تعمیم بیشتر، کد healthd_common نیز در health@2.0-impl گنجانده شده است. healthd_common جدید شامل بقیه کدهای مشترک بین health@2.0-service، شارژر و healthd است و به جای BatteryMonitor به روش های IHealth فراخوانی می کند.

سرویس Health 2.0 را پیاده سازی کنید

هنگام اجرای سرویس health@2.0 برای یک دستگاه، اگر اجرای پیش فرض این است:

  • برای دستگاه کافی است، مستقیماً از android.hardware.health@2.0-service استفاده کنید.

  • برای دستگاه کافی نیست، android.hardware.health@2.0-service.(device) قابل اجرا را ایجاد کنید و شامل موارد زیر باشد:

    #include <health2/service.h>
int main() { return health_service_main(); }

سپس:

  • اگر libhealthd:

    • وجود دارد، به آن پیوند دهید.
    • وجود ندارد، پیاده سازی های خالی برای توابع healthd_board_init و healthd_board_battery_update ارائه کنید.

  • اگر متغیرهای BOARD_PERIODIC_CHORES_INTERVAL_* مخصوص تابلو باشد:

    • تعریف شده است، یک HealthServiceCommon.cpp مخصوص دستگاه ایجاد کنید (کپی شده از hardware/interfaces/health/2.0/utils/libhealthservice ) و آن را در healthd_mode_service_2_0_init سفارشی کنید.
    • تعریف نشده اند، به صورت ایستا به libhealthservice پیوند دهید.

  • اگر دستگاه:

    • اگر API های getStorageInfo و getDiskStats را پیاده سازی کنید، پیاده سازی را در توابع get_storage_info و get_disk_stats ارائه دهید.
    • نباید آن APIها را پیاده سازی کنید، به صورت ایستا به libstoragehealthdefault پیوند دهید.

  • مجوزهای لازم SELinux را به روز کنید.

  • پیاده سازی HAL در بازیابی با نصب یک پیاده سازی عبوری در تصویر بازیابی. مثال:

    // Android.bp
cc_library_shared {
    name: "android.hardware.health@2.0-impl-<device>",
    recovery_available: true,
    relative_install_path: "hw",
    static_libs: [
        "android.hardware.health@2.0-impl",
        "libhealthd.<device>"
        // Include the following or implement device-specific storage APIs
        "libhealthstoragedefault",
    ],
    srcs: [
        "HealthImpl.cpp",
    ],
    overrides: [
        "android.hardware.health@2.0-impl-default",
    ],
}

    // HealthImpl.cpp
#include <health2/Health.h>
#include <healthd/healthd.h>
using android::hardware::health::V2_0::IHealth;
using android::hardware::health::V2_0::implementation::Health;
extern "C" IHealth* HIDL_FETCH_IHealth(const char* name) {
    const static std::string providedInstance{"default"};
    if (providedInstance != name) return nullptr;
    return Health::initInstance(&gHealthdConfig).get();
}

    # device.mk
PRODUCT_PACKAGES += android.hardware.health@2.0-impl-<device>

برای جزئیات، به hardware/interfaces/health/2.0/README.md مراجعه کنید.

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

به Health Clients for Health 2.1 HAL مراجعه کنید.

SELinux تغییر می کند

HAL جدید health@2.0 شامل تغییرات SELinux زیر است:

  • Health@2.0-service را به file_contexts اضافه می کند.
  • به system_server و storaged اجازه می دهد تا از hal_health استفاده کنند.
  • به system_server ( BatteryService ) اجازه می دهد تا batteryproperties_service ( IBatteryPropertiesRegistrar ) را ثبت کند.
  • به healthd اجازه می دهد تا hal_health ارائه دهد.
  • قوانینی را حذف می کند که به system_server و storaged اجازه می دهد تا از طریق binder به healthd فراخوانی کنند.
  • قوانینی را حذف می کند که healthd اجازه می دهد batteryproperties_service ثبت کند ( IBatteryPropertiesRegistrar ).

برای دستگاه هایی با پیاده سازی خاص خود، ممکن است برخی تغییرات SELinux فروشنده ضروری باشد. مثال:

# device/<manufacturer>/<device>/sepolicy/vendor/file_contexts
/vendor/bin/hw/android\.hardware\.health@2\.0-service.<device> u:object_r:hal_health_default_exec:s0

# 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.

رابط های هسته

به رابط های هسته برای Health 2.1 HAL مراجعه کنید.

تست کردن

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

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

به اطلاعات مورد نیاز باتری مراجعه کنید.