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

Android 9 বুটলোডার বুট কারণ স্পেসিফিকেশন নিম্নলিখিত পরিবর্তন অন্তর্ভুক্ত.

বুট কারণ

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

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

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

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

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

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

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

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

বুটস্ট্যাট যুক্তি নির্ভর করে আরও তথ্যপূর্ণ এবং অনুগত 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" (পছন্দের)।

কারণ-উপরেজন সমন্বয়

অ্যান্ড্রয়েড 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 এবং Android সোর্স রিপোজিটরিতে সংশ্লিষ্ট গিট চেঞ্জলগ ইতিহাস দেখুন।

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

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

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

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

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

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

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

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

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

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