تنفيذ 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 مع 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 قبل تمريرها إلى الدالة الإنشائية لفئة تنفيذ Health. يجب أن ترث فئة تنفيذ الصحة من 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 (تمت إضافته في الإصدار 2.1 من تطبيق "صحّة Google")
• /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 من تطبيق "صحّة Google")
• /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 من تطبيق "صحّة Google")
• /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 الخاصة بالصحة مجموعة من المتطلبات في واجهة HAL، ولكن اختبارات VTS المقابلة تتساهل نسبيًا في فرض هذه المتطلبات. في Android 11، تتم إضافة اختبارات جديدة في VTS لفرض المتطلبات التالية على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث:

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