অ্যান্ড্রয়েড ১০-এ, ConfigStore HAL বিল্ড ফ্ল্যাগ ব্যবহার করে vendor পার্টিশনে কনফিগের মানগুলো সংরক্ষণ করে এবং system পার্টিশনের একটি সার্ভিস HIDL ব্যবহার করে সেই মানগুলো অ্যাক্সেস করে (অ্যান্ড্রয়েড ৯-এও এটি প্রযোজ্য ছিল)। তবে, উচ্চ মেমরি খরচ এবং ব্যবহারে অসুবিধার কারণে ConfigStore HAL-কে অপ্রচলিত ঘোষণা করা হয়েছে।
পুরানো ভেন্ডর পার্টিশনগুলিকে সমর্থন করার জন্য ConfigStore HAL, AOSP-তে থেকে যায়। Android 10 বা তার পরবর্তী সংস্করণে চালিত ডিভাইসগুলিতে, surfaceflinger প্রথমে সিস্টেম প্রোপার্টিগুলি পড়ে; যদি `SurfaceFlingerProperties.sysprop`-এ কোনো কনফিগ আইটেমের জন্য কোনো সিস্টেম প্রোপার্টি সংজ্ঞায়িত না থাকে, তাহলে `surfaceflinger` ConfigStore HAL-এ ফিরে যায়।
অ্যান্ড্রয়েড ৮.০ একক অ্যান্ড্রয়েড অপারেটিং সিস্টেমকে জেনেরিক ( system.img ) এবং হার্ডওয়্যার-নির্দিষ্ট ( vendor.img ও odm.img ) পার্টিশনে বিভক্ত করে। এই পরিবর্তনের ফলে, সিস্টেম পার্টিশনে ইনস্টল করা মডিউলগুলো থেকে কন্ডিশনাল কম্পাইলেশন অবশ্যই সরিয়ে ফেলতে হবে এবং এই ধরনের মডিউলগুলোকে রানটাইমে সিস্টেমের কনফিগারেশন নির্ধারণ করতে হবে (এবং সেই কনফিগারেশনের উপর নির্ভর করে ভিন্নভাবে আচরণ করতে হবে)।
ConfigStore HAL, অ্যান্ড্রয়েড ফ্রেমওয়ার্ক কনফিগার করতে ব্যবহৃত রিড-অনলি কনফিগারেশন আইটেমগুলো অ্যাক্সেস করার জন্য একগুচ্ছ API প্রদান করে। এই পৃষ্ঠায় ConfigStore HAL-এর ডিজাইন বর্ণনা করা হয়েছে (এবং কেন এই উদ্দেশ্যে সিস্টেম প্রোপার্টি ব্যবহার করা হয়নি); এই বিভাগের অন্যান্য পৃষ্ঠাগুলোতে HAL ইন্টারফেস , সার্ভিস ইমপ্লিমেন্টেশন এবং ক্লায়েন্ট-সাইড ব্যবহার বিস্তারিতভাবে বর্ণনা করা হয়েছে, যার সবকটিতেই উদাহরণ হিসেবে surfaceflinger ব্যবহার করা হয়েছে। ConfigStore ইন্টারফেস ক্লাস সম্পর্কে সাহায্যের জন্য, “Adding Interface Classes and Items” দেখুন।
সিস্টেম প্রোপার্টি ব্যবহার করছেন না কেন?
আমরা সিস্টেম প্রোপার্টি ব্যবহার করার কথা বিবেচনা করেছিলাম, কিন্তু বেশ কিছু মৌলিক সমস্যা খুঁজে পেয়েছি, যার মধ্যে রয়েছে:
- ভ্যালুর দৈর্ঘ্যের সীমাবদ্ধতা। সিস্টেম প্রোপার্টিগুলোর ভ্যালুর দৈর্ঘ্যের উপর কঠোর সীমাবদ্ধতা (৯২ বাইট) রয়েছে। এছাড়াও, যেহেতু এই সীমাবদ্ধতাগুলো সি ম্যাক্রো হিসেবে সরাসরি অ্যান্ড্রয়েড অ্যাপে প্রকাশ করা হয়েছে, তাই এর দৈর্ঘ্য বাড়ালে ব্যাকওয়ার্ড-কম্প্যাটিবিলিটি সমস্যা দেখা দিতে পারে।
- কোনো টাইপ সাপোর্ট নেই। সমস্ত ভ্যালু মূলত স্ট্রিং, এবং এপিআইগুলো কেবল স্ট্রিংটিকে পার্স করে একটি
intবাboolএ রূপান্তর করে। অন্যান্য যৌগিক ডেটা টাইপ (যেমন, অ্যারে এবং স্ট্রাক্ট) ক্লায়েন্টদের দ্বারা এনকোড/ডিকোড করা উচিত (উদাহরণস্বরূপ,"aaa,bbb,ccc"তিনটি স্ট্রিংয়ের একটি অ্যারে হিসাবে কোড করা যেতে পারে)। - ওভাররাইট। যেহেতু রিড-অনলি সিস্টেম প্রোপার্টিগুলো রাইট-ওয়ান্স প্রোপার্টি হিসেবে প্রয়োগ করা হয়, তাই যে সকল ভেন্ডর/ওডিএম AOSP-সংজ্ঞায়িত রিড-অনলি ভ্যালু ওভাররাইড করতে চায়, তাদের অবশ্যই AOSP-সংজ্ঞায়িত রিড-অনলি ভ্যালুর আগে নিজেদের রিড-অনলি ভ্যালু ইম্পোর্ট করতে হবে। এর ফলে, ভেন্ডর-সংজ্ঞায়িত রিরাইটেবল ভ্যালুগুলো AOSP-সংজ্ঞায়িত ভ্যালু দ্বারা ওভাররাইড হয়ে যায়।
- অ্যাড্রেস স্পেসের প্রয়োজনীয়তা। সিস্টেম প্রোপার্টিগুলো প্রতিটি প্রসেসে তুলনামূলকভাবে বেশি পরিমাণ অ্যাড্রেস স্পেস দখল করে। সিস্টেম প্রোপার্টিগুলোকে
prop_areaইউনিটে ভাগ করা হয়, যার একটি নির্দিষ্ট আকার হলো ১২৮ কিলোবাইট। এমনকি যদি কোনো প্রসেসের কেবল একটিমাত্র সিস্টেম প্রোপার্টি অ্যাক্সেস করা হয়, তাহলেও এর পুরোটাই সেই প্রসেসের অ্যাড্রেস স্পেসের জন্য বরাদ্দ করা হয়। ৩২-বিটের ডিভাইসগুলোতে এটি সমস্যা তৈরি করতে পারে, যেখানে অ্যাড্রেস স্পেস অত্যন্ত মূল্যবান।
আমরা সামঞ্জস্যতা বজায় রেখে এই সীমাবদ্ধতাগুলো অতিক্রম করার চেষ্টা করেছিলাম, কিন্তু আমাদের উদ্বেগ থেকেই গিয়েছিল যে সিস্টেম প্রোপার্টিগুলো রিড-অনলি কনফিগারেশন আইটেম অ্যাক্সেস করার জন্য ডিজাইন করা হয়নি। অবশেষে আমরা এই সিদ্ধান্তে উপনীত হই যে, রিয়েল টাইমে সমগ্র অ্যান্ড্রয়েড জুড়ে কয়েকটি ডায়নামিকভাবে আপডেট হওয়া আইটেম শেয়ার করার জন্য সিস্টেম প্রোপার্টিগুলোই বেশি উপযুক্ত, এবং রিড-অনলি কনফিগারেশন আইটেমগুলো অ্যাক্সেস করার জন্য একটি নতুন ডেডিকেটেড সিস্টেমের প্রয়োজন ছিল।
কনফিগস্টোর এইচএএল ডিজাইন
মৌলিক নকশাটি সহজ:
চিত্র ১. কনফিগস্টোর এইচএএল ডিজাইন
- HIDL-এ বিল্ড ফ্ল্যাগগুলো (যা বর্তমানে ফ্রেমওয়ার্কটি শর্তসাপেক্ষে কম্পাইল করার জন্য ব্যবহৃত হয়) বর্ণনা করুন।
- ভেন্ডর এবং ওইএম-রা এইচএএল সার্ভিস বাস্তবায়নের মাধ্যমে বিল্ড ফ্ল্যাগের জন্য এসওসি এবং ডিভাইস-নির্দিষ্ট মান সরবরাহ করে।
- রানটাইমে কোনো কনফিগারেশন আইটেমের মান খুঁজে বের করার জন্য HAL সার্ভিস ব্যবহার করতে ফ্রেমওয়ার্কটি পরিবর্তন করুন।
ফ্রেমওয়ার্ক বর্তমানে যে কনফিগারেশন আইটেমগুলো ব্যবহার করে, সেগুলো একটি ভার্সনযুক্ত HIDL প্যাকেজে ( android.hardware.configstore@1.0 ) অন্তর্ভুক্ত রয়েছে। ভেন্ডর/ওইএম-রা এই প্যাকেজের ইন্টারফেসগুলো ইমপ্লিমেন্ট করার মাধ্যমে কনফিগারেশন আইটেমগুলোতে ভ্যালু সরবরাহ করে, এবং ফ্রেমওয়ার্ক যখন কোনো কনফিগারেশন আইটেমের জন্য ভ্যালু পেতে চায়, তখন সেই ইন্টারফেসগুলো ব্যবহার করে।
নিরাপত্তা সংক্রান্ত বিবেচনা
একই ইন্টারফেসে সংজ্ঞায়িত বিল্ড ফ্ল্যাগগুলো একই SELinux পলিসি দ্বারা প্রভাবিত হয়। যদি এক বা একাধিক বিল্ড ফ্ল্যাগের জন্য ভিন্ন ভিন্ন SELinux পলিসি প্রয়োজন হয়, তবে সেগুলোকে অবশ্যই অন্য একটি ইন্টারফেসে আলাদা করতে হবে । এর জন্য android.hardware.configstore package একটি বড় ধরনের সংশোধনের প্রয়োজন হতে পারে, কারণ এই আলাদা করা ইন্টারফেসগুলো আর ব্যাকওয়ার্ড-কম্প্যাটিবল থাকে না।