تطبيق 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. عند الترقية الأجهزة التي تعمل بالإصدار 8.x أو 9 من نظام التشغيل Android صورة البائع وإطار عمل Android 11 قد لا توفر صورة البائع خدمة Health@2.1. الرجوع التوافق مع صور البائع القديمة من قِبل الجدول الزمني للإيقاف النهائي.

لضمان التوافق مع الأنظمة القديمة:

  1. يسجّل healthd IHealth في hwservicemanager على الرغم من أنه نظام برنامج خفي. تمت إضافة IHealth إلى بيان النظام، باسم المثيل "احتياطية".
  2. يتواصل إطار العمل وstoraged مع "healthd" من خلال "hwbinder". بدلاً من binder.
  3. تم تغيير رمز إطار العمل وstoraged لاسترجاع المثيل. "تلقائي" إذا كانت متاحة، ثم "نسخة احتياطية".
    • يستخدم رمز عميل C++ المنطق المحدّد في libhealthhalutils.
    • يستخدم رمز عميل Java المنطق المحدّد في HealthServiceWrapper.
  4. بعد توفُّر تطبيق IHealth/تلقائي على نطاق واسع، وبعدما تتم إتاحة صور المورِّدين في الإصدار 8.1 من نظام التشغيل Android متوقفة نهائيًا، ويمكن أيضًا إيقاف IHealth/backup وhealthd. لمزيد من المعلومات، التفاصيل، راجع إيقاف Health@1.0

متغيّرات الإصدار الخاصة باللوحة من أجل الصحة

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
  • لاسترداد البيانات الارتباط بـ libbatterymonitor مرتبط في health@2.0-impl يتم استبدال جميع المكالمات إلى BatteryMonitor بالمكالمات في فئة تنفيذ Health.

  • البطارية: كان BatteryManager.queryProperty(int id) هو الوحيد عميل IBatteryPropertiesRegistrar.getProperty. تم تقديم "IBatteryPropertiesRegistrar.getProperty" من قِبل healthd وتمت قراءة /sys/class/power_supply مباشرةً.

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

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

  • مساحة تخزين في نظام التشغيل Android 9 والإصدارات الأحدث، يستخدم 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 بالوصول إلى واجهات النواة هذه تلقائيًا، ما لم يتم تجاوزها في صفحة منشئ فئة التنفيذ.

إذا كانت هذه الملفات مفقودة أو يتعذّر الوصول إليها من 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.

الاختبار

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

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

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

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