রানটাইম অনুমতি অনুরোধ

প্রতিটি অ্যান্ড্রয়েড অ্যাপ একটি সীমিত-অ্যাক্সেস স্যান্ডবক্সে চলে। যদি আপনার অ্যাপের নিজের স্যান্ডবক্সের বাইরের কোনো রিসোর্স বা তথ্য ব্যবহার করার প্রয়োজন হয়, তবে আপনি একটি রানটাইম পারমিশন ঘোষণা করতে পারেন এবং এই অ্যাক্সেস প্রদানের জন্য একটি পারমিশন রিকোয়েস্ট সেট আপ করতে পারেন। এই ধাপগুলো পারমিশন ব্যবহারের ওয়ার্কফ্লো- এর অংশ।

আপনি যদি কোনো বিপজ্জনক পারমিশন ঘোষণা করেন এবং আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ৬.০ (এপিআই লেভেল ২৩) বা তার উচ্চতর সংস্করণের কোনো ডিভাইসে ইনস্টল করা থাকে, তাহলে আপনাকে অবশ্যই এই গাইডের ধাপগুলো অনুসরণ করে রানটাইমে সেই বিপজ্জনক পারমিশনগুলোর জন্য অনুরোধ করতে হবে।

যদি আপনি কোনো বিপজ্জনক পারমিশন ঘোষণা না করেন, অথবা আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ৫.১ (এপিআই লেভেল ২২) বা তার নিম্ন সংস্করণের কোনো ডিভাইসে ইনস্টল করা থাকে, তাহলে পারমিশনগুলো স্বয়ংক্রিয়ভাবে মঞ্জুর হয়ে যাবে এবং এই পৃষ্ঠার বাকি ধাপগুলোর কোনোটিই আপনাকে সম্পন্ন করতে হবে না।

মৌলিক নীতি

রানটাইমে অনুমতি চাওয়ার মৌলিক নীতিগুলো নিম্নরূপ:

• ব্যবহারকারী যখন প্রয়োজনীয় ফিচারটি ব্যবহার করা শুরু করে, তখন প্রাসঙ্গিকভাবে অনুমতির জন্য জিজ্ঞাসা করুন।
• ব্যবহারকারীকে ব্লক করবেন না। শিক্ষামূলক UI ফ্লো বাতিল করার বিকল্প সর্বদা প্রদান করুন, যেমন এমন একটি ফ্লো যা অনুমতি চাওয়ার কারণ ব্যাখ্যা করে।
• যদি ব্যবহারকারী কোনো ফিচারের জন্য প্রয়োজনীয় অনুমতি প্রত্যাখ্যান বা প্রত্যাহার করে নেন, তাহলে আপনার অ্যাপটিকে সাবলীলভাবে ডাউনগ্রেড করুন, যাতে ব্যবহারকারী অ্যাপটি ব্যবহার করা চালিয়ে যেতে পারেন; এর জন্য সম্ভবত অনুমতি প্রয়োজন এমন ফিচারটি নিষ্ক্রিয় করে দিন।
• সিস্টেমের কোনো আচরণ সম্পর্কে অনুমান করবেন না। উদাহরণস্বরূপ, ধরে নেবেন না যে পারমিশনগুলো একই পারমিশন গ্রুপে থাকে। একটি পারমিশন গ্রুপ কেবল সিস্টেমকে ব্যবহারকারীর কাছে প্রদর্শিত সিস্টেম ডায়ালগের সংখ্যা কমাতে সাহায্য করে, যখন কোনো অ্যাপ ঘনিষ্ঠভাবে সম্পর্কিত পারমিশনের জন্য অনুরোধ করে।

অনুমতি অনুরোধ করার কর্মপ্রবাহ

আপনার অ্যাপে রানটাইম পারমিশন ঘোষণা ও অনুরোধ করার আগে, মূল্যায়ন করুন যে আপনার অ্যাপের সত্যিই তা করার প্রয়োজন আছে কিনা । কোনো পারমিশন ঘোষণা না করেই আপনি আপনার অ্যাপে ছবি তোলা, মিডিয়া প্লেব্যাক থামানো এবং প্রাসঙ্গিক বিজ্ঞাপন দেখানোর মতো অনেক কাজ সম্পন্ন করতে পারেন।

যদি আপনি এই সিদ্ধান্তে আসেন যে আপনার অ্যাপের রানটাইম পারমিশন ঘোষণা ও অনুরোধ করার প্রয়োজন আছে, তাহলে এই ধাপগুলো সম্পন্ন করুন:

1. আপনার অ্যাপের ম্যানিফেস্ট ফাইলে, আপনার অ্যাপের প্রয়োজন হতে পারে এমন অনুমতিগুলো ঘোষণা করুন ।
2. আপনার অ্যাপের ইউজার এক্সপেরিয়েন্স (UX) এমনভাবে ডিজাইন করুন , যাতে অ্যাপের নির্দিষ্ট অ্যাকশনগুলো নির্দিষ্ট রানটাইম পারমিশনের সাথে যুক্ত থাকে। ব্যবহারকারীদের জানিয়ে দিন যে, কোন কোন অ্যাকশনের জন্য আপনার অ্যাপকে তাদের ব্যক্তিগত ডেটা অ্যাক্সেস করার অনুমতি দিতে হতে পারে।
3. আপনার অ্যাপে ব্যবহারকারী যখন এমন কোনো কাজ বা অ্যাকশন শুরু করবে যার জন্য নির্দিষ্ট ব্যক্তিগত ডেটা অ্যাক্সেস করার প্রয়োজন, তখন পর্যন্ত অপেক্ষা করুন । সেই সময়ে, আপনার অ্যাপ সেই ডেটা অ্যাক্সেস করার জন্য প্রয়োজনীয় রানটাইম পারমিশনের জন্য অনুরোধ করতে পারে।

4. ব্যবহারকারী ইতিমধ্যে অনুমতি দিয়েছেন কিনা তা যাচাই করুন ।

   আপনার অ্যাপের জন্য রানটাইম পারমিশন প্রয়োজন। যদি প্রয়োজন হয়, আপনার অ্যাপ ব্যবহারকারীর ব্যক্তিগত তথ্য অ্যাক্সেস করতে পারবে। যদি প্রয়োজন না হয়, পরবর্তী ধাপে যান।

   যখনই আপনি এমন কোনো কাজ করবেন যার জন্য অনুমতির প্রয়োজন, তখন আপনাকে অবশ্যই যাচাই করে দেখতে হবে যে আপনার সেই অনুমতি আছে কি না।

5. আপনার অ্যাপের কোনো নির্দিষ্ট রানটাইম পারমিশন দেওয়ার প্রয়োজন কেন, তার কারণ ব্যাখ্যা করে ব্যবহারকারীকে কোনো যুক্তি দেখানো উচিত কিনা, তা যাচাই করুন । যদি সিস্টেম নির্ধারণ করে যে আপনার অ্যাপের কোনো যুক্তি দেখানো উচিত নয়, তাহলে কোনো UI এলিমেন্ট না দেখিয়ে সরাসরি পরবর্তী ধাপে এগিয়ে যান।

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

6. ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করার জন্য আপনার অ্যাপের প্রয়োজনীয় রানটাইম পারমিশনের অনুরোধ করুন । সিস্টেমটি একটি রানটাইম পারমিশন প্রম্পট প্রদর্শন করে, যেমনটি পারমিশন ওভারভিউ পৃষ্ঠায় দেখানো হয়।

7. ব্যবহারকারীর প্রতিক্রিয়া যাচাই করুন —তিনি রানটাইম পারমিশনটি মঞ্জুর করেছেন নাকি প্রত্যাখ্যান করেছেন।

8. যদি ব্যবহারকারী আপনার অ্যাপকে অনুমতি দিয়ে থাকেন, তাহলে আপনি ব্যবহারকারীর ব্যক্তিগত তথ্য অ্যাক্সেস করতে পারবেন। এর পরিবর্তে, যদি ব্যবহারকারী অনুমতিটি প্রত্যাখ্যান করে থাকেন, তবে আপনার অ্যাপের অভিজ্ঞতাকে এমনভাবে পরিবর্তন করুন যাতে এটি সেই অনুমতি দ্বারা সুরক্ষিত তথ্য ছাড়াই ব্যবহারকারীকে কার্যকারিতা প্রদান করে।

চিত্র ১-এ এই প্রক্রিয়ার সাথে সংশ্লিষ্ট কার্যপ্রবাহ এবং সিদ্ধান্তসমূহ তুলে ধরা হয়েছে:

আপনার অ্যাপকে ইতিমধ্যে অনুমতি দেওয়া হয়েছে কিনা তা নির্ধারণ করুন।

ব্যবহারকারী আপনার অ্যাপকে কোনো নির্দিষ্ট অনুমতি আগে থেকেই দিয়েছেন কিনা তা পরীক্ষা করতে, সেই অনুমতিটি ContextCompat.checkSelfPermission() মেথডে পাস করুন। আপনার অ্যাপের অনুমতিটি আছে কিনা তার উপর নির্ভর করে এই মেথডটি PERMISSION_GRANTED অথবা PERMISSION_DENIED রিটার্ন করে।

আপনার অ্যাপের কেন অনুমতি প্রয়োজন তা ব্যাখ্যা করুন।

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

গবেষণায় দেখা গেছে যে, ব্যবহারকারীরা অনুমতির অনুরোধের বিষয়ে অনেক বেশি স্বাচ্ছন্দ্য বোধ করেন যদি তারা জানতে পারেন যে অ্যাপটির কেন সেই অনুমতি প্রয়োজন, যেমন—অনুমতিটি অ্যাপটির কোনো মূল বৈশিষ্ট্য সমর্থন করার জন্য নাকি বিজ্ঞাপনের জন্য প্রয়োজন। ফলস্বরূপ, আপনি যদি কোনো একটি পারমিশন গ্রুপের অধীনে থাকা এপিআই কলগুলোর একটি ক্ষুদ্র অংশই কেবল ব্যবহার করেন, তবে স্পষ্টভাবে উল্লেখ করুন যে আপনি সেই পারমিশনগুলোর মধ্যে কোনটি এবং কেন ব্যবহার করছেন। উদাহরণস্বরূপ, আপনি যদি কেবল সাধারণ অবস্থান (coarse location) ব্যবহার করেন, তবে আপনার অ্যাপের বিবরণে বা আপনার অ্যাপ সম্পর্কিত সহায়ক আর্টিকেলগুলোতে ব্যবহারকারীকে এই বিষয়টি জানিয়ে দিন।

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

কোনো ফিচার কাজ করানোর জন্য যদি অনুমতির অনুরোধ করার প্রয়োজন হয়, কিন্তু ব্যবহারকারীর কাছে কারণটি স্পষ্ট না থাকে, তাহলে সংবেদনশীল অনুমতিগুলো কেন প্রয়োজন তা ব্যাখ্যা করার একটি উপায় খুঁজে বের করুন।

যদি ContextCompat.checkSelfPermission() মেথডটি PERMISSION_DENIED রিটার্ন করে, তাহলে shouldShowRequestPermissionRationale() কল করুন। যদি এই মেথডটি true রিটার্ন করে, তাহলে ব্যবহারকারীকে একটি শিক্ষামূলক UI দেখান। এই UI-তে বর্ণনা করুন, ব্যবহারকারী যে ফিচারটি চালু করতে চান, সেটির জন্য কেন একটি নির্দিষ্ট পারমিশন প্রয়োজন।

এছাড়াও, যদি আপনার অ্যাপ অবস্থান, মাইক্রোফোন বা ক্যামেরা সম্পর্কিত কোনো অনুমতি চায়, তাহলে আপনার অ্যাপের কেন এই তথ্যে প্রবেশাধিকার প্রয়োজন, তা ব্যাখ্যা করার কথা বিবেচনা করুন।

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

ব্যবহারকারী কোনো শিক্ষামূলক UI দেখার পর, অথবা shouldShowRequestPermissionRationale() ফাংশনের রিটার্ন ভ্যালু থেকে যদি বোঝা যায় যে আপনার কোনো শিক্ষামূলক UI দেখানোর প্রয়োজন নেই, তাহলে অনুমতির জন্য অনুরোধ করুন। ব্যবহারকারীরা একটি সিস্টেম পারমিশন ডায়ালগ দেখতে পান, যেখানে তারা আপনার অ্যাপকে কোনো নির্দিষ্ট অনুমতি দেবেন কিনা তা বেছে নিতে পারেন।

এটি করার জন্য, একটি AndroidX লাইব্রেরিতে অন্তর্ভুক্ত RequestPermission কন্ট্রাক্টটি ব্যবহার করুন, যেখানে আপনি সিস্টেমকে আপনার হয়ে পারমিশন রিকোয়েস্ট কোডটি পরিচালনা করার অনুমতি দেন । যেহেতু RequestPermission কন্ট্রাক্ট ব্যবহার করলে আপনার লজিক সহজ হয়ে যায়, তাই সম্ভব হলে এটিই প্রস্তাবিত সমাধান। তবে, প্রয়োজনে আপনি পারমিশন রিকোয়েস্টের অংশ হিসেবে নিজেও একটি রিকোয়েস্ট কোড পরিচালনা করতে পারেন এবং এই রিকোয়েস্ট কোডটি আপনার পারমিশন কলব্যাক লজিকে অন্তর্ভুক্ত করতে পারেন।

সিস্টেমকে অনুমতি অনুরোধ কোড পরিচালনা করার অনুমতি দিন।

অনুমতি অনুরোধের সাথে যুক্ত অনুরোধ কোডটি সিস্টেমকে পরিচালনা করার সুযোগ দিতে, আপনার মডিউলের build.gradle ফাইলে নিম্নলিখিত লাইব্রেরিগুলির উপর নির্ভরতা যোগ করুন:

• androidx.activity , সংস্করণ 1.2.0 বা তার পরবর্তী
• androidx.fragment , সংস্করণ 1.3.0 বা তার পরবর্তী

এরপর আপনি নিচের ক্লাসগুলোর মধ্যে যেকোনো একটি ব্যবহার করতে পারেন:

• একটিমাত্র অনুমতির জন্য অনুরোধ করতে RequestPermission ব্যবহার করুন।
• একই সময়ে একাধিক অনুমতির অনুরোধ করতে, RequestMultiplePermissions ব্যবহার করুন।

নিম্নলিখিত ধাপগুলিতে RequestPermission কন্ট্রাক্টটি কীভাবে ব্যবহার করতে হয় তা দেখানো হয়েছে। RequestMultiplePermissions কন্ট্রাক্টটির ক্ষেত্রেও প্রক্রিয়াটি প্রায় একই।

1. আপনার অ্যাক্টিভিটি বা ফ্র্যাগমেন্টের ইনিশিয়ালাইজেশন লজিকে, registerForActivityResult() কল করার সময় ActivityResultCallback এর একটি ইমপ্লিমেন্টেশন পাস করুন। ActivityResultCallback নির্ধারণ করে যে, অনুমতির অনুরোধের জবাবে ব্যবহারকারীর প্রতিক্রিয়া আপনার অ্যাপ কীভাবে পরিচালনা করবে।

   registerForActivityResult() এর রিটার্ন ভ্যালুর একটি রেফারেন্স রাখুন, যা ActivityResultLauncher টাইপের।

2. প্রয়োজনে সিস্টেম পারমিশন ডায়ালগটি প্রদর্শন করতে, পূর্ববর্তী ধাপে আপনার সংরক্ষণ করা ActivityResultLauncher এর ইনস্ট্যান্সটিতে launch() মেথডটি কল করুন।

   launch() কল করার পর, সিস্টেম পারমিশন ডায়ালগটি প্রদর্শিত হয়। যখন ব্যবহারকারী কোনো পছন্দ নির্বাচন করেন, তখন সিস্টেম অ্যাসিঙ্ক্রোনাসভাবে আপনার ActivityResultCallback এর ইমপ্লিমেন্টেশনটি কল করে, যা আপনি পূর্ববর্তী ধাপে সংজ্ঞায়িত করেছিলেন।

   দ্রষ্টব্য: আপনি launch() কল করলে যে ডায়ালগটি প্রদর্শিত হয়, আপনার অ্যাপ সেটি কাস্টমাইজ করতে পারে না । ব্যবহারকারীকে আরও তথ্য বা প্রেক্ষাপট দেওয়ার জন্য, আপনার অ্যাপের UI পরিবর্তন করুন, যাতে ব্যবহারকারীরা সহজে বুঝতে পারে যে আপনার অ্যাপের কোনো একটি ফিচারের জন্য কেন একটি নির্দিষ্ট পারমিশন প্রয়োজন। উদাহরণস্বরূপ, আপনি ফিচারটি চালু করার বাটনের লেখাটি পরিবর্তন করতে পারেন।

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

নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে পারমিশন রেসপন্সটি হ্যান্ডেল করতে হয়:

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

এবং এই কোড স্নিপেটটি কোনো অনুমতি যাচাই করার এবং প্রয়োজনে ব্যবহারকারীর কাছ থেকে অনুমতি চাওয়ার প্রস্তাবিত প্রক্রিয়াটি প্রদর্শন করে:

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

অনুমতি অনুরোধ কোডটি নিজেই পরিচালনা করুন

সিস্টেমকে অনুমতি অনুরোধ কোড পরিচালনা করতে দেওয়ার বিকল্প হিসেবে, আপনি নিজেই অনুমতি অনুরোধ কোডটি পরিচালনা করতে পারেন। এটি করার জন্য, requestPermissions() কল করার সময় অনুরোধ কোডটি অন্তর্ভুক্ত করুন।

নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে একটি রিকোয়েস্ট কোড ব্যবহার করে অনুমতির জন্য অনুরোধ করতে হয়:

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

ব্যবহারকারী সিস্টেম পারমিশন ডায়ালগে সাড়া দেওয়ার পর, সিস্টেম আপনার অ্যাপের onRequestPermissionsResult() ফাংশনটিকে কল করে। সিস্টেম পারমিশন ডায়ালগে ব্যবহারকারীর দেওয়া সাড়া এবং আপনার সংজ্ঞায়িত রিকোয়েস্ট কোডটি পাস করে, যা নিম্নলিখিত কোড স্নিপেটে দেখানো হয়েছে:

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

অবস্থানের অনুমতি অনুরোধ করুন

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

সম্মুখভাগের অবস্থান

আপনার অ্যাপে যদি এমন কোনো ফিচার থাকে যা শুধুমাত্র একবার, অথবা একটি নির্দিষ্ট সময়ের জন্য অবস্থানের তথ্য শেয়ার বা গ্রহণ করে, তাহলে সেই ফিচারটির জন্য ফোরগ্রাউন্ড লোকেশন অ্যাক্সেস প্রয়োজন। নিচে এর কিছু উদাহরণ দেওয়া হলো:

• একটি নেভিগেশন অ্যাপের মধ্যে থাকা একটি ফিচারের মাধ্যমে ব্যবহারকারীরা ধাপে ধাপে দিকনির্দেশনা পেতে পারেন।
• একটি মেসেজিং অ্যাপের মধ্যে থাকা একটি ফিচারের মাধ্যমে ব্যবহারকারীরা অন্য ব্যবহারকারীর সাথে তাদের বর্তমান অবস্থান শেয়ার করতে পারেন।

নিম্নলিখিত পরিস্থিতিগুলির মধ্যে কোনো একটিতে আপনার অ্যাপের কোনো ফিচার ডিভাইসের বর্তমান অবস্থান অ্যাক্সেস করলে, সিস্টেম আপনার অ্যাপটিকে ফোরগ্রাউন্ড লোকেশন ব্যবহারকারী হিসেবে বিবেচনা করে:

• আপনার অ্যাপের অন্তর্গত একটি অ্যাক্টিভিটি দৃশ্যমান।

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

  অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) এবং এর পরবর্তী সংস্করণগুলিতে, আপনাকে অবশ্যই location নামের একটি ফোরগ্রাউন্ড সার্ভিস টাইপ ডিক্লেয়ার করতে হবে, যেমনটি নিম্নলিখিত কোড স্নিপেটে দেখানো হয়েছে। অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে, আমরা এই ফোরগ্রাউন্ড সার্ভিস টাইপটি ডিক্লেয়ার করার পরামর্শ দিই।

  <!-- Recommended for Android 9 (API level 28) and lower. -->
  <!-- Required for Android 10 (API level 29) and higher. -->
  <service
      android:name="MyNavigationService"
      android:foregroundServiceType="location" ... >
      <!-- Any inner elements go here. -->
  </service>

যখন আপনার অ্যাপ ACCESS_COARSE_LOCATION অথবা ACCESS_FINE_LOCATION পারমিশনের জন্য অনুরোধ করে, তখন আপনি ফোরগ্রাউন্ড লোকেশনের প্রয়োজনীয়তা ঘোষণা করেন, যেমনটি নিম্নলিখিত কোড স্নিপেটে দেখানো হয়েছে:

<manifest ... >
  <!-- Include this permission any time your app needs location information. -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

পটভূমির অবস্থান

অ্যাপটির কোনো ফিচার যদি ক্রমাগত অন্যান্য ব্যবহারকারীদের সাথে লোকেশন শেয়ার করে অথবা জিওফেন্সিং এপিআই (Geofencing API) ব্যবহার করে, তাহলে অ্যাপটির ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসের প্রয়োজন হয়। এর কয়েকটি উদাহরণ নিচে দেওয়া হলো:

• পারিবারিক অবস্থান শেয়ার করার একটি অ্যাপের মধ্যে এমন একটি ফিচার রয়েছে, যা ব্যবহারকারীদের পরিবারের সদস্যদের সাথে ক্রমাগত অবস্থান শেয়ার করতে দেয়।
• একটি IoT অ্যাপের মধ্যে থাকা একটি ফিচারের মাধ্যমে ব্যবহারকারীরা তাদের বাড়ির ডিভাইসগুলো এমনভাবে কনফিগার করতে পারেন, যাতে ব্যবহারকারী বাড়ি থেকে বের হলে সেগুলো বন্ধ হয়ে যায় এবং বাড়ি ফিরলে আবার চালু হয়ে যায়।

ফোরগ্রাউন্ড লোকেশন বিভাগে বর্ণিত পরিস্থিতিগুলো ছাড়া অন্য কোনো পরিস্থিতিতে যদি আপনার অ্যাপটি ডিভাইসের বর্তমান লোকেশন অ্যাক্সেস করে, তাহলে সিস্টেম সেটিকে ব্যাকগ্রাউন্ড লোকেশন ব্যবহারকারী হিসেবে বিবেচনা করে। ব্যাকগ্রাউন্ড লোকেশনের নির্ভুলতা ফোরগ্রাউন্ড লোকেশনের নির্ভুলতার সমান, যা আপনার অ্যাপের ঘোষিত লোকেশন পারমিশনগুলোর উপর নির্ভর করে।

অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) এবং এর পরবর্তী সংস্করণগুলোতে, রানটাইমে ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসের অনুরোধ করার জন্য আপনাকে আপনার অ্যাপের ম্যানিফেস্টে অবশ্যই ACCESS_BACKGROUND_LOCATION পারমিশনটি ঘোষণা করতে হবে। অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলোতে, যখন আপনার অ্যাপ ফোরগ্রাউন্ড লোকেশন অ্যাক্সেস পায়, তখন এটি স্বয়ংক্রিয়ভাবে ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসও পেয়ে যায়।

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

অনুমতি প্রত্যাখ্যান পরিচালনা করুন

যদি ব্যবহারকারী কোনো অনুমতির অনুরোধ প্রত্যাখ্যান করেন, তবে আপনার অ্যাপকে অবশ্যই তাকে অনুমতি প্রত্যাখ্যানের পরিণাম বুঝতে সাহায্য করতে হবে। বিশেষ করে, অনুমতি না থাকার কারণে কোন ফিচারগুলো কাজ করছে না, সে সম্পর্কে আপনার অ্যাপকে ব্যবহারকারীদের সচেতন করতে হবে। এটি করার সময়, নিম্নলিখিত সর্বোত্তম অনুশীলনগুলো মনে রাখবেন:

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

• ব্যবহারকারীর মনোযোগ আকর্ষণ করুন। আপনার অ্যাপের UI-এর এমন একটি নির্দিষ্ট অংশ হাইলাইট করুন, যেখানে প্রয়োজনীয় অনুমতি না থাকার কারণে কার্যকারিতা সীমিত। আপনি যা করতে পারেন তার কিছু উদাহরণ নিচে দেওয়া হলো:

  • যেখানে ফিচারটির ফলাফল বা ডেটা প্রদর্শিত হতো, সেখানে একটি বার্তা দেখান।
  • একটি ভিন্ন বাটন প্রদর্শন করুন, যেটিতে একটি ত্রুটির আইকন ও রঙ থাকবে।

• সুনির্দিষ্ট হোন। কোনো সাধারণ বার্তা প্রদর্শন করবেন না। এর পরিবর্তে, পরিষ্কারভাবে জানিয়ে দিন যে আপনার অ্যাপের প্রয়োজনীয় অনুমতি না থাকার কারণে কোন ফিচারগুলো ব্যবহার করা যাচ্ছে না।

• ইউজার ইন্টারফেস ব্লক করবেন না। অন্য কথায়, এমন কোনো পূর্ণ-স্ক্রিন সতর্কীকরণ বার্তা প্রদর্শন করবেন না যা ব্যবহারকারীদের আপনার অ্যাপটি ব্যবহার করা থেকে পুরোপুরি বিরত রাখে।

• ব্যবহারকারীর পছন্দকে সম্মান করুন: অনুরোধ করা অনুমতি না থাকার কারণে ব্যবহারকারীদের কার্যকারিতা কীভাবে প্রভাবিত হচ্ছে, তা তাদের জানানো ঠিক হলেও, তাদের সিদ্ধান্ত পরিবর্তনের জন্য চাপ দেওয়া উচিত নয়। যখন প্রয়োজন হয় (যেমন অনুমতি ছাড়া ব্লক করা অ্যাপের কোনো অংশ ব্যবহার করার চেষ্টা করার সময়), তখন ব্যবহারকারীকে জানানো জরুরি যে তিনি সম্পূর্ণ ফিচার ব্যবহারের সুযোগ পাচ্ছেন না। কিন্তু সিদ্ধান্ত পুনর্বিবেচনা করার জন্য ক্রমাগত পীড়াপীড়ি করা তাদের পছন্দের প্রতি সম্মানজনক নয়।

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

এছাড়াও, যদি কোনো ডিভাইসে আপনার অ্যাপটি ইনস্টল থাকা অবস্থায় ব্যবহারকারী কোনো নির্দিষ্ট অনুমতির জন্য একাধিকবার 'অস্বীকার করুন' (Deny) বিকল্পটি বেছে নেন, তাহলে আপনার অ্যাপটি আবার সেই অনুমতি চাইলে ব্যবহারকারী আর সিস্টেম পারমিশন ডায়ালগটি দেখতে পাবেন না। ব্যবহারকারীর এই পদক্ষেপের অর্থ হলো 'আবার জিজ্ঞাসা করবেন না', এবং এটিকে একটি স্থায়ী অস্বীকৃতি হিসেবে গণ্য করা হয়। ব্যবহারকারীদের শুধুমাত্র তখনই অনুমতির জন্য জিজ্ঞাসা করা অত্যন্ত গুরুত্বপূর্ণ, যখন তাদের কোনো নির্দিষ্ট ফিচারের প্রয়োজন হয়; অন্যথায়, আপনি অনিচ্ছাকৃতভাবে পুনরায় অনুমতি চাওয়ার ক্ষমতা হারাতে পারেন। কিছু পরিস্থিতিতে, ব্যবহারকারীর কোনো পদক্ষেপ ছাড়াই অনুমতিটি স্বয়ংক্রিয়ভাবে অস্বীকার করা হতে পারে। (একটি অনুমতি স্বয়ংক্রিয়ভাবে মঞ্জুরও হতে পারে।) স্বয়ংক্রিয় আচরণ সম্পর্কে কোনো কিছু অনুমান না করাই গুরুত্বপূর্ণ। প্রতিবার যখন আপনার অ্যাপকে এমন কোনো কার্যকারিতা অ্যাক্সেস করতে হবে যার জন্য অনুমতির প্রয়োজন, তখন পরীক্ষা করে দেখুন যে আপনার অ্যাপকে সেই অনুমতিটি এখনও দেওয়া হয়েছে কিনা। অ্যাপের অনুমতি চাওয়ার সময় সেরা ব্যবহারকারীর অভিজ্ঞতা প্রদানের জন্য, 'অ্যাপ পারমিশনের সেরা অনুশীলন ' (App permissions best practices) অংশটিও দেখুন।

টেস্টিং এবং ডিবাগিং করার সময় ডিনায়াল স্ট্যাটাস পরীক্ষা করুন।

কোনো অ্যাপের অনুমতি স্থায়ীভাবে বাতিল করা হয়েছে কিনা (ডিবাগিং এবং টেস্টিংয়ের উদ্দেশ্যে), তা শনাক্ত করতে নিম্নলিখিত কমান্ডটি ব্যবহার করুন:

adb shell dumpsys package PACKAGE_NAME

যেখানে PACKAGE_NAME হলো পরিদর্শন করার প্যাকেজের নাম।

কমান্ডটির আউটপুটে এইরকম দেখতে বিভিন্ন অংশ থাকে:

...
runtime permissions:
  android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...

ব্যবহারকারী কর্তৃক একবার প্রত্যাখ্যাত অনুমতিসমূহ USER_SET দ্বারা চিহ্নিত করা হয়। দুইবার 'প্রত্যাখ্যান' নির্বাচন করার মাধ্যমে স্থায়ীভাবে প্রত্যাখ্যাত অনুমতিসমূহ USER_FIXED দ্বারা চিহ্নিত করা হয়।

টেস্টিংয়ের সময় পরীক্ষকরা যাতে রিকোয়েস্ট ডায়ালগটি দেখতে পান, তা নিশ্চিত করতে আপনার অ্যাপের ডিবাগিং শেষ হলে এই ফ্ল্যাগগুলো রিসেট করুন। এটি করার জন্য, এই কমান্ডটি ব্যবহার করুন:

adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed

PERMISSION_NAME হলো সেই অনুমতির নাম যা আপনি রিসেট করতে চান।

PERMISSION_NAME হলো সেই অনুমতির নাম যা আপনি রিসেট করতে চান।

অ্যান্ড্রয়েড অ্যাপ পারমিশনগুলির সম্পূর্ণ তালিকা দেখতে, পারমিশন এপিআই রেফারেন্স পৃষ্ঠাটি দেখুন।

এককালীন অনুমতি

অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) থেকে, যখনই আপনার অ্যাপ অবস্থান, মাইক্রোফোন বা ক্যামেরা সম্পর্কিত কোনো অনুমতির জন্য অনুরোধ করে, ব্যবহারকারীর সামনে আসা অনুমতি ডায়ালগে ‘শুধুমাত্র এইবার’ নামে একটি বিকল্প থাকে, যেমনটি চিত্র ২-এ দেখানো হয়েছে। যদি ব্যবহারকারী ডায়ালগে এই বিকল্পটি নির্বাচন করেন, তাহলে আপনার অ্যাপকে একটি অস্থায়ী এককালীন অনুমতি দেওয়া হয়।

এরপর আপনার অ্যাপটি একটি নির্দিষ্ট সময়ের জন্য সংশ্লিষ্ট ডেটা অ্যাক্সেস করতে পারবে, যা আপনার অ্যাপের আচরণ এবং ব্যবহারকারীর কার্যকলাপের উপর নির্ভর করে।

• আপনার অ্যাপের কার্যকলাপ দৃশ্যমান থাকা অবস্থায়, আপনার অ্যাপ ডেটা অ্যাক্সেস করতে পারে।
• যদি ব্যবহারকারী আপনার অ্যাপটিকে ব্যাকগ্রাউন্ডে পাঠিয়ে দেয়, তাহলেও আপনার অ্যাপটি অল্প সময়ের জন্য ডেটা অ্যাক্সেস করা চালিয়ে যেতে পারে।
• অ্যাক্টিভিটিটি দৃশ্যমান থাকা অবস্থায় যদি আপনি কোনো ফোরগ্রাউন্ড সার্ভিস চালু করেন এবং এরপর ব্যবহারকারী আপনার অ্যাপটিকে ব্যাকগ্রাউন্ডে নিয়ে যান, তাহলে ফোরগ্রাউন্ড সার্ভিসটি বন্ধ না হওয়া পর্যন্ত আপনার অ্যাপটি ডেটা অ্যাক্সেস করা চালিয়ে যেতে পারবে।

অনুমতি প্রত্যাহার করা হলে অ্যাপ প্রক্রিয়াটি বন্ধ হয়ে যায়।

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

পরবর্তীতে যখন ব্যবহারকারী আপনার অ্যাপটি খুলবেন এবং অ্যাপের কোনো ফিচার অবস্থান, মাইক্রোফোন বা ক্যামেরার অ্যাক্সেস চাইবে, তখন ব্যবহারকারীর কাছে পুনরায় অনুমতি চাওয়া হবে।

অব্যবহৃত অনুমতিগুলি রিসেট করুন

অ্যান্ড্রয়েড অব্যবহৃত রানটাইম পারমিশনগুলোকে তাদের ডিফল্ট, অর্থাৎ প্রত্যাখ্যাত অবস্থায় রিসেট করার বেশ কয়েকটি উপায় প্রদান করে:

• এমন একটি এপিআই যার মাধ্যমে আপনি সক্রিয়ভাবে আপনার অ্যাপের অব্যবহৃত রানটাইম পারমিশনের অ্যাক্সেস বন্ধ করে দিতে পারেন।
• একটি সিস্টেম ব্যবস্থা যা অব্যবহৃত অ্যাপগুলির অনুমতি স্বয়ংক্রিয়ভাবে রিসেট করে ।

অ্যাপ অ্যাক্সেস সরান

অ্যান্ড্রয়েড ১৩ (এপিআই লেভেল ৩৩) এবং এর পরবর্তী সংস্করণগুলোতে, আপনি আপনার অ্যাপের অপ্রয়োজনীয় রানটাইম পারমিশনগুলো বন্ধ করে দিতে পারেন। যখন আপনি আপনার অ্যাপ আপডেট করবেন, তখন এই পদক্ষেপটি গ্রহণ করুন, যাতে ব্যবহারকারীরা সহজেই বুঝতে পারেন কেন আপনার অ্যাপ নির্দিষ্ট পারমিশনগুলো চেয়ে চলেছে। এই বিষয়টি আপনার অ্যাপের প্রতি ব্যবহারকারীর আস্থা তৈরিতে সাহায্য করে।

একটি রানটাইম পারমিশনের অ্যাক্সেস অপসারণ করতে, revokeSelfPermissionOnKill() ফাংশনে সেই পারমিশনটির নাম পাস করুন। একই সাথে একাধিক রানটাইম পারমিশনের অ্যাক্সেস অপসারণ করতে, revokeSelfPermissionsOnKill() ফাংশনে পারমিশন নামগুলোর একটি সংগ্রহ পাস করুন। পারমিশন অপসারণ প্রক্রিয়াটি অ্যাসিঙ্ক্রোনাসভাবে সম্পন্ন হয় এবং আপনার অ্যাপের UID-এর সাথে যুক্ত সমস্ত প্রসেস বন্ধ করে দেয়।

সিস্টেম যাতে আপনার অ্যাপের পারমিশন অ্যাক্সেস বাতিল করতে পারে, তার জন্য আপনার অ্যাপের সাথে যুক্ত সমস্ত প্রসেস বন্ধ করতে হবে। আপনি যখন এপিআই (API) কল করেন, তখন সিস্টেম নির্ধারণ করে কখন এই প্রসেসগুলো বন্ধ করা নিরাপদ। সাধারণত, সিস্টেম ততক্ষণ অপেক্ষা করে যতক্ষণ না আপনার অ্যাপ ফোরগ্রাউন্ডের পরিবর্তে ব্যাকগ্রাউন্ডে দীর্ঘ সময় ধরে চলতে থাকে।

আপনার অ্যাপের আর নির্দিষ্ট রানটাইম পারমিশনের প্রয়োজন নেই, এই তথ্যটি ব্যবহারকারীকে জানাতে, পরবর্তী বার অ্যাপটি চালু করার সময় একটি ডায়ালগ দেখান। এই ডায়ালগে পারমিশনগুলোর তালিকা অন্তর্ভুক্ত থাকতে পারে।

অব্যবহৃত অ্যাপের অনুমতি স্বয়ংক্রিয়ভাবে রিসেট করুন

আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) বা তার উচ্চতর সংস্করণকে টার্গেট করে এবং কয়েক মাস ধরে ব্যবহার না করা হয়, তাহলে সিস্টেম ব্যবহারকারীর দেওয়া সংবেদনশীল রানটাইম পারমিশনগুলো স্বয়ংক্রিয়ভাবে রিসেট করে ব্যবহারকারীর ডেটা সুরক্ষিত রাখে। অ্যাপ হাইবারনেশন সম্পর্কিত গাইডে আরও জানুন।

প্রয়োজনে ডিফল্ট হ্যান্ডলার হওয়ার জন্য অনুরোধ করুন

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

ডিফল্ট হ্যান্ডলার সম্পর্কে আরও তথ্যের জন্য, ব্যবহারকারীদের ডিফল্ট হ্যান্ডলার প্রম্পট দেখানোর নির্দেশনাসহ, শুধুমাত্র ডিফল্ট হ্যান্ডলারে ব্যবহৃত অনুমতি সংক্রান্ত নির্দেশিকাটি দেখুন ।

পরীক্ষার উদ্দেশ্যে সমস্ত রানটাইম অনুমতি প্রদান করুন।

এমুলেটর বা টেস্ট ডিভাইসে কোনো অ্যাপ ইনস্টল করার সময় স্বয়ংক্রিয়ভাবে সমস্ত রানটাইম পারমিশন দেওয়ার জন্য, adb shell install কমান্ডের জন্য -g অপশনটি ব্যবহার করুন, যেমনটি নিম্নলিখিত কোড স্নিপেটে দেখানো হয়েছে:

adb shell install -g PATH_TO_APK_FILE

অতিরিক্ত সম্পদ

অনুমতি সম্পর্কে অতিরিক্ত তথ্যের জন্য, এই নিবন্ধগুলি পড়ুন:

• অনুমতির সংক্ষিপ্ত বিবরণ
• অ্যাপ অনুমতির সর্বোত্তম অনুশীলন

অনুমতি অনুরোধ করার বিষয়ে আরও জানতে, অনুমতির নমুনাগুলো পর্যালোচনা করুন।

আপনি এই কোডল্যাবটিও সম্পন্ন করতে পারেন, যেখানে গোপনীয়তা রক্ষার সর্বোত্তম অনুশীলনগুলো দেখানো হয়েছে ।