تنفيذ Health 2.1

في Android 11، تم إعادة تصميم جميع الرموز البرمجية healthd في libhealthloop وlibhealth2impl، ثم تم تعديلها لتنفيذ HAL الخاص بإصدار 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 مع healthd من خلال hwbinder بدلاً من binder.
  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 قبل تمريرها إلى الدالة الإنشائية لفئة تنفيذ الصحة. يجب أن ترث فئة تنفيذ الصحة من android::hardware::health::V2_1::implementation::Health.

تنفيذ خدمة Health 2.1

للحصول على معلومات حول تنفيذ خدمة Health 2.1، يُرجى الاطّلاع على hardware/interfaces/health/2.1/README.md.

عملاء الصحة

يتضمّن health@2.x العملاء التاليين:

  • charger. يتم تضمين استخدام الرمزين 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 مباشرةً.

    ولأسباب أمنية، لا يُسمح للتطبيقات بالوصول إلى طبقة تجريد الأجهزة (HAL) الخاصة بالصحة بشكل مباشر. في الإصدار 9 من نظام التشغيل Android والإصدارات الأحدث، تقدّم BatteryService خدمة IBatteryPropertiesRegistrar المستندة إلى Binder بدلاً من healthd. تفوّض BatteryService مهمة معالجة الطلب إلى طبقة تجريد الأجهزة (HAL) الخاصة بالصحة لاسترداد المعلومات المطلوبة.

  • BatteryService. في الإصدار 9 والإصدارات الأحدث من نظام التشغيل Android، تستخدم BatteryService HealthServiceWrapper لتحديد ما إذا كان سيتم استخدام نسخة خدمة الصحة الافتراضية من vendor أو نسخة خدمة الصحة الاحتياطية من healthd. يستمع BatteryService بعد ذلك إلى أحداث الصحة من خلال IHealth.registerCallback.

  • Storaged. في الإصدار 9 والإصدارات الأحدث من نظام التشغيل Android، تستخدم storaged libhealthhalutils لتحديد ما إذا كان سيتم استخدام نسخة خدمة الصحة الافتراضية من vendor أو نسخة خدمة الصحة الاحتياطية من healthd. storaged ثم يستمع إلى أحداث الصحة من خلال IHealth.registerCallback ويسترد معلومات التخزين.

تغييرات SELinux

يتضمّن إطار عمل HAL للإصدار 2.1 من health التغييرات التالية في 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 (تمت إضافته في 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

يتم تلقائيًا الوصول إلى واجهات النواة هذه من خلال أي عملية تنفيذ لواجهة HAL الخاصة بالصحة والمحدّدة للجهاز والتي تستخدم libbatterymonitor، ما لم يتم إلغاؤها في أداة إنشاء فئة تنفيذ الصحة.

إذا كانت هذه الملفات مفقودة أو تعذّر الوصول إليها من healthd أو من الخدمة التلقائية (على سبيل المثال، إذا كان الملف عبارة عن رابط رمزي إلى مجلد خاص بمورّد يرفض الوصول إليه بسبب سياسة SELinux التي تم إعدادها بشكل غير صحيح)، قد لا تعمل بشكل صحيح. لذلك، قد تكون هناك حاجة إلى إجراء تغييرات إضافية خاصة بالمورّد على SELinux حتى في حال استخدام عملية التنفيذ التلقائية.

قد تكون بعض واجهات النواة المستخدَمة في الإصدار 2.1 من Health، مثل /sys/class/power_supply/*/capacity_level و /sys/class/power_supply/*/time_to_full_now، اختيارية. ومع ذلك، لمنع حدوث سلوكيات غير صحيحة في إطار العمل نتيجة عدم توفّر واجهات نواة، يُنصح بالاختيار الدقيق CL 1398913 قبل إنشاء خدمة Health HAL 2.1.

الاختبار

يتضمّن نظام التشغيل Android 11 اختبارات VTS مكتوبة خصيصًا لواجهة HAL الخاصة بـ health@2.1. إذا كان الجهاز يعرّف health@2.1 HAL في بيان الجهاز، يجب أن يجتاز اختبارات VTS ذات الصلة. تتم كتابة الاختبارات لكل من مثيل HAL التلقائي (لضمان تنفيذ الجهاز لطبقة HAL بشكل صحيح) والمثيل الاحتياطي (لضمان استمرار عمل healthd بشكل صحيح قبل إزالته).

متطلبات معلومات البطارية

تحدّد طبقة تجريد الأجهزة (HAL) 2.0 Health مجموعة من المتطلبات على واجهة HAL، ولكن اختبارات VTS المقابلة تكون متساهلة نسبيًا في فرضها. في Android 11، تتم إضافة اختبارات جديدة في VTS لفرض المتطلبات التالية على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث:

  • يجب أن تكون وحدات تيار البطارية اللحظي والمتوسط هي ميكرو أمبير (μA).
  • يجب أن تكون إشارة تيار البطارية اللحظي والمتوسط صحيحة. على وجه التحديد:
    • تكون القيمة الحالية 0 عندما تكون حالة البطارية UNKNOWN
    • current > 0 عندما تكون حالة البطارية CHARGING
    • current <= 0 عندما تكون حالة البطارية NOT_CHARGING
    • current < 0 عندما تكون حالة البطارية DISCHARGING
    • لا يتم فرضها عندما تكون حالة البطارية 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.