Permission Group ใน Android — คืออะไร กลุ่มสิทธิ์และหลักการทำงาน

Permission Group ใน Android คืออะไร

Permission Group เป็นกลไกระบบ Android ที่รวมสิทธิ์อันตรายหลายรายการเป็นกลุ่มเดียวตามวัตถุประสงค์การทำงานของมัน แต่ละกลุ่มมีตัวระบุสตริง เช่น android.permission-group.CAMERA หรือ android.permission-group.LOCATION สิทธิ์ทั้งหมดภายในกลุ่มเดียวเชื่อมโยงกันทางตรรกะและให้การเข้าถึงฟังก์ชันที่เกี่ยวข้องของอุปกรณ์

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

สิ่งสำคัญคือต้องเข้าใจว่านักพัฒนาไม่สามารถสร้าง Permission Group ของตนเองได้ กลุ่มถูกกำหนดไว้ล่วงหน้าในระดับระบบปฏิบัติการและอธิบายไว้ในไฟล์ permissions.xml บนอุปกรณ์แต่ละเครื่อง แอปพลิเคชันเพียงประกาศ uses-permission และระบบจะจับคู่สิทธิ์กับกลุ่มโดยอัตโนมัติตาม protectionLevel และการจัดหมวดหมู่ใน AOSP

ระบบกำหนดกลุ่มอย่างไร

การจับคู่สิทธิ์กับกลุ่มเกิดขึ้นผ่านแอตทริบิวต์ permissionGroup ในนิยามสิทธิ์ของระบบ ตัวอย่างเช่น CAMERA ประกาศด้วย permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION ด้วย permissionGroup="android.permission-group.LOCATION" การจับคู่นี้ถูกกำหนดไว้ตายตัวในโค้ด Android Open Source Project และเหมือนกันบนอุปกรณ์ที่ได้รับการรับรองทั้งหมด

Permission Group ทำงานอย่างไร

กลไกกลุ่ม ทำงานบนหลักการ “หนึ่งไดอะล็อกต่อกลุ่ม” เมื่อแอปพลิเคชันขอสิทธิ์อันตรายใด ๆ เป็นครั้งแรก ระบบจะตรวจสอบ Permission Group ของมัน หากยังไม่มีสิทธิ์ใดจากกลุ่มนี้ที่ถูกอนุญาต — จะแสดงไดอะล็อก หลังจากยินยอม ระบบจะทำเครื่องหมายทั้งกลุ่มว่าอนุญาตแล้ว และคำขอถัดไปสำหรับสิทธิ์อื่นจากกลุ่มเดียวกันจะได้รับการตอบสนองโดยไม่ต้องใช้ UI

อัลกอริทึมแบบง่ายมีลักษณะดังนี้:

• แอปพลิเคชันเรียก requestPermissions สำหรับ ACCESS_FINE_LOCATION
• ระบบกำหนดกลุ่ม — android.permission-group.LOCATION
• ตรวจสอบว่ากลุ่ม LOCATION ถูกอนุญาตก่อนหน้านี้หรือไม่
• หากไม่ — แสดงไดอะล็อกพร้อมชื่อกลุ่มและรายการสิทธิ์ที่รวมอยู่
• หลังจาก Allow — กลุ่ม LOCATION ทั้งหมดถือว่าอนุญาตแล้ว
• ACCESS_COARSE_LOCATION พร้อมใช้งาน โดยไม่ต้องขอเพิ่มเติม

กลไกนี้ใช้กับสิทธิ์อันตรายเท่านั้น สิทธิ์ปกติไม่มีกลุ่มและไม่มีส่วนร่วมในตรรกะนี้ สิทธิ์พิเศษและสิทธิ์ที่ลงนามก็ไม่ถูกจัดกลุ่มเช่นกัน — มีระบบควบคุมการเข้าถึงแยกต่างหาก

ข้อจำกัดของตรรกะกลุ่ม

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

รายการ Permission Group ใน Android

Android กำหนด Permission Group ระบบต่อไปนี้สำหรับสิทธิ์อันตราย แต่ละกลุ่มรวมสิทธิ์หนึ่งรายการขึ้นไปที่รวมกันด้วยวัตถุประสงค์การทำงานร่วมกัน

การเปลี่ยนแปลงในเวอร์ชันใหม่

บน Android 13 (API 33) มีกลุ่มใหม่ NEARBY_DEVICES ปรากฏขึ้น ซึ่งรวม BLUETOOTH_SCAN, BLUETOOTH_CONNECT และ BLUETOOTH_ADVERTISE นอกจากนี้ กลุ่ม STORAGE ถูกแทนที่บางส่วนด้วยสิทธิ์สื่อ READ_MEDIA_IMAGES, READ_MEDIA_VIDEO และ READ_MEDIA_AUDIO ซึ่งไม่ได้เป็นส่วนหนึ่งของ STORAGE แต่เป็นสิทธิ์อันตรายอิสระที่ไม่มีการจัดกลุ่ม

กลุ่มสิทธิ์แบบกำหนดเอง

นักพัฒนาสามารถประกาศสิทธิ์ของตนเองด้วย Permission Group แบบกำหนดเองผ่านแอตทริบิวต์ permissionGroup ในไฟล์ manifest อย่างไรก็ตาม สิ่งนี้ใช้ได้เฉพาะกับสิทธิ์แบบกำหนดเองของแอปพลิเคชันเดียวกันและไม่ส่งผลกระทบต่อไดอะล็อก UI ของระบบ ในทางปฏิบัติ Permission Group แบบกำหนดเองไม่ค่อยถูกใช้ — สำหรับการโต้ตอบระหว่างแอปพลิเคชันในสแต็กเดียวกัน

Permission Group และ UX

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

งานวิจัย UX แสดงให้เห็นว่าไดอะล็อกกลุ่มถูกรับรู้โดยผู้ใช้ว่าโปร่งใสมากขึ้น เมื่อแอปพลิเคชันขอ “สิทธิ์ในการเข้าถึงกล้อง” ผู้ใช้จะเข้าใจบริบท หากแต่ละสิทธิ์ถูกขอแยกกัน — CAMERA, CAMERA2, FLASHLIGHT — มันจะสร้างความประทับใจถึงความซ้ำซ้อน Permission Group ทำให้รายละเอียดนี้เป็นนามธรรม

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

Permission Group เทียบกับ ProtectionLevel

Permission Group และ ProtectionLevel เป็นสองมิติที่แตกต่างกันของระบบสิทธิ์ Android ProtectionLevel กำหนดวิธีการอนุญาตสิทธิ์ (normal, dangerous, signature, privileged) ในขณะที่ Permission Group เป็นหมวดหมู่สำหรับการแสดงผล UI พวกมันเป็นอิสระ แต่ในทางปฏิบัติ การรวมกัน dangerous + permission group พบบ่อยที่สุด

สิทธิ์ของ ProtectionLevel เดียวกันสามารถเป็นของกลุ่มที่แตกต่างกัน ตัวอย่างเช่น ACCESS_FINE_LOCATION และ CAMERA ทั้งคู่มี protectionLevel dangerous แต่เป็นของกลุ่มที่แตกต่างกัน — LOCATION และ CAMERA และในทางกลับกัน สิทธิ์ที่มีชื่อคล้ายกันมักเป็นของกลุ่มเดียวกันเสมอ: ACCESS_FINE_LOCATION และ ACCESS_COARSE_LOCATION ทั้งคู่อยู่ใน LOCATION

ระดับการป้องกันที่สูงกว่า — signature และ privileged — ไม่ใช้ Permission Group สำหรับ UI การอนุญาตของพวกมันถูกควบคุมในระดับระบบ: signature ถูกอนุญาตให้กับแอปพลิเคชันที่ลงนามด้วยใบรับรองเดียวกันกับระบบ และ privileged กับแอปพลิเคชันในอิมเมจระบบ กลุ่มสำหรับสิทธิ์ดังกล่าวมีอยู่แต่ไม่ส่งผลกระทบต่อไดอะล็อก UX เพราะไดอะล็อกเหล่านี้ไม่ปรากฏขึ้น

ตรวจสอบ Permission Group ในโค้ด

นักพัฒนาสามารถ กำหนด Permission Group ของสิทธิ์ใด ๆ ผ่านโปรแกรมโดยใช้ PackageManager เมธอด getPermissionInfo ส่งคืน PermissionInfo พร้อมฟิลด์ group ที่มีตัวระบุสตริงของกลุ่ม ซึ่งมีประโยชน์สำหรับการบันทึก การวิเคราะห์ และหน้าจอสิทธิ์ UI แบบกำหนดเอง

fun getPermissionGroupName(
    permission: String
): String? {
    return try {
        val pm = packageManager
        val info = pm.getPermissionInfo(
            permission,
            PackageManager.GET_META_DATA
        )
        info.group
    } catch (e: NameNotFoundException) {
        null
    }
}

fun getPermissionsByGroup(
    group: String
): List<String> {
    val pm = packageManager
    val perms = pm.queryPermissionsByGroup(
        group,
        PackageManager.GET_META_DATA
    )
    return perms.map { it.name }
}

การใช้งานใน DI และสถาปัตยกรรม

ความรู้เกี่ยวกับ Permission Group ช่วยสร้างสถาปัตยกรรมคำขอ คุณสามารถสร้างสิ่งที่เป็นนามธรรมที่เรียกว่า PermissionGroupProvider ซึ่งส่งคืนรายการสิทธิ์สำหรับกลุ่มเฉพาะ ซึ่งทำให้การทดสอบง่ายขึ้น: ในการทดสอบหน่วย ผู้ให้บริการส่งคืนข้อมูลจำลองโดยไม่เรียก PackageManager ในการทดสอบเครื่องมือ มันส่งคืนกลุ่มจริงจากระบบ

PermissionGroupProvider ใน DI

การรวม PermissionGroupProvider ผ่าน Dagger Hilt หรือ Koin ช่วยให้การจัดการการจับคู่สิทธิ์กับกลุ่มเป็นแบบรวมศูนย์ ในผู้ให้บริการ คุณสามารถแคชผลลัพธ์ของ PackageManager.queryPermissionsByGroup เพื่อหลีกเลี่ยงการเรียกระบบซ้ำ ๆ ในทุกคำขอ ซึ่งสำคัญเป็นพิเศษสำหรับหน้าจอ การตั้งค่า ที่แสดงรายการสิทธิ์ทั้งหมดและสถานะของมัน

การบันทึกและการวิเคราะห์

เมื่อรวบรวมการวิเคราะห์เกี่ยวกับการปฏิเสธ การบันทึกไม่เพียงแต่ชื่อสิทธิ์เท่านั้น แต่ยังรวมถึง Permission Group ของมันด้วย เป็นประโยชน์ ซึ่งช่วยระบุว่าพื้นที่การทำงานใดทำให้เกิดการปฏิเสธมากที่สุด ตัวอย่างเช่น กลุ่ม LOCATION มีอัตราการปฏิเสธสูงที่สุดตามประเพณี — ประมาณ 40 เปอร์เซ็นต์ ตามสถิติของ Google Play Console

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