একটি কাস্টম অ্যাপ্লিকেশন অনুমতি সংজ্ঞায়িত করুন

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

পটভূমি

অ্যান্ড্রয়েড একটি প্রিভিলেজ-সেপারেটেড অপারেটিং সিস্টেম, যেখানে প্রতিটি অ্যাপ একটি স্বতন্ত্র সিস্টেম আইডেন্টিটি (লিনাক্স ইউজার আইডি এবং গ্রুপ আইডি) নিয়ে চলে। সিস্টেমের অংশগুলোও স্বতন্ত্র আইডেন্টিটিতে বিভক্ত থাকে। এর মাধ্যমে লিনাক্স অ্যাপগুলোকে একে অপরের থেকে এবং সিস্টেম থেকে বিচ্ছিন্ন রাখে।

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

অ্যাপ সাইনিং

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

ডিভাইস তৈরির সময়ের পরে স্বাক্ষরের অনুমতি দিন।

অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) থেকে, সিগনেচার-লেভেল পারমিশনের জন্য knownCerts অ্যাট্রিবিউটটি আপনাকে ডিক্লারেশনের সময় পরিচিত সাইনিং সার্টিফিকেটগুলোর ডাইজেস্ট উল্লেখ করার সুযোগ দেয়।

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

knownSigner ফ্ল্যাগটি ডিভাইস এবং অ্যাপগুলোকে ডিভাইস উৎপাদন ও প্রেরণের সময় অ্যাপগুলোকে স্বাক্ষর না করেই অন্যান্য অ্যাপকে স্বাক্ষরের অনুমতি দেওয়ার সুযোগ দেয়।

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

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

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

কোনো অ্যাপ দ্বারা সংরক্ষিত ডেটাকে সেই অ্যাপের ইউজার আইডি দেওয়া হয় এবং তা সাধারণত অন্য প্যাকেজগুলোর কাছে অ্যাক্সেসযোগ্য থাকে না।

অ্যান্ড্রয়েডের নিরাপত্তা মডেল সম্পর্কে আরও তথ্যের জন্য, অ্যান্ড্রয়েড নিরাপত্তা ওভারভিউ দেখুন।

অনুমতি নির্ধারণ ও প্রয়োগ করুন

আপনার নিজের অনুমতিগুলো প্রয়োগ করতে হলে, আপনাকে প্রথমে আপনার 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> এলিমেন্ট ব্যবহার করে আপনার অ্যাপগুলোর জন্য কাস্টম পারমিশন নির্ধারণ করতে পারেন এবং অন্যান্য অ্যাপ থেকেও কাস্টম পারমিশন চাইতে পারেন। তবে, এমনটা করা প্রয়োজনীয় কিনা, তা সতর্কতার সাথে মূল্যায়ন করুন।

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

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