Health 2.1 लागू करें

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 सेवा न मिले. इस्तेमाल बंद होने का शेड्यूल, वेंडर की पुरानी इमेज के साथ काम करने की सुविधा को लागू करता है.

यह पक्का करने के लिए कि पुराने सिस्टम के साथ काम किया जा सकता है:

  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 को बंद किया जा सकता है. ज़्यादा जानकारी के लिए, health@1.0 को बंद किया जा रहा है लेख पढ़ें.

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

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

Health@2.1 में, वेंडर, हेल्थ इंप्लिमेंटेशन क्लास कंस्ट्रक्टर में पास करने से पहले, healthd_config निर्देश में समय-समय पर होने वाले काम के इंटरवल की इन दो वैल्यू को बदल सकते हैं. हेल्थ की सुविधा को लागू करने वाली क्लास को 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 में किया गया है.
  • वापस पाना. libbatterymonitor से लिंक को health@2.0-impl में रैप किया गया है. BatteryMonitor के सभी कॉल को Health लागू करने वाली क्लास में कॉल से बदल दिया जाता है.

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

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

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

Health 2.0 HAL, HAL इंटरफ़ेस के लिए ज़रूरी शर्तों का एक सेट बताता है. हालांकि, इससे जुड़े वीटीएस टेस्ट में इन शर्तों को लागू करने के लिए ज़्यादा ज़रूरत नहीं होती. Android 11 में, नए वीटीएस टेस्ट जोड़े गए हैं, ताकि Android 11 और उसके बाद के वर्शन वाले डिवाइसों पर नीचे दी गई ज़रूरी शर्तें लागू की जा सकें:

  • बैटरी के इंस्टैटन्यूअस और औसत करंट की इकाइयां माइक्रोऐंप (μA) होनी चाहिए.
  • बैटरी के मौजूदा और औसत करंट का साइन सही होना चाहिए. खास तौर पर:
    • बैटरी की स्थिति UNKNOWN होने पर, current == 0
    • बैटरी की स्थिति CHARGING होने पर करंट > 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 पावर सप्लाई क्लास देखें.