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 পরিষেবাগুলি দ্বারা সরবরাহ করা হয়৷ Google-এর OTA অবকাঠামো ব্যবহার না করা OEMগুলি AOSP সিস্টেম কোড পুনরায় ব্যবহার করতে সক্ষম হবে কিন্তু তাদের নিজস্ব ক্লায়েন্ট সরবরাহ করতে হবে।

OEM তাদের নিজস্ব ক্লায়েন্ট সরবরাহ করার জন্য, ক্লায়েন্টের প্রয়োজন:

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

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

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

সিস্টেমের দিকে, 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 (প্লাস 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/ এর অধীনে সংরক্ষিত হয়েছে। লগ গ্রুপ আইডি সহ ব্যবহারকারীরা ফাইল সিস্টেম লগগুলি অ্যাক্সেস করতে সক্ষম হবেন।

বুটলোডার মিথস্ক্রিয়া

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

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

স্ট্রিমিং আপডেট সমর্থন

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

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

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

একটি A/B আপডেটের জীবন

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

ঐচ্ছিকভাবে, OTA প্যাকেজের মেটাডেটা নিজেই নির্দেশ করে যে আপডেটটি স্ট্রিম করা যেতে পারে; একই প্যাকেজ নন-স্ট্রিমিং ইনস্টলেশনের জন্যও ব্যবহার করা যেতে পারে। সার্ভার মেটাডেটা ব্যবহার করে ক্লায়েন্টকে জানাতে পারে যে এটি স্ট্রিমিং হচ্ছে তাই ক্লায়েন্ট সঠিকভাবে update_engine OTA হস্তান্তর করবে। ডিভাইস নির্মাতারা তাদের নিজস্ব সার্ভার এবং ক্লায়েন্ট সহ স্ট্রিমিং আপডেটগুলি সক্ষম করতে পারে যাতে সার্ভার সনাক্ত করে যে আপডেটটি স্ট্রিমিং হচ্ছে (অথবা ধরে নিন সমস্ত আপডেট স্ট্রিমিং হচ্ছে) এবং ক্লায়েন্ট স্ট্রিমিংয়ের জন্য 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) বাইনারি ব্যবহার করা হয় তবে এটি পুরানো কার্নেলের সাথে সামঞ্জস্যপূর্ণ হওয়া উচিত (যেমন একটি 64-বিট নতুন প্রোগ্রাম একটি পুরানো 32-বিট কার্নেলে চলমান যদি আর্কিটেকচারটি 32- থেকে 64-বিট বিল্ডে পরিবর্তন করা হয়)। লোডার ( 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, care_map.txt এক্সট্র্যাক্ট করে, ডিভাইস রিবুট করার আগে অ্যাক্সেসের অনুমতি সেট আপ করে এবং সিস্টেম সফলভাবে নতুন সংস্করণে বুট হওয়ার পরে এক্সট্রাক্ট করা ফাইল মুছে দেয়।