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

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

ব্যাকগ্রাউন্ড

Android ওপেন সোর্স প্রজেক্ট (AOSP) ফ্রেমওয়ার্ক Mainline আর্কিটেকচার মেনে চলে যাতে পুরনো ভেন্ডর ইমপ্লিমেন্টেশনের সাথে ব্যাকওয়ার্ড কম্প্যাটিবিলিটি বজায় রাখা যায়। যেমন, Android 10 AOSP সোর্স থেকে তৈরি করা জেনেরিক সিস্টেম ইমেজ (GSI) Android 8 বা তার পরবর্তী ভার্সন দ্বারা পরিচালিত যেকোনও Treble-কমপ্লায়েন্ট ডিভাইসে রান করতে পারে।

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

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

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

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

SSI-এর সংক্ষিপ্ত বিবরণ

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

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

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

প্রোডাক্ট-নির্দিষ্ট কম্পোনেন্টকে প্রোডাক্ট পার্টিশনে আলাদা করার মূল ধারণাটি, Mainline-এর SoC-নির্দিষ্ট কম্পোনেন্টকে ভেন্ডর পার্টিশনে আলাদা করার মতো। প্রোডাক্ট ইন্টারফেস (VINTF-এর মতো) SSI ও প্রোডাক্ট পার্টিশনের মধ্যে যোগাযোগ করতে দেয়। SSI-এর ক্ষেত্রে, কম্পোনেন্ট শব্দটি সব রিসোর্স, বাইনারি, টেক্সট ও লাইব্রেরিকে বর্ণনা করে যেগুলি পার্টিশন হয়ে যাওয়া ছবিতে ইনস্টল করা হয়।

SSI-এর আশেপাশে পার্টিশন

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

ছবি ১. SSI-এর আশেপাশে পার্টিশন ও ইন্টারফেস।

ছবি ও পার্টিশন

এই বিভাগে দেওয়া তথ্য ইমেজ ও পার্টিশন শব্দ দুটির মধ্যে পার্থক্য বোঝায়।

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

ছবি ১-এর বিভাগগুলি নিচে উল্লেখ করা সংজ্ঞা অনুযায়ী নির্ধারিত হয়:

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

• প্রোডাক্টের ছবি: প্রোডাক্ট বা ডিভাইস-নির্দিষ্ট কম্পোনেন্টের একটি সংগ্রহ যা Android OS-এ OEM কাস্টমাইজেশন ও এক্সটেনশনকে উপস্থাপন করে। /vendor পার্টিশনে SoC-নির্দিষ্ট কম্পোনেন্ট রাখুন। এছাড়াও, SoC ভেন্ডররা SoC-এর সাথে সম্পর্কিত নয় এমন উপযুক্ত কম্পোনেন্টগুলির জন্য /product পার্টিশন ব্যবহার করতে পারেন। যেমন, কোনও SoC ভেন্ডর যদি তাদের OEM গ্রাহকদের SoC-ইন্ডিপেন্ডেন্ট কম্পোনেন্ট প্রদান করে (যা প্রোডাক্টের সাথে শিপ করার জন্য ঐচ্ছিক), তাহলে 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 কল করতে পারে।

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

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

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

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

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

SSI-এর আশেপাশে ভেন্ডর ও প্রোডাক্টের ছবির জন্য দুটি প্রধান ইন্টারফেস রয়েছে:

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

  • HIDL (Passthrough HAL শুধুমাত্র system এবং system_ext মডিউলের জন্য উপলভ্য)
  • স্টেবল AIDL
  • কনফিগারেশন
    • সিস্টেম প্রপার্টি API
    • কনফিগারেশন ফাইল স্কিমা API
  • ভেন্ডর নেটিভ ডেভেলপমেন্ট কিট (VNDK)
  • Android SDK API
  • Java SDK লাইব্রেরি

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

SSI চালু করা

Android 11 ও তার পরবর্তী যেকোনও ভার্সনে SSI কীভাবে কাজ করে তা এই বিভাগে ব্যাখ্যা করা হয়েছে।

কম্পোনেন্ট আনবান্ডেল করা

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

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

প্রোডাক্ট ইন্টারফেস এনফোর্স করুন

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

GSI-ভিত্তিক SSI-এর জন্য সাজেস্ট করা ধাপ

ছবি ২. GSI-ভিত্তিক SSI-এর জন্য সাজেস্ট করা পার্টিশন।

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

এছাড়াও, OEM-রা তাদের SSI তৈরি করতে GSI ব্যবহার করতে পারে। ছবি ও পার্টিশন বিভাগে ব্যাখ্যা করা হয়েছে, SSI-তে AOSP-এর মাধ্যমে নির্ধারিত কম্পোনেন্ট ও OEM-এর মাধ্যমে নির্ধারিত কম্পোনেন্টের জন্য system_ext ছবি থাকে। GSI যখন system ইমেজ হিসেবে ব্যবহার করা হয়, তখন OEM আপগ্রেড করার জন্য system_ext ইমেজে ফোকাস করতে পারে।

AOSP বা প্রায়-AOSP সিস্টেম ইমেজ ব্যবহার করার সময়, এই বিভাগটি OEM-দের /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-তে পরিবর্তিত ফাইল সীমিত করতে একটি অনুমোদিত তালিকা নির্ধারণ করুন

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

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

ছবি ৫. OEM GSI-তে পরিবর্তিত ফাইলের তালিকা কমাতে, অনুমোদিত তালিকা নির্ধারণ করুন।

ধাপ ৪: OEM GSI-এর বাইনারি যেন AOSP GSI-এর মতো হয় তা নিশ্চিত করুন

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

ছবি ৬. OEM GSI-এর বাইনারি যেন AOSP GSI-এর মতো হয় তা নিশ্চিত করুন।

SSI-এর সংজ্ঞা দাও

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

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

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

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 পার্টিশন সাধারণ করার জন্য সাজেশন দেওয়া হয়েছে।

সিস্টেম পার্টিশনে লুকানো API প্রকাশ করুন

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

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

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

SKU-নির্দিষ্ট অ্যাপ বন্ধ করা সংক্রান্ত পরিবর্তন

Android 16, বেছে বেছে APK বন্ধ করার জন্য লেগ্যাসি মেকানিজম বন্ধ করে দিয়েছে এবং সরিয়ে দিয়েছে হার্ডওয়্যার SKU-এর উপর ভিত্তি করে ফ্রেমওয়ার্ক রিসোর্স ওভারলে ব্যবহার করে (config_disableApksUnlessMatchedSku_apk_list এবং config_disableApkUnlessMatchedSku_skus_list)। বিস্তারিত জানতে, aosp/3444399 দেখুন।

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

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

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

3. /product/etc/sysconfig/ এর অধীনে SKU-নির্দিষ্ট sysconfig সাবডাইরেক্টরি তৈরি করুন sku_<SKU_NAME>। সিস্টেম অটোমেটিক সেই ডিরেক্টরি থেকে কনফিগারেশন লোড করে যা 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-এর জন্য অ্যাপটি আবার চালু করে যখন এটি সংশ্লিষ্ট sku_<name> ডিরেক্টরিতে রাখা হয়।

স্ট্যাটিক রিসোর্স ওভারলে ব্যবহার না করে RRO নির্ধারণ করা

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

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

SSI সম্পর্কে প্রায়শই জিজ্ঞাসিত প্রশ্ন নিচে দেওয়া হল।

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

এটি ডিভাইসের (বা ডিভাইস গ্রুপের) সাধারণতা ও বৈশিষ্ট্যের উপর নির্ভর করে। OEM system_ext পার্টিশনকে কমন করার চেষ্টা করতে পারে, যেমনটি system_ext পার্টিশনকে কমন করুন লিঙ্কে বর্ণনা করা হয়েছে। ডিভাইস গ্রুপে অনেক পার্থক্য থাকলে, একাধিক SSI নির্ধারণ করাই ভাল।

আমার ইমপ্লিমেন্টেশনের সাথে কনফ্লিক্ট করে এমন মডিউল কি আমি generic_system.mk থেকে সরাতে পারি?

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