تنفيذ 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 وإجراء الاستطلاعات. في مرحلة الإعداد، يسجِّل 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 نهائيًا. لمزيد من التفاصيل، يُرجى الاطّلاع على إيقاف health@1.0 نهائيًا.

متغيّرات الإنشاء الخاصة باللوحة لتطبيق 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.
  • recovery. تم تضمين الرابط المؤدّي إلى 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 بدلاً من healthd. BatteryService تفوض المكالمة إلى HAL لصحة التطبيقات لاسترداد المعلومات المطلوبة.

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

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

تغييرات SELinux

يتضمّن Health@2.1 HAL تغييرات 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 على واجهات kernel التالية ل retrieving battery information:

  • /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 تتمكّن من الوصول إلى واجهات نظام التشغيل الأساسية هذه تلقائيًا، ما لم يتم إلغاؤها في أداة إنشاء فئة health implementation.

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

قد تكون بعض واجهات نظام التشغيل الأساسية المستخدَمة في Health 2.1، مثل /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 بشكل صحيح) والمثيل الاحتياطي (لضمان استمرار عمل healthd بشكل صحيح قبل إزالته).

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

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

  • يجب أن تكون وحدات تيار البطارية الفوري والمتوسط بالميكرومللي أمبير (μA).
  • يجب أن تكون علامة التيار الفوري والمتوسط للبطارية صحيحة. على وجه التحديد:
    • current == 0 عندما تكون حالة البطارية هي UNKNOWN
    • التيار > 0 عندما تكون حالة البطارية CHARGING
    • current <= 0 عندما تكون حالة البطارية هي NOT_CHARGING
    • current < 0 عندما تكون حالة البطارية هي DISCHARGING
    • لا يتم فرضه عندما تكون حالة البطارية FULL
  • يجب أن تكون حالة البطارية صحيحة وفقًا لما إذا كان مصدر الطاقة متصلاً أم لا. على وجه التحديد:
    • يجب أن تكون حالة البطارية إحدى الحالات التالية: CHARGING أو NOT_CHARGING أو FULL في حال الاتصال بمصدر طاقة فقط
    • يجب أن تكون حالة البطارية DISCHARGING في حال عدم اتصال مصدر الطاقة بالجهاز فقط.

إذا كنت تستخدم libbatterymonitor في عملية التنفيذ وتمرير القيم من واجهات kernel، تأكَّد من أنّ عقد 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.