شما باید از HIDL برای توصیف تمام پرچم های ساخت استفاده شده برای کامپایل کردن چارچوب مشروط استفاده کنید. پرچم های ساخت مربوطه باید گروه بندی شده و در یک فایل .hal
قرار گیرند. استفاده از HIDL برای تعیین موارد پیکربندی شامل مزایای زیر است:
- نسخهبندی شده (برای افزودن آیتمهای پیکربندی جدید، فروشندگان/نسخههای OEM باید صراحتاً HAL را گسترش دهند)
- به خوبی مستند شده است
- کنترل دسترسی با استفاده از SELinux
- بررسی سلامت اقلام پیکربندی از طریق مجموعه تست فروشنده (بررسی محدوده، بررسی وابستگی بین اقلام و غیره)
- APIهای تولید شده خودکار در C++ و Java
پرچم های ساخت مورد استفاده فریم ورک را شناسایی کنید
با شناسایی پیکربندیهای ساخت که برای کامپایل شرطی چارچوب استفاده میشوند، شروع کنید، سپس پیکربندیهای منسوخ را کنار بگذارید تا مجموعه کوچکتر شود. به عنوان مثال، مجموعهای از پرچمهای ساخت زیر برای surfaceflinger
شناسایی میشوند:
-
TARGET_USES_HWC2
-
TARGET_BOARD_PLATFORM
-
TARGET_DISABLE_TRIPLE_BUFFERING
-
TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
-
NUM_FRAMEBUFFER_SURFACE_BUFFERS
-
TARGET_RUNNING_WITHOUT_SYNC_FRAMEWORK
-
VSYNC_EVENT_PHASE_OFFSET_NS
-
SF_VSYNC_EVENT_PHASE_OFFSET_NS
-
PRESENT_TIME_OFFSET_FROM_VSYNC_NS
-
MAX_VIRTUAL_DISPLAY_DIMENSION
یک رابط HAL ایجاد کنید
Build configs for a subsystem are accessed through a HAL interface, while interfaces for giving configuration values are grouped in the HAL package android.hardware.configstore
(currently at version 1.0). به عنوان مثال، برای ایجاد یک فایل رابط HAL برای surfaceflinger
، در hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
:
package android.hardware.configstore@1.0; interface ISurfaceFlingerConfigs { // TO-BE-FILLED-BELOW };
پس از ایجاد فایل .hal
، hardware/interfaces/update-makefiles.sh
را اجرا کنید تا فایل .hal
جدید را به فایل های Android.bp
و Android.mk
اضافه کنید.
اضافه کردن توابع برای پرچم های ساخت
برای هر پرچم ساخت، یک تابع جدید به رابط اضافه کنید. For example, in hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
:
interface ISurfaceFlingerConfigs { disableTripleBuffering() generates(OptionalBool ret); forceHwcForVirtualDisplays() generates(OptionalBool ret); enum NumBuffers: uint8_t { USE_DEFAULT = 0, TWO = 2, THREE = 3, }; numFramebufferSurfaceBuffers() generates(NumBuffers ret); runWithoutSyncFramework() generates(OptionalBool ret); vsyncEventPhaseOffsetNs generates (OptionalUInt64 ret); presentTimeOffsetFromSyncNs generates (OptionalUInt64 ret); maxVirtualDisplayDimension() generates(OptionalInt32 ret); };
هنگام اضافه کردن یک تابع:
- با نام ها مختصر باشید. Avoid converting makefile variable names into function names and keep in mind that
TARGET_
andBOARD_
prefixes are no longer necessary. - نظرات را اضافه کنید. به توسعه دهندگان کمک کنید تا هدف آیتم پیکربندی، نحوه تغییر رفتار چارچوب، مقادیر معتبر و سایر اطلاعات مرتبط را درک کنند.
انواع بازگشتی تابع می توانند Optional[Bool|String|Int32|UInt32|Int64|UInt64]
باشند. Types are defined in types.hal
in the same directory and wrap primitive values with a field that indicates if the value is specified by the HAL; اگر نه، از مقدار پیش فرض استفاده می شود.
struct OptionalString { bool specified; string value; };
در صورت لزوم، enum را تعریف کنید که بهترین نوع آیتم پیکربندی را نشان می دهد و از آن به عنوان نوع بازگشتی استفاده کنید. در مثال بالا، enum NumBuffers
برای محدود کردن تعداد مقادیر معتبر تعریف شده است. هنگام تعریف چنین انواع داده های سفارشی، یک فیلد یا یک مقدار enum (مثلا USE_DEFAULT
) اضافه کنید تا مشخص کنید که مقدار توسط HAL مشخص شده است/نیست.
اجباری نیست که یک پرچم ساخت تنها به یک تابع در HIDL تبدیل شود. دارندگان ماژول می توانند به طور متناوب پرچم های ساخت نزدیک مرتبط را در یک ساختار جمع کنند و تابعی داشته باشند که آن ساختار را برمی گرداند (این کار می تواند تعداد فراخوانی های تابع را کاهش دهد).
For example, an option for aggregating two build flags into a single struct in hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
is:
interface ISurfaceFlingerConfigs { // other functions here struct SyncConfigs { OptionalInt64 vsyncEventPhaseoffsetNs; OptionalInt64 presentTimeoffsetFromSyncNs; }; getSyncConfigs() generates (SyncConfigs ret); // other functions here };
جایگزین های یک تابع HAL منفرد
As an alternative to using a single HAL function for all build flags, the HAL interface also provides simple functions such as getBoolean(string key)
and getInteger(string key)
. جفتهای key=value
واقعی در فایلهای جداگانه ذخیره میشوند و سرویس HAL مقادیر را با خواندن/تجزیه آن فایلها ارائه میکند.
اگرچه تعریف این رویکرد آسان است، اما مزایای ارائه شده توسط HIDL (نسخه اجباری، سهولت مستندسازی، کنترل دسترسی) را شامل نمی شود و بنابراین توصیه نمی شود.
رابط های تک و چندگانه
طراحی رابط HAL برای موارد پیکربندی دو گزینه را ارائه می دهد:
- یک رابط واحد که تمام موارد پیکربندی را پوشش می دهد
- رابط های متعدد، که هر کدام مجموعه ای از آیتم های پیکربندی مرتبط را پوشش می دهند
یک رابط ساده تر است، اما با اضافه شدن موارد پیکربندی بیشتر به فایل واحد، می تواند غیرقابل نگهداری شود. علاوه بر این، کنترل دسترسی دقیق نیست، بنابراین فرآیندی که به رابط دسترسی دارد میتواند همه موارد پیکربندی را بخواند (دسترسی به مجموعه جزئی از موارد پیکربندی نمیتواند اعطا شود). از طرف دیگر، اگر دسترسی داده نشود، موارد پیکربندی قابل خواندن نیستند.
به دلیل این مشکلات، اندروید از چندین رابط با یک رابط HAL برای گروهی از آیتم های پیکربندی مرتبط استفاده می کند. به عنوان مثال، ISurfaceflingerConfigs
برای موارد پیکربندی مربوط به surfaceflinger
، و IBluetoothConfigs
برای موارد پیکربندی مرتبط با بلوتوث.
شما باید از HIDL برای توصیف تمام پرچم های ساخت استفاده شده برای کامپایل کردن چارچوب مشروط استفاده کنید. پرچم های ساخت مربوطه باید گروه بندی شده و در یک فایل .hal
قرار گیرند. استفاده از HIDL برای تعیین موارد پیکربندی شامل مزایای زیر است:
- نسخهبندی شده (برای افزودن آیتمهای پیکربندی جدید، فروشندگان/نسخههای OEM باید صراحتاً HAL را گسترش دهند)
- به خوبی مستند شده است
- کنترل دسترسی با استفاده از SELinux
- Sanity check for configuration items through the Vendor Test Suite (range check, inter-dependency check among items, etc.)
- APIهای تولید شده خودکار در C++ و Java
پرچم های ساخت مورد استفاده فریم ورک را شناسایی کنید
با شناسایی پیکربندیهای ساخت که برای کامپایل شرطی چارچوب استفاده میشوند، شروع کنید، سپس پیکربندیهای منسوخ را کنار بگذارید تا مجموعه کوچکتر شود. به عنوان مثال، مجموعهای از پرچمهای ساخت زیر برای surfaceflinger
شناسایی میشوند:
-
TARGET_USES_HWC2
-
TARGET_BOARD_PLATFORM
-
TARGET_DISABLE_TRIPLE_BUFFERING
-
TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
-
NUM_FRAMEBUFFER_SURFACE_BUFFERS
-
TARGET_RUNNING_WITHOUT_SYNC_FRAMEWORK
-
VSYNC_EVENT_PHASE_OFFSET_NS
-
SF_VSYNC_EVENT_PHASE_OFFSET_NS
-
PRESENT_TIME_OFFSET_FROM_VSYNC_NS
-
MAX_VIRTUAL_DISPLAY_DIMENSION
یک رابط HAL ایجاد کنید
پیکربندیهای ساخت برای یک زیرسیستم از طریق یک رابط HAL قابل دسترسی هستند، در حالی که رابطهای برای دادن مقادیر پیکربندی در بسته HAL android.hardware.configstore
(در حال حاضر در نسخه 1.0) گروهبندی میشوند. For example, to create a HAL interface file for surfaceflinger
, in hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
:
package android.hardware.configstore@1.0; interface ISurfaceFlingerConfigs { // TO-BE-FILLED-BELOW };
پس از ایجاد فایل .hal
، hardware/interfaces/update-makefiles.sh
را اجرا کنید تا فایل .hal
جدید را به فایل های Android.bp
و Android.mk
اضافه کنید.
اضافه کردن توابع برای پرچم های ساخت
برای هر پرچم ساخت، یک تابع جدید به رابط اضافه کنید. For example, in hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
:
interface ISurfaceFlingerConfigs { disableTripleBuffering() generates(OptionalBool ret); forceHwcForVirtualDisplays() generates(OptionalBool ret); enum NumBuffers: uint8_t { USE_DEFAULT = 0, TWO = 2, THREE = 3, }; numFramebufferSurfaceBuffers() generates(NumBuffers ret); runWithoutSyncFramework() generates(OptionalBool ret); vsyncEventPhaseOffsetNs generates (OptionalUInt64 ret); presentTimeOffsetFromSyncNs generates (OptionalUInt64 ret); maxVirtualDisplayDimension() generates(OptionalInt32 ret); };
هنگام اضافه کردن یک تابع:
- با نام ها مختصر باشید. Avoid converting makefile variable names into function names and keep in mind that
TARGET_
andBOARD_
prefixes are no longer necessary. - نظرات را اضافه کنید. به توسعه دهندگان کمک کنید تا هدف آیتم پیکربندی، نحوه تغییر رفتار چارچوب، مقادیر معتبر و سایر اطلاعات مرتبط را درک کنند.
انواع بازگشتی تابع می توانند Optional[Bool|String|Int32|UInt32|Int64|UInt64]
باشند. انواع در types.hal
در همان دایرکتوری تعریف می شوند و مقادیر اولیه را با فیلدی می پوشانند که نشان می دهد آیا مقدار توسط HAL مشخص شده است یا خیر. اگر نه، از مقدار پیش فرض استفاده می شود.
struct OptionalString { bool specified; string value; };
در صورت لزوم، enum را تعریف کنید که بهترین نوع آیتم پیکربندی را نشان می دهد و از آن به عنوان نوع بازگشتی استفاده کنید. در مثال بالا، enum NumBuffers
برای محدود کردن تعداد مقادیر معتبر تعریف شده است. هنگام تعریف چنین انواع داده های سفارشی، یک فیلد یا یک مقدار enum (مثلا USE_DEFAULT
) اضافه کنید تا مشخص کنید که مقدار توسط HAL مشخص شده است/نیست.
اجباری نیست که یک پرچم ساخت تنها به یک تابع در HIDL تبدیل شود. دارندگان ماژول می توانند به طور متناوب پرچم های ساخت نزدیک مرتبط را در یک ساختار جمع کنند و تابعی داشته باشند که آن ساختار را برمی گرداند (این کار می تواند تعداد فراخوانی های تابع را کاهش دهد).
For example, an option for aggregating two build flags into a single struct in hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
is:
interface ISurfaceFlingerConfigs { // other functions here struct SyncConfigs { OptionalInt64 vsyncEventPhaseoffsetNs; OptionalInt64 presentTimeoffsetFromSyncNs; }; getSyncConfigs() generates (SyncConfigs ret); // other functions here };
جایگزین های یک تابع HAL منفرد
به عنوان جایگزینی برای استفاده از یک تابع HAL برای همه پرچمهای ساخت، رابط HAL همچنین عملکردهای سادهای مانند getBoolean(string key)
و getInteger(string key)
را ارائه میکند. جفتهای key=value
واقعی در فایلهای جداگانه ذخیره میشوند و سرویس HAL مقادیر را با خواندن/تجزیه آن فایلها ارائه میکند.
اگرچه تعریف این رویکرد آسان است، اما مزایای ارائه شده توسط HIDL (نسخه اجباری، سهولت مستندسازی، کنترل دسترسی) را شامل نمی شود و بنابراین توصیه نمی شود.
رابط های تک و چندگانه
طراحی رابط HAL برای موارد پیکربندی دو گزینه را ارائه می دهد:
- یک رابط واحد که تمام موارد پیکربندی را پوشش می دهد
- رابط های متعدد، که هر کدام مجموعه ای از آیتم های پیکربندی مرتبط را پوشش می دهند
یک رابط ساده تر است، اما با اضافه شدن موارد پیکربندی بیشتر به فایل واحد، می تواند غیرقابل نگهداری شود. علاوه بر این، کنترل دسترسی دقیق نیست، بنابراین فرآیندی که به رابط دسترسی دارد میتواند همه موارد پیکربندی را بخواند (دسترسی به مجموعه جزئی از موارد پیکربندی نمیتواند اعطا شود). از طرف دیگر، اگر دسترسی داده نشود، موارد پیکربندی قابل خواندن نیستند.
به دلیل این مشکلات، اندروید از چندین رابط با یک رابط HAL برای گروهی از آیتم های پیکربندی مرتبط استفاده می کند. به عنوان مثال، ISurfaceflingerConfigs
برای موارد پیکربندی مربوط به surfaceflinger
، و IBluetoothConfigs
برای موارد پیکربندی مرتبط با بلوتوث.
شما باید از HIDL برای توصیف تمام پرچم های ساخت استفاده شده برای کامپایل کردن چارچوب مشروط استفاده کنید. پرچم های ساخت مربوطه باید گروه بندی شده و در یک فایل .hal
قرار گیرند. استفاده از HIDL برای تعیین موارد پیکربندی شامل مزایای زیر است:
- نسخهبندی شده (برای افزودن آیتمهای پیکربندی جدید، فروشندگان/نسخههای OEM باید صراحتاً HAL را گسترش دهند)
- به خوبی مستند شده است
- کنترل دسترسی با استفاده از SELinux
- بررسی سلامت اقلام پیکربندی از طریق مجموعه تست فروشنده (بررسی محدوده، بررسی وابستگی بین اقلام و غیره)
- APIهای تولید شده خودکار در C++ و Java
پرچم های ساخت مورد استفاده فریم ورک را شناسایی کنید
با شناسایی پیکربندیهای ساخت که برای کامپایل شرطی چارچوب استفاده میشوند، شروع کنید، سپس پیکربندیهای منسوخ را کنار بگذارید تا مجموعه کوچکتر شود. For example, the following set of build flags are identified for surfaceflinger
:
-
TARGET_USES_HWC2
-
TARGET_BOARD_PLATFORM
-
TARGET_DISABLE_TRIPLE_BUFFERING
-
TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
-
NUM_FRAMEBUFFER_SURFACE_BUFFERS
-
TARGET_RUNNING_WITHOUT_SYNC_FRAMEWORK
-
VSYNC_EVENT_PHASE_OFFSET_NS
-
SF_VSYNC_EVENT_PHASE_OFFSET_NS
-
PRESENT_TIME_OFFSET_FROM_VSYNC_NS
-
MAX_VIRTUAL_DISPLAY_DIMENSION
یک رابط HAL ایجاد کنید
پیکربندیهای ساخت برای یک زیرسیستم از طریق یک رابط HAL قابل دسترسی هستند، در حالی که رابطهای برای دادن مقادیر پیکربندی در بسته HAL android.hardware.configstore
(در حال حاضر در نسخه 1.0) گروهبندی میشوند. به عنوان مثال، برای ایجاد یک فایل رابط HAL برای surfaceflinger
، در hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
:
package android.hardware.configstore@1.0; interface ISurfaceFlingerConfigs { // TO-BE-FILLED-BELOW };
پس از ایجاد فایل .hal
، hardware/interfaces/update-makefiles.sh
را اجرا کنید تا فایل .hal
جدید را به فایل های Android.bp
و Android.mk
اضافه کنید.
اضافه کردن توابع برای پرچم های ساخت
برای هر پرچم ساخت، یک تابع جدید به رابط اضافه کنید. به عنوان مثال، در hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
:
interface ISurfaceFlingerConfigs { disableTripleBuffering() generates(OptionalBool ret); forceHwcForVirtualDisplays() generates(OptionalBool ret); enum NumBuffers: uint8_t { USE_DEFAULT = 0, TWO = 2, THREE = 3, }; numFramebufferSurfaceBuffers() generates(NumBuffers ret); runWithoutSyncFramework() generates(OptionalBool ret); vsyncEventPhaseOffsetNs generates (OptionalUInt64 ret); presentTimeOffsetFromSyncNs generates (OptionalUInt64 ret); maxVirtualDisplayDimension() generates(OptionalInt32 ret); };
هنگام اضافه کردن یک تابع:
- با نام ها مختصر باشید. از تبدیل نام متغیرهای makefile به نام توابع خودداری کنید و به خاطر داشته باشید که پیشوندهای
TARGET_
وBOARD_
دیگر ضروری نیستند. - نظرات را اضافه کنید. به توسعه دهندگان کمک کنید تا هدف آیتم پیکربندی، نحوه تغییر رفتار چارچوب، مقادیر معتبر و سایر اطلاعات مرتبط را درک کنند.
انواع بازگشتی تابع می توانند Optional[Bool|String|Int32|UInt32|Int64|UInt64]
باشند. Types are defined in types.hal
in the same directory and wrap primitive values with a field that indicates if the value is specified by the HAL; اگر نه، از مقدار پیش فرض استفاده می شود.
struct OptionalString { bool specified; string value; };
در صورت لزوم، enum را تعریف کنید که بهترین نوع آیتم پیکربندی را نشان می دهد و از آن به عنوان نوع بازگشتی استفاده کنید. در مثال بالا، enum NumBuffers
برای محدود کردن تعداد مقادیر معتبر تعریف شده است. هنگام تعریف چنین انواع داده های سفارشی، یک فیلد یا یک مقدار enum (مثلا USE_DEFAULT
) اضافه کنید تا مشخص کنید که مقدار توسط HAL مشخص شده است/نیست.
اجباری نیست که یک پرچم ساخت تنها به یک تابع در HIDL تبدیل شود. دارندگان ماژول می توانند به طور متناوب پرچم های ساخت نزدیک مرتبط را در یک ساختار جمع کنند و تابعی داشته باشند که آن ساختار را برمی گرداند (این کار می تواند تعداد فراخوانی های تابع را کاهش دهد).
به عنوان مثال، گزینه ای برای تجمیع دو پرچم ساخت در یک ساختار واحد در hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal
این است:
interface ISurfaceFlingerConfigs { // other functions here struct SyncConfigs { OptionalInt64 vsyncEventPhaseoffsetNs; OptionalInt64 presentTimeoffsetFromSyncNs; }; getSyncConfigs() generates (SyncConfigs ret); // other functions here };
جایگزین های یک تابع HAL منفرد
As an alternative to using a single HAL function for all build flags, the HAL interface also provides simple functions such as getBoolean(string key)
and getInteger(string key)
. The actual key=value
pairs are stored in separate files and the HAL service provides values by reading/parsing those files.
اگرچه تعریف این رویکرد آسان است، اما مزایای ارائه شده توسط HIDL (نسخه اجباری، سهولت مستندسازی، کنترل دسترسی) را شامل نمی شود و بنابراین توصیه نمی شود.
رابط های تک و چندگانه
طراحی رابط HAL برای موارد پیکربندی دو گزینه را ارائه می دهد:
- یک رابط واحد که تمام موارد پیکربندی را پوشش می دهد
- رابط های متعدد، که هر کدام مجموعه ای از آیتم های پیکربندی مرتبط را پوشش می دهند
یک رابط ساده تر است، اما با اضافه شدن موارد پیکربندی بیشتر به فایل واحد، می تواند غیرقابل نگهداری شود. علاوه بر این، کنترل دسترسی دقیق نیست، بنابراین فرآیندی که به رابط دسترسی دارد میتواند همه موارد پیکربندی را بخواند (دسترسی به مجموعه جزئی از موارد پیکربندی نمیتواند اعطا شود). از طرف دیگر، اگر دسترسی داده نشود، موارد پیکربندی قابل خواندن نیستند.
به دلیل این مشکلات، اندروید از چندین رابط با یک رابط HAL برای گروهی از آیتم های پیکربندی مرتبط استفاده می کند. For example, ISurfaceflingerConfigs
for surfaceflinger
-related configuration items, and IBluetoothConfigs
for Bluetooth-related configuration items.