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

গুগল কি কোনো ডিভাইসে এ/বি ওটিএ ব্যবহার করেছে?

হ্যাঁ। A/B আপডেটের বিপণনগত নাম হলো সিমলেস আপডেট । ২০১৬ সালের অক্টোবর মাস থেকে পিক্সেল এবং পিক্সেল এক্সএল ফোনগুলোতে A/B আপডেট দেওয়া শুরু হয় এবং সমস্ত ক্রোমবুক একই update_engine ইমপ্লিমেন্টেশন ব্যবহার করে। এর জন্য প্রয়োজনীয় প্ল্যাটফর্ম কোড ইমপ্লিমেন্টেশন অ্যান্ড্রয়েড ৭.১ এবং তার পরবর্তী সংস্করণগুলোতে সর্বজনীনভাবে উপলব্ধ।

কেন A/B OTA-গুলো আরও ভালো?

আপডেট নেওয়ার ক্ষেত্রে A/B OTA একটি উন্নততর ইউজার এক্সপেরিয়েন্স প্রদান করে। মাসিক সিকিউরিটি আপডেটের পরিমাপ থেকে দেখা যায় যে এই ফিচারটি ইতোমধ্যেই সফল বলে প্রমাণিত হয়েছে: ২০১৭ সালের মে মাস পর্যন্ত, এক মাস পর ৯৫% পিক্সেল ব্যবহারকারী সর্বশেষ সিকিউরিটি আপডেট ব্যবহার করছেন, যেখানে নেক্সাস ব্যবহারকারীদের ক্ষেত্রে এই হার ৮৭%, এবং পিক্সেল ব্যবহারকারীরা নেক্সাস ব্যবহারকারীদের চেয়ে দ্রুত আপডেট করেন। OTA চলাকালীন ব্লক আপডেট করতে ব্যর্থ হলে ডিভাইসটি আর বুট না হওয়ার সমস্যা হয় না; নতুন সিস্টেম ইমেজ সফলভাবে বুট না হওয়া পর্যন্ত, অ্যান্ড্রয়েড পূর্ববর্তী কার্যকরী সিস্টেম ইমেজে ফিরে যাওয়ার ক্ষমতা ধরে রাখে।

system_other বলতে কী বোঝায়?

অ্যাপ্লিকেশনগুলো .apk ফাইলে সংরক্ষিত থাকে, যা আসলে ZIP আর্কাইভ। প্রতিটি .apk ফাইলের ভেতরে এক বা একাধিক .dex ফাইল থাকে, যেগুলোতে পোর্টেবল ডালভিক বাইটকোড থাকে। একটি .odex ফাইল (অপ্টিমাইজড .dex) .apk ফাইল থেকে আলাদাভাবে থাকে এবং এতে ডিভাইসের জন্য নির্দিষ্ট মেশিন কোড থাকতে পারে। যদি একটি .odex ফাইল উপলব্ধ থাকে, তবে অ্যান্ড্রয়েড প্রতিবার অ্যাপ্লিকেশন চালু করার সময় কোড কম্পাইল হওয়ার জন্য অপেক্ষা না করেই, আগে থেকে কম্পাইল করা গতিতে অ্যাপ্লিকেশনগুলো চালাতে পারে। একটি .odex ফাইল থাকা কঠোরভাবে আবশ্যক নয়: অ্যান্ড্রয়েড ইন্টারপ্রিটেশন বা জাস্ট-ইন-টাইম (JIT) কম্পাইলেশনের মাধ্যমে সরাসরি .dex কোড চালাতে পারে, কিন্তু জায়গা উপলব্ধ থাকলে একটি .odex ফাইল চালু হওয়ার গতি এবং চলার গতির সেরা সমন্বয় প্রদান করে।

উদাহরণ: অ্যান্ড্রয়েড ৭.১ চালিত একটি নেক্সাস ৬পি-এর installed-files.txt ফাইলের ক্ষেত্রে, যার মোট সিস্টেম ইমেজ সাইজ ২৬২৮ MiB (২৭৫৫৭৯২৮৩৬ বাইট), ফাইল টাইপ অনুযায়ী সামগ্রিক সিস্টেম ইমেজ সাইজে সবচেয়ে বেশি অবদান রাখা ফাইলগুলোর বিভাজন নিচে দেওয়া হলো:

.odex	১৩৯১৭৭০৩১২ বাইট	৫০.৫%
.apk	৮৪৬৮৭৮২৫৯ বাইট	৩০.৭%
.so (নেটিভ C/C++ কোড)	২০২১৬২৪৭৯ বাইট	৭.৩%
.oat ফাইল/.art ছবি	১৬৩৮৯২১৮৮ বাইট	৫.৯%
ফন্ট	৩৮৯৫২৩৬১ বাইট	১.৪%
আইসিইউ স্থানীয় ডেটা	২৭৪৬৮৬৮৭ বাইট	০.৯%

এই পরিসংখ্যান অন্যান্য ডিভাইসের ক্ষেত্রেও একই রকম, তাই Nexus/Pixel ডিভাইসগুলিতে, .odex ফাইলগুলি সিস্টেম পার্টিশনের প্রায় অর্ধেক জায়গা নেয়। এর মানে হল, আমরা ext4 ব্যবহার করা চালিয়ে যেতে পারতাম কিন্তু কারখানাতেই .odex ফাইলগুলিকে B পার্টিশনে লিখে দিতাম এবং তারপর প্রথম বুটে সেগুলিকে /data তে কপি করতাম। ext4 A/B-এর সাথে ব্যবহৃত প্রকৃত স্টোরেজ SquashFS A/B-এর মতোই, কারণ যদি আমরা SquashFS ব্যবহার করতাম, তাহলে আমরা আগে থেকে বেছে নেওয়া .odex ফাইলগুলি system_b-এর পরিবর্তে system_a-তে পাঠাতাম।

.odex ফাইলগুলোকে /data-তে কপি করলে কি /system-এ বাঁচানো জায়গা /data-তে নষ্ট হয়ে যায় না?

ঠিক তা নয়। পিক্সেল ডিভাইসে, .odex ফাইলগুলোর বেশিরভাগ জায়গাই অ্যাপের জন্য ব্যবহৃত হয়, যেগুলো সাধারণত /data ফোল্ডারে থাকে। এই অ্যাপগুলো গুগল প্লে থেকে আপডেট নেয়, তাই ডিভাইসের বেশিরভাগ সময় সিস্টেম ইমেজের .apk এবং .odex ফাইলগুলো অব্যবহৃত থাকে। যখন ব্যবহারকারী কোনো অ্যাপ ব্যবহার করেন, তখন এই ধরনের ফাইলগুলোকে পুরোপুরি বাদ দিয়ে সেগুলোর জায়গায় ছোট, প্রোফাইল-ভিত্তিক .odex ফাইল ব্যবহার করা যায় (ফলে যে অ্যাপগুলো ব্যবহারকারী ব্যবহার করেন না, সেগুলোর জন্য কোনো জায়গার প্রয়োজন হয় না)। বিস্তারিত জানতে, গুগল আই/ও ২০১৬-এর 'The Evolution of Art' শীর্ষক আলোচনাটি দেখুন।

কয়েকটি প্রধান কারণে এই তুলনা করা কঠিন:

• গুগল প্লে দ্বারা আপডেট করা অ্যাপগুলো প্রথম আপডেট পাওয়ার সাথে সাথেই তাদের .odex ফাইলগুলো /data ফোল্ডারে তৈরি হয়ে যায়।
• যেসব অ্যাপ ব্যবহারকারী চালান না, সেগুলোর জন্য .odex ফাইলের কোনো প্রয়োজনই নেই।
• প্রোফাইল-চালিত কম্পাইলেশন অ্যাহেড-অফ-টাইম কম্পাইলেশনের চেয়ে ছোট .odex ফাইল তৈরি করে (কারণ এটি শুধুমাত্র পারফরম্যান্সের জন্য গুরুত্বপূর্ণ কোড অপ্টিমাইজ করে)।

OEM-দের জন্য উপলব্ধ টিউনিং বিকল্পগুলির বিশদ বিবরণের জন্য, ART কনফিগার করা দেখুন।

/data-তে কি .odex ফাইলগুলোর দুটো কপি নেই?

বিষয়টা আরেকটু জটিল... নতুন সিস্টেম ইমেজটি লেখা হয়ে গেলে, নতুন .dex ফাইলগুলো তৈরি করার জন্য dex2oat-এর নতুন সংস্করণটি নতুন .dex ফাইলগুলোর ওপর চালানো হয়। এই প্রক্রিয়াটি ঘটে যখন পুরোনো সিস্টেমটি তখনও চালু থাকে, তাই পুরোনো এবং নতুন উভয় .odex ফাইলই একই সময়ে /data তে থাকে।

OtaDexoptService ( frameworks/base/+/android17-release/services/core/java/com/android/server/pm/OtaDexoptService.java ) এর কোডটি প্রতিটি প্যাকেজ অপ্টিমাইজ করার আগে /data অতিরিক্ত ভরে যাওয়া এড়াতে getAvailableSpace কল করে। উল্লেখ্য যে, এখানে ' available' বা 'উপলব্ধ' বলতে আসলে একটি রক্ষণশীল ধারণা বোঝানো হয়েছে: এটি হলো সিস্টেমের স্বাভাবিক সর্বনিম্ন স্থানসীমায় পৌঁছানোর আগে অবশিষ্ট থাকা জায়গার পরিমাণ (যা শতাংশ এবং বাইট উভয় হিসাবেই পরিমাপ করা হয়)। তাই যদি /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 সিস্টেমেও সমস্যা তৈরি করবে)।

এইসব লেখালেখি আর ফটোকপি করার ফলে কি ফ্ল্যাশের ক্ষয় বাড়ে না?

ফ্ল্যাশের খুব অল্প অংশই রিরাইট করা হয়: একটি সম্পূর্ণ পিক্সেল সিস্টেম আপডেটে প্রায় ২.৩ GiB ডেটা লেখা হয়। (অ্যাপগুলোও রিকম্পাইল করা হয়, তবে এটি নন-A/B অ্যাপের ক্ষেত্রেও প্রযোজ্য।) ঐতিহ্যগতভাবে, ব্লক-ভিত্তিক সম্পূর্ণ OTA-গুলো প্রায় একই পরিমাণ ডেটা লিখত, তাই ফ্ল্যাশের ক্ষয়ের হারও একই রকম হওয়া উচিত।

দুটি সিস্টেম পার্টিশন ফ্ল্যাশ করলে কি ফ্যাক্টরি ফ্ল্যাশিংয়ের সময় বেড়ে যায়?

না। সিস্টেম ইমেজের আকারে পিক্সেল বাড়েনি (এটি কেবল দুটি পার্টিশনে জায়গা ভাগ করে দিয়েছে)।

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 চালানো হয়। এই কাজটি সম্পন্ন না হওয়া পর্যন্ত আপডেটটি উপলব্ধ বলে বিবেচিত হয় না।

আমরা কি একটি ৩২ GiB A/B ডিভাইস পাঠাতে পারি (পাঠানো উচিত)? ১৬ GiB? ৮ GiB?

পিক্সেল ডিভাইসে প্রমাণিত হয়েছে যে ৩২GiB ভালোভাবে কাজ করে, এবং ১৬GiB এর মধ্যে ৩২০MiB মানে ২% হ্রাস। একইভাবে, ৮GiB এর মধ্যে ৩২০MiB মানে ৪% হ্রাস। স্পষ্টতই, ৪GiB যুক্ত ডিভাইসের ক্ষেত্রে A/B পদ্ধতিটি সুপারিশযোগ্য নয়, কারণ এক্ষেত্রে অতিরিক্ত ৩২০MiB জায়গা মোট উপলব্ধ স্থানের প্রায় ১০%।

AVB2.0 এর জন্য কি A/B OTA প্রয়োজন?

না, অ্যান্ড্রয়েড ভেরিফাইড বুট-এর জন্য সবসময় ব্লক-ভিত্তিক আপডেট প্রয়োজন হয়, কিন্তু এ/বি আপডেট আবশ্যক নয়।

A/B OTA-গুলোর জন্য কি AVB2.0 প্রয়োজন?

না।

A/B OTA কি AVB2.0-এর রোলব্যাক সুরক্ষা লঙ্ঘন করে?

না। এখানে কিছুটা বিভ্রান্তি আছে, কারণ যদি একটি A/B সিস্টেম নতুন সিস্টেম ইমেজে বুট করতে ব্যর্থ হয়, তবে এটি (আপনার বুটলোডার দ্বারা নির্ধারিত কিছু সংখ্যক বার চেষ্টার পর) স্বয়ংক্রিয়ভাবে "পূর্ববর্তী" সিস্টেম ইমেজে ফিরে যাবে। তবে এখানে মূল বিষয় হলো, A/B-এর ক্ষেত্রে "পূর্ববর্তী" বলতে আসলে তখনও "বর্তমান" সিস্টেম ইমেজকেই বোঝায়। ডিভাইসটি সফলভাবে একটি নতুন ইমেজ বুট করার সাথে সাথেই রোলব্যাক সুরক্ষা সক্রিয় হয়ে ওঠে এবং নিশ্চিত করে যে আপনি আর আগের অবস্থায় ফিরে যেতে পারবেন না। কিন্তু যতক্ষণ না আপনি নতুন ইমেজটি সফলভাবে বুট করছেন, ততক্ষণ রোলব্যাক সুরক্ষা এটিকে বর্তমান সিস্টেম ইমেজ হিসেবে বিবেচনা করে না।

সিস্টেম চালু থাকা অবস্থায় যদি কোনো আপডেট ইনস্টল করা হয়, তাহলে কি তা ধীরগতির হয় না?

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

একটি OTA নেওয়ার সময় দুটি পর্যায় থাকে, যা UI-তে প্রোগ্রেস বারের নিচে 'ধাপ ১/২' এবং 'ধাপ ২/২' হিসেবে স্পষ্টভাবে দেখানো হয়। ধাপ ১-এ ডেটা ব্লকগুলো লেখা হয়, আর ধাপ ২-এ .dex ফাইলগুলো প্রি-কম্পাইল করা হয়। পারফরম্যান্সের ওপর প্রভাবের দিক থেকে এই দুটি পর্যায় বেশ ভিন্ন। প্রথম পর্যায়টি হলো সাধারণ I/O। এর জন্য খুব কম রিসোর্সের (র‍্যাম, সিপিইউ, I/O) প্রয়োজন হয়, কারণ এটি শুধু ধীরে ধীরে ব্লক কপি করে।

দ্বিতীয় ধাপে নতুন সিস্টেম ইমেজটি প্রি-কম্পাইল করার জন্য dex2oat চালানো হয়। এর প্রয়োজনীয়তার ক্ষেত্রে সুস্পষ্ট কোনো সীমা নেই, কারণ এটি প্রকৃত অ্যাপ কম্পাইল করে। এবং স্বাভাবিকভাবেই, একটি ছোট ও সরল অ্যাপের তুলনায় একটি বড় ও জটিল অ্যাপ কম্পাইল করতে অনেক বেশি কাজ করতে হয়; অপরদিকে, প্রথম ধাপে এমন কোনো ডিস্ক ব্লক থাকে না যা অন্যগুলোর চেয়ে বড় বা বেশি জটিল।

এই প্রক্রিয়াটি অনেকটা সেইরকম, যেমনটা গুগল প্লে বছরের পর বছর ধরে '৫টি অ্যাপ আপডেট হয়েছে' নোটিফিকেশন দেখানোর আগে ব্যাকগ্রাউন্ডে কোনো অ্যাপ আপডেট ইনস্টল করে আসছে।

যদি কোনো ব্যবহারকারী আসলেই আপডেটের জন্য অপেক্ষা করে থাকেন, তাহলে কী হবে?

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

আপডেট প্রয়োগ করতে ব্যর্থ হলে কী হবে?

নন-এ/বি আপডেটের ক্ষেত্রে, কোনো আপডেট প্রয়োগ করতে ব্যর্থ হলে ব্যবহারকারীর ডিভাইসটি সাধারণত অকেজো হয়ে পড়ত। এর একমাত্র ব্যতিক্রম ছিল যদি কোনো অ্যাপ্লিকেশন চালু হওয়ার আগেই ব্যর্থতাটি ঘটত (যেমন, প্যাকেজটি যাচাই করতে ব্যর্থ হওয়ার কারণে)। এ/বি আপডেটের ক্ষেত্রে, কোনো আপডেট প্রয়োগ করতে ব্যর্থ হলেও তা বর্তমানে চলমান সিস্টেমকে প্রভাবিত করে না। আপডেটটি পরে আবার চেষ্টা করা যেতে পারে।