تنفيذ 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 لجلب مثيل "default" (تلقائي) إذا كان متاحًا، ثم "backup" (احتياطي).
   • يستخدم رمز عميل 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.
• الاسترداد يتم تضمين الرابط المؤدي إلى 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. تفويض المكالمة إلى طبقة تجريد الأجهزة (HAL) الخاصة بالصحة لاسترداد المعلومات المطلوبةBatteryService

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

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

تغييرات SELinux

يتضمّن HAL الخاص بإصدار health@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 من تطبيق "صحّة 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.

الاختبار

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

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

تحدّد طبقة تجريد الأجهزة (HAL) 2.0 الخاصة بنظام التشغيل Android مجموعة من المتطلبات على واجهة 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.