Runtime Permission: কী কী প্রকার রয়েছে এবং Android-এ কাজের নীতি

Runtime Permission কী?

Runtime Permission হল একটি Android নিরাপত্তা মডেল যেখানে অ্যাপ সেই সময়ে সংবেদনশীল ডেটা অ্যাক্সেসের অনুরোধ করে যখন সেই কার্যকারিতাটি ব্যবহারকারীর জন্য সত্যিই প্রয়োজনীয়। Android 6.0-এর আগে, সমস্ত অনুমতি অ্যাপ ইনস্টলেশনের সময় প্রদান করা হত এবং ব্যবহারকারী অ্যাপটি সম্পূর্ণভাবে আনইনস্টল না করে সেগুলি প্রত্যাহার করতে পারত না।

Android অনুমতি মডেলের বিবর্তন

Android 6.0-এর আগে, ব্যবহারকারী ইনস্টলেশনের সময় সমস্ত অনুমতির একটি তালিকা দেখত এবং হয় সমস্ত গ্রহণ করতে পারত বা ইনস্টলেশন প্রত্যাখ্যান করতে পারত। 2015 সালের একটি গবেষণায় দেখা গেছে যে 87% ব্যবহারকারী ইনস্টলেশনের সময় অনুমতি তালিকা পড়েন না। Android 6.0 রানটাইম অনুমতি চালু করেছে, অনুমতিগুলিকে সাধারণ (স্বয়ংক্রিয়) এবং বিপজ্জনক (অনুরোধ সহ) এ বিভক্ত করেছে। Android 11 একবারের অনুমতি যোগ করেছে — অ্যাপ বন্ধ হলে স্বয়ংক্রিয় প্রত্যাহার। Android 13 ফটো পিকার এবং পুশ বিজ্ঞপ্তিগুলিকে পৃথক রানটাইম অনুমতি হিসাবে চালু করেছে।

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 সমস্ত অনুমতিকে বিভিন্ন সুরক্ষা স্তরে শ্রেণীবদ্ধ করে: সাধারণ, বিপজ্জনক, স্বাক্ষর এবং বিশেষ। সাধারণ অনুমতিগুলি ইনস্টলেশনের সময় স্বয়ংক্রিয়ভাবে প্রদান করা হয়। বিপজ্জনক অনুমতিগুলি রানটাইম অনুরোধ প্রয়োজন। স্বাক্ষর অনুমতিগুলি শুধুমাত্র একই সার্টিফিকেট দিয়ে স্বাক্ষরিত অ্যাপগুলির জন্য উপলব্ধ।

বিপজ্জনক অনুমতি গ্রুপ

বিশেষ অনুমতিগুলি (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) Settings.ACTION_MANAGE_OVERLAY_PERMISSION-এর মাধ্যমে সিস্টেম সেটিংসে অতিরিক্ত নেভিগেশন প্রয়োজন। এই অনুমতিগুলি মানক সিস্টেম ডায়ালগের মাধ্যমে অনুরোধ করা যায় না এবং সেটিংস স্ক্রিনে ব্যবহারকারীর স্পষ্ট পদক্ষেপ প্রয়োজন।

Android 12+-এ অনুমতির অনুরোধ

Android 12 রানটাইম অনুমতি মডেলে উল্লেখযোগ্য পরিবর্তন এনেছে। একবারের অনুমতিগুলি শুধুমাত্র একটি সেশনের জন্য ক্যামেরা, মাইক্রোফোন বা জিওলোকেশনে অ্যাক্সেস প্রদানের অনুমতি দেয়। ব্যবহারকারী অ্যাপ বন্ধ করার সাথে সাথে অনুমতি স্বয়ংক্রিয়ভাবে প্রত্যাহার করা হয়। গোপনীয়তা সূচকগুলি হল স্ট্যাটাস বারে সবুজ সূচক যা দেখায় কখন অ্যাপ ক্যামেরা বা মাইক্রোফোন ব্যবহার করছে।

একবারের অনুমতিগুলি পরিচালনা

// 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 সুপারিশ করে যে সমস্ত রানটাইম অনুমতির জন্য সর্বদা একটি বিকল্প প্রক্রিয়া প্রদান করা উচিত।

নিরাপত্তা সুপারিশ

রানটাইম অনুমতিগুলি শুধুমাত্র একটি প্রযুক্তিগত প্রক্রিয়া নয়, বরং অ্যাপের প্রতি ব্যবহারকারীর আস্থার একটি উপাদানও। অনুপযুক্ত সময়ে অনুমতি অনুরোধ (উদাহরণস্বরূপ, প্রথম লঞ্চে) সম্মতির সম্ভাবনা উল্লেখযোগ্যভাবে হ্রাস করে। Google Play Store অনুমতি অনুরোধের ফ্রিকোয়েন্সি এবং প্রসঙ্গ বিশ্লেষণ করে: আক্রমণাত্মক অনুরোধযুক্ত অ্যাপগুলি অনুসন্ধানে নিম্ন অবস্থান পায়।

অনুমতি অনুরোধের নিয়ম

প্রসঙ্গ — যে কাজটির জন্য প্রয়োজন সেই কাজটি করার ঠিক আগে অনুমতি অনুরোধ করুন। সর্বনিম্ন — শুধুমাত্র সেই অনুমতিগুলির অনুরোধ করুন যা বৈশিষ্ট্যটি কাজ করার জন্য সত্যিই প্রয়োজনীয়। স্বচ্ছতা — সিস্টেম ডায়ালগের আগে ব্যবহারকারীকে ব্যাখ্যা করুন কেন অনুমতি প্রয়োজন। প্রত্যাহার — রানটাইমে অনুমতি প্রত্যাহার সঠিকভাবে পরিচালনা করতে ACTION_PERMISSION_REVOCATION-এ সাবস্ক্রাইব করুন।

রানটাইম অনুমতি পরীক্ষার জন্য, adb কমান্ড ব্যবহার করুন: adb shell pm revoke <package> android.permission.CAMERA অ্যাপ পুনরায় ইনস্টল না করেই অনুমতি প্রত্যাহার সিমুলেট করার অনুমতি দেয়। Espresso এবং UiAutomator GrantPermissionRule-এর মাধ্যমে অনুমতি ডায়ালগ পরীক্ষা সমর্থন করে। রানটাইম অনুমতি সহ অ্যাপগুলির জন্য CI/CD পাইপলাইনে এই সরঞ্জামগুলির সংহতকরণ বাধ্যতামূলক।

Google Play Console-এ অনুমতি অডিটিং

Google Play Console একটি অনুমতি অডিটিং বিভাগ সরবরাহ করে, যেখানে ডেভেলপাররা দেখতে পারেন কতবার অনুমতি অনুরোধ করা হয়েছে, কত শতাংশ ব্যবহারকারী অ্যাক্সেস প্রদান করে এবং কোন অনুমতিগুলি প্রত্যাহার করা হয়েছে। এই ডেটা বিশ্লেষণ অকার্যকর অনুরোধগুলি সনাক্ত করতে এবং UX অপ্টিমাইজ করতে সহায়তা করে। উদাহরণস্বরূপ, যদি 40% এর কম ব্যবহারকারী জিওলোকেশন প্রদান করে, তবে অনুরোধের সময় পুনর্বিবেচনা করুন এবং আরও বাধ্যতামূলক যুক্তি যুক্ত করুন।

অনুমতি-সম্পর্কিত ANR (অ্যাপ্লিকেশন নট রেসপন্ডিং) পর্যবেক্ষণের জন্য Android Vitals ব্যবহার করাও গুরুত্বপূর্ণ। যদি প্রধান থ্রেডে অনুমতি অনুরোধ কার্যকর করা হয় বা সিস্টেম ডায়ালগ UI ব্লক করে, তবে এটি ধীর ডিভাইসগুলিতে ANR সৃষ্টি করতে পারে। ব্যবহারকারী ইন্টারফেস ব্লক করা এড়াতে অনুমতি পরীক্ষা এবং অনুরোধ একটি পৃথক থ্রেডে সরান বা অ্যাসিঙ্ক্রোনাস হ্যান্ডলিংয়ের জন্য Kotlin করুটিন ব্যবহার করুন।