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-এর বিপরীতে, বিপজ্জনক অনুমতিগুলি সর্বদা সিস্টেম অনুমতি পরিচালনা UI-তে প্রদর্শিত হয় এবং প্রত্যাহার করা যেতে পারে।

Permission Group এবং Dangerous

সমস্ত বিপজ্জনক অনুমতি কার্যকরী বিভাগ অনুসারে Permission Groups-এ grouped করা হয়। উদাহরণস্বরূপ, 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 সহ ফিরে আসবে। ব্যবহারকারী অস্পষ্ট আচরণের সম্মুখীন হবেন, যা অ্যাপ্লিকেশন অভিজ্ঞতাকে নেতিবাচকভাবে প্রভাবিত করে।