Android میں Dangerous Permission: یہ کیا ہے، اجازتوں کی فہرست اور رن ٹائم درخواست

Android میں Dangerous Permission کیا ہے

Dangerous Permission Android سسٹم کی اجازتوں کا ایک زمرہ ہے جو صارف کے حساس ڈیٹا تک رسائی فراہم کرتا ہے۔ عام اجازتوں کے برعکس، خطرناک اجازتیں انسٹالیشن کے دوران خود بخود نہیں دی جاتیں — ایپلیکیشن کو Android 6.0 Marshmallow (API 23) میں متعارف کرائے گئے رن ٹائم میکانزم کے ذریعے رن ٹائم پر واضح طور پر ان کی درخواست کرنی ہوتی ہے۔

واضح درخواست کی ضرورت ان اعداد و شمار کی نوعیت کی وجہ سے ہے جن کی یہ اجازتیں حفاظت کرتی ہیں: صارف کا مقام، ذاتی رابطے، کیمرہ اور مائیکروفون کا مواد، کال ہسٹری اور SMS۔ Android اس ڈیٹا کو حساس سمجھتا ہے اور صارف کو شعوری طور پر رسائی دینے کی ضرورت ہوتی ہے۔ Android Privacy Sandbox (2024) کے مطابق، صارف اوسطاً تقریباً 30 فیصد رن ٹائم درخواستوں کو مسترد کرتے ہیں۔

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

ProtectionLevel dangerous

تحفظ کی سطح dangerous OS سطح پر سسٹم اجازت کی تعریفات میں سیٹ کی جاتی ہے۔ جب کوئی ایپلیکیشن اس protectionLevel کے ساتھ uses-permission کا اعلان کرتی ہے، تو سسٹم اجازت کو رن ٹائم درخواست کی ضرورت کے طور پر نشان زد کرتا ہے۔ normal کے برعکس، خطرناک اجازتیں ہمیشہ سسٹم اجازت کے انتظام کے انٹرفیس میں ظاہر ہوتی ہیں اور منسوخ کی جا سکتی ہیں۔

Permission Group اور Dangerous

تمام خطرناک اجازتیں فعال زمرے کے مطابق Permission Groups میں گروپ کی جاتی ہیں۔ مثال کے طور پر، CAMERA اور CAMERA2 CAMERA گروپ میں ہیں، ACCESS_FINE_LOCATION اور ACCESS_COARSE_LOCATION LOCATION گروپ میں ہیں۔ اگر صارف نے کسی گروپ سے ایک اجازت دی ہے، تو اسی گروپ کی باقی اجازتیں اضافی ڈائیلاگ کے بغیر خود بخود دے دی جاتی ہیں۔

رن ٹائم درخواست کیسے کام کرتی ہے

رن ٹائم درخواست ایک میکانزم ہے جس میں ایپلیکیشن اجازت کی درخواست کا ڈائیلاگ ظاہر کرنے کے لیے سسٹم API کو کال کرتی ہے۔ صارف اجازت کے نام اور Allow اور Deny بٹنوں کے ساتھ ایک موڈل ونڈو دیکھتا ہے۔ جواب کے بعد، سسٹم نتیجہ کے ساتھ onRequestPermissionsResult کال بیک کو کال کرتا ہے۔

مکمل چکر تین مراحل پر مشتمل ہے: checkSelfPermission کے ذریعے حیثیت چیک کرنا، اجازت نہ ہونے پر requestPermissions کو کال کرنا، اور onRequestPermissionsResult میں نتیجہ کو ہینڈل کرنا۔ حیثیت چیک لازمی ہے کیونکہ صارف نے ترتیبات کے ذریعے کسی بھی وقت اجازت منسوخ کر دی ہو سکتی ہے، اور بغیر چیک کیے فنکشن کو کال کرنے سے SecurityException ہو گا۔

fun checkAndRequestCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED -> {
            openCamera()
        }
        else -> {
            ActivityCompat.requestPermissions(
                this,
                arrayOf(Manifest.permission.CAMERA),
                REQUEST_CAMERA_CODE
            )
        }
    }
}

نتیجہ کی ہینڈلنگ ActivityResultLauncher یا onRequestPermissionsResult میں ہوتی ہے۔ تجویز کردہ جدید طریقہ ہے ActivityResultContracts.RequestPermission کا استعمال، جو واضح درخواست کوڈز کے بغیر ایک صاف API فراہم کرتا ہے۔ یہ معاہدہ Boolean لوٹاتا ہے — کہ اجازت دی گئی یا نہیں۔

درخواست کے بہترین طریقے

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

Android میں خطرناک اجازتوں کی فہرست

Android وضاحت کرتا ہے خطرناک اجازتوں کے کئی گروپ، ہر ایک میں ایک یا زیادہ مستقلات ہوتے ہیں۔ سب سے مکمل فہرست Manifest.permission کلاس میں دستیاب ہے۔ نیچے ترقی میں استعمال ہونے والے اہم گروپ اور اجازتیں دی گئی ہیں۔

Android 12+ میں نئی اجازتیں

Android 12 سے شروع کرتے ہوئے، Google نے کچھ اجازتوں کے لیے تقاضے سخت کر دیے ہیں۔ مثال کے طور پر، BLUETOOTH_CONNECT اور BLUETOOTH_SCAN خطرناک ہو گئی ہیں اور رن ٹائم درخواست کی ضرورت ہے۔ سینسرز تک پس منظر میں رسائی کے لیے BODY_SENSORS_BACKGROUND اجازت بھی شامل کی گئی ہے۔ ڈیولپرز کو targetSdkVersion اپ ڈیٹ کرنا ہو گا اور موجودہ OS ورژنز پر درخواستوں کا ٹیسٹ کرنا ہو گا۔

Android 13+ کے لیے اجازتیں

Android 13 (API 33) نے اطلاعوں (POST_NOTIFICATIONS) اور میڈیا فائلوں (READ_MEDIA_IMAGES، READ_MEDIA_VIDEO، READ_MEDIA_AUDIO) کے لیے نئی اجازتیں متعارف کرائیں، جنہوں نے عمومی READ_EXTERNAL_STORAGE کو بدل دیا۔ اب فوٹوز، ویڈیوز اور آڈیو تک رسائی ایک ہی ڈائیلاگ کے بغیر خصوصی اجازتوں کے ذریعے الگ الگ درخواست کی جاتی ہے۔

Dangerous بمقابلہ Normal Permission

Dangerous اور Normal Permission دینے کے طریقہ، منسوخی کی صلاحیت اور UX میں بنیادی طور پر مختلف ہیں۔ Normal انسٹالیشن کے دوران خود بخود دی جاتی ہے، Dangerous کے لیے واضح رن ٹائم ڈائیلاگ کی ضرورت ہوتی ہے۔ Normal کو ترتیبات کے ذریعے منسوخ نہیں کیا جا سکتا، Dangerous کو کسی بھی وقت غیر فعال کیا جا سکتا ہے۔ یہ عدم توازن مختلف ترقیاتی پیٹرن بناتا ہے۔

کوڈ کے نقطہ نظر سے، خطرناک اجازتوں کے لیے زیادہ کام درکار ہے: checkSelfPermission، requestPermissions، رد عمل کو ہینڈل کرنا۔ عام اجازتوں کے لیے، AndroidManifest.xml میں ایک لائن کافی ہے۔ تاہم، Dangerous Permission صارف کو کنٹرول دیتی ہے، جو اعتماد بڑھاتا ہے، خاص طور پر کیمرہ یا مقام جیسی حساس خصوصیات کے لیے۔

زمرہ جات کے درمیان انتخاب ڈیولپر پر نہیں ہے — یہ سسٹم کے ذریعے طے کیا جاتا ہے۔ ڈیولپر صرف uses-permission کا اعلان کرتا ہے، اور سسٹم protectionLevel کی بنیاد پر زمرہ طے کرتا ہے۔ تاہم، خطرناک اجازتوں کی درخواست کی حکمت عملی صارف کے تجربے کو متاثر کرتی ہے: بار بار یا نامناسب ڈائیلاگ ایپلیکیشن کی درجہ بندی کو کم کرتے ہیں۔

Kotlin میں اجازتیں کیسے درخواست کریں

جدید طریقہ Kotlin میں اجازتیں درخواست کرنے کا ActivityResultContracts.RequestMultiplePermissions یا RequestPermission استعمال کرنا ہے۔ یہ معاہدے androidx.activity لائبریری کا حصہ ہیں اور onRequestPermissionsResult کو اوور رائڈ کرنے کی ضرورت کے بغیر lambda پر مبنی ایک صاف API فراہم کرتے ہیں۔

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                showPermissionDeniedMessage()
            }
        }

    fun requestCamera() {
        when {
            ContextCompat.checkSelfPermission(
                this,
                Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED ->
                openCamera()
            ActivityCompat.shouldShowRequestPermissionRationale(
                this,
                Manifest.permission.CAMERA
            ) ->
                showRationaleDialog()
            else ->
                requestPermissionLauncher.launch(
                    Manifest.permission.CAMERA
                )
        }
    }
}

ایک ساتھ متعدد اجازتوں کی درخواست کرنا

جب کسی ایپلیکیشن کو ایک ساتھ متعدد خطرناک اجازتوں کی ضرورت ہو، RequestMultiplePermissions استعمال کریں۔ معاہدہ Map<String, Boolean> لوٹاتا ہے جہاں کلید اجازت کا نام اور قدر نتیجہ ہے۔ یہ پہلی لانچ پر مفید ہے جب ویڈیو ریکارڈنگ کے لیے CAMERA اور RECORD_AUDIO کی درخواست کرنے کی ضرورت ہوتی ہے۔

پہلی بار رد عمل کو ہینڈل کرنا

اگر صارف درخواست کو مسترد کرتا ہے، تو shouldShowRequestPermissionRationale طریقہ true لوٹاتا ہے۔ یہ اشارہ ہے کہ اجازت کی ضرورت کی وضاحت ظاہر کی جائے۔ بہترین طریقہ یہ ہے کہ وضاحت اور دوبارہ کوشش کریں بٹن کے ساتھ ایک حسب ضرورت ڈائیلاگ دکھایا جائے۔ اگر صارف Never Ask Again چیک باکس کو نشان زد کرکے دوبارہ درخواست مسترد کرتا ہے، تو shouldShowRequestPermissionRationale false لوٹائے گا، اور آپ کو ترتیبات پر ری ڈائریکٹ کرنے کی ضرورت ہے۔

رد عمل اور Never Ask Again کو ہینڈل کرنا

Never Ask Again ایک جھنڈا ہے جسے صارف رن ٹائم ڈائیلاگ کو دوسری بار مسترد کرتے وقت سیٹ کر سکتا ہے۔ اس کے بعد، اس اجازت کے لیے معیاری ڈائیلاگ مزید نہیں دکھایا جاتا۔ رسائی دینے کا واحد طریقہ صارف کو سسٹم ایپ ترتیبات پر ری ڈائریکٹ کرنا ہے۔

ڈیولپر کو دو رد عمل کے منظرناموں کے درمیان فرق کرنا ہو گا: پہلا، جب shouldShowRequestPermissionRationale true لوٹاتا ہے (صارف نے مسترد کر دیا لیکن ڈائیلاگ اب بھی دکھایا جا سکتا ہے)، اور دوسرا، جب طریقہ false لوٹاتا ہے (Never Ask Again فعال ہے یا اجازت پالیسی کے ذریعے مسدود ہے)۔ دوسرے معاملے میں، آپ کو ترتیبات کھولیں بٹن دکھانا چاہیے۔

fun handlePermissionDenied(permission: String) {
    if (ActivityCompat.shouldShowRequestPermissionRationale(
            this, permission
    )) {
        showRationaleDialog(permission)
    } else {
        showSettingsRedirectDialog(permission)
    }
}

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("رسائی سے انکار کر دیا گیا")
        .setMessage(
            "اجازت مسدود ہے۔ ترتیبات کھولیں۔"
        )
        .setPositiveButton("ترتیبات") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

یہ ضروری ہے کہ اگر shouldShowRequestPermissionRationale نے false لوٹایا ہے تو اجازت دوبارہ درخواست نہ کی جائے۔ اس معاملے میں requestPermissions کا بار بار کال کرنا کوئی ڈائیلاگ نہیں دکھائے گا — نتیجہ وضاحت کے بغیر فوری طور پر DENIED کے ساتھ واپس آئے گا۔ صارف کو غیر واضح رویے کا سامنا کرنا پڑے گا، جو ایپلیکیشن کے تجربے پر منفی اثر ڈالتا ہے۔