প্রতিটি Android অ্যাপ একটি সীমিত-অ্যাক্সেস স্যান্ডবক্সে চলে। যদি আপনার অ্যাপের নিজস্ব স্যান্ডবক্সের বাইরে সম্পদ বা তথ্য ব্যবহার করার প্রয়োজন হয়, তাহলে আপনি একটি রানটাইম অনুমতি ঘোষণা করতে পারেন এবং এই অ্যাক্সেস প্রদান করে এমন একটি অনুমতি অনুরোধ সেট আপ করতে পারেন। এই পদক্ষেপগুলি অনুমতি ব্যবহারের জন্য কর্মপ্রবাহের অংশ।
আপনি যদি কোনো বিপজ্জনক অনুমতি ঘোষণা করেন, এবং যদি আপনার অ্যাপটি Android 6.0 (API লেভেল 23) বা তার বেশি চালিত কোনো ডিভাইসে ইনস্টল করা থাকে, তাহলে আপনাকে অবশ্যই এই গাইডের ধাপগুলি অনুসরণ করে রানটাইমে বিপজ্জনক অনুমতির জন্য অনুরোধ করতে হবে।
আপনি যদি কোনো বিপজ্জনক অনুমতি ঘোষণা না করেন, অথবা যদি আপনার অ্যাপটি Android 5.1 (API লেভেল 22) বা তার নিচে চলে এমন কোনো ডিভাইসে ইনস্টল করা থাকে, তাহলে অনুমতিগুলি স্বয়ংক্রিয়ভাবে মঞ্জুর হয়ে যায় এবং আপনাকে বাকি কোনো ধাপ সম্পূর্ণ করতে হবে না। এই পৃষ্ঠায়
মৌলিক নীতি
রানটাইমে অনুমতির অনুরোধ করার প্রাথমিক নীতিগুলি নিম্নরূপ:
- ব্যবহারকারী যখন প্রয়োজনীয় বৈশিষ্ট্যটির সাথে ইন্টারঅ্যাক্ট করতে শুরু করেন তখন প্রসঙ্গে একটি অনুমতির জন্য জিজ্ঞাসা করুন৷
- ব্যবহারকারীকে ব্লক করবেন না। সর্বদা একটি শিক্ষাগত UI প্রবাহ বাতিল করার বিকল্প প্রদান করুন, যেমন একটি প্রবাহ যা অনুমতির অনুরোধের যুক্তি ব্যাখ্যা করে।
- যদি ব্যবহারকারী একটি বৈশিষ্ট্যের প্রয়োজন এমন একটি অনুমতিকে অস্বীকার করে বা প্রত্যাহার করে, তাহলে আপনার অ্যাপটিকে সুন্দরভাবে অবনমিত করুন যাতে ব্যবহারকারী আপনার অ্যাপ ব্যবহার করা চালিয়ে যেতে পারে, সম্ভবত অনুমতির প্রয়োজন এমন বৈশিষ্ট্যটি নিষ্ক্রিয় করে৷
- কোনো সিস্টেম আচরণ অনুমান করবেন না। উদাহরণস্বরূপ, অনুমান করবেন না যে অনুমতিগুলি একই অনুমতি গোষ্ঠীতে উপস্থিত হয়৷ একটি অনুমতি গোষ্ঠী কেবলমাত্র সিস্টেমকে সাহায্য করে সিস্টেম ডায়ালগের সংখ্যা কমিয়ে আনতে যা ব্যবহারকারীর কাছে উপস্থাপিত হয় যখন একটি অ্যাপ ঘনিষ্ঠভাবে সম্পর্কিত অনুমতিগুলির অনুরোধ করে।
অনুমতির অনুরোধের জন্য কর্মপ্রবাহ
আপনি ঘোষণা করার আগে এবং আপনার অ্যাপে রানটাইম অনুমতির অনুরোধ করার আগে, আপনার অ্যাপের তা করা দরকার কিনা তা মূল্যায়ন করুন । আপনি আপনার অ্যাপে অনেকগুলি ব্যবহারের ক্ষেত্রে পূরণ করতে পারেন, যেমন ফটো তোলা, মিডিয়া প্লেব্যাক বিরাম দেওয়া এবং প্রাসঙ্গিক বিজ্ঞাপনগুলি প্রদর্শন করা, কোনো অনুমতি ঘোষণা করার প্রয়োজন ছাড়াই৷
আপনি যদি উপসংহারে পৌঁছেন যে আপনার অ্যাপটিকে রানটাইম অনুমতি ঘোষণা করতে হবে এবং অনুরোধ করতে হবে, এই পদক্ষেপগুলি সম্পূর্ণ করুন:
- আপনার অ্যাপের ম্যানিফেস্ট ফাইলে, আপনার অ্যাপের অনুরোধ করার প্রয়োজন হতে পারে এমন অনুমতিগুলি ঘোষণা করুন ৷
- আপনার অ্যাপের UX ডিজাইন করুন যাতে আপনার অ্যাপের নির্দিষ্ট ক্রিয়াগুলি নির্দিষ্ট রানটাইম অনুমতির সাথে যুক্ত থাকে। ব্যবহারকারীদের জানতে দিন যে কোন কাজগুলির জন্য তাদের ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করার জন্য আপনার অ্যাপের অনুমতি দেওয়ার প্রয়োজন হতে পারে৷
- ব্যবহারকারী আপনার অ্যাপে এমন টাস্ক বা অ্যাকশন শুরু করার জন্য অপেক্ষা করুন যার জন্য নির্দিষ্ট ব্যক্তিগত ব্যবহারকারীর ডেটাতে অ্যাক্সেস প্রয়োজন। সেই সময়ে, আপনার অ্যাপ সেই ডেটা অ্যাক্সেস করার জন্য প্রয়োজনীয় রানটাইম অনুমতির অনুরোধ করতে পারে।
ব্যবহারকারী ইতিমধ্যে আপনার অ্যাপের জন্য প্রয়োজনীয় রানটাইম অনুমতি দিয়েছেন কিনা তা পরীক্ষা করুন । যদি তাই হয়, আপনার অ্যাপ ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করতে পারে। যদি না হয়, পরবর্তী ধাপে চালিয়ে যান।
প্রতিবার যখন আপনি একটি অপারেশন করেন যার জন্য সেই অনুমতির প্রয়োজন হয় তখন আপনাকে অবশ্যই পরীক্ষা করতে হবে৷
আপনার অ্যাপের ব্যবহারকারীকে কেন একটি নির্দিষ্ট রানটাইম অনুমতি দিতে হবে তা ব্যাখ্যা করে আপনার অ্যাপ ব্যবহারকারীকে যুক্তি দেখাবে কিনা তা পরীক্ষা করুন । যদি সিস্টেম নির্ধারণ করে যে আপনার অ্যাপটি কোনো যুক্তি দেখাবে না, তাহলে কোনো UI উপাদান না দেখিয়ে সরাসরি পরবর্তী ধাপে যান।
সিস্টেম যদি নির্ধারণ করে যে আপনার অ্যাপের একটি যুক্তি দেখানো উচিত, তবে, ব্যবহারকারীর কাছে একটি UI উপাদানে যুক্তি উপস্থাপন করুন। এই যুক্তিতে, স্পষ্টভাবে ব্যাখ্যা করুন যে আপনার অ্যাপ কোন ডেটা অ্যাক্সেস করার চেষ্টা করছে এবং অ্যাপটি ব্যবহারকারীকে কি সুবিধা দিতে পারে যদি তারা রানটাইম অনুমতি দেয়। ব্যবহারকারী যৌক্তিকতা স্বীকার করার পরে, পরবর্তী ধাপে চালিয়ে যান।
ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করার জন্য আপনার অ্যাপের যে রানটাইম অনুমতি প্রয়োজন তা অনুরোধ করুন । সিস্টেমটি একটি রানটাইম অনুমতি প্রম্পট প্রদর্শন করে, যেমন অনুমতি ওভারভিউ পৃষ্ঠায় দেখানো একটি।
ব্যবহারকারীর প্রতিক্রিয়া পরীক্ষা করুন—তারা রানটাইম অনুমতি মঞ্জুর বা অস্বীকার করা বেছে নিয়েছে কিনা।
ব্যবহারকারী আপনার অ্যাপের অনুমতি দিলে, আপনি ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করতে পারবেন। ব্যবহারকারী যদি এর পরিবর্তে অনুমতি অস্বীকার করে, তাহলে আপনার অ্যাপের অভিজ্ঞতাকে ভালোভাবে হ্রাস করুন যাতে এটি সেই অনুমতি দ্বারা সুরক্ষিত তথ্য ছাড়াই ব্যবহারকারীকে কার্যকারিতা প্রদান করে।
চিত্র 1 এই প্রক্রিয়ার সাথে যুক্ত কর্মপ্রবাহ এবং সিদ্ধান্তের সেটকে চিত্রিত করে:
আপনার অ্যাপটিকে ইতিমধ্যেই অনুমতি দেওয়া হয়েছে কিনা তা নির্ধারণ করুন
ব্যবহারকারী আপনার অ্যাপটিকে ইতিমধ্যেই একটি নির্দিষ্ট অনুমতি দিয়েছে কিনা তা পরীক্ষা করতে, সেই অনুমতিটি 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
চুক্তির জন্য প্রক্রিয়াটি প্রায় একই।
আপনার অ্যাক্টিভিটি বা ফ্র্যাগমেন্টের ইনিশিয়ালাইজেশন লজিকে,
registerForActivityResult()
এ একটি কলেActivityResultCallback
এর বাস্তবায়ন পাস করুন।ActivityResultCallback
সংজ্ঞায়িত করে কিভাবে আপনার অ্যাপ অনুমতির অনুরোধে ব্যবহারকারীর প্রতিক্রিয়া পরিচালনা করে।registerForActivityResult()
এর রিটার্ন মানের একটি রেফারেন্স রাখুন, যাActivityResultLauncher
টাইপের।প্রয়োজনে সিস্টেম অনুমতি ডায়ালগ প্রদর্শন করতে, আপনি আগের ধাপে সংরক্ষিত
ActivityResultLauncher
এর উদাহরণেlaunch()
পদ্ধতিতে কল করুন।launch()
কল করার পরে, সিস্টেম অনুমতি ডায়ালগ প্রদর্শিত হয়। যখন ব্যবহারকারী একটি পছন্দ করে, সিস্টেমটি অ্যাসিঙ্ক্রোনাসভাবে আপনারActivityResultCallback
এর বাস্তবায়নের আহ্বান জানায়, যা আপনি পূর্ববর্তী ধাপে সংজ্ঞায়িত করেছেন।দ্রষ্টব্য: আপনি যখন
launch()
কল করেন তখন আপনার অ্যাপটি প্রদর্শিত ডায়ালগটি কাস্টমাইজ করতে পারে না । ব্যবহারকারীকে আরও তথ্য বা প্রসঙ্গ সরবরাহ করতে, আপনার অ্যাপের UI পরিবর্তন করুন যাতে ব্যবহারকারীদের বুঝতে সহজ হয় কেন আপনার অ্যাপের একটি বৈশিষ্ট্যের জন্য একটি নির্দিষ্ট অনুমতি প্রয়োজন। উদাহরণস্বরূপ, আপনি বৈশিষ্ট্যটি সক্ষম করে এমন বোতামের পাঠ্য পরিবর্তন করতে পারেন।এছাড়াও, সিস্টেম অনুমতি ডায়ালগের পাঠ্যটি আপনার অনুরোধ করা অনুমতির সাথে যুক্ত অনুমতি গোষ্ঠীর উল্লেখ করে। এই অনুমতি গ্রুপিং সিস্টেম সহজে-ব্যবহারের জন্য ডিজাইন করা হয়েছে, এবং আপনার অ্যাপটি একটি নির্দিষ্ট অনুমতি গোষ্ঠীর মধ্যে বা বাইরে থাকা অনুমতিগুলির উপর নির্ভর করা উচিত নয়।
নিম্নলিখিত কোড স্নিপেট দেখায় কিভাবে অনুমতি প্রতিক্রিয়া পরিচালনা করতে হয়:
কোটলিন
// Register the permissions callback, which handles the user's response to the // system permissions dialog. Save the return value, an instance of // ActivityResultLauncher. You can use either a val, as shown in this snippet, // or a lateinit var in your onAttach() or onCreate() method. val requestPermissionLauncher = registerForActivityResult(RequestPermission() ) { isGranted: Boolean -> if (isGranted) { // 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. } }
জাভা
// Register the permissions callback, which handles the user's response to the // system permissions dialog. Save the return value, an instance of // ActivityResultLauncher, as an instance variable. private ActivityResultLauncher<String> requestPermissionLauncher = registerForActivityResult(new RequestPermission(), isGranted -> { if (isGranted) { // 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. } });
এবং এই কোড স্নিপেট একটি অনুমতি পরীক্ষা করার জন্য এবং প্রয়োজনে ব্যবহারকারীর কাছ থেকে অনুমতির অনুরোধ করার জন্য প্রস্তাবিত প্রক্রিয়া প্রদর্শন করে:
কোটলিন
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. } }
অবস্থান অনুমতি অনুরোধ
যখন আপনি অবস্থানের অনুমতির জন্য অনুরোধ করেন, অন্য যেকোনো রানটাইম অনুমতির মতো একই সেরা অনুশীলনগুলি অনুসরণ করুন৷ অবস্থানের অনুমতির ক্ষেত্রে একটি গুরুত্বপূর্ণ পার্থক্য হল যে সিস্টেমটি অবস্থান সম্পর্কিত একাধিক অনুমতি অন্তর্ভুক্ত করে। আপনি কোন অনুমতিগুলির জন্য অনুরোধ করেন এবং আপনি কীভাবে তাদের অনুরোধ করেন তা নির্ভর করে আপনার অ্যাপের ব্যবহারের ক্ষেত্রে অবস্থানের প্রয়োজনীয়তার উপর।
ফোরগ্রাউন্ড অবস্থান
যদি আপনার অ্যাপে এমন একটি বৈশিষ্ট্য থাকে যা শুধুমাত্র একবার বা নির্দিষ্ট সময়ের জন্য অবস্থানের তথ্য শেয়ার করে বা গ্রহণ করে, তাহলে সেই বৈশিষ্ট্যটির জন্য ফোরগ্রাউন্ড লোকেশন অ্যাক্সেস প্রয়োজন। কিছু উদাহরণ নিম্নলিখিত অন্তর্ভুক্ত:
- একটি নেভিগেশন অ্যাপের মধ্যে, একটি বৈশিষ্ট্য ব্যবহারকারীদের পালাক্রমে দিকনির্দেশ পেতে দেয়।
- একটি মেসেজিং অ্যাপের মধ্যে, একটি বৈশিষ্ট্য ব্যবহারকারীদের তাদের বর্তমান অবস্থান অন্য ব্যবহারকারীর সাথে শেয়ার করতে দেয়।
সিস্টেমটি আপনার অ্যাপটিকে ফোরগ্রাউন্ড লোকেশন ব্যবহার করছে বলে বিবেচনা করে যদি আপনার অ্যাপের একটি বৈশিষ্ট্য নিম্নলিখিত পরিস্থিতিতে ডিভাইসের বর্তমান অবস্থান অ্যাক্সেস করে:
- আপনার অ্যাপের অন্তর্গত একটি কার্যকলাপ দৃশ্যমান।
আপনার অ্যাপ একটি ফোরগ্রাউন্ড পরিষেবা চালাচ্ছে। যখন একটি ফোরগ্রাউন্ড পরিষেবা চলছে, সিস্টেমটি একটি অবিরাম বিজ্ঞপ্তি দেখিয়ে ব্যবহারকারীর সচেতনতা বাড়ায়। আপনার অ্যাপটি ব্যাকগ্রাউন্ডে রাখা হলে অ্যাক্সেস বজায় রাখে, যেমন ব্যবহারকারী যখন তাদের ডিভাইসে হোম বোতাম টিপে বা তাদের ডিভাইসের প্রদর্শন বন্ধ করে দেয়।
Android 10 (API স্তর 29) এবং উচ্চতর, আপনাকে অবশ্যই একটি ফোরগ্রাউন্ড পরিষেবার ধরনের
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>
পটভূমি অবস্থান
একটি অ্যাপের ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসের প্রয়োজন যদি অ্যাপের মধ্যে একটি বৈশিষ্ট্য ক্রমাগত অন্যান্য ব্যবহারকারীদের সাথে লোকেশন শেয়ার করে বা জিওফেনিং API ব্যবহার করে। বেশ কয়েকটি উদাহরণ নিম্নলিখিত অন্তর্ভুক্ত:
- একটি ফ্যামিলি লোকেশন শেয়ারিং অ্যাপের মধ্যে, একটি বৈশিষ্ট্য ব্যবহারকারীদের পরিবারের সদস্যদের সাথে ক্রমাগত লোকেশন শেয়ার করতে দেয়।
- একটি IoT অ্যাপের মধ্যে, একটি বৈশিষ্ট্য ব্যবহারকারীদের তাদের বাড়ির ডিভাইসগুলিকে এমনভাবে কনফিগার করতে দেয় যে ব্যবহারকারীরা যখন তাদের বাড়ি ছেড়ে যায় তখন তারা বন্ধ করে দেয় এবং ব্যবহারকারী যখন বাড়িতে ফিরে আসে তখন আবার চালু করে।
সিস্টেমটি আপনার অ্যাপটিকে ব্যাকগ্রাউন্ড লোকেশন ব্যবহার করছে বলে বিবেচনা করে যদি এটি ফোরগ্রাউন্ড লোকেশন বিভাগে বর্ণিত অন্য কোনো পরিস্থিতিতে ডিভাইসের বর্তমান অবস্থান অ্যাক্সেস করে। পটভূমি অবস্থান নির্ভুলতা ফোরগ্রাউন্ড অবস্থান নির্ভুলতার সমান, যা আপনার অ্যাপ ঘোষণা করা অবস্থানের অনুমতিগুলির উপর নির্ভর করে৷
Android 10 (API স্তর 29) এবং উচ্চতর, রানটাইমে ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসের অনুরোধ করতে আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্টে 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 এর একটি নির্দিষ্ট অংশ হাইলাইট করুন যেখানে সীমিত কার্যকারিতা রয়েছে কারণ আপনার অ্যাপের প্রয়োজনীয় অনুমতি নেই। আপনি যা করতে পারেন তার উদাহরণগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:
- একটি বার্তা দেখান যেখানে বৈশিষ্ট্যের ফলাফল বা ডেটা উপস্থিত হবে৷
- একটি ভিন্ন বোতাম প্রদর্শন করুন যাতে একটি ত্রুটি আইকন এবং রঙ রয়েছে৷
নির্দিষ্ট হোন। একটি সাধারণ বার্তা প্রদর্শন করবেন না। পরিবর্তে, কোন বৈশিষ্ট্যগুলি অনুপলব্ধ তা পরিষ্কার করুন কারণ আপনার অ্যাপের প্রয়োজনীয় অনুমতি নেই৷
ইউজার ইন্টারফেস ব্লক করবেন না। অন্য কথায়, একটি পূর্ণ-স্ক্রীন সতর্কতা বার্তা প্রদর্শন করবেন না যা ব্যবহারকারীদের আপনার অ্যাপ ব্যবহার করা চালিয়ে যেতে বাধা দেয়।
একই সময়ে, আপনার অ্যাপের ব্যবহারকারীর অনুমতি অস্বীকার করার সিদ্ধান্তকে সম্মান করা উচিত। অ্যান্ড্রয়েড 11 (এপিআই লেভেল 30) থেকে শুরু করে, কোনো ডিভাইসে আপনার অ্যাপের ইনস্টলেশনের জীবদ্দশায় ব্যবহারকারী যদি একাধিকবার নির্দিষ্ট অনুমতির জন্য অস্বীকার করে ট্যাপ করে, আপনার অ্যাপ আবার সেই অনুমতির অনুরোধ করলে ব্যবহারকারী সিস্টেম পারমিশন ডায়ালগ দেখতে পাবেন না। ব্যবহারকারীর ক্রিয়াটি বোঝায় "আবার জিজ্ঞাসা করবেন না।" পূর্ববর্তী সংস্করণগুলিতে, ব্যবহারকারীরা প্রতিবার আপনার অ্যাপ অনুমতির অনুরোধ করার সময় সিস্টেম অনুমতি ডায়ালগ দেখেছেন, যদি না তারা আগে একটি "আবার জিজ্ঞাসা করবেন না" চেকবক্স বা বিকল্প নির্বাচন করেন।
যদি একজন ব্যবহারকারী একাধিকবার অনুমতির অনুরোধ অস্বীকার করে, তাহলে এটি একটি স্থায়ী অস্বীকৃতি বলে বিবেচিত হয়। ব্যবহারকারীদের একটি নির্দিষ্ট বৈশিষ্ট্যে অ্যাক্সেসের প্রয়োজন হলে শুধুমাত্র অনুমতির জন্য অনুরোধ করা খুবই গুরুত্বপূর্ণ, অন্যথায় আপনি অসাবধানতাবশত অনুমতিগুলি পুনরায় অনুরোধ করার ক্ষমতা হারাতে পারেন।
নির্দিষ্ট পরিস্থিতিতে, ব্যবহারকারীর কোনো ব্যবস্থা না নিয়েই অনুমতি স্বয়ংক্রিয়ভাবে অস্বীকার করা হতে পারে। (একটি অনুমতি স্বয়ংক্রিয়ভাবে মঞ্জুর করা যেতে পারে।) স্বয়ংক্রিয় আচরণ সম্পর্কে কিছু অনুমান না করা গুরুত্বপূর্ণ। প্রতিবার যখন আপনার অ্যাপের কার্যকারিতা অ্যাক্সেস করার প্রয়োজন হয় যার জন্য একটি অনুমতির প্রয়োজন হয়, পরীক্ষা করে দেখুন যে আপনার অ্যাপটি এখনও সেই অনুমতি মঞ্জুর করা হয়েছে।
অ্যাপের অনুমতি চাওয়ার সময় সর্বোত্তম ব্যবহারকারীর অভিজ্ঞতা প্রদান করতে, অ্যাপের অনুমতির সেরা অনুশীলনগুলিও দেখুন।
পরীক্ষা এবং ডিবাগিং করার সময় অস্বীকারের স্থিতি পরীক্ষা করুন
একটি অ্যাপ্লিকেশন স্থায়ীভাবে অনুমতি অস্বীকার করা হয়েছে কিনা তা সনাক্ত করতে (ডিবাগিং এবং পরীক্ষার উদ্দেশ্যে), নিম্নলিখিত কমান্ডটি ব্যবহার করুন:
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 হল সেই অনুমতির নাম যা আপনি পুনরায় সেট করতে চান৷
অ্যান্ড্রয়েড অ্যাপের অনুমতিগুলির একটি সম্পূর্ণ তালিকা দেখতে, অনুমতি API রেফারেন্স পৃষ্ঠাতে যান।
এককালীন অনুমতি
অ্যান্ড্রয়েড 11 (এপিআই লেভেল 30) থেকে শুরু করে, যখনই আপনার অ্যাপ লোকেশন, মাইক্রোফোন বা ক্যামেরা সম্পর্কিত অনুমতির অনুরোধ করে, ব্যবহারকারী-মুখী অনুমতি ডায়ালগে শুধুমাত্র এই সময় নামে একটি বিকল্প থাকে, যেমন চিত্র 2-এ দেখানো হয়েছে। ব্যবহারকারী যদি এটি নির্বাচন করে ডায়ালগের বিকল্পে, আপনার অ্যাপটিকে একটি অস্থায়ী এককালীন অনুমতি দেওয়া হয়েছে।
আপনার অ্যাপটি তখন একটি নির্দিষ্ট সময়ের জন্য সম্পর্কিত ডেটা অ্যাক্সেস করতে পারে যা আপনার অ্যাপের আচরণ এবং ব্যবহারকারীর কর্মের উপর নির্ভর করে:
- আপনার অ্যাপের কার্যকলাপ দৃশ্যমান থাকাকালীন, আপনার অ্যাপ ডেটা অ্যাক্সেস করতে পারে।
- ব্যবহারকারী যদি আপনার অ্যাপকে ব্যাকগ্রাউন্ডে পাঠায়, তাহলে আপনার অ্যাপটি অল্প সময়ের জন্য ডেটা অ্যাক্সেস করা চালিয়ে যেতে পারে।
- ক্রিয়াকলাপটি দৃশ্যমান থাকাকালীন আপনি যদি একটি ফোরগ্রাউন্ড পরিষেবা চালু করেন এবং ব্যবহারকারী আপনার অ্যাপটিকে ব্যাকগ্রাউন্ডে নিয়ে যান, আপনার অ্যাপটি ফোরগ্রাউন্ড পরিষেবা বন্ধ না হওয়া পর্যন্ত ডেটা অ্যাক্সেস করা চালিয়ে যেতে পারে।
অনুমতি প্রত্যাহার করা হলে অ্যাপ প্রক্রিয়া বন্ধ হয়ে যায়
যদি ব্যবহারকারী একবারের অনুমতি প্রত্যাহার করে, যেমন সিস্টেম সেটিংসে, তাহলে আপনার অ্যাপটি ডেটা অ্যাক্সেস করতে পারবে না, আপনি ফোরগ্রাউন্ড পরিষেবা চালু করেছেন কিনা। যেকোনো অনুমতির মতো, ব্যবহারকারী যদি আপনার অ্যাপের এককালীন অনুমতি প্রত্যাহার করে, আপনার অ্যাপের প্রক্রিয়াটি বন্ধ হয়ে যায়।
যখন ব্যবহারকারী পরবর্তীতে আপনার অ্যাপটি খোলে এবং আপনার অ্যাপের একটি বৈশিষ্ট্য অবস্থান, মাইক্রোফোন বা ক্যামেরায় অ্যাক্সেসের অনুরোধ করে, তখন ব্যবহারকারীকে আবার অনুমতির জন্য অনুরোধ করা হয়।
অব্যবহৃত অনুমতি পুনরায় সেট করুন
অ্যান্ড্রয়েড অব্যবহৃত রানটাইম অনুমতিগুলিকে তাদের ডিফল্ট, অস্বীকৃত অবস্থায় পুনরায় সেট করার বিভিন্ন উপায় সরবরাহ করে:
- একটি API যেখানে আপনি একটি অব্যবহৃত রানটাইম অনুমতিতে আপনার অ্যাপের অ্যাক্সেস সক্রিয়ভাবে সরিয়ে দিতে পারেন।
- একটি সিস্টেম মেকানিজম যা স্বয়ংক্রিয়ভাবে অব্যবহৃত অ্যাপগুলির অনুমতিগুলি পুনরায় সেট করে ৷
অ্যাপ অ্যাক্সেস সরান
অ্যান্ড্রয়েড 13 (এপিআই লেভেল 33) এবং উচ্চতর, আপনি রানটাইম অনুমতিগুলিতে আপনার অ্যাপের অ্যাক্সেস সরিয়ে ফেলতে পারেন যা আপনার অ্যাপের আর প্রয়োজন হয় না। আপনি যখন আপনার অ্যাপ আপডেট করেন, তখন এই পদক্ষেপটি সম্পাদন করুন যাতে ব্যবহারকারীরা বুঝতে পারে যে কেন আপনার অ্যাপ নির্দিষ্ট অনুমতির অনুরোধ করে চলেছে। এই জ্ঞান আপনার অ্যাপে ব্যবহারকারীর আস্থা তৈরি করতে সাহায্য করে।
রানটাইম অনুমতির অ্যাক্সেস সরাতে, সেই অনুমতির নামটি revokeSelfPermissionOnKill()
এ পাস করুন। একই সময়ে রানটাইম অনুমতিগুলির একটি গোষ্ঠীতে অ্যাক্সেস সরাতে, revokeSelfPermissionsOnKill()
এ অনুমতির নামের একটি সংগ্রহ পাস করুন। অনুমতি অপসারণ প্রক্রিয়া অ্যাসিঙ্ক্রোনাসভাবে ঘটে এবং আপনার অ্যাপের UID-এর সাথে যুক্ত সমস্ত প্রক্রিয়াকে মেরে ফেলে।
অনুমতিতে আপনার অ্যাপের অ্যাক্সেস সরিয়ে দেওয়ার জন্য সিস্টেমের জন্য, আপনার অ্যাপের সাথে আবদ্ধ সমস্ত প্রক্রিয়া অবশ্যই মেরে ফেলতে হবে। আপনি যখন API কল করেন, তখন সিস্টেম নির্ধারণ করে যে কখন এই প্রক্রিয়াগুলিকে মেরে ফেলা নিরাপদ। সাধারণত, আপনার অ্যাপটি ফোরগ্রাউন্ডের পরিবর্তে ব্যাকগ্রাউন্ডে চলার জন্য একটি বর্ধিত সময় ব্যয় না করা পর্যন্ত সিস্টেমটি অপেক্ষা করে।
ব্যবহারকারীকে জানাতে যে আপনার অ্যাপের আর নির্দিষ্ট রানটাইম অনুমতিগুলিতে অ্যাক্সেসের প্রয়োজন নেই, পরের বার ব্যবহারকারী আপনার অ্যাপ চালু করার সময় একটি ডায়ালগ দেখান। এই ডায়ালগে অনুমতির তালিকা অন্তর্ভুক্ত করা যেতে পারে।
অব্যবহৃত অ্যাপের অটো রিসেট অনুমতি
যদি আপনার অ্যাপটি Android 11 (API লেভেল 30) বা তার বেশিকে টার্গেট করে এবং কয়েক মাস ধরে ব্যবহার না করা হয়, তাহলে ব্যবহারকারী আপনার অ্যাপকে যে সংবেদনশীল রানটাইম অনুমতি দিয়েছিলেন সেটি স্বয়ংক্রিয়ভাবে রিসেট করে সিস্টেম ব্যবহারকারীর ডেটা রক্ষা করে। অ্যাপ হাইবারনেশন সম্পর্কে গাইডে আরও জানুন।
প্রয়োজনে ডিফল্ট হ্যান্ডলার হওয়ার জন্য অনুরোধ করুন
কিছু অ্যাপ কল লগ এবং এসএমএস বার্তা সম্পর্কিত সংবেদনশীল ব্যবহারকারীর তথ্য অ্যাক্সেসের উপর নির্ভর করে। আপনি যদি কল লগ এবং এসএমএস বার্তাগুলির নির্দিষ্ট অনুমতিগুলির জন্য অনুরোধ করতে চান এবং আপনার অ্যাপটি প্লে স্টোরে প্রকাশ করতে চান, তাহলে এই রানটাইম অনুমতিগুলির অনুরোধ করার আগে আপনাকে অবশ্যই আপনার অ্যাপটিকে একটি মূল সিস্টেম ফাংশনের জন্য ডিফল্ট হ্যান্ডলার হিসাবে সেট করার জন্য অনুরোধ করতে হবে৷
ব্যবহারকারীদের একটি ডিফল্ট হ্যান্ডলার প্রম্পট দেখানোর নির্দেশিকা সহ ডিফল্ট হ্যান্ডলার সম্পর্কে আরও তথ্যের জন্য, শুধুমাত্র ডিফল্ট হ্যান্ডলারগুলিতে ব্যবহৃত অনুমতি সম্পর্কে নির্দেশিকা দেখুন ।
পরীক্ষার উদ্দেশ্যে সমস্ত রানটাইম অনুমতি দিন
আপনি যখন কোনো এমুলেটর বা টেস্ট ডিভাইসে কোনো অ্যাপ ইনস্টল করেন তখন সমস্ত রানটাইম অনুমতি স্বয়ংক্রিয়ভাবে মঞ্জুর করতে, adb shell install
কমান্ডের জন্য -g
বিকল্পটি ব্যবহার করুন, যেমনটি নিম্নলিখিত কোড স্নিপেটে দেখানো হয়েছে:
adb shell install -g PATH_TO_APK_FILE
অতিরিক্ত সম্পদ
অনুমতি সম্পর্কে অতিরিক্ত তথ্যের জন্য, এই নিবন্ধগুলি পড়ুন:
অনুমতির অনুরোধ সম্পর্কে আরও জানতে, অনুমতির নমুনাগুলি পর্যালোচনা করুন
আপনি এই কোডল্যাবটি সম্পূর্ণ করতে পারেন যা গোপনীয়তার সর্বোত্তম অনুশীলনগুলি প্রদর্শন করে ।