AndroidManifest Permissions: মূল ধারণা, ঘোষণা এবং অনুমতির প্রকার

AndroidManifest Permissions কী?

AndroidManifest Permissions হল Android-এর নিরাপত্তা ব্যবস্থা যা সুরক্ষিত ডেটা এবং সিস্টেম ফাংশনে অ্যাপ্লিকেশন অ্যাক্সেস নিয়ন্ত্রণ করে। প্রতিটি অ্যাপ্লিকেশনকে এলিমেন্ট ব্যবহার করে AndroidManifest.xml ফাইলে প্রয়োজনীয় অনুমতি ঘোষণা করতে হবে। ঘোষণা ছাড়া, সংশ্লিষ্ট API কল করলে SecurityException নিরাপত্তা ত্রুটি হবে।

Android অনুমতি মডেল বিবর্তনের বেশ কয়েকটি ধাপ অতিক্রম করেছে। Android 6.0 (API 23) এর আগে, সমস্ত অনুমতি ইনস্টলেশনের সময় প্রদান করা হত — ব্যবহারকারী সম্পূর্ণ তালিকা দেখত এবং অ্যাপ্লিকেশন ইনস্টল করতে সম্মত বা অস্বীকার করত। Android 6.0 থেকে শুরু করে, dangerous স্তরের অনুমতিগুলি রানটাইমে (Runtime Permissions) অনুরোধ করা হয়, যা ব্যবহারকারীকে আরও নমনীয় নিয়ন্ত্রণ দেয়।

অনুমতিগুলি চারটি সুরক্ষা স্তরে বিভক্ত: normal (ইনস্টলেশনে স্বয়ংক্রিয়ভাবে প্রদান), dangerous (রানটাইম অনুরোধ প্রয়োজন), signature (শুধুমাত্র একই সার্টিফিকেট দিয়ে স্বাক্ষরিত অ্যাপ্লিকেশনের জন্য উপলব্ধ) এবং special (সেটিংসে পৃথক সক্রিয়করণ প্রয়োজন)। প্রতিটি স্তরের নিজস্ব প্রদান এবং প্রত্যাহার প্রক্রিয়া রয়েছে।

Google I/O 2024 অনুসারে, Android 15 আরও গ্র্যানুলার অনুমতি চালু করার পরিকল্পনা করছে — ব্যবহারকারী পুরো মিডিয়া লাইব্রেরির পরিবর্তে শুধুমাত্র নির্দিষ্ট ফাইলগুলিতে অ্যাক্সেস দিতে পারবেন। এটি ডিফল্টরূপে প্রদত্ত ডেটার পরিমাণ কমানোর Android-এর প্রবণতা অব্যাহত রাখে।

iOS অনুমতি মডেল থেকে পার্থক্য

iOS-এর বিপরীতে, যেখানে সমস্ত অনুমতি রানটাইমে অনুরোধ করা হয়, Android অনুমতিগুলিকে ইনস্টল-টাইম এবং রানটাইমে বিভক্ত করে। normal স্তর ব্যবহারকারীকে না জানিয়েই ইনস্টলেশনে স্বয়ংক্রিয়ভাবে প্রদান করা হয়। dangerous স্তরের iOS-এর মতো স্পষ্ট ডায়ালগ প্রয়োজন।

আরেকটি পার্থক্য: Android-এ, অনুমতিগুলি অনুমতি গ্রুপে সংগঠিত। যদি ব্যবহারকারী ক্যামেরা অ্যাক্সেসে সম্মত হন, অ্যাপ্লিকেশন স্বয়ংক্রিয়ভাবে মাইক্রোফোন অ্যাক্সেস পায় — তারা একই MICROPHONE গ্রুপে রয়েছে। iOS-এ, প্রতিটি অনুমতি গ্রুপ নির্বিশেষে স্বাধীনভাবে অনুরোধ করা হয়।

Android সংস্করণ অনুসারে অনুমতির বিবর্তন

অনুমতির কী কী প্রকার রয়েছে

Android অনুমতির জন্য চারটি সুরক্ষা স্তর সংজ্ঞায়িত করে, প্রতিটির নিজস্ব প্রদান নিয়ম রয়েছে। আসুন প্রতিটি স্তর বিস্তারিতভাবে দেখি।

Normal অনুমতি (ইনস্টল-টাইম)

Normal অনুমতিগুলি ব্যবহারকারীকে না জানিয়ে বা অনুরোধ না করেই অ্যাপ্লিকেশন ইনস্টলেশনে স্বয়ংক্রিয়ভাবে প্রদান করা হয়। এগুলি নিম্ন-ঝুঁকির ফাংশন কভার করে যা ব্যবহারকারীর গোপনীয়তার জন্য হুমকি নয়: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH। ব্যবহারকারী কোনও সম্মতি ডায়ালগ দেখেন না — অনুমতি ইনস্টলেশনের পরেই প্রদান করা হয়েছে বলে গণ্য হয়।

Normal অনুমতির জন্য ডেভেলপারকে কোডে অনুরোধ পরিচালনা করার প্রয়োজন নেই — ম্যানিফেস্টে ঘোষণা করাই যথেষ্ট। তবে, Android 12+-এ, Google Play থেকে ইনস্টল করার সময়, ব্যবহারকারী সমস্ত normal অনুমতি তালিকাভুক্ত একটি «অনুমতি» ট্যাব দেখেন, যা স্বচ্ছতা বাড়ায়। Statista (2024) অনুসারে, Google Play-তে 90% এর বেশি অ্যাপ্লিকেশন সবচেয়ে সাধারণ normal অনুমতি হিসেবে INTERNET ব্যবহার করে।

Dangerous অনুমতি (রানটাইম)

Dangerous অনুমতিগুলি ডেটা এবং ফাংশনে অ্যাক্সেস কভার করে যা গোপনীয়তার সাথে আপস করতে পারে: ক্যামেরা, মাইক্রোফোন, জিওলোকেশন, পরিচিতি, SMS, ফোন, ক্যালেন্ডার, বডি সেন্সর। এই অনুমতিগুলির একটি দুই-পদক্ষেপ প্রক্রিয়া প্রয়োজন: ম্যানিফেস্টে ঘোষণা + ActivityCompat.requestPermissions()-এর মাধ্যমে রানটাইম অনুরোধ।

ব্যবহারকারী একটি dangerous অনুমতি অস্বীকার করতে পারেন, এবং অ্যাপ্লিকেশনকে এই পরিস্থিতি সঠিকভাবে পরিচালনা করতে হবে। Android 11+-এ, যদি ব্যবহারকারী দুবার অস্বীকার করেন, পরবর্তী অনুরোধগুলি সিস্টেম ডায়ালগ দেখায় না — সিস্টেম স্বয়ংক্রিয়ভাবে DENIED ফেরত দেয়। এই ক্ষেত্রে, অ্যাপ্লিকেশনকে ব্যবহারকারীকে সেটিংসে নির্দেশিত করা উচিত।

Signature এবং Special অনুমতি

signature স্তর — অনুমতি স্বয়ংক্রিয়ভাবে প্রদান করা হয় যদি অ্যাপ্লিকেশন একই সার্টিফিকেট দিয়ে স্বাক্ষরিত হয় যা সিস্টেম বা অন্য একটি অ্যাপ্লিকেশন অনুমতিটি সংজ্ঞায়িত করেছে। সিস্টেম এবং কর্পোরেট অ্যাপ্লিকেশনের জন্য ব্যবহৃত হয়। উদাহরণ: BIND_ACCESSIBILITY_SERVICE — শুধুমাত্র সিস্টেম অ্যাপ্লিকেশনের জন্য উপলব্ধ।

special স্তর (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — সিস্টেম সেটিংসের মাধ্যমে ব্যবহারকারীর স্পষ্ট পদক্ষেপ প্রয়োজন। অ্যাপ্লিকেশন Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION) ব্যবহার করে সেটিংস পৃষ্ঠা খুলতে পারে। Google Play special অনুমতি ব্যবহার সীমাবদ্ধ করে এবং প্রকাশনার সময় ফর্মে যৌক্তিকতা প্রয়োজন।

Runtime Permission: dangerous অনুমতি নিয়ে কাজ করা

Android 6.0 থেকে, সমস্ত dangerous অনুমতির রানটাইম অনুরোধ প্রয়োজন। আসুন Kotlin-এ রানটাইম অনুমতি নিয়ে সম্পূর্ণ কাজের চক্র দেখি।

অনুমতি পরীক্ষা এবং অনুরোধ

যে API-র জন্য dangerous অনুমতি প্রয়োজন তা কল করার আগে, সর্বদা ContextCompat.checkSelfPermission()-এর মাধ্যমে বর্তমান স্থিতি পরীক্ষা করুন। যদি স্থিতি PERMISSION_GRANTED হয়, আপনি API কল করতে পারেন। যদি PERMISSION_DENIED হয়, আপনাকে ActivityResultContract RequestPermission (AndroidX) বা পুরোনো requestPermissions()-এর মাধ্যমে অনুমতি অনুরোধ করতে হবে।

একসাথে একাধিক অনুমতি অনুরোধ করতে ActivityResultContracts.RequestMultiplePermissions ব্যবহার করার পরামর্শ দেওয়া হয়। Google একটি ডায়ালগে সম্পর্কিত অনুমতি (যেমন, ভিডিও রেকর্ডিংয়ের জন্য ক্যামেরা + মাইক্রোফোন) গ্রুপ করার পরামর্শ দেয়, যাতে ব্যবহারকারী অনুরোধের সম্পূর্ণ প্রসঙ্গ দেখতে পান।

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

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

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

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

«আবার জিজ্ঞাসা করবেন না» অস্বীকৃতি পরিচালনা

যদি ব্যবহারকারী দুবার অস্বীকার করেন, Android অনুরোধটিকে «Never ask again» অবস্থায় নিয়ে যায়। এই ক্ষেত্রে, shouldShowRequestPermissionRationale() false ফেরত দেয় এবং সিস্টেম ডায়ালগ দেখানো হবে না। অ্যাপ্লিকেশনকে Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS)-এর মাধ্যমে ব্যবহারকারীকে সিস্টেম সেটিংসে নির্দেশিত করা উচিত।

গুরুত্বপূর্ণ: প্রথম অস্বীকৃতির পরপরই সেটিংস খোলার অফার দেওয়া ডায়ালগ দেখাবেন না — এটি আক্রমণাত্মক আচরণ হিসাবে বিবেচিত হয়। shouldShowRequestPermissionRationale() ব্যবহার করে নির্ধারণ করুন যে ব্যাখ্যা দেখানোর প্রয়োজন কিনা। Material Design Guidelines শুধুমাত্র «সেটিংস খুলুন» বোতামের পরিবর্তে অ্যাক্সেসের মান ব্যাখ্যা করে একটি স্ক্রিন দেখানোর পরামর্শ দেয়।

private fun openAppSettings() {
    Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", packageName, null)
    ).also { intent ->
        startActivity(intent)
    }
}

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("ক্যামেরায় অ্যাক্সেস")
        .setMessage("সেটিংসে ক্যামেরা অ্যাক্সেসের অনুমতি দিন, "
            + "প্রোফাইল ছবি তোলার জন্য")
        .setPositiveButton("সেটিংস খুলুন") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("বাতিল করুন", null)
        .show()
}

AndroidManifest.xml-এ অনুমতি ঘোষণা

AndroidManifest.xml ফাইলে প্রতিটি অনুমতির জন্য এলিমেন্ট থাকে যা অ্যাপ্লিকেশন ব্যবহার করে। অনুমতিগুলি স্তরে এলিমেন্টের আগে ঘোষণা করা হয়।

ঘোষণার সিনট্যাক্স

প্রতিটি অনুমতি একটি পৃথক এলিমেন্টের সাথে android:name অ্যাট্রিবিউট ব্যবহার করে ঘোষণা করা হয় যা সম্পূর্ণ অনুমতি নাম নির্দিষ্ট করে। নির্দিষ্ট Android সংস্করণে চালু করা অনুমতির জন্য, ঘোষণাটি শুধুমাত্র প্রয়োজনীয় সংস্করণে সীমাবদ্ধ করতে maxSdkVersion অ্যাট্রিবিউট ব্যবহার করুন — এটি সামঞ্জস্য উন্নত করে।

উদাহরণস্বরূপ, WRITE_EXTERNAL_STORAGE অনুমতি Android 10+ (Scoped Storage) এ প্রয়োজন নেই, তাই maxSdkVersion="28" (Android 9) নির্দিষ্ট করুন। এটি নতুন সংস্করণে ব্যবহারকারীদের অপ্রয়োজনীয় প্রশ্ন প্রতিরোধ করে। Android Studio Lint-এর মাধ্যমে প্রস্তাবিত maxSdkVersion সম্পর্কে সতর্ক করে।

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

    <uses-feature
        android:name="android.hardware.camera"
        android:required="false" />

    <application>
        <!-- ... -->
    </application>
</manifest>

ফিল্টারিংয়ের জন্য ব্যবহার

এলিমেন্ট নির্দেশ করে যে অ্যাপ্লিকেশনটির নির্দিষ্ট হার্ডওয়্যার (ক্যামেরা, GPS, NFC) প্রয়োজন। android:required="false" অ্যাট্রিবিউট অ্যাপ্লিকেশনটিকে সেই হার্ডওয়্যার ছাড়া ডিভাইসে ইনস্টল করার অনুমতি দেয় — কোডে উপলব্ধতা পরীক্ষা করা হয়। যদি required="true" হয়, Google Play অ্যাপ্লিকেশনটি ফিল্টার করে, এটি অনুপযুক্ত ডিভাইসের জন্য অনুপলব্ধ করে।

সমস্ত হার্ডওয়্যার বৈশিষ্ট্যের জন্য required="false" সেট করার এবং PackageManager.hasSystemFeature()-এর মাধ্যমে প্রোগ্রামেটিকভাবে উপলব্ধতা পরীক্ষা করার পরামর্শ দেওয়া হয়। এটি আপনার অ্যাপ্লিকেশনের দর্শক প্রসারিত করে। একমাত্র ব্যতিক্রম যদি বৈশিষ্ট্যটি অ্যাপ্লিকেশনের অপারেশনের জন্য গুরুত্বপূর্ণ হয় (GPS ছাড়া ট্যাক্সি অর্ডারিং অ্যাপ্লিকেশনের কোনও মানে নেই)।

সেরা অভ্যাস এবং ত্রুটি

অনুমতির সঠিক ব্যবস্থাপনা Android অ্যাপ্লিকেশন মানের একটি মূল দিক। আসুন প্রধান সুপারিশ এবং সাধারণ ত্রুটিগুলি পর্যালোচনা করি।

অনুরোধ করা অনুমতি ন্যূনতম করুন

শুধুমাত্র সেই অনুমতিগুলি অনুরোধ করুন যা অ্যাপ্লিকেশন পরিচালনার জন্য সত্যিই প্রয়োজনীয়। প্রতিটি অতিরিক্ত অনুমতি ইনস্টল রূপান্তর হ্রাস করে এবং অস্বীকৃতি হার বাড়ায়। Google Play Console দেখায় কতজন ব্যবহারকারী অনুমতি সেটের কারণে ইনস্টলেশন প্রত্যাখ্যান করেছেন। AppBrain (2024) অনুসারে, 10+ dangerous অনুমতি সহ অ্যাপ্লিকেশনগুলির 35% কম ইনস্টল রয়েছে।

নিয়মিত আপনার অনুমতি তালিকা পর্যালোচনা করুন। অব্যবহৃত অনুমতিগুলি সরান, বিশেষ করে নতুন Android সংস্করণে মাইগ্রেট করার সময় যেখানে কিছু অনুমতি ঐচ্ছিক হয়ে যায়। উদাহরণস্বরূপ, Android 13+ এ ফটো পিকার (ActivityResultContracts.PickVisualMedia) দিয়ে, মিডিয়া লাইব্রেরি অ্যাক্সেস বিপজ্জনক READ_MEDIA_IMAGES অনুমতি ছাড়াই পাওয়া যেতে পারে।

অনুরোধের আগে যুক্তি দেখান

একটি বিপজ্জনক অনুমতি অনুরোধ করার আগে, ব্যবহারকারীকে একটি স্ক্রিন দেখান যা ব্যাখ্যা করে কেন এই অনুমতি প্রয়োজন এবং এটি কী মূল্য প্রদান করে। Material Design একটি আইকন, সংক্ষিপ্ত পাঠ এবং «চালিয়ে যান» বোতাম সহ বটম শীট বা ডায়ালগ ব্যবহার করার পরামর্শ দেয়। যুক্তি সরাসরি অনুরোধের তুলনায় সম্মতি 20-30% বাড়ায়।

launch() কল করার আগে shouldShowRequestPermissionRationale() পরীক্ষা করুন। যদি true হয়, যুক্তি দেখান। যদি false হয়, হয় অনুমতি ইতিমধ্যে দেওয়া হয়েছে বা ব্যবহারকারী স্থায়ীভাবে এটি অস্বীকার করেছেন (আবার কখনও জিজ্ঞাসা করবেন না)। শেষের ক্ষেত্রে, অনুরোধ পুনরাবৃত্তি করার পরিবর্তে «সেটিংস খুলুন» বোতাম দেখান।

সমস্ত অনুমতি পরিস্থিতি পরীক্ষা করুন

সমস্ত সম্ভাব্য পরিস্থিতি পরীক্ষা করুন: অনুমতি প্রদান, অস্বীকৃতি, স্থায়ী অস্বীকৃতি, সেটিংসে অনুমতি প্রত্যাহার, অনুমতি রিসেট (Android 11+ অটো-রিসেট)। প্রতিটি পরিস্থিতি ক্র্যাশ বা ডেটা ক্ষতি ছাড়াই পরিচালনা করা উচিত। Android Testing Guide পরীক্ষা স্বয়ংক্রিয় করতে TestPermission লাইব্রেরি ব্যবহার করার পরামর্শ দেয়।

সেই পরিস্থিতিতে বিশেষ মনোযোগ দিন যখন ব্যবহারকারী অ্যাপ্লিকেশন চলাকালীন অনুমতি প্রত্যাহার করেন (অ্যাপ্লিকেশন ছোট → সেটিংস → প্রত্যাহার)। অ্যাপ্লিকেশনে ফিরে আসার পরে, onResume()-এ সমস্ত অনুমতি পরীক্ষা করুন। অনুমতি স্থিতি ক্যাশ করার উপর নির্ভর করবেন না — ব্যবহারকারী যে কোনও সময় এটি পরিবর্তন করতে পারেন।

সাধারণ ত্রুটি

• প্রথমে checkSelfPermission পরীক্ষা না করে অনুমতি অনুরোধ — অপ্রয়োজনীয় ডায়ালগ ট্রিগার করে
• shouldShowRequestPermissionRationale উপেক্ষা করা — প্রথম অস্বীকৃতির পরে UX খারাপ করে
• প্রসঙ্গ ছাড়া অনুমতি অনুরোধ (শুধু «অ্যাক্সেস অনুমতি দিন?») — সম্মতি হ্রাস করে
• Android 10+ এ maxSdkVersion ছাড়া WRITE_EXTERNAL_STORAGE ব্যবহার — অপ্রয়োজনীয় অনুরোধ
• onResume-এ অনুমতি পরীক্ষার অভাব — সেটিংসে অনুমতি প্রত্যাহার মিস করা