تم إعادة تنظيم كل رمز healthd
في health@2.0-impl و
libhealthservice
، ثم تم تعديله لتطبيق health@2.0 HAL. يتم ربط هاتَين المكتبتَين بشكلٍ ثابت من خلال Health@2.0-service، ما يتيح له تنفيذ العمل الذي تم إنجازه سابقًا من خلال healthd
(أي تشغيل healthd_mainloop
وإجراء الاستطلاع). في مرحلة الإعداد، تسجِّل خدمة health@2.0 تنفيذًا لحدود IHealth
إلى hwservicemanager
. عند ترقية الأجهزة التي تعمل بنظام التشغيل
Android 8.x من صورة موفِّر البرامج وإطار عمل Android 9، قد لا توفِّر صورة الموفِّر خدمة
health@2.0. ويتم فرض ذلك
بموجب
الجدول الزمني للإيقاف النهائي.
لحل هذه المشكلة، عليك تنفيذ ما يلي:
- يسجّل
healthd
IHealth
فيhwservicemanager
(على الرغم من كونه برنامجًا خفيًا للنظام). تمت إضافةIHealth
إلى بيان النظام، مع اسم المثيل"backup"
. - يتواصل إطار العمل و
storaged
معhealthd
من خلالhwbinder
بدلاً منbinder
. - تم تغيير رمز الإطار و
storaged
لجلب العنصر"default"
إذا كان متاحًا، ثم"backup"
.- يستخدم رمز العميل بتنسيق C++ المنطق المحدَّد في
libhealthhalutils
. - يستخدم رمز Java المخصّص للعملاء المنطق المحدّد في
HealthServiceWrapper
.
- يستخدم رمز العميل بتنسيق C++ المنطق المحدَّد في
- بعد توفّر IHealth/default على نطاق واسع وإيقاف استخدام صور مورّدي Android 8.1 نهائيًا، يمكن إيقاف استخدام IHealth/backup و
healthd
نهائيًا. لمزيد من التفاصيل، يُرجى الاطّلاع على مقالة إيقاف health@1.0 نهائيًا.
متغيّرات الإنشاء الخاصة باللوحة لتطبيق healthd
BOARD_PERIODIC_CHORES_INTERVAL_*
هي متغيّرات خاصة باللوحة تُستخدَم لإنشاء
healthd
. كجزء من تقسيم الإصدارات الخاصة بالنظام/المورّد،
لا يمكن تحديد القيم الخاصة باللوحة لوحدات النظام. في Health@2.0، يمكن للمورّدين إلغاء هاتين القيمتين في healthd_mode_ops->init
(عن طريق إزالة التبعية libhealthservice
في health@2.0-service.<device>
وإعادة تنفيذ هذه الدالة).
مكتبة التنفيذ الثابت
على عكس مكتبات تنفيذ HAL الأخرى، مكتبة التنفيذ health@2.0-impl هي مكتبة ثابتة يتم ربط health@2.0-service وcharger وrecovery وhealthd القديم بها.
تُنفِّذ health@2.0.impl فئة IHealth
كما هو موضّح أعلاه، وهي مخصّصة للتغليف
حول libbatterymonitor
وlibhealthd.BOARD
. يجب ألا يستخدم
مستخدمو health@2.0-impl فئة BatteryMonitor
أو الدوالّ في
libhealthd
مباشرةً، بل يجب استبدال هذه الطلبات بطلبات إلى
فئة Health
، وهي واجهة لتنفيذIHealth
. لتبسيط الشرح،
يتم أيضًا تضمين رمز healthd_common
في health@2.0-impl. يحتوي الرمز الجديد
healthd_common
على بقية الرمز البرمجي المشترك بين health@2.0-service و
charger وhealthd
ويُجري طلبات إلى طرق IHealth بدلاً من BatteryMonitor.
تنفيذ خدمة Health 2.0
عند تنفيذ خدمة health@2.0 لجهاز، إذا كان التنفيذ التلقائي هو:
- كافية للجهاز ويمكن استخدام
android.hardware.health@2.0-service
مباشرةً غير كافٍ للجهاز، أنشئ ملف
android.hardware.health@2.0-service.(device)
القابل للتنفيذ وضمِّن ما يلي:#include <health2/service.h> int main() { return health_service_main(); }
بعد ذلك:
إذا كان خاصًا بمجلس الإدارة
libhealthd:
- موجود، رابط إليه.
- لا تتوفّر، يجب توفير عمليات تنفيذ فارغة لدالتَي
healthd_board_init
وhealthd_board_battery_update
.
إذا كانت متغيرات
BOARD_PERIODIC_CHORES_INTERVAL_*
خاصة باللوحة:- تم تحديدها، أنشئ
HealthServiceCommon.cpp
خاصًا بالجهاز (مُنسخ منhardware/interfaces/health/2.0/utils/libhealthservice
) و خصِّصه فيhealthd_mode_service_2_0_init
. - لم يتم تعريفها، ويجب ربطها بـ
libhealthservice
بشكلٍ ثابت.
- تم تحديدها، أنشئ
إذا كان الجهاز:
- يجب تنفيذ واجهات برمجة التطبيقات
getStorageInfo
وgetDiskStats
، ويجب توفير التنفيذ في دالتَيget_storage_info
وget_disk_stats
. - يجب عدم تنفيذ واجهات برمجة التطبيقات هذه، ويجب الربط بـ
libstoragehealthdefault
بشكل ثابت.
- يجب تنفيذ واجهات برمجة التطبيقات
عدِّل أذونات SELinux اللازمة.
يمكنك تنفيذ HAL في وضع الاسترداد من خلال تثبيت عملية تنفيذ للمرور إلى صورة الاسترداد. مثال:
// Android.bp cc_library_shared { name: "android.hardware.health@2.0-impl-<device>", recovery_available: true, relative_install_path: "hw", static_libs: [ "android.hardware.health@2.0-impl", "libhealthd.<device>" // Include the following or implement device-specific storage APIs "libhealthstoragedefault", ], srcs: [ "HealthImpl.cpp", ], overrides: [ "android.hardware.health@2.0-impl-default", ], }
// HealthImpl.cpp #include <health2/Health.h> #include <healthd/healthd.h> using android::hardware::health::V2_0::IHealth; using android::hardware::health::V2_0::implementation::Health; extern "C" IHealth* HIDL_FETCH_IHealth(const char* name) { const static std::string providedInstance{"default"}; if (providedInstance != name) return nullptr; return Health::initInstance(&gHealthdConfig).get(); }
# device.mk PRODUCT_PACKAGES += android.hardware.health@2.0-impl-<device>
للاطّلاع على التفاصيل، راجِع hardware/interfaces/health/2.0/README.md.
عملاء الخدمات الصحية
راجع برامج الصحة لبرنامج Health 2.1 HAL.
تغييرات SELinux
يتضمّن HAL الجديد health@2.0 تغييرات SELinux التالية:
- تضيف health@2.0-service إلى
file_contexts
. - السماح لـ
system_server
وstoraged
باستخدامhal_health
- السماح
system_server
(BatteryService
) بتسجيلbatteryproperties_service
(IBatteryPropertiesRegistrar
) - السماح
healthd
بتقديمhal_health
- تزيل القواعد التي تسمح لـ
system_server
وstoraged
بالاتصال برقمhealthd
من خلال المُحِبِّس. - تزيل القواعد التي تسمح
healthd
بتسجيلbatteryproperties_service
(IBatteryPropertiesRegistrar
).
بالنسبة إلى الأجهزة التي تستخدم أسلوب التنفيذ الخاص بها، قد يكون من الضروري إجراء بعض التغييرات على SELinux لدى المورّد. مثال:
# device/<manufacturer>/<device>/sepolicy/vendor/file_contexts
/vendor/bin/hw/android\.hardware\.health@2\.0-service.<device> u:object_r:hal_health_default_exec:s0
# 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.
واجهات النواة
يمكنك الاطّلاع على واجهات النواة في Health 2.1 HAL.
الاختبار
يتضمّن Android 9 اختبارات VTS جديدة
مكتوبة خصيصًا لـ Health@2.0 HAL. إذا كان الجهاز يعلن عن توفير واجهة برمجة التطبيقات
health@2.0 HAL في بيان الجهاز، يجب أن يجتاز اختبارات VTS المقابلة.
تتمّ كتابة الاختبارات لكلّ من المثيل التلقائي (للتأكّد من أنّ الجهاز
ينفّذ بروتوكول HAL بشكلٍ صحيح) ومثيل النسخة الاحتياطية (للتأكّد من استمرار
عمل healthd
على النحو الصحيح قبل إزالته).
متطلّبات معلومات البطارية
راجِع متطلّبات معلومات البطارية.