অ্যাপকে দেওয়া কাস্টম অনুমতি নির্ধারণ করুন

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

ব্যাকগ্রাউন্ড

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

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

অ্যাপ সাইনিং

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

ডিভাইস তৈরির সময়ের পরে সিগনেচার সংক্রান্ত অনুমতি দিন

Android 12 (API লেভেল 31) থেকে শুরু করে, সিগনেচার-লেভেল অনুমতির জন্য knownCerts অ্যাট্রিবিউট আপনাকে ঘোষণার সময়ে পরিচিত সাইনিং সার্টিফিকেটের ডাইজেস্ট রেফার করতে দেয়।

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

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

ব্যবহারকারীর আইডি ও ফাইল অ্যাক্সেস

ইনস্টল করার সময়, Android প্রতিটি প্যাকেজকে একটি স্বতন্ত্র Linux ব্যবহারকারী আইডি দেয়। সেই ডিভাইসে প্যাকেজের লাইফটাইম চলাকালীন পরিচয় একই থাকে। অন্য ডিভাইসে, একই প্যাকেজের আলাদা UID থাকতে পারে—গুরুত্বপূর্ণ হল, প্রদত্ত ডিভাইসে প্রতিটি প্যাকেজের আলাদা UID আছে।

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

কোনও অ্যাপের মাধ্যমে স্টোর করা যেকোনও ডেটা সেই অ্যাপের ব্যবহারকারীর আইডিতে অ্যাসাইন করা হয় এবং সাধারণত অন্যান্য প্যাকেজ তা অ্যাক্সেস করতে পারে না।

Android-এর নিরাপত্তা মডেল সম্পর্কে আরও জানতে, Android নিরাপত্তা ওভারভিউ দেখুন।

অনুমতি নির্ধারণ ও এনফোর্স করা

আপনার নিজের অনুমতি এনফোর্স করতে, আপনাকে প্রথমে আপনার AndroidManifest.xml-এ এক বা একাধিক <permission> এলিমেন্ট ব্যবহার করে সেগুলি ঘোষণা করতে হবে।

নামকরণ কনভেনশন

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

আমরা সাজেস্ট করি যে, অ্যাপের প্যাকেজের নামের সাথে প্রিফিক্স হিসেবে অনুমতি যোগ করুন, রিভার্স-ডোমেন-স্টাইল নাম ব্যবহার করে, তারপরে .permission. এবং তারপরে অনুমতি যে ক্ষমতার প্রতিনিধিত্ব করে তার বিবরণ, আপার SNAKE_CASE-এ। যেমন, com.example.myapp.permission.ENGAGE_HYPERSPACE।

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

উদাহরণ

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

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

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

android:permissionGroup অ্যাট্রিবিউটটি ঐচ্ছিক এবং শুধুমাত্র ব্যবহারকারীকে সিস্টেম ডিসপ্লে সংক্রান্ত অনুমতি দেখানোর জন্য ব্যবহার করা হয়। বেশিরভাগ ক্ষেত্রে, আপনি এটি একটি স্ট্যান্ডার্ড সিস্টেম গ্রুপে সেট করেন (android.Manifest.permission_group-এ তালিকাভুক্ত), যদিও আপনি নিজেই একটি গ্রুপ সংজ্ঞায়িত করতে পারেন, যেমনটি নিম্নলিখিত বিভাগে বর্ণনা করা হয়েছে। আমরা আগে থেকে থাকা গ্রুপ ব্যবহার করার সাজেশন দিই, কারণ এটি ব্যবহারকারীকে দেখানো অনুমতি UI-কে সহজ করে তোলে।

অনুমতির জন্য আপনাকে লেবেল ও বিবরণ, দুটিই দিতে হবে। এগুলি হল স্ট্রিং রিসোর্স যা ব্যবহারকারী দেখতে পান যখন তিনি অনুমতির তালিকা (android:label) অথবা কোনও একটি অনুমতির বিবরণ (android:description) দেখেন। লেবেলটি ছোট: কয়েকটি শব্দে সেই মূল কার্যকারিতা বর্ণনা করা হয় যা অনুমতিটি সুরক্ষিত করছে। বিবরণ হল দুটি বাক্য যা বর্ণনা করে যে অনুমতিটি একজন হোল্ডারকে কী করতে দেয়। আমাদের কনভেনশন হল একটি দুই-বাক্যের বিবরণ যেখানে প্রথম বাক্যটি অনুমতি বর্ণনা করে এবং দ্বিতীয় বাক্যটি ব্যবহারকারীকে সেই ধরনের জিনিস সম্পর্কে সতর্ক করে যা কোনও অ্যাপকে অনুমতি দেওয়া হলে ভুল হতে পারে।

CALL_PHONE অনুমতির জন্য লেবেল ও বিবরণের একটি উদাহরণ এখানে দেওয়া হল:

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

পারমিশন গ্রুপ তৈরি করা

আগের বিভাগে যেমন দেখানো হয়েছে, আপনি android:permissionGroup অ্যাট্রিবিউট ব্যবহার করে সিস্টেমকে সাহায্য করতে পারেন যাতে সেটি ব্যবহারকারীকে অনুমতি সম্পর্কে বর্ণনা করতে পারে। বেশিরভাগ ক্ষেত্রে, আপনি এটি একটি স্ট্যান্ডার্ড সিস্টেম গ্রুপে সেট করেন (android.Manifest.permission_group-এ তালিকাভুক্ত), তবে আপনি <permission-group>-এর মাধ্যমে আপনার নিজস্ব গ্রুপও সংজ্ঞায়িত করতে পারেন।

<permission-group> এলিমেন্টটি অনুমতির একটি সেটের জন্য একটি লেবেল সংজ্ঞায়িত করে—উভয়ই ম্যানিফেস্টে <permission> এলিমেন্ট সহ এবং অন্য কোথাও ঘোষিত। ব্যবহারকারীকে দেখানোর সময় অনুমতিগুলি কীভাবে গ্রুপ করা হয়, এটি শুধুমাত্র তার উপর প্রভাব ফেলে। <permission-group> এলিমেন্ট গ্রুপের সাথে সম্পর্কিত অনুমতি নির্দিষ্ট করে না, তবে এটি গ্রুপকে একটি নাম দেয়।

আপনি গ্রুপের নাম <permission> এলিমেন্টের permissionGroup অ্যাট্রিবিউটে অ্যাসাইন করে গ্রুপে অনুমতি দিতে পারেন।

<permission-tree> এলিমেন্ট, কোডে সংজ্ঞায়িত করা অনুমতির গ্রুপের জন্য নেমস্পেস ঘোষণা করে।

কাস্টম অনুমতি সংক্রান্ত সাজেশন

আপনি নিজের অ্যাপের জন্য কাস্টম অনুমতি নির্ধারণ করতে পারেন এবং <uses-permission> এলিমেন্ট নির্ধারণ করে অন্যান্য অ্যাপ থেকে কাস্টম অনুমতির জন্য অনুরোধ করতে পারেন। তবে, এটি করা প্রয়োজন কিনা তা ভালভাবে মূল্যায়ন করুন।

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

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