A/B (বিরামহীন) সিস্টেম আপডেট

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

A/B সিস্টেম আপডেট এবং সেগুলি কীভাবে কাজ করে সেই সম্পর্কে আরও তথ্যের জন্য, পার্টিশন বেছে নেওয়া (স্লট) দেখুন।

A/B সিস্টেম আপডেট নিম্নলিখিত সুবিধাগুলি প্রদান করে:

  • ব্যবহারকারীকে বাধা না দিয়ে, সিস্টেম চলাকালীন OTA আপডেট হতে পারে। OTA চলাকালীন ব্যবহারকারীরা তাদের ডিভাইস ব্যবহার করা চালিয়ে যেতে পারবেন—আপডেট চলাকালীন একমাত্র ডাউনটাইম হল যখন ডিভাইসটি আপডেট করা ডিস্ক পার্টিশনে রিবুট হয়।
  • আপডেট করার পরে, রিবুট করতে সাধারণ রিবুটের চেয়ে বেশি সময় লাগে না।
  • OTA প্রয়োগ করা না গেলে (যেমন, ফ্ল্যাশ ঠিকমতো না হওয়ার কারণে), ব্যবহারকারীর উপর কোনও প্রভাব পড়বে না। ব্যবহারকারী পুরনো OS ব্যবহার করা চালিয়ে যাবেন এবং ক্লায়েন্ট আপডেট করার জন্য আবার চেষ্টা করতে পারবেন।
  • OTA আপডেট প্রয়োগ করা হলে কিন্তু বুট করতে না পারলে, ডিভাইসটি পুরনো পার্টিশনে রিবুট হবে এবং ব্যবহারযোগ্য থাকবে। ক্লায়েন্ট আবার আপডেট করার চেষ্টা করতে পারে।
  • যেকোনও সমস্যা (যেমন, I/O সংক্রান্ত সমস্যা) শুধুমাত্র ব্যবহার করা হয়নি এমন পার্টিশন সেটে প্রভাব ফেলে এবং আবার চেষ্টা করা যেতে পারে। এই ধরনের সমস্যা হওয়ার সম্ভাবনাও কম থাকে কারণ ব্যবহারকারীর অভিজ্ঞতা যাতে খারাপ না হয় সেই জন্য I/O লোড ইচ্ছাকৃতভাবে কম রাখা হয়।
  • A/B ডিভাইসে আপডেট স্ট্রিম করা যায়, এর ফলে ইনস্টল করার আগে প্যাকেজ ডাউনলোড করার প্রয়োজন হয় না। স্ট্রিমিংয়ের অর্থ হল, ব্যবহারকারীর কাছে আপডেট প্যাকেজ স্টোর করার জন্য /data বা /cache-এ পর্যাপ্ত ফ্রি স্পেস থাকার প্রয়োজন নেই।
  • OTA আপডেট প্যাকেজ স্টোর করার জন্য ক্যাশে পার্টিশন আর ব্যবহার করা হয় না, তাই ভবিষ্যতে আপডেট করার জন্য ক্যাশে পার্টিশন যথেষ্ট বড় কিনা তা নিশ্চিত করার প্রয়োজন নেই।
  • dm-verity গ্যারান্টি দেয় যে ডিভাইসটি কোনও দুর্নীতিগ্রস্ত ইমেজ বুট করবে না। খারাপ OTA বা dm-verity সংক্রান্ত সমস্যার কারণে কোনও ডিভাইস বুট না হলে, ডিভাইসটি একটি পুরনো ইমেজে রিবুট করতে পারে। (Android যাচাই করা বুট-এর জন্য A/B আপডেটের প্রয়োজন নেই।)

A/B সিস্টেম আপডেট সম্পর্কে

A/B আপডেটের জন্য ক্লায়েন্ট ও সিস্টেম, দুটিতেই পরিবর্তন করতে হয়। তবে, OTA প্যাকেজ সার্ভারে কোনও পরিবর্তন করার প্রয়োজন নেই: আপডেট প্যাকেজ এখনও HTTPS-এর মাধ্যমে পরিবেশন করা হয়। Google-এর OTA ইনফ্রাস্ট্রাকচার ব্যবহার করা ডিভাইসের ক্ষেত্রে, সিস্টেমের পরিবর্তনগুলি সবই AOSP-তে থাকে এবং ক্লায়েন্ট কোড Google Play পরিষেবা প্রদান করে। যেসব OEM Google-এর OTA ইনফ্রাস্ট্রাকচার ব্যবহার করে না, তারা AOSP সিস্টেম কোড আবার ব্যবহার করতে পারবে, তবে তাদের নিজস্ব ক্লায়েন্ট দিতে হবে।

OEM-এর নিজস্ব ক্লায়েন্টকে সাপ্লাই করার ক্ষেত্রে, ক্লায়েন্টকে এগুলি করতে হবে:

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

ঐচ্ছিকভাবে, ক্লায়েন্ট এগুলি করতে পারেন:

  • ব্যবহারকারীকে রিবুট করতে বলার জন্য একটি বিজ্ঞপ্তি দেখান। আপনি যদি এমন কোনও নীতি প্রয়োগ করতে চান যেখানে ব্যবহারকারীকে নিয়মিত আপডেট করার জন্য উৎসাহিত করা হয়, তাহলে এই বিজ্ঞপ্তি আপনার ক্লায়েন্টে যোগ করা যেতে পারে। ক্লায়েন্ট ব্যবহারকারীকে প্রম্পট না করলে, ব্যবহারকারী পরের বার রিবুট করার সময় আপডেট পেয়ে যাবেন। (Google-এর ক্লায়েন্টের প্রতিটি আপডেটের জন্য কনফিগার করা যায় এমন বিলম্ব আছে।)
  • ব্যবহারকারী নতুন OS ভার্সনে বুট করেছেন কিনা অথবা তার সেটি করার কথা ছিল কিনা, কিন্তু পুরনো OS ভার্সনে ফিরে গেছেন কিনা তা বিজ্ঞপ্তি দেখিয়ে ব্যবহারকারীকে জানান। (Google-এর ক্লায়েন্ট সাধারণত কোনওটিই করে না।)

সিস্টেমের দিক থেকে, A/B সিস্টেম আপডেট নিম্নলিখিত বিষয়গুলিকে প্রভাবিত করে:

  • পার্টিশন বেছে নেওয়া (স্লট), update_engine ডেমোন এবং বুটলোডার ইন্টার‍্যাকশন (নিচে বর্ণনা করা হয়েছে)
  • বিল্ড প্রসেস ও OTA আপডেট প্যাকেজ জেনারেশন (যা A/B আপডেট প্রয়োগ করা নিবন্ধে বর্ণনা করা হয়েছে)

পার্টিশন বেছে নেওয়া (স্লট)

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

প্রতিটি স্লটে একটি বুটযোগ্য অ্যাট্রিবিউট থাকে যা বলে যে স্লটে একটি সঠিক সিস্টেম আছে কিনা যেখান থেকে ডিভাইস বুট করতে পারে। সিস্টেম চালু থাকলে বর্তমান স্লট বুট করা যায়, কিন্তু অন্য স্লটে সিস্টেমের পুরনো (তবুও সঠিক) ভার্সন, নতুন ভার্সন বা ভুল ডেটা থাকতে পারে। বর্তমান স্লট যাই হোক না কেন, একটি স্লট আছে যা অ্যাক্টিভ স্লট (যেটি থেকে বুটলোডার পরবর্তী বুটে বুট করবে) অথবা পছন্দের স্লট।

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

ইঞ্জিন ডেমন আপডেট করা

A/B সিস্টেম আপডেট, সিস্টেমকে নতুন, আপডেট করা ভার্সনে বুট করার জন্য প্রস্তুত করতে update_engine নামের একটি ব্যাকগ্রাউন্ড ডেমন ব্যবহার করে। এই ড্যামন নিম্নলিখিত অ্যাকশন নিতে পারে:

  • বর্তমান স্লট A/B পার্টিশন থেকে পড়ুন এবং OTA প্যাকেজের নির্দেশ অনুযায়ী অব্যবহৃত স্লট A/B পার্টিশনে যেকোনও ডেটা লিখুন।
  • আগে থেকে নির্দিষ্ট করা ওয়ার্কফ্লোতে boot_control ইন্টারফেস কল করুন।
  • OTA প্যাকেজের নির্দেশ অনুযায়ী, অব্যবহৃত সব স্লট পার্টিশন লেখার পরে, নতুন পার্টিশন থেকে ইনস্টল-পরবর্তী প্রোগ্রাম চালান। (বিস্তারিত জানতে, ইনস্টলেশন-পরবর্তী দেখুন)।

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

ইঞ্জিন সোর্স আপডেট করুন

update_engine সোর্সটি system/update_engine-এ অবস্থিত। A/B OTA dexopt ফাইল installd এবং প্যাকেজ ম্যানেজারের মধ্যে ভাগ করা থাকে:

  • frameworks/native/cmds/installd/ota*-এ পোস্ট-ইনস্টল স্ক্রিপ্ট, chroot-এর বাইনারি, dex2oat কল করা ইনস্টল করা ক্লোন, পোস্ট-OTA মুভ-আর্টিফ্যাক্ট স্ক্রিপ্ট এবং মুভ স্ক্রিপ্টের জন্য rc ফাইল অন্তর্ভুক্ত থাকে।
  • frameworks/base/services/core/java/com/android/server/pm/OtaDexoptService.java (plus OtaDexoptShellCommand) হল প্যাকেজ ম্যানেজার যা অ্যাপ্লিকেশনের জন্য dex2oat কমান্ড প্রস্তুত করে।

কার্যকর উদাহরণের জন্য, /device/google/marlin/device-common.mk দেখুন।

ইঞ্জিন লগ আপডেট করা

Android 8.x রিলিজ ও তার আগের ভার্সনের জন্য, update_engine লগ logcat-এ এবং সমস্যার রিপোর্টে পাওয়া যাবে। ফাইল সিস্টেমে update_engine লগ উপলভ্য করতে, আপনার বিল্ডে নিম্নলিখিত পরিবর্তনগুলি প্যাচ করুন:

এইসব পরিবর্তন সবচেয়ে সাম্প্রতিক update_engine লগ কপি করে /data/misc/update_engine_log/update_engine.YEAR-TIME-এ সেভ করে। বর্তমান লগ ছাড়াও, পাঁচটি সাম্প্রতিক লগ /data/misc/update_engine_log/-এর অধীনে সেভ করা হয়। log গ্রুপ আইডি সহ ব্যবহারকারীরা ফাইল সিস্টেম লগ অ্যাক্সেস করতে পারবেন।

বুটলোডার ইন্টার‍্যাকশন

boot_control HAL, update_engine (এবং সম্ভবত অন্যান্য ডিমোন) ব্যবহার করে বুটলোডারকে কী বুট করতে হবে সেই বিষয়ে নির্দেশ দেওয়া হয়। সাধারণ উদাহরণমূলক পরিস্থিতি এবং সেগুলির সাথে যুক্ত স্টেটগুলির মধ্যে নিম্নলিখিত বিষয়গুলি অন্তর্ভুক্ত:

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

স্ট্রিমিং আপডেট সংক্রান্ত সহায়তা

ব্যবহারকারীর ডিভাইসে আপডেট প্যাকেজ ডাউনলোড করার জন্য সবসময় /data পর্যাপ্ত জায়গা থাকে না। OEM বা ব্যবহারকারী কেউই /cache পার্টিশনে স্পেস নষ্ট করতে চান না, কিছু ব্যবহারকারী আপডেট ছাড়াই কাজ চালান কারণ আপডেট প্যাকেজ স্টোর করার জন্য ডিভাইসে কোনও জায়গা থাকে না। এই সমস্যার সমাধান করতে, Android 8.0, A/B আপডেট স্ট্রিম করার সুবিধা যোগ করেছে যা ডাউনলোড করার সময় ব্লকগুলি সরাসরি B পার্টিশনে লেখে, এর ফলে ব্লকগুলিকে /data-এ স্টোর করতে হয় না। স্ট্রিমিং A/B আপডেটের জন্য প্রায় কোনও অস্থায়ী স্টোরেজের প্রয়োজন হয় না এবং এতে মেটাডেটার জন্য মোটামুটি ১০০ KiB স্টোরেজ প্রয়োজন হয়।

Android 7.1-এ স্ট্রিমিং আপডেট চালু করতে, নিম্নলিখিত প্যাচগুলি বেছে নিন:

Android 7.1 ও তার পরবর্তী যেকোনও ভার্সনে A/B আপডেট স্ট্রিম করার জন্য এইসব প্যাচ প্রয়োজন। এটি Google Mobile Services (GMS) বা অন্য কোনও আপডেট ক্লায়েন্ট ব্যবহার করতে পারে।

A/B আপডেটের মেয়াদ

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

বিকল্প হিসেবে, OTA প্যাকেজের মেটাডেটা থেকে বোঝা যায় যে আপডেট স্ট্রিম করা যাবে; একই প্যাকেজ স্ট্রিম না করে ইনস্টল করার জন্যও ব্যবহার করা যেতে পারে। সার্ভার মেটাডেটা ব্যবহার করে ক্লায়েন্টকে জানাতে পারে যে এটি স্ট্রিম করছে, যাতে ক্লায়েন্ট OTA-কে update_engine-এর কাছে সঠিকভাবে হ্যান্ড অফ করতে পারে। নিজস্ব সার্ভার ও ক্লায়েন্ট আছে এমন ডিভাইস প্রস্তুতকারক আপডেট স্ট্রিমিং চালু করতে পারেন। এর জন্য সার্ভারকে শনাক্ত করতে হবে যে আপডেটটি স্ট্রিমিং হচ্ছে (অথবা ধরে নিতে হবে যে সব আপডেটই স্ট্রিমিং হচ্ছে) এবং ক্লায়েন্টকে স্ট্রিমিংয়ের জন্য update_engine-এ সঠিক কল করতে হবে। প্যাকেজটি স্ট্রিমিং ভেরিয়েন্টের, এই তথ্যটি ব্যবহার করে ম্যানুফ্যাকচারাররা ক্লায়েন্টকে একটি ফ্ল্যাগ পাঠাতে পারেন, যাতে ফ্রেমওয়ার্কের দিকে স্ট্রিমিং হিসেবে হ্যান্ড অফ ট্রিগার করা যায়।

পে-লোড উপলভ্য হওয়ার পরে, আপডেট প্রসেসটি নিম্নলিখিতভাবে সম্পন্ন হয়:

ধাপ অ্যাক্টিভিটি
1 বর্তমান স্লট (বা "সোর্স স্লট") সফল হিসেবে চিহ্নিত করা হয়েছে (আগে থেকে চিহ্নিত করা না থাকলে) এবং এর সাথে markBootSuccessful() আছে।
2 ব্যবহার না করা স্লট (বা "টার্গেট স্লট") কে ফাংশন কল করে বুট করার অযোগ্য হিসেবে চিহ্নিত করা হয় setSlotAsUnbootable(). বুটলোডার যাতে অব্যবহৃত স্লটে ফিরে না যায়, তার জন্য আপডেট শুরু হওয়ার সময় বর্তমান স্লটকে সবসময় সফল হিসেবে চিহ্নিত করা হয়, যেটিতে শীঘ্রই ভুল ডেটা থাকবে। সিস্টেম যদি এমন পর্যায়ে পৌঁছে যায় যেখানে এটি আপডেট প্রয়োগ করা শুরু করতে পারে, তাহলে বর্তমান স্লটকে সফল হিসেবে চিহ্নিত করা হয়, এমনকি অন্যান্য মেজর কম্পোনেন্ট ভেঙে গেলেও (যেমন, ক্র্যাশ লুপে থাকা UI) এটি করা হয়, কারণ এইসব সমস্যা সমাধান করার জন্য নতুন সফ্টওয়্যার পুশ করা সম্ভব।

আপডেট পেলোড হল একটি অস্বচ্ছ ব্লব যাতে নতুন ভার্সনে আপডেট করার নির্দেশাবলী থাকে। আপডেট পেলোডে নিম্নলিখিত তথ্য থাকে:
  • মেটাডেটা। আপডেট পেলোডের তুলনামূলকভাবে ছোট অংশ, মেটাডেটা টার্গেট স্লটে নতুন ভার্সন তৈরি ও যাচাই করার জন্য অপারেশনের একটি তালিকা থাকে। যেমন, কোনও অপারেশন নির্দিষ্ট ব্লব ডিকম্প্রেস করে টার্গেট পার্টিশনের নির্দিষ্ট ব্লকে লিখতে পারে অথবা সোর্স পার্টিশন থেকে রিড করে বাইনারি প্যাচ প্রয়োগ করে টার্গেট পার্টিশনের নির্দিষ্ট ব্লকে লিখতে পারে।
  • অতিরিক্ত ডেটা। আপডেট পেলোডের বেশিরভাগ অংশ হিসেবে, অপারেশন সম্পর্কিত অতিরিক্ত ডেটাতে এইসব উদাহরণে কম্প্রেস করা ব্লব বা বাইনারি প্যাচ থাকে।
3 পে-লোড মেটাডেটা ডাউনলোড করা হয়।
4 মেটাডেটাতে সংজ্ঞায়িত প্রতিটি অপারেশনের জন্য, সংশ্লিষ্ট ডেটা (যদি থাকে) ক্রমে মেমরিতে ডাউনলোড করা হয়, অপারেশন প্রয়োগ করা হয় এবং সংশ্লিষ্ট মেমরি বাতিল করা হয়।
5 সম্পূর্ণ পার্টিশন আবার পড়া হয় এবং প্রত্যাশিত হ্যাশের সাথে যাচাই করা হয়।
6 ইনস্টল করার পরের ধাপ (যদি কিছু থাকে) রান করানো হয়। কোনও ধাপ কার্যকর করার সময় সমস্যা হলে, আপডেট করা যায় না এবং সম্ভবত অন্য কোনও পেলোড দিয়ে আবার চেষ্টা করা হয়। এতক্ষণ পর্যন্ত সব ধাপ সফলভাবে সম্পূর্ণ করা গেলে, আপডেট সফল হয় এবং শেষ ধাপটি এক্সিকিউট করা হয়।
7 setActiveBootSlot() কল করে ব্যবহার না করা স্লটকে অ্যাক্টিভ হিসেবে চিহ্নিত করা হয়। ব্যবহার না করা স্লট অ্যাক্টিভ হিসেবে চিহ্নিত করার অর্থ এই নয় যে এটি বুটিং সম্পূর্ণ করবে। বুটলোডার (বা সিস্টেম নিজেই) অ্যাক্টিভ স্লটকে আগের অবস্থায় ফিরিয়ে নিয়ে যেতে পারে, যদি এটি কোনও সফল স্টেট রিড না করে।
8 ইনস্টলেশনের পরে (নিচে বর্ণনা করা হয়েছে) "নতুন আপডেট" ভার্সন থেকে একটি প্রোগ্রাম রান করতে হয়, যদিও সেটি পুরনো ভার্সনে রান করে। OTA প্যাকেজে উল্লেখ করা থাকলে, এই ধাপটি বাধ্যতামূলক এবং প্রোগ্রামটিকে 0 এক্সিট কোড সহ রিটার্ন করতে হবে; অন্যথায়, আপডেটটি সম্পূর্ণ হবে না।
9 সিস্টেমটি নতুন স্লটে যথেষ্ট বুট করার পরে এবং রিবুট-পরবর্তী চেক সম্পূর্ণ করার পরে, বর্তমান স্লট (আগে "টার্গেট স্লট" ছিল) সফল হিসেবে চিহ্নিত করা হয় markBootSuccessful() কল করে।

ইনস্টল করার পরে

যেসব পার্টিশনে ইনস্টল করার পরের ধাপ উল্লেখ করা আছে, update_engine সেইসব পার্টিশনকে নির্দিষ্ট লোকেশনে মাউন্ট করে এবং মাউন্ট করা পার্টিশনের সাপেক্ষে OTA-তে উল্লেখ করা প্রোগ্রাম এক্সিকিউট করে। যেমন, যদি সিস্টেম পার্টিশনে পোস্ট-ইনস্টল প্রোগ্রামকে usr/bin/postinstall হিসেবে সংজ্ঞায়িত করা হয়, তাহলে অব্যবহৃত স্লট থেকে এই পার্টিশনটি একটি নির্দিষ্ট লোকেশনে (যেমন /postinstall_mount) মাউন্ট করা হবে এবং /postinstall_mount/usr/bin/postinstall কমান্ডটি এক্সিকিউট করা হবে।

ইনস্টলেশন পরবর্তী প্রসেস সফলভাবে সম্পূর্ণ করতে, পুরনো কার্নেলকে এগুলি করতে হবে:

  • নতুন ফাইলসিস্টেম ফর্ম্যাট মাউন্ট করুন। ফাইলসিস্টেমের ধরন পরিবর্তন করা যাবে না, যদি না সেটি পুরনো কার্নেলে কাজ করে, এর মধ্যে কম্প্রেস করা ফাইলসিস্টেম (যেমন, SquashFS) ব্যবহার করলে ব্যবহৃত কম্প্রেশন অ্যালগরিদম সংক্রান্ত বিবরণের মতো বিষয় অন্তর্ভুক্ত।
  • নতুন পার্টিশনের পোস্ট-ইনস্টল প্রোগ্রাম ফর্ম্যাট সম্পর্কে জানুন। এক্সিকিউটেবল ও লিঙ্কেবল ফর্ম্যাট (ELF) বাইনারি ব্যবহার করলে, সেটি পুরনো কার্নেলের সাথে মানানসই হতে হবে (যেমন, আর্কিটেকচার ৩২-বিট থেকে ৬৪-বিট বিল্ডে পরিবর্তন করা হলে, পুরনো ৩২-বিট কার্নেলে চলা ৬৪-বিট নতুন প্রোগ্রাম)। লোডারকে (ld) অন্য পাথ ব্যবহার করতে বা স্ট্যাটিক বাইনারি তৈরি করতে নির্দেশ না দেওয়া হলে, লাইব্রেরিগুলি নতুন সিস্টেম ইমেজ থেকে নয়, পুরনো সিস্টেম ইমেজ থেকে লোড করা হবে।

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

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

বেছে নেওয়া পোস্ট-ইনস্টল প্রোগ্রাম postinstall SELinux কনটেক্সটে চলে। নতুন মাউন্ট করা পার্টিশনের সব ফাইলকে postinstall_file দিয়ে ট্যাগ করা হবে, সেগুলি নতুন সিস্টেমে রিবুট করার পরে সেগুলির অ্যাট্রিবিউট যাই হোক না কেন। নতুন সিস্টেমে SELinux অ্যাট্রিবিউটে পরিবর্তন করা হলে তা ইনস্টল-পরবর্তী ধাপে কোনও প্রভাব ফেলবে না। ইনস্টল করার পরে চালানো প্রোগ্রামের অতিরিক্ত অনুমতির প্রয়োজন হলে, সেগুলি অবশ্যই ইনস্টল করার পরে চালানো প্রোগ্রামের কনটেক্সটে যোগ করতে হবে।

রিবুট করার পরে

রিবুট করার পরে, update_verifier dm-verity ব্যবহার করে ইন্টিগ্রিটি চেক ট্রিগার করে। এই চেকটি জাইগোটের আগে শুরু হয় যাতে জাভা পরিষেবা কোনও অপরিবর্তনীয় পরিবর্তন করতে না পারে যা নিরাপদ রোলব্যাক প্রতিরোধ করবে। এই প্রসেস চলাকালীন, যাচাই করা বুট বা dm-verity কোনও দুর্নীতি শনাক্ত করলে, বুটলোডার এবং কার্নেলও রিবুট ট্রিগার করতে পারে। চেক করা হয়ে গেলে, update_verifier বুট সফল হয়েছে বলে চিহ্নিত করে।

update_verifier শুধুমাত্র /data/ota_package/care_map.txt-এ তালিকাভুক্ত ব্লকগুলি পড়বে, যা AOSP কোড ব্যবহার করার সময় A/B OTA প্যাকেজে অন্তর্ভুক্ত থাকে। GmsCore-এর মতো Java সিস্টেম আপডেট ক্লায়েন্ট, এক্সট্র্যাক্ট করে care_map.txt, ডিভাইস রিবুট করার আগে অ্যাক্সেস সংক্রান্ত অনুমতি সেট-আপ করে এবং সিস্টেম নতুন ভার্সনে সফলভাবে বুট হয়ে গেলে এক্সট্র্যাক্ট করা ফাইল মুছে দেয়।