स्वास्थ्य को लागू करना 2.1

एंड्रॉइड 11 में, सभी healthd कोड को libhealthloop और libhealth2impl में दोबारा तैयार किया जाता है, फिर हेल्थ@2.1 HAL को लागू करने के लिए संशोधित किया जाता है। ये दोनों लाइब्रेरी health@2.0-impl-2.1 2.1 द्वारा स्थिर रूप से जुड़ी हुई हैं, जो हेल्थ 2.1 का पासथ्रू कार्यान्वयन है। स्थिर रूप से लिंक की गई लाइब्रेरी health@2.0-impl-2.1 2.1 को healthd के समान कार्य करने में सक्षम बनाती है, जैसे कि healthd_mainloop चलाना और पोलिंग करना। Init में, health@2.1-service इंटरफ़ेस IHealth के कार्यान्वयन को hwservicemanager में पंजीकृत करता है। एंड्रॉइड 8.x या 9 विक्रेता छवि और एंड्रॉइड 11 फ्रेमवर्क के साथ उपकरणों को अपग्रेड करते समय, विक्रेता छवि हेल्थ@2.1 सेवा प्रदान नहीं कर सकती है। पुरानी विक्रेता छवियों के साथ पश्चगामी संगतता को बहिष्करण शेड्यूल द्वारा लागू किया जाता है।

पश्चगामी संगतता सुनिश्चित करने के लिए:

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

स्वास्थ्य के लिए बोर्ड-विशिष्ट बिल्ड वैरिएबल

BOARD_PERIODIC_CHORES_INTERVAL_* बोर्ड-विशिष्ट चर हैं जिनका उपयोग healthd बनाने के लिए किया जाता है। सिस्टम/विक्रेता बिल्ड स्प्लिट के भाग के रूप में, सिस्टम मॉड्यूल के लिए बोर्ड-विशिष्ट मानों को परिभाषित नहीं किया जा सकता है । इन मानों को अप्रचलित फ़ंक्शन healthd_board_init में ओवरराइड किया जाता था।

हेल्थ@2.1 में, विक्रेता स्वास्थ्य कार्यान्वयन वर्ग कंस्ट्रक्टर को पास करने से पहले healthd_config संरचना में इन दो आवधिक कार्य अंतराल मानों को ओवरराइड कर सकते हैं। स्वास्थ्य कार्यान्वयन वर्ग को android::hardware::health::V2_1::implementation::Health से प्राप्त होना चाहिए।

स्वास्थ्य 2.1 सेवा का कार्यान्वयन

स्वास्थ्य 2.1 सेवा को लागू करने की जानकारी के लिए, हार्डवेयर/इंटरफ़ेस/हेल्थ/2.1/README.md देखें।

स्वास्थ्य ग्राहक

health@2.x के निम्नलिखित ग्राहक हैं:

  • चार्जर . libbatterymonitor और healthd_common कोड का उपयोग health@2.0-impl में लपेटा गया है।
  • वसूली । libbatterymonitor का लिंक health@2.0-impl में लपेटा गया है। BatteryMonitor की सभी कॉलों को Health कार्यान्वयन वर्ग में कॉलों द्वारा प्रतिस्थापित कर दिया जाता है।

  • बैटरी प्रबंधक । BatteryManager.queryProperty(int id) IBatteryPropertiesRegistrar.getProperty का एकमात्र ग्राहक था। IBatteryPropertiesRegistrar.getProperty healthd द्वारा प्रदान किया गया था और सीधे /sys/class/power_supply पढ़ा गया था।

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

  • बैटरीसेवा । एंड्रॉइड 9 और उच्चतर में, BatteryService यह निर्धारित करने के लिए HealthServiceWrapper उपयोग करता है कि vendor से डिफ़ॉल्ट स्वास्थ्य सेवा उदाहरण का उपयोग करना है या healthd से बैकअप स्वास्थ्य सेवा उदाहरण का उपयोग करना है। इसके बाद BatteryService IHealth.registerCallback के माध्यम से स्वास्थ्य संबंधी घटनाओं को सुनता है।

  • भण्डारित । एंड्रॉइड 9 और उच्चतर में, storaged यह निर्धारित करने के लिए libhealthhalutils उपयोग करता है कि vendor से डिफ़ॉल्ट स्वास्थ्य सेवा उदाहरण का उपयोग करना है या healthd से बैकअप स्वास्थ्य सेवा उदाहरण का उपयोग करना है। storaged फिर IHealth.registerCallback के माध्यम से स्वास्थ्य घटनाओं को सुनता है और भंडारण जानकारी पुनर्प्राप्त करता है।

SELinux बदलता है

हेल्थ@2.1 एचएएल में प्लेटफ़ॉर्म में निम्नलिखित SELinux परिवर्तन शामिल हैं:

  • android.hardware.health@2.1-service को file_contexts में जोड़ता है।

अपने स्वयं के कार्यान्वयन वाले उपकरणों के लिए, कुछ विक्रेता 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 (स्वास्थ्य 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 (स्वास्थ्य 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 (स्वास्थ्य 2.1 में जोड़ा गया)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

कोई भी उपकरण-विशिष्ट स्वास्थ्य HAL कार्यान्वयन जो libbatterymonitor का उपयोग करता है, डिफ़ॉल्ट रूप से इन कर्नेल इंटरफ़ेस तक पहुँचता है, जब तक कि स्वास्थ्य कार्यान्वयन वर्ग कंस्ट्रक्टर में ओवरराइड न किया गया हो।

यदि ये फ़ाइलें गायब हैं या healthd या डिफ़ॉल्ट सेवा से पहुंच योग्य नहीं हैं (उदाहरण के लिए फ़ाइल विक्रेता-विशिष्ट फ़ोल्डर का एक सिम्लिंक है जो गलत कॉन्फ़िगर की गई SELinux नीति के कारण पहुंच से इनकार करती है), तो वे सही ढंग से काम नहीं कर सकते हैं। इसलिए, अतिरिक्त विक्रेता-विशिष्ट SELinux परिवर्तन आवश्यक हो सकते हैं, भले ही डिफ़ॉल्ट कार्यान्वयन का उपयोग किया गया हो।

स्वास्थ्य 2.1 में प्रयुक्त कुछ कर्नेल इंटरफ़ेस, जैसे /sys/class/power_supply/*/capacity_level और /sys/class/power_supply/*/time_to_full_now वैकल्पिक हो सकते हैं। हालाँकि, गुम कर्नेल इंटरफ़ेस के परिणामस्वरूप होने वाले गलत फ़्रेमवर्क व्यवहार को रोकने के लिए, स्वास्थ्य HAL 2.1 सेवा के निर्माण से पहले CL 1398913 को चेरी-पिक करने की अनुशंसा की जाती है।

परिक्षण

एंड्रॉइड 11 में विशेष रूप से हेल्थ@2.1 एचएएल के लिए लिखे गए नए वीटीएस परीक्षण शामिल हैं। यदि कोई डिवाइस डिवाइस मेनिफेस्ट में हेल्थ@2.1 एचएएल घोषित करता है, तो उसे संबंधित वीटीएस परीक्षण पास करना होगा। परीक्षण डिफ़ॉल्ट इंस्टेंस (यह सुनिश्चित करने के लिए कि डिवाइस एचएएल को सही ढंग से कार्यान्वित करता है) और बैकअप इंस्टेंस (यह सुनिश्चित करने के लिए कि हटाए जाने से पहले healthd सही ढंग से काम करता रहे) दोनों के लिए लिखे गए हैं।

बैटरी सूचना आवश्यकताएँ

स्वास्थ्य 2.0 एचएएल एचएएल इंटरफ़ेस पर आवश्यकताओं का एक सेट बताता है, लेकिन संबंधित वीटीएस परीक्षण उन्हें लागू करने में अपेक्षाकृत आराम देते हैं। एंड्रॉइड 11 में, एंड्रॉइड 11 और उच्चतर के साथ लॉन्च होने वाले उपकरणों पर निम्नलिखित आवश्यकताओं को लागू करने के लिए नए वीटीएस परीक्षण जोड़े गए हैं:

  • आंतरिक और औसत बैटरी करंट की इकाइयाँ माइक्रोएम्प्स (μA) होनी चाहिए।
  • तात्कालिक और औसत बैटरी करंट का संकेत सही होना चाहिए। विशेष रूप से:
    • करंट == 0 जब बैटरी की स्थिति UNKNOWN हो
    • जब बैटरी की स्थिति CHARGING हो तो करंट > 0
    • जब बैटरी की स्थिति NOT_CHARGING हो तो करंट <= 0
    • जब बैटरी DISCHARGING हो तो करंट <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 1000 से विभाजित करता है और मानों को मिलीवोल्ट (एमवी) में रिपोर्ट करता है। @1.0::HealthInfo देखें।

विवरण के लिए, लिनक्स बिजली आपूर्ति वर्ग देखें।