HAL های موجود پویا

اجرای خاموشی پویا شامل سیم کشی جریان داده و اجرای فرآیندهای پویا است که در بخش های زیر به تفصیل شرح داده شده است.

تغییرات در تعاریف 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 بگوید خدمات درخواستی را شروع کند. در اندروید 9، init شامل سه پیام کنترلی اضافی است (مانند ctl.start ): ctl.interface_start ، ctl.interface_stop و ctl.interface_restart . از این پیام ها می توان برای سیگنال init برای بالا و پایین آوردن رابط های سخت افزاری خاص استفاده کرد. هنگامی که یک سرویس درخواست می شود و ثبت نمی شود، hwservicemanager درخواست می کند که سرویس راه اندازی شود. با این حال، HAL های پویا نیازی به استفاده از هیچ یک از این موارد ندارند.

خروجی HAL را تعیین کنید

در اندروید 9، خروج HAL باید به صورت دستی تعیین شود. برای اندروید 10 و بالاتر، می‌توان آن را با چرخه‌های عمر خودکار نیز تعیین کرد.

خاموش شدن پویا به چند سیاست برای تصمیم گیری در مورد زمان شروع HAL و زمان خاموش کردن HAL نیاز دارد. اگر یک HAL به هر دلیلی تصمیم به خروج بگیرد، با استفاده از اطلاعات ارائه شده در تعریف HAL ​​و زیرساخت ارائه شده توسط تغییرات در init و hwservicemanager ، به طور خودکار در صورت نیاز دوباره راه اندازی مجدد می شود. این می تواند شامل چند استراتژی مختلف باشد، از جمله:

• یک HAL می‌تواند انتخاب کند که خروجی خود را فراخوانی کند، اگر کسی یک API نزدیک یا مشابه روی آن فراخوانی کند. این رفتار باید در رابط HAL مربوطه مشخص شود.
• HAL ها می توانند پس از اتمام کارشان خاموش شوند (مستند شده در فایل HAL).

چرخه عمر خودکار

اندروید 10 پشتیبانی بیشتری به هسته و hwservicemanager اضافه می‌کند که به HAL‌ها اجازه می‌دهد تا زمانی که هیچ کلاینت ندارند، به‌طور خودکار خاموش شوند. برای استفاده از این ویژگی، تمام مراحل موجود در تعاریف Changes to HAL و همچنین:

• برای مثال، به جای تابع عضو، registerAsService ، سرویس را در C++ با LazyServiceRegistrar ثبت کنید:

  // only one instance of LazyServiceRegistrar per process
  LazyServiceRegistrar registrar;
  registrar.registerAsService(myHidlService /* , "default" */);

• بررسی کنید که کلاینت HAL فقط زمانی که از آن استفاده می‌شود، به HAL سطح بالا (رابط ثبت‌شده در hwservicemanager ) اشاره می‌کند. برای جلوگیری از تأخیر در صورت رها شدن این مرجع بر روی یک رشته hwbinder که به اجرا ادامه می‌دهد، مشتری باید IPCThreadState::self()->flushCommands() پس از حذف مرجع فراخوانی کند تا اطمینان حاصل شود که درایور بایندر از تعداد مرجع مرتبط مطلع شده است. تغییر می کند.