ক্যানোনিকাল বুট কারণ

অ্যান্ড্রয়েড ৯-এ বুটলোডার বুট রিজন স্পেসিফিকেশনে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

বুটের কারণ

একটি বুটলোডার কোনো ডিভাইস কেন রিবুট হয়েছে তা নির্ধারণ করতে বিশেষভাবে উপলব্ধ হার্ডওয়্যার এবং মেমরি রিসোর্স ব্যবহার করে, এবং তারপর সেই নির্ধারণের বিষয়টি জানানোর জন্য ডিভাইসটি চালু করার সময় অ্যান্ড্রয়েড কার্নেল কমান্ড লাইনে androidboot.bootreason=<reason> যোগ করে। এরপর init এই কমান্ড লাইনটিকে অনুবাদ করে অ্যান্ড্রয়েড প্রপার্টি bootloader_boot_reason_prop ( ro.boot.bootreason )-এ তা প্রয়োগ করে। অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণে চালু হওয়া ডিভাইসগুলোর ক্ষেত্রে, যেগুলোতে কার্নেল ভার্সন ৫.১০ বা তার বেশি ব্যবহৃত হয়, সেখানে কার্নেল কমান্ড লাইনের পরিবর্তে bootconfig-এ androidboot.bootreason=<reason> যোগ করা হয়।

বুট কারণের স্পেসিফিকেশন

অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে একটি বুট রিজন ফরম্যাট নির্দিষ্ট করা ছিল, যেখানে কোনো স্পেস থাকত না, সব অক্ষর ছোট হাতের হতো, খুব কম শর্ত থাকত (যেমন kernel_panic , watchdog , cold / warm / hard রিপোর্ট করার জন্য), এবং অন্যান্য স্বতন্ত্র কারণের জন্যও ছাড় দেওয়া হতো। এই শিথিল নির্দিষ্টকরণের ফলে শত শত কাস্টম (এবং কখনও কখনও অর্থহীন) বুট রিজন স্ট্রিংয়ের ব্যাপক বিস্তার ঘটে, যা ফলস্বরূপ একটি নিয়ন্ত্রণহীন পরিস্থিতির সৃষ্টি করে। অ্যান্ড্রয়েডের বর্তমান সংস্করণে, বুটলোডার দ্বারা ফাইল করা প্রায় পার্স-অযোগ্য বা অর্থহীন কন্টেন্টের বিপুল পরিমাণ bootloader_boot_reason_prop এর জন্য কমপ্লায়েন্স সমস্যা তৈরি করেছে।

অ্যান্ড্রয়েড ৯ প্রকাশের সাথে সাথে, অ্যান্ড্রয়েড টিম উপলব্ধি করছে যে পুরোনো bootloader_boot_reason_prop যথেষ্ট জনপ্রিয়তা রয়েছে এবং এটিকে রানটাইমে নতুন করে লেখা সম্ভব নয়। সুতরাং, বুট রিজন স্পেসিফিকেশনের যেকোনো উন্নতি অবশ্যই বুটলোডার ডেভেলপারদের সাথে আলোচনা এবং বিদ্যমান সিস্টেমে কিছু ছোটখাটো পরিবর্তনের মাধ্যমে করতে হবে। এই লক্ষ্যে অ্যান্ড্রয়েড টিম যা করছে তা হলো:

• বুটলোডার ডেভেলপারদের উৎসাহিত করার জন্য তাদের সাথে সম্পৃক্ত হওয়া:
  • bootloader_boot_reason_prop কে প্রামাণিক, পার্সযোগ্য এবং শনাক্তযোগ্য কারণ প্রদান করুন।
  • system/core/bootstat/bootstat.cpp kBootReasonMap তালিকায় অংশগ্রহণ করুন।
• system_boot_reason_prop ( sys.boot.reason )-এর একটি নিয়ন্ত্রিত এবং রানটাইমে পুনঃলিখনযোগ্য উৎস যোগ করা। সীমিত সংখ্যক সিস্টেম অ্যাপ (যেমন bootstat এবং init ) এই প্রপার্টিটি পুনঃলিখন করতে পারে, কিন্তু সমস্ত অ্যাপকে এটি পড়ার জন্য sepolicy অধিকার দেওয়া যেতে পারে।
• সিস্টেম বুট রিজন প্রপার্টি system_boot_reason_prop এর বিষয়বস্তু বিশ্বাস করার আগে ইউজারডেটা মাউন্ট হওয়া পর্যন্ত অপেক্ষা করার জন্য ব্যবহারকারীদের বুটের কারণ সম্পর্কে অবহিত করা।

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

• ইউজারডেটা মাউন্ট হওয়ার আগে , system_boot_reason_prop bootloader_boot_reason_prop থেকে মানটি থাকবে।
• ইউজারডেটা মাউন্ট হওয়ার পরে , system_boot_reason_prop সামঞ্জস্যপূর্ণ হতে বা আরও সঠিক তথ্য প্রদানের জন্য আপডেট করা হতে পারে।

এই কারণে, অ্যান্ড্রয়েড ৯ বুট কারণটি আনুষ্ঠানিকভাবে পাওয়ার সময়কাল বাড়িয়ে দিয়েছে, এবং এটিকে বুট করার সাথে সাথেই সঠিক হওয়ার ( bootloader_boot_reason_prop এর মাধ্যমে) পরিবর্তে শুধুমাত্র ইউজারডেটা মাউন্ট হওয়ার পরেই উপলব্ধ করে ( system_boot_reason_prop এর মাধ্যমে)।

বুটস্ট্যাট লজিক আরও তথ্যবহুল এবং সঙ্গতিপূর্ণ bootloader_boot_reason_prop উপর নির্ভর করে। যখন সেই প্রপার্টিটি একটি অনুমানযোগ্য ফরম্যাট ব্যবহার করে, তখন এটি সমস্ত নিয়ন্ত্রিত রিবুট এবং শাটডাউন পরিস্থিতির নির্ভুলতা উন্নত করে, যা ফলস্বরূপ system_boot_reason_prop এর নির্ভুলতা এবং অর্থকে পরিমার্জিত ও প্রসারিত করে।

ক্যানোনিকাল বুট কারণ ফর্ম্যাট

অ্যান্ড্রয়েড ৯-এ bootloader_boot_reason_prop এর জন্য প্রমিত বুট কারণ ফরম্যাটটি নিম্নলিখিত সিনট্যাক্স ব্যবহার করে:

<reason>,<subreason>,<detail>…

বিন্যাস নিয়মাবলী:

• ছোট হাতের অক্ষর
• কোনো ফাঁকা স্থান নেই (আন্ডারলাইন ব্যবহার করুন)
• সমস্ত মুদ্রণযোগ্য অক্ষর
• কমা দ্বারা পৃথক করা reason , subreason এবং এক বা একাধিক detail বিবরণ।
  • একটি আবশ্যক reason যা ডিভাইসটি রিবুট বা শাটডাউন করার সর্বোচ্চ অগ্রাধিকারের কারণটিকে উপস্থাপন করে।
  • একটি ঐচ্ছিক subreason যা ডিভাইসটি কেন রিবুট বা শাটডাউন করতে হয়েছিল (অথবা কে ডিভাইসটি রিবুট বা শাটডাউন করেছিল) তার একটি সংক্ষিপ্ত সারসংক্ষেপ উপস্থাপন করে।
  • এক বা একাধিক ঐচ্ছিক detail ভ্যালু। কোন নির্দিষ্ট সিস্টেমটির কারণে subreason ঘটেছে তা নির্ধারণে সহায়তার জন্য একটি detail কোনো সাবসিস্টেমকে নির্দেশ করতে পারে। আপনি একাধিক detail ভ্যালু নির্দিষ্ট করতে পারেন, যেগুলো সাধারণত গুরুত্বের একটি ক্রম অনুসরণ করবে। তবে, সমান গুরুত্বের একাধিক detail ভ্যালু রিপোর্ট করাও গ্রহণযোগ্য।

bootloader_boot_reason_prop এর জন্য একটি খালি মান অবৈধ বলে বিবেচিত হয় (কারণ এটি অন্যান্য এজেন্টদেরকে পরবর্তীতে একটি বুট কারণ যুক্ত করার সুযোগ দেয়)।

কারণের প্রয়োজনীয়তা

reason হিসেবে প্রদত্ত মান (প্রথম স্প্যান, সমাপ্তির পূর্বে বা কমা) অবশ্যই নিম্নলিখিত সেট থেকে হতে হবে, যা কার্নেল, স্ট্রং এবং ব্লান্ট কারণ—এই তিন ভাগে বিভক্ত:

• কার্নেল সেট:
  • " watchdog"
  • "kernel_panic"
• শক্তিশালী সেট:
  • "recovery"
  • "bootloader"
• ভোঁতা সেট:
  • "cold" . সাধারণত মেমরি সহ সমস্ত ডিভাইসের সম্পূর্ণ রিসেট বোঝায়।
  • "hard" . সাধারণত বোঝায় যে হার্ডওয়্যারের অবস্থা রিসেট করা হয়েছে এবং ramoops স্থায়ী বিষয়বস্তু ধরে রাখবে।
  • "warm" সাধারণত বোঝায় যে মেমোরি এবং ডিভাইসগুলো কিছু স্টেট ধরে রাখে, এবং ramoops ) (কার্নেলের pstore ড্রাইভার দেখুন) ব্যাকস্টোরে স্থায়ী কন্টেন্ট থাকে।
  • "shutdown"
  • "reboot" । সাধারণত এর অর্থ হলো ramoops অবস্থা এবং হার্ডওয়্যারের অবস্থা অজানা। এই মানটি একটি সর্বব্যাপী নির্দেশক, কারণ কোল্ড ( cold ), hard ) এবং warm মানগুলো ডিভাইসটির রিসেটের গভীরতা সম্পর্কে সূত্র প্রদান করে।

বুটলোডারকে অবশ্যই একটি কার্নেল সেট বা ব্লান্ট সেট reason প্রদান করতে হবে, এবং যদি একটি subreason নির্ধারণ করা সম্ভব হয় তবে তা প্রদান করতে জোরালোভাবে উৎসাহিত করা হয়। উদাহরণস্বরূপ, পাওয়ার কী দীর্ঘক্ষণ চেপে রাখার ক্ষেত্রে, যেখানে ramoops ব্যাকআপ থাকতেও পারে বা নাও থাকতে পারে, তার বুট কারণ হবে "reboot,longkey" ।

কোনো ফার্স্ট-স্প্যান reason কোনো subreason বা detail অংশ হতে পারে না। তবে, যেহেতু কার্নেল সেট রিজন ইউজার স্পেস দ্বারা তৈরি করা যায় না, তাই একটি ব্লান্ট সেট রিজনের পরে সোর্সের ডিটেইলসহ "watchdog" পুনরায় ব্যবহার করা যেতে পারে (উদাহরণস্বরূপ, "reboot,watchdog,service_manager_unresponsive" বা "reboot,software,watchdog" )।

বুট হওয়ার কারণগুলো বোঝার জন্য বিশেষজ্ঞ অভ্যন্তরীণ জ্ঞানের প্রয়োজন হওয়া উচিত নয় এবং/অথবা এটি একটি স্বজ্ঞাত প্রতিবেদনের মাধ্যমে মানুষের পাঠযোগ্য হওয়া উচিত। উদাহরণ: "shutdown,vbxd" (খারাপ), "shutdown,uv" (ভালো), "shutdown,undervoltage" (পছন্দনীয়)।

কারণ-উপকারণ সংমিশ্রণ

অ্যান্ড্রয়েড কিছু নির্দিষ্ট reason ও subreason -কারণ সংমিশ্রণ সংরক্ষণ করে, যা সাধারণ ব্যবহারে অতিরিক্ত ব্যবহার করা উচিত নয়, তবে ক্ষেত্রবিশেষে ব্যবহার করা যেতে পারে যদি সংমিশ্রণটি সংশ্লিষ্ট পরিস্থিতিকে সঠিকভাবে প্রতিফলিত করে। সংরক্ষিত সংমিশ্রণের উদাহরণগুলির মধ্যে রয়েছে:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" ( thermald থেকে)
• "shutdown,battery"
• "shutdown,battery,thermal" ( BatteryStatsService থেকে)
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

আরও বিস্তারিত জানতে, system/core/bootstat/bootstat.cpp এ থাকা kBootReasonMap এবং অ্যান্ড্রয়েড সোর্স রিপোজিটরিতে সংশ্লিষ্ট গিট চেঞ্জলগ হিস্ট্রি দেখুন।

বুট করার কারণ রিপোর্ট করুন

বুটলোডার থেকে আসা অথবা ক্যানোনিকাল বুট রিজনে নথিভুক্ত সমস্ত বুট রিজন অবশ্যই system/core/bootstat/bootstat.cpp ফাইলের kBootReasonMap সেকশনে নথিভুক্ত করতে হবে। kBootReasonMap তালিকাটি কমপ্লায়েন্ট এবং লিগ্যাসি নন-কমপ্লায়েন্ট রিজনের একটি মিশ্রণ। বুটলোডার ডেভেলপারদের এখানে শুধুমাত্র নতুন কমপ্লায়েন্ট রিজনগুলো রেজিস্টার করা উচিত (এবং নন-কমপ্লায়েন্ট রিজন রেজিস্টার করা উচিত নয়, যদি না প্রোডাক্টটি ইতিমধ্যে বাজারে চলে আসে এবং তা পরিবর্তন করা সম্ভব না হয়)।

আমরা system/core/bootstat/bootstat.cpp এ বিদ্যমান, সঙ্গতিপূর্ণ এন্ট্রিগুলি ব্যবহার করার এবং একটি অ-সঙ্গতিপূর্ণ স্ট্রিং ব্যবহার করার আগে সংযম অবলম্বন করার জন্য দৃঢ়ভাবে সুপারিশ করি। নির্দেশিকা হিসাবে, এটি হলো:

• বুটলোডার থেকে "kernel_panic" রিপোর্ট করা যেতে পারে , কারণ bootstat সম্ভবত ramoops এ kernel_panic signatures পরীক্ষা করে উপ-কারণগুলোকে পরিমার্জন করে প্রামাণিক system_boot_reason_prop এ পরিণত করতে পারে।
• বুটলোডার থেকে kBootReasonMap এ কোনো নিয়মবহির্ভূত স্ট্রিং (যেমন "panic") রিপোর্ট করা ঠিক নয় , কারণ এটি শেষ পর্যন্ত reason পরিমার্জন করার ক্ষমতা নষ্ট করে দেবে।

উদাহরণস্বরূপ, যদি kBootReasonMap "wdog_bark" থাকে, তাহলে একজন বুটলোডার ডেভেলপারের যা করা উচিত তা হলো:

• "watchdog,bark" এ পরিবর্তন করুন এবং kBootReasonMap এর তালিকায় যোগ করুন।
• যারা এই প্রযুক্তির সাথে অপরিচিত, তাদের জন্য "bark" শব্দটির অর্থ কী তা বিবেচনা করুন এবং এর চেয়ে আরও অর্থপূর্ণ কোনো subreason আছে কিনা তা নির্ধারণ করুন।

বুট কারণের সম্মতি যাচাই করুন

বর্তমানে, অ্যান্ড্রয়েড এমন কোনো সক্রিয় CTS টেস্ট প্রদান করে না যা একটি বুটলোডার দ্বারা সৃষ্ট সম্ভাব্য সমস্ত বুট কারণকে নির্ভুলভাবে সক্রিয় বা পরীক্ষা করতে পারে; তবে অংশীদাররা সামঞ্জস্যতা নির্ধারণের জন্য একটি নিষ্ক্রিয় পরীক্ষা চালানোর চেষ্টা করতে পারেন।

ফলস্বরূপ, বুটলোডার কমপ্লায়েন্সের জন্য বুটলোডার ডেভেলপারদের উপরে বর্ণিত নিয়ম ও নির্দেশিকাগুলির মূল উদ্দেশ্য স্বেচ্ছায় মেনে চলতে হবে। আমরা এই ধরনের ডেভেলপারদের AOSP-তে (বিশেষত system/core/bootstat/bootstat.cpp তে) অবদান রাখতে এবং বুট রিজন সংক্রান্ত সমস্যা নিয়ে আলোচনার জন্য এই সুযোগটিকে একটি ফোরাম হিসেবে ব্যবহার করতে উৎসাহিত করি।