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