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

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

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

আপনি যদি কোনও বিপজ্জনক অনুমতি ঘোষণা না করেন বা আপনার অ্যাপটি যদি এমন কোনও ডিভাইসে ইনস্টল করা থাকে যেটি Android 5.1 (API লেভেল 22) বা তার নিচের ভার্সনে চলে, তাহলে অনুমতিগুলি অটোমেটিক মঞ্জুর করা হয় এবং আপনাকে এই পৃষ্ঠার বাকি ধাপগুলির কোনওটিই সম্পূর্ণ করতে হবে না।

প্রাথমিক নীতি

রানটাইমে অনুমতি চাওয়ার প্রাথমিক নীতিগুলি নিচে উল্লেখ করা হল:

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

অনুমতির অনুরোধ করার জন্য ওয়ার্কফ্লো

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

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

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

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

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

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

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

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

  7. ব্যবহারকারীর উত্তর চেক করুন—তিনি রানটাইম অনুমতি দেওয়ার বিকল্প বেছে নিয়েছেন নাকি প্রত্যাখ্যান করেছেন।

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

ছবি ১-এ এই প্রসেসের সাথে যুক্ত ওয়ার্কফ্লো ও সিদ্ধান্তের সেট দেখানো হয়েছে:

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

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

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

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

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

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

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

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

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 পরিবর্তন করুন যাতে ব্যবহারকারীরা সহজেই বুঝতে পারেন যে আপনার অ্যাপের কোনও ফিচারের জন্য কেন নির্দিষ্ট অনুমতির প্রয়োজন। যেমন, আপনি হয়ত সেই বোতামের টেক্সট পরিবর্তন করতে পারেন যা ফিচারটি চালু করে।

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

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

Kotlin

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);
}

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

Kotlin

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()-এ কল করে অনুরোধ কোডটি অন্তর্ভুক্ত করুন।

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

Kotlin

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()-এর ইমপ্লিমেন্টেশনকে ইনভোক করে। সিস্টেম অনুমতি ডায়ালগে ব্যবহারকারীর উত্তর পাস করে, সাথে আপনার সংজ্ঞায়িত করা অনুরোধ কোডও পাস করে, যেমনটি নিম্নলিখিত কোড স্নিপেটে দেখানো হয়েছে:

Kotlin

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.
    }
}

লোকেশন অ্যাক্সেস করার অনুমতি চাওয়া

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

ফোরগ্রাউন্ড লোকেশন

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

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

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

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

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

    <!-- 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 অ্যাপের মধ্যে, একটি ফিচার ব্যবহারকারীদের তাদের হোম ডিভাইসগুলি এমনভাবে কনফিগার করতে দেয় যাতে ব্যবহারকারী তাদের বাড়ি থেকে বের হওয়ার সময় সেগুলি বন্ধ হয়ে যায় এবং ব্যবহারকারী বাড়িতে ফিরে এলে আবার চালু হয়।

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

Android 10 (API লেভেল 29) এবং তার পরবর্তী ভার্সনে, রানটাইমে ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসের অনুরোধ করতে, আপনার অ্যাপের ম্যানিফেস্টে ACCESS_BACKGROUND_LOCATION অনুমতি ঘোষণা করতে হবে। Android-এর আগের ভার্সনে, আপনার অ্যাপ ফোরগ্রাউন্ড লোকেশন অ্যাক্সেস পেলে, এটি অটোমেটিক ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসও পেয়ে যায়।

<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-এর একটি নির্দিষ্ট অংশ হাইলাইট করুন যেখানে সীমিত কার্যকারিতা রয়েছে কারণ আপনার অ্যাপের প্রয়োজনীয় অনুমতি নেই। আপনি কী কী করতে পারেন তার কিছু উদাহরণ নিচে দেওয়া হল:

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

  • ইউজার ইন্টারফেস ব্লক করবেন না। অন্যভাবে বলতে গেলে, ফুল-স্ক্রিন সতর্কতামূলক মেসেজ দেখাবেন না যা ব্যবহারকারীকে আপনার অ্যাপ ব্যবহার করা চালিয়ে যেতে বাধা দেয়।

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

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

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

টেস্ট ও ডিবাগ করার সময় ডিনায়াল স্ট্যাটাস ভালোভাবে দেখুন

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

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 হল সেই অনুমতির নাম যা আপনি রিসেট করতে চান।

Android অ্যাপকে দেওয়া অনুমতির সম্পূর্ণ তালিকা দেখতে, অনুমতি API রেফারেন্স পৃষ্ঠা দেখুন।

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

'শুধু এইবার' বিকল্পটি ডায়ালগের তিনটি বোতামের মধ্যে
    দ্বিতীয় বোতাম।
ছবি ২. অ্যাপ এককালীন অনুমতি চাইলে সিস্টেম ডায়ালগ দেখানো হয়।

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

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

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

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

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

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

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

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

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

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

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

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

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

অব্যবহৃত অ্যাপের অনুমতি অটো-রিসেট করুন

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

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

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

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

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

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

adb shell install -g PATH_TO_APK_FILE

অতিরিক্ত রিসোর্স

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

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

এছাড়াও, আপনি এই কোডল্যাব সম্পূর্ণ করতে পারেন যা গোপনীয়তা সংক্রান্ত পেশাদার পদ্ধতি দেখায়।