Google কি কোনও ডিভাইসে A/B OTA ব্যবহার করেছে?
হ্যাঁ। A/B আপডেটের মার্কেটিং নাম হল সিমলেস আপডেট। Pixel এবং Pixel XL
ফোন অক্টোবর ২০১৬ থেকে A/B সহ শিপ করা হয় এবং সব Chromebook-এ A/B-এর একই
update_engine
ইমপ্লিমেন্টেশন ব্যবহার করা হয়। প্রয়োজনীয় প্ল্যাটফর্ম কোড ইমপ্লিমেন্টেশন Android 7.1 এবং
এর পরবর্তী যেকোনও ভার্সনে পাবলিক।
A/B OTA কেন আরও ভালো?
আপডেট নেওয়ার সময় A/B OTA আরও ভালো ব্যবহারকারীর অভিজ্ঞতা প্রদান করে। মাসিক নিরাপত্তা আপডেট থেকে পাওয়া পরিমাপ দেখায় যে এই ফিচারটি ইতিমধ্যেই সফল হয়েছে: মে ২০১৭ পর্যন্ত, Pixel মালিকদের ৯৫% এক মাস পরে লেটেস্ট নিরাপত্তা আপডেট রান করাচ্ছেন, যেখানে Nexus ব্যবহারকারীদের মধ্যে ৮৭% এটি করছেন। এছাড়াও, Pixel ব্যবহারকারীরা Nexus ব্যবহারকারীদের তুলনায় শীঘ্রই আপডেট করেন। OTA চলাকালীন ব্লক আপডেট করা না গেলে, ডিভাইস আর বুট হয় না। নতুন সিস্টেম ইমেজ সফলভাবে বুট না হওয়া পর্যন্ত, Android আগের সিস্টেম ইমেজে ফিরে যাওয়ার ক্ষমতা ধরে রাখে।
system_other কী?
অ্যাপ্লিকেশন .apk ফাইলে স্টোর করা হয়, যা আসলে ZIP আর্কাইভ। প্রতিটি .apk ফাইলের মধ্যে এক বা একাধিক .dex ফাইল থাকে যাতে পোর্টেবল ডালভিক বাইটকোড থাকে। .odex ফাইল (অপ্টিমাইজ করা .dex) .apk ফাইল থেকে আলাদা থাকে এবং এতে ডিভাইস-নির্দিষ্ট মেশিন কোড থাকতে পারে। .odex ফাইল উপলভ্য থাকলে, Android, সময়ের আগেই কম্পাইল করা স্পিডে অ্যাপ্লিকেশন চালাতে পারে এবং প্রতিবার অ্যাপ্লিকেশন চালু করার সময় কোড কম্পাইল করার জন্য অপেক্ষা করতে হয় না। একটি .odex ফাইল কঠোরভাবে প্রয়োজনীয় নয়: Android আসলে সরাসরি ব্যাখ্যা বা জাস্ট-ইন-টাইম (JIT) কম্পাইলেশনের মাধ্যমে .dex কোড চালাতে পারে, তবে স্পেস উপলভ্য থাকলে .odex ফাইল লঞ্চ স্পিড এবং রান-টাইম স্পিডের সেরা কম্বিনেশন প্রদান করে।
উদাহরণ: Nexus 6P-এর ইনস্টল করা-files.txt-এর জন্য, Android 7.1-এর সাথে মোট সিস্টেম ইমেজ সাইজ ২৬২৮MiB (২৭৫৫৭৯২৮৩৬ বাইট), ফাইল ধরন অনুযায়ী সামগ্রিক সিস্টেম ইমেজ সাইজের সবচেয়ে বড় কন্ট্রিবিউটরদের ব্রেকডাউন নিচে দেওয়া হল:
| .odex | ১৩৯১৭৭০৩১২ বাইট | ৫০.৫% |
| .apk | ৮৪৬৮৭৮২৫৯ বাইট | ৩০.৭% |
| .so (নেটিভ C/C++ কোড) | ২০২১৬২৪৭৯ বাইট | ৭.৩% |
| .oat ফাইল/.art ছবি | ১৬৩৮৯২১৮৮ বাইট | ৫.৯% |
| ফন্ট | ৩৮৯৫২৩৬১ বাইট | ১.৪% |
| icu লোকেল ডেটা | ২৭৪৬৮৬৮৭ বাইট | ০.৯% |
অন্যান্য ডিভাইসের ক্ষেত্রেও এই সংখ্যাগুলি একই রকম, তাই Nexus/Pixel ডিভাইসে, .odex ফাইলগুলি
সিস্টেম পার্টিশনের প্রায় অর্ধেক জায়গা নেয়। এর অর্থ হল, আমরা ext4 ব্যবহার করা চালিয়ে যেতে পারি, তবে ফ্যাক্টরিতে B পার্টিশনে .odex ফাইল লিখতে হবে এবং তারপর প্রথমবার বুট করার সময় সেগুলি /data-এ কপি করতে হবে। ext4 A/B-এর সাথে ব্যবহৃত আসল স্টোরেজ SquashFS A/B-এর মতো একই রকম, কারণ আমরা যদি
SquashFS ব্যবহার করতাম, তাহলে আমরা system_b-এর পরিবর্তে system_a-তে
প্রিঅপটেড .odex ফাইল শিপ করতাম।
/data-তে .odex ফাইল কপি করার অর্থ কি /system-এ সেভ করা স্পেস /data-তে আর নেই?
ঠিক তা নয়। Pixel-এ, .odex ফাইলের মাধ্যমে নেওয়া বেশিরভাগ স্পেস অ্যাপের জন্য, যা সাধারণত
/data-এ থাকে। এইসব অ্যাপ Google Play আপডেট নেয়, তাই সিস্টেম ইমেজে .apk এবং .odex ফাইল
ডিভাইসের লাইফটাইমের বেশিরভাগ সময় অব্যবহৃত থাকে। এই ধরনের ফাইল সম্পূর্ণভাবে বাদ দেওয়া
যায় এবং ব্যবহারকারী যখন কোনও অ্যাপ ব্যবহার করেন, তখন প্রোফাইল-পরিচালিত ছোট .odex ফাইল দিয়ে সেগুলি
প্রতিস্থাপন করা যায় (এর ফলে ব্যবহারকারী ব্যবহার করেন না এমন অ্যাপের জন্য কোনও জায়গার প্রয়োজন হয় না)। আরও বিবরণের জন্য, Google
I/O 2016-এর The Evolution of Art শীর্ষক আলোচনা দেখুন।
কয়েকটি গুরুত্বপূর্ণ কারণে তুলনা করা কঠিন:
-
Google Play-এর মাধ্যমে আপডেট করা অ্যাপের .odex ফাইল সবসময়
/data-এ থাকে, প্রথম আপডেট পাওয়ার সাথে সাথেই এটি সেখানে চলে যায়। - ব্যবহারকারী যেসব অ্যাপ চালান না সেগুলির জন্য .odex ফাইলের কোনও প্রয়োজন নেই।
- প্রোফাইল-চালিত কম্পাইলেশন, সময়ের আগে কম্পাইলেশনের চেয়ে ছোট .odex ফাইল তৈরি করে (কারণ আগেরটি শুধুমাত্র পারফর্ম্যান্স-ক্রিটিক্যাল কোড অপ্টিমাইজ করে)।
OEM-এর জন্য উপলভ্য টিউনিং বিকল্পের বিবরণ পেতে, দেখুন ART কনফিগার করা।
/data-তে .odex ফাইলের দুটি কপি নেই?
এটি একটু বেশি জটিল ... নতুন সিস্টেম ইমেজ লেখা হয়ে যাওয়ার পরে, নতুন .odex ফাইল তৈরি করতে,
dex2oat-এর নতুন ভার্সন নতুন .dex ফাইলের বিরুদ্ধে চালানো হয়। পুরনো সিস্টেম এখনও চলছে বলে এটি
ঘটে, তাই পুরনো ও নতুন .odex ফাইল /data-এ একই সাথে
থাকে।
OtaDexoptService-এর (frameworks/base/+/android17-release/services/core/java/com/android/server/pm/OtaDexoptService.java) কোড প্রতিটি প্যাকেজ অপ্টিমাইজ করার আগে getAvailableSpace কল করে যাতে বেশি পূরণ না হয়ে যায়
/data। মনে রাখবেন, এখানে উপলভ্য এখনও রক্ষণশীল: এটি হল সিস্টেমের স্বাভাবিক কম স্পেস থ্রেশহোল্ডে পৌঁছানোর
আগে বাকি থাকা স্পেসের পরিমাণ (শতাংশ এবং বাইট গণনা, উভয় হিসাবেই পরিমাপ করা হয়)। তাই /data ভর্তি হয়ে গেলে, প্রতিটি .odex ফাইলের
দুটি কপি থাকবে না। একই কোডে BULK_DELETE_THRESHOLD-ও আছে: ডিভাইস যদি উপলভ্য স্পেস ভর্তি করার
কাছাকাছি পৌঁছে যায় (যেমনটি উপরে বর্ণনা করা হয়েছে), তাহলে যেসব অ্যাপ ব্যবহার করা হয় না, সেগুলির .odex ফাইল
সরিয়ে দেওয়া হয়। এটি হল আরেকটি কেস যেখানে প্রতিটি .odex ফাইলের দুটি কপি নেই।
সবচেয়ে খারাপ পরিস্থিতিতে, /data সম্পূর্ণ ভর্তি হয়ে গেলে, ডিভাইসটি নতুন সিস্টেমে রিবুট না হওয়া পর্যন্ত এবং পুরনো সিস্টেমের .odex ফাইলের আর প্রয়োজন না হওয়া পর্যন্ত আপডেটটি অপেক্ষা করে।
PackageManager এটি ম্যানেজ করে: (frameworks/base/+/android17-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215)। নতুন সিস্টেম সফলভাবে বুট করার পরে, installd (frameworks/native/+/android17-release/cmds/installd/dexopt.cpp#2422) পুরনো সিস্টেমের ব্যবহার করা .odex ফাইল সরিয়ে দিতে পারে, এর ফলে ডিভাইসটি
স্টেডি স্টেটে ফিরে আসে যেখানে শুধুমাত্র একটি কপি থাকে।
তাই, /data-এ সব .odex ফাইলের দুটি কপি থাকতে পারে, তবে
(ক) এটি অস্থায়ী এবং (খ) /data-এ এমনিতেই প্রচুর খালি জায়গা থাকলে তবেই
এটি হয়। আপডেট চলাকালীন ছাড়া, শুধুমাত্র একটি কপি থাকে। এছাড়াও, ART-এর সাধারণ দৃঢ়তা সংক্রান্ত ফিচারের অংশ হিসেবে, এটি কোনওভাবেই /data-এ .odex ফাইল
পূর্ণ করবে না (কারণ এটি নন-A/B সিস্টেমেও একটি সমস্যা হবে)।
এইসব লেখা/কপি করার ফলে কি ফ্ল্যাশ মেমরি বেশি ক্ষয় হয় না?
ফ্ল্যাশের শুধুমাত্র একটি ছোট অংশ আবার লেখা হয়: সম্পূর্ণ Pixel সিস্টেম আপডেট প্রায় ২.৩ জিবি ডেটা লেখে। (অ্যাপগুলিও আবার কম্পাইল করা হয়, তবে এটি নন-A/B-এর ক্ষেত্রেও প্রযোজ্য।) প্রথাগতভাবে, ব্লক-ভিত্তিক সম্পূর্ণ ওটিএ (OTA) একই পরিমাণ ডেটা লেখে, তাই ফ্ল্যাশ ক্ষয় হওয়ার হার একই রকম হওয়া উচিত।
দুটি সিস্টেম পার্টিশন ফ্ল্যাশ করলে কি ফ্যাক্টরি ফ্ল্যাশিংয়ের সময় বেড়ে যায়?
না। সিস্টেম ইমেজ সাইজে Pixel-এর কোনও বৃদ্ধি হয়নি (এটি শুধুমাত্র দুটি পার্টিশন জুড়ে স্পেস ভাগ করেছে)।
B-তে .odex ফাইল না রাখলে কি ফ্যাক্টরি ডেটা রিসেট করার পরে রিবুট করার প্রসেস ধীরে ধীরে হয়?
হ্যাঁ। আপনি যদি সত্যিই কোনও ডিভাইস ব্যবহার করে থাকেন, OTA নিয়ে থাকেন এবং ফ্যাক্টরি ডেটা রিসেট করে থাকেন, তাহলে
প্রথম রিবুটটি অন্য সময়ের তুলনায় ধীরে হবে (Pixel XL-এ ১ মিনিট ৪০ সেকেন্ড বনাম ৪০ সেকেন্ড) কারণ
প্রথম OTA-এর পরে B থেকে .odex ফাইলগুলি চলে যাবে এবং তাই /data-এ কপি করা যাবে না। এটিই হল ট্রেড-অফ।
ফ্যাক্টরি ডেটা রিসেট করার অপারেশনটি রেগুলার বুটের তুলনায় খুব কমই করা হয়, তাই এতে কত সময় লাগছে
তা খুব একটা গুরুত্বপূর্ণ নয়। (এর ফলে, ফ্যাক্টরি থেকে ডিভাইস পাওয়া ব্যবহারকারী বা পর্যালোচকদের উপর কোনও প্রভাব পড়ে না, কারণ সেই ক্ষেত্রে B পার্টিশন উপলভ্য থাকে।) JIT কম্পাইলার ব্যবহার করার অর্থ হল, আমাদের
সবকিছু আবার কম্পাইল করতে হবে না, তাই এটি আপনি যতটা খারাপ ভাবছেন ততটা খারাপ নয়। এছাড়াও, ম্যানিফেস্টে
coreApp="true" ব্যবহার করে অ্যাপকে আগে থেকে কম্পাইলেশন প্রয়োজন হিসেবে চিহ্নিত করা
সম্ভব: (frameworks/base/+/android17-release/packages/SystemUI/AndroidManifest.xml#23)। এটি বর্তমানে system_server ব্যবহার করে কারণ নিরাপত্তার
কারণে JIT করার অনুমতি নেই।
/system-এর পরিবর্তে /data-তে .odex ফাইল রাখলে কি OTA-এর পরে রিবুট করার প্রসেস স্লো হয়ে যায় না?
না। উপরে যেমন ব্যাখ্যা করা হয়েছে, নতুন সিস্টেমের জন্য প্রয়োজনীয় ফাইল জেনারেট করতে পুরনো সিস্টেম ইমেজ এখনও রান করার সময় নতুন dex2oat রান করা হয়। সেই কাজ সম্পূর্ণ না হওয়া পর্যন্ত আপডেট উপলভ্য হয়েছে বলে বিবেচনা করা হয় না।
আমরা কি ৩২ গিগাবাইট এ/বি ডিভাইস শিপ করতে পারি (করা উচিত)? ১৬ গিবিবাইট? 8GiB?
Pixel-এ এটি ভাল কাজ করে বলে প্রমাণিত হওয়ায় ৩২GiB ভাল কাজ করে এবং ১৬GiB-এর মধ্যে ৩২০MiB মানে ২% কমে যাওয়া। একইভাবে, ৮GiB-এর মধ্যে ৩২০MiB, ৪% কমেছে। অবশ্যই, ৪ জিবি র্যামের ডিভাইসে A/B বেছে নেওয়ার সাজেশন দেওয়া হবে না, কারণ ৩২০ এমআইবি ওভারহেড হল মোট উপলভ্য স্পেসের প্রায় ১০%।
AVB2.0-এর জন্য কি A/B OTA প্রয়োজন?
না। Android যাচাই করা বুট-এর জন্য সবসময় ব্লক-ভিত্তিক আপডেট প্রয়োজন, তবে A/B আপডেট প্রয়োজন নয়।
A/B OTA-এর জন্য কি AVB2.0 প্রয়োজন?
না।
A/B OTA কি AVB2.0-এর রোলব্যাক সুরক্ষা ভেঙে দেয়?
না। এখানে কিছু বিভ্রান্তি রয়েছে কারণ A/B সিস্টেম নতুন সিস্টেম ইমেজ বুট করতে না পারলে, এটি (আপনার বুটলোডার দ্বারা নির্ধারিত কিছু সংখ্যক প্রচেষ্টার পরে) অটোমেটিক "আগের" সিস্টেম ইমেজে ফিরে যাবে। তবে, এখানে মূল বিষয় হল যে A/B-এর "আগের" অর্থে আসলে এখনও "বর্তমান" সিস্টেম ইমেজকে বোঝানো হচ্ছে। ডিভাইসটি নতুন ইমেজ বুট করার সাথে সাথেই রোলব্যাক সুরক্ষা চালু হয়ে যায় এবং নিশ্চিত করে যে আপনি আর আগের ভার্সনে ফিরে যেতে পারবেন না। কিন্তু আপনি যতক্ষণ না নতুন ইমেজটি সফলভাবে বুট করছেন, ততক্ষণ রোলব্যাক সুরক্ষা এটিকে বর্তমান সিস্টেম ইমেজ হিসেবে বিবেচনা করে না।
সিস্টেম চলাকালীন আপডেট ইনস্টল করলে, সেটি কি খুব ধীরে হয় না?
A/B নয় এমন আপডেটের ক্ষেত্রে, যত দ্রুত সম্ভব আপডেট ইনস্টল করার চেষ্টা করা হয় কারণ ব্যবহারকারী অপেক্ষা করছেন এবং আপডেট প্রয়োগ করার সময় তার ডিভাইস ব্যবহার করতে পারছেন না। A/B আপডেটের ক্ষেত্রে, বিপরীতটি সত্য; কারণ ব্যবহারকারী এখনও তার ডিভাইস ব্যবহার করছেন, যতটা সম্ভব কম প্রভাব লক্ষ্য, তাই আপডেট ইচ্ছাকৃতভাবে ধীর হয়। Java সিস্টেম আপডেট ক্লায়েন্টের লজিকের মাধ্যমে (Google-এর জন্য এটি হল GmsCore, GMS-এর প্রদান করা মূল প্যাকেজ), Android এছাড়াও এমন একটি সময় বেছে নেওয়ার চেষ্টা করে যখন ব্যবহারকারীরা তাদের ডিভাইস একেবারেই ব্যবহার করছেন না। প্ল্যাটফর্মটি আপডেট পজ/আবার চালু করার সুবিধা প্রদান করে এবং ব্যবহারকারী ডিভাইস ব্যবহার করা শুরু করলে আপডেট পজ করতে এবং ডিভাইসটি আবার আইডল থাকলে তা আবার চালু করতে ক্লায়েন্ট এটি ব্যবহার করতে পারে।
OTA নেওয়ার সময় দুটি ফেজ থাকে, যা UI-তে প্রগ্রেস বারের নিচে ২টির মধ্যে ১টি ধাপ এবং ২টির মধ্যে ২টি ধাপ হিসেবে স্পষ্টভাবে দেখানো হয়। ধাপ ১ ডেটা ব্লক লেখার সাথে সম্পর্কিত, অন্যদিকে ধাপ ২ হল .dex ফাইল প্রি-কম্পাইল করা। পারফর্ম্যান্সের উপর প্রভাবের দিক থেকে এই দুটি পর্যায় একে অপরের থেকে বেশ আলাদা। প্রথম পর্যায়ে সহজ ইনপুট/আউটপুট থাকে। এর জন্য খুব কম রিসোর্স (RAM, CPU, I/O) প্রয়োজন হয়, কারণ এটি শুধু ধীরে ধীরে ব্লক কপি করে।
দ্বিতীয় ধাপে, নতুন সিস্টেম ইমেজ প্রি-কম্পাইল করার জন্য dex2oat রান করে। এর প্রয়োজনীয়তা স্পষ্ট করে নির্ধারণ করা কঠিন কারণ এটি আসল অ্যাপ কম্পাইল করে। অবশ্যই, একটি ছোট ও সাধারণ অ্যাপের তুলনায় একটি বড় ও জটিল অ্যাপ কম্পাইল করার জন্য অনেক বেশি কাজ করতে হয়; যেখানে ফেজ ১-এ এমন কোনও ডিস্ক ব্লক নেই যা অন্যগুলির চেয়ে বড় বা বেশি জটিল।
এই প্রসেসটি সেই প্রসেসের মতোই, যখন Google Play ৫টি অ্যাপ আপডেট করা হয়েছে বিজ্ঞপ্তি দেখানোর আগে ব্যাকগ্রাউন্ডে অ্যাপ আপডেট ইনস্টল করে, যেমনটি বহু বছর ধরে করা হচ্ছে।
ব্যবহারকারী যদি সত্যিই আপডেটের জন্য অপেক্ষা করেন, তাহলে কী হবে?
GmsCore-এ বর্তমান প্রয়োগ ব্যাকগ্রাউন্ড আপডেট ও ব্যবহারকারীর দ্বারা শুরু করা আপডেটের মধ্যে পার্থক্য করে না, তবে ভবিষ্যতে তা করতে পারে। ব্যবহারকারী যদি আপডেট ইনস্টল করার জন্য স্পষ্টভাবে অনুরোধ করেন বা আপডেট প্রগ্রেস স্ক্রিন দেখেন, তাহলে আমরা ধরে নেব যে তিনি আপডেট শেষ হওয়ার জন্য অপেক্ষা করছেন এবং আপডেট করার কাজকে অগ্রাধিকার দেব।
আপডেট প্রয়োগ করা না গেলে কী হবে?
A/B নয় এমন আপডেটের ক্ষেত্রে, কোনও আপডেট প্রয়োগ করা না গেলে, ব্যবহারকারী সাধারণত ব্যবহার করা যায় না এমন ডিভাইস নিয়ে বসে থাকতেন। ব্যতিক্রম শুধু তখনই হয় যখন কোনও অ্যাপ্লিকেশন শুরু হওয়ার আগেই সমস্যা হয় (যেমন, প্যাকেজ যাচাই করা যায়নি)। A/B আপডেটের ক্ষেত্রে, কোনও আপডেট প্রয়োগ করতে না পারলে বর্তমানে রান করা সিস্টেমের উপর কোনও প্রভাব পড়ে না। পরে আবার আপডেট করার চেষ্টা করা যেতে পারে।