HAL ইন্টারফেস তৈরি করা

ফ্রেমওয়ার্ক কন্ডিশনালি কম্পাইল করার জন্য ব্যবহৃত সব বিল্ড ফ্ল্যাগ বর্ণনা করতে আপনাকে অবশ্যই HIDL ব্যবহার করতে হবে। প্রাসঙ্গিক বিল্ড ফ্ল্যাগগুলিকে গ্রুপ করে একটি সিঙ্গেল .hal ফাইলে অন্তর্ভুক্ত করতে হবে। কনফিগারেশন আইটেম নির্দিষ্ট করার জন্য HIDL ব্যবহার করলে নিম্নলিখিত সুবিধাগুলি পাওয়া যায়:

• ভার্সন করা (নতুন কনফিগার আইটেম যোগ করতে, ভেন্ডর/OEM-কে অবশ্যই HAL এক্সটেন্ড করতে হবে)
• ভালোভাবে ডকুমেন্ট করা
• SELinux ব্যবহার করে অ্যাক্সেস কন্ট্রোল
• ভেন্ডর টেস্ট সুইট-এর মাধ্যমে কনফিগারেশন আইটেমের জন্য স্যানিটি চেক (রেঞ্জ চেক, আইটেমগুলির মধ্যে পারস্পরিক নির্ভরতা চেক ইত্যাদি)
• C++ ও Java, দু'টি ভাষাতেই অটোমেটিক জেনারেট হওয়া API

ফ্রেমওয়ার্কের মাধ্যমে ব্যবহৃত বিল্ড ফ্ল্যাগ শনাক্ত করা

কন্ডিশনাল কম্পাইল করার জন্য ব্যবহৃত বিল্ড কনফিগারেশন শনাক্ত করার মাধ্যমে শুরু করুন ফ্রেমওয়ার্ক, তারপর সেটটি ছোট করতে অপ্রয়োজনীয় কনফিগারেশন বাদ দিন। যেমন, 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)। যেমন, surfaceflinger-এর জন্য HAL ইন্টারফেস ফাইল তৈরি করতে, in hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal:

package android.hardware.configstore@1.0;

interface ISurfaceFlingerConfigs {
    // TO-BE-FILLED-BELOW
};

.hal ফাইল তৈরি করার পরে, Android.bp এবং Android.mk ফাইলে নতুন .hal ফাইল যোগ করতে hardware/interfaces/update-makefiles.sh রান করুন।

বিল্ড ফ্ল্যাগের জন্য ফাংশন যোগ করা

প্রতিটি বিল্ড ফ্ল্যাগের জন্য ইন্টারফেসে একটি নতুন ফাংশন যোগ করুন। যেমন, 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.hal-এ ধরনগুলি সংজ্ঞায়িত করা হয় এবং কোনও ফিল্ডের সাথে আদিম মানগুলি র‍্যাপ করা হয় যা নির্দেশ করে যে মানটি HAL দ্বারা নির্দিষ্ট করা হয়েছে কিনা; যদি না হয়, তাহলে ডিফল্ট মান ব্যবহার করা হয়।

struct OptionalString {
    bool specified;
    string value;
};

উপযুক্ত হলে, এমন এনুম সংজ্ঞায়িত করুন যা কনফিগারেশন আইটেমের ধরনের সবচেয়ে ভালভাবে প্রতিনিধিত্ব করে এবং সেই এনুমকে রিটার্ন টাইপ হিসেবে ব্যবহার করুন। উপরের উদাহরণে, NumBuffers enum-কে বৈধ ভ্যালুর সংখ্যা সীমিত করার জন্য সংজ্ঞায়িত করা হয়েছে। এই ধরনের কাস্টম ডেটা টাইপ নির্ধারণ করার সময়, HAL-এর মাধ্যমে ভ্যালু নির্দিষ্ট করা হয়েছে/হয়নি তা বোঝানোর জন্য একটি ফিল্ড বা enum ভ্যালু (যেমন, USE_DEFAULT) যোগ করুন।

HIDL-এ একটি বিল্ড ফ্ল্যাগকে একটি ফাংশন হতে হবে এমন কোনও বাধ্যবাধকতা নেই। মডিউল মালিকরা বিকল্প হিসেবে, খুব কাছাকাছি সম্পর্কিত বিল্ড ফ্ল্যাগগুলিকে একটি স্ট্রাকচারে একত্রিত করতে পারেন এবং এমন একটি ফাংশন থাকতে পারে যা সেই স্ট্রাকচারটি রিটার্ন করে (এটি করলে ফাংশন কলের সংখ্যা কমে যেতে পারে)।

যেমন, hardware/interfaces/configstore/1.0/ISurfaceFlingerConfigs.hal এ একটি struct-এ দুটি বিল্ড ফ্ল্যাগ একত্রিত করার বিকল্প হল:

 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 ইন্টারফেসের ডিজাইন দুটি বিকল্প প্রদান করে:

• একটি ইন্টারফেস যা সব কনফিগারেশন আইটেম কভার করে
• একাধিক ইন্টারফেস, যার প্রত্যেকটি সম্পর্কিত কনফিগারেশন আইটেমের একটি সেট কভার করে

একটি ইন্টারফেস সহজ হলেও, একটি ফাইলে আরও বেশি কনফিগারেশন আইটেম যোগ করা হলে তা ম্যানেজ করা কঠিন হয়ে পড়ে। এছাড়াও, অ্যাক্সেস কন্ট্রোল ফাইন-গ্রেনড নয়, তাই ইন্টারফেসে অ্যাক্সেস মঞ্জুর করা হয়েছে এমন প্রসেস সব কনফিগারেশন আইটেম পড়তে পারে (কনফিগারেশন আইটেমের আংশিক সেটে অ্যাক্সেস মঞ্জুর করা যায় না)। বিকল্প হিসেবে, অ্যাক্সেস না দেওয়া হলে, কনফিগারেশন আইটেম পড়া যাবে না।

এইসব সমস্যার কারণে, Android সম্পর্কিত কনফিগারেশন আইটেমের গ্রুপের জন্য একটি HAL ইন্টারফেস সহ একাধিক ইন্টারফেস ব্যবহার করে। যেমন, surfaceflinger-সম্পর্কিত কনফিগারেশন আইটেমের জন্য ISurfaceflingerConfigs এবং ব্লুটুথ-সম্পর্কিত কনফিগারেশন আইটেমের জন্য IBluetoothConfigs।