HIDL ইন্টারফেসের চারপাশে তৈরি করা হয়েছে, একটি বিমূর্ত টাইপ যা অবজেক্ট-ওরিয়েন্টেড ভাষায় ব্যবহার করা হয় আচরণকে সংজ্ঞায়িত করতে। প্রতিটি ইন্টারফেস একটি প্যাকেজের অংশ।
প্যাকেজ
প্যাকেজের নামের সাবলেভেল থাকতে পারে যেমন package.subpackage
। প্রকাশিত HIDL প্যাকেজের রুট ডিরেক্টরি হল hardware/interfaces
বা vendor/vendorName
(উদাহরণস্বরূপ, পিক্সেল ডিভাইসের জন্য vendor/google
)। প্যাকেজ নাম রুট ডিরেক্টরির অধীনে এক বা একাধিক সাবডিরেক্টরি গঠন করে; একটি প্যাকেজ সংজ্ঞায়িত সমস্ত ফাইল একই ডিরেক্টরিতে থাকে। উদাহরণস্বরূপ, package android.hardware.example.extension.light@2.0
hardware/interfaces/example/extension/light/2.0
অধীনে পাওয়া যেতে পারে।
নিম্নলিখিত সারণী প্যাকেজ উপসর্গ এবং অবস্থান তালিকাভুক্ত করে:
প্যাকেজ উপসর্গ | অবস্থান | ইন্টারফেস প্রকার |
---|---|---|
android.hardware.* | hardware/interfaces/* | HAL |
android.frameworks.* | frameworks/hardware/interfaces/* | ফ্রেমওয়ার্ক/ সম্পর্কিত |
android.system.* | system/hardware/interfaces/* | সিস্টেম/সম্পর্কিত |
android.hidl.* | system/libhidl/transport/* | মূল |
প্যাকেজ ডিরেক্টরিতে এক্সটেনশন .hal
সহ ফাইল রয়েছে। প্রতিটি ফাইলে একটি package
স্টেটমেন্ট থাকতে হবে যার নাম প্যাকেজ এবং সংস্করণ ফাইলটির অংশ। ফাইল types.hal
, যদি উপস্থিত থাকে তবে একটি ইন্টারফেস সংজ্ঞায়িত করে না বরং প্যাকেজের প্রতিটি ইন্টারফেসে অ্যাক্সেসযোগ্য ডেটা প্রকারগুলিকে সংজ্ঞায়িত করে।
ইন্টারফেস সংজ্ঞা
types.hal
বাদ দিয়ে, অন্য প্রতিটি .hal
ফাইল একটি ইন্টারফেস সংজ্ঞায়িত করে। একটি ইন্টারফেস সাধারণত নিম্নরূপ সংজ্ঞায়িত করা হয়:
interface IBar extends IFoo { // IFoo is another interface // embedded types struct MyStruct {/*...*/}; // interface methods create(int32_t id) generates (MyStruct s); close(); };
একটি স্পষ্ট extends
ডিক্লেয়ারেশন ছাড়া একটি ইন্টারফেস android.hidl.base@1.0::IBase
(জাভাতে java.lang.Object
এর অনুরূপ।) IBase ইন্টারফেস, পরোক্ষভাবে আমদানি করা, বেশ কয়েকটি সংরক্ষিত পদ্ধতি ঘোষণা করে যা উচিত নয় এবং করা উচিত নয়। ব্যবহারকারী-সংজ্ঞায়িত ইন্টারফেসে পুনরায় ঘোষণা করা বা অন্যথায় ব্যবহার করা। এই পদ্ধতি অন্তর্ভুক্ত:
-
ping
-
interfaceChain
-
interfaceDescriptor
-
notifySyspropsChanged
-
linkToDeath
-
unlinkToDeath
-
setHALInstrumentation
-
getDebugInfo
-
debug
-
getHashChain
আমদানি প্রক্রিয়া
import
স্টেটমেন্ট হল HIDL মেকানিজম প্যাকেজ ইন্টারফেস এবং অন্য প্যাকেজে টাইপ অ্যাক্সেস করার জন্য। একটি import
বিবৃতি দুটি সত্তার সাথে নিজেকে উদ্বিগ্ন করে:
- আমদানি করা সত্তা, যা একটি প্যাকেজ বা একটি ইন্টারফেস হতে পারে
- ইম্পোর্ট ed সত্তা, যা একটি প্যাকেজ বা একটি ইন্টারফেস হতে পারে
আমদানিকারী সত্তা import
বিবৃতির অবস্থান দ্বারা নির্ধারিত হয়। যখন স্টেটমেন্টটি প্যাকেজের types.hal
এর ভিতরে থাকে, তখন যা আমদানি করা হচ্ছে তা পুরো প্যাকেজ দ্বারা দৃশ্যমান হয়; এটি একটি প্যাকেজ-স্তরের আমদানি। যখন বিবৃতিটি একটি ইন্টারফেস ফাইলের ভিতরে থাকে, তখন আমদানিকারী সত্তাটি নিজেই ইন্টারফেস হয়; এটি একটি ইন্টারফেস-স্তরের আমদানি।
আমদানিকৃত সত্তাটি import
কীওয়ার্ডের পরে মান দ্বারা নির্ধারিত হয়। মান একটি সম্পূর্ণ যোগ্য নাম হতে হবে না; যদি একটি উপাদান বাদ দেওয়া হয়, এটি স্বয়ংক্রিয়ভাবে বর্তমান প্যাকেজ থেকে তথ্য দিয়ে পূর্ণ হয়। সম্পূর্ণরূপে যোগ্য মানগুলির জন্য, নিম্নলিখিত আমদানি ক্ষেত্রে সমর্থিত:
- পুরো প্যাকেজ আমদানি। যদি মানটি একটি প্যাকেজের নাম এবং একটি সংস্করণ হয় (নীচে বর্ণিত সিনট্যাক্স), তাহলে সম্পূর্ণ প্যাকেজটি আমদানিকারী সত্তায় আমদানি করা হয়।
- আংশিক আমদানি। মান যদি হয়:
- একটি ইন্টারফেস, প্যাকেজের
types.hal
এবং সেই ইন্টারফেসটি আমদানিকারী সত্তায় আমদানি করা হয়। -
types.hal
এ সংজ্ঞায়িত একটি UDT , তারপর শুধুমাত্র UDT আমদানিকারী সত্তায় আমদানি করা হয় (types.hal
এ অন্যান্য ধরনের আমদানি করা হয় না)।
- একটি ইন্টারফেস, প্যাকেজের
- প্রকার-শুধুই আমদানি। যদি মান উপরে বর্ণিত একটি আংশিক আমদানির সিনট্যাক্স ব্যবহার করে, কিন্তু ইন্টারফেস নামের পরিবর্তে কীওয়ার্ড
types
সাথে, মনোনীত প্যাকেজেরtypes.hal
এ শুধুমাত্র UDTs আমদানি করা হয়।
আমদানিকারী সত্তা নিম্নলিখিতগুলির সংমিশ্রণে অ্যাক্সেস পায়:
- আমদানি করা প্যাকেজের সাধারণ ইউডিটিগুলি
types.hal
এ সংজ্ঞায়িত করা হয়েছে; - আমদানি করা প্যাকেজের ইন্টারফেসগুলি (একটি সম্পূর্ণ-প্যাকেজ আমদানির জন্য) বা নির্দিষ্ট ইন্টারফেস (একটি আংশিক আমদানির জন্য) তাদের আহ্বান করার উদ্দেশ্যে, তাদের কাছে হ্যান্ডেলগুলি প্রেরণ এবং/অথবা তাদের কাছ থেকে উত্তরাধিকারসূত্রে প্রাপ্ত।
আমদানি বিবৃতিটি আমদানি করা প্যাকেজ বা ইন্টারফেসের নাম এবং সংস্করণ প্রদান করতে সম্পূর্ণরূপে যোগ্যতাসম্পন্ন-টাইপ-নাম সিনট্যাক্স ব্যবহার করে:
import android.hardware.nfc@1.0; // import a whole package import android.hardware.example@1.0::IQuux; // import an interface and types.hal import android.hardware.example@1.0::types; // import just types.hal
ইন্টারফেসের উত্তরাধিকার
একটি ইন্টারফেস পূর্বে-সংজ্ঞায়িত ইন্টারফেসের একটি এক্সটেনশন হতে পারে। এক্সটেনশন নিম্নলিখিত তিনটি প্রকারের একটি হতে পারে:
- ইন্টারফেস অন্যটিতে কার্যকারিতা যোগ করতে পারে, এর API অপরিবর্তিত অন্তর্ভুক্ত করে।
- প্যাকেজ অন্য একটিতে কার্যকারিতা যোগ করতে পারে, এর API অপরিবর্তিত অন্তর্ভুক্ত করে।
- ইন্টারফেস একটি প্যাকেজ বা একটি নির্দিষ্ট ইন্টারফেস থেকে প্রকারগুলি আমদানি করতে পারে।
একটি ইন্টারফেস শুধুমাত্র একটি অন্য ইন্টারফেস প্রসারিত করতে পারে (কোন একাধিক উত্তরাধিকার নেই)। একটি প্যাকেজের প্রতিটি ইন্টারফেস একটি নন-জিরো মাইনর সংস্করণ নম্বর সহ প্যাকেজের পূর্ববর্তী সংস্করণে একটি ইন্টারফেস প্রসারিত করতে হবে। উদাহরণস্বরূপ, যদি প্যাকেজ derivative
4.0 সংস্করণের একটি ইন্টারফেস IBar
প্যাকেজ original
1.2 সংস্করণে একটি ইন্টারফেস IFoo
উপর ভিত্তি করে (প্রসারিত) হয় এবং প্যাকেজ original
সংস্করণ 1.3 তৈরি করা হয়, IBar
সংস্করণ 4.1 IFoo
এর সংস্করণ 1.3 প্রসারিত করতে পারে না। . পরিবর্তে, IBar
সংস্করণ 4.1 অবশ্যই IBar
সংস্করণ 4.0 প্রসারিত করবে, যা IFoo
সংস্করণ 1.2 এর সাথে সংযুক্ত। IBar
সংস্করণ 5.0 IFoo
সংস্করণ 1.3 প্রসারিত করতে পারে, যদি ইচ্ছা হয়।
ইন্টারফেস এক্সটেনশনগুলি জেনারেট করা কোডে লাইব্রেরি নির্ভরতা বা ক্রস-এইচএএল অন্তর্ভুক্তি বোঝায় না - তারা কেবল HIDL স্তরে ডেটা কাঠামো এবং পদ্ধতির সংজ্ঞা আমদানি করে। একটি HAL-এর প্রতিটি পদ্ধতি অবশ্যই সেই HAL-এ প্রয়োগ করতে হবে৷
বিক্রেতা এক্সটেনশন
কিছু ক্ষেত্রে, বিক্রেতা এক্সটেনশনগুলি বেস অবজেক্টের একটি সাবক্লাস হিসাবে প্রয়োগ করা হয় যা তাদের প্রসারিত মূল ইন্টারফেসের প্রতিনিধিত্ব করে। একই বস্তু বেস HAL নাম এবং সংস্করণের অধীনে নিবন্ধিত হয় এবং এক্সটেনশনের (বিক্রেতা) HAL নাম এবং সংস্করণের অধীনে।
সংস্করণ করা
প্যাকেজ সংস্করণ করা হয়, এবং ইন্টারফেস তাদের প্যাকেজ সংস্করণ আছে. সংস্করণ দুটি পূর্ণসংখ্যায় প্রকাশ করা হয়, প্রধান । নাবালক
- প্রধান সংস্করণগুলি পিছনের দিকে সামঞ্জস্যপূর্ণ নয়। বড় সংস্করণ সংখ্যা বৃদ্ধি করা ছোট সংস্করণ সংখ্যা 0 এ পুনরায় সেট করে।
- ছোট সংস্করণগুলি পিছনের দিকে সামঞ্জস্যপূর্ণ। গৌণ সংখ্যা বৃদ্ধি ইঙ্গিত করে যে নতুন সংস্করণটি পূর্ববর্তী সংস্করণের সাথে সম্পূর্ণ পশ্চাদপদ সামঞ্জস্যপূর্ণ। নতুন ডাটা স্ট্রাকচার এবং পদ্ধতি যোগ করা যেতে পারে, কিন্তু কোন বিদ্যমান ডাটা স্ট্রাকচার বা পদ্ধতি স্বাক্ষর পরিবর্তন করা যাবে না।
একটি এইচএএল-এর একাধিক বড় বা ছোট সংস্করণ একই সাথে একটি ডিভাইসে উপস্থিত থাকতে পারে। যাইহোক, একটি ছোট সংস্করণ একটি প্রধান সংস্করণের চেয়ে পছন্দ করা উচিত কারণ ক্লায়েন্ট কোড যা পূর্ববর্তী ছোট সংস্করণ ইন্টারফেসের সাথে কাজ করে সেই একই ইন্টারফেসের পরবর্তী ছোট সংস্করণগুলির সাথেও কাজ করে। সংস্করণ এবং বিক্রেতা এক্সটেনশন সম্পর্কে আরও বিশদ বিবরণের জন্য, HIDL সংস্করণ দেখুন।
ইন্টারফেস লেআউট সারাংশ
এই বিভাগটি সংক্ষিপ্ত করে কিভাবে একটি HIDL ইন্টারফেস প্যাকেজ (যেমন hardware/interfaces
) পরিচালনা করতে হয় এবং HIDL বিভাগে উপস্থাপিত তথ্য একত্রিত করে। পড়ার আগে, নিশ্চিত করুন যে আপনি HIDL সংস্করণের সাথে পরিচিত, hidl-gen ধারণার সাথে হ্যাশিং , সাধারণভাবে HIDL এর সাথে কাজ করার বিশদ বিবরণ এবং নিম্নলিখিত সংজ্ঞাগুলি:
মেয়াদ | সংজ্ঞা |
---|---|
অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABI) | অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেস প্লাস যেকোনো বাইনারি লিঙ্কেজ প্রয়োজন। |
সম্পূর্ণ যোগ্য নাম (fqName) | একটি hidl প্রকারকে আলাদা করার জন্য নাম। উদাহরণ: android.hardware.foo@1.0::IFoo । |
প্যাকেজ | একটি HIDL ইন্টারফেস এবং প্রকারগুলি ধারণকারী প্যাকেজ৷ উদাহরণ: android.hardware.foo@1.0 । |
প্যাকেজ রুট | রুট প্যাকেজ যা HIDL ইন্টারফেস ধারণ করে। উদাহরণ: HIDL ইন্টারফেস android.hardware প্যাকেজ রুটে রয়েছে android.hardware.foo@1.0 । |
প্যাকেজ রুট পাথ | Android সোর্স ট্রিতে অবস্থান যেখানে একটি প্যাকেজ রুট ম্যাপ করে। |
আরও সংজ্ঞার জন্য, HIDL পরিভাষা দেখুন।
প্রতিটি ফাইল প্যাকেজ রুট ম্যাপিং এবং এর সম্পূর্ণ যোগ্য নাম থেকে পাওয়া যাবে
প্যাকেজ রুটগুলি আর্গুমেন্ট হিসাবে hidl-gen
এ নির্দিষ্ট করা হয়েছে -r android.hardware:hardware/interfaces
। উদাহরণস্বরূপ, যদি প্যাকেজটি vendor.awesome.foo@1.0::IFoo
হয় এবং hidl-gen
পাঠানো হয় -r vendor.awesome:some/device/independent/path/interfaces
, তাহলে ইন্টারফেস ফাইলটি $ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal
-এ অবস্থিত হওয়া উচিত। $ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal
।
অনুশীলনে, একটি বিক্রেতা বা OEM নামক একটি awesome
তাদের আদর্শ ইন্টারফেসকে vendor.awesome
এ রাখার পরামর্শ দেওয়া হয়। একটি প্যাকেজ পাথ নির্বাচন করার পরে, এটি পরিবর্তন করা উচিত নয় কারণ এটি ইন্টারফেসের ABI-তে বেক করা হয়।
প্যাকেজ পাথ ম্যাপিং অনন্য হওয়া উচিত
উদাহরণস্বরূপ, যদি আপনার কাছে থাকে -rsome.package:$PATH_A
এবং -rsome.package:$PATH_B
, একটি সামঞ্জস্যপূর্ণ ইন্টারফেস ডিরেক্টরির জন্য $PATH_A
অবশ্যই $PATH_B
এর সমান হতে হবে (এটি সংস্করণ ইন্টারফেসগুলিকে আরও সহজ করে তোলে)।
প্যাকেজ রুটের একটি সংস্করণ ফাইল থাকতে হবে
আপনি যদি একটি প্যাকেজ পাথ তৈরি করেন যেমন -r vendor.awesome:vendor/awesome/interfaces
, তাহলে আপনার $ANDROID_BUILD_TOP/vendor/awesome/interfaces/current.txt
ফাইলটিও তৈরি করা উচিত, যাতে -Lhash
ব্যবহার করে তৈরি ইন্টারফেসের হ্যাশ থাকা উচিত। hidl-gen
এ বিকল্প (এটি hidl-gen এর সাথে হ্যাশিং- এ ব্যাপকভাবে আলোচনা করা হয়েছে)।
ইন্টারফেসগুলি ডিভাইস-স্বাধীন অবস্থানগুলিতে যায়
অনুশীলনে, আমরা শাখাগুলির মধ্যে ইন্টারফেস ভাগ করার পরামর্শ দিই। এটি সর্বাধিক কোড পুনরায় ব্যবহার এবং বিভিন্ন ডিভাইস এবং ব্যবহারের ক্ষেত্রে কোডের সর্বাধিক পরীক্ষার অনুমতি দেয়।