Health 2.0 लागू करें

सभी healthd कोड को health@2.0-impl और libhealthservice में रीफ़ैक्टर किया गया है. इसके बाद, health@2.0 HAL को लागू करने के लिए उसमें बदलाव किया गया है. इन दोनों लाइब्रेरी को health@2.0-service ने स्टैटिक तौर पर लिंक किया है. इससे, यह वह काम कर सकती है जो पहले healthd करती थी. जैसे, healthd_mainloop को चलाना और पोलिंग करना. शुरू करने के दौरान, health@2.0-service, इंटरफ़ेस IHealth से hwservicemanager को लागू करने के लिए रजिस्टर करता है. Android 8.x वेंडर इमेज और Android 9 फ़्रेमवर्क वाले डिवाइसों को अपग्रेड करते समय, हो सकता है कि वेंडर इमेज से health@2.0 सेवा न मिल पाए. इसे सपोर्ट उपलब्ध न होने या रोके जाने के शेड्यूल के हिसाब से लागू किया जाता है.

इस गड़बड़ी को ठीक करने के लिए:

  1. healthd, IHealth को hwservicemanager पर रजिस्टर करता है, भले ही वह सिस्टम डेमन हो. सिस्टम मेनिफ़ेस्ट में, IHealth को जोड़ा गया. इसके उदाहरण के तौर पर, "backup" को जोड़ा गया.
  2. फ़्रेमवर्क और storaged, healthd के साथ binder के बजाय hwbinder की मदद से कम्यूनिकेट करते हैं.
  3. फ़्रेमवर्क और storaged के लिए कोड को बदला गया है, ताकि "default" उपलब्ध होने पर उसे फ़ेच किया जा सके. अगर "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 में इन दो वैल्यू को बदल सकते हैं (health@2.0-service.<device> में libhealthservice डिपेंडेंसी को छोड़कर और इस फ़ंक्शन को फिर से लागू करके).

स्टैटिक लागू करने की लाइब्रेरी

एचएएल लागू करने वाली अन्य लाइब्रेरी के मुकाबले, लागू करने वाली लाइब्रेरी health@2.0-impl एक स्टैटिक लाइब्रेरी है. इसमें health@2.0-service, चार्जर, रिकवरी, और लेगसी 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 तरीकों का इस्तेमाल करने वाले कॉल भी शामिल हैं.

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 की ज़रूरी अनुमतियां अपडेट करें.

  • रिकवरी इमेज में पासथ्रू लागू करके, रिकवरी में एचएएल लागू करें. उदाहरण:

    // 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 से जुड़े ये बदलाव शामिल हैं:

  • file_contexts में health@2.0-service जोड़ता है.
  • system_server और storaged को hal_health इस्तेमाल करने की अनुमति देता है.
  • system_server (BatteryService) को batteryproperties_service (IBatteryPropertiesRegistrar) को रजिस्टर करने की अनुमति देता है.
  • healthd को hal_health उपलब्ध कराने की अनुमति देता है.
  • ऐसे नियम हटाता है जिनकी मदद से system_server और storaged, बाइंडर की मदद से healthd में कॉल इन कर सकते हैं.
  • ऐसे नियम हटाता है जिनकी मदद से healthd, batteryproperties_service (IBatteryPropertiesRegistrar) को रजिस्टर कर सकता है.

जिन डिवाइसों पर SELinux की सुविधा पहले से मौजूद है उनके लिए, वेंडर को 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 के लिए Kernel इंटरफ़ेस देखें.

टेस्ट करना

Android 9 में, खास तौर पर health@2.0 HAL के लिए लिखे गए नए VTS टेस्ट शामिल हैं. अगर किसी डिवाइस के मेनिफ़ेस्ट में यह बताया गया है कि वह डिवाइस, health@2.0 HAL उपलब्ध कराता है, तो उसे इससे जुड़े VTS टेस्ट पास करने होंगे. डिफ़ॉल्ट इंस्टेंस और बैकअप इंस्टेंस, दोनों के लिए टेस्ट लिखे जाते हैं. इससे यह पक्का किया जाता है कि डिवाइस एचएएल को सही तरीके से लागू करता है या नहीं. इससे यह पक्का किया जा सकेगा कि healthd हटाए जाने से पहले सही तरीके से काम करता रहे.

बैटरी की जानकारी से जुड़ी ज़रूरी शर्तें

बैटरी की जानकारी से जुड़ी ज़रूरी शर्तें देखें.