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

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

পটভূমি

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

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

অ্যাপ সাইনিং

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

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

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

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

knownSigner ফ্ল্যাগ ডিভাইস এবং অ্যাপগুলিকে ডিভাইস উত্পাদন এবং চালানের সময় অ্যাপগুলিতে স্বাক্ষর না করেই অন্যান্য অ্যাপগুলিতে স্বাক্ষর করার অনুমতি দেয়৷

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

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

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

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

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

সতর্কতা: প্রতিটি প্যাকেজের জন্য AndroidManifest.xml ফাইলের <manifest> ট্যাগে sharedUserId বৈশিষ্ট্যটি একাধিক প্যাকেজ একই ব্যবহারকারী আইডি বরাদ্দ করতে ব্যবহার করা যেতে পারে। যাইহোক, শেয়ার্ড ইউজার আইডি প্যাকেজ ম্যানেজারের মধ্যে অ-নির্ধারণমূলক আচরণ সৃষ্টি করে। যেমন, তাদের ব্যবহারকে দৃঢ়ভাবে নিরুৎসাহিত করা হয়েছে এবং Android এর ভবিষ্যত সংস্করণে সরানো হতে পারে৷ পরিবর্তে, অ্যাপগুলিকে শেয়ার করা উপাদানগুলির মধ্যে আন্তঃকার্যক্ষমতা সহজতর করার জন্য পরিষেবা এবং সামগ্রী প্রদানকারীর মতো সঠিক যোগাযোগ ব্যবস্থা ব্যবহার করা উচিত। মনে রাখবেন যে বিদ্যমান অ্যাপগুলি এই মানটি সরাতে পারে না, কারণ শেয়ার করা ব্যবহারকারী আইডি থেকে স্থানান্তর করা সমর্থিত নয়৷

অনুমতি সংজ্ঞায়িত করুন এবং প্রয়োগ করুন

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

নামকরণের রীতি

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

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

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

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

সম্পর্কে পড়া চালিয়ে যান:

<uses-permission>

ম্যানিফেস্ট ট্যাগের জন্য API রেফারেন্স যা আপনার অ্যাপের প্রয়োজনীয় সিস্টেম অনুমতিগুলি ঘোষণা করে৷

এছাড়াও আপনি আগ্রহী হতে পারে:

অ্যান্ড্রয়েড নিরাপত্তা ওভারভিউ

অ্যান্ড্রয়েড প্ল্যাটফর্মের নিরাপত্তা মডেল সম্পর্কে বিস্তারিত আলোচনা।