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

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

বুট করার কারণ

কোনও ডিভাইস কেন রিবুট হয়েছে তা নির্ধারণ করতে বুটলোডার অনন্যভাবে উপলভ্য হার্ডওয়্যার ও মেমরি রিসোর্স ব্যবহার করে, তারপর সেটি লঞ্চ করার জন্য Android কার্নেল কমান্ড লাইনে androidboot.bootreason=<reason> যোগ করে সেই নির্ধারণ কমিউনিকেট করে। init তারপর এই কমান্ড লাইনকে Android প্রপার্টি bootloader_boot_reason_prop (ro.boot.bootreason)-এ প্রোপাগেট করার জন্য অনুবাদ করে। Android 12 বা তার পরবর্তী যেকোনও ভার্সন সহ লঞ্চ হওয়া ডিভাইসের ক্ষেত্রে, কার্নেল ভার্সন 5.10 বা তার পরবর্তী যেকোনও ভার্সন ব্যবহার করে, androidboot.bootreason=<reason> কার্নেল কমান্ড লাইনের পরিবর্তে bootconfig-এ যোগ করা হয়।

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

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

Android 9 রিলিজের সাথে, Android টিম স্বীকার করে যে পুরনো bootloader_boot_reason_prop-এর গুরুত্বপূর্ণ মোমেন্টাম আছে এবং রানটাইমে এটি আবার লেখা যাবে না। বুট হওয়ার কারণের স্পেসিফিকেশনে কোনও উন্নতি করতে হলে, বুটলোডার ডেভেলপারদের সাথে ইন্টার‍্যাকশন এবং আগে থেকে থাকা সিস্টেমে পরিবর্তন করতে হবে। এই উদ্দেশ্যে Android টিম:

• বুটলোডার ডেভেলপারদের সাথে যোগাযোগ করে তাদের এইসব করতে উৎসাহিত করা:
  • 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 বুট করার সময় প্রথম দিকে উপলভ্য থাকলেও, Android নিরাপত্তা নীতি অনুসারে প্রয়োজন মতো এটি ব্লক করা হয়, কারণ এটি ভুল, পার্স করা যায় না এমন এবং নন-ক্যাননিক্যাল তথ্য দেখায়। বেশিরভাগ ক্ষেত্রে, শুধুমাত্র বুট সিস্টেম সম্পর্কে গভীর জ্ঞান আছে এমন ডেভেলপারদের এই তথ্য অ্যাক্সেস করার প্রয়োজন। system_boot_reason_prop সহ বুট করার কারণের জন্য একটি পরিমার্জিত, পার্স করা যায় এবং প্রামাণিক API নির্ভরযোগ্যভাবে এবং সঠিকভাবে শুধুমাত্র পরে ব্যবহারকারীর ডেটা মাউন্ট করা হলে পাওয়া যেতে পারে। বিশেষত:

• আগে ব্যবহারকারীর ডেটা মাউন্ট করা হয়েছে, system_boot_reason_prop-এ bootloader_boot_reason_prop-এর ভ্যালু থাকবে।
• userdata মাউন্ট করার পরে, system_boot_reason_prop আপডেট করা হতে পারে যাতে তা মেনে চলা হয় অথবা আরও সঠিক তথ্য রিপোর্ট করা যায়।

এই কারণে, Android 9 বুট করার কারণ আনুষ্ঠানিকভাবে পাওয়ার আগে সময়সীমা বাড়িয়ে দেয়। এর ফলে, বুট করার সময় (bootloader_boot_reason_prop সহ) সাথে সাথেই সঠিক তথ্য পাওয়ার পরিবর্তে, এখন শুধুমাত্র ব্যবহারকারীর ডেটা মাউন্ট করার পরে (system_boot_reason_prop সহ) এই তথ্য উপলভ্য হয়।

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

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

Android 9-এ bootloader_boot_reason_prop -এর জন্য ক্যাননিকাল বুট কারণ ফর্ম্যাট নিম্নলিখিত সিনট্যাক্স ব্যবহার করে:

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

ফর্ম্যাটিং সংক্রান্ত নিয়ম:

• লোয়ার কেস
• কোনও ফাঁকা জায়গা নেই (আন্ডারলাইন ব্যবহার করুন)
• প্রিন্ট করা যাবে এমন সব অক্ষর
• কমা দিয়ে আলাদা করা reason, subreason এবং এক বা একাধিক detail ইনস্ট্যান্স।
  • একটি প্রয়োজনীয় reason যা সবচেয়ে বেশি অগ্রাধিকারের কারণ দেখায় যে কেন ডিভাইস রিবুট বা শাটডাউন করতে হয়েছে।
  • একটি ঐচ্ছিক subreason যা ডিভাইসটি কেন রিবুট বা বন্ধ করতে হয়েছিল (বা কে ডিভাইসটি রিবুট বা বন্ধ করেছিল) তার একটি সংক্ষিপ্ত সারসংক্ষেপ দেখায়।
  • এক বা একাধিক ঐচ্ছিক detail ভ্যালু। detail একটি সাবসিস্টেমকে নির্দেশ করতে পারে যা নির্ধারণ করতে সাহায্য করে যে কোন নির্দিষ্ট সিস্টেমের কারণে subreason হয়েছে। আপনি একাধিক 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" (পছন্দসই)।

কারণ-উপকারণের কম্বিনেশন

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

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

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

বুট করার কারণ সম্পর্কে অভিযোগ জানানো

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

আমরা সাজেস্ট করি যে আপনি system/core/bootstat/bootstat.cpp-এ আগে থেকে থাকা, নিয়ম মেনে চলা এন্ট্রি ব্যবহার করুন এবং নিয়ম মেনে না চলা স্ট্রিং ব্যবহার করার আগে সাবধানে কাজ করুন। নির্দেশিকা হিসেবে এটি হল:

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

যেমন, kBootReasonMap-এ "wdog_bark" থাকলে, বুটলোডার ডেভেলপারকে এগুলি করতে হবে:

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

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

এই মুহূর্তে, Android এমন কোনও অ্যাক্টিভ CTS টেস্ট প্রদান করে না যা বুটলোডার প্রদান করতে পারে এমন সম্ভাব্য সমস্ত বুট কারণকে সঠিকভাবে ট্রিগার বা পরিদর্শন করতে পারে; পার্টনাররা এখনও মানানসই কিনা তা নির্ধারণ করতে প্যাসিভ টেস্ট চালানোর চেষ্টা করতে পারেন।

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