تطبيق Health 2.0

تمت إعادة احتساب جميع رموز healthd في Health@2.0-impl libhealthservice، ثم تم تعديلها لتنفيذ Health@2.0 HAL. هذان الاثنان المكتبات مرتبطة بشكل ثابت باستخدام Health@2.0-service، ما يتيح لها تنفيذ الشغل الذي أنجزه healthd سابقًا (أي تشغيل healthd_mainloop وتنفيذ والاستطلاعات). في init، تسجِّل Health@2.0-service تنفيذًا من IHealth إلى hwservicemanager. عند ترقية الأجهزة باستخدام صورة المورّد للإصدار 8.x من نظام التشغيل Android وإطار عمل Android 9 قد لا يتم تقديم خدمة Health@2.0 من خلال صورة المورّد. يتم فرض ذلك بواسطة الجدول الزمني للإيقاف النهائي.

لحل هذه المشكلة، عليك تنفيذ ما يلي:

  1. يسجّل healthd IHealth في hwservicemanager (على الرغم من أنه نظام برنامج خفي). تمت إضافة IHealth إلى بيان النظام، مع اسم المثيل "backup"
  2. يتواصل إطار العمل و"storaged" مع "healthd" من خلال "hwbinder". بدلاً من binder.
  3. تم تغيير رمز إطار العمل وstoraged لاسترجاع المثيل. "default" إذا كان متاحًا، ثم "backup".
    • يستخدم رمز عميل C++ المنطق المحدّد في libhealthhalutils.
    • يستخدم رمز عميل Java المنطق المحدّد في HealthServiceWrapper.
  4. بعد توفُّر تطبيق IHealth/تلقائي على نطاق واسع، وبعدما تتم إتاحة صور المورِّدين في الإصدار 8.1 من نظام التشغيل Android متوقفة نهائيًا، ويمكن أيضًا إيقاف IHealth/backup وhealthd. لمزيد من المعلومات، لمزيد من التفاصيل، يُرجى الاطّلاع على إيقاف Health@1.0.

متغيّرات الإصدار الخاصة باللوحة من أجل الصحة

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، شاحن، واسترداد الحساب القديم، ورابط سليم قديم.

تنفِّذ 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 ويطلب منك طرق 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 بشكلٍ ثابت.
  • إذا كان الجهاز:

    • في حال تنفيذ واجهتَي برمجة التطبيقات getStorageInfo وgetDiskStats، يجب تقديم السمة التنفيذ في الدالتين get_storage_info وget_disk_stats.
    • يجب عدم تنفيذ واجهات برمجة التطبيقات هذه، يُرجى الربط بـ 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 2.1 HAL.

التغييرات على SELinux

يتضمن ملف Health@2.0 HAL الجديد التغييرات التالية في نظام SELinux:

  • لإضافة Health@2.0-service إلى file_contexts.
  • يسمح هذا الإذن لكل من system_server وstoraged باستخدام hal_health.
  • يسمح هذا الإذن لـ "system_server" (BatteryService) بالتسجيل. batteryproperties_service (IBatteryPropertiesRegistrar).
  • تسمح هذه السياسة لتطبيق healthd بتوفير hal_health.
  • إزالة القواعد التي تسمح لـ "system_server" و"storaged" بالاتصال 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.

الاختبار

يتضمّن Android 9 اختبارات VTS جديدة مكتوبة خصيصًا لـ Health@2.0 HAL. إذا أعلن أحد الأجهزة عن توفيره Health@2.0 HAL في بيان الجهاز، يجب أن تجتاز اختبارات VTS المقابلة. وتُكتب اختبارات لكلٍ من المثيل الافتراضي (للتأكد من أن الجهاز وتنفيذ HAL بشكل صحيح) والمثيل الاحتياطي (للتأكد من أن healthd يستمر في العمل بشكل صحيح قبل إزالته).

متطلبات معلومات البطارية

راجِع متطلبات معلومات البطارية.