সচরাচর জিজ্ঞাস্য

Google কি কোনো ডিভাইসে A/B OTA ব্যবহার করেছে?

হ্যাঁ. A/B আপডেটের বিপণনের নাম হল বিরামহীন আপডেট । অক্টোবর 2016 থেকে Pixel এবং Pixel XL ফোনগুলি A/B এর সাথে পাঠানো হয়েছে, এবং সমস্ত Chromebooks A/B-এর একই update_engine বাস্তবায়ন ব্যবহার করে৷ প্রয়োজনীয় প্ল্যাটফর্ম কোড বাস্তবায়ন Android 7.1 এবং উচ্চতর সংস্করণে সর্বজনীন।

A/B OTA কেন ভালো?

আপডেট নেওয়ার সময় A/B OTAগুলি একটি ভাল ব্যবহারকারীর অভিজ্ঞতা প্রদান করে। মাসিক নিরাপত্তা আপডেটের পরিমাপগুলি দেখায় যে এই বৈশিষ্ট্যটি ইতিমধ্যেই একটি সফলতা প্রমাণ করেছে: মে 2017 পর্যন্ত, 87% Nexus ব্যবহারকারীর তুলনায় Pixel এর মালিকদের 95% এক মাস পরে সর্বশেষ নিরাপত্তা আপডেট চালাচ্ছেন, এবং Pixel ব্যবহারকারীরা Nexus ব্যবহারকারীদের চেয়ে তাড়াতাড়ি আপডেট করে। একটি OTA চলাকালীন ব্লক আপডেট করতে ব্যর্থতার ফলে এমন ডিভাইস আর বুট হবে না; নতুন সিস্টেম ইমেজ সফলভাবে বুট না হওয়া পর্যন্ত, অ্যান্ড্রয়েড আগের ওয়ার্কিং সিস্টেম ইমেজে ফিরে যাওয়ার ক্ষমতা ধরে রাখে।

কিভাবে A/B 2016 পিক্সেল পার্টিশন মাপ প্রভাবিত করেছে?

নিম্নলিখিত টেবিলে শিপিং A/B কনফিগারেশন বনাম অভ্যন্তরীণভাবে পরীক্ষিত নন-A/B কনফিগারেশনের বিশদ বিবরণ রয়েছে:

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

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

কেন আপনি SquashFS ব্যবহার করেননি?

আমরা SquashFS নিয়ে পরীক্ষা-নিরীক্ষা করেছি কিন্তু উচ্চ-সম্পন্ন ডিভাইসের জন্য কাঙ্খিত কর্মক্ষমতা অর্জন করতে পারিনি। আমরা হ্যান্ডহেল্ড ডিভাইসের জন্য SquashFS ব্যবহার করি না বা সুপারিশ করি না।

আরও নির্দিষ্টভাবে, স্কোয়াশএফএস সিস্টেম পার্টিশনে প্রায় 50% আকারের সঞ্চয় প্রদান করেছে, কিন্তু যে ফাইলগুলি ভালভাবে সংকুচিত হয়েছে তার বেশিরভাগই ছিল প্রি-কম্পাইল করা .odex ফাইল। এই ফাইলগুলির খুব উচ্চ কম্প্রেশন অনুপাত ছিল (80% এর কাছাকাছি), কিন্তু বাকি সিস্টেম পার্টিশনের জন্য কম্প্রেশন অনুপাত ছিল অনেক কম। উপরন্তু, Android 7.0-এ SquashFS নিম্নলিখিত কর্মক্ষমতা উদ্বেগ উত্থাপন করেছে:

• পিক্সেলের আগের ডিভাইসের তুলনায় খুব দ্রুত ফ্ল্যাশ আছে কিন্তু অতিরিক্ত CPU সাইকেল নেই, তাই ফ্ল্যাশ থেকে কম বাইট পড়া কিন্তু I/O-এর জন্য আরও CPU প্রয়োজন একটি সম্ভাব্য বাধা।
• I/O পরিবর্তনগুলি যেগুলি আনলোড করা সিস্টেমে চালিত একটি কৃত্রিম বেঞ্চমার্কে ভাল কাজ করে তা কখনও কখনও বাস্তব-বিশ্বের লোডের অধীনে বাস্তব-বিশ্ব ব্যবহারের ক্ষেত্রে ভাল কাজ করে না (যেমন Nexus 6-এ ক্রিপ্টো)।
• বেঞ্চমার্কিং কিছু জায়গায় 85% রিগ্রেশন দেখিয়েছে।

SquashFS পরিপক্ক হওয়ার সাথে সাথে CPU প্রভাব কমাতে বৈশিষ্ট্য যোগ করে (যেমন সাধারণভাবে অ্যাক্সেস করা ফাইলগুলির একটি সাদা তালিকা যা সংকুচিত করা উচিত নয়), আমরা এটির মূল্যায়ন চালিয়ে যাব এবং ডিভাইস নির্মাতাদের সুপারিশ অফার করব।

আপনি কিভাবে SquashFS ছাড়া সিস্টেম পার্টিশনের আকার অর্ধেক করলেন?

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

উদাহরণ: 2628MiB (2755792836 বাইট) এর মোট সিস্টেম ইমেজ সাইজ সহ Android 7.1 চালিত Nexus 6P থেকে ইনস্টল করা-files.txt-এর জন্য, ফাইলের ধরন অনুসারে সামগ্রিক সিস্টেম চিত্রের আকারে সবচেয়ে বড় অবদানকারীদের ভাঙ্গন নিম্নরূপ:

এই পরিসংখ্যান অন্যান্য ডিভাইসের জন্যও একই রকম, তাই Nexus/Pixel ডিভাইসে, .odex ফাইলগুলি প্রায় অর্ধেক সিস্টেম পার্টিশন নেয়। এর মানে হল আমরা ext4 ব্যবহার চালিয়ে যেতে পারি কিন্তু ফ্যাক্টরির B পার্টিশনে .odex ফাইল লিখতে পারি এবং তারপর প্রথম বুটে /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 দেখুন।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

নিয়মিত বুটের তুলনায় ফ্যাক্টরি ডেটা রিসেট একটি বিরল অপারেশন হওয়া উচিত তাই সময় নেওয়া কম গুরুত্বপূর্ণ। (এটি ব্যবহারকারী বা পর্যালোচকদের প্রভাবিত করে না যারা তাদের ডিভাইসটি ফ্যাক্টরি থেকে পায়, কারণ সেক্ষেত্রে B পার্টিশন পাওয়া যায়।) JIT কম্পাইলার ব্যবহার করার অর্থ হল আমাদের সবকিছু পুনরায় কম্পাইল করার দরকার নেই, তাই এটি আপনার মতো খারাপ নয় অবস্যই চিন্তিত. ম্যানিফেস্টে coreApp="true" ব্যবহার করে অ্যাপ্লিকেশানগুলিকে আগাম-সময়ের সংকলনের প্রয়োজন হিসাবে চিহ্নিত করাও সম্ভব: ( frameworks/base/+/main/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 OTAs প্রয়োজন?

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

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

না.

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

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

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

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

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

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

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

যদি একজন ব্যবহারকারী প্রকৃতপক্ষে আপডেটের জন্য অপেক্ষা করে থাকে?

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

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

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

একটি চিপে কোন সিস্টেম (SoCs) A/B সমর্থন করে?

2017-03-15 পর্যন্ত, আমাদের কাছে নিম্নলিখিত তথ্য রয়েছে:

সময়সূচী সম্পর্কে বিশদ বিবরণের জন্য, আপনার SoC পরিচিতিগুলির সাথে চেক করুন। উপরে তালিকাভুক্ত নয় এমন SoCগুলির জন্য, সরাসরি আপনার SoC-এর সাথে যোগাযোগ করুন।