প্রতিটি অ্যান্ড্রয়েড অ্যাপ একটি সীমিত অ্যাক্সেস স্যান্ডবক্সে চলে। যদি আপনার অ্যাপের নিজস্ব স্যান্ডবক্সের বাইরে রিসোর্স বা তথ্য ব্যবহার করার প্রয়োজন হয়, তাহলে আপনি একটি রানটাইম অনুমতি ঘোষণা করতে পারেন এবং এই অ্যাক্সেস প্রদানকারী একটি অনুমতি অনুরোধ সেট আপ করতে পারেন। এই পদক্ষেপগুলি অনুমতি ব্যবহারের জন্য কর্মপ্রবাহের অংশ।
যদি আপনি কোনও বিপজ্জনক অনুমতি ঘোষণা করেন, এবং যদি আপনার অ্যাপটি এমন কোনও ডিভাইসে ইনস্টল করা থাকে যা Android 6.0 (API লেভেল 23) বা তার বেশি চালিত হয়, তাহলে আপনাকে রানটাইমের সময় এই নির্দেশিকার ধাপগুলি অনুসরণ করে বিপজ্জনক অনুমতিগুলির জন্য অনুরোধ করতে হবে।
যদি আপনি কোনও বিপজ্জনক অনুমতি ঘোষণা না করেন, অথবা যদি আপনার অ্যাপটি এমন কোনও ডিভাইসে ইনস্টল করা থাকে যা Android 5.1 (API লেভেল 22) বা তার কম সংস্করণে চলে, তাহলে অনুমতিগুলি স্বয়ংক্রিয়ভাবে মঞ্জুর হয়ে যাবে এবং আপনাকে এই পৃষ্ঠার অবশিষ্ট কোনও পদক্ষেপ সম্পূর্ণ করতে হবে না।
মৌলিক নীতিমালা
রানটাইমে অনুমতি অনুরোধ করার মৌলিক নীতিগুলি নিম্নরূপ:
- ব্যবহারকারী যখন প্রয়োজনীয় বৈশিষ্ট্যটির সাথে ইন্টারঅ্যাক্ট করতে শুরু করেন, তখন প্রসঙ্গে অনুমতি চাইতে পারেন।
- ব্যবহারকারীকে ব্লক করবেন না। সর্বদা শিক্ষামূলক UI ফ্লো বাতিল করার বিকল্প প্রদান করুন, যেমন একটি ফ্লো যা অনুমতি অনুরোধের যুক্তি ব্যাখ্যা করে।
- যদি ব্যবহারকারী কোনও বৈশিষ্ট্যের প্রয়োজনীয় অনুমতি অস্বীকার করে বা প্রত্যাহার করে, তাহলে আপনার অ্যাপটিকে সুন্দরভাবে অবনমিত করুন যাতে ব্যবহারকারী আপনার অ্যাপটি ব্যবহার চালিয়ে যেতে পারেন, সম্ভবত সেই বৈশিষ্ট্যটি অক্ষম করে যার জন্য অনুমতির প্রয়োজন।
- কোনও সিস্টেম আচরণ ধরে নিবেন না। উদাহরণস্বরূপ, ধরে নিবেন না যে অনুমতিগুলি একই অনুমতি গোষ্ঠীতে প্রদর্শিত হয়। একটি অনুমতি গোষ্ঠী কেবল সিস্টেমকে এমন সিস্টেম ডায়ালগের সংখ্যা কমাতে সাহায্য করে যা ব্যবহারকারীর কাছে উপস্থাপিত হয় যখন কোনও অ্যাপ ঘনিষ্ঠভাবে সম্পর্কিত অনুমতির অনুরোধ করে।
অনুমতি অনুরোধের জন্য কর্মপ্রবাহ
আপনার অ্যাপে রানটাইম অনুমতি ঘোষণা এবং অনুরোধ করার আগে, আপনার অ্যাপটিকে তা করতে হবে কিনা তা মূল্যায়ন করুন । আপনি আপনার অ্যাপে অনেক ব্যবহারের ক্ষেত্রে কাজ করতে পারেন, যেমন ছবি তোলা, মিডিয়া প্লেব্যাক থামানো এবং প্রাসঙ্গিক বিজ্ঞাপন প্রদর্শন করা, কোনও অনুমতি ঘোষণা না করেই।
যদি আপনি এই সিদ্ধান্তে পৌঁছান যে আপনার অ্যাপটিকে রানটাইম অনুমতি ঘোষণা করতে হবে এবং অনুরোধ করতে হবে, তাহলে এই পদক্ষেপগুলি সম্পূর্ণ করুন:
- আপনার অ্যাপের ম্যানিফেস্ট ফাইলে, আপনার অ্যাপের জন্য যে অনুমতিগুলির অনুরোধ করার প্রয়োজন হতে পারে তা ঘোষণা করুন ।
- আপনার অ্যাপের UX এমনভাবে ডিজাইন করুন যাতে আপনার অ্যাপের নির্দিষ্ট ক্রিয়াগুলি নির্দিষ্ট রানটাইম অনুমতির সাথে সম্পর্কিত হয়। ব্যবহারকারীদের জানান যে কোন ক্রিয়াগুলির জন্য আপনার অ্যাপকে ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করার অনুমতি দেওয়ার প্রয়োজন হতে পারে।
- আপনার অ্যাপে ব্যবহারকারীর সেই কাজ বা অ্যাকশনটি চালু না হওয়া পর্যন্ত অপেক্ষা করুন যার জন্য নির্দিষ্ট ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেসের প্রয়োজন হয়। সেই সময়ে, আপনার অ্যাপটি সেই ডেটা অ্যাক্সেস করার জন্য প্রয়োজনীয় রানটাইম অনুমতির জন্য অনুরোধ করতে পারে।
ব্যবহারকারী ইতিমধ্যেই আপনার অ্যাপের জন্য প্রয়োজনীয় রানটাইম অনুমতিটি মঞ্জুর করেছেন কিনা তা পরীক্ষা করুন । যদি তাই হয়, তাহলে আপনার অ্যাপ ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করতে পারবে। যদি না হয়, তাহলে পরবর্তী ধাপে যান।
প্রতিবার যখন আপনি এমন কোনও অপারেশন করবেন যার জন্য সেই অনুমতির প্রয়োজন হবে, তখন আপনার কাছে অনুমতি আছে কিনা তা পরীক্ষা করে দেখতে হবে।
আপনার অ্যাপটি ব্যবহারকারীকে কোনও যুক্তি দেখাবে কিনা তা পরীক্ষা করে দেখুন , কেন আপনার অ্যাপটিকে একটি নির্দিষ্ট রানটাইম অনুমতি প্রদানের প্রয়োজন তা ব্যাখ্যা করে। যদি সিস্টেম নির্ধারণ করে যে আপনার অ্যাপটি কোনও যুক্তি দেখাবে না, তাহলে কোনও UI উপাদান না দেখিয়ে সরাসরি পরবর্তী ধাপে যান।
যদি সিস্টেম নির্ধারণ করে যে আপনার অ্যাপের কোনও যুক্তি দেখানো উচিত, তবে একটি UI উপাদানে ব্যবহারকারীর কাছে যুক্তিটি উপস্থাপন করুন। এই যুক্তিতে, আপনার অ্যাপ কোন ডেটা অ্যাক্সেস করার চেষ্টা করছে এবং রানটাইম অনুমতি দিলে অ্যাপটি ব্যবহারকারীকে কী কী সুবিধা প্রদান করতে পারে তা স্পষ্টভাবে ব্যাখ্যা করুন। ব্যবহারকারী যুক্তিটি স্বীকার করার পরে, পরবর্তী ধাপে এগিয়ে যান।
আপনার অ্যাপের ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করার জন্য যে রানটাইম অনুমতির প্রয়োজন তা অনুরোধ করুন । সিস্টেমটি একটি রানটাইম অনুমতি প্রম্পট প্রদর্শন করে, যেমন অনুমতি ওভারভিউ পৃষ্ঠায় দেখানো হয়েছে।
ব্যবহারকারীর প্রতিক্রিয়া পরীক্ষা করুন—তারা রানটাইম অনুমতি মঞ্জুর করেছেন নাকি প্রত্যাখ্যান করেছেন।
যদি ব্যবহারকারী আপনার অ্যাপটিকে অনুমতি দেন, তাহলে আপনি ব্যক্তিগত ব্যবহারকারীর ডেটা অ্যাক্সেস করতে পারবেন। যদি ব্যবহারকারী অনুমতি প্রত্যাখ্যান করেন, তাহলে আপনার অ্যাপের অভিজ্ঞতাকে সুন্দরভাবে হ্রাস করুন যাতে এটি সেই অনুমতি দ্বারা সুরক্ষিত তথ্য ছাড়াই ব্যবহারকারীকে কার্যকারিতা প্রদান করে।
চিত্র ১ এই প্রক্রিয়ার সাথে সম্পর্কিত কর্মপ্রবাহ এবং সিদ্ধান্তের সেট চিত্রিত করে:
আপনার অ্যাপটিকে ইতিমধ্যেই অনুমতি দেওয়া হয়েছে কিনা তা নির্ধারণ করুন
ব্যবহারকারী ইতিমধ্যেই আপনার অ্যাপটিকে একটি নির্দিষ্ট অনুমতি দিয়েছেন কিনা তা পরীক্ষা করার জন্য, সেই অনুমতিটি 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 চুক্তির ক্ষেত্রে প্রক্রিয়াটি প্রায় একই রকম।
আপনার অ্যাক্টিভিটি বা ফ্র্যাগমেন্টের ইনিশিয়ালাইজেশন লজিকে,
ActivityResultCallbackএর একটি বাস্তবায়নকেregisterForActivityResult()কলে স্থানান্তর করুন।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. } }
অবস্থানের অনুমতির জন্য অনুরোধ করুন
যখন আপনি অবস্থানের অনুমতির জন্য অনুরোধ করবেন, তখন অন্য যেকোনো রানটাইম অনুমতির মতো একই সর্বোত্তম অনুশীলনগুলি অনুসরণ করুন। অবস্থানের অনুমতির ক্ষেত্রে একটি গুরুত্বপূর্ণ পার্থক্য হল যে সিস্টেমে অবস্থান সম্পর্কিত একাধিক অনুমতি অন্তর্ভুক্ত থাকে। আপনি কোন অনুমতিগুলির জন্য অনুরোধ করবেন এবং কীভাবে আপনি সেগুলি অনুরোধ করবেন তা আপনার অ্যাপের ব্যবহারের ক্ষেত্রে অবস্থানের প্রয়োজনীয়তার উপর নির্ভর করে।
অগ্রভাগের অবস্থান
যদি আপনার অ্যাপে এমন কোনও বৈশিষ্ট্য থাকে যা কেবল একবার বা নির্দিষ্ট সময়ের জন্য অবস্থানের তথ্য ভাগ করে নেয় বা গ্রহণ করে, তাহলে সেই বৈশিষ্ট্যটির জন্য ফোরগ্রাউন্ড অবস্থান অ্যাক্সেস প্রয়োজন। কিছু উদাহরণের মধ্যে রয়েছে:
- একটি নেভিগেশন অ্যাপের মধ্যে, একটি বৈশিষ্ট্য ব্যবহারকারীদের পালাক্রমে দিকনির্দেশনা পেতে দেয়।
- একটি মেসেজিং অ্যাপের মধ্যে, একটি বৈশিষ্ট্য ব্যবহারকারীদের তাদের বর্তমান অবস্থান অন্য ব্যবহারকারীর সাথে ভাগ করে নিতে দেয়।
যদি আপনার অ্যাপের কোনও বৈশিষ্ট্য নিম্নলিখিত পরিস্থিতিতে ডিভাইসের বর্তমান অবস্থান অ্যাক্সেস করে, তাহলে সিস্টেমটি আপনার অ্যাপটিকে ফোরগ্রাউন্ড লোকেশন ব্যবহার করছে বলে বিবেচনা করে:
- আপনার অ্যাপের অন্তর্গত একটি কার্যকলাপ দৃশ্যমান।
আপনার অ্যাপটি একটি ফোরগ্রাউন্ড পরিষেবা চালাচ্ছে। যখন একটি ফোরগ্রাউন্ড পরিষেবা চলছে, তখন সিস্টেমটি একটি স্থায়ী বিজ্ঞপ্তি দেখিয়ে ব্যবহারকারীদের সচেতনতা বৃদ্ধি করে। আপনার অ্যাপটি ব্যাকগ্রাউন্ডে রাখলে অ্যাক্সেস ধরে রাখে, যেমন যখন ব্যবহারকারী তাদের ডিভাইসের হোম বোতাম টিপে বা তাদের ডিভাইসের ডিসপ্লে বন্ধ করে দেয়।
অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) এবং তার উচ্চতর সংস্করণে, আপনাকে অবশ্যই একটি ফোরগ্রাউন্ড পরিষেবার ধরণ
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 অ্যাপের মধ্যে, একটি বৈশিষ্ট্য ব্যবহারকারীদের তাদের হোম ডিভাইসগুলিকে এমনভাবে কনফিগার করতে দেয় যাতে ব্যবহারকারী যখন তাদের বাড়ি থেকে বের হন তখন সেগুলি বন্ধ হয়ে যায় এবং ব্যবহারকারী যখন বাড়িতে ফিরে আসেন তখন আবার চালু হয়।
যদি আপনার অ্যাপটি ফোরগ্রাউন্ড লোকেশন বিভাগে বর্ণিত পরিস্থিতি ব্যতীত অন্য কোনও পরিস্থিতিতে ডিভাইসের বর্তমান অবস্থান অ্যাক্সেস করে, তাহলে সিস্টেমটি ব্যাকগ্রাউন্ড লোকেশন ব্যবহার করছে বলে মনে করে। ব্যাকগ্রাউন্ড লোকেশনের নির্ভুলতা ফোরগ্রাউন্ড লোকেশনের নির্ভুলতার মতোই, যা আপনার অ্যাপের ঘোষিত অবস্থানের অনুমতির উপর নির্ভর করে।
অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) এবং তার উচ্চতর সংস্করণে, রানটাইমের সময় ব্যাকগ্রাউন্ড লোকেশন অ্যাক্সেসের অনুরোধ করার জন্য আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্টে 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-এর একটি নির্দিষ্ট অংশ হাইলাইট করুন যেখানে আপনার অ্যাপের প্রয়োজনীয় অনুমতি না থাকার কারণে কার্যকারিতা সীমিত। আপনি যা করতে পারেন তার উদাহরণগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:
- বৈশিষ্ট্যটির ফলাফল বা ডেটা কোথায় প্রদর্শিত হবে তা একটি বার্তা দেখান।
- একটি ভিন্ন বোতাম প্রদর্শন করুন যাতে একটি ত্রুটি আইকন এবং রঙ রয়েছে।
নির্দিষ্ট করে বলুন। সাধারণ বার্তা প্রদর্শন করবেন না। পরিবর্তে, স্পষ্ট করে বলুন যে কোন বৈশিষ্ট্যগুলি অনুপলব্ধ কারণ আপনার অ্যাপের প্রয়োজনীয় অনুমতি নেই।
ইউজার ইন্টারফেস ব্লক করবেন না। অন্য কথায়, এমন কোনও পূর্ণ-স্ক্রিন সতর্কতা বার্তা প্রদর্শন করবেন না যা ব্যবহারকারীদের আপনার অ্যাপটি ব্যবহার করা থেকে বিরত রাখে।
একই সাথে, আপনার অ্যাপের উচিত ব্যবহারকারীর অনুমতি প্রত্যাখ্যানের সিদ্ধান্তকে সম্মান করা। অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) থেকে শুরু করে, যদি ব্যবহারকারী আপনার অ্যাপের ডিভাইসে ইনস্টলেশনের সময় একাধিকবার নির্দিষ্ট অনুমতির জন্য "ডিনি" ট্যাপ করে, তাহলে আপনার অ্যাপটি আবার সেই অনুমতির জন্য অনুরোধ করলে ব্যবহারকারী সিস্টেম অনুমতি ডায়ালগটি দেখতে পাবেন না। ব্যবহারকারীর ক্রিয়াটি বোঝায় "আবার জিজ্ঞাসা করবেন না"। পূর্ববর্তী সংস্করণগুলিতে, ব্যবহারকারীরা আপনার অ্যাপের অনুমতির জন্য অনুরোধ করার সময় প্রতিবার সিস্টেম অনুমতি ডায়ালগটি দেখতে পেতেন, যদি না তারা পূর্বে "আবার জিজ্ঞাসা করবেন না" চেকবক্স বা বিকল্পটি নির্বাচন করে থাকেন।
যদি কোনও ব্যবহারকারী একাধিকবার অনুমতির অনুরোধ প্রত্যাখ্যান করেন, তাহলে এটিকে স্থায়ী অস্বীকার হিসেবে বিবেচনা করা হবে। ব্যবহারকারীদের যখন কোনও নির্দিষ্ট বৈশিষ্ট্যে অ্যাক্সেসের প্রয়োজন হয় তখনই কেবল অনুমতির জন্য অনুরোধ করা খুবই গুরুত্বপূর্ণ, অন্যথায় আপনি অসাবধানতাবশত পুনরায় অনুমতির অনুরোধ করার ক্ষমতা হারাতে পারেন।
কিছু পরিস্থিতিতে, ব্যবহারকারী কোনও পদক্ষেপ না নিলেও, অনুমতিটি স্বয়ংক্রিয়ভাবে অস্বীকার করা হতে পারে। (একটি অনুমতি স্বয়ংক্রিয়ভাবেও মঞ্জুর করা হতে পারে।) স্বয়ংক্রিয় আচরণ সম্পর্কে কিছু ধরে না নেওয়া গুরুত্বপূর্ণ। প্রতিবার যখন আপনার অ্যাপের এমন কার্যকারিতা অ্যাক্সেস করার প্রয়োজন হয় যার জন্য অনুমতি প্রয়োজন, তখন পরীক্ষা করে দেখুন যে আপনার অ্যাপটি এখনও সেই অনুমতি পেয়েছে কিনা।
অ্যাপ অনুমতি চাওয়ার সময় সর্বোত্তম ব্যবহারকারীর অভিজ্ঞতা প্রদানের জন্য, অ্যাপ অনুমতির সর্বোত্তম অনুশীলনগুলিও দেখুন।
পরীক্ষা এবং ডিবাগ করার সময় অস্বীকৃতির অবস্থা পরীক্ষা করুন
কোনও অ্যাপকে স্থায়ীভাবে অনুমতি দেওয়া হয়নি কিনা তা সনাক্ত করতে (ডিবাগিং এবং পরীক্ষার উদ্দেশ্যে), নিম্নলিখিত কমান্ডটি ব্যবহার করুন:
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 রেফারেন্স পৃষ্ঠাটি দেখুন।
এককালীন অনুমতি
অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) থেকে শুরু করে, যখনই আপনার অ্যাপ অবস্থান, মাইক্রোফোন বা ক্যামেরা সম্পর্কিত কোনও অনুমতির অনুরোধ করে, তখন ব্যবহারকারী-মুখী অনুমতি ডায়ালগে " Only this time" নামে একটি বিকল্প থাকে, যেমনটি চিত্র ২-এ দেখানো হয়েছে। যদি ব্যবহারকারী ডায়ালগে এই বিকল্পটি নির্বাচন করেন, তাহলে আপনার অ্যাপটিকে একটি অস্থায়ী এককালীন অনুমতি দেওয়া হবে।
আপনার অ্যাপটি তখন আপনার অ্যাপের আচরণ এবং ব্যবহারকারীর কর্মকাণ্ডের উপর নির্ভর করে একটি নির্দিষ্ট সময়ের জন্য সম্পর্কিত ডেটা অ্যাক্সেস করতে পারে:
- আপনার অ্যাপের কার্যকলাপ দৃশ্যমান থাকাকালীন, আপনার অ্যাপ ডেটা অ্যাক্সেস করতে পারবে।
- যদি ব্যবহারকারী আপনার অ্যাপটিকে ব্যাকগ্রাউন্ডে পাঠায়, তাহলে আপনার অ্যাপটি অল্প সময়ের জন্য ডেটা অ্যাক্সেস করতে পারবে।
- যদি আপনি কার্যকলাপটি দৃশ্যমান থাকাকালীন একটি ফোরগ্রাউন্ড পরিষেবা চালু করেন এবং ব্যবহারকারী আপনার অ্যাপটিকে ব্যাকগ্রাউন্ডে সরিয়ে নেন, তাহলে ফোরগ্রাউন্ড পরিষেবা বন্ধ না হওয়া পর্যন্ত আপনার অ্যাপ ডেটা অ্যাক্সেস করা চালিয়ে যেতে পারে।
অনুমতি বাতিল হলে অ্যাপ প্রক্রিয়া বন্ধ হয়ে যায়
যদি ব্যবহারকারী একবারের অনুমতি প্রত্যাহার করে, যেমন সিস্টেম সেটিংসে, তাহলে আপনার অ্যাপ ডেটা অ্যাক্সেস করতে পারবে না, আপনি ফোরগ্রাউন্ড পরিষেবা চালু করেছেন কিনা তা নির্বিশেষে। যেকোনো অনুমতির মতো, যদি ব্যবহারকারী আপনার অ্যাপের একবারের অনুমতি প্রত্যাহার করে, তাহলে আপনার অ্যাপের প্রক্রিয়াটি বন্ধ হয়ে যায়।
যখন ব্যবহারকারী পরবর্তীতে আপনার অ্যাপটি খোলেন এবং আপনার অ্যাপের কোনও বৈশিষ্ট্য লোকেশন, মাইক্রোফোন বা ক্যামেরা অ্যাক্সেসের অনুরোধ করে, তখন ব্যবহারকারীকে আবার অনুমতির জন্য অনুরোধ করা হয়।
অব্যবহৃত অনুমতিগুলি রিসেট করুন
অ্যান্ড্রয়েড অব্যবহৃত রানটাইম অনুমতিগুলিকে তাদের ডিফল্ট, অস্বীকৃত অবস্থায় রিসেট করার বিভিন্ন উপায় প্রদান করে:
- এমন একটি API যেখানে আপনি আপনার অ্যাপের অব্যবহৃত রানটাইম অনুমতির অ্যাক্সেস সক্রিয়ভাবে সরিয়ে ফেলতে পারবেন।
- একটি সিস্টেম মেকানিজম যা অব্যবহৃত অ্যাপের অনুমতি স্বয়ংক্রিয়ভাবে রিসেট করে ।
অ্যাপ অ্যাক্সেস সরান
অ্যান্ড্রয়েড ১৩ (এপিআই লেভেল ৩৩) এবং তার উচ্চতর সংস্করণে, আপনি আপনার অ্যাপের রানটাইম অনুমতির অ্যাক্সেস সরিয়ে ফেলতে পারেন যা আপনার অ্যাপের আর প্রয়োজন হয় না। আপনার অ্যাপ আপডেট করার সময়, এই পদক্ষেপটি সম্পাদন করুন যাতে ব্যবহারকারীরা বুঝতে পারেন যে আপনার অ্যাপ কেন নির্দিষ্ট অনুমতির জন্য অনুরোধ করে চলেছে। এই জ্ঞান আপনার অ্যাপের প্রতি ব্যবহারকারীর আস্থা তৈরি করতে সাহায্য করে।
রানটাইম অনুমতির অ্যাক্সেস অপসারণ করতে, সেই অনুমতির নামটি revokeSelfPermissionOnKill() এ পাস করুন। একই সাথে রানটাইম অনুমতির একটি গ্রুপের অ্যাক্সেস অপসারণ করতে, অনুমতির নামের একটি সংগ্রহ revokeSelfPermissionsOnKill() এ পাস করুন। অনুমতি অপসারণ প্রক্রিয়াটি অ্যাসিঙ্ক্রোনাসভাবে ঘটে এবং আপনার অ্যাপের UID-এর সাথে সম্পর্কিত সমস্ত প্রক্রিয়া বন্ধ করে দেয়।
আপনার অ্যাপের অনুমতিগুলি থেকে অ্যাক্সেস সরাতে সিস্টেমকে অবশ্যই আপনার অ্যাপের সাথে সংযুক্ত সমস্ত প্রক্রিয়া বন্ধ করতে হবে। আপনি যখন API কল করেন, তখন সিস্টেম নির্ধারণ করে যে কখন এই প্রক্রিয়াগুলি বন্ধ করা নিরাপদ। সাধারণত, সিস্টেমটি আপনার অ্যাপটি ফোরগ্রাউন্ডের পরিবর্তে ব্যাকগ্রাউন্ডে দীর্ঘ সময় ধরে চলার জন্য অপেক্ষা করে।
ব্যবহারকারীকে জানানোর জন্য যে আপনার অ্যাপের আর নির্দিষ্ট রানটাইম অনুমতির অ্যাক্সেসের প্রয়োজন নেই, পরের বার ব্যবহারকারী যখন আপনার অ্যাপ চালু করবেন তখন একটি ডায়ালগ দেখান। এই ডায়ালগে অনুমতির তালিকা অন্তর্ভুক্ত থাকতে পারে।
অব্যবহৃত অ্যাপের অনুমতিগুলি স্বয়ংক্রিয়ভাবে রিসেট করুন
যদি আপনার অ্যাপটি Android 11 (API লেভেল 30) বা তার উচ্চতর ভার্সনের জন্য তৈরি হয় এবং কয়েক মাস ধরে ব্যবহার না করা হয়, তাহলে সিস্টেমটি ব্যবহারকারীর দেওয়া সংবেদনশীল রানটাইম অনুমতিগুলি স্বয়ংক্রিয়ভাবে রিসেট করে ব্যবহারকারীর ডেটা সুরক্ষিত করে। অ্যাপ হাইবারনেশন সম্পর্কে আরও জানুন গাইডে।
প্রয়োজনে ডিফল্ট হ্যান্ডলার হওয়ার অনুরোধ করুন
কিছু অ্যাপ কল লগ এবং এসএমএস বার্তা সম্পর্কিত সংবেদনশীল ব্যবহারকারীর তথ্য অ্যাক্সেসের উপর নির্ভর করে। আপনি যদি কল লগ এবং এসএমএস বার্তাগুলির জন্য নির্দিষ্ট অনুমতিগুলির জন্য অনুরোধ করতে চান এবং আপনার অ্যাপটি প্লে স্টোরে প্রকাশ করতে চান, তাহলে এই রানটাইম অনুমতিগুলির অনুরোধ করার আগে আপনাকে ব্যবহারকারীকে আপনার অ্যাপটিকে একটি মূল সিস্টেম ফাংশনের জন্য ডিফল্ট হ্যান্ডলার হিসাবে সেট করতে অনুরোধ করতে হবে।
ডিফল্ট হ্যান্ডলার সম্পর্কে আরও তথ্যের জন্য, ব্যবহারকারীদের ডিফল্ট হ্যান্ডলার প্রম্পট দেখানোর নির্দেশিকা সহ, শুধুমাত্র ডিফল্ট হ্যান্ডলারগুলিতে ব্যবহৃত অনুমতি সম্পর্কে নির্দেশিকাটি দেখুন ।
পরীক্ষার উদ্দেশ্যে সমস্ত রানটাইম অনুমতি দিন
এমুলেটর বা টেস্ট ডিভাইসে অ্যাপ ইনস্টল করার সময় স্বয়ংক্রিয়ভাবে সমস্ত রানটাইম অনুমতি প্রদান করতে, নিম্নলিখিত কোড স্নিপেটে প্রদর্শিত adb shell install কমান্ডের জন্য -g বিকল্পটি ব্যবহার করুন:
adb shell install -g PATH_TO_APK_FILE
অতিরিক্ত সম্পদ
অনুমতি সম্পর্কে অতিরিক্ত তথ্যের জন্য, এই নিবন্ধগুলি পড়ুন:
অনুমতি চাওয়া সম্পর্কে আরও জানতে, অনুমতির নমুনাগুলি পর্যালোচনা করুন।
আপনি এই কোডল্যাবটিও সম্পূর্ণ করতে পারেন যা গোপনীয়তার সর্বোত্তম অনুশীলনগুলি প্রদর্শন করে ।