Runtime Permission: کتنی اقسام ہیں اور Android میں کام کرنے کا اصول

Runtime Permission کیا ہے؟

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

Android اجازت ماڈل کا ارتقاء

Android 6.0 سے پہلے، صارف انسٹالیشن کے وقت تمام اجازتوں کی فہرست دیکھتا تھا اور یا تو سب کو قبول کر سکتا تھا یا انسٹالیشن سے انکار کر سکتا تھا۔ 2015 کے ایک مطالعے سے پتہ چلا کہ 87% صارفین انسٹالیشن کے وقت اجازت کی فہرست نہیں پڑھتے۔ Android 6.0 نے runtime permissions متعارف کرائیں، اجازتوں کو معمولی (خودکار) اور خطرناک (درخواست کے ساتھ) میں تقسیم کیا۔ Android 11 نے ایک بار کی اجازتیں شامل کیں — ایپ بند ہونے پر خودکار منسوخی۔ Android 13 نے فوٹو پکر اور پش نوٹیفیکیشنز کو علیحدہ runtime permissions کے طور پر متعارف کرایا۔

iOS iOS 10 سے اسی طرح کا ماڈل استعمال کرتا ہے، جہاں کیمرہ، مائیکروفون اور جغرافیائی مقام تک رسائی پہلے استعمال پر درخواست کی جاتی ہے۔ تاہم، iOS میں “معمولی اجازتوں” کا تصور نہیں ہے — ہر اجازت واضح طور پر درخواست کی جاتی ہے، اور انکار اس وقت تک برقرار رہتا ہے جب تک ڈیولپر سسٹم سیٹنگز کے ذریعے دوبارہ درخواست نہ کرے۔

Android میں Runtime Permission کیسے کام کرتا ہے؟

Runtime Permission requestPermissions() طریقہ (AndroidX — ActivityResultLauncher) کے ذریعے بلائے گئے سسٹم ڈائیلاگ کے ذریعے کام کرتا ہے۔ سسٹم ایک وضاحت کے ساتھ معیاری ڈائیلاگ دکھاتا ہے، اور صارف “اجازت دیں” یا “انکار کریں” کا انتخاب کرتا ہے۔ جواب کے بعد، ایک کال بیک متحرک ہوتا ہے جہاں ایپ صارف کے فیصلے پر عمل کرتی ہے۔

ActivityResultLauncher کے ذریعے اجازت کی درخواست

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

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

shouldShowRequestPermissionRationale طریقہ true لوٹاتا ہے اگر صارف پہلے ہی ایک بار درخواست کو مسترد کر چکا ہے۔ اس صورت میں، یہ تجویز کیا جاتا ہے کہ وضاحت کے ساتھ ایک ڈائیلاگ دکھایا جائے کہ ایپ کو اجازت کیوں ضروری ہے، اور اس کے بعد ہی دوبارہ درخواست کی جائے۔ اس سے صارف کی رضامندی کا امکان 30–40% بڑھ جاتا ہے (Google I/O 2024 ڈیٹا)۔

Android میں اجازتوں کی اقسام

Android تمام اجازتوں کو کئی تحفظ کی سطحوں میں درجہ بندی کرتا ہے: معمولی، خطرناک، دستخط اور خصوصی۔ معمولی اجازتیں انسٹالیشن پر خود بخود دی جاتی ہیں۔ خطرناک اجازتیں runtime درخواست کی ضرورت ہوتی ہیں۔ دستخط اجازتیں صرف اسی سرٹیفکیٹ سے دستخط شدہ ایپس کے لیے دستیاب ہیں۔

خطرناک اجازت گروپس

خصوصی اجازتیں (SYSTEM_ALERT_WINDOW، WRITE_SETTINGS، MANAGE_EXTERNAL_STORAGE) کو Settings.ACTION_MANAGE_OVERLAY_PERMISSION کے ذریعے سسٹم سیٹنگز میں اضافی نیویگیشن درکار ہوتی ہے۔ ان اجازتوں کی درخواست معیاری سسٹم ڈائیلاگ کے ذریعے نہیں کی جا سکتی اور سیٹنگز اسکرین میں صارف کے واضح عمل کی ضرورت ہوتی ہے۔

Android 12+ میں اجازتوں کی درخواست

Android 12 نے runtime permissions ماڈل میں اہم تبدیلیاں متعارف کرائیں۔ ایک بار کی اجازتیں صرف ایک سیشن کے لیے کیمرہ، مائیکروفون یا جغرافیائی مقام تک رسائی دینے کی اجازت دیتی ہیں۔ جیسے ہی صارف ایپ بند کرتا ہے، اجازت خود بخود منسوخ ہو جاتی ہے۔ پرائیویسی اشارے اسٹیٹس بار میں سبز اشارے ہیں جو دکھاتے ہیں کہ ایپ کیمرہ یا مائیکروفون استعمال کر رہی ہے۔

ایک بار کی اجازتوں کو ہینڈل کرنا

// Android 12+ — ایک بار کی لوکیشن اجازت کو ہینڈل کرنا
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// چیک کریں کہ آیا اجازت سسٹم کے ذریعے منسوخ کر دی گئی تھی (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 نے POST_NOTIFICATIONS اجازت کو خطرناک گروپ میں شامل کیا، جس کے لیے پش نوٹیفیکیشن بھیجنے کے لیے واضح درخواست درکار ہے۔ Android 14 نے پس منظر کے جغرافیائی مقام پر پابندیاں لگائیں: ایپ کو ہر بار پس منظر کی لوکیشن کی درخواست کرنے پر صارف کی واضح منظوری لینی ہوگی۔ فوٹو پکر (API 33+) نے تصویر کے انتخاب کے لیے READ_EXTERNAL_STORAGE کی ضرورت کو ختم کر دیا۔

صارف کے انکار کو ہینڈل کرنا

صارف کا اجازت کی درخواست کو مسترد کرنا ایک معمولی صورت حال ہے جسے صحیح طریقے سے ہینڈل کیا جانا چاہیے۔ انکار کی دو اقسام ہیں: ایک بار (صارف نے “انکار کریں” دبایا) اور مستقل (صارف نے “دوبارہ نہ پوچھیں” کا انتخاب کیا)۔ دوسری صورت میں، سسٹم ڈائیلاگ دوبارہ ظاہر نہیں ہوگا، اور ایپ کو صارف کو سسٹم سیٹنگز پر ری ڈائریکٹ کرنا ہوگا۔

انکار کو ہینڈل کرنے کی حکمت عملی

پہلے انکار کے بعد، ایپ کو ایک استدلال ڈائیلاگ دکھانا چاہیے — اس کی اپنی وضاحت کہ اجازت کیوں ضروری ہے۔ اگر صارف دوبارہ انکار کرتا ہے، تو ایپ کو Settings.ACTION_APPLICATION_DETAILS_SETTINGS کے ذریعے ایپ سیٹنگز اسکرین پر ری ڈائریکٹ کرنا چاہیے۔ Material 3 زیادہ قدرتی UX کے لیے PermissionRequestBottomSheet استعمال کرنے کی سفارش کرتا ہے۔

انکار پر ایپ کی فعالیت کو مکمل طور پر مسدود نہ کرنا ضروری ہے۔ مثال کے طور پر، اگر صارف نے جغرافیائی مقام کو مسترد کر دیا، تو ایپ کو دستی پتہ درج کرنے کی سہولت فراہم کرنی چاہیے۔ کیمرہ کے لیے، گیلری سے تصویر اپ لوڈ کرنے کی اجازت دیں۔ Google سفارش کرتا ہے کہ تمام runtime permissions کے لیے ہمیشہ ایک متبادل طریقہ کار فراہم کیا جائے۔

سیکورٹی سفارشات

Runtime permissions صرف ایک تکنیکی طریقہ کار نہیں ہیں، بلکہ ایپ میں صارف کے اعتماد کا ایک عنصر بھی ہیں۔ نامناسب وقت پر اجازت کی درخواست (مثال کے طور پر، پہلی لانچ پر) رضامندی کے امکان کو نمایاں طور پر کم کر دیتی ہے۔ Google Play Store اجازت کی درخواستوں کی تعدد اور سیاق و سباق کا تجزیہ کرتا ہے: جارحانہ درخواستوں والی ایپس تلاش میں کم مقام حاصل کرتی ہیں۔

اجازت کی درخواست کے قواعد

سیاق و سباق — اس عمل کو انجام دینے سے فوراً پہلے اجازت کی درخواست کریں جس کے لیے اس کی ضرورت ہے۔ کم از کم — صرف انہی اجازتوں کی درخواست کریں جو واقعی فیچر کے کام کرنے کے لیے ضروری ہیں۔ شفافیت — سسٹم ڈائیلاگ سے پہلے صارف کو بتائیں کہ اجازت کیوں ضروری ہے۔ منسوخی — runtime پر اجازت کی منسوخی کو صحیح طریقے سے ہینڈل کرنے کے لیے ACTION_PERMISSION_REVOCATION کو سبسکرائب کریں۔

Runtime permissions کی جانچ کے لیے، adb کمانڈز استعمال کریں: adb shell pm revoke <package> android.permission.CAMERA ایپ کو دوبارہ انسٹال کیے بغیر اجازت کی منسوخی کو نقل کرنے کی اجازت دیتا ہے۔ Espresso اور UiAutomator GrantPermissionRule کے ذریعے اجازت ڈائیلاگ کی جانچ کی حمایت کرتے ہیں۔ Runtime permissions والی ایپس کے لیے CI/CD پائپ لائن میں ان ٹولز کا انضمام لازمی ہے۔

Google Play Console میں اجازت کی آڈیٹنگ

Google Play Console ایک اجازت آڈیٹنگ سیکشن فراہم کرتا ہے، جہاں ڈیولپر دیکھ سکتا ہے کہ کتنی بار اجازتوں کی درخواست کی جاتی ہے، کتنے فیصد صارفین رسائی فراہم کرتے ہیں اور کون سی اجازتیں منسوخ کی گئیں۔ اس ڈیٹا کا تجزیہ غیر موثر درخواستوں کی شناخت اور UX کو بہتر بنانے میں مدد کرتا ہے۔ مثال کے طور پر، اگر 40% سے کم صارفین جغرافیائی مقام فراہم کرتے ہیں، تو درخواست کے وقت پر نظر ثانی کریں اور زیادہ قائل استدلال شامل کریں۔

اجازت سے متعلق ANR (ایپلیکیشن ریسپانس نہیں دے رہی) کی نگرانی کے لیے Android Vitals کا استعمال بھی اہم ہے۔ اگر اجازت کی درخواست مرکزی تھریڈ پر عمل میں لائی جائے یا سسٹم ڈائیلاگ UI کو مسدود کرے، تو یہ سست آلات پر ANR کا سبب بن سکتا ہے۔ یوزر انٹرفیس کو مسدود ہونے سے بچنے کے لیے اجازت کی جانچ اور درخواست کو علیحدہ تھریڈ پر منتقل کریں یا غیر مطابقت پذیر ہینڈلنگ کے لیے Kotlin coroutines استعمال کریں۔