حالة نظام Android

يتضمّن الإصدار 9 من Android android.hardware.health HAL 2.0، وهو upgrade upgrade من الإصدار health@1.0 HAL. يتمتع HAL الجديد هذا بالمزايا التالية:

• فصل أكثر وضوحًا بين إطار العمل ورمز المورّد
• إيقاف برنامج healthd الخفي غير الضروري
• درجات أكبر من الحرية لتخصيص المورّد في تقارير ملف المرضى
• معلومات عن سلامة الجهاز أكثر من مجرد البطارية

يتضمّن نظام التشغيل Android 11 android.hardware.health HAL 2.1، وهو ترقية طفيفة للإصدار health@2.0 HAL. توفّر واجهة HAL الجديدة التالية المزايا:

• سهولة التنفيذ
• توافق أفضل مع واجهات 2.0 HAL API الحالية
• فصل الصوت العالي الطبقة بشكل أفضل في رمز الشحن خارج الوضع
• إتاحة إطار عمل أفضل للإشارة إلى حالة بطارية الجهاز

يتضمّن نظام Android 13 android.hardware.health AIDL HAL، وهي عملية تحويل من health@2.1 HAL. يتمتع HAL الجديد هذا بالمزايا التالية:

• إزالة واجهات برمجة التطبيقات المتعلّقة بالشاحن غير المستخدَمة
• إزالة StorageAttribute والحقول ذات الصلة غير المستخدَمة
• دعم الشحن في قاعدة الإرساء

المتطلبات

الأجهزة التي تعمل بالإصدارَين 9 و10 من نظام التشغيل Android

يجب أن توفّر الأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android 2.x HAL (ويجب ألا توفّر 1.0 HAL) أو AIDL HAL. بالنسبة إلى الأجهزة التي لا تعمل بنظام التشغيل Android 9 ولكنّها تخطط لتعديل صورة المورّد إلى الإصدار 3 من "جدول توافق إطار العمل المستهدَف" (تم إصداره في Android 9)، يجب إزالة عمليات تنفيذ HAL 1.0 الحالية و توفير HAL 2.x أو HAL AIDL.

يتضمّن AOSP عدة مكتبات مساعدة مصمّمة لمساعدتك في تنفيذ واجهة برمجة التطبيقات 2.0 HAL والانتقال من واجهة برمجة التطبيقات القديمة 1.0 HAL.

الأجهزة التي تعمل بالإصدارَين 11 و12 من نظام التشغيل Android

يجب أن توفّر الأجهزة التي تعمل بنظام التشغيل Android 11 واجهة برمجة التطبيقات 2.1 HAL (ويجب عدم توفير واجهة برمجة التطبيقات 1.0 أو 2.0 HAL) أو واجهة برمجة التطبيقات AIDL HAL. بالنسبة إلى الأجهزة التي لا يتم إطلاقها باستخدام Android 11 ولكن يتم التخطيط لتحديث ملف علامة التمييز الخاصة بالمطوِّر إلى الإصدار 5 من "جدول توافق إطار العمل المستهدَف" (الذي تم إصداره في Android 11)، يجب إزالة عمليات تنفيذ HAL 2.0 الحالية وتوفير HAL 2.1 أو HAL AIDL. ننصح أيضًا بتوفير حزمة HAL 2.1 على الأجهزة التي لا تعمل بنظام التشغيل Android 11 والتي لا يتم التخطيط لتحديث صورة المورّد لها.

يتضمّن AOSP عدة مكتبات مساعدة مصمّمة لمساعدتك في تنفيذ واجهة برمجة التطبيقات 2.1 لمستوى الحِزم (HAL) والانتقال من واجهة برمجة التطبيقات القديمة 1.0 لمستوى الحِزم.

الأجهزة التي تعمل بنظام التشغيل Android 13 والإصدارات الأحدث

يجب أن توفّر الأجهزة التي تعمل بالإصدار 13 من نظام التشغيل Android حزمة AIDL HAL (ويجب ألّا توفّر حزمة HIDL HAL). بالنسبة إلى الأجهزة التي لا تعمل بالإصدار 13 من نظام التشغيل Android ولكنّها مخطّط لها تحديث صورة المورّد إلى الإصدار 7 من "جدول توافق إطار العمل" المستهدف (الذي تم طرحه في الإصدار 13 من نظام التشغيل Android)، يجب إزالة عمليات تنفيذ HIDL HAL الحالية وتوفير AIDL HAL. ننصح أيضًا باستخدام حزمة AIDL HAL على الأجهزة التي لا تعمل بنظام التشغيل Android 13 والتي لا يتم التخطيط لتعديل صورة المورّد عليها.

يجب ألا توفّر الأجهزة HIDL 1.0 HAL.

يشمل AOSP العديد من مكتبات المساعدة المصممة لمساعدتك في تنفيذ اتفاقية HIDL والانتقال من HALs القديمة.

المصطلحات

• health@1.0: اختصار android.hardware.health@1.0 يشير إلى الإصدار 1.0 من HIDL HAL للصحة الذي تم إصداره في Android 8.0.
• health@2.0: اختصار android.hardware.health@2.0. يشير إلى الإصدار 2.0 من health HIDL HAL الذي تم إصداره في Android 9.
• health@2.1: اختصار android.hardware.health@2.1. يشير إلى الإصدار 2.1 من health HIDL HAL الذي تم إصداره في Android 11.
• health AIDL HAL: اختصار android.hardware.health.
  • تم طرح الإصدار 1 في Android 13.
• شاحن: ملف قابل للتنفيذ يتم تشغيله في وضع الشحن غير النشط ويعرض الصورة المتحركة لشحن الهاتف.
• recovery: ملف قابل للتنفيذ يعمل في وضع الاسترداد ويجب أن يسترجع معلومات البطارية.
• ‫healthd: برنامج خلفية قديم يعمل في Android ويسترجع معلومات متعلقة بالصحة ويقدّمها إلى إطار العمل.
• ‫storaged: برنامج تابع يعمل في نظام التشغيل Android لاسترداد معلومات مساحة التخزين وتقديمها إلى إطار العمل

تطبيق Health في Android 8.x

في الإصدار 8.x من نظام التشغيل Android، يعمل مكوّن "الصحة" على النحو الموضّح بالتفصيل في المخطّط البياني التالي:

الشكل 1: تطبيق "صحة Google" في الإصدار 8.x من نظام التشغيل Android

في هذا الرسم البياني:

• يستخدم إطار العمل مكالمة binder واحدة ومكالمة hwbinder واحدة للتواصل مع الأجهزة.
• يرتبط healthd بشكل ثابت بـ libhealthd_android وlibbatterymonitor و libbatteryservice.
• يرتبط health@1.0-impl بشكل ثابت بملف libhealthd.BOARD.

يمكن لكل لوحة تخصيص libhealthd.BOARD مختلف. يتم تحديد الشاحن وhealth@1.0-impl ورابط الاسترداد الذي سيتم استخدامه في وقت الإنشاء.

بالنسبة إلى الأوضاع الأخرى:

الشكل 2: الصحة في الإصدار 8.x من نظام التشغيل Android، مع الشحن في وضع عدم الاتصال ووضع الاسترداد

• يرتبط الشاحن بشكل ثابت بـ libhealthd.BOARD libhealthd_charger وlibbatterymonitor.
• يرتبط عنصر الاسترداد بشكل ثابت بـ libhealthd.BOARD و libbatterymonitor.

تطبيق Health في Android 9

في Android 9، يعمل مكوّن "الصحة" على النحو الموضّح بالتفصيل في المخطّط البياني التالي:

الشكل 3 تطبيق "صحة Google" في Android 9

يحاول إطار العمل استرداد خدمة Health@2.0 من hwservicemanager. وفي حال تعذّر ذلك، يتمّ استدعاء health@1.0 (في Android 8.x). يتم الاحتفاظ بمسار الرمز القديم لتكون صورة نظام Android 9 متوافقة مع صورة المورِّد الإصدار Android 8.x. لا يستردّ إطار العمل المعلومات من كلتا حِزم HAL لأنّه يمكن أن يتوفّر على الجهاز إصدار واحد فقط من الخدمة (1.0 أو 2.0).

بالنسبة إلى الأوضاع الأخرى:

الشكل 4: ميزة "الصحة" في Android 9 ووضع الشحن في وضع الإيقاف ووضع الاسترداد

تطبيق "صحة Google" في Android 11

في Android 11، يعمل مكوِّن تطبيق Health على النحو المفصّل في المخطّط البياني التالي:

[system]
    | getService()
    V
[health@2.1-service]
        | getService(stub=true)
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

في حال عدم توفّر عملية تنفيذ health 2.1، يعود النظام إلى مسار الرمز القديم كما هو موضّح في الأقسام السابقة.

بالنسبة إلى الأوضاع الأخرى:

[       charger          ]
    | getService()      |  (legacy code path)
    V                   +-------------------------------------------------+
[health@2.1-service]                                                      |
        | getService(stub=true)                                           |
        V                                                                 |
[      health@2.0-impl-2.1-<device>.so      ]                             |
        |                                  | (device-dependent linkage)   |
        V                                  V                              |
+---------Helper libs for impl--------+   [libhealthd.device]             |
| [libhealthloop (uevent, wakealarm)] |                                   |
| [libhealth2impl (IHealth impl)    ] | <---------------------------------+
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

[recovery]
        | getService() w/o hwservicemanager
        V
[      health@2.0-impl-2.1-<device>.so      ]
        |                                  | (device-dependent linkage)
        V                                  V
+---------Helper libs for impl--------+   [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl)    ] |
| [libbatterymonitor (battery)      ] |
+-------------------------------------+

اطّلِع على الرسم البياني المبسّط التالي للأوضاع المختلفة:

الشكل 5: بنية Health HAL 2.1 الأساسية

تطبيق Health في Android 13

في Android 13، تمّ طرح Health AIDL HAL. يعمل عنصر health على النحو الموضّح بالتفصيل في المخطّط البياني التالي:

الشكل 6: بنية Health AIDL HAL الأساسية

واجهة HIDL HAL 2.0

يوفّر Health@2.0 HAL نفس وظائف إطار العمل الذي يوفّره البرنامج الخفي القديم. وتوفّر أيضًا واجهات برمجة تطبيقات مشابهة لما كان يقدّمه healthd سابقًا كخدمة ربط (أي IBatteryPropertiesRegistrar).

توفّر الواجهة الرئيسية، IHealth ، الوظائف التالية:

• registerCallback، بدلاً من IBatteryPropertiesRegistrar.registerListener
• unregisterCallback، بدلاً من IBatteryPropertiesRegistrar.unregisterListener
• update، لاستبدال IBatteryPropertiesRegistrar.scheduleUpdate
• يتم استبدال IBatteryPropertiesRegistrar.getProperties بما يلي:
  • getChargeCounter
  • getCurrentNow
  • getCurrentAverage
  • getCapacity
  • getEnergyCounter
  • getChargeStatus
  • getHealthInfo

بالإضافة إلى ذلك، توفّر IHealth واجهات برمجة التطبيقات الجديدة التالية لتطبيق storaged بهدف استرداد المعلومات المتعلّقة بمساحة التخزين الخاصة بالمورّد:

• getStorageInfo
• getDiskStats

يتم عرض بنية جديدة، @2.0::HealthInfo، من خلال عمليات الاستدعاء وgetHealthInfo. يحتوي هذا العنصر على جميع معلومات سلامة الجهاز المتاحة من خلال health@2.0 HAL، بما في ذلك:

• معلومات الشحن (التيار الكهربائي المتردد/USB/الشحن اللاسلكي، والتيار الكهربي، والجهد الكهربي، وما إلى ذلك)
• معلومات البطارية (مدى توفّرها ومستوى شحن البطارية والحدّ الأقصى الحالي للجهد الكهربي والشحن والتكنولوجيا، وما إلى ذلك)
• معلومات مساحة التخزين (معلومات عن جهاز التخزين وإحصاءات القرص)

للحصول على معلومات عن تنفيذ Health 2.0، يُرجى الاطّلاع على مقالة تنفيذ Health 2.0.

واجهة HIDL HAL 2.1

يتيح Health@2.1 HAL شحن الجهاز في وضع الإيقاف ويقدّم المزيد من المعلومات حول البطارية.

توفّر الواجهة الرئيسية، IHealth، الوظائف الإضافية التالية:

• getHealthConfig: لاسترداد إعدادات HAL هذا
• getHealthInfo_2_1: ترقية إصدار بسيط إلى getHealthInfo
• ‫shouldKeepScreenOn: لتحديد ما إذا كان يجب إبقاء الشاشة مفعّلة في وضع الشاحن

بالإضافة إلى ذلك، يجب تنفيذ @2.1::IHealth لتتوافق مع @2.1::IHealthInfoCallback لدوالّ registerCallback و unregisterCallback المُكتسَبة. تعرض واجهة ردّ الاتصال الجديدة معلومات الحالة للعميل باستخدام الدالة healthInfoChanged_2_1 بدلاً من الدالة healthInfoChanged المُكتسَبة.

يتم عرض بنية جديدة، @2.1::HealthInfo، من خلال عمليات الاستدعاء و getHealthInfo_2_1. يحتوي هذا العنصر على معلومات إضافية عن سلامة الجهاز متوفّرة من خلال health@2.0 HAL، بما في ذلك:

• مستوى سعة البطارية
• وقت شحن البطارية بالكامل الآن (بالثواني)
• سعة تصميم البطارية للشحن الكامل (بالميكرو أمبير في الساعة)

اطلع على مخطط UML التالي للفئات المفيدة لتنفيذ HAL الصحي:

الشكل 7: مخطّط UML لـ Health HAL 2.1

للحصول على معلومات عن تنفيذ Health 2.1، يُرجى الاطّلاع على مقالة تنفيذ Health 2.1.

الإصدار 1 من واجهة AIDL HAL

التغييرات في واجهة برمجة التطبيقات

يتوافق الإصدار 1 من واجهة برمجة التطبيقات لـ HAL مع واجهات برمجة تطبيقات مشابهة لواجهة برمجة التطبيقات HIDL 2.1 HAL. مقارنةً بواجهة HIDL 2.1، يتم تغيير ما يلي في واجهة برمجة التطبيقات:

• لم يتم نقل واجهات برمجة التطبيقات ذات الصلة بالشاحن والمُقدَّمة في HIDL HAL 2.1 إلى AIDL HAL. بما أنّ وظيفة الشحن في وضع الإيقاف لا تتوفّر إلا في القسم /vendor، ليست هناك حاجة إلى واجهات برمجة التطبيقات في واجهة المورّد. لتنفيذ ميزة "الشحن في وضع الإيقاف" بشكلٍ صحيح، يُرجى الاطّلاع على الشاحن أدناه.
• تتم إزالة النوع StorageAttribute والحقول ذات الصلة لأنّها غير مستخدَمة.
• تمت إضافة chargerDockOnline إلى HealthInfo لإتاحة شحن الجهاز من خلال قاعدة الإرساء.

التنفيذ

اطّلِع على مخطّط UML البياني التالي للفئات المفيدة لتنفيذ HAL للصحة:

الشكل 8. مخطّط UML لـ Health AIDL HAL

للحصول على معلومات عن تنفيذ خدمة Health AIDL، يُرجى الاطّلاع على مقالة Implementing Health AIDL HAL (تنفيذ Health AIDL HAL).

الاسترداد

يتيح نظام Android 13 استخدام أداة الربط في وضع الاسترداد. يؤدي تثبيت خدمة Health AIDL في وضع الاسترداد إلى تشغيلها في هذا الوضع.

للحصول على معلومات عن تثبيت خدمة Health AIDL في وضع الاسترداد، يُرجى الاطّلاع على الخطوات التالية:

• استخدام نموذج خدمة AIDL HAL للصحة
• إنشاء تغييرات في النظام

شاحن

تم نقل وظيفة الشحن في وضع الإيقاف من /system إلى /vendor. بالنسبة إلى الأجهزة التي تعمل بنظام Android 13، إذا كانت تتيح الشحن في وضع الإيقاف، يجب أن يتيح ملف HAL الثنائي وضع الشاحن. لإجراء ذلك، يُرجى الرجوع إلى تنفيذ الشاحن.

خصائص نظام الشاحن

لم تعُد السمات ro.charger.* قابلة للقراءة من خلال الملف الثنائي charger في /vendor. إذا كان جهازك يحتوي على أي من خصائص نظام ro.charger.*، يُرجى الرجوع إلى خصائص النظام للشاحن.