सभी healthd
कोड को health@2.0-impl और libhealthservice
में दोबारा क्रियान्वित किया गया है, फिर health@2.0 HAL को लागू करने के लिए संशोधित किया गया है। ये दो पुस्तकालय स्वास्थ्य@2.0-सेवा द्वारा स्थिर रूप से जुड़े हुए हैं, जो इसे पहले healthd
द्वारा किए गए कार्य को करने में सक्षम बनाता है (अर्थात healthd_mainloop
चलाएँ और मतदान करें)। init में, health@2.0-service इंटरफ़ेस IHealth
के कार्यान्वयन को hwservicemanager
में पंजीकृत करता है। Android 8.x विक्रेता छवि और Android 9 फ़्रेमवर्क के साथ उपकरणों को अपग्रेड करते समय, विक्रेता छवि द्वारा health@2.0 सेवा प्रदान नहीं की जा सकती है। यह बहिष्करण अनुसूची द्वारा लागू किया गया है।
इस मुद्दे को हल करने के लिए:
-
healthd
IHealth
कोhwservicemanager
(सिस्टम डेमॉन होने के बावजूद) में पंजीकृत करता है।IHealth
को सिस्टम मेनिफेस्ट में जोड़ा जाता है, उदाहरण के लिए नाम "बैकअप" के साथ। - फ्रेमवर्क और
healthd
binder
के बजायstoraged
के माध्यम सेhwbinder
के साथ संवाद करते हैं। - फ्रेमवर्क और
storaged
के लिए कोड को "डिफ़ॉल्ट" उदाहरण लाने के लिए बदल दिया जाता है, यदि उपलब्ध हो, तो "बैकअप"।- C++ क्लाइंट कोड
libhealthhalutils
में परिभाषित तर्क का उपयोग करता है। - Java क्लाइंट कोड
HealthServiceWrapper
में परिभाषित तर्क का उपयोग करता है।
- C++ क्लाइंट कोड
- आईहेल्थ/डिफॉल्ट के व्यापक रूप से उपलब्ध होने और एंड्रॉइड 8.1 विक्रेता छवियों के बहिष्कृत होने के बाद,
healthd
/बैकअप और हेल्थ को बहिष्कृत किया जा सकता है। अधिक जानकारी के लिए, deprecating health@1.0 देखें।
स्वास्थ्य के लिए बोर्ड-विशिष्ट बिल्ड चर
BOARD_PERIODIC_CHORES_INTERVAL_*
healthd
निर्माण के लिए उपयोग किए जाने वाले बोर्ड-विशिष्ट चर हैं। सिस्टम/विक्रेता बिल्ड स्प्लिट के हिस्से के रूप में, सिस्टम मॉड्यूल के लिए बोर्ड-विशिष्ट मानों को परिभाषित नहीं किया जा सकता है। Health@2.0 में, विक्रेता healthd_mode_ops->init
में इन दो मानों को ओवरराइड कर सकते हैं (स्वास्थ्य@2.0-service में libhealthservice
निर्भरता को health@2.0-service.<device>
और इस फ़ंक्शन को फिर से लागू करके)।
स्थिर कार्यान्वयन पुस्तकालय
अन्य एचएएल कार्यान्वयन पुस्तकालयों के विपरीत, कार्यान्वयन पुस्तकालय स्वास्थ्य@2.0-इम्पल एक स्थिर पुस्तकालय है जिसमें स्वास्थ्य@2.0-सेवा, चार्जर, पुनर्प्राप्ति, और विरासत स्वास्थ्य लिंक है।
health@2.0.impl ऊपर वर्णित अनुसार IHealth
को लागू करता है और इसका उद्देश्य libbatterymonitor
और libhealthd. BOARD
। Health@2.0-impl के इन उपयोगकर्ताओं को बैटरी libhealthd
BatteryMonitor
कार्यों का सीधे उपयोग नहीं करना चाहिए; इसके बजाय, इन कॉलों को Health
वर्ग में कॉल के साथ प्रतिस्थापित किया जाना चाहिए, IHealth
इंटरफ़ेस का कार्यान्वयन। आगे सामान्यीकरण करने के लिए, healthd_common
कोड भी health@2.0-impl में शामिल है। नए healthd_common
में health@2.0-service, चार्जर, और healthd
के बीच शेष सामान्य कोड शामिल है और बैटरी मॉनिटर के बजाय IHealth विधियों में कॉल करता है।
स्वास्थ्य 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
API को लागू करना चाहिए,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>
विवरण के लिए, हार्डवेयर/इंटरफेस/स्वास्थ्य/2.0/README.md देखें ।
स्वास्थ्य ग्राहक
स्वास्थ्य 2.1 एचएएल के लिए स्वास्थ्य ग्राहक देखें।
SELinux परिवर्तन
नए Health@2.0 HAL में निम्नलिखित SELinux परिवर्तन शामिल हैं:
- file_contexts में
file_contexts
जोड़ता है। -
system_server
औरstoraged
कोhal_health
का उपयोग करने की अनुमति देता है। -
batteryproperties_service
(बैटरी सर्विस) कोsystem_server
(BatteryService
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.
कर्नेल इंटरफेस
स्वास्थ्य 2.1 एचएएल के लिए कर्नेल इंटरफेस देखें।
परिक्षण
Android 9 में विशेष रूप से health@2.0 HAL के लिए लिखे गए नए VTS परीक्षण शामिल हैं। यदि कोई उपकरण डिवाइस मेनिफेस्ट में health@2.0 HAL प्रदान करने की घोषणा करता है, तो उसे संबंधित VTS परीक्षण पास करना होगा। डिफ़ॉल्ट इंस्टेंस (यह सुनिश्चित करने के लिए कि डिवाइस एचएएल को सही तरीके से लागू करता है) और बैकअप इंस्टेंस (यह सुनिश्चित करने के लिए कि healthd
इसे हटाए जाने से पहले सही ढंग से काम करना जारी रखता है) दोनों के लिए टेस्ट लिखे गए हैं।
बैटरी जानकारी आवश्यकताएँ
बैटरी जानकारी आवश्यकताएँ देखें।