Health 2.1 लागू करना

Android 11 में, सभी healthd कोड को libhealthloop और libhealth2impl में रीफ़ैक्टर किया गया है. इसके बाद, [email protected] एचएएल को लागू करने के लिए इसमें बदलाव किया गया है. ये दोनों लाइब्रेरी, Health 2.1 के पासथ्रू इम्प्लीमेंटेशन [email protected] के ज़रिए स्टैटिक तौर पर लिंक की जाती हैं. स्टैटिक तौर पर लिंक की गई लाइब्रेरी, [email protected] को healthd की तरह ही काम करने की सुविधा देती हैं. जैसे, healthd_mainloop चलाना और पोलिंग करना. init में, [email protected], hwservicemanager में इंटरफ़ेस IHealth के किसी लागू करने वाले को रजिस्टर करता है. Android 8.x या 9 वर्शन वाली वेंडर इमेज और Android 11 फ़्रेमवर्क वाले डिवाइसों को अपग्रेड करते समय, हो सकता है कि वेंडर इमेज, [email protected] सेवा उपलब्ध न कराए. वेंडर की पुरानी इमेज के साथ काम करने की सुविधा, बंद होने के शेड्यूल के हिसाब से लागू की जाती है.

यह पक्का करने के लिए कि पुराने सिस्टम के साथ काम करने की सुविधा उपलब्ध हो:

1. healthd, सिस्टम डेमॉन होने के बावजूद hwservicemanager के लिए IHealth रजिस्टर करता है. IHealth को सिस्टम मेनिफ़ेस्ट में जोड़ा जाता है. इसका इंस्टेंस नाम "backup" होता है.
2. फ़्रेमवर्क और storaged, binder के बजाय hwbinder के ज़रिए healthd से कम्यूनिकेट करते हैं.
3. फ़्रेमवर्क और storaged के कोड में बदलाव किया गया है, ताकि अगर "default" इंस्टेंस उपलब्ध हो, तो उसे फ़ेच किया जा सके. अगर यह उपलब्ध नहीं है, तो "backup" इंस्टेंस को फ़ेच किया जा सके.
   • C++ क्लाइंट कोड, libhealthhalutils में तय किए गए लॉजिक का इस्तेमाल करता है.
   • Java क्लाइंट कोड, HealthServiceWrapper में तय किए गए लॉजिक का इस्तेमाल करता है.
4. IHealth/default के बड़े पैमाने पर उपलब्ध होने और Android 8.1 की वेंडर इमेज के बंद होने के बाद, IHealth/backup और healthd को बंद किया जा सकता है.

बोर्ड के हिसाब से, healthd के लिए बिल्ड वैरिएबल

BOARD_PERIODIC_CHORES_INTERVAL_* बोर्ड के हिसाब से वैरिएबल होते हैं, जिनका इस्तेमाल healthd बनाने के लिए किया जाता है. सिस्टम/वेंडर बिल्ड स्प्लिट के तहत, सिस्टम मॉड्यूल के लिए बोर्ड के हिसाब से वैल्यू तय नहीं की जा सकती हैं. इन वैल्यू को, अब इस्तेमाल नहीं किए जा सकने वाले फ़ंक्शन healthd_board_init में बदला जाता था.

[email protected] में, वेंडर इन दोनों कामों के लिए तय किए गए समय की वैल्यू को healthd_config स्ट्रक्चर में बदल सकते हैं. इसके बाद, वे इसे हेल्थ इंप्लीमेंटेशन क्लास कंस्ट्रक्टर को पास कर सकते हैं. स्वास्थ्य से जुड़ी सुविधा लागू करने वाली क्लास को android::hardware::health::V2_1::implementation::Health से इनहेरिट करना चाहिए.

Health 2.1 सेवा लागू करना

Health 2.1 सेवा को लागू करने के बारे में जानकारी के लिए, hardware/interfaces/health/2.1/README.md देखें.

स्वास्थ्य से जुड़े क्लाइंट

[email protected] के ये क्लाइंट हैं:

• चार्जर. libbatterymonitor और healthd_common कोड का इस्तेमाल [email protected] में किया जाता है.
• recovery. libbatterymonitor से लिंक करने की सुविधा, [email protected] में शामिल है. BatteryMonitor को किए गए सभी कॉल, Health लागू करने वाली क्लास को किए गए कॉल से बदल दिए जाते हैं.

• BatteryManager. BatteryManager.queryProperty(int id), IBatteryPropertiesRegistrar.getProperty का इकलौता क्लाइंट था. IBatteryPropertiesRegistrar.getProperty को healthd ने उपलब्ध कराया था और /sys/class/power_supply ने इसे सीधे तौर पर पढ़ा था.

  सुरक्षा को ध्यान में रखते हुए, ऐप्लिकेशन को सीधे तौर पर हेल्थ एचएएल को कॉल करने की अनुमति नहीं है. Android 9 और इसके बाद के वर्शन में, बाइंडर सेवा IBatteryPropertiesRegistrar को healthd के बजाय BatteryService से उपलब्ध कराया जाता है. BatteryService मांगी गई जानकारी को वापस पाने के लिए, कॉल को हेल्थ HAL को सौंपता है.

• BatteryService. Android 9 और इसके बाद के वर्शन में, BatteryService यह तय करने के लिए HealthServiceWrapper का इस्तेमाल करता है कि vendor से डिफ़ॉल्ट हेल्थ सर्विस इंस्टेंस का इस्तेमाल करना है या healthd से बैकअप हेल्थ सर्विस इंस्टेंस का इस्तेमाल करना है. BatteryService के ज़रिए, सेहत से जुड़े इवेंट के बारे में सुनता है.IHealth.registerCallback

• Storaged. Android 9 और इसके बाद के वर्शन में, storaged यह तय करने के लिए libhealthhalutils का इस्तेमाल करता है कि vendor से डिफ़ॉल्ट हेल्थ सर्विस इंस्टेंस का इस्तेमाल करना है या healthd से बैकअप हेल्थ सर्विस इंस्टेंस का इस्तेमाल करना है. storaged, IHealth.registerCallback के ज़रिए सेहत से जुड़े इवेंट की जानकारी इकट्ठा करता है. इसके बाद, वह स्टोरेज की जानकारी को वापस पाता है.

SELinux में किए गए बदलाव

[email protected] HAL में, प्लैटफ़ॉर्म में SELinux से जुड़े ये बदलाव शामिल हैं:

• [email protected] को 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 डेमॉन और डिफ़ॉल्ट तौर पर लागू किया गया [email protected], बैटरी की जानकारी पाने के लिए इन कर्नल इंटरफ़ेस को ऐक्सेस करते हैं:

• /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

डिवाइस के हिसाब से लागू किया गया कोई भी हेल्थ एचएएल, डिफ़ॉल्ट रूप से इन कर्नल इंटरफ़ेस को ऐक्सेस करता है. हालांकि, हेल्थ इंप्लीमेंटेशन क्लास कंस्ट्रक्टर में इसे बदला जा सकता है.libbatterymonitor

अगर ये फ़ाइलें मौजूद नहीं हैं या 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 में, खास तौर पर [email protected] HAL के लिए लिखे गए नए वीटीएस टेस्ट शामिल हैं. अगर कोई डिवाइस, डिवाइस मेनिफ़ेस्ट में [email protected] एचएएल के बारे में बताता है, तो उसे इससे जुड़े वीटीएस टेस्ट पास करने होंगे. टेस्ट, डिफ़ॉल्ट इंस्टेंस के साथ-साथ बैकअप इंस्टेंस के लिए भी लिखे जाते हैं. डिफ़ॉल्ट इंस्टेंस के लिए, यह पक्का करने के लिए कि डिवाइस HAL को सही तरीके से लागू करता है. बैकअप इंस्टेंस के लिए, यह पक्का करने के लिए कि healthd को हटाने से पहले, वह सही तरीके से काम करता रहे.

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

Health 2.0 HAL, HAL इंटरफ़ेस के लिए ज़रूरी शर्तों का एक सेट बताता है. हालांकि, इनसे जुड़े वीटीएस टेस्ट में इन शर्तों को लागू करने के लिए, कुछ हद तक छूट दी जाती है. Android 11 में, नए वीटीएस टेस्ट जोड़े गए हैं. इनसे 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
  • ध्यान दें कि डिफ़ॉल्ट HAL लागू करने पर, voltage_now को 1000 से भाग दिया जाता है और वैल्यू को मिलीवोल्ट (mV) में रिपोर्ट किया जाता है. @1.0::HealthInfo देखें.

ज़्यादा जानकारी के लिए, Linux पावर सप्लाई क्लास देखें.