تطبيق 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 أو Android 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 قبل الانتقال إلى الدالة الإنشائية لفئة تطبيق الصحة. يجب أن تكتسب فئة تنفيذ الصحة من 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 والإصدارات الأحدث، يستخدم BatteryService HealthServiceWrapper لتحديد ما إذا كان سيتم استخدام مثيل الخدمة الصحية التلقائي من vendor أو استخدام مثيل الخدمة الصحية الاحتياطي من healthd. ينتظر "BatteryService" بعد ذلك الاستماع إلى الأحداث الصحية من خلال "IHealth.registerCallback".

  • Storaged: في الإصدار 9 من Android والإصدارات الأحدث، يستخدم storaged libhealthhalutils لتحديد ما إذا كان سيتم استخدام مثيل الخدمة الصحية التلقائي من 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 الوصول إلى واجهات النواة التالية لاسترداد معلومات البطارية:

  • /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 يمكنه الوصول إلى واجهات kernel هذه تلقائيًا، ما لم يتم تجاوزه في أداة إنشاء فئة تنفيذ الصحة.

إذا كانت هذه الملفات غير متوفّرة أو يتعذّر الوصول إليها من 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).
  • تأكَّد من أنّ قياس الجهد الكهربائي للبطارية بوحدات ميكرو فولت. يتضمن ذلك عُقد sysfs التالية:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • يُرجى العِلم أنّ عملية تنفيذ HAL التلقائية تقسم voltage_now على 1000 وتُبلغ عن القيم بالمللي فولت (mV). راجِع @1.0::HealthInfo.

لمعرفة التفاصيل، يُرجى الاطّلاع على فئة وحدة إمداد الطاقة في Linux.