في 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. الرجوع
التوافق مع صور البائع القديمة من قِبل
الجدول الزمني للإيقاف النهائي.
لضمان التوافق مع الأنظمة القديمة:
- يسجّل
healthd
IHealth
فيhwservicemanager
على الرغم من أنه نظام برنامج خفي. تمت إضافةIHealth
إلى بيان النظام، باسم المثيل "احتياطية". - يتواصل إطار العمل و
storaged
مع "healthd
" من خلال "hwbinder
". بدلاً منbinder
. - تم تغيير رمز إطار العمل و
storaged
لاسترجاع المثيل. "تلقائي" إذا كانت متاحة، ثم "نسخة احتياطية".- يستخدم رمز عميل C++ المنطق المحدّد في
libhealthhalutils
. - يستخدم رمز عميل Java المنطق المحدّد في
HealthServiceWrapper
.
- يستخدم رمز عميل C++ المنطق المحدّد في
- بعد توفُّر تطبيق 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
.
- القيمة الحالية == 0 عندما تكون حالة البطارية
- يجب أن تكون حالة البطارية صحيحة مقابل ما إذا كان مصدر الطاقة
متصلين. وعلى وجه التحديد:
- يجب أن تكون حالة البطارية إحدى القيم التالية:
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