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

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

উদাহরণ: ২৬২৮MiB (২৭৫৫৭৯২৮৩৬ বাইট) মোট সিস্টেম ছবির আকার সহ Android 7.1 চালিত Nexus 6P থেকে installed-files.txt ফাইলের জন্য, ফাইলের ধরণ অনুসারে সামগ্রিক সিস্টেম ছবির আকারে সবচেয়ে বড় অবদানকারীদের বিভাজন নিম্নরূপ:

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

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

.odex ফাইলগুলি /data তে অনুলিপি করার অর্থ কি /system এ সংরক্ষিত স্থান /data তে হারিয়ে যাবে না?

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

কয়েকটি মূল কারণে তুলনাটি কঠিন:

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

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

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

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

OtaDexoptService ( frameworks/base/+/android16-qpr1-release/services/core/java/com/android/server/pm/OtaDexoptService.java ) এর কোডটি /data অতিরিক্ত ভরাট এড়াতে প্রতিটি প্যাকেজ অপ্টিমাইজ করার আগে getAvailableSpace কল করে। মনে রাখবেন যে এখানে উপলব্ধ এখনও রক্ষণশীল: এটি স্বাভাবিক সিস্টেমের নিম্ন স্থান থ্রেশহোল্ডে পৌঁছানোর আগে অবশিষ্ট স্থানের পরিমাণ (শতাংশ এবং বাইট গণনা উভয় হিসাবে পরিমাপ করা হয়)। সুতরাং যদি /data পূর্ণ হয়, তাহলে প্রতিটি .odex ফাইলের দুটি কপি থাকবে না। একই কোডে একটি BULK_DELETE_THRESHOLDও রয়েছে: যদি ডিভাইসটি উপলব্ধ স্থান পূরণের কাছাকাছি চলে যায় (যেমনটি বর্ণনা করা হয়েছে), তবে ব্যবহৃত না হওয়া অ্যাপগুলির .odex ফাইলগুলি সরানো হয়। প্রতিটি .odex ফাইলের দুটি কপি ছাড়াই এটি আরেকটি ঘটনা।

সবচেয়ে খারাপ ক্ষেত্রে যেখানে /data সম্পূর্ণরূপে পূর্ণ থাকে, আপডেটটি ডিভাইসটি নতুন সিস্টেমে রিবুট না হওয়া পর্যন্ত অপেক্ষা করে এবং পুরানো সিস্টেমের .odex ফাইলগুলির আর প্রয়োজন হয় না। প্যাকেজম্যানেজার এটি পরিচালনা করে: ( frameworks/base/+/android16-qpr1-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215 )। নতুন সিস্টেমটি সফলভাবে বুট হওয়ার পরে, installd ( frameworks/native/+/android16-qpr1-release/cmds/installd/dexopt.cpp#2422 ) পুরানো সিস্টেম দ্বারা ব্যবহৃত .odex ফাইলগুলি সরিয়ে ফেলতে পারে, ডিভাইসটিকে স্থিতিশীল অবস্থায় ফিরিয়ে আনে যেখানে শুধুমাত্র একটি কপি থাকে।

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

এই সব লেখা/অনুলিপি কি ফ্ল্যাশের ক্ষয়ক্ষতি বাড়ায় না?

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

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

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

.odex ফাইলগুলি B তে রাখলে কি ফ্যাক্টরি ডেটা রিসেট করার পরে রিবুট করা ধীর হয়ে যায় না?

হ্যাঁ। যদি আপনি আসলেই কোনও ডিভাইস ব্যবহার করে থাকেন, একটি OTA নিয়ে থাকেন এবং ফ্যাক্টরি ডেটা রিসেট করে থাকেন, তাহলে প্রথম রিবুটটি অন্যথায় হওয়ার চেয়ে ধীর হবে (একটি Pixel XL-এ 1m40s বনাম 40s) কারণ .odex ফাইলগুলি প্রথম OTA-এর পরে B থেকে হারিয়ে যাবে এবং তাই /data তে অনুলিপি করা যাবে না। এটাই বিনিময়।

নিয়মিত বুটের তুলনায় ফ্যাক্টরি ডেটা রিসেট একটি বিরল অপারেশন হওয়া উচিত, তাই এতে যে সময় লাগে তা কম গুরুত্বপূর্ণ। (এটি ব্যবহারকারী বা পর্যালোচকদের উপর প্রভাব ফেলে না যারা তাদের ডিভাইসটি ফ্যাক্টরি থেকে নেন, কারণ সেক্ষেত্রে B পার্টিশন উপলব্ধ থাকে।) JIT কম্পাইলার ব্যবহারের অর্থ হল আমাদের সবকিছু পুনরায় কম্পাইল করার প্রয়োজন নেই, তাই এটি আপনার ভাবার মতো খারাপ নয়। ম্যানিফেস্টে coreApp="true" ব্যবহার করে অ্যাপগুলিকে আগে থেকে কম্পাইল করার প্রয়োজন হিসাবে চিহ্নিত করাও সম্ভব: ( frameworks/base/+/android16-qpr1-release/packages/SystemUI/AndroidManifest.xml#23 )। এটি বর্তমানে system_server দ্বারা ব্যবহৃত হয় কারণ নিরাপত্তার কারণে এটি JIT করার অনুমতি নেই।

.odex ফাইলগুলি /system-এর পরিবর্তে /data-তে রাখলে কি OTA-এর পরে রিবুট করার গতি ধীর হয়ে যায় না?

না। উপরে যেমন ব্যাখ্যা করা হয়েছে, নতুন dex2oat তখনই চালানো হয় যখন পুরানো সিস্টেম ইমেজটি এখনও চলমান থাকে যাতে নতুন সিস্টেমের জন্য প্রয়োজনীয় ফাইলগুলি তৈরি করা যায়। কাজটি সম্পন্ন না হওয়া পর্যন্ত আপডেটটি উপলব্ধ বলে বিবেচিত হয় না।

আমরা কি 32GiB A/B ডিভাইস পাঠাতে পারি? 16GiB? 8GiB?

32GiB ভালো কাজ করে যেমনটি Pixel-এ প্রমাণিত হয়েছে, এবং 16GiB-এর মধ্যে 320MiB মানে 2% হ্রাস। একইভাবে, 8GiB-এর মধ্যে 320MiB হ্রাস 4%। স্পষ্টতই 4GiB বিশিষ্ট ডিভাইসগুলিতে A/B প্রস্তাবিত পছন্দ হবে না, কারণ 320MiB ওভারহেড মোট উপলব্ধ স্থানের প্রায় 10%।

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

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

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

না।

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

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

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

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

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

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

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

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

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

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

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