في 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
إلى بيان النظام ، باسم المثيل "backup". - يتواصل الإطار
healthd
storaged
hwbinder
بدلاً منbinder
. - يتم تغيير رمز الإطار
storaged
لجلب المثيل "الافتراضي" إذا كان متاحًا ، ثم "النسخ الاحتياطي".- يستخدم كود العميل C ++ المنطق المحدد في
libhealthhalutils
. - يستخدم كود عميل Java المنطق المحدد في
HealthServiceWrapper
.
- يستخدم كود العميل C ++ المنطق المحدد في
- بعد أن يتوفر IHealth / default على نطاق واسع ويتم إهمال صور بائع Android 8.1 ، يمكن إهمال IHealth / backup و
healthd
. لمزيد من التفاصيل ، راجع Deprecating 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
code فيhealth@2.0-impl
. - الانتعاش . تم تغليف الارتباط بـ
libbatterymonitor
فيhealth@2.0-impl
. يتم استبدال جميع المكالمات إلىBatteryMonitor
بمكالمات في فئة تنفيذHealth
. مدير البطارية . كان
BatteryManager.queryProperty(int id)
هو العميل الوحيد لـIBatteryPropertiesRegistrar.getProperty
. تم توفيرIBatteryPropertiesRegistrar.getProperty
بواسطةhealthd
وقراءة/sys/class/power_supply
.لاعتبارات أمنية ، لا يُسمح للتطبيقات بالاتصال بـ Health HAL مباشرةً. في Android 9 والإصدارات الأحدث ، يتم توفير خدمة
IBatteryPropertiesRegistrar
بواسطةBatteryService
بدلاً منhealthd
. تقومBatteryService
بتفويض المكالمة إلى HAL الصحي لاسترداد المعلومات المطلوبة.BatteryService . في Android 9 والإصدارات الأحدث ، تستخدم
BatteryService
HealthServiceWrapper
لتحديد ما إذا كنت تريد استخدام مثيل الخدمة الصحية الافتراضية منvendor
أو استخدام مثيل الخدمة الصحية الاحتياطية منhealthd
. ثم تستمعBatteryService
للأحداث الصحية عبرIHealth.registerCallback
.مخزنة . في Android 9 والإصدارات الأحدث ، يستخدم
libhealthhalutils
storaged
ما إذا كان سيتم استخدام مثيل الخدمة الصحية الافتراضية من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.
واجهات Kernel
يقوم 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
(تمت إضافته في الإصدار الصحي 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 قبل إنشاء خدمة HAL 2.1 الصحية.
اختبارات
يتضمن Android 11 اختبارات VTS جديدة مكتوبة خصيصًا لـ health@2.1 HAL. إذا أعلن أحد الأجهزة عن health@2.1 HAL في بيان الجهاز ، فيجب أن يجتاز اختبارات VTS المقابلة. تتم كتابة الاختبارات لكل من المثيل الافتراضي (للتأكد من أن الجهاز ينفذ طبقة تجريد الأجهزة بشكل صحيح) ومثيل النسخة الاحتياطية (لضمان استمرار healthd
في العمل بشكل صحيح قبل إزالته).
متطلبات معلومات البطارية
ينص health 2.0 HAL على مجموعة من المتطلبات على واجهة HAL ، لكن اختبارات VTS المقابلة تكون مريحة نسبيًا عند فرضها. في Android 11 ، تمت إضافة اختبارات VTS جديدة لفرض المتطلبات التالية على الأجهزة التي تعمل بنظام Android 11 والإصدارات الأحدث:
- يجب أن تكون وحدات التيار الداخلي والمتوسط للبطارية ميكرو أمبير (μA).
- يجب أن تكون علامة تيار البطارية اللحظي والمتوسط صحيحة. خاصة:
- الحالي == 0 عندما تكون حالة البطارية غير
UNKNOWN
- الحالي> 0 عندما تكون حالة البطارية قيد
CHARGING
- الحالي <= 0 عندما تكون حالة البطارية
NOT_CHARGING
- الحالي <0 عندما تكون حالة البطارية
DISCHARGING
- لا يتم فرضه عندما تكون حالة البطارية
FULL
- الحالي == 0 عندما تكون حالة البطارية غير
- يجب أن تكون حالة البطارية صحيحة مقابل توصيل مصدر طاقة أم لا. خاصة:
- يجب أن تكون حالة البطارية
NOT_CHARGING
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 ويبلغ عن القيم بالميليفولت (بالسيارات). انظر @ 1.0 :: HealthInfo .
-
للحصول على التفاصيل ، راجع فئة مزود الطاقة في Linux .