শেয়ার করা সিস্টেম ইমেজ

এই পৃষ্ঠায় এমন কয়েকটি কৌশল তুলে ধরা হয়েছে যা অ্যান্ড্রয়েড ওইএম (OEM)-রা তাদের বিভিন্ন প্রোডাক্ট লাইনের মধ্যে একটি শেয়ার্ড সিস্টেম ইমেজ (SSI) রাখার জন্য ব্যবহার করতে পারে। এছাড়াও, এখানে একটি এওএসপি (AOSP) দ্বারা নির্মিত জেনেরিক সিস্টেম ইমেজ (GSI)-এর উপর ভিত্তি করে ওইএম-এর নিজস্ব এসএসআই (SSI) তৈরির একটি পদ্ধতি প্রস্তাব করা হয়েছে।

পটভূমি

অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট (AOSP) ফ্রেমওয়ার্কটি পুরোনো ভেন্ডর ইমপ্লিমেন্টেশনগুলোর সাথে ব্যাকওয়ার্ড কম্প্যাটিবিলিটি বজায় রাখার জন্য মেইনলাইন আর্কিটেকচার মেনে চলে। উদাহরণস্বরূপ, অ্যান্ড্রয়েড ১০ AOSP সোর্স থেকে তৈরি একটি জেনেরিক সিস্টেম ইমেজ (GSI) অ্যান্ড্রয়েড ৮ বা তার উচ্চতর সংস্করণে চালিত যেকোনো ট্রেবল-কমপ্লায়েন্ট ডিভাইসে চলতে পারে।

মেইনলাইন অ্যান্ড্রয়েডকে দুটি স্বতন্ত্র অংশে বিভক্ত করার মাধ্যমে এটি অর্জন করে: হার্ডওয়্যার-নির্দিষ্ট ভেন্ডর ইমপ্লিমেন্টেশন এবং জেনেরিক অ্যান্ড্রয়েড ওএস ফ্রেমওয়ার্ক। প্রতিটি উপাদান একটি পৃথক পার্টিশনে ইনস্টল করা হয়—হার্ডওয়্যার-নির্দিষ্ট সফটওয়্যারের জন্য ভেন্ডর পার্টিশন এবং জেনেরিক ওএস-এর জন্য সিস্টেম পার্টিশন। এদের মধ্যে ভেন্ডর ইন্টারফেস ( VINTF ) নামে একটি ভার্সনযুক্ত ইন্টারফেস প্রয়োগ করা হয়। এই পার্টিশনিং সিস্টেমটি OEM-দের ভেন্ডর পার্টিশনে হাত না দিয়েই সিস্টেম পার্টিশন পরিবর্তন করতে এবং এর বিপরীতটিও করতে দেয়।

ঐতিহাসিকভাবে, SoC ভেন্ডর এবং OEM-রা কনজিউমার ডিভাইসে ব্যবহৃত অ্যান্ড্রয়েড ফ্রেমওয়ার্ক সংস্করণটিকে ব্যাপকভাবে পরিবর্তন করত (বিস্তারিত জানতে, ‘লাইফ অফ অ্যান অ্যান্ড্রয়েড রিলিজ’ দেখুন)। যেহেতু এই ফ্রেমওয়ার্ক এক্সটেনশনগুলো খুব কমই ব্যাকওয়ার্ড কম্প্যাটিবিলিটি মাথায় রেখে ডিজাইন করা হতো, তাই ডিভাইস-নির্দিষ্ট পরিবর্তনগুলো পরবর্তী OS আপগ্রেডের জটিলতা এবং আর্থিক খরচ নাটকীয়ভাবে বাড়িয়ে দিত। অ্যান্ড্রয়েড ১০ (API লেভেল ২৯) এবং এর নিচের সংস্করণগুলোতে, ইকোসিস্টেমে একটি সুস্পষ্ট, মানসম্মত আর্কিটেকচারের অভাব ছিল, যা পার্টনারদের অ্যান্ড্রয়েড ফ্রেমওয়ার্কের মডিউলার এক্সটেনশন তৈরি করতে দেয়।

এই পৃষ্ঠায় বর্ণনা করা হয়েছে কিভাবে SoC ভেন্ডর এবং OEM-রা একটি শেয়ার্ড সিস্টেম ইমেজ (SSI) তৈরি করতে পারে। SSI হলো অ্যান্ড্রয়েড ওএস সোর্স থেকে তৈরি একটি সমন্বিত ফ্রেমওয়ার্ক ইমেজ যা একাধিক ডিভাইসে পুনরায় ব্যবহার করা যায়। এই পার্টিশনড আর্কিটেকচারের মাধ্যমে ভেন্ডর ইমপ্লিমেন্টেশনগুলোর সাথে নিখুঁত ব্যাকওয়ার্ড কম্প্যাটিবিলিটি বজায় রেখে, একটি SSI অ্যান্ড্রয়েড ওএস আপগ্রেডের খরচ এবং জটিলতা উল্লেখযোগ্যভাবে কমিয়ে দেয়।

বাস্তবায়নের বিস্তারিত বিবরণের জন্য, GSI-ভিত্তিক SSI-এর জন্য প্রস্তাবিত পদক্ষেপসমূহ দেখুন। পদক্ষেপগুলো মডিউলার; আপনার আর্কিটেকচারের উপর নির্ভর করে, আপনি সমস্ত ধাপের পরিবর্তে নির্দিষ্ট পর্যায়গুলো (যেমন ধাপ ১: OEM সিস্টেম ইমেজের (OEM GSI) জন্য generic_system.mk ইনহেরিট করা ) বাস্তবায়ন করতে পারেন।

এসএসআই ওভারভিউ

SSI-এর মাধ্যমে, পণ্য-নির্দিষ্ট সফ্টওয়্যার উপাদান এবং OEM এক্সটেনশনগুলিকে একটি নতুন /product পার্টিশনে রাখা হয়। /product পার্টিশনের উপাদানগুলি /system পার্টিশনের উপাদানগুলির সাথে যোগাযোগ করার জন্য একটি সু-সংজ্ঞায়িত, স্থিতিশীল ইন্টারফেস ব্যবহার করে। OEM-রা একটি SSI তৈরি করতে পারে, অথবা একাধিক ডিভাইস SKU জুড়ে ব্যবহারের জন্য অল্প সংখ্যক SSI রাখতে পারে। যখন অ্যান্ড্রয়েড ওএস-এর একটি নতুন সংস্করণ প্রকাশিত হয়, তখন OEM-রা তাদের SSI-গুলিকে সর্বশেষ অ্যান্ড্রয়েড রিলিজে আপডেট করার জন্য শুধুমাত্র একবার বিনিয়োগ করে। তারা /product পার্টিশন আপডেট না করেই একাধিক ডিভাইস আপডেট করার জন্য SSI-গুলি পুনরায় ব্যবহার করতে পারে।

OEM এবং SoC ভেন্ডররা কাস্টম ফিচার ও মডিফিকেশন সহ SSI তৈরি করতে পারে। এই পৃষ্ঠায় প্রদত্ত পদ্ধতি ও সর্বোত্তম অনুশীলনগুলো OEM-দের নিম্নলিখিত মূল লক্ষ্যগুলো অর্জনে ব্যবহারের জন্য তৈরি করা হয়েছে:

• একাধিক ডিভাইস SKU জুড়ে SSI পুনরায় ব্যবহার করুন।
• ওএস আপগ্রেড আরও সহজ করতে মডিউলার এক্সটেনশনগুলির সাহায্যে অ্যান্ড্রয়েড সিস্টেম আপডেট করুন।

প্রোডাক্ট-নির্দিষ্ট উপাদানগুলোকে প্রোডাক্ট পার্টিশনে আলাদা করার মূল ধারণাটি, মেইনলাইন কর্তৃক SoC-নির্দিষ্ট উপাদানগুলোকে ভেন্ডর পার্টিশনে আলাদা করার অনুরূপ। একটি প্রোডাক্ট ইন্টারফেস ( VINTF- এর মতো) SSI এবং প্রোডাক্ট পার্টিশনের মধ্যে যোগাযোগের সুযোগ করে দেয়। SSI-এর ক্ষেত্রে, ' কম্পোনেন্ট' শব্দটি সেই সমস্ত রিসোর্স, বাইনারি, টেক্সট এবং লাইব্রেরিকে বোঝায় যা ইমেজে ইনস্টল করা হয় এবং যা পরবর্তীতে পার্টিশনে পরিণত হয়।

এসএসআই-এর আশেপাশে বিভাজন

চিত্র ১-এ SSI-এর চারপাশের পার্টিশনগুলো, পার্টিশনগুলো জুড়ে থাকা ভার্সনযুক্ত ইন্টারফেসগুলো এবং ইন্টারফেসগুলোর ওপর থাকা পলিসিগুলো দেখানো হয়েছে। এই অংশে প্রতিটি পার্টিশন এবং ইন্টারফেস বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে।

চিত্র ১. এসএসআই-এর চারপাশের পার্টিশন এবং ইন্টারফেসসমূহ।

ছবি এবং পার্টিশন

এই অংশে ইমেজ এবং পার্টিশন শব্দ দুটির মধ্যে পার্থক্য তুলে ধরা হয়েছে।

• ইমেজ হলো সফটওয়্যারের একটি ধারণাগত অংশ যা স্বাধীনভাবে আপডেট করা যায়।
• পার্টিশন হলো একটি ভৌত ​​স্টোরেজ অবস্থান যা স্বাধীনভাবে আপডেট করা যায়।

চিত্র ১-এ থাকা অংশগুলো নিম্নরূপভাবে সংজ্ঞায়িত করা হয়েছে:

• SSI: একটি ইমেজ যা একটি OEM-এর জন্য সাধারণ এবং যা একাধিক ডিভাইসে থাকতে পারে। এতে কোনো হার্ডওয়্যার-নির্দিষ্ট বা পণ্য-নির্দিষ্ট উপাদান থাকে না। সংজ্ঞানুসারে, একটি নির্দিষ্ট SSI-এর সবকিছু সেই SSI ব্যবহারকারী সমস্ত ডিভাইসের মধ্যে শেয়ার করা হয়। SSI-টি একটি একক /system ইমেজ, অথবা একটি /system এবং /system_ext পার্টিশন দ্বারা গঠিত।

• প্রোডাক্ট ইমেজ: প্রোডাক্ট বা ডিভাইস-নির্দিষ্ট কম্পোনেন্টগুলোর একটি সংগ্রহ, যা অ্যান্ড্রয়েড ওএস-এ OEM কাস্টমাইজেশন এবং এক্সটেনশনগুলোকে উপস্থাপন করে। SoC-নির্দিষ্ট কম্পোনেন্টগুলো /vendor পার্টিশনে রাখুন। SoC ভেন্ডররাও উপযুক্ত কম্পোনেন্ট, যেমন SoC-নিরপেক্ষ কম্পোনেন্টগুলোর জন্য /product পার্টিশন ব্যবহার করতে পারেন। উদাহরণস্বরূপ, যদি কোনো SoC ভেন্ডর তাদের OEM গ্রাহকদের একটি SoC-নিরপেক্ষ কম্পোনেন্ট সরবরাহ করে (যা প্রোডাক্টের সাথে পাঠানো ঐচ্ছিক), তবে সেই SoC ভেন্ডর কম্পোনেন্টটিকে প্রোডাক্ট ইমেজে রাখতে পারেন। কোনো কম্পোনেন্টের অবস্থান তার উদ্দেশ্য দ্বারা নির্ধারিত হয়, তার মালিকানা দ্বারা নয়।

• ভেন্ডর ইমেজ: এসওসি-নির্দিষ্ট উপাদানগুলোর একটি সংগ্রহ।

• ODM ইমেজ: বোর্ড-নির্দিষ্ট উপাদানগুলির একটি সংগ্রহ যা SoC দ্বারা সরবরাহ করা হয় না। সাধারণত SoC ভেন্ডর, ভেন্ডর ইমেজের মালিক হয়, আর ডিভাইস নির্মাতা ODM ইমেজের মালিক হয়। যখন কোনো আলাদা /odm পার্টিশন থাকে না, তখন SoC ভেন্ডর এবং ODM উভয় ইমেজই /vendor পার্টিশনে একত্রিত হয়ে যায়।

/system_ext পার্টিশন

/system_ext পার্টিশনটি ঐচ্ছিক। AOSP-ভিত্তিক কম্পোনেন্টগুলোর সাথে নিবিড়ভাবে সংযুক্ত যেকোনো কাস্টম ফিচার এবং এক্সটেনশনের জন্য এই পার্টিশনটি ব্যবহার করুন। এই পার্টিশনটিকে /system পার্টিশনের OEM-নির্দিষ্ট এক্সটেনশন হিসেবে ধরে নেওয়া হয়, যেখানে দুটি পার্টিশনের মধ্যে কোনো ইন্টারফেস সংজ্ঞায়িত করা নেই। /system_ext পার্টিশনের কম্পোনেন্টগুলো /system পার্টিশনে প্রাইভেট API কল করতে পারে, এবং /system পার্টিশনের কম্পোনেন্টগুলো /system_ext পার্টিশনে প্রাইভেট API কল করতে পারে।

যেহেতু পার্টিশন দুটি ঘনিষ্ঠভাবে সংযুক্ত, তাই অ্যান্ড্রয়েডের নতুন সংস্করণ প্রকাশিত হলে উভয় পার্টিশনই একসাথে আপগ্রেড করা হয়। অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণের জন্য তৈরি করা একটি /system_ext পার্টিশনকে পরবর্তী সংস্করণে /system পার্টিশনের সাথে সামঞ্জস্যপূর্ণ হওয়ার প্রয়োজন হয় না।

/system_ext পার্টিশনে একটি মডিউল ইনস্টল করতে, Android.bp ফাইলে system_ext_specific: true যোগ করুন। যেসব ডিভাইসে /system_ext পার্টিশন নেই, সেগুলোতে এই ধরনের মডিউলগুলো /system পার্টিশনের অন্তর্গত ./system_ext সাবডিরেক্টরিতে ইনস্টল করুন।

ইতিহাস: /system_ext পার্টিশনের মূল নকশার লক্ষ্য ছিল সমস্ত OEM-নির্দিষ্ট উপাদান, সেগুলি সাধারণ হোক বা না হোক, /product পার্টিশনে রাখা। তবে, সেগুলিকে একবারে সরানো সম্ভব ছিল না, বিশেষ করে যখন কিছু উপাদানের /system পার্টিশনের সাথে একটি দৃঢ় সংযোগ ছিল। একটি দৃঢ় সংযুক্ত উপাদানকে /product পার্টিশনে সরাতে হলে, প্রোডাক্ট ইন্টারফেসটি প্রসারিত করতে হতো। এর জন্য প্রায়শই উপাদানটিকে ব্যাপকভাবে রিফ্যাক্টর করার প্রয়োজন হতো, যা প্রচুর সময় এবং শ্রম ব্যয় করত। /system_ext পার্টিশনটি সেইসব উপাদানকে সাময়িকভাবে রাখার একটি জায়গা হিসাবে শুরু হয়েছিল, যেগুলি /product পার্টিশনে সরানোর জন্য প্রস্তুত ছিল না। SSI-এর লক্ষ্য ছিল অবশেষে /system_ext পার্টিশনটি বিলুপ্ত করা।

তবে, /system_ext পার্টিশনটি /system পার্টিশনকে AOSP-এর যতটা সম্ভব কাছাকাছি রাখার জন্য উপযোগী। SSI-এর ক্ষেত্রে, আপগ্রেডের বেশিরভাগ প্রচেষ্টা /system এবং /system_ext পার্টিশনের উপাদানগুলোর পেছনে ব্যয় হয়। যখন সিস্টেম ইমেজটি AOSP-এর সোর্সগুলোর সাথে যতটা সম্ভব সাদৃশ্যপূর্ণ সোর্স থেকে তৈরি করা হয়, তখন আপনি আপগ্রেডের প্রচেষ্টা system_ext ইমেজের উপর কেন্দ্রীভূত করতে পারেন।

ছবিগুলির মধ্যে ইন্টারফেস

SSI-তে বিক্রেতা এবং পণ্যের ছবির জন্য দুটি প্রধান ইন্টারফেস রয়েছে:

• ভেন্ডর ইন্টারফেস (VINTF) : VINTF হলো ভেন্ডর এবং ODM ইমেজে অবস্থিত কম্পোনেন্টগুলোর ইন্টারফেস। প্রোডাক্ট এবং সিস্টেম ইমেজের কম্পোনেন্টগুলো শুধুমাত্র এই ইন্টারফেসের মাধ্যমেই ভেন্ডর এবং ODM ইমেজের সাথে যোগাযোগ করতে পারে। উদাহরণস্বরূপ, একটি ভেন্ডর ইমেজ সিস্টেম ইমেজের কোনো প্রাইভেট অংশের উপর নির্ভর করতে পারে না, এবং এর বিপরীতটিও সত্য। এটি ট্রেবল আর্কিটেকচারে (যা এখন বৃহত্তর মেইনলাইন আর্কিটেকচারের অংশ) সংজ্ঞায়িত করা হয়েছে, যা ইমেজগুলোকে সিস্টেম এবং ভেন্ডর পার্টিশনে বিভক্ত করে। এই ইন্টারফেসটি নিম্নলিখিত পদ্ধতি ব্যবহার করে বর্ণনা করা হয়:

  • HIDL (পাসথ্রু HAL শুধুমাত্র system এবং system_ext মডিউলগুলির জন্য উপলব্ধ)
  • স্থিতিশীল AIDL
  • কনফিগারেশন
    • সিস্টেম প্রোপার্টিজ এপিআই
    • কনফিগারেশন ফাইল স্কিমা এপিআই
  • ভিএনডিকে
  • অ্যান্ড্রয়েড এসডিকে এপিআই
  • জাভা এসডিকে লাইব্রেরি

• প্রোডাক্ট ইন্টারফেস: প্রোডাক্ট ইন্টারফেস হলো SSI এবং প্রোডাক্ট ইমেজের মধ্যকার সংযোগস্থল। একটি স্থিতিশীল ইন্টারফেস নির্ধারণ করার মাধ্যমে একটি SSI-এর মধ্যে থাকা প্রোডাক্ট কম্পোনেন্টগুলোকে সিস্টেম কম্পোনেন্টগুলো থেকে বিচ্ছিন্ন করা হয়।

এসএসআই সক্ষম করুন

এই অংশে অ্যান্ড্রয়েড ১১ এবং এর পরবর্তী সংস্করণগুলোতে কীভাবে SSI সমর্থন করা যায়, তা ব্যাখ্যা করা হয়েছে।

উপাদানগুলি আলাদা করুন

সিস্টেম কম্পোনেন্টগুলো থেকে /product পার্টিশনকে আনবান্ডল করতে হলে, /product পার্টিশনটির এনফোর্সমেন্ট পলিসি অবশ্যই সেই /vendor পার্টিশনের এনফোর্সমেন্ট পলিসির মতোই হতে হবে, যা মেইনলাইনের মাধ্যমে ইতিমধ্যেই আনবান্ডল করা হয়েছিল।

• অন্তর্নির্মিত ইন্টারফেস: /product পার্টিশনের অন্তর্নির্মিত মডিউলগুলোকে অবশ্যই অন্যান্য পার্টিশন থেকে আলাদা করতে হবে। প্রোডাক্ট মডিউলগুলো থেকে শুধুমাত্র /system পার্টিশনের কিছু VNDK লাইব্রেরি (LLNDK সহ) ব্যবহারের অনুমতি আছে। প্রোডাক্ট অ্যাপগুলো যে JNI লাইব্রেরিগুলোর উপর নির্ভর করে, সেগুলো অবশ্যই NDK লাইব্রেরি হতে হবে।
• জাভা ইন্টারফেস: /product পার্টিশনের জাভা (অ্যাপ) মডিউলগুলো হিডেন এপিআই (hidden API) ব্যবহার করতে পারে না, কারণ সেগুলো অস্থিতিশীল। এই মডিউলগুলোকে অবশ্যই শুধুমাত্র /system পার্টিশনের পাবলিক এপিআই ও সিস্টেম এপিআই এবং /system বা /system_ext পার্টিশনের জাভা এসডিকে (SDK) লাইব্রেরি ব্যবহার করতে হবে। আপনি কাস্টম এপিআই-এর জন্য জাভা এসডিকে লাইব্রেরি সংজ্ঞায়িত করতে পারেন।

পণ্যের ইন্টারফেস প্রয়োগ করুন

/product পার্টিশনটি আনবান্ডল করা নিশ্চিত করতে, OEM-রা তাদের ডিভাইসগুলোকে প্রোডাক্ট ইন্টারফেস প্রয়োগ করতে পারে। এর জন্য বিল্ট-ইন মডিউলগুলোর ক্ষেত্রে PRODUCT_PRODUCT_VNDK_VERSION:= current এবং জাভা মডিউলগুলোর ক্ষেত্রে PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true সেট করতে হয়। যদি ডিভাইসটির PRODUCT_SHIPPING_API_LEVEL 30 বা তার বেশি হয়, তবে এই ভ্যারিয়েবলগুলো স্বয়ংক্রিয়ভাবে সেট হয়ে যায়। বিস্তারিত তথ্যের জন্য, “Enforce product partition interfaces” দেখুন।

জিএসআই-ভিত্তিক এসএসআই-এর জন্য প্রস্তাবিত পদক্ষেপ

চিত্র ২. জিএসআই-ভিত্তিক এসএসআই-এর জন্য প্রস্তাবিত বিভাজনসমূহ।

জেনেরিক সিস্টেম ইমেজ (GSI) হলো এমন একটি সিস্টেম ইমেজ যা সরাসরি AOSP থেকে তৈরি করা হয়। এটি কমপ্লায়েন্স টেস্টের (যেমন, CTS-on-GSI) জন্য এবং একটি রেফারেন্স প্ল্যাটফর্ম হিসেবে ব্যবহৃত হয়, যা অ্যাপ ডেভেলপাররা তাদের অ্যাপের সামঞ্জস্যতা পরীক্ষা করার জন্য ব্যবহার করতে পারেন, যখন তাদের কাছে অ্যান্ড্রয়েডের প্রয়োজনীয় সংস্করণ চালিত কোনো আসল ডিভাইস থাকে না।

OEM-রা তাদের SSI তৈরি করতে GSI-ও ব্যবহার করতে পারে। 'ইমেজ এবং পার্টিশন' অংশে যেমন ব্যাখ্যা করা হয়েছে, SSI-তে AOSP-দ্বারা সংজ্ঞায়িত কম্পোনেন্টগুলোর জন্য সিস্টেম ইমেজ এবং OEM-দ্বারা সংজ্ঞায়িত কম্পোনেন্টগুলোর জন্য system_ext ইমেজ থাকে। যখন GSI system ইমেজ হিসেবে ব্যবহৃত হয়, তখন OEM আপগ্রেডের জন্য system_ext ইমেজের উপর মনোযোগ দিতে পারে।

এই বিভাগটি সেইসব OEM-দের জন্য নির্দেশিকা প্রদান করে, যারা একটি AOSP বা প্রায়-AOSP সিস্টেম ইমেজ ব্যবহার করার সময় তাদের কাস্টমাইজেশনগুলিকে /system_ext এবং /product পার্টিশনে মডিউলারাইজ করতে চান। যদি OEM-রা AOSP সোর্স থেকে সিস্টেম ইমেজ তৈরি করে, তবে তারা তাদের তৈরি করা সিস্টেম ইমেজটিকে AOSP দ্বারা প্রদত্ত GSI দিয়ে প্রতিস্থাপন করতে পারে। তবে, OEM-দের চূড়ান্ত ধাপে (যেমন আছে তেমন GSI ব্যবহার করে) একবারে পৌঁছানোর প্রয়োজন নেই।

ধাপ ১: OEM সিস্টেম ইমেজ (OEM GSI)-এর জন্য generic_system.mk ইনহেরিট করুন।

generic_system.mk (যা Android 11-এ mainline_system.mk নামে এবং AOSP-তে generic_system.mk নামে পুনঃনামকরণ করা হয়েছিল) ইনহেরিট করার মাধ্যমে, সিস্টেম ইমেজ (OEM GSI)-এ AOSP GSI-এর সমস্ত ফাইল অন্তর্ভুক্ত থাকে। এই ফাইলগুলি OEM দ্বারা পরিবর্তিত হতে পারে, যাতে OEM GSI-তে AOSP GSI ফাইলগুলির পাশাপাশি OEM-এর নিজস্ব ফাইলগুলিও থাকতে পারে।

চিত্র ৩. OEM-এর সিস্টেম ইমেজের জন্য generic_system.mk উত্তরাধিকারসূত্রে গ্রহণ করুন।

ধাপ ২: OEM GSI-তে যেন AOSP GSI-এর মতো একই ফাইল তালিকা থাকে।

এই পর্যায়ে OEM GSI-তে অতিরিক্ত ফাইল থাকতে পারে না, তাই OEM-এর নিজস্ব ফাইলগুলো system_ext বা product পার্টিশনে সরিয়ে নিন।

চিত্র ৪। যোগ করা ফাইলগুলো OEM GSI থেকে বাইরে সরিয়ে নিন।

ধাপ ৩: OEM GSI-তে পরিবর্তিত ফাইল সীমিত করার জন্য একটি অনুমতি তালিকা (allowlist) নির্ধারণ করুন।

পরিবর্তিত ফাইলগুলি পরীক্ষা করার জন্য, OEM-রা ` compare_images টুলটি ব্যবহার করতে পারেন এবং AOSP GSI-এর সাথে OEM GSI-এর তুলনা করতে পারেন। generic_system_* AOSP লাঞ্চ টার্গেট থেকে AOSP GSI সংগ্রহ করুন।

allowlist প্যারামিটার সহ compare_images টুলটি পর্যায়ক্রমে চালানোর মাধ্যমে, আপনি অনুমোদিত তালিকার বাইরের পার্থক্যগুলো পর্যবেক্ষণ করতে পারেন। এটি OEM GSI-তে অতিরিক্ত পরিবর্তন প্রতিরোধ করে।

চিত্র ৫। OEM GSI-তে পরিবর্তিত ফাইলের তালিকা কমাতে allowlist নির্ধারণ করুন।

ধাপ ৪: OEM GSI-তে AOSP GSI-এর মতো একই বাইনারি রাখুন।

অ্যালাওলিস্ট পরিমার্জন করার মাধ্যমে OEM-রা তাদের নিজস্ব পণ্যের জন্য সিস্টেম ইমেজ হিসেবে AOSP GSI ব্যবহার করতে পারে। অ্যালাওলিস্ট পরিমার্জন করার জন্য, OEM-রা হয় OEM GSI-তে তাদের পরিবর্তনগুলো বর্জন করতে পারে, অথবা তাদের পরিবর্তনগুলো AOSP-তে আপস্ট্রিম করতে পারে, যাতে AOSP GSI-তে তাদের পরিবর্তনগুলো অন্তর্ভুক্ত থাকে।

চিত্র ৬। OEM GSI-কে AOSP GSI-এর বাইনারিগুলোর অনুরূপ বাইনারি প্রদান করুন।

এসএসআই-এর সংজ্ঞা দিন

OEM-রা তাদের SSI নির্ধারণ করতে নিম্নলিখিত নির্দেশিকা ব্যবহার করতে পারেন।

বিল্ড করার সময় /system পার্টিশনকে সুরক্ষিত করুন

/system পার্টিশনে কোনো পণ্য-নির্দিষ্ট পরিবর্তন এড়াতে এবং OEM GSI সংজ্ঞায়িত করতে, OEM-রা require-artifacts-in-path নামক একটি মেকফাইল ম্যাক্রো ব্যবহার করতে পারে, যা ম্যাক্রোটি কল করার পরে সিস্টেম মডিউলের কোনো ঘোষণা প্রতিরোধ করে। ধাপ ১: মেকফাইল তৈরি করুন এবং আর্টিফ্যাক্ট পাথ চেক সক্ষম করুন -এ উদাহরণটি দেখুন।

OEM-রা /system পার্টিশনে সাময়িকভাবে পণ্য-নির্দিষ্ট মডিউল ইনস্টল করার অনুমতি দেওয়ার জন্য একটি তালিকা নির্ধারণ করতে পারে। তবে, OEM-এর সমস্ত পণ্যের জন্য OEM GSI-কে সাধারণ করতে তালিকাটি অবশ্যই খালি থাকতে হবে। এই প্রক্রিয়াটি OEM GSI নির্ধারণ করার জন্য এবং এটি AOSP GSI-এর ধাপগুলো থেকে স্বাধীন হতে পারে।

/system_ext পার্টিশনটিকে সাধারণ করুন

/system_ext পার্টিশনটি ডিভাইসভেদে ভিন্ন হতে পারে, কারণ এতে ডিভাইস-নির্দিষ্ট, সিস্টেমের সাথে যুক্ত মডিউল থাকতে পারে। যেহেতু SSI-টি /system এবং /system_ext পার্টিশন নিয়ে গঠিত, তাই /system_ext পার্টিশনের পার্থক্যগুলো OEM-দের একটি SSI নির্ধারণ করতে বাধা দেয়। OEM-রা তাদের নিজস্ব SSI রাখতে পারে এবং যেকোনো পার্থক্য দূর করে ও /system_ext পার্টিশনটিকে সাধারণ করে তোলার মাধ্যমে সেই SSI-টি একাধিক ডিভাইসের মধ্যে শেয়ার করতে পারে।

এই বিভাগে /system_ext পার্টিশনটিকে কমন করার জন্য সুপারিশ দেওয়া হয়েছে।

সিস্টেম পার্টিশনে লুকানো এপিআইগুলো উন্মোচন করুন

অনেক প্রোডাক্ট-নির্দিষ্ট অ্যাপ প্রোডাক্ট পার্টিশনে ইনস্টল করা যায় না, কারণ সেগুলোতে হিডেন এপিআই (hidden API) ব্যবহৃত হয়, যা প্রোডাক্ট পার্টিশনে নিষিদ্ধ। ডিভাইস-নির্দিষ্ট অ্যাপগুলোকে প্রোডাক্ট পার্টিশনে সরাতে হলে, সেগুলোর হিডেন এপিআই-এর ব্যবহার বন্ধ করুন।

অ্যাপগুলো থেকে হিডেন এপিআই (hidden APIs) সরানোর সবচেয়ে ভালো উপায় হলো সেগুলোর পরিবর্তে বিকল্প পাবলিক বা সিস্টেম এপিআই খুঁজে বের করা। যদি হিডেন এপিআইগুলোর পরিবর্তে কোনো এপিআই না থাকে, তবে ওইএম (OEM)-রা তাদের ডিভাইসের জন্য নতুন সিস্টেম এপিআই সংজ্ঞায়িত করতে এওএসপি (AOSP)-তে অবদান রাখতে পারে।

বিকল্পভাবে, OEM-রা /system_ext পার্টিশনে তাদের নিজস্ব জাভা SDK লাইব্রেরি তৈরি করে কাস্টম API সংজ্ঞায়িত করতে পারে। এই লাইব্রেরিটি সিস্টেম পার্টিশনের লুকানো API ব্যবহার করতে পারে এবং প্রোডাক্ট বা ভেন্ডর পার্টিশনের অ্যাপগুলোকে সেই API সরবরাহ করতে পারে। ব্যাকওয়ার্ড কম্প্যাটিবিলিটির জন্য OEM-দের অবশ্যই প্রোডাক্ট-ফেসিং API-গুলো ফ্রিজ করতে হবে।

SKU-নির্দিষ্ট অ্যাপ নিষ্ক্রিয়করণ প্রতিস্থাপন করুন

অ্যান্ড্রয়েড ১৬ ফ্রেমওয়ার্ক রিসোর্স ওভারলে ব্যবহার করে হার্ডওয়্যার SKU-এর উপর ভিত্তি করে বেছে বেছে APK নিষ্ক্রিয় করার পুরোনো প্রক্রিয়াটি ( config_disableApksUnlessMatchedSku_apk_list এবং config_disableApkUnlessMatchedSku_skus_list ) অপ্রচলিত ঘোষণা করেছে এবং সরিয়ে দিয়েছে। বিস্তারিত জানতে, aosp/3444399 দেখুন।

এর প্রস্তাবিত বিকল্প হলো SKU-নির্দিষ্ট ডিরেক্টরিগুলোর মধ্যে install-in-user-type সিস্টেম কনফিগারেশন ব্যবহার করা। এই পদ্ধতিটি ইনস্টলেশন-পরবর্তী সময়ে শুধু নিষ্ক্রিয় করার পরিবর্তে, একটি নির্দিষ্ট SKU-এর যেকোনো ব্যবহারকারীর জন্য প্যাকেজটি ইনস্টল হওয়া প্রতিরোধ করে।

1. আপনার সিস্টেম ইমেজে থাকা সমস্ত SKU-এর জন্য সম্ভাব্য সকল অ্যাপের সুপারসেট, অর্থাৎ সমস্ত APK-কে ইমেজের মধ্যে অন্তর্ভুক্ত করুন, সাধারণত /product পার্টিশনে।

2. নিশ্চিত করুন যে ro.boot.hardware.sku সিস্টেম প্রপার্টিতে ডিভাইস SKU সঠিকভাবে সেট করা আছে (যা সিস্টেম বুট করার সময় ডিভাইস SKU শনাক্ত করতে ব্যবহার করে)।

3. sku_<SKU_NAME> নামকরণের রীতি ব্যবহার করে /product/etc/sysconfig/ এর অধীনে SKU-নির্দিষ্ট sysconfig সাবডিরেক্টরি তৈরি করুন। সিস্টেম স্বয়ংক্রিয়ভাবে সেই ডিরেক্টরি থেকে কনফিগারেশন লোড করে যা ro.boot.hardware.sku প্রপার্টির সাথে মেলে। উদাহরণ পাথ: /product/etc/sysconfig/sku_basic_model/ ।

4. অ্যাপ ইনস্টলেশন প্রতিরোধ কনফিগার করুন। SKU-নির্দিষ্ট ডিরেক্টরির ভিতরে, একটি XML কনফিগারেশন ফাইল তৈরি করুন (উদাহরণস্বরূপ, disabled_apps.xml ) এবং নির্দিষ্ট প্যাকেজ বাদ দিতে <do-not-install-in> ট্যাগটি ব্যবহার করুন।

XML উদাহরণ ( /product/etc/sysconfig/sku_basic_model/disabled_apps.xml ):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

এখানে পদ্ধতি দুটির একটি তুলনা দেওয়া হলো:

যেসব ক্ষেত্রে আরও সূক্ষ্ম নিয়ন্ত্রণের প্রয়োজন হয় (যেমন, এমন কোনো অ্যাপ নিষ্ক্রিয় করা যা সাধারণত সমস্ত SKU-তে ডিফল্টরূপে ইনস্টল করা থাকে), Android sysconfig-এ disabled-in-sku এবং enabled-in-sku-override ট্যাগও সমর্থন করে:

• <disabled-in-sku package="com.example.app" /> অ্যাপটিকে বিশ্বব্যাপী নিষ্ক্রিয় করে।

• <enabled-in-sku-override package="com.example.app" /> সংশ্লিষ্ট sku_<name> ডিরেক্টরিতে রাখলে একটি নির্দিষ্ট SKU-এর জন্য অ্যাপটিকে পুনরায় সক্রিয় করে।

স্ট্যাটিক রিসোর্স ওভারলে ব্যবহার না করে RRO সংজ্ঞায়িত করুন।

একটি স্ট্যাটিক রিসোর্স ওভারলে ওভারলে করা প্যাকেজগুলোকে নিয়ন্ত্রণ করে। তবে, এটি একটি SSI নির্ধারণে বাধা সৃষ্টি করতে পারে, তাই নিশ্চিত করুন যে RRO-এর জন্য প্রোপার্টিগুলো চালু এবং সঠিকভাবে সেট করা আছে। প্রোপার্টিগুলো নিম্নরূপে সেট করার মাধ্যমে, OEM-রা স্বয়ংক্রিয়ভাবে তৈরি হওয়া সমস্ত ওভারলেকে RRO হিসেবে রাখতে পারেন।

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

যদি বিস্তারিত কনফিগারেশনের প্রয়োজন হয়, তবে স্বয়ংক্রিয়ভাবে তৈরি হওয়া RRO-এর উপর নির্ভর না করে ম্যানুয়ালি একটি RRO নির্ধারণ করুন। বিস্তারিত তথ্যের জন্য, "রানটাইমে একটি অ্যাপের রিসোর্সের মান পরিবর্তন করুন" দেখুন। OEM-রা android:requiredSystemPropertyName এবং android:requiredSystemPropertyValue অ্যাট্রিবিউট ব্যবহার করে সিস্টেম প্রোপার্টির উপর নির্ভরশীল শর্তসাপেক্ষ RRO-ও নির্ধারণ করতে পারে।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী (FAQ)

এসএসআই (SSI) সম্পর্কে প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী নিচে দেওয়া হলো।

আমি কি একাধিক এসএসআই নির্ধারণ করতে পারি?

এটি ডিভাইসগুলোর (বা ডিভাইস গ্রুপের) সাধারণ বৈশিষ্ট্য এবং বৈশিষ্ট্যের উপর নির্ভর করে। OEM-রা system_ext পার্টিশনটিকে সাধারণ করার চেষ্টা করতে পারে, যেমনটি "Make the system_ext partition common" অংশে বর্ণনা করা হয়েছে। যদি একটি ডিভাইস গ্রুপের মধ্যে অনেক পার্থক্য থাকে, তাহলে একাধিক SSI সংজ্ঞায়িত করা ভালো।

আমি কি generic_system.mk থেকে এমন মডিউলগুলো সরিয়ে ফেলতে পারি যেগুলো আমার ইমপ্লিমেন্টেশনের সাথে সাংঘর্ষিক?

না। GSI-এর একটি ন্যূনতম সংখ্যক বুটেবল এবং টেস্টেবল মডিউল রয়েছে। যদি আপনার মনে হয় কোনো মডিউল অপরিহার্য নয়, তাহলে generic_system.mk ফাইলটি আপডেট করার জন্য একটি বাগ রিপোর্ট করুন ।