Android میں Permission Group — یہ کیا ہے، اجازت کے گروپ اور کام کرنے کا اصول

Android میں Permission Group کیا ہے

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 کے بغیر پوری کی جاتی ہیں۔

آسان الگورتھم اس طرح نظر آتا ہے:

• ایپلیکیشن ACCESS_FINE_LOCATION کے لیے requestPermissions کال کرتی ہے
• سسٹم گروپ متعین کرتا ہے — android.permission-group.LOCATION
• جانچ کرتا ہے کہ LOCATION گروپ پہلے دیا گیا ہے یا نہیں
• اگر نہیں — گروپ کا نام اور شامل اجازتوں کی فہرست کے ساتھ ایک ڈائیلاگ دکھاتا ہے
• Allow کے بعد — پورا LOCATION گروپ دیا ہوا سمجھا جاتا ہے
• ACCESS_COARSE_LOCATION اب اضافی درخواست کے بغیر دستیاب ہے

یہ طریقہ کار صرف خطرناک اجازتوں پر لاگو ہوتا ہے۔ عام اجازتوں کے گروپ نہیں ہوتے اور وہ اس منطق میں حصہ نہیں لیتیں۔ مراعات یافتہ اور دستخط شدہ اجازتیں بھی گروپ نہیں کی جاتیں — ان کا رسائی کنٹرول کا علیحدہ نظام ہے۔

گروپ منطق کی حدود

گروپ “الٹی طرف” کام نہیں کرتے: ترتیبات کے ذریعے گروپ سے ایک اجازت واپس لینے سے صرف وہ اجازت واپس لی جاتی ہے، باقی متاثر نہیں ہوتیں۔ نیز، اگر صارف کسی گروپ کے ڈائیلاگ کو مسترد کرتا ہے، تو یہ دوسرے گروپوں کو مسدود نہیں کرتا — ہر نئی اجازت ایک مختلف گروپ سے اپنا علیحدہ ڈائیلاگ دکھائے گی۔ Permission Group صرف درخواست کے UX کو متاثر کرتا ہے، سیکیورٹی ماڈل کو نہیں۔

Android میں Permission Group کی فہرست

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 کا حصہ نہیں ہیں بلکہ گروپ بندی کے بغیر آزاد خطرناک اجازتیں ہیں۔

اپنی مرضی کے اجازت گروپ

ڈیولپرز مینی فیسٹ میں permissionGroup وصف کے ذریعے اپنی مرضی کے Permission Group کے ساتھ اپنی اجازتیں اعلان کر سکتے ہیں۔ تاہم، یہ صرف اسی ایپلیکیشن کی اپنی مرضی کی اجازتوں کے لیے کام کرتا ہے اور سسٹم 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 — UI کے لیے Permission Group استعمال نہیں کرتیں۔ ان کی فراہمی سسٹم کی سطح پر کنٹرول کی جاتی ہے: signature ان ایپلیکیشنز کو دی جاتی ہے جو سسٹم کے ایک ہی سرٹیفکیٹ سے دستخط شدہ ہوں، اور privileged سسٹم امیج میں ایپلیکیشنز کو۔ ایسی اجازتوں کے لیے گروپ موجود ہوتے ہیں لیکن UX ڈائیلاگ کو متاثر نہیں کرتے کیونکہ یہ ڈائیلاگ ظاہر ہی نہیں ہوتے۔

کوڈ میں Permission Group کی جانچ

ڈیولپر PackageManager کے ذریعے کسی بھی اجازت کا Permission Group پروگرام کے ذریعے متعین کر سکتا ہے۔ 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 کو کال کیے بغیر فرضی ڈیٹا لوٹاتا ہے۔ انسٹرومینٹیشن ٹیسٹ میں، یہ سسٹم سے حقیقی گروپ لوٹاتا ہے۔

DI میں PermissionGroupProvider

Dagger Hilt یا Koin کے ذریعے PermissionGroupProvider کا انضمام اجازت سے گروپ کی نقشہ سازی کے مرکزی انتظام کی اجازت دیتا ہے۔ فراہم کنندہ میں، آپ ہر درخواست پر بار بار سسٹم کال سے بچنے کے لیے PackageManager.queryPermissionsByGroup کے نتیجے کو کیش کر سکتے ہیں۔ یہ خاص طور پر ترتیبات کی اسکرینوں کے لیے اہم ہے جہاں اجازتوں کی مکمل فہرست اور ان کی حالت ظاہر ہوتی ہے۔

لاگنگ اور تجزیہ

انکار کے بارے میں تجزیہ جمع کرتے وقت، نہ صرف اجازت کا نام بلکہ اس کا Permission Group بھی لاگ کرنا مفید ہے۔ اس سے یہ پہچاننے میں مدد ملتی ہے کہ کون سے فعلی علاقے سب سے زیادہ انکار کا باعث بنتے ہیں۔ مثال کے طور پر، LOCATION گروپ روایتی طور پر سب سے زیادہ انکار کی شرح رکھتا ہے — Google Play Console کے اعدادوشمار کے مطابق تقریباً 40 فیصد۔

گروپوں کے لحاظ سے تجزیہ مصنوعات کے فیصلے لینے میں مدد کرتا ہے: اگر CONTACTS گروپ میں انکار کی شرح زیادہ ہے، تو شاید درخواست کے وقت پر نظرثانی کرنا یا ایک استدلال ڈائیلاگ شامل کرنا ضروری ہے۔ تجزیہ کے لیے گروپ پر مبنی نقطہ نظر انفرادی اجازتوں کے تجزیہ سے زیادہ مکمل تصویر فراہم کرتا ہے، کیونکہ پورے گروپ میں انکار کی تعداد ایک فعلی علاقے کے بارے میں صارفین کے عمومی رویے کی عکاسی کرتی ہے۔