بسته ها

با چند استثنا، بسته های رابط HIDL در hardware/interfaces یا دایرکتوری vendor/ قرار دارند. hardware/interfaces نقشه های سطح بالا را مستقیماً به فضای نام بسته android.hardware می رسانند. نسخه یک زیر شاخه زیر فضای نام بسته (نه رابط) است.

کامپایلر hidl-gen فایل های .hal را در مجموعه ای از فایل های .h و .cpp کامپایل می کند. از این فایل‌های تولید شده خودکار، یک کتابخانه مشترک ساخته می‌شود که پیاده‌سازی مشتری/سرور با آن پیوند برقرار می‌کند. فایل Android.bp که این کتابخانه مشترک را می سازد، توسط اسکریپت hardware/interfaces/update-makefiles.sh به طور خودکار تولید می شود. هر بار که یک بسته جدید به hardware/interfaces اضافه می کنید، یا فایل های .hal را به/از یک بسته موجود اضافه/حذف می کنید، باید اسکریپت را دوباره اجرا کنید تا اطمینان حاصل کنید که کتابخانه مشترک تولید شده به روز است.

به عنوان مثال، فایل نمونه IFoo.hal باید در hardware/interfaces/samples/1.0 قرار گیرد. فایل نمونه IFoo.hal یک رابط IFoo در بسته نمونه ایجاد می کند:

package android.hardware.samples@1.0;
interface IFoo {
    struct Foo {
       int64_t someValue;
       handle  myHandle;
    };

    someMethod() generates (vec<uint32_t>);
    anotherMethod(Foo foo) generates (int32_t ret);
};

فایل های تولید شده

فایل‌های تولید شده خودکار در یک بسته HIDL به یک کتابخانه مشترک با همان نام بسته مرتبط می‌شوند (برای مثال android.hardware.samples@1.0 ). کتابخانه مشترک همچنین یک هدر منفرد به نام IFoo.h را صادر می کند که می تواند توسط کلاینت ها و سرورها گنجانده شود. با استفاده از کامپایلر hidl-gen با فایل رابط IFoo.hal به عنوان ورودی، حالت binderized دارای فایل‌های تولید خودکار زیر است:

شکل 1. فایل های تولید شده توسط کامپایلر.

• IFoo.h رابط IFoo خالص را در کلاس C++ توصیف می کند. این شامل متدها و انواع تعریف شده در رابط IFoo در فایل IFoo.hal است که در صورت لزوم به انواع C++ ترجمه شده است. حاوی جزئیات مربوط به مکانیسم RPC (به عنوان مثال، HwBinder ) مورد استفاده برای اجرای این رابط نیست . فضای نام کلاس با بسته و نسخه است، به عنوان مثال، ::android::hardware::samples::IFoo::V1_0 . هم کلاینت ها و هم سرورها شامل این هدر هستند: کلاینت هایی برای فراخوانی متدها بر روی آن و سرورهایی برای پیاده سازی آن متدها.
• IHwFoo.h . فایل هدر که حاوی اعلان‌هایی برای توابعی است که انواع داده‌های مورد استفاده در رابط را سریال‌سازی می‌کنند. توسعه دهندگان هرگز نباید هدر او را مستقیماً وارد کنند (این شامل هیچ کلاسی نیست).
• BpHwFoo.h . کلاسی که از IFoo به ارث می رسد و اجرای پروکسی HwBinder (سمت کلاینت) رابط را توصیف می کند. توسعه دهندگان هرگز نباید مستقیماً به این کلاس مراجعه کنند.
• BnHwFoo.h . کلاسی که ارجاعی به پیاده سازی IFoo دارد و پیاده سازی HwBinder Stub (سمت سرور) رابط را توصیف می کند. توسعه دهندگان هرگز نباید مستقیماً به این کلاس مراجعه کنند.
• FooAll.cpp . کلاسی که شامل پیاده سازی ها برای پراکسی HwBinder و خرد HwBinder است. هنگامی که یک کلاینت یک متد واسط را فراخوانی می کند، پروکسی به طور خودکار آرگومان های کلاینت را بررسی می کند و تراکنش را به درایور هسته بایندر می فرستد، که تراکنش را به قسمت خرد در طرف دیگر تحویل می دهد (که سپس اجرای واقعی سرور را فراخوانی می کند).

ساختار فایل ها مشابه فایل های تولید شده توسط aidl-cpp است (برای جزئیات، به "حالت عبور" در نمای کلی HIDL مراجعه کنید). تنها فایلی که به صورت خودکار تولید می‌شود و مستقل از مکانیزم RPC مورد استفاده HIDL است، IFoo.h است. همه فایل های دیگر به مکانیسم HwBinder RPC مورد استفاده توسط HIDL گره خورده اند. بنابراین، پیاده سازی مشتری و سرور هرگز نباید مستقیماً به چیزی غیر از IFoo اشاره کند . برای دستیابی به این هدف، فقط IFoo.h و پیوند را در مقابل کتابخانه مشترک ایجاد شده قرار دهید.

پیوند به کتابخانه های مشترک

کلاینت یا سروری که از هر رابطی در یک بسته استفاده می کند باید کتابخانه مشترک آن بسته را در یکی از مکان های زیر (1) قرار دهد:

• در Android.mk :

  LOCAL_SHARED_LIBRARIES += android.hardware.samples@1.0

• در Android.bp :

  shared_libs: [
      /* ... */
      "android.hardware.samples@1.0",
  ],

کتابخانه‌های دیگری که ممکن است لازم باشد شامل شوند:

فضاهای نام

توابع و انواع HIDL مانند Return<T> و Void() در فضای نام ::android::hardware اعلان می شوند. فضای نام C++ یک بسته با نام بسته و نسخه تعیین می شود. به عنوان مثال، بسته mypackage با نسخه 1.2 تحت hardware/interfaces دارای ویژگی های زیر است:

• فضای نام C++ ::android::hardware::mypackage::V1_2 است
• نام کاملا واجد شرایط IMyInterface در آن بسته این است: ::android::hardware::mypackage::V1_2::IMyInterface . ( IMyInterface یک شناسه است، نه بخشی از فضای نام).
• انواع تعریف شده در فایل types.hal بسته به صورت: ::android::hardware::mypackage::V1_2::MyPackageType مشخص می شود