অ্যান্ড্রয়েড 6.0 এবং উচ্চতর সংস্করণে, ব্যবহারকারীদের জন্য অনুমতিগুলিকে আরও বোধগম্য, উপযোগী এবং সুরক্ষিত করার জন্য অ্যান্ড্রয়েড অ্যাপের অনুমতি মডেলটি ডিজাইন করা হয়েছে। মডেলটি এমন অ্যান্ড্রয়েড অ্যাপগুলিকে স্থানান্তরিত করেছে যেগুলির জন্য বিপজ্জনক অনুমতি প্রয়োজন ( আক্রান্ত অনুমতিগুলি দেখুন) একটি ইনস্টল-টাইম অনুমতি মডেল থেকে রানটাইম অনুমতি মডেলে:
- ইনস্টল-টাইম অনুমতি
( অ্যান্ড্রয়েড 5.1 এবং তার নিচের ) ব্যবহারকারীরা অ্যাপটি ইনস্টল বা আপডেট করার সময় একটি অ্যাপকে বিপজ্জনক অনুমতি দেয়। ডিভাইস নির্মাতারা এবং বাহক ব্যবহারকারীকে অবহিত না করেই প্রি-অনুমোদিত অনুমতি সহ অ্যাপগুলি পূর্ব-ইন্সটল করতে পারে।
- রানটাইম অনুমতি
( অ্যান্ড্রয়েড 6.0 থেকে 9 ) যখন অ্যাপটি চলছে তখন ব্যবহারকারীরা একটি অ্যাপকে বিপজ্জনক অনুমতি দেয়। যখন অনুমতির অনুরোধ করা হয় (যেমন কখন অ্যাপটি চালু হয় বা কখন ব্যবহারকারী একটি নির্দিষ্ট বৈশিষ্ট্য অ্যাক্সেস করে) অ্যাপের উপর নির্ভর করে, তবে ব্যবহারকারী নির্দিষ্ট অনুমতি গোষ্ঠীগুলিতে অ্যাপ অ্যাক্সেস মঞ্জুর/অস্বীকার করে। OEMs/ক্যারিয়াররা অ্যাপগুলিকে প্রি-ইন্সটল করতে পারে, কিন্তু অনুমতি দিতে পারে না যদি না তারা ব্যতিক্রম প্রক্রিয়ার মধ্য দিয়ে যায়। ( ব্যতিক্রম তৈরি করা দেখুন।)
( অ্যান্ড্রয়েড 10 ) ব্যবহারকারীরা স্বচ্ছতা দেখতে পান এবং কোন অ্যাপে অ্যাক্টিভিটি রিকগনিশন (এআর) রানটাইম অনুমতি রয়েছে তার উপর তাদের নিয়ন্ত্রণ রয়েছে। ব্যবহারকারীদের রানটাইম অনুমতি ডায়ালগ দ্বারা অনুরোধ করা হয় হয় সর্বদা অনুমতি দিন, ব্যবহার করার সময় অনুমতি দিন, অথবা অনুমতি অস্বীকার করুন। অ্যান্ড্রয়েড 10-এ একটি ওএস আপগ্রেড করার সময়, অ্যাপগুলিকে দেওয়া অনুমতিগুলি বজায় রাখা হয়, তবে ব্যবহারকারীরা সেটিংসে গিয়ে সেগুলি পরিবর্তন করতে পারেন।
রানটাইম অনুমতিগুলি অ্যাপগুলিকে ব্যবহারকারীর সম্মতি ছাড়া ব্যক্তিগত ডেটাতে অ্যাক্সেস পেতে বাধা দেয় এবং অ্যাপগুলি যে ধরণের অনুমতিগুলি চাচ্ছে বা দেওয়া হয়েছে সেগুলির অতিরিক্ত প্রসঙ্গ এবং দৃশ্যমানতা প্রদান করে৷ রানটাইম মডেলটি ডেভেলপারদের উৎসাহিত করে যাতে ব্যবহারকারীদের বুঝতে সাহায্য করে যে কেন অ্যাপগুলির অনুরোধ করা অনুমতিগুলির প্রয়োজন, এবং আরও বেশি স্বচ্ছতা প্রদান করে যাতে ব্যবহারকারীরা সেগুলি মঞ্জুর বা অস্বীকার করার বিষয়ে আরও ভাল সিদ্ধান্ত নিতে পারে৷
প্রভাবিত অনুমতি
Android 6.0 এবং উচ্চতর একটি রানটাইম অনুমতি মডেল ব্যবহার করার জন্য বিপজ্জনক অনুমতি প্রয়োজন। বিপজ্জনক অনুমতিগুলি হল উচ্চ-ঝুঁকির অনুমতি (যেমন READ_CALENDAR ) যা অনুরোধকারী অ্যাপগুলিকে ব্যক্তিগত ব্যবহারকারীর ডেটাতে অ্যাক্সেস দেয়, বা কোনও ডিভাইসের উপর নিয়ন্ত্রণ করে, যা ব্যবহারকারীকে নেতিবাচকভাবে প্রভাবিত করতে পারে। বিপজ্জনক অনুমতিগুলির একটি তালিকা দেখতে, কমান্ডটি চালান:
adb shell pm list permissions -g -d
অ্যান্ড্রয়েড 6.0 এবং উচ্চতর সাধারণ অনুমতির আচরণ পরিবর্তন করে না। এগুলি স্বাভাবিক, সিস্টেম এবং স্বাক্ষর অনুমতি সহ সমস্ত অ-বিপজ্জনক অনুমতি৷ সাধারণ অনুমতিগুলি হল নিম্ন-ঝুঁকির অনুমতি (যেমন SET_WALLPAPER ) যা অনুরোধকারী অ্যাপগুলিকে অন্যান্য অ্যাপ, সিস্টেম বা ব্যবহারকারীর জন্য ন্যূনতম ঝুঁকি সহ বিচ্ছিন্ন অ্যাপ-স্তরের বৈশিষ্ট্যগুলিতে অ্যাক্সেস দেয়। অ্যান্ড্রয়েড 5.1 এবং নিম্ন রিলিজের মতো, সিস্টেমটি স্বয়ংক্রিয়ভাবে ইনস্টলেশনের সময় একটি অনুরোধকারী অ্যাপকে স্বাভাবিক অনুমতি দেয় এবং ব্যবহারকারীকে অনুমোদনের জন্য অনুরোধ করে না। অনুমতির বিস্তারিত জানার জন্য, <permission> উপাদান ডকুমেন্টেশন দেখুন।
অ্যান্ড্রয়েড 10 এ হার্ড এবং নরম সীমাবদ্ধতা
বিপজ্জনক হওয়ার পাশাপাশি, একটি অনুমতি কঠিন-সীমাবদ্ধ বা নরম-সীমাবদ্ধ হতে পারে। উভয় ক্ষেত্রেই, সীমাবদ্ধ অনুমতি অবশ্যই অনুমোদিত তালিকাভুক্ত হতে হবে। অ-অনুমোদিত হার্ড বিধিনিষেধ অ-অনুমোদিত সফ্ট বিধিনিষেধের চেয়ে ভিন্নভাবে আচরণ করে:
- ( হার্ড সীমাবদ্ধতা ) অ্যাপ্লিকেশানগুলিকে অনুমতি দেওয়া যাবে না যেগুলি অনুমোদিত তালিকাভুক্ত নয়৷
- ( নরম বিধিনিষেধ ) অ্যাপ্লিকেশানগুলিকে অনুমতি ছাড়াই তারা অনুরোধ করা নির্দিষ্ট অনুমতি অনুযায়ী আচরণ করে৷ অনুরোধ করা অনুমতির জন্য আচরণটি পাবলিক ডকুমেন্টেশনে বর্ণনা করা হয়েছে।
একটি অ্যাপ ইনস্টল করার সময়, ইনস্টলার (যেমন Google Play Store) অ্যাপের জন্য সীমাবদ্ধ অনুমতিগুলিকে অনুমতি না দেওয়ার জন্য নির্বাচন করতে পারে। অনুমতিগুলি প্ল্যাটফর্ম দ্বারা সীমাবদ্ধ এবং শুধুমাত্র যদি একটি অ্যাপ প্ল্যাটফর্ম নীতি অনুযায়ী বিশেষ মানদণ্ড পূরণ করে তবেই মঞ্জুর করা যায়। কঠোর-সীমাবদ্ধ অনুমতি প্রকারের উদাহরণগুলির মধ্যে SMS এবং কল লগ অনুমতি অন্তর্ভুক্ত।
ইনস্টলেশনের সময় এবং কখন অনুমতি দেওয়া হয়
- Android 9-to-10 আপগ্রেডের সময় একটি অ্যাপ ইতিমধ্যেই ইনস্টল করা আছে।
- একটি অনুমতি আগে থেকে দেওয়া আছে বা একটি অ্যাপ আগে থেকে ইনস্টল করা আছে।
- অনুমতি তালিকাভুক্ত করার জন্য ইতিমধ্যেই সংজ্ঞায়িত একটি ভূমিকার জন্য একটি অনুমতি প্রয়োজন৷
- ইনস্টলার (যেমন Google Play Store) অনুমতিটিকে অনুমোদিত তালিকাভুক্ত হিসাবে চিহ্নিত করে৷
ব্যবহারকারীরা ম্যানুয়ালি অনুমতি তালিকাভুক্ত করতে পারবেন না।
প্রয়োজনীয়তা
রানটাইম পারমিশন মডেলটি সেটআপ প্রক্রিয়ার অংশ হিসাবে ডিভাইসে প্রি-ইনস্টল করা অ্যাপস এবং অ্যাপস সহ সমস্ত অ্যাপের ক্ষেত্রে প্রযোজ্য। অ্যাপ সফ্টওয়্যার প্রয়োজনীয়তা অন্তর্ভুক্ত:
- রানটাইম অনুমতি মডেল অবশ্যই Android 6.0 এবং উচ্চতর সংস্করণে চলমান সমস্ত ডিভাইস জুড়ে সামঞ্জস্যপূর্ণ হতে হবে। এটি অ্যান্ড্রয়েড কম্প্যাটিবিলিটি টেস্ট স্যুট (সিটিএস) পরীক্ষা দ্বারা প্রয়োগ করা হয়।
- অ্যাপ্লিকেশানগুলি অবশ্যই ব্যবহারকারীদের রানটাইমে অ্যাপের অনুমতি দেওয়ার জন্য অনুরোধ করবে৷ বিস্তারিত জানার জন্য, অ্যাপ আপডেট করুন দেখুন। ডিভাইসের প্রত্যাশিত অপারেশনের জন্য মৌলিক ডিভাইস কার্যকারিতা প্রদান করে এমন ডিফল্ট অ্যাপ এবং হ্যান্ডলারদের সীমিত ব্যতিক্রম মঞ্জুর করা যেতে পারে। (উদাহরণস্বরূপ,
ACTION_CALLপরিচালনার জন্য ডিভাইসের ডিফল্ট ডায়ালার অ্যাপে ফোন অনুমতির অ্যাক্সেস থাকতে পারে।) বিস্তারিত জানার জন্য, ব্যতিক্রম তৈরি করা দেখুন। - বিপজ্জনক অনুমতি রয়েছে এমন প্রিলোড করা অ্যাপগুলিকে অবশ্যই API স্তর 23 টার্গেট করতে হবে এবং রানটাইম অনুমতি মডেল বজায় রাখতে হবে। অর্থাৎ, অ্যাপ ইনস্টলেশনের সময় UI ফ্লো অবশ্যই পারমিশন কন্ট্রোলারের AOSP বাস্তবায়ন থেকে বিচ্যুত হবে না, ব্যবহারকারীরা আগে থেকে ইনস্টল করা অ্যাপগুলির বিপজ্জনক অনুমতি প্রত্যাহার করতে পারেন, ইত্যাদি।
- হেডলেস অ্যাপগুলিকে অনুমতির অনুরোধ করতে বা প্রয়োজনীয় অনুমতি আছে এমন অন্য অ্যাপের সাথে একটি UID শেয়ার করতে একটি কার্যকলাপ ব্যবহার করতে হবে। বিস্তারিত জানার জন্য, হেডলেস অ্যাপস দেখুন।
পারমিশন মাইগ্রেশন
Android 5.x-এ অ্যাপ্লিকেশানগুলিতে প্রদত্ত অনুমতিগুলি Android 6.0 বা উচ্চতর সংস্করণে আপডেট করার পরেও মঞ্জুর করা হয়, তবে ব্যবহারকারীরা যে কোনও সময় সেই অনুমতিগুলি প্রত্যাহার করতে পারেন৷
একটি অ্যান্ড্রয়েড 9-থেকে-10 আপডেটে, সমস্ত কঠোর-সীমাবদ্ধ অনুমতি অনুমোদিত তালিকাভুক্ত হয়। ফোরগ্রাউন্ড/ব্যাকগ্রাউন্ড স্প্লিট পারমিশন বাস্তবায়নের বিস্তারিত জানার জন্য, Android 10 গোপনীয়তা পরিবর্তন দেখুন, পটভূমি অবস্থানের অনুরোধের সাথে শুরু করুন।
মিশ্রণ
অ্যান্ড্রয়েড 6.0 এবং উচ্চতর সংস্করণের জন্য অ্যাপ রানটাইম পারমিশন মডেলকে ইন্টিগ্রেট করার সময়, নতুন মডেলের সাথে কাজ করার জন্য আপনাকে অবশ্যই আগে থেকে ইনস্টল করা অ্যাপ আপডেট করতে হবে। আপনি মূল কার্যকারিতার জন্য ডিফল্ট হ্যান্ডলার/প্রোভাইডার অ্যাপগুলির জন্য ব্যতিক্রমগুলিও সংজ্ঞায়িত করতে পারেন, কাস্টম অনুমতিগুলি সংজ্ঞায়িত করতে পারেন এবং PermissionController অ্যাপে ব্যবহৃত থিমটি কাস্টমাইজ করতে পারেন৷
অ্যাপস আপডেট করুন
সিস্টেম ইমেজে থাকা অ্যাপ এবং প্রিইন্সটল করা অ্যাপগুলি স্বয়ংক্রিয়ভাবে আগে থেকে দেওয়া অনুমতি নয়। ডেভেলপার নির্দেশিকা ব্যবহার করে প্রয়োজনীয় অ্যাপ পরিবর্তন করতে আমরা আপনাকে পূর্ব-ইন্সটল করা অ্যাপ ডেভেলপারদের (OEM, ক্যারিয়ার, এবং তৃতীয় পক্ষ) সাথে কাজ করতে উৎসাহিত করি। বিশেষত, আপনাকে নিশ্চিত করতে হবে যে ব্যবহারকারীরা অনুমতি প্রত্যাহার করলে ক্র্যাশ এবং অন্যান্য সমস্যা এড়াতে আগে থেকে ইনস্টল করা অ্যাপগুলি সংশোধন করা হয়েছে।
প্রিলোড করা অ্যাপস
অ্যান্ড্রয়েড 9 এবং তার চেয়ে কম সময়ে, বিপজ্জনক অনুমতি ব্যবহার করে এমন প্রিলোড করা অ্যাপগুলিকে অবশ্যই API স্তর 23 বা উচ্চতর টার্গেট করতে হবে এবং Android 6.0 এবং উচ্চতর AOSP অনুমতি মডেল বজায় রাখতে হবে। উদাহরণস্বরূপ, একটি অ্যাপ ইনস্টলেশনের সময় UI প্রবাহটি PermissionController এর AOSP বাস্তবায়ন থেকে বিচ্যুত হওয়া উচিত নয়। এমনকি ব্যবহারকারীরা আগে থেকে ইনস্টল করা অ্যাপের বিপজ্জনক অনুমতি প্রত্যাহার করতে পারেন।
অ্যান্ড্রয়েড 6.0 থেকে 9-এ, ইনস্টল প্রবাহের সময় কিছু অনুমতি দেওয়া হয়। যাইহোক, 10 থেকে শুরু করে, ইনস্টল ফ্লো ( Package Installer অ্যাপ দ্বারা সঞ্চালিত) অনুমতি প্রদানের থেকে একটি পৃথক ফাংশন ( Permission Controller অ্যাপে)।
মাথাবিহীন অ্যাপস
শুধুমাত্র কার্যকলাপ অনুমতি অনুরোধ করতে পারেন. পরিষেবাগুলি সরাসরি অনুমতির জন্য অনুরোধ করতে পারে না৷
- অ্যান্ড্রয়েড 5.1 এবং তার আগের সংস্করণে, হেডলেস অ্যাপগুলি ইনস্টল করার সময় অনুমতির জন্য অনুরোধ করতে পারে, বা যদি সেগুলি কোনও কার্যকলাপ ব্যবহার না করেই আগে থেকে ইনস্টল করা থাকে।
- অ্যান্ড্রয়েড 6.0 এবং উচ্চতর সংস্করণে, হেডলেস অ্যাপগুলিকে অনুমতির অনুরোধ করতে নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটি ব্যবহার করতে হবে:
- অনুমতির অনুরোধ করতে একটি কার্যকলাপ যোগ করুন। (এই পছন্দের পদ্ধতি.)
- প্রয়োজনীয় অনুমতি আছে এমন অন্য অ্যাপের সাথে একটি UID শেয়ার করুন। এই পদ্ধতিটি শুধুমাত্র তখনই ব্যবহার করুন যখন আপনার একাধিক APK একটি একক অ্যাপ হিসেবে পরিচালনা করার জন্য প্ল্যাটফর্মের প্রয়োজন হয়।
লক্ষ্য হল অনুমতির অনুরোধের সাথে ব্যবহারকারীদের বিভ্রান্ত করা এড়ানো যা প্রেক্ষাপটের বাইরে প্রদর্শিত হয়।
PackageInstaller UI কাস্টমাইজ করুন
যদি ইচ্ছা হয়, আপনি প্যাকেজইনস্টলার দ্বারা ব্যবহৃত ডিফল্ট ডিভাইস থিমগুলি ( Theme.DeviceDefault.Settings এবং Theme.DeviceDefault.Light.Dialog.NoActionBar ) আপডেট করে অনুমতি UI থিম কাস্টমাইজ করতে পারেন৷ যাইহোক, যেহেতু অ্যাপ ডেভেলপারদের জন্য ধারাবাহিকতা গুরুত্বপূর্ণ, আপনি অনুমতি UI কখন প্রদর্শিত হবে তার স্থান নির্ধারণ, অবস্থান এবং নিয়ম কাস্টমাইজ করতে পারবেন না।
অতিরিক্ত ভাষার জন্য স্ট্রিং অন্তর্ভুক্ত করতে, AOSP-এ স্ট্রিংগুলিকে অবদান রাখুন।
ব্যতিক্রম তৈরি করুন
আপনি প্যাকেজম্যানেজারে DefaultPermissionGrantPolicy.java ক্লাস ব্যবহার করে মূল OS কার্যকারিতার জন্য ডিফল্ট হ্যান্ডলার বা প্রদানকারী অ্যাপগুলিকে প্রাক-অনুমতি দিতে পারেন। উদাহরণ:
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
কাস্টম অনুমতি সংজ্ঞায়িত করুন
আপনি কাস্টম অনুমতি এবং গোষ্ঠীগুলিকে স্বাভাবিক বা বিপজ্জনক হিসাবে সংজ্ঞায়িত করতে পারেন এবং বিদ্যমান অনুমতি গোষ্ঠীগুলিতে OEM/ক্যারিয়ার-নির্দিষ্ট অনুমতি যোগ করতে পারেন, ঠিক যেমন আপনি Android 5.x এবং পূর্ববর্তী প্রকাশগুলিতে করতে পারেন৷
অ্যান্ড্রয়েড 6.0 এবং পরবর্তীতে, আপনি যদি একটি নতুন বিপজ্জনক অনুমতি যোগ করেন তবে এটি অবশ্যই অন্যান্য বিপজ্জনক অনুমতিগুলির মতোই পরিচালনা করতে হবে (অ্যাপ রানটাইমের সময় অনুরোধ করা হয়েছিল এবং ব্যবহারকারীদের দ্বারা প্রত্যাহারযোগ্য)৷ বিশেষভাবে:
- আপনি একটি বর্তমান গ্রুপে নতুন অনুমতি যোগ করতে পারেন, কিন্তু আপনি বিপজ্জনক অনুমতি এবং বিপজ্জনক অনুমতি গোষ্ঠীর AOSP ম্যাপিং পরিবর্তন করতে পারবেন না। (অন্য কথায়, আপনি একটি গ্রুপ থেকে একটি অনুমতি সরাতে এবং অন্য গ্রুপে বরাদ্দ করতে পারবেন না)।
- আপনি ডিভাইসে ইনস্টল করা অ্যাপগুলিতে নতুন অনুমতি গ্রুপ যোগ করতে পারেন, কিন্তু আপনি প্ল্যাটফর্ম ম্যানিফেস্টে নতুন অনুমতি গোষ্ঠী যোগ করতে পারবেন না।
পরীক্ষার অনুমতি
অ্যান্ড্রয়েডে সামঞ্জস্য পরীক্ষা স্যুট (সিটিএস) পরীক্ষা রয়েছে যা যাচাই করে যে পৃথক অনুমতিগুলি সঠিক গোষ্ঠীতে ম্যাপ করা হয়েছে। এই পরীক্ষাগুলি পাস করা Android 6.0 এবং পরবর্তী CTS সামঞ্জস্যের জন্য প্রয়োজনীয়।
অনুমতি প্রত্যাহার করুন
Android 13 এবং পরবর্তীতে, আপনি Context.revokeSelfPermissionsOnKill() ব্যবহার করে আপনার নিজের দেওয়া রানটাইম অনুমতি প্রত্যাহার করতে পারবেন। প্রত্যাহারটি অ্যাসিঙ্ক্রোনাসভাবে ঘটে এবং ব্যবহারকারীকে ব্যাহত না করে এটি করা নিরাপদ হলে ট্রিগার হয়৷ প্রত্যাহার ট্রিগার করা হলে, কলিং ইউআইডি-তে চলমান সমস্ত প্রক্রিয়া বন্ধ হয়ে যায়।
এটা বোঝা গুরুত্বপূর্ণ যে একটি একক অনুমতি প্রত্যাহার করা সেটিংস UI-তে প্রতিফলিত নাও হতে পারে, যা গোষ্ঠী অনুসারে অনুমতিগুলিকে বিবেচনা করে৷ সাধারণত, একটি অনুমতি গোষ্ঠী প্রদর্শিত হয় যতক্ষণ না সেই গোষ্ঠীর অন্তত একটি অনুমতি দেওয়া হয়। ব্যবহারকারীরা সেটিংসে প্রত্যাহার নিশ্চিত করতে সক্ষম কিনা তা নিশ্চিত করা আপনার জন্য গুরুত্বপূর্ণ হলে, অনুমতি গোষ্ঠীর প্রতিটি অনুমতি প্রত্যাহার করতে ভুলবেন না। একটি নির্দিষ্ট গোষ্ঠীর কোন অনুমতিগুলি তা জানতে, আপনি PackageManager.getGroupOfPlatformPermission এবং PackageManager.getPlatformPermissionsForGroup ব্যবহার করতে পারেন।
যখন সিস্টেম অনুরোধ করা অনুমতিগুলি প্রত্যাহার করে, তখন এটি সংশ্লিষ্ট পটভূমি অনুমতিগুলিও প্রত্যাহার করে যদি তাদের সংশ্লিষ্ট ফোরগ্রাউন্ড অনুমতিগুলি এখনও মঞ্জুর করা না হয়।
যতক্ষণ প্রক্রিয়াটি অগ্রভাগে থাকে ততক্ষণ প্রত্যাহারটি ট্রিগার করা হয় না তবে বর্তমান uid-এ চলমান সমস্ত প্রক্রিয়া ম্যানুয়ালি হত্যা করে, উদাহরণস্বরূপ System.exit() ব্যবহার করে সরাসরি ট্রিগার করা যেতে পারে। তবে কখন এটি ট্রিগার করতে হবে তা সিস্টেমকে সিদ্ধান্ত নেওয়ার পরামর্শ দেওয়া হয়।
একটি অনুমতি প্রত্যাহার কার্যকর হওয়ার পরে, আপনি এটি আবার অনুরোধ করতে সক্ষম হবেন এবং ব্যবহারকারীকে অনুরোধটি মঞ্জুর বা অস্বীকার করার জন্য অনুরোধ করা হবে৷ ব্যবহারকারীর দ্বারা পূর্বে অস্বীকার করা অনুমতির অনুরোধ করা সম্ভব নয়৷ যখন আপনি বর্তমানে আপনার কাছে থাকা অনুমতিগুলি প্রত্যাহার করার জন্য উত্সাহিত করা হয় তবে আর প্রয়োজন নেই, আপনার সতর্কতা অবলম্বন করা উচিত যে এটি কার্যকর না হওয়া পর্যন্ত প্রত্যাহার সম্পর্কে ব্যবহারকারীকে অবহিত করবেন না।