सभी 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 सेवा न मिल पाए. इसे सपोर्ट उपलब्ध न होने या रोके जाने के शेड्यूल के हिसाब से लागू किया जाता है.
इस गड़बड़ी को ठीक करने के लिए:
healthd
,IHealth
कोhwservicemanager
पर रजिस्टर करता है, भले ही वह सिस्टम डेमन हो. सिस्टम मेनिफ़ेस्ट में,IHealth
को जोड़ा गया. इसके उदाहरण के तौर पर,"backup"
को जोड़ा गया.- फ़्रेमवर्क और
storaged
,healthd
के साथbinder
के बजायhwbinder
की मदद से कम्यूनिकेट करते हैं. - फ़्रेमवर्क और
storaged
के लिए कोड को बदला गया है, ताकि"default"
उपलब्ध होने पर उसे फ़ेच किया जा सके. अगर"default"
उपलब्ध नहीं है, तो"backup"
को फ़ेच किया जाएगा.- C++ क्लाइंट कोड,
libhealthhalutils
में बताए गए लॉजिक का इस्तेमाल करता है. - Java क्लाइंट कोड,
HealthServiceWrapper
में बताए गए लॉजिक का इस्तेमाल करता है.
- C++ क्लाइंट कोड,
- 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
हटाए जाने से पहले सही तरीके से काम करता रहे.
बैटरी की जानकारी से जुड़ी ज़रूरी शर्तें
बैटरी की जानकारी से जुड़ी ज़रूरी शर्तें देखें.