চেরি-নিম্নলিখিত জ্ঞাত সমস্যা সমাধানের জন্য নিম্নলিখিত প্যাচগুলি বেছে নিন।
সাইডলোড করার সময় বরাদ্দযোগ্য স্থান সঠিকভাবে পরীক্ষা করুন
একটি ভার্চুয়াল A/B ডিভাইসে একটি সম্পূর্ণ OTA প্যাকেজ সাইডলোড করা যাতে *2 * সমষ্টি (আপডেট গ্রুপের আকার)* এর চেয়ে ছোট আকারের একটি সুপার পার্টিশন রয়েছে তা রিকভারি লগ /tmp/recovery.log এ নিম্নলিখিতগুলির সাথে ব্যর্থ হতে পারে:
The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...
এখানে লগের একটি উদাহরণ:
[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.
আপনি যদি এই সমস্যার সম্মুখীন হন, চেরি পিক CL 1399393 , পুনঃনির্মাণ করুন এবং বুট পার্টিশন বা রিকভারি পার্টিশন ফ্ল্যাশ করুন যদি ডিভাইসটি বুট হিসাবে পুনরুদ্ধার ব্যবহার না করে।
মার্জ করার সময় সেগমেন্টেশন ফল্ট ঠিক করুন
একটি OTA আপডেট প্রয়োগ করার পরে, VAB মার্জ প্রক্রিয়া চলাকালীন, update_engine_client --cancel এ একটি কল CleanupPreviousUpdateAction ক্র্যাশ করে। markSlotSuccessful দেরিতে আসলে একটি সম্ভাব্য ওয়াইল্ড পয়েন্টার ত্রুটিও বিদ্যমান।
StopActionInternal ফাংশন যোগ করে এটি সমাধান করা হয়েছে। CleanupPreviousUpdateAction ধ্বংসের মুলতুবি কাজগুলি বাতিল করে। এটি একটি ভেরিয়েবল বজায় রাখে যা বার্তা লুপে মুলতুবি থাকা টাস্কের টাস্ক আইডি ট্র্যাক করে। ধ্বংস করার সময়, সেগফল্ট এড়াতে মুলতুবি কাজটি বাতিল করা হয়।
মার্জ করার সময় update_engine এ SIGSEGV ক্র্যাশগুলি ঠিক করতে আপনার Android 11 সোর্স ট্রিতে নিম্নলিখিত পরিবর্তনগুলি রয়েছে তা নিশ্চিত করুন:
- CL 1439792 (CL 1439372 এর পূর্বশর্ত)
- CL 1439372 (
CleanupPreviousUpdateAction: ধ্বংসের মুলতুবি কাজগুলি বাতিল করুন) - CL 1663460 (
markSlotSuccessfulদেরিতে এলে সম্ভাব্য ওয়াইল্ড পয়েন্টার ত্রুটি ঠিক করুন)
আপডেট_ইঞ্জিন অকাল মার্জ প্রতিরোধ করুন
যখন একটি ডিভাইস বুট হয় (Android 11 এবং উচ্চতর), এবং বুট সম্পূর্ণ হয়, update_engine কল করে ScheduleWaitMarkBootSuccessful() , এবং WaitForMergeOrSchedule() । এটি মার্জ প্রক্রিয়া শুরু করে। যাইহোক, ডিভাইসটি পুরানো স্লটে রিবুট হয়। যেহেতু মার্জ ইতিমধ্যেই শুরু হয়েছে, ডিভাইসটি বুট করতে ব্যর্থ হয় এবং অকার্যকর হয়ে যায়।
আপনার উৎস গাছে নিম্নলিখিত পরিবর্তন যোগ করুন। মনে রাখবেন যে CL 1664859 ঐচ্ছিক।
- CL 1439792 (CL 1439372 এর পূর্বশর্ত)
- CL 1439372 (
CleanupPreviousUpdateAction: ধ্বংসের মুলতুবি কাজগুলি বাতিল করুন) - CL 1663460 (
markSlotSuccessfulদেরিতে এলে সম্ভাব্য ওয়াইল্ড পয়েন্টার ত্রুটি ঠিক করুন) - CL 1664859 (ঐচ্ছিক -
CleanupPreviousUpdateActionএর জন্যunittestযোগ করুন)
সঠিক dm-verity কনফিগারেশন নিশ্চিত করুন
অ্যান্ড্রয়েড 11 এবং উচ্চতর, ডিভাইসগুলি অসাবধানতাবশত নিম্নলিখিত dm-verity বিকল্পগুলির সাথে কনফিগার করা যেতে পারে:
- কার্নেলে
CONFIG_DM_VERITY_AVB=y - বুটলোডার
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIOছাড়া যেকোন সত্যতা মোড, (যেমনAVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) ব্যবহার করার জন্য কনফিগার করা হয়েছে।
এই ডিভাইস কনফিগারেশনের সাথে, যেকোন সত্যতা ত্রুটির কারণে vbmeta পার্টিশনটি নষ্ট হয়ে যায় এবং নন-A/B ডিভাইসগুলিকে অকার্যকর করে তোলে। একইভাবে, যদি একটি মার্জ শুরু হয়, তাহলে A/B ডিভাইসগুলিও অকার্যকর হয়ে যেতে পারে। শুধুমাত্র AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO যাচাই মোড ব্যবহার করুন৷
- কার্নেলে
CONFIG_DM_VERITY_AVB=nসেট করুন। - পরিবর্তে
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIOমোড ব্যবহার করতে ডিভাইসগুলি কনফিগার করুন৷
আরও তথ্যের জন্য যাচাই ডকুমেন্টেশন উল্লেখ করুন: dm-verity Errors হ্যান্ডলিং ।
মার্জ করা ফাইলটি সঠিকভাবে কনফিগার করা হয়েছে তা নিশ্চিত করুন
আপনি যদি আলাদাভাবে সিস্টেম ইমেজ এবং ভেন্ডর ইমেজ তৈরি করেন, তাহলে merge_target_files ব্যবহার করে সেগুলিকে একত্রিত করার জন্য, ভার্চুয়াল A/B কনফিগারেশনগুলি মার্জ প্রক্রিয়া চলাকালীন ভুলভাবে বাদ দেওয়া হতে পারে। মার্জ করা টার্গেট ফাইলে ভার্চুয়াল A/B কনফিগারেশন সঠিক কিনা তা যাচাই করতে, নিম্নলিখিত প্যাচগুলি প্রয়োগ করুন: CL 2084183 (ডাইনামিক পার্টিশন তথ্যে অভিন্ন কী/ভাল জোড়া মার্জ করুন)
প্রয়োজনীয় উপাদান আপডেট করুন
অ্যান্ড্রয়েড 13 অনুযায়ী, snapuserd ভেন্ডর রামডিস্ক থেকে জেনেরিক রামডিস্কে সরানো হয়েছে। যদি আপনার ডিভাইসটি Android 13-এ আপগ্রেড করা হয়, তাহলে এটা সম্ভব যে বিক্রেতা র্যামডিস্ক এবং জেনেরিক র্যামডিস্ক উভয়েই snapuserd একটি কপি রয়েছে। এই পরিস্থিতিতে, ভার্চুয়াল A/B-এর জন্য snapuserd এর সিস্টেম কপি প্রয়োজন। snapuserd এর সঠিক কপি জায়গায় আছে তা নিশ্চিত করতে, CL 2031243 ( snapuserd কপি first_stage_ramdisk) প্রয়োগ করুন।