রিজুমে-অন-রিবুট

অ্যান্ড্রয়েড ১১-এ, RecoverySystem ক্লাস মেথডগুলোর সাথে A/B আপডেট বা ভার্চুয়াল A/B আপডেট পদ্ধতি ব্যবহার করে OTA আপডেট প্রয়োগ করা যায়। একটি OTA আপডেট প্রয়োগ করার জন্য ডিভাইসটি রিবুট হওয়ার পর, Resume-on-Reboot (RoR) ডিভাইসটির Credential Encrypted (CE) স্টোরেজ আনলক করে দেয়।

যদিও অ্যান্ড্রয়েড ১১-এ পার্টনাররা এই প্রক্রিয়াটিকে একটি OTA সিস্টেম ফিচারের সাথে যুক্ত করতে পারত, যা ডিভাইসটি নিষ্ক্রিয় থাকার সময় আপডেট প্রয়োগ করত, অ্যান্ড্রয়েড ১২-এ পার্টনারদের কোনো অতিরিক্ত OTA সিস্টেম ফিচারের প্রয়োজন নেই। RoR প্রক্রিয়াটি ব্যবহারকারীদের অতিরিক্ত নিরাপত্তা এবং সুবিধা প্রদান করে, কারণ ডিভাইস নিষ্ক্রিয় থাকার সময়েও আপডেটগুলো করা যায়, অন্যদিকে অ্যান্ড্রয়েড ১২-এর মাল্টি-ক্লায়েন্ট এবং সার্ভার-ভিত্তিক আপডেট কার্যকারিতাগুলো একত্রে ডিভাইসের হার্ডওয়্যার-স্তরের নিরাপত্তা প্রদান করে।

যদিও অ্যান্ড্রয়েড ১১-এ RoR সমর্থন করার জন্য android.hardware.reboot_escrow ফিচারটির জন্য আপনাকে ডিভাইসের অনুমতি দিতে হবে, অ্যান্ড্রয়েড ১২ এবং তার পরবর্তী সংস্করণগুলিতে সার্ভার-ভিত্তিক RoR চালু করার জন্য এটি করার প্রয়োজন নেই, কারণ সেগুলি HAL ব্যবহার করে না।

পটভূমি

অ্যান্ড্রয়েড ৭ থেকে শুরু করে, অ্যান্ড্রয়েড ডিরেক্ট বুট সমর্থন করে, যা ব্যবহারকারী কর্তৃক সিই স্টোরেজ আনলক করার আগেই ডিভাইসের অ্যাপগুলোকে চালু হতে সক্ষম করে। ডিরেক্ট বুট সমর্থনের বাস্তবায়ন ব্যবহারকারীদের একটি উন্নততর অভিজ্ঞতা প্রদান করেছিল, যতক্ষণ না বুট করার পরে লক স্ক্রিন নলেজ ফ্যাক্টর (LSKF) প্রবেশ করানোর প্রয়োজন পড়ত।

OTA আপডেটের পর ডিভাইস রিবুট করা হলে, RoR-এর মাধ্যমে ডিভাইসের সমস্ত অ্যাপের CE স্টোরেজ আনলক করা যায়, এমনকি যেগুলো ডিরেক্ট বুট সাপোর্ট করে না সেগুলোরও। এই ফিচারটি ব্যবহারকারীদের রিবুটের পরেও তাদের ইনস্টল করা সমস্ত অ্যাপ থেকে নোটিফিকেশন পেতে সক্ষম করে।

হুমকি মডেল

RoR-এর একটি বাস্তবায়নকে অবশ্যই নিশ্চিত করতে হবে যে, যখন কোনো ডিভাইস আক্রমণকারীর হাতে পড়ে, তখন আক্রমণকারীর পক্ষে ব্যবহারকারীর CE-এনক্রিপ্টেড ডেটা পুনরুদ্ধার করা অত্যন্ত কঠিন হবে; এমনকি যদি ডিভাইসটি চালু থাকে, CE স্টোরেজ আনলক করা থাকে, এবং ব্যবহারকারী OTA আপডেট পাওয়ার পর ডিভাইসটি আনলক করেন। আক্রমণকারী যদি ব্রডকাস্ট ক্রিপ্টোগ্রাফিক সাইনিং কী-গুলোর অ্যাক্সেস পেয়েও যায়, তবুও ইনসাইডার অ্যাটাক প্রতিরোধ ব্যবস্থা কার্যকর থাকতে হবে।

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

সক্ষমতা

• যেকোনো ভেন্ডর বা কোম্পানির সাইনিং কী ব্যবহার করে যেকোনো মেসেজ সাইন করা যায়।
• এর ফলে ডিভাইসটিতে একটি OTA আপডেট আসতে পারে।
• যেকোনো হার্ডওয়্যারের (যেমন অ্যাপ্লিকেশন প্রসেসর, বা ফ্ল্যাশ মেমরি) কার্যকারিতা পরিবর্তন করতে পারে - তবে নিচে সীমাবদ্ধতা অংশে বিস্তারিতভাবে বর্ণিত ক্ষেত্রগুলো এর ব্যতিক্রম। (তবে, এই ধরনের পরিবর্তনের ফলে কমপক্ষে এক ঘণ্টার বিলম্ব ঘটে এবং পাওয়ার সাইকেল সম্পন্ন হয়, যা র‍্যামের বিষয়বস্তু ধ্বংস করে দেয়।)

সীমাবদ্ধতা

• টেম্পার-রেজিস্ট্যান্ট হার্ডওয়্যারের (যেমন, একটি টাইটান এম) কার্যকারিতা পরিবর্তন করা যায় না।
• লাইভ ডিভাইসটির র‍্যাম পড়া যাচ্ছে না।
• ব্যবহারকারীর পরিচয়পত্র (পিন, প্যাটার্ন, পাসওয়ার্ড) অনুমান করা যায় না বা অন্য কোনোভাবে তা প্রবেশ করানো যায় না।

সমাধান

অ্যান্ড্রয়েড ১২ RoR আপডেট সিস্টেম অত্যন্ত দক্ষ আক্রমণকারীদের বিরুদ্ধে নিরাপত্তা প্রদান করে এবং এটি এমনভাবে করে যাতে ডিভাইসের পাসওয়ার্ড ও পিন ডিভাইসেই থেকে যায়—এগুলো কখনোই গুগল সার্ভারে পাঠানো বা সংরক্ষণ করা হয় না। যে প্রক্রিয়াটি নিশ্চিত করে যে প্রদত্ত নিরাপত্তার স্তর একটি হার্ডওয়্যার-ভিত্তিক, ডিভাইস-স্তরের RoR সিস্টেমের অনুরূপ, তার একটি সংক্ষিপ্ত বিবরণ নিচে দেওয়া হলো:

• অ্যান্ড্রয়েড ডিভাইসে সংরক্ষিত ডেটার ওপর ক্রিপ্টোগ্রাফিক সুরক্ষা প্রয়োগ করে।
• সমস্ত ডেটা বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট (TEE)-এ সংরক্ষিত কী দ্বারা সুরক্ষিত থাকে।
• TEE শুধুমাত্র তখনই কী-গুলো রিলিজ করে, যখন চলমান অপারেটিং সিস্টেম ক্রিপ্টোগ্রাফিক অথেনটিকেশন ( ভেরিফায়েড বুট ) পাস করে।
• গুগল সার্ভারে চলমান RoR পরিষেবাটি একটি গোপনীয় তথ্য সংরক্ষণের মাধ্যমে CE ডেটা সুরক্ষিত করে, যা শুধুমাত্র সীমিত সময়ের জন্য পুনরুদ্ধার করা যায়। এটি সমগ্র অ্যান্ড্রয়েড ইকোসিস্টেম জুড়ে কাজ করে।
• ব্যবহারকারীর পিন দ্বারা সুরক্ষিত একটি ক্রিপ্টোগ্রাফিক কী ডিভাইসটি আনলক করতে এবং সিই স্টোরেজ ডিক্রিপ্ট করতে ব্যবহৃত হয়।
  • যখন রাতে রিবুট করার জন্য সময় নির্ধারণ করা হয়, তখন অ্যান্ড্রয়েড ব্যবহারকারীকে তার পিন প্রবেশ করতে বলে এবং তারপর একটি সিন্থেটিক পাসওয়ার্ড (SP) তৈরি করে।
  • এরপর এটি SP-টিকে দুইবার এনক্রিপ্ট করে: একবার RAM-এ সংরক্ষিত K_s কী দিয়ে, এবং আবার TEE-তে সংরক্ষিত K_k কী দিয়ে।
  • দ্বৈত-এনক্রিপ্টেড এসপি (SP) ডিস্কে সংরক্ষিত থাকে এবং র‍্যাম থেকে তা মুছে ফেলা হয়। উভয় কী নতুন করে তৈরি করা হয় এবং শুধুমাত্র একবার রিবুট করার জন্য ব্যবহৃত হয়।
• রিবুট করার সময় হলে, অ্যান্ড্রয়েড K_s সার্ভারের কাছে অর্পণ করে। K_k সহ রসিদটি ডিস্কে সংরক্ষণ করার আগে এনক্রিপ্ট করা হয়।
• রিবুটের পরে, অ্যান্ড্রয়েড রসিদটি ডিক্রিপ্ট করার জন্য K_k ব্যবহার করে, তারপর K_s পুনরুদ্ধার করার জন্য সেটি সার্ভারে পাঠায়।
  • ডিস্কে সংরক্ষিত SP ডিক্রিপ্ট করার জন্য K_k এবং K_s ব্যবহার করা হয়।
  • অ্যান্ড্রয়েড সিই স্টোরেজ আনলক করতে এবং অ্যাপগুলোকে স্বাভাবিকভাবে চালু করার অনুমতি দিতে এসপি ব্যবহার করে।
  • K_k এবং K_s বাদ দেওয়া হয়।

যে আপডেটগুলো আপনার ফোনকে সুরক্ষিত রাখে, সেগুলো আপনার সুবিধামতো সময়ে হতে পারে: যখন আপনি ঘুমিয়ে থাকেন।

সিম-পিন রিপ্লে

নির্দিষ্ট কিছু পরিস্থিতিতে একটি সিম কার্ডের পিন কোড ক্যাশ থেকে যাচাই করা হয়, এই প্রক্রিয়াটিকে সিম-পিন রিপ্লে বলা হয়।

একটি সক্রিয় পিনযুক্ত সিম কার্ডকে সেলুলার সংযোগ পুনরুদ্ধার করার জন্য (যা ফোন কল, এসএমএস এবং ডেটা পরিষেবার জন্য আবশ্যক) স্বয়ংক্রিয় রিবুটের পরে একটি নির্বিঘ্ন পিন কোড যাচাইকরণের (সিম-পিন রিপ্লে) মধ্য দিয়ে যেতে হয়। সিম পিন এবং এর সাথে সম্পর্কিত সিম কার্ডের তথ্য (আইসিসিআইডি এবং সিম স্লট নম্বর) একসাথে নিরাপদে সংরক্ষণ করা হয়। সংরক্ষিত পিনটি শুধুমাত্র একটি সফল স্বয়ংক্রিয় রিবুটের পরেই পুনরুদ্ধার করা এবং যাচাইকরণের জন্য ব্যবহার করা যায়। যদি ডিভাইসটি সুরক্ষিত থাকে, তবে সিম পিনটি এলএসকেএফ (LSKF) দ্বারা সুরক্ষিত কী-এর সাথে সংরক্ষণ করা হয়। যদি সিমে পিন সক্রিয় থাকে, তবে ওটিএ আপডেট এবং সার্ভার-ভিত্তিক RoR-এর জন্য RoR সার্ভারের সাথে সংযোগের জন্য একটি ওয়াইফাই সংযোগের প্রয়োজন হয় , যা রিবুটের পরে (সেলুলার সংযোগ সহ) মৌলিক কার্যকারিতা নিশ্চিত করে।

প্রতিবার ব্যবহারকারী সফলভাবে সিম পিন সক্রিয়, যাচাই বা পরিবর্তন করলে, এটি পুনরায় এনক্রিপ্ট করে সংরক্ষণ করা হয়। নিম্নলিখিত যেকোনো একটি ঘটলে সিম পিনটি বাতিল হয়ে যায়:

• সিমটি সরানো বা রিসেট করা হয়েছে।
• ব্যবহারকারী পিনটি নিষ্ক্রিয় করে দেন।
• RoR দ্বারা শুরু না হওয়া একটি রিবুট ঘটেছে।

RoR-এর মাধ্যমে চালু হওয়া রিবুটের পর সংরক্ষিত সিম পিনটি শুধুমাত্র একবার এবং খুব অল্প সময়ের জন্য (২০ সেকেন্ড) ব্যবহার করা যাবে— যদি সিম কার্ডের বিবরণ মিলে যায়। সংরক্ষিত সিম পিনটি কখনোই TelephonyManager অ্যাপের বাইরে যায় না এবং এটি কোনো বাহ্যিক মডিউল দ্বারা পুনরুদ্ধার করা যায় না।

বাস্তবায়ন নির্দেশিকা

অ্যান্ড্রয়েড ১২-এ, মাল্টি-ক্লায়েন্ট এবং সার্ভার-ভিত্তিক RoR ফাংশনগুলো পার্টনারদের OTA আপডেট পাঠানোর সময় তাদের উপর চাপ কমিয়ে দেয়। প্রয়োজনীয় আপডেটগুলো ডিভাইসের সুবিধাজনক ডাউনটাইমে, যেমন নির্দিষ্ট স্লিপ আওয়ারের সময়, সম্পন্ন হতে পারে।

এই সময়কালে OTA আপডেট যেন ব্যবহারকারীদের বিরক্ত না করে, তা নিশ্চিত করতে আলোর নির্গমন কমাতে ডার্ক মোড ব্যবহার করুন। এটি করার জন্য, ডিভাইসের বুটলোডারকে 'reason unattended স্ট্রিংটি খুঁজতে বলুন। যদি unattended মান true হয়, তাহলে ডিভাইসটিকে ডার্ক মোডে রাখুন। মনে রাখবেন যে, শব্দ এবং আলোর নির্গমন কমানো প্রতিটি OEM-এর দায়িত্ব।

আপনি যদি অ্যান্ড্রয়েড ১২-এ আপগ্রেড করেন অথবা অ্যান্ড্রয়েড ১২ চালিত ডিভাইস চালু করেন, তবে নতুন RoR কার্যকারিতাটি প্রয়োগ করার জন্য আপনাকে কিছু করতে হবে না।

মাল্টি-ক্লায়েন্ট ফ্লোতে একটি নতুন কল যুক্ত হয়েছে, isPreparedForUnattendedUpdate , যা নিচে দেখানো হলো:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

আপনাকে এটি প্রয়োগ করতে হবে না, কারণ অ্যান্ড্রয়েড ১২ থেকে HAL অপ্রচলিত হয়ে গেছে।

টেলিফোনি ম্যানেজার

অ্যান্ড্রয়েড ১২-এ রিবুট আসন্ন হলে OTA ক্লায়েন্ট TelephonyManager সিস্টেম API-কে কল করে। এই API সমস্ত ক্যাশ করা পিন কোডকে AVAILABLE অবস্থা থেকে REBOOT_READY অবস্থায় নিয়ে যায়। TelephonyManager সিস্টেম API-টি বিদ্যমান REBOOT Manifest পারমিশন দ্বারা সুরক্ষিত।

 /**
    * The unattended reboot was prepared successfully.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;

   /**
    * The unattended reboot was prepared, but the user will need to manually
    * enter the PIN code of at least one SIM card present in the device.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;

   /**
    * The unattended reboot was not prepared due to generic error.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;

   /** @hide */
   @Retention(RetentionPolicy.SOURCE)
   @IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
           value = {
                   PREPARE_UNATTENDED_REBOOT_SUCCESS,
                   PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
                   PREPARE_UNATTENDED_REBOOT_ERROR
           })
   public @interface PrepareUnattendedRebootResult {}

   /**
    * Prepare TelephonyManager for an unattended reboot. The reboot is
    * required to be done shortly after the API is invoked.
    *
    * Requires system privileges.
    *
    * <p>Requires Permission:
    *   {@link android.Manifest.permission#REBOOT}
    *
    * @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
    * {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
    * at least one SIM card for which the user needs to manually enter the PIN
    * code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
    * of error.
    * @hide
    */
   @SystemApi
   @RequiresPermission(android.Manifest.permission.REBOOT)
   @PrepareUnattendedRebootResult
   public int prepareForUnattendedReboot()

TelephonyManager সিস্টেম API বিশেষাধিকারপ্রাপ্ত APK-গুলো দ্বারা ব্যবহৃত হয়।

পরীক্ষা

নতুন API পরীক্ষা করতে, এই কমান্ডটি চালান:

    adb shell cmd phone unattended-reboot

এই কমান্ডটি শুধুমাত্র তখনই কাজ করে যখন শেলটি রুট হিসেবে চলে ( adb root )।

শুধুমাত্র অ্যান্ড্রয়েড ১১

এই পৃষ্ঠার বাকি অংশ অ্যান্ড্রয়েড ১১-এর ক্ষেত্রে প্রযোজ্য।

জুলাই ২০২০ পর্যন্ত, RoR HAL-এর বাস্তবায়ন দুটি শ্রেণীতে বিভক্ত:

1. যদি SoC হার্ডওয়্যার রিবুটের পরেও র‍্যামের স্থায়িত্ব সমর্থন করে, তাহলে OEM-রা AOSP-তে থাকা ডিফল্ট ইমপ্লিমেন্টেশন ( ডিফল্ট র‍্যাম এসক্রো ) ব্যবহার করতে পারেন।
2. যদি ডিভাইস হার্ডওয়্যার বা এসওসি একটি সুরক্ষিত হার্ডওয়্যার এনক্লেভ (নিজস্ব র‍্যাম এবং রম সহ একটি পৃথক নিরাপত্তা কোপ্রসেসর) সমর্থন করে, তবে অতিরিক্তভাবে এটিকে নিম্নলিখিত কাজগুলো অবশ্যই করতে হবে:
   • প্রধান সিপিইউ রিবুট শনাক্ত করতে সক্ষম।
   • এমন একটি হার্ডওয়্যার টাইমার সোর্স থাকতে হবে যা রিবুটের পরেও কার্যকর থাকে। অর্থাৎ, এনক্লেভটিকে অবশ্যই রিবুট শনাক্ত করতে এবং রিবুটের আগে সেট করা টাইমারটির মেয়াদ শেষ করতে সক্ষম হতে হবে।
   • এনক্লেভের র‍্যাম/রমে একটি এসক্রোড কী এমনভাবে সংরক্ষণ করার ব্যবস্থা থাকতে হবে, যাতে অফলাইন আক্রমণের মাধ্যমে তা পুনরুদ্ধার করা না যায়। RoR কী-টি অবশ্যই এমনভাবে সংরক্ষণ করতে হবে, যাতে অভ্যন্তরীণ ব্যক্তি বা আক্রমণকারীদের পক্ষে তা পুনরুদ্ধার করা অসম্ভব হয়।

ডিফল্ট র‍্যাম এসক্রো

AOSP-তে র‍্যাম পার্সিস্টেন্স ব্যবহার করে RoR HAL-এর একটি ইমপ্লিমেন্টেশন রয়েছে। এটি কার্যকর করার জন্য, OEM-দের অবশ্যই নিশ্চিত করতে হবে যে তাদের SoC-গুলো রিবুটের পরেও র‍্যাম পার্সিস্টেন্স সমর্থন করে। কিছু SoC রিবুটের পরেও র‍্যামের বিষয়বস্তু ধরে রাখতে পারে না, তাই এই ডিফল্ট HAL চালু করার আগে OEM-দের তাদের SoC পার্টনারদের সাথে পরামর্শ করার উপদেশ দেওয়া হয়। এর প্রামাণ্য রেফারেন্সটি পরবর্তী বিভাগে দেওয়া হলো।

RoR ব্যবহার করে OTA আপডেটের প্রবাহ

RoR বাস্তবায়নের জন্য প্রয়োজনীয় মেথডগুলো কল করতে ফোনের OTA ক্লায়েন্ট অ্যাপটিতে অবশ্যই Manifest.permission.REBOOT এবং Manifest.permission.RECOVERY পারমিশন থাকতে হবে। এই পূর্বশর্তটি পূরণ হলে, একটি আপডেটের প্রক্রিয়াটি নিম্নলিখিত ধাপগুলো অনুসরণ করে:

1. OTA ক্লায়েন্ট অ্যাপ আপডেটটি ডাউনলোড করে।
2. OTA ক্লায়েন্ট অ্যাপটি RecoverySystem#prepareForUnattendedUpdate কে কল করে, যার ফলে পরবর্তী আনলকের সময় লক স্ক্রিনে ব্যবহারকারীকে তার পিন, প্যাটার্ন বা পাসওয়ার্ডের জন্য অনুরোধ করা হয়।
3. ব্যবহারকারী লকস্ক্রিন থেকে ডিভাইসটি আনলক করেন এবং ডিভাইসটি আপডেট প্রয়োগের জন্য প্রস্তুত হয়ে যায়।
4. OTA ক্লায়েন্ট অ্যাপ RecoverySystem#rebootAndApply কে কল করে, যা অবিলম্বে একটি রিবুট শুরু করে।

এই প্রক্রিয়ার শেষে, ডিভাইসটি রিবুট হয় এবং RoR মেকানিজম ক্রেডেনশিয়াল এনক্রিপ্টেড (CE) স্টোরেজটি আনলক করে। অ্যাপগুলোর কাছে এটি একটি সাধারণ ইউজার আনলক হিসেবে প্রতীয়মান হয়, তাই তারা ACTION_LOCKED_BOOT_COMPLETED এবং ACTION_BOOT_COMPLETED-এর মতো সমস্ত সিগন্যাল পায়, যা তারা সাধারণত পেয়ে থাকে।

পণ্যের কনফিগারেশন পরিবর্তন করুন

অ্যান্ড্রয়েড ১১-এ RoR ফিচার সমর্থন করে এমন হিসেবে চিহ্নিত একটি পণ্যে অবশ্যই RebootEscrow HAL-এর একটি ইমপ্লিমেন্টেশন এবং ফিচার মার্কার XML ফাইলটি অন্তর্ভুক্ত থাকতে হবে। ডিফল্ট ইমপ্লিমেন্টেশনটি সেইসব ডিভাইসে ভালোভাবে কাজ করে যেগুলো ওয়ার্ম রিবুট ব্যবহার করে (যখন রিবুটের সময় DRAM-এর পাওয়ার চালু থাকে)।

রিবুট এসক্রো বৈশিষ্ট্য চিহ্নিতকারী

ফিচার মার্কারটিও অবশ্যই উপস্থিত থাকতে হবে:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

ডিফল্ট রিবুট এসক্রো এইচএএল বাস্তবায়ন

ডিফল্ট বাস্তবায়ন ব্যবহার করার জন্য, আপনাকে অবশ্যই 65536 (0x10000) বাইট সংরক্ষণ করতে হবে। নিরাপত্তা বৈশিষ্ট্যগুলো যাতে স্থায়ী থাকে, তা নিশ্চিত করতে এই বাইটগুলো কখনোই নন-ভোলাটাইল স্টোরেজে লিখবেন না।

লিনাক্স কার্নেল ডিভাইস ট্রি পরিবর্তন

লিনাক্স কার্নেলের ডিভাইস ট্রিতে, আপনাকে অবশ্যই একটি pmem অঞ্চলের জন্য মেমরি সংরক্ষণ করতে হবে। নিম্নলিখিত উদাহরণটি দেখাচ্ছে যে 0x50000000 সংরক্ষিত করা হয়েছে:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

যাচাই করুন যে ব্লক ডিরেক্টরিতে /dev/block/pmem0 মতো নামের (যেমন pmem1 বা pmem2 ) একটি নতুন ডিভাইস আছে।

Device.mk পরিবর্তন

ধরে নিচ্ছি যে পূর্ববর্তী ধাপের আপনার নতুন ডিভাইসটির নাম pmem0 , আপনাকে অবশ্যই নিশ্চিত করতে হবে যে নিম্নলিখিত নতুন এন্ট্রিগুলি vendor/<oem>/<product>/device.mk এ যুক্ত হয়েছে:

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default

SELinux নিয়ম

ডিভাইসের file_contexts এ এই নতুন এন্ট্রিগুলো যোগ করুন:

/dev/block/pmem0  u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default  u:object_r:hal_rebootescrow_default_exec:s0