Health 2.1 लागू करना

Android 11 में, सभी healthd कोड को libhealthloop और libhealth2impl में फिर से बनाया गया है. इसके बाद, health@2.1 एचएएल को लागू करने के लिए उसमें बदलाव किया गया है. इन दोनों लाइब्रेरी को 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 सेवा न मिले. इस्तेमाल बंद होने के शेड्यूल के मुताबिक, वेंडर की पुरानी इमेज के साथ काम करने की सुविधा लागू की जाती है.

पुराने सिस्टम के साथ काम करने की सुविधा देने के लिए:

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

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

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

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

Health 2.0 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 पावर सप्लाई क्लास देखें.