ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP

หน้านี้ได้รับการแปลโดย Cloud Translation API

กลับมาทำงานต่อเมื่อรีบูต
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

ใน Android 11 คุณจะอัปเดต OTA ได้โดยใช้กลไกการอัปเดต A/B หรือการอัปเดต A/B เสมือนจริง ร่วมกับเมธอดของคลาส RecoverySystem หลังจากอุปกรณ์รีบูตเพื่อใช้การอัปเดต OTA แล้ว ฟีเจอร์กลับมาทำงานต่อเมื่อรีบูต (RoR) จะปลดล็อกพื้นที่เก็บข้อมูลที่มีการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) ของอุปกรณ์

แม้ว่าพาร์ทเนอร์จะสามารถจับคู่กระบวนการนี้กับฟีเจอร์ของระบบ OTA ที่ใช้ อัปเดตเมื่อคาดว่าอุปกรณ์จะไม่มีความเคลื่อนไหวใน Android 11 ใน พาร์ทเนอร์ Android 12 ไม่ต้องใช้ระบบ OTA เพิ่มเติม กระบวนการ RoR เพิ่มความปลอดภัยและความสะดวกให้กับผู้ใช้ เนื่องจากสามารถอัปเดตได้ในช่วงเวลาที่อุปกรณ์ไม่ได้ใช้งาน ขณะที่ฟังก์ชันการอัปเดตแบบไคลเอ็นต์หลายรายการและแบบเซิร์ฟเวอร์ของ Android 12 ร่วมกันมอบความปลอดภัยระดับฮาร์ดแวร์ให้กับอุปกรณ์

แม้ว่าจะต้องให้สิทธิ์อุปกรณ์สำหรับandroid.hardware.reboot_escrowฟีเจอร์เพื่อรองรับ RoR ใน Android 11 แต่คุณไม่จำเป็นต้องดำเนินการนี้เพื่อเปิดใช้ RoR ที่อิงตามเซิร์ฟเวอร์ใน Android 12 ขึ้นไป เนื่องจากไม่ใช้ HAL

ฉากหลัง

เริ่มตั้งแต่ Android 7 เป็นต้นไป การเปิดเครื่องโดยตรงที่รองรับ Android ซึ่งทำให้แอปในอุปกรณ์เริ่มทำงานได้ก่อนที่พื้นที่เก็บข้อมูล CE จะปลดล็อกโดย ผู้ใช้รายนั้น การใช้การสนับสนุน Direct Boot ช่วยให้ผู้ใช้ได้รับ ประสบการณ์ก่อนป้อน "ปัจจัยความรู้สำหรับหน้าจอล็อก" (LSKF) หลังจากเปิดเครื่อง

RoR ช่วยให้ปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมดในอุปกรณ์ได้ ซึ่งรวมถึง แอปที่ไม่รองรับ Direct Boot เมื่อเริ่มต้นการรีบูตหลังจาก การอัปเดต OTA ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งไว้ทั้งหมดหลังจากรีบูต

โมเดลภัยคุกคาม

การติดตั้งใช้งาน RoR ต้องทำให้มั่นใจว่าเมื่ออุปกรณ์ตกอยู่ในมือผู้โจมตี ผู้โจมตีจะกู้คืนข้อมูลที่เข้ารหัสด้วย CE ของผู้ใช้ได้ยากมาก แม้ว่าอุปกรณ์จะเปิดอยู่ พื้นที่เก็บข้อมูล CE จะปลดล็อกอยู่ และผู้ใช้ปลดล็อกอุปกรณ์หลังจากได้รับการอัปเดต OTA แล้วก็ตาม บุคคลภายใน การต้านทานการโจมตีต้องได้ผลแม้ว่าผู้โจมตีจะเข้าถึง คีย์การเข้ารหัสลับในการออกอากาศ

กล่าวโดยละเอียดคือ ผู้โจมตีที่มีอุปกรณ์อยู่จริงต้องไม่อ่านพื้นที่เก็บข้อมูล CE และสามารถดำเนินการต่อไปนี้ได้

ความสามารถ

ใช้คีย์การรับรองของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามในข้อความที่กำหนดเอง
อาจทําให้อุปกรณ์ได้รับการอัปเดต OTA
แก้ไขการทํางานของฮาร์ดแวร์ได้ (เช่น โปรเซสเซอร์แอปพลิเคชัน หรือหน่วยความจําแฟลช) ยกเว้นตามที่ระบุไว้ในข้อจํากัดด้านล่าง (อย่างไรก็ตาม การแก้ไขดังกล่าวมีทั้งความล่าช้าอย่างน้อย 1 ชั่วโมง และ รอบการทำงานซึ่งจะทำลายเนื้อหา RAM)

ข้อจำกัด

ไม่สามารถแก้ไขการทำงานของฮาร์ดแวร์ป้องกันการงัดแงะ (เช่น Titan M)
อ่าน RAM ของอุปกรณ์ที่กำลังดำเนินอยู่ไม่ได้
ไม่สามารถคาดเดาข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือทำให้ผู้ใช้ป้อนข้อมูลเข้าสู่ระบบ

โซลูชัน

ระบบอัปเดต RoR ของ Android 12 มอบความปลอดภัย ผู้โจมตีที่มีความซับซ้อนมาก และทำเช่นนี้ได้ขณะที่รหัสผ่านในอุปกรณ์และ PIN จะอยู่ในอุปกรณ์ โดยจะไม่มีการส่งไปยังหรือจัดเก็บไว้บนเซิร์ฟเวอร์ของ Google ช่วงเวลานี้ เป็นภาพรวมของกระบวนการที่ทำให้มั่นใจได้ว่าระดับการรักษาความปลอดภัยที่มีให้ คล้ายกับระบบ RoR ระดับอุปกรณ์ที่อิงตามฮาร์ดแวร์

Android จะใช้การป้องกันด้วยการเข้ารหัสกับข้อมูลที่จัดเก็บไว้ในอุปกรณ์
ระบบจะปกป้องข้อมูลทั้งหมดด้วยคีย์ที่จัดเก็บไว้ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
TEE จะปล่อยคีย์ก็ต่อเมื่อระบบปฏิบัติการที่ทำงานอยู่ผ่านการตรวจสอบสิทธิ์การเข้ารหัส (การเปิดเครื่องที่ได้รับการยืนยัน)
บริการ RoR ที่ทำงานบนเซิร์ฟเวอร์ของ Google รักษาความปลอดภัยข้อมูล CE โดยการจัดเก็บข้อมูลลับ ที่ดึงข้อมูลได้ในระยะเวลาที่จำกัดเท่านั้น การดำเนินการนี้ใช้ได้ทั่วทั้งระบบนิเวศของ Android
คีย์การเข้ารหัสที่ป้องกันด้วย PIN ของผู้ใช้จะใช้เพื่อปลดล็อกอุปกรณ์ และถอดรหัสพื้นที่เก็บข้อมูล CE
- เมื่อตั้งเวลารีบูตข้ามคืนไว้ Android จะแจ้งให้ผู้ใช้ป้อน PIN จากนั้นจะคำนวณรหัสผ่านสังเคราะห์ (SP)
- จากนั้นจะเข้ารหัส SP 2 ครั้ง โดยการเข้ารหัสครั้งแรกจะใช้คีย์ K_s ที่เก็บไว้ใน RAM และการเข้ารหัสครั้งที่ 2 จะใช้คีย์ K_k ที่เก็บไว้ใน TEE
- ระบบจะจัดเก็บ SP ที่เข้ารหัส 2 ชั้นไว้ในดิสก์ และลบ SP ออกจาก RAM ทั้ง 2 คีย์เป็นคีย์ที่สร้างขึ้นใหม่และใช้สำหรับรีบูตเพียงครั้งเดียวเท่านั้น
เมื่อถึงเวลารีบูต Android จะมอบหมาย K_s ให้กับเซิร์ฟเวอร์ ระบบจะเข้ารหัสใบเสร็จที่มี K_k ก่อนที่จะจัดเก็บไว้ในดิสก์
หลังจากรีบูต Android จะใช้ K_k เพื่อถอดรหัสใบเสร็จ จากนั้นส่งใบเสร็จไปยังเซิร์ฟเวอร์เพื่อเรียกข้อมูล K_s
- K_k และ K_s ใช้ในการถอดรหัส SP ที่จัดเก็บในดิสก์
- Android ใช้ SP เพื่อปลดล็อกพื้นที่เก็บข้อมูล CE และอนุญาตให้เริ่มต้นแอปตามปกติ
- K_k และ K_s ถูกทิ้ง

การอัปเดตที่รักษาความปลอดภัยให้โทรศัพท์จะดำเนินการในเวลาที่คุณสะดวก เช่น ขณะนอนหลับ

สำคัญ: ฟังก์ชัน RoR ที่อิงตามเซิร์ฟเวอร์จะทำงานโดยที่ไม่ทำให้เซิร์ฟเวอร์ทำงาน เรียนรู้ PIN ของผู้ใช้: คีย์ K_s เป็นข้อมูลลับเดียวที่เซิร์ฟเวอร์เชื่อถือ และโมเดลจะสร้างขึ้นแบบสุ่มทุกครั้ง รหัสผ่านในอุปกรณ์และ PIN จะยังอยู่ อุปกรณ์จะไม่ถูกส่งไปยังเซิร์ฟเวอร์ และจะไม่เก็บข้อมูลไว้ในเครื่อง

การเล่น PIN ของซิมซ้ำ

ภายใต้เงื่อนไขบางประการ รหัส PIN ของซิมการ์ดจะได้รับการยืนยันจากแคช ซึ่งเป็นกระบวนการที่เรียกว่าการเล่นซ้ำ SIM-PIN

ซิมการ์ดที่มี PIN เปิดใช้อยู่จะต้องได้รับรหัส PIN ที่ราบรื่นด้วย การยืนยัน (การเล่นซ้ำ SIM-PIN) หลังจากการรีบูตโดยไม่ต้องดำเนินการใดๆ เพื่อคืนค่าเครือข่ายมือถือ การเชื่อมต่อ (จำเป็นสำหรับการโทรศัพท์ ข้อความ SMS และบริการอินเทอร์เน็ต) ระบบจะจัดเก็บ PIN ของซิมการ์ดและข้อมูลซิมการ์ดที่ตรงกัน (ICCID และหมายเลขช่อง SIM) ไว้ด้วยกันอย่างปลอดภัย คุณจะเรียกดูและใช้ PIN ที่เก็บไว้เพื่อยืนยันได้หลังจากที่รีบูตโดยอัตโนมัติสำเร็จเท่านั้น หากอุปกรณ์คือ มีความปลอดภัย PIN ของซิมจะจัดเก็บไว้กับคีย์ที่ได้รับการปกป้องโดย LSKF หากซิมเปิดใช้ PIN การโต้ตอบกับเซิร์ฟเวอร์ RoR ต้องเชื่อมต่อ Wi-Fi สำหรับการอัปเดต OTA และ RoR บนเซิร์ฟเวอร์ ซึ่งจะช่วยให้มั่นใจได้ว่าฟังก์ชันพื้นฐาน (ที่มีการเชื่อมต่อเครือข่ายมือถือ) จะทำงานได้หลังจากรีบูต

ระบบจะเข้ารหัส PIN ของซิมใหม่และจัดเก็บทุกครั้งที่ผู้ใช้เปิดใช้สำเร็จ ตรวจสอบ หรือแก้ไข ระบบจะทิ้ง PIN ของซิม หากเป็นไปตามข้อใดข้อหนึ่งต่อไปนี้ เกิดขึ้น:

ถอดหรือรีเซ็ตซิมแล้ว
ผู้ใช้ปิดใช้ PIN
เกิดรีบูตที่ไม่ได้เริ่มโดย RoR

PIN ของซิมที่เก็บไว้จะใช้ได้ครั้งเดียวหลังจากการรีบูตที่ RoR เริ่มต้นขึ้น และใช้ได้เพียงระยะเวลาสั้นๆ (20 วินาที) เท่านั้นหากรายละเอียดของซิมการ์ดตรงกัน PIN ของ SIM ที่เก็บไว้จะไม่ออกจากแอป TelephonyManager และโมดูลภายนอกจะเรียกข้อมูล PIN ดังกล่าวไม่ได้

หลักเกณฑ์การใช้งาน

ใน Android 12 ฟังก์ชัน RoR แบบหลายไคลเอ็นต์และแบบเซิร์ฟเวอร์จะช่วยลดภาระให้กับพาร์ทเนอร์เมื่อมีการพุชการอัปเดต OTA การอัปเดตที่จำเป็นอาจเกิดขึ้นในช่วงที่อุปกรณ์หยุดทำงานชั่วคราวในช่วงเวลาที่สะดวก เช่น ในช่วงที่ระบุไว้ว่าเป็นเวลานอน

ใช้โหมดมืดเพื่อลดการปล่อยแสงเพื่อให้การอัปเดต OTA ในช่วงเวลาดังกล่าวไม่รบกวนผู้ใช้ โดยให้ Bootloader ของอุปกรณ์ค้นหาสตริงเหตุผล unattended หาก unattended เป็น true ให้ตั้งค่าอุปกรณ์เป็นโหมดมืด โปรดทราบว่า OEM แต่ละรายมีหน้าที่ดังนี้ ช่วยลดการปล่อยเสียงและแสง

หากคุณอัปเกรดเป็น Android 12 หรือเปิดตัว อุปกรณ์ Android 12 คุณไม่จําเป็นต้องดําเนินการใดๆ เพื่อ ใช้ฟังก์ชัน RoR ใหม่

มีการเรียกใช้ใหม่ 1 รายการในขั้นตอนสำหรับลูกค้าหลายราย isPreparedForUnattendedUpdate ดังที่แสดงด้านล่าง

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

คุณไม่จำเป็นต้องใช้วิธีนี้ เนื่องจาก HAL ถูกเลิกใช้งานแล้วใน Android 12

TelephonyManager

ไคลเอ็นต์ OTA จะเรียกใช้ TelephonyManager System API เมื่อใกล้ถึงเวลารีบูตใน Android 12 API นี้ย้ายรหัส PIN ที่แคชไว้ทั้งหมดจาก สถานะ 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()

APK ที่มีสิทธิ์จะใช้ TelephonyManager System API

การทดสอบ

หากต้องการทดสอบ API ใหม่ ให้เรียกใช้คําสั่งนี้

    adb shell cmd phone unattended-reboot

คำสั่งนี้จะใช้งานได้เมื่อเชลล์ทำงานเป็นรูท (adb root) เท่านั้น

Android 11 เท่านั้น

ส่วนที่เหลือของหน้านี้ใช้กับ Android 11

การใช้งาน RoR HAL แบ่งออกเป็น 2 หมวดหมู่ตั้งแต่เดือนกรกฎาคม 2020 ดังนี้

หากฮาร์ดแวร์ SoC รองรับการคงข้อมูลใน RAM ไว้ระหว่างการรีบูต OEM จะใช้การใช้งานเริ่มต้นใน AOSP (Default RAM Escrow) ได้
หากฮาร์ดแวร์หรือ SoC ของอุปกรณ์รองรับ Enclave ฮาร์ดแวร์ที่ปลอดภัย (ตัวประมวลผลร่วมด้านความปลอดภัยแบบแยกต่างหากที่มี RAM และ ROM ของตัวเอง) อุปกรณ์จะต้องดำเนินการต่อไปนี้ด้วย
- ตรวจจับการรีบูต CPU หลักได้
- มีแหล่งที่มาของตัวจับเวลาฮาร์ดแวร์ที่ยังคงอยู่หลังจากการรีบูต กล่าวคือ Enclave ต้องตรวจพบการรีบูตและทำให้ตัวจับเวลาที่ตั้งไว้ก่อนการรีบูตหมดอายุ
- รองรับการจัดเก็บคีย์ที่เข้ารหัสไว้ใน RAM/ROM ของเครือข่ายที่ปลอดภัยที่ไม่สามารถ จะกู้คืนได้ด้วยการโจมตีแบบออฟไลน์ โดยต้องจัดเก็บคีย์ RoR ในลักษณะที่ทําให้บุคคลภายในหรือผู้โจมตีไม่สามารถกู้คืนได้

วงเงินประกัน RAM เริ่มต้น

AOSP มีการใช้งาน RoR HAL โดยใช้การคงข้อมูลใน RAM OEM ต้องตรวจสอบว่า SoC รองรับการคงข้อมูลใน RAM ไว้เมื่อรีบูตเพื่อให้ฟีเจอร์นี้ทำงานได้ SoC บางรายการจะไม่สามารถยืนยันเนื้อหา RAM ได้เมื่อรีบูต OEM ขอแนะนำให้ปรึกษาพาร์ทเนอร์ SoC ของตนก่อนเปิดใช้ HAL เริ่มต้นนี้ ข้อมูลอ้างอิงตามหลักเกณฑ์สําหรับเรื่องนี้อยู่ในส่วนต่อไปนี้

ขั้นตอนการอัปเดต OTA โดยใช้ RoR

แอปไคลเอ็นต์ OTA ในโทรศัพท์ต้องมีสิทธิ์ Manifest.permission.REBOOT และ Manifest.permission.RECOVERY เพื่อเรียกใช้เมธอดที่จำเป็นในการใช้งาน RoR เมื่อมีคุณสมบัติตามข้อกําหนดเบื้องต้นแล้ว ขั้นตอนของการอัปเดตจะเป็นไปตามขั้นตอนต่อไปนี้

แอปไคลเอ็นต์ OTA ดาวน์โหลดการอัปเดต
การเรียกแอปไคลเอ็นต์ของ OTA ไปยัง RecoverySystem#prepareForUnattendedUpdate ทำให้ผู้ใช้ต้องขอ PIN, รูปแบบ หรือรหัสผ่าน ในการปลดล็อกครั้งถัดไป
ผู้ใช้ปลดล็อกอุปกรณ์ที่หน้าจอล็อก และอุปกรณ์ก็พร้อมที่จะรับการอัปเดต
แอปไคลเอ็นต์ OTA โทรหา RecoverySystem#rebootAndApply ซึ่งจะทริกเกอร์การรีบูตทันที

เมื่อสิ้นสุดขั้นตอนนี้ อุปกรณ์จะรีบูตและ RoR จะปลดล็อกที่เก็บข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบ (CE) การดำเนินการนี้จะปรากฏในแอปเป็นการปลดล็อกของผู้ใช้ตามปกติ แอปจึงได้รับสัญญาณทั้งหมด เช่น ACTION_LOCKED_BOOT_COMPLETED และ ACTION_BOOT_COMPLETED ตามที่ควรจะเป็น

แก้ไขการกำหนดค่าผลิตภัณฑ์

ผลิตภัณฑ์ที่มีการทำเครื่องหมายว่ารองรับฟีเจอร์ RoR ใน Android 11 ต้องมี การนำ รีบูตEscrow HAL มาใช้และรวมไฟล์ XML ของตัวทำเครื่องหมายฟีเจอร์ การใช้งานเริ่มต้นทำงานได้ดีในอุปกรณ์ที่ใช้การรีบูตแบบ Warm (เมื่อ ไฟที่ไปยัง DRAM จะติดอยู่ตลอดขณะรีบูต)

รีบูตเครื่องหมายฟีเจอร์การระงับ

นอกจากนี้จะต้องมีเครื่องหมายแสดงองค์ประกอบด้วย:

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

การใช้งาน HAL ของรีบัวส์เริ่มต้น

หากต้องการใช้การติดตั้งใช้งานเริ่มต้น คุณต้องจอง 65536 (0x10000) ไบต์ อย่าเขียนไบต์เหล่านี้ลงในพื้นที่เก็บข้อมูลแบบไม่ผันแปรเพื่อให้แน่ใจว่าพร็อพเพอร์ตี้ความปลอดภัยจะยังคงอยู่

การเปลี่ยนแปลงแผนผังอุปกรณ์เคอร์เนล Linux

ในแผนผังอุปกรณ์ของเคอร์เนลของ Linux คุณต้องจองหน่วยความจำสำหรับภูมิภาค 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