Permission Group در Android — این چیست، گروه‌های اجازه و اصل کار

Permission Group در Android چیست

Permission Group — یک مکانیسم سیستمی Android است که چند اجازه خطرناک را بر اساس نوع کارکردی آنها در یک گروه جمع می‌کند. هر گروه یک شناسه رشته‌ای دارد، مانند android.permission-group.CAMERA یا android.permission-group.LOCATION. همه اجازه‌ها در یک گروه به طور منطقی مرتبط هستند و به قابلیت‌های مشترک دستگاه دسترسی می‌دهند.

گروه‌های اجازه همراه با مدل درخواست runtime در 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 آن را بررسی می‌کند. اگر هیچ اجازه‌ای از این گروه هنوز اعطا نشده باشد — دیالوگ نشان داده می‌شود. پس از موافقت، سیستم کل گروه را به عنوان اعطا شده علامت می‌زند و درخواست‌های بعدی سایر اجازه‌ها از همان گروه بدون واسط کاربر برآورده می‌شوند.

الگوریتم به صورت ساده شده به این صورت است:

• برنامه 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 در مانیفست اعلام کنند. اما این فقط برای اجازه‌های سفارشی همان برنامه کار می‌کند و بر دیالوگ‌های 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 شامل شناسه رشته‌ای گروه برمی‌گرداند. این برای ثبت رویداد، تحلیل و صفحات سفارشی اجازه مفید است.

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 ایجاد کرد که فهرست اجازه‌ها را برای یک گروه خاص برمی‌گرداند. این آزمایش را ساده‌تر می‌کند: در آزمایش‌های واحد، provider بدون مراجعه به PackageManager اطلاعات ساختگی برمی‌گرداند. در آزمایش‌های ابزاری — گروه‌های واقعی از سیستم.

PermissionGroupProvider در DI

ادغام PermissionGroupProvider از طریق Dagger Hilt یا Koin امکان مدیریت متمرکز نقشه‌بندی اجازه‌ها و گروه‌ها را فراهم می‌کند. در provider می‌توان نتیجه PackageManager.queryPermissionsByGroup را ذخیره کرد تا از تماس‌های تکراری سیستم در هر درخواست جلوگیری شود. این به ویژه برای صفحات تنظیمات که فهرست کامل اجازه‌ها و وضعیت آنها را نمایش می‌دهد، مهم است.

ثبت رویداد و تحلیل

هنگام جمع‌آوری تحلیل درباره خودداری‌ها، ثبت نام نه فقط نام اجازه بلکه Permission Group آن نیز مفید است. این به شناسایی مناطق کارکردی که بیشترین خودداری را ایجاد می‌کنند کمک می‌کند. به عنوان مثال، گروه LOCATION به طور سنتی بالاترین درصد خودداری را دارد — حدود 40 درصد، بر اساس آمار Google Play Console.

تحلیل گروهی به اتخاذ تصمیمات محصول کمک می‌کند: اگر گروه CONTACTS درصد بالایی از خودداری دارد، شاید باید زمان درخواست را تجدید نظر کرد یا یک دیالوگ توضیحی اضافه کرد. رویکرد گروهی به تحلیل تصویر کامل‌تری نسبت به تحلیل اجازه‌های فردی می‌دهد، زیرا تعداد خودداری‌ها در کل گروه نشان‌دهنده نگرش کلی کاربران به آن حوزه کارکردی است.