Android-এ Permission Group — এটি কী, অনুমতি গ্রুপ এবং কাজের নীতি

Android-এ Permission Group কী

Permission Group হল Android-এর একটি সিস্টেম প্রক্রিয়া যা তাদের কার্যকরী উদ্দেশ্যের ভিত্তিতে একাধিক বিপজ্জনক অনুমতিকে একটি গ্রুপে একত্রিত করে। প্রতিটি গ্রুপের একটি স্ট্রিং আইডেন্টিফায়ার থাকে, যেমন android.permission-group.CAMERA বা android.permission-group.LOCATION। একটি গ্রুপের মধ্যে সমস্ত অনুমতি যৌক্তিকভাবে সম্পর্কিত এবং ডিভাইসের সম্পর্কিত ফাংশনগুলিতে অ্যাক্সেস প্রদান করে।

Android 6.0 Marshmallow-এ রানটাইম অনুরোধ মডেলের সাথে অনুমতি গ্রুপগুলি উপস্থিত হয়েছিল। তাদের মূল উদ্দেশ্য হল ব্যবহারকারীর সাথে মিথস্ক্রিয়া সহজ করা: প্রতিটি পৃথক অনুমতির জন্য ডায়ালগের সিরিজের পরিবর্তে, সিস্টেম প্রতি গ্রুপে একটি ডায়ালগ দেখায়। যদি ব্যবহারকারী একটি গ্রুপ থেকে একটি অনুমতি মঞ্জুর করে, বাকিগুলি স্বয়ংক্রিয়ভাবে অনুমোদিত বলে বিবেচিত হয়। Android UX Research (2015) অনুসারে, এটি প্রথম লঞ্চে অস্বীকৃতির সংখ্যা 20 শতাংশ হ্রাস করেছে।

এটি বোঝা গুরুত্বপূর্ণ যে ডেভেলপার নিজের Permission Group তৈরি করতে পারে না। গ্রুপগুলি অপারেটিং সিস্টেম স্তরে পূর্বনির্ধারিত এবং প্রতিটি ডিভাইসে permissions.xml ফাইলে বর্ণিত। অ্যাপ্লিকেশন শুধুমাত্র uses-permission ঘোষণা করে, এবং সিস্টেম স্বয়ংক্রিয়ভাবে protectionLevel এবং AOSP-তে শ্রেণীবিভাগের ভিত্তিতে অনুমতিকে তার গ্রুপে ম্যাপ করে।

সিস্টেম কীভাবে গ্রুপ নির্ধারণ করে

একটি অনুমতিকে গ্রুপে ম্যাপিং সিস্টেম অনুমতি সংজ্ঞায় permissionGroup অ্যাট্রিবিউটের মাধ্যমে ঘটে। উদাহরণস্বরূপ, CAMERA permissionGroup="android.permission-group.CAMERA" দিয়ে ঘোষিত, ACCESS_FINE_LOCATION permissionGroup="android.permission-group.LOCATION" দিয়ে। এই ম্যাপিং Android Open Source Project কোডে হার্ডকোডেড এবং সমস্ত প্রত্যয়িত ডিভাইসে অভিন্ন।

Permission Group কীভাবে কাজ করে

গ্রুপ প্রক্রিয়া “প্রতি গ্রুপে একটি ডায়ালগ” নীতিতে কাজ করে। যখন একটি অ্যাপ্লিকেশন প্রথমবার কোনো বিপজ্জনক অনুমতি অনুরোধ করে, সিস্টেম তার Permission Group পরীক্ষা করে। যদি এই গ্রুপ থেকে এখনও কোনো অনুমতি মঞ্জুর না করা হয় — একটি ডায়ালগ দেখানো হয়। সম্মতির পরে, সিস্টেম পুরো গ্রুপটিকে মঞ্জুরকৃত হিসাবে চিহ্নিত করে, এবং একই গ্রুপ থেকে অন্যান্য অনুমতির পরবর্তী অনুরোধগুলি UI ছাড়াই পূর্ণ হয়।

সরলীকৃত অ্যালগরিদমটি এইরকম দেখায়:

• অ্যাপ্লিকেশন ACCESS_FINE_LOCATION-এর জন্য requestPermissions কল করে
• সিস্টেম গ্রুপ নির্ধারণ করে — android.permission-group.LOCATION
• পরীক্ষা করে যে LOCATION গ্রুপ পূর্বে মঞ্জুর হয়েছে কিনা
• যদি না — গ্রুপের নাম এবং অন্তর্ভুক্ত অনুমতির তালিকা সহ একটি ডায়ালগ দেখায়
• Allow-এর পরে — পুরো LOCATION গ্রুপটি মঞ্জুর বলে বিবেচিত হয়
• ACCESS_COARSE_LOCATION এখন অতিরিক্ত অনুরোধ ছাড়াই উপলব্ধ

এই প্রক্রিয়া শুধুমাত্র বিপজ্জনক অনুমতির ক্ষেত্রে প্রযোজ্য। সাধারণ অনুমতির গ্রুপ নেই এবং তারা এই যুক্তিতে অংশগ্রহণ করে না। বিশেষাধিকারপ্রাপ্ত এবং স্বাক্ষরিত অনুমতিগুলিও গ্রুপ করা হয় না — তাদের অ্যাক্সেস নিয়ন্ত্রণের পৃথক ব্যবস্থা রয়েছে।

গ্রুপ যুক্তির সীমাবদ্ধতা

গ্রুপগুলি “উল্টো দিকে” কাজ করে না: সেটিংসের মাধ্যমে গ্রুপ থেকে একটি অনুমতি প্রত্যাহার করলে শুধুমাত্র সেই অনুমতিটি প্রত্যাহার হয়, অন্যগুলি প্রভাবিত হয় না। এছাড়াও, যদি ব্যবহারকারী একটি গ্রুপের ডায়ালগ প্রত্যাখ্যান করে, এটি অন্য গ্রুপগুলিকে ব্লক করে না — একটি ভিন্ন গ্রুপ থেকে প্রতিটি নতুন অনুমতি তার নিজস্ব ডায়ালগ দেখাবে। Permission Group শুধুমাত্র অনুরোধ UX-কে প্রভাবিত করে, নিরাপত্তা মডেলকে নয়।

Android-এ Permission Group-এর তালিকা

Android নিম্নলিখিত সিস্টেম Permission Group-গুলিকে বিপজ্জনক অনুমতির জন্য সংজ্ঞায়িত করে। প্রতিটি গ্রুপে এক বা একাধিক অনুমতি অন্তর্ভুক্ত থাকে যা একটি সাধারণ কার্যকরী উদ্দেশ্যে একত্রিত।

নতুন সংস্করণে পরিবর্তন

Android 13 (API 33)-এ, একটি নতুন গ্রুপ NEARBY_DEVICES উপস্থিত হয়েছে, যা BLUETOOTH_SCAN, BLUETOOTH_CONNECT এবং BLUETOOTH_ADVERTISE-কে একত্রিত করে। এছাড়াও, STORAGE গ্রুপটি আংশিকভাবে মিডিয়া অনুমতি READ_MEDIA_IMAGES, READ_MEDIA_VIDEO এবং READ_MEDIA_AUDIO দ্বারা প্রতিস্থাপিত হয়েছে, যা STORAGE-এর অংশ নয় বরং গ্রুপিং ছাড়াই স্বাধীন বিপজ্জনক অনুমতি।

কাস্টম অনুমতি গ্রুপ

ডেভেলপাররা ম্যানিফেস্টে permissionGroup অ্যাট্রিবিউটের মাধ্যমে কাস্টম Permission Group সহ নিজস্ব অনুমতি ঘোষণা করতে পারেন। তবে, এটি শুধুমাত্র একই অ্যাপ্লিকেশনের কাস্টম অনুমতির জন্য কাজ করে এবং সিস্টেম UI ডায়ালগগুলিকে প্রভাবিত করে না। বাস্তবে, কাস্টম Permission Group খুব কমই ব্যবহৃত হয় — একই স্ট্যাকের অ্যাপ্লিকেশনগুলির মধ্যে মিথস্ক্রিয়ার জন্য।

Permission Group এবং UX

Permission Group-এর প্রভাব ব্যবহারকারীর অভিজ্ঞতার উপর উল্লেখযোগ্য। গ্রুপিংয়ের কারণে, ব্যবহারকারী বিভিন্ন অনুমতির জন্য 8টি পৃথক ডায়ালগ দেখেন না, বরং কয়েকটি গ্রুপ ডায়ালগ দেখেন। এটি জ্ঞানীয় বোঝা হ্রাস করে এবং ব্যবহারকারীর তার উদ্দেশ্য না বুঝে একটি গুরুত্বপূর্ণ অনুমতি অস্বীকার করার সম্ভাবনা হ্রাস করে।

UX গবেষণা দেখায় যে গ্রুপ ডায়ালগগুলি ব্যবহারকারীদের দ্বারা আরও স্বচ্ছ বলে বিবেচিত হয়। যখন একটি অ্যাপ্লিকেশন “ক্যামেরায় অ্যাক্সেসের অনুমতি” অনুরোধ করে, ব্যবহারকারী প্রসঙ্গটি বোঝেন। যদি প্রতিটি অনুমতি পৃথকভাবে অনুরোধ করা হত — CAMERA, CAMERA2, FLASHLIGHT — এটি অপ্রয়োজনীয়তার ছাপ তৈরি করত। Permission Group এই বিশদটি বিমূর্ত করে।

সেরা অনুশীলন হল একবারে শুধুমাত্র একটি গ্রুপ থেকে অনুমতি অনুরোধ করা। যদি একটি অ্যাপ্লিকেশনের ক্যামেরা এবং অবস্থান উভয়ের প্রয়োজন হয়, তবে সেগুলি একটি requestPermissions কলের মাধ্যমে অনুরোধ করবেন না। প্রথমে একটি গ্রুপ অনুরোধ করুন ব্যাখ্যা করার পরে কেন এটি প্রয়োজন, তারপর দ্বিতীয়টি। এটি ব্যবহারকারীকে নিয়ন্ত্রণ এবং প্রতিটি বৈশিষ্ট্যের ক্রমিক বোঝাপড়া দেয়।

Permission Group বনাম ProtectionLevel

Permission Group এবং ProtectionLevel Android অনুমতি সিস্টেমের দুটি ভিন্ন মাত্রা। ProtectionLevel নির্ধারণ করে কীভাবে একটি অনুমতি মঞ্জুর করা হয় (normal, dangerous, signature, privileged), যখন Permission Group UI প্রদর্শনের জন্য একটি বিভাগ। এগুলি স্বাধীন, কিন্তু বাস্তবে dangerous + permission group সংমিশ্রণটি সবচেয়ে সাধারণ।

একই ProtectionLevel-এর অনুমতিগুলি ভিন্ন গ্রুপের অন্তর্ভুক্ত হতে পারে। উদাহরণস্বরূপ, ACCESS_FINE_LOCATION এবং CAMERA উভয়েরই protectionLevel dangerous কিন্তু তারা ভিন্ন গ্রুপ — LOCATION এবং CAMERA-এর অন্তর্ভুক্ত। এবং বিপরীতে, একই নামের অনুমতিগুলি সর্বদা একই গ্রুপের অন্তর্ভুক্ত: ACCESS_FINE_LOCATION এবং ACCESS_COARSE_LOCATION উভয়ই LOCATION-এ।

উচ্চ স্তরের সুরক্ষা স্তর — signature এবং privileged — UI-র জন্য Permission Group ব্যবহার করে না। তাদের মঞ্জুরি সিস্টেম স্তরে নিয়ন্ত্রিত হয়: signature সিস্টেমের মতো একই সার্টিফিকেট দিয়ে স্বাক্ষরিত অ্যাপ্লিকেশনগুলিকে মঞ্জুর করা হয়, এবং privileged সিস্টেম ইমেজের অ্যাপ্লিকেশনগুলিকে। এই ধরনের অনুমতির জন্য গ্রুপ বিদ্যমান কিন্তু UX ডায়ালগগুলিকে প্রভাবিত করে না কারণ এই ডায়ালগগুলি কেবল দেখা যায় না।

কোডে Permission Group পরীক্ষা

ডেভেলপার PackageManager-এর মাধ্যমে যেকোনো অনুমতির Permission Group প্রোগ্রামেটিকভাবে নির্ধারণ করতে পারে। getPermissionInfo পদ্ধতি PermissionInfo ফেরত দেয় যার group ফিল্ডে গ্রুপের স্ট্রিং আইডেন্টিফায়ার থাকে। এটি লগিং, বিশ্লেষণ এবং কাস্টম অনুমতি UI স্ক্রিনের জন্য উপযোগী।

fun getPermissionGroupName(
    permission: String
): String? {
    return try {
        val pm = packageManager
        val info = pm.getPermissionInfo(
            permission,
            PackageManager.GET_META_DATA
        )
        info.group
    } catch (e: NameNotFoundException) {
        null
    }
}

fun getPermissionsByGroup(
    group: String
): List<String> {
    val pm = packageManager
    val perms = pm.queryPermissionsByGroup(
        group,
        PackageManager.GET_META_DATA
    )
    return perms.map { it.name }
}

DI এবং আর্কিটেকচারে ব্যবহার

Permission Group-এর জ্ঞান অনুরোধ আর্কিটেকচার তৈরি করতে সহায়তা করে। আপনি PermissionGroupProvider নামে একটি অ্যাবস্ট্রাকশন তৈরি করতে পারেন যা একটি নির্দিষ্ট গ্রুপের জন্য অনুমতির তালিকা ফেরত দেয়। এটি পরীক্ষা সহজ করে: ইউনিট পরীক্ষায়, প্রদানকারী PackageManager কল না করেই নকল ডেটা ফেরত দেয়। ইন্সট্রুমেন্টেশন পরীক্ষায়, এটি সিস্টেম থেকে বাস্তব গ্রুপ ফেরত দেয়।

DI-তে PermissionGroupProvider

Dagger Hilt বা Koin-এর মাধ্যমে PermissionGroupProvider-কে সংহত করা অনুমতি-থেকে-গ্রুপ ম্যাপিংয়ের কেন্দ্রীভূত ব্যবস্থাপনার অনুমতি দেয়। প্রদানকারীতে, আপনি প্রতিটি অনুরোধে পুনরাবৃত্ত সিস্টেম কল এড়াতে PackageManager.queryPermissionsByGroup-এর ফলাফল ক্যাশে করতে পারেন। এটি সেটিংস স্ক্রিনের জন্য বিশেষভাবে গুরুত্বপূর্ণ যেখানে অনুমতির সম্পূর্ণ তালিকা এবং তাদের অবস্থা প্রদর্শিত হয়।

লগিং এবং বিশ্লেষণ

অস্বীকৃতি সম্পর্কে বিশ্লেষণ সংগ্রহ করার সময়, শুধুমাত্র অনুমতির নাম নয় বরং এর Permission Group-ও লগ করা উপযোগী। এটি সনাক্ত করতে সহায়তা করে যে কোন কার্যকরী ক্ষেত্রগুলি সবচেয়ে বেশি অস্বীকৃতি ঘটায়। উদাহরণস্বরূপ, LOCATION গ্রুপ ঐতিহ্যগতভাবে সর্বোচ্চ অস্বীকৃতি হার রাখে — Google Play Console-এর পরিসংখ্যান অনুসারে প্রায় 40 শতাংশ।

গ্রুপ অনুসারে বিশ্লেষণ পণ্যের সিদ্ধান্ত নিতে সহায়তা করে: যদি CONTACTS গ্রুপের উচ্চ অস্বীকৃতি হার থাকে, তবে অনুরোধের সময় পুনর্বিবেচনা করা বা যুক্তি ডায়ালগ যোগ করা প্রয়োজন হতে পারে। বিশ্লেষণের জন্য গ্রুপ-ভিত্তিক দৃষ্টিভঙ্গি পৃথক অনুমতির বিশ্লেষণের চেয়ে আরও সম্পূর্ণ চিত্র প্রদান করে, কারণ সম্পূর্ণ গ্রুপ জুড়ে অস্বীকৃতির সংখ্যা একটি কার্যকরী ক্ষেত্রের প্রতি ব্যবহারকারীদের সাধারণ মনোভাব প্রতিফলিত করে।