অ্যান্ড্রয়েড শেয়ার্ড সিস্টেম ইমেজ

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

পটভূমি

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

প্রেরণা

AOSP-এ প্রকাশিত ফ্রেমওয়ার্ক কোডটি ট্রেবল আর্কিটেকচারের সাথে সঙ্গতিপূর্ণ হয়েছে এবং পুরানো বিক্রেতা বাস্তবায়নের সাথে পশ্চাদমুখী সামঞ্জস্য বজায় রেখেছে। উদাহরণস্বরূপ, অ্যান্ড্রয়েড 10 এওএসপি উত্স থেকে তৈরি একটি জেনেরিক সিস্টেম ইমেজ অ্যান্ড্রয়েড 8 বা উচ্চতর সংস্করণে চলমান যেকোনও ট্রেবল-সম্মত ডিভাইসে চলতে পারে। অ্যান্ড্রয়েডের যে সংস্করণটি ভোক্তাদের ডিভাইসে পাঠানো হয় তা SoC বিক্রেতা এবং OEM দ্বারা পরিবর্তিত হয়। ( একটি অ্যান্ড্রয়েড রিলিজের জীবন দেখুন।) ফ্রেমওয়ার্কে করা এই পরিবর্তন এবং এক্সটেনশনগুলি পশ্চাদপদ সামঞ্জস্য বজায় রাখার জন্য লেখা হয়নি, যা একটি OS আপগ্রেডে জটিলতা এবং উচ্চ খরচে অনুবাদ করেছে৷ ডিভাইস-নির্দিষ্ট পরিবর্তন এবং পরিবর্তনগুলি একটি Android OS সংস্করণ আপগ্রেড করার খরচ এবং জটিলতা যোগ করে।

অ্যান্ড্রয়েড 11-এর আগে কোনও স্পষ্ট আর্কিটেকচার ছিল না যা অংশীদারদের Android OS ফ্রেমওয়ার্কে মডুলার এক্সটেনশন তৈরি করতে সক্ষম করেছিল। এই দস্তাবেজটি একটি SSI তৈরি করতে SoC বিক্রেতা এবং OEMগুলি যে পদক্ষেপগুলি নিতে পারে তার বর্ণনা দেয়৷ এর অর্থ হল একটি ছবি, একাধিক ডিভাইস জুড়ে পুনঃব্যবহারের জন্য, বিক্রেতা বাস্তবায়নের সাথে পিছিয়ে থাকা সামঞ্জস্য বজায় রাখার জন্য এবং Android OS আপগ্রেডের জটিলতা এবং খরচে উল্লেখযোগ্য হ্রাস প্রদানের জন্য Android OS ফ্রেমওয়ার্ক উত্স থেকে নির্মিত৷ একটি SSI তৈরি করার জন্য আপনার প্রয়োজন নির্দিষ্ট ধাপগুলির জন্য, GSI-ভিত্তিক SSI বিভাগের জন্য প্রস্তাবিত পদক্ষেপগুলি দেখুন, এবং নোট করুন যে আপনাকে চারটি ধাপ ব্যবহার করতে হবে না। আপনি কোন পদক্ষেপগুলি চয়ন করেন (কেবলমাত্র ধাপ 1, উদাহরণস্বরূপ) আপনার বাস্তবায়নের উপর নির্ভর করে।

SSI ওভারভিউ

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

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

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

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

SSI এর চারপাশে পার্টিশন

চিত্র 1 SSI-এর চারপাশে পার্টিশন দেখায়, এবং ইন্টারফেসের উপর পার্টিশন এবং নীতিগুলি জুড়ে সংস্করণযুক্ত ইন্টারফেসগুলি দেখায়। এই বিভাগে প্রতিটি পার্টিশন এবং ইন্টারফেস বিশদভাবে ব্যাখ্যা করা হয়েছে।

Partitions and interfaces around SSI block diagram

চিত্র 1. SSI এর চারপাশে পার্টিশন এবং ইন্টারফেস

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

এই বিভাগের তথ্য চিত্র এবং পার্টিশন শব্দগুলির মধ্যে পার্থক্য করে।

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

চিত্র 1 এর বিভাগগুলি নিম্নরূপ সংজ্ঞায়িত করা হয়েছে:

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

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

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

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

  • বিক্রেতা : SoC-নির্দিষ্ট উপাদানগুলির একটি সংগ্রহ।

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

ইমেজ মধ্যে ইন্টারফেস

বিক্রেতা এবং পণ্যের চিত্রগুলির জন্য দুটি প্রধান ইন্টারফেস SSI এর চারপাশে বিদ্যমান:

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

    • HIDL (পাসথ্রু HAL শুধুমাত্র system এবং system_ext মডিউলের জন্য উপলব্ধ)
    • স্থিতিশীল এআইডিএল
    • কনফিগারেশন
      • সিস্টেম বৈশিষ্ট্য API
      • কনফিগ ফাইল স্কিমা API
    • ভিএনডিকে
    • Android SDK APIs
    • জাভা SDK লাইব্রেরি

  • প্রোডাক্ট ইন্টারফেস : প্রোডাক্ট ইন্টারফেস হল SSI এবং প্রোডাক্ট ইমেজের মধ্যে ইন্টারফেস। একটি স্থিতিশীল ইন্টারফেস সংজ্ঞায়িত করা একটি SSI-তে সিস্টেম উপাদান থেকে পণ্য উপাদানগুলিকে ডিকপল করে। পণ্য ইন্টারফেসের জন্য VINTF এর মতো একই স্থিতিশীল ইন্টারফেস প্রয়োজন। যাইহোক, শুধুমাত্র VNDK এবং Android SDK APIগুলি Android 11 (এবং উচ্চতর) দিয়ে লঞ্চ হওয়া ডিভাইসগুলির জন্য প্রয়োগ করা হয়।

Android 11 এ SSI সক্ষম করা হচ্ছে

এই বিভাগটি ব্যাখ্যা করে যে Android 11-এ SSI সমর্থন করার জন্য নতুন বৈশিষ্ট্যগুলি কীভাবে ব্যবহার করতে হয়৷

/system_ext পার্টিশন

/system_ext পার্টিশনটি একটি ঐচ্ছিক পার্টিশন হিসাবে Android 11-এ চালু করা হয়েছিল। (এটি নন-AOSP উপাদানগুলির জন্য জায়গা যা /system পার্টিশনে AOSP-সংজ্ঞায়িত উপাদানগুলির সাথে শক্ত সংযোগ রয়েছে।) /system_ext পার্টিশনটিকে /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 ইমেজে আপগ্রেড প্রচেষ্টা ফোকাস করতে পারেন।

/system এবং /system_ext পার্টিশন থেকে /product পার্টিশনে কম্পোনেন্ট আনবান্ড করা

Android 9 একটি /product পার্টিশন চালু করেছে যা /system পার্টিশনের সাথে মিলিত হয়েছে। /product পার্টিশনের মডিউলগুলি কোনো সীমাবদ্ধতা ছাড়াই সিস্টেম রিসোর্স ব্যবহার করে এবং এর বিপরীতে। Android 10-এ SSI সম্ভব করতে, পণ্যের উপাদানগুলিকে /system_ext এবং /product পার্টিশনে বিভক্ত করা হয়েছে। /system_ext পার্টিশনকে সিস্টেমের উপাদানগুলি ব্যবহার করার বিধিনিষেধ মেনে চলতে হবে না যা /product পার্টিশন অ্যান্ড্রয়েড 9 এ করেছিল। Android 10 থেকে শুরু করে, /product পার্টিশনটিকে /system পার্টিশন থেকে আনবান্ডেড হতে হবে এবং এর থেকে স্থিতিশীল ইন্টারফেস ব্যবহার করতে হবে /system এবং /system_ext পার্টিশন।

/system_ext পার্টিশনের প্রাথমিক উদ্দেশ্য হল সিস্টেমের বৈশিষ্ট্যগুলিকে প্রসারিত করা, বান্ডিল পণ্য মডিউল ইনস্টল করার পরিবর্তে, যেমন /system_ext partition বিভাগে বর্ণিত হয়েছে। এটি করার জন্য, পণ্য-নির্দিষ্ট মডিউলগুলিকে আনবান্ডেল করুন এবং সেগুলিকে /product পার্টিশনে নিয়ে যান। পণ্য-নির্দিষ্ট মডিউলগুলিকে আনবান্ড করা ডিভাইসগুলিতে /system_ext সাধারণ করে তোলে। (আরো বিস্তারিত জানার জন্য, /system_ext পার্টিশনকে সাধারণ করা দেখুন।)

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

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

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

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

Suggested partitions for GSI-based SSI

চিত্র 2. GSI-ভিত্তিক SSI-এর জন্য প্রস্তাবিত পার্টিশন

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

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

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

ধাপ 1. 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 ফাইল নিজেই পরিবর্তন করার অনুমতি দেওয়া হয় না।

Inheriting `generic_system.mk` for OEM system image

চিত্র 3. OEM এর সিস্টেম ইমেজের জন্য generic_system.mk ইনহেরিট করা হচ্ছে

ধাপ 2. OEM GSI তৈরি করা AOSP GSI-এর সাথে ফাইলগুলির একই তালিকা রয়েছে৷

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

Moving added files out of the OEM GSI

চিত্র 4. যোগ করা ফাইলগুলিকে OEM GSI থেকে সরানো হচ্ছে

ধাপ 3. OEM GSI-তে পরিবর্তিত ফাইলগুলিকে সীমাবদ্ধ করার জন্য একটি অনুমোদিত তালিকা নির্ধারণ করা

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

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

Define an allowlist to reduce the list of modified files in OEM GSI

চিত্র 5. OEM GSI-তে পরিবর্তিত ফাইলের তালিকা কমাতে একটি অনুমোদিত তালিকা নির্ধারণ করুন

ধাপ 4. OEM GSI তৈরি করা AOSP GSI-এর মত একই বাইনারি আছে

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

Make OEM GSI have the same binaries as AOSP GSI

চিত্র 6. OEM GSI তৈরি করা AOSP GSI-এর মতো একই বাইনারি রয়েছে

OEM-এর জন্য SSI সংজ্ঞায়িত করা

বিল্ড টাইমে /সিস্টেম পার্টিশন রক্ষা করুন

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

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

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

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

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

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

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

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

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

অ্যাপ্লিকেশনগুলি থেকে লুকানো APIগুলি সরানোর পছন্দের উপায় হল বিকল্প পাবলিক বা সিস্টেম APIগুলিকে প্রতিস্থাপন করার জন্য খুঁজে বের করা৷ যদি লুকানো APIগুলি প্রতিস্থাপন করার জন্য কোনো API না থাকে, তাহলে OEMগুলি তাদের ডিভাইসের জন্য নতুন সিস্টেম APIগুলি সংজ্ঞায়িত করতে AOSP-তে অবদান রাখতে পারে।

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

সমস্ত APK-এর সুপারসেট অন্তর্ভুক্ত করুন এবং প্রতিটি ডিভাইসের জন্য কিছু প্যাকেজ ইনস্টল এড়িয়ে যান

সিস্টেমের সাথে বান্ডিল করা কিছু প্যাকেজ ডিভাইস জুড়ে সাধারণ নয়। এই APK মডিউলগুলিকে পণ্য বা বিক্রেতা পার্টিশনে সরানোর জন্য আনবান্ড করা কঠিন হতে পারে। একটি অন্তর্বর্তী সমাধান হিসাবে, OEMগুলি SSI-কে সমস্ত মডিউল অন্তর্ভুক্ত করতে পারে, তারপর একটি SKU বৈশিষ্ট্য ( ro.boot.hardware.sku ) ব্যবহার করে অবাঞ্ছিতগুলিকে ফিল্টার করতে পারে৷ ফিল্টার ব্যবহার করতে, OEMগুলি ফ্রেমওয়ার্ক সংস্থানগুলিকে ওভারলে করে config_disableApkUnlessMatchedSku_skus_list এবং config_disableApksUnlessMatchedSku_apk_list ।

আরও সুনির্দিষ্ট সেটিংসের জন্য, একটি ব্রডকাস্ট রিসিভার ঘোষণা করুন যা অপ্রয়োজনীয় প্যাকেজগুলি নিষ্ক্রিয় করে। সম্প্রচার গ্রহণকারী ACTION_BOOT_COMPLETED বার্তাটি পেলে প্যাকেজটিকে নিষ্ক্রিয় করতে setApplicationEnabledSetting কল করে৷

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

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

আমি একাধিক SSI সংজ্ঞায়িত করতে পারি?

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

আমি কি একটি OEM GSI-এর জন্য generic_system.mk ( mainline_system.mk ) পরিবর্তন করতে পারি?

না। কিন্তু OEMs একটি OEM GSI-এর জন্য একটি নতুন মেকফাইল সংজ্ঞায়িত করতে পারে যা generic_system.mk ফাইলের উত্তরাধিকারী এবং পরিবর্তে নতুন মেকফাইল ব্যবহার করে। একটি উদাহরণের জন্য, পণ্য পার্টিশন ইন্টারফেস প্রয়োগ করা দেখুন।

আমি কি generic_system.mk থেকে মডিউলগুলি সরাতে পারি যা আমার বাস্তবায়নের সাথে বিরোধপূর্ণ?

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