Android 11 में, सभी healthd
कोड को libhealthloop
और libhealth2impl
में फिर से बनाया गया है. इसके बाद, health@2.1 HAL को लागू करने के लिए उसमें बदलाव किया गया है. इन दोनों लाइब्रेरी को health@2.0-impl-2.1
से स्टैटिक तौर पर लिंक किया गया है. यह Health 2.1 के पासथ्रू लागू करने का तरीका है. स्टैटिक तौर पर लिंक की गई लाइब्रेरी, health@2.0-impl-2.1
को healthd
के जैसे काम करने में मदद करती हैं. जैसे, healthd_mainloop
को चलाना और पोलिंग करना. init में, health@2.1-service
IHealth
से hwservicemanager
तक इंटरफ़ेस के लागू होने की जानकारी रजिस्टर करता है. Android 8.x या 9 वाली वेंडर इमेज और Android 11 फ़्रेमवर्क वाले डिवाइसों को अपग्रेड करते समय, हो सकता है कि वेंडर इमेज से health@2.1 सेवा न मिले. इस्तेमाल बंद होने का शेड्यूल, वेंडर की पुरानी इमेज के साथ काम करने की सुविधा लागू करता है.
पुराने सिस्टम के साथ काम करने की सुविधा को पक्का करने के लिए:
healthd
, सिस्टम डेमन होने के बावजूदIHealth
कोhwservicemanager
पर रजिस्टर करता है.IHealth
को सिस्टम मेनिफ़ेस्ट में जोड़ा जाता है. साथ ही, इंस्टेंस का नाम "backup" होता है.- फ़्रेमवर्क और
storaged
,binder
के बजायhwbinder
के ज़रिएhealthd
से संपर्क करते हैं. - फ़्रेमवर्क और
storaged
के कोड को बदला गया है, ताकि अगर "डिफ़ॉल्ट" इंस्टेंस उपलब्ध हो, तो उसे फ़ेच किया जा सके. अगर "डिफ़ॉल्ट" इंस्टेंस उपलब्ध न हो, तो "बैकअप" इंस्टेंस फ़ेच किया जा सके.- C++ क्लाइंट कोड,
libhealthhalutils
में बताए गए लॉजिक का इस्तेमाल करता है. - Java क्लाइंट कोड,
HealthServiceWrapper
में बताए गए लॉजिक का इस्तेमाल करता है.
- C++ क्लाइंट कोड,
- IHealth/default के बड़े पैमाने पर उपलब्ध होने और Android 8.1 वेंडर इमेज के बंद होने के बाद, IHealth/backup और
healthd
को बंद किया जा सकता है. ज़्यादा जानकारी के लिए, health@1.0 को बंद किया जा रहा है लेख पढ़ें.
healthd के लिए, बोर्ड के हिसाब से बने वैरिएबल
BOARD_PERIODIC_CHORES_INTERVAL_*
, बोर्ड के हिसाब से वैरिएबल होते हैं. इनका इस्तेमाल,
healthd
बनाने के लिए किया जाता है. सिस्टम/वेंडर के हिसाब से बंटवारे के तहत, सिस्टम मॉड्यूल के लिए बोर्ड के हिसाब से वैल्यू तय नहीं की जा सकती. ये वैल्यू, अब इस्तेमाल नहीं किए जाने वाले फ़ंक्शन healthd_board_init
में बदल दी जाती थीं.
health@2.1 में, वेंडर, healthd_config
स्ट्रक्चर में इन दो बार-बार होने वाली टास्क के इंटरवल की वैल्यू को बदल सकते हैं. इसके बाद, वे इन्हें health लागू करने वाली क्लास के कंस्ट्रक्टर में पास कर सकते हैं. हेल्थ की सुविधा को लागू करने वाली क्लास को android::hardware::health::V2_1::implementation::Health
से इनहेरिट करना चाहिए.
Health 2.1 सेवा को लागू करना
Health 2.1 सेवा को लागू करने के बारे में जानकारी पाने के लिए, hardware/interfaces/health/2.1/README.md देखें.
स्वास्थ्य से जुड़े क्लाइंट
health@2.x में ये क्लाइंट हैं:
- चार्जर.
libbatterymonitor
औरhealthd_common
कोड का इस्तेमाल,health@2.0-impl
में किया गया है. - recovery.
libbatterymonitor
से लिंक कोhealth@2.0-impl
में रैप किया गया है.BatteryMonitor
के सभी कॉल कोHealth
लागू करने वाली क्लास में कॉल से बदल दिया जाता है. BatteryManager.
BatteryManager.queryProperty(int id)
,IBatteryPropertiesRegistrar.getProperty
का एकमात्र क्लाइंट था.IBatteryPropertiesRegistrar.getProperty
कोhealthd
ने उपलब्ध कराया था और इसे सीधे/sys/class/power_supply
ने पढ़ा था.सुरक्षा से जुड़ी वजहों से, ऐप्लिकेशन को सीधे तौर पर स्वास्थ्य से जुड़े एचएएल को कॉल करने की अनुमति नहीं है. Android 9 और उसके बाद के वर्शन में,
healthd
के बजायBatteryService
से बाइंडर सेवाIBatteryPropertiesRegistrar
मिलती है.BatteryService
, मांगी गई जानकारी पाने के लिए, कॉल को स्वास्थ्य से जुड़े एचएएल को सौंपता है.BatteryService. Android 9 और इसके बाद के वर्शन में,
BatteryService
यह तय करने के लिएHealthServiceWrapper
का इस्तेमाल करता है किvendor
से डिफ़ॉल्ट हेल्थ सेवा इंस्टेंस का इस्तेमाल किया जाए याhealthd
से बैकअप हेल्थ सेवा इंस्टेंस का इस्तेमाल किया जाए. इसके बाद,BatteryService
IHealth.registerCallback
की मदद से, सेहत से जुड़े इवेंट को सुनता है.Storaged. Android 9 और इसके बाद के वर्शन में,
storaged
यह तय करने के लिएlibhealthhalutils
का इस्तेमाल करता है किvendor
से डिफ़ॉल्ट हेल्थ सेवा इंस्टेंस का इस्तेमाल किया जाए याhealthd
से बैकअप हेल्थ सेवा इंस्टेंस का इस्तेमाल किया जाए. इसके बाद,storaged
IHealth.registerCallback
की मदद से, डिवाइस की परफ़ॉर्मेंस से जुड़े इवेंट को सुनता है और स्टोरेज की जानकारी हासिल करता है.
SELinux में हुए बदलाव
health@2.1 HAL में, प्लैटफ़ॉर्म में SELinux से जुड़े ये बदलाव शामिल हैं:
android.hardware.health@2.1-service
कोfile_contexts
में जोड़ता है.
जिन डिवाइसों पर SELinux की सुविधा पहले से मौजूद है उनके लिए, वेंडर को SELinux में कुछ बदलाव करने पड़ सकते हैं. उदाहरण:
# 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.
कर्नेल इंटरफ़ेस
healthd
डेमन और डिफ़ॉल्ट तौर पर लागू होने वाला android.hardware.health@2.0-impl-2.1
, बैटरी की जानकारी पाने के लिए, इन कर्नेल इंटरफ़ेस को ऐक्सेस करता है:
/sys/class/power_supply/*/capacity_level
(Health 2.1 में जोड़ा गया)/sys/class/power_supply/*/capacity
/sys/class/power_supply/*/charge_counter
/sys/class/power_supply/*/charge_full
/sys/class/power_supply/*/charge_full_design
(Health 2.1 में जोड़ा गया)/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
/sys/class/power_supply/*/cycle_count
/sys/class/power_supply/*/health
/sys/class/power_supply/*/online
/sys/class/power_supply/*/present
/sys/class/power_supply/*/status
/sys/class/power_supply/*/technology
/sys/class/power_supply/*/temp
/sys/class/power_supply/*/time_to_full_now
(Health 2.1 में जोड़ा गया)/sys/class/power_supply/*/type
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
डिवाइस के हिसाब से लागू किया गया कोई भी health HAL, libbatterymonitor
का इस्तेमाल करके डिफ़ॉल्ट रूप से इन कर्नेल इंटरफ़ेस को ऐक्सेस करता है. ऐसा तब तक होता है, जब तक कि health implementation क्लास के कन्स्ट्रक्टर में बदलाव न किया जाए.
अगर ये फ़ाइलें मौजूद नहीं हैं या healthd
या डिफ़ॉल्ट सेवा से ऐक्सेस नहीं की जा सकती हैं, तो हो सकता है कि ये ठीक से काम न करें. उदाहरण के लिए, अगर फ़ाइल किसी वेंडर के फ़ोल्डर का लिंक है और SELinux नीति के गलत कॉन्फ़िगरेशन की वजह से ऐक्सेस नहीं किया जा सकता, तो ऐसा हो सकता है. इसलिए, डिफ़ॉल्ट तरीके का इस्तेमाल करने के बावजूद, वेंडर के हिसाब से SELinux में कुछ और बदलाव करना ज़रूरी हो सकता है.
Health 2.1 में इस्तेमाल किए गए कुछ कर्नेल इंटरफ़ेस, जैसे कि /sys/class/power_supply/*/capacity_level
और /sys/class/power_supply/*/time_to_full_now
ज़रूरी नहीं हो सकते. हालांकि, हमारा सुझाव है कि Health HAL 2.1 सेवा बनाने से पहले, CL 1398913 को चुनें. इससे, कर्नेल इंटरफ़ेस के मौजूद न होने की वजह से, फ़्रेमवर्क के गलत तरीके से काम करने से बचा जा सकता है.
टेस्ट करना
Android 11 में, खास तौर पर health@2.1 HAL के लिए लिखे गए नए VTS टेस्ट शामिल हैं. अगर किसी डिवाइस के मेनिफ़ेस्ट में, डिवाइस के लिए इस्तेमाल होने वाले HAL के तौर पर, health@2.1 का एलान किया गया है, तो उसे इससे जुड़े VTS टेस्ट पास करने होंगे.
टेस्ट, डिफ़ॉल्ट इंस्टेंस (यह पक्का करने के लिए कि डिवाइस, एचएएल को सही तरीके से लागू करता है) और बैकअप इंस्टेंस, दोनों के लिए लिखे जाते हैं. इससे यह पक्का किया जा सकता है कि healthd
को हटाने से पहले, वह सही तरीके से काम करता रहे.
बैटरी की जानकारी से जुड़ी ज़रूरी शर्तें
Health 2.0 HAL, HAL इंटरफ़ेस के लिए ज़रूरी शर्तों का एक सेट बताता है. हालांकि, इससे जुड़े वीटीएस टेस्ट में इन शर्तों को लागू करने के लिए ज़्यादा ज़रूरत नहीं होती. Android 11 में, नए VTS टेस्ट जोड़े गए हैं. इनकी मदद से, Android 11 और उसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर, इन ज़रूरी शर्तों को लागू किया जाएगा:
- बैटरी के इंस्टैटन्यूअस और औसत करंट की इकाइयां माइक्रोऐंप (μA) होनी चाहिए.
- बैटरी के मौजूदा और औसत करंट का साइन सही होना चाहिए.
खास तौर पर:
- बैटरी की स्थिति
UNKNOWN
होने पर, current == 0 - बैटरी की स्थिति
CHARGING
होने पर, current > 0 - बैटरी की स्थिति
NOT_CHARGING
होने पर, current <= 0 - बैटरी की स्थिति
DISCHARGING
होने पर, current < 0 - बैटरी की स्थिति
FULL
होने पर, यह सेटिंग लागू नहीं होती
- बैटरी की स्थिति
- बैटरी की स्थिति सही होनी चाहिए, भले ही पावर सोर्स कनेक्ट हो या नहीं. खास तौर पर:
- बैटरी की स्थिति,
CHARGING
,NOT_CHARGING
याFULL
में से कोई एक होनी चाहिए. ऐसा सिर्फ़ तब किया जाना चाहिए, जब डिवाइस को पावर सोर्स से कनेक्ट किया गया हो; - बैटरी का स्टेटस
DISCHARGING
सिर्फ़ तब होना चाहिए, जब पावर सोर्स डिसकनेक्ट हो.
- बैटरी की स्थिति,
अगर आपने libbatterymonitor
का इस्तेमाल किया है और कर्नेल इंटरफ़ेस से वैल्यू भेजी हैं, तो पक्का करें कि sysfs नोड सही वैल्यू दिखा रहे हों:
- पक्का करें कि बैटरी के करंट की जानकारी, सही साइन और यूनिट के साथ दी गई हो. इसमें ये sysfs नोड शामिल हैं:
/sys/class/power_supply/*/current_avg
/sys/class/power_supply/*/current_max
/sys/class/power_supply/*/current_now
- पॉज़िटिव वैल्यू से पता चलता है कि बैटरी में कितनी करंट आ रही है.
- वैल्यू माइक्रोऐंप (μA) में होनी चाहिए.
- पक्का करें कि बैटरी वोल्टेज को माइक्रोवॉल्ट (μV) में रिपोर्ट किया गया हो. इसमें ये sysfs नोड शामिल हैं:
/sys/class/power_supply/*/voltage_max
/sys/class/power_supply/*/voltage_now
- ध्यान दें कि डिफ़ॉल्ट एचएएल लागू करने पर,
voltage_now
को 1,000 से divide किया जाता है और वैल्यू को मिलीवोल्ट (mV) में रिपोर्ट किया जाता है. @1.0::HealthInfo देखें.
ज़्यादा जानकारी के लिए, Linux पावर सप्लाई क्लास देखें.