تطبيق الصحة 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 والاستقصاء. في init، تسجل health@2.1-service تنفيذ واجهة IHealth إلى hwservicemanager . عند ترقية الأجهزة التي تحتوي على صورة البائع Android 8.x أو 9 وإطار عمل Android 11، قد لا توفر صورة البائع خدمة health@2.1. يتم فرض التوافق مع صور البائع القديمة من خلال جدول الإهمال .

لضمان التوافق مع الإصدارات السابقة:

  1. يقوم healthd بتسجيل IHealth في hwservicemanager على الرغم من كونه برنامجًا خفيًا للنظام. تتم إضافة IHealth إلى بيان النظام، باسم المثيل "النسخ الاحتياطي".
  2. يتواصل إطار storaged مع healthd عبر hwbinder بدلاً من binder .
  3. يتم تغيير رمز إطار العمل storaged لجلب المثيل "الافتراضي" إذا كان متاحًا، ثم "النسخ الاحتياطي".
    • يستخدم كود عميل C++ المنطق المحدد في libhealthhalutils .
    • يستخدم رمز عميل Java المنطق المحدد في HealthServiceWrapper .
  4. بعد إتاحة 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 (أضيف في الإصدار الصحي 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 (أضيف في الإصدار الصحي 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 المقابلة. تتم كتابة الاختبارات لكل من المثيل الافتراضي (للتأكد من أن الجهاز ينفذ HAL بشكل صحيح) والمثيل الاحتياطي (للتأكد من استمرار healthd في العمل بشكل صحيح قبل إزالته).

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

تنص الصحة 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).
  • تأكد من الإبلاغ عن جهد البطارية بالميكروفولت (μV). يتضمن ذلك عقد sysfs التالية:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • لاحظ أن تطبيق HAL الافتراضي يقسم voltage_now على 1000 ويبلغ القيم بالميلي فولت (mV). راجع @1.0::HealthInfo .

للحصول على التفاصيل، راجع فئة مصدر طاقة Linux .