في 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. يتم فرض التوافق مع صور البائع القديمة من خلال جدول الإهمال .
لضمان التوافق مع الإصدارات السابقة:
- يقوم
healthd
بتسجيلIHealth
فيhwservicemanager
على الرغم من كونه برنامجًا خفيًا للنظام. تتم إضافةIHealth
إلى بيان النظام، باسم المثيل "النسخ الاحتياطي". - يتواصل إطار العمل
storaged
معhealthd
من خلالhwbinder
بدلاً منbinder
. - يتم تغيير رمز إطار العمل
storaged
لجلب المثيل "الافتراضي" إذا كان متاحًا، ثم "النسخ الاحتياطي".- يستخدم كود عميل C++ المنطق المحدد في
libhealthhalutils
. - يستخدم رمز عميل Java المنطق المحدد في
HealthServiceWrapper
.
- يستخدم كود عميل C++ المنطق المحدد في
- بعد إتاحة 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
.
تنفيذ خدمة الصحة 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 الصحي مباشرة. في نظام التشغيل Android 9 والإصدارات الأحدث، يتم توفير خدمة الموثق
IBatteryPropertiesRegistrar
بواسطةBatteryService
بدلاً منhealthd
. يقومBatteryService
بتفويض الاتصال إلى HAL الصحي لاسترداد المعلومات المطلوبة.خدمة البطارية. في 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
بالوصول إلى واجهات kernel التالية لاسترداد معلومات البطارية:
-
/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 الإضافية الخاصة بالمورد ضرورية على الرغم من استخدام التنفيذ الافتراضي.
قد تكون بعض واجهات kernel المستخدمة في Health 2.1، مثل /sys/class/power_supply/*/capacity_level
و /sys/class/power_supply/*/time_to_full_now
اختيارية. ومع ذلك، لمنع سلوكيات إطار العمل غير الصحيحة الناتجة عن فقدان واجهات kernel، فمن المستحسن اختيار 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).
-
- تأكد من الإبلاغ عن جهد البطارية بالميكروفولت (μV). يتضمن ذلك عقد sysfs التالية:
-
/sys/class/power_supply/*/voltage_max
-
/sys/class/power_supply/*/voltage_now
- لاحظ أن تطبيق HAL الافتراضي يقسم
voltage_now
على 1000 ويبلغ القيم بالميلي فولت (mV). راجع @1.0::HealthInfo .
-
للحصول على التفاصيل، راجع فئة مصدر طاقة Linux .