สิทธิ์รันไทม์

ใน Android 6.0 ขึ้นไป รูปแบบการอนุญาตแอปพลิเคชัน Android ได้รับการออกแบบมาเพื่อให้เข้าใจ มีประโยชน์ และปลอดภัยสำหรับผู้ใช้มากขึ้น โมเดลได้ย้ายแอปพลิเคชัน Android ที่ต้องการการอนุญาตที่เป็นอันตราย (ดู การอนุญาตที่ ได้รับผลกระทบ ) จากรูปแบบการอนุญาต เวลาติดตั้ง ไปยังโมเดลการอนุญาต รันไทม์ :

• สิทธิ์ในการติดตั้งเวลา

  ( Android 5.1 และต่ำกว่า ) ผู้ใช้ให้การ อนุญาตที่เป็นอันตราย แก่แอปเมื่อติดตั้งหรืออัปเดตแอป ผู้ผลิตอุปกรณ์และผู้ให้บริการสามารถติดตั้งแอปล่วงหน้าด้วยสิทธิ์ที่กำหนดไว้ล่วงหน้าโดยไม่ต้องแจ้งให้ผู้ใช้ทราบ

• สิทธิ์รันไทม์

  ( Android 6.0 – 9 ) ผู้ใช้ให้การอนุญาตที่เป็นอันตรายแก่แอปเมื่อแอปทำงาน เมื่อมีการร้องขอการอนุญาต (เช่น เมื่อแอปเปิดตัวหรือเมื่อผู้ใช้เข้าถึงคุณสมบัติเฉพาะ) ขึ้นอยู่กับแอปพลิเคชัน แต่ผู้ใช้ให้สิทธิ์/ปฏิเสธการเข้าถึงแอปพลิเคชันไปยังกลุ่มการอนุญาตเฉพาะ OEM/ผู้ให้บริการสามารถติดตั้งแอปล่วงหน้าได้ แต่ไม่สามารถตั้งค่าการอนุญาตล่วงหน้าได้ เว้นแต่จะผ่านกระบวนการยกเว้น (ดู การสร้างข้อยกเว้น .)

  ( Android 10 ) ผู้ใช้มองเห็นความโปร่งใสที่เพิ่มขึ้นและสามารถควบคุมได้ว่าแอปใดบ้างที่มีสิทธิ์ในการรู้จำกิจกรรม (AR) ผู้ใช้จะได้รับแจ้งจาก กล่องโต้ตอบการอนุญาตรันไทม์ เพื่ออนุญาตเสมอ อนุญาตขณะใช้งาน หรือปฏิเสธการอนุญาต ในการอัปเกรดระบบปฏิบัติการเป็น Android 10 สิทธิ์ที่มอบให้กับแอปจะยังคงอยู่ แต่ผู้ใช้สามารถเข้าไปที่ การตั้งค่า และเปลี่ยนแปลงได้

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

สิทธิ์ที่ได้รับผลกระทบ

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

adb shell pm list permissions -g -d

Android 6.0 ขึ้นไปจะไม่เปลี่ยนการทำงานของ การอนุญาตตามปกติ ทั้งหมดนี้เป็นสิทธิ์ที่ไม่เป็นอันตราย ซึ่งรวมถึงสิทธิ์ปกติ ระบบ และลายเซ็น การอนุญาตปกติเป็นการอนุญาตที่มีความเสี่ยงต่ำกว่า (เช่น SET_WALLPAPER ) ที่อนุญาตให้แอปพลิเคชันเข้าถึงคุณลักษณะระดับแอปพลิเคชันที่แยกออกมาโดยมีความเสี่ยงน้อยที่สุดสำหรับแอปพลิเคชันอื่น ระบบ หรือผู้ใช้ เช่นเดียวกับใน Android 5.1 และรุ่นที่ต่ำกว่า ระบบจะให้การอนุญาตตามปกติโดยอัตโนมัติกับแอปพลิเคชันที่ร้องขอเมื่อทำการติดตั้ง และไม่แจ้งให้ผู้ใช้อนุมัติ สำหรับรายละเอียดเกี่ยวกับการอนุญาต โปรดดูเอกสารประกอบ องค์ประกอบ <permission>

ข้อ จำกัด แบบแข็งและแบบอ่อนใน Android 10

นอกจากจะเป็นอันตรายแล้ว การอนุญาตยังสามารถจำกัดแบบเข้มงวดหรือแบบจำกัดได้ ไม่ว่าในกรณีใด การอนุญาตแบบจำกัดจะต้องได้รับอนุญาตด้วย ข้อจำกัดฮาร์ดที่ไม่อนุญาตมีพฤติกรรมแตกต่างจากข้อจำกัดซอฟต์ที่ไม่อนุญาต:

• ( ข้อจำกัด แบบตายตัว ) ไม่สามารถให้สิทธิ์แอปที่ไม่อยู่ในรายการที่อนุญาต
• ( ข้อ จำกัด อ่อน ) แอพที่ไม่มีรายการที่อนุญาตทำงานตามการอนุญาตเฉพาะที่พวกเขาร้องขอ ลักษณะการทำงานได้อธิบายไว้ในเอกสารสาธารณะสำหรับการขออนุญาตที่ร้องขอ

เมื่อติดตั้งแอป โปรแกรมติดตั้ง (เช่น Google Play Store) อาจเลือกที่จะไม่อนุญาตการอนุญาตที่จำกัดสำหรับแอป สิทธิ์ถูกจำกัดโดยแพลตฟอร์มและสามารถอนุญาตได้ก็ต่อเมื่อแอปตรงตามเกณฑ์พิเศษตามนโยบายแพลตฟอร์ม ตัวอย่างของประเภทการอนุญาตที่จำกัดอย่างเข้มงวด ได้แก่ การอนุญาต SMS และประวัติการโทร

รายการที่อนุญาตเกิดขึ้นระหว่างการติดตั้งและเมื่อ

• แอปได้รับการติดตั้งแล้วในระหว่างการอัปเกรด Android 9 เป็น 10
• มีการอนุญาตล่วงหน้าหรือมีการติดตั้งแอพไว้ล่วงหน้า
• ต้องมีการอนุญาตสำหรับบทบาทที่กำหนดไว้แล้วในรายการอนุญาต
• โปรแกรมติดตั้ง (เช่น Google Play Store) ทำเครื่องหมายการอนุญาตว่าได้รับอนุญาต

ผู้ใช้จะอนุญาตรายการอนุญาตด้วยตนเองไม่ได้

ความต้องการ

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

• รูปแบบการอนุญาตรันไทม์ต้องสอดคล้องกันในอุปกรณ์ทั้งหมดที่ใช้ Android 6.0 ขึ้นไป สิ่งนี้บังคับใช้โดยการทดสอบ Android Compatibility Test Suite (CTS)
• แอปต้องแจ้งให้ผู้ใช้ให้สิทธิ์แอปพลิเคชัน ณ รันไทม์ สำหรับรายละเอียด โปรดดูที่ การ อัปเดตแอปพลิเคชัน อาจมีข้อยกเว้นที่จำกัดสำหรับแอปพลิเคชันเริ่มต้นและตัวจัดการที่มีฟังก์ชันพื้นฐานของอุปกรณ์ซึ่งเป็นพื้นฐานของการทำงานที่คาดไว้ของอุปกรณ์ (ตัวอย่างเช่น แอป Dialer เริ่มต้นของอุปกรณ์สำหรับจัดการ ACTION_CALL อาจมีสิทธิ์เข้าถึงโทรศัพท์) สำหรับรายละเอียด โปรดดูที่ การสร้างข้อยกเว้น
• แอปที่โหลดไว้ล่วงหน้าซึ่งมีสิทธิ์ที่เป็นอันตรายต้องกำหนดเป้าหมาย API ระดับ 23 และรักษารูปแบบการอนุญาตรันไทม์ กล่าวคือ การไหลของ UI ระหว่างการติดตั้งแอปต้องไม่เบี่ยงเบนไปจากการใช้งาน PermissionController AOSP ผู้ใช้สามารถเพิกถอนการอนุญาตที่เป็นอันตรายของแอปที่ติดตั้งไว้ล่วงหน้า และอื่นๆ
• แอปพลิเคชันหัวขาดต้องใช้กิจกรรมเพื่อขอสิทธิ์หรือแชร์ UID กับแอปพลิเคชันอื่นที่มีสิทธิ์ที่จำเป็น สำหรับรายละเอียด โปรดดู แอปพลิเคชันหัวขาด

สิทธิ์การโยกย้าย

สิทธิ์ที่มอบให้กับแอปพลิเคชันบน Android 5.x จะยังคงได้รับหลังจากอัปเดตเป็น Android 6.0 หรือสูงกว่า แต่ผู้ใช้สามารถเพิกถอนการอนุญาตเหล่านั้นได้ทุกเมื่อ

ในการอัปเดต Android 9 ถึง 10 สิทธิ์ที่จำกัดฮาร์ดทั้งหมดจะได้รับอนุญาต สำหรับรายละเอียดเกี่ยวกับการใช้สิทธิ์แยกส่วนพื้นหน้า/พื้นหลัง โปรดดู ที่การเปลี่ยนแปลงความเป็นส่วนตัวของ Android 10 โดยเริ่มจาก ขอตำแหน่งในพื้นหลัง

บูรณาการ

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

อัพเดทแอพพลิเคชั่น

แอปพลิเคชันบนอิมเมจระบบและแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าไม่ใช่การอนุญาตล่วงหน้าโดยอัตโนมัติ เราขอแนะนำให้คุณทำงานร่วมกับนักพัฒนาแอปที่ติดตั้งไว้ล่วงหน้า (OEM ผู้ให้บริการ และบุคคลที่สาม) เพื่อทำการแก้ไขแอปที่จำเป็นโดยใช้ หลักเกณฑ์สำหรับนักพัฒนาซอฟต์แวร์ โดยเฉพาะอย่างยิ่ง คุณต้องตรวจสอบให้แน่ใจว่าแอปพลิเคชันที่ติดตั้งไว้ล่วงหน้าได้รับการแก้ไขเพื่อหลีกเลี่ยงการหยุดทำงานและปัญหาอื่นๆ เมื่อผู้ใช้เพิกถอนการอนุญาต

แอปพลิเคชั่นที่โหลดไว้ล่วงหน้า

ใน Android 9 และต่ำกว่า แอปที่โหลดไว้ล่วงหน้าซึ่งใช้การอนุญาตที่เป็นอันตรายจะต้องกำหนดเป้าหมาย API ระดับ 23 หรือสูงกว่า และรักษารูปแบบการอนุญาต Android 6.0 และ AOSP ที่สูงกว่า ตัวอย่างเช่น โฟลว์ UI ระหว่างการติดตั้งแอปต้องไม่เบี่ยงเบนไปจากการใช้งาน AOSP ของ PermissionController ผู้ใช้ยังสามารถเพิกถอนการอนุญาตที่เป็นอันตรายของแอพที่ติดตั้งล่วงหน้า

ใน Android 6.0 ถึง 9 การอนุญาตบางอย่างจะได้รับระหว่างขั้นตอนการติดตั้ง อย่างไรก็ตาม เริ่มต้นใน 10 ขั้นตอนการติดตั้ง (ดำเนินการโดยแอป Package Installer ) เป็นฟังก์ชันที่แยกต่างหากจากการให้สิทธิ์ (ในแอป Permission Controller )

แอปพลิเคชั่นหัวขาด

เฉพาะกิจกรรมเท่านั้นที่สามารถขอสิทธิ์ได้ บริการไม่สามารถขอสิทธิ์ได้โดยตรง

• ใน Android 5.1 และรุ่นก่อนหน้า แอปพลิเคชันที่ไม่มีส่วนหัวสามารถร้องขอการอนุญาตเมื่อติดตั้ง หรือหากติดตั้งไว้ล่วงหน้าโดยไม่ต้องใช้กิจกรรม
• ใน Android 6.0 ขึ้นไป แอปพลิเคชันที่ไม่มีส่วนหัวต้องใช้วิธีใดวิธีหนึ่งต่อไปนี้เพื่อขอสิทธิ์:
• เพิ่มกิจกรรมเพื่อขอสิทธิ์ (วิธีนี้เป็นวิธีที่แนะนำ)
• แชร์ UID กับแอปพลิเคชันอื่นที่มีสิทธิ์ที่จำเป็น ใช้วิธีนี้เฉพาะเมื่อคุณต้องการแพลตฟอร์มเพื่อจัดการ APK หลายรายการเป็นแอปพลิเคชันเดียว

เป้าหมายคือเพื่อหลีกเลี่ยงความสับสนให้ผู้ใช้กับคำขอสิทธิ์ที่ปรากฏนอกบริบท

การปรับแต่ง PackageInstaller UI

หากต้องการ คุณสามารถปรับแต่ง ธีม Permissions UI โดยอัปเดตธีมอุปกรณ์เริ่มต้น ( Theme.DeviceDefault.Settings และ Theme.DeviceDefault.Light.Dialog.NoActionBar ) ที่ใช้โดย PackageInstaller อย่างไรก็ตาม เนื่องจากความสม่ำเสมอเป็นสิ่งสำคัญสำหรับนักพัฒนาแอป คุณจึงไม่สามารถปรับแต่งตำแหน่ง ตำแหน่ง และกฎว่าเมื่อใดที่ UI สิทธิ์ปรากฏขึ้น

หากต้องการรวม สตริง สำหรับภาษาเพิ่มเติม ให้ใส่สตริงลงใน AOSP

การสร้างข้อยกเว้น

คุณสามารถให้สิทธิ์ล่วงหน้าแก่แอปพลิเคชันที่เป็นตัวจัดการเริ่มต้นหรือผู้ให้บริการสำหรับฟังก์ชันหลักของระบบปฏิบัติการโดยใช้คลาส DefaultPermissionGrantPolicy.java ใน PackageManager ตัวอย่าง:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

การกำหนดสิทธิ์ที่กำหนดเอง

คุณสามารถกำหนดสิทธิ์และกลุ่มที่กำหนดเองได้ตาม ปกติ หรือ เป็นอันตราย และเพิ่มการอนุญาตเฉพาะ OEM/Carrier ให้กับกลุ่มการอนุญาตที่มีอยู่ เช่นเดียวกับใน Android 5.x และรุ่นก่อนหน้า

ใน Android 6.0 ขึ้นไป หากคุณเพิ่มการอนุญาตที่เป็นอันตรายใหม่ จะต้องได้รับการจัดการในลักษณะเดียวกับการอนุญาตที่เป็นอันตรายอื่นๆ (ร้องขอระหว่างรันไทม์ของแอปและผู้ใช้เพิกถอนได้) โดยเฉพาะ:

• คุณสามารถเพิ่มการอนุญาตใหม่ให้กับกลุ่มปัจจุบันได้ แต่คุณไม่สามารถแก้ไขการแมป AOSP ของการอนุญาตที่เป็นอันตรายและกลุ่มการอนุญาตที่เป็นอันตราย (กล่าวคือ คุณไม่สามารถลบการอนุญาตออกจากกลุ่มและมอบหมายให้กับกลุ่มอื่นได้)
• คุณสามารถเพิ่มกลุ่มสิทธิ์ใหม่ในแอปพลิเคชันที่ติดตั้งบนอุปกรณ์ แต่คุณไม่สามารถเพิ่มกลุ่มสิทธิ์ใหม่ในรายการแพลตฟอร์มได้

ทดสอบสิทธิ์

Android มีการทดสอบความเข้ากันได้ของชุดทดสอบ (CTS) ที่ตรวจสอบว่าสิทธิ์แต่ละรายการถูกแมปกับกลุ่มที่ถูกต้อง การผ่านการทดสอบเหล่านี้เป็นข้อกำหนดสำหรับ Android 6.0 และความเข้ากันได้ของ CTS ที่ใหม่กว่า

เพิกถอนสิทธิ์

ใน Android 13 และใหม่กว่า คุณสามารถเพิกถอนการอนุญาตรันไทม์ที่ได้รับของคุณเองได้โดยใช้ Context.revokeSelfPermissionsOnKill() การเพิกถอนเกิดขึ้นแบบอะซิงโครนัสและถูกทริกเกอร์เมื่อสามารถทำได้อย่างปลอดภัยโดยไม่รบกวนผู้ใช้ เมื่อการเพิกถอนถูกทริกเกอร์ กระบวนการทั้งหมดที่ทำงานอยู่ใน UID การโทรจะถูกฆ่า

สิ่งสำคัญคือต้องเข้าใจว่าการเพิกถอนการอนุญาตเพียงครั้งเดียวอาจไม่ปรากฏใน UI การตั้งค่า ซึ่งจะถือว่าการอนุญาตตามกลุ่ม โดยปกติ กลุ่มสิทธิ์จะแสดงตามที่ได้รับตราบเท่าที่มีการอนุญาตอย่างน้อยหนึ่งรายการในกลุ่มนั้น หากการทำให้มั่นใจว่าผู้ใช้สามารถยืนยันการเพิกถอนในการตั้งค่าเป็นสิ่งสำคัญสำหรับคุณ ตรวจสอบให้แน่ใจว่าได้เพิกถอนการอนุญาตทั้งหมดในกลุ่มการอนุญาต หากต้องการทราบว่าสิทธิ์ใดบ้างที่เป็นของกลุ่มใดกลุ่มหนึ่ง คุณสามารถใช้ PackageManager.getGroupOfPlatformPermission และ PackageManager.getPlatformPermissionsForGroup

เมื่อระบบเพิกถอนการอนุญาตที่ร้องขอ ระบบจะเพิกถอนการอนุญาตในพื้นหลังที่เกี่ยวข้องด้วยหากไม่มีการอนุญาตเบื้องหน้าที่สอดคล้องกัน

การเพิกถอนจะไม่ถูกทริกเกอร์ตราบใดที่กระบวนการยังคงอยู่ในเบื้องหน้า แต่ยังสามารถทริกเกอร์ได้ทันทีด้วยการฆ่ากระบวนการทั้งหมดที่ทำงานอยู่ใน uid ปัจจุบันด้วยตนเอง เช่น การใช้ System.exit() อย่างไรก็ตาม ขอแนะนำให้ระบบตัดสินใจว่าจะทริกเกอร์เมื่อใด

หลังจากการเพิกถอนการอนุญาตมีผลแล้ว คุณสามารถขอได้อีกครั้ง และผู้ใช้จะได้รับแจ้งให้อนุญาตหรือปฏิเสธคำขอ เป็นไปไม่ได้ที่จะขออนุญาตที่ผู้ใช้เคยปฏิเสธมาก่อน แม้ว่าคุณจะได้รับการสนับสนุนให้เพิกถอนการอนุญาตที่คุณมีอยู่แต่ไม่จำเป็นอีกต่อไป คุณควรระมัดระวังอย่าแจ้งให้ผู้ใช้ทราบเกี่ยวกับการเพิกถอนจนกว่าจะมีผลบังคับ