اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
واجهات برمجة التطبيقات لأجهزة الاستشعار المتاحة ديناميكيًا
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يتيح نظام التشغيل Android 9 إيقاف أنظمة Android المكوّنة
الفرعية بشكل ديناميكي عندما لا تكون قيد الاستخدام أو غير مطلوبة. على سبيل المثال، عندما لا يستخدم أحد المستخدمين شبكة Wi-Fi، يجب ألا تستهلك الأنظمة الفرعية لشبكة Wi-Fi الذاكرة أو
الطاقة أو موارد النظام الأخرى. في الإصدارات السابقة من Android، كانت واجهات HAL أو برامج التشغيل
تظل مفتوحة على أجهزة Android طوال مدة تشغيل هاتف Android.
يتضمن تنفيذ الإيقاف الديناميكي ربط تدفقات البيانات وتنفيذ العمليات الديناميكية كما هو موضّح بالتفصيل في الأقسام التالية.
تغييرات على تعريفات HAL
يتطلّب الإيقاف الديناميكي معلومات عن العمليات التي توفّر واجهات HAL (قد تكون هذه المعلومات مفيدة أيضًا لاحقًا في سياقات أخرى)، وكذلك عدم بدء العمليات عند التشغيل وعدم إعادة تشغيلها (إلى أن تتم الإعادة
مرة أخرى) عند الخروج.
# some init.rc script associated with the HAL
service vendor.some-service-name /vendor/bin/hw/some-binary-service
# init language extension, provides information of what service is served
# if multiple interfaces are served, they can be specified one on each line
interface android.hardware.light@2.0::ILight default
# restarted if hwservicemanager dies
# would also cause the hal to start early during boot if disabled wasn't set
class hal
# will not be restarted if it exits until it is requested to be restarted
oneshot
# will only be started when requested
disabled
# ... other properties
التغييرات على init وhwservicemanager
يتطلّب الإيقاف الديناميكي أيضًا أن يطلب hwservicemanager
من
init
بدء الخدمات المطلوبة. في Android 9، يحتوي init
على ثلاث رسائل تحكّم إضافية (مثل ctl.start
): ctl.interface_start
وctl.interface_stop
وctl.interface_restart
.
يمكن استخدام هذه الرسائل للإشارة إلى init
لعرض
واجهات أجهزة معيّنة وإخفائها. عند طلب خدمة غير
مسجَّلة، يطلب hwservicemanager
بدء الخدمة. ومع ذلك، لا تتطلّب واجهات HAL الديناميكية استخدام أيٍّ من هذه العناصر.
تحديد وقت خروج HAL
في Android 9، يجب تحديد مخرج HAL يدويًا. بالنسبة إلى Android 10 والإصدارات الأحدث، يمكن أيضًا تحديده باستخدام
مراحل الحياة التلقائية.
يتطلب الإيقاف الديناميكي سياسات متعدّدة لتحديد وقت بدء
HAL ووقت إيقاف HAL. إذا قرّر HAL الخروج لأي سبب،
ستتم إعادة تشغيله تلقائيًا عند الحاجة إليه مرة أخرى باستخدام المعلومات
المقدَّمة في تعريف HAL والبنية الأساسية المقدَّمة من خلال التغييرات على
init
وhwservicemanager
. ويمكن أن يشمل ذلك
استراتيجيتَين مختلفتَين، وهما:
- يمكن أن يختار HAL طلب الخروج من نفسه إذا طلب أحد المستخدمين واجهة برمجة تطبيقات مشابهة أو
قريبة منه. يجب تحديد هذا السلوك في واجهة HAL
المقابلة.
- يمكن إيقاف وحدات HAL عند اكتمال مهمتها (موثَّقة في ملف HAL
).
مراحل النشاط التلقائية
يضيف نظام التشغيل Android 10 المزيد من التوافق مع kernel و
hwservicemanager
، ما يسمح لواجهات HAL بالإيقاف التلقائي
عندما لا يكون لديها عملاء. لاستخدام هذه الميزة، عليك تنفيذ جميع الخطوات الواردة في
التغييرات على تعريفات HAL بالإضافة إلى:
- سجِّل الخدمة في C++ باستخدام
LazyServiceRegistrar
بدلاً من الدالة العضو registerAsService
، على سبيل المثال:
// only one instance of LazyServiceRegistrar per process
LazyServiceRegistrar registrar;
registrar.registerAsService(myHidlService /* , "default" */);
- تأكَّد من أنّ برنامج HAL يحفظ إشارة إلى HAL من المستوى الأعلى (واجهة العميل المسجَّلة باستخدام
hwservicemanager
) فقط عند استخدامها. لتجنُّب حدوث تأخيرات في حال تم إسقاط هذا المرجع في سلسلة مهام hwbinder
التي تستمر في التنفيذ، يجب أن يستدعي العميل أيضًا
IPCThreadState::self()->flushCommands()
بعد إسقاط المرجع
لضمان إرسال إشعار إلى برنامج تشغيل Binder بتغييرات عدد المرجع المرتبط.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Dynamically available HALs\n\nAndroid 9 supports the dynamic shutdown of Android hardware subsystems when they are not in use or not needed. For example, when a user is not using Wi-Fi, the Wi-Fi subsystems should not be taking up memory, power, or other system resources. In earlier versions of Android, HALs/drivers were kept open on Android devices for the entire duration an Android phone was booted.\n\nImplementing dynamic shutdown involves wiring up data flows and executing\ndynamic processes as detailed in the following sections.\n\nChanges to HAL definitions\n--------------------------\n\nDynamic shutdown requires information on which processes serve what HAL\ninterfaces (this information may also be useful later in other contexts) as\nwell as not starting processes on boot and not restarting them (until\nrequested again) when they exit. \n\n```objective-c\n# some init.rc script associated with the HAL\nservice vendor.some-service-name /vendor/bin/hw/some-binary-service\n # init language extension, provides information of what service is served\n # if multiple interfaces are served, they can be specified one on each line\n interface android.hardware.light@2.0::ILight default\n # restarted if hwservicemanager dies\n # would also cause the hal to start early during boot if disabled wasn't set\n class hal\n # will not be restarted if it exits until it is requested to be restarted\n oneshot\n # will only be started when requested\n disabled\n # ... other properties\n```\n\nChanges to init and hwservicemanager\n------------------------------------\n\nDynamic shutdown also requires the `hwservicemanager` to tell\n`init` to start requested services. In Android 9,\n`init` includes three additional control messages (e.g.\n`ctl.start`): `ctl.interface_start`,\n`ctl.interface_stop`, and `ctl.interface_restart`.\nThese messages can be used to signal `init` to bring up and down\nspecific hardware interfaces. When a service is requested and isn't\nregistered, `hwservicemanager` requests that the service be\nstarted. However, dynamic HALs don't require using any of these.\n\nDetermine HAL exit\n------------------\n\nIn Android 9, HAL exit has to be manually\ndetermined. For Android 10 and higher, it can also\nbe determined with\n[automatic lifecycles](#automatic-lifecycles).\n\nDynamic shutdown requires multiple policies for deciding when to start a\nHAL and when to shutdown a HAL. If a HAL decides to exit for any reason, it\nwill automatically be restarted when it is needed again using the information\nprovided in the HAL definition and the infrastructure provided by changes to\n`init` and `hwservicemanager`. This could involve a\ncouple of different strategies, including:\n\n- A HAL could choose to call exit on itself if someone calls a close or similar API on it. This behavior must be specified in the corresponding HAL interface.\n- HALs can shut down when their task is completed (documented in the HAL file).\n\nAutomatic lifecycles\n--------------------\n\nAndroid 10 adds more support to the kernel and\n`hwservicemanager`, which allows HALs to shut down automatically\nwhenever they have no clients. To use this feature, do all of the steps in\n[Changes to HAL definitions](#changes-HAL-definitions) as well\nas:\n\n- Register the service in C++ with `LazyServiceRegistrar` instead of the member function, `registerAsService`, for example: \n\n ```scilab\n // only one instance of LazyServiceRegistrar per process\n LazyServiceRegistrar registrar;\n registrar.registerAsService(myHidlService /* , \"default\" */);\n ```\n- Verify that the HAL client keeps a reference to the top-level HAL (the interface registered with `hwservicemanager`) only when it's in use. To avoid delays if this reference is dropped on a hwbinder thread that continues to execute, the client should also call `IPCThreadState::self()-\u003eflushCommands()` after dropping the reference to ensure that the binder driver is notified of the associated reference count changes."]]