تطبيق Health 2.0

تم إعادة تنظيم كل رمز healthd في health@2.0-impl و libhealthservice، ثم تم تعديله لتطبيق health@2.0 HAL. يتم ربط هاتَين المكتبتَين بشكلٍ ثابت من خلال Health@2.0-service، ما يتيح له تنفيذ العمل الذي تم إنجازه سابقًا من خلال healthd (أي تشغيل healthd_mainloop وإجراء الاستطلاع). في مرحلة الإعداد، تسجِّل خدمة health@2.0 تنفيذًا لحدود IHealth إلى hwservicemanager. عند ترقية الأجهزة التي تعمل بنظام التشغيل Android 8.x من صورة موفِّر البرامج وإطار عمل 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/default على نطاق واسع وإيقاف استخدام صور مورّدي Android 8.1 نهائيًا، يمكن إيقاف استخدام IHealth/backup وhealthd نهائيًا. لمزيد من التفاصيل، يُرجى الاطّلاع على مقالة إيقاف 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 وcharger وrecovery و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 و charger وhealthd ويُجري طلبات إلى طرق IHealth بدلاً من BatteryMonitor.

تنفيذ خدمة 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

يتضمّن 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 بالاتصال برقم 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 على النحو الصحيح قبل إزالته).

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

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