AndroidManifest.xml — এটি কী, প্রধান উপাদান এবং ম্যানিফেস্ট কনফিগারেশন

AndroidManifest.xml কী

AndroidManifest.xml হল একটি রুট কনফিগারেশন ফাইল XML ফরম্যাটে, যা প্রতিটি Android প্রকল্পকে app/src/main ডিরেক্টরিতে রাখতে বাধ্য। Android সিস্টেম যেকোনো অ্যাপ্লিকেশন কোড চালানোর আগে এটি বিশ্লেষণ করে — APK পার্সিংয়ের সময় ইনস্টলেশনের ধাপে। যদি ম্যানিফেস্টে সিনট্যাক্স ত্রুটি থাকে বা বাধ্যতামূলক ঘোষণা অনুপস্থিত থাকে, তাহলে ইনস্টলেশন ত্রুটির বার্তা সহ বাতিল হয়।

ফাইলটিতে অ্যাপ্লিকেশনের সম্পূর্ণ ঘোষণা থাকে: সমস্ত উপাদানের তালিকা (Activity, Service, BroadcastReceiver, ContentProvider), অনুরোধকৃত অনুমতি, ন্যূনতম SDK সংস্করণ, হার্ডওয়্যার প্রয়োজনীয়তা এবং থিম ও স্টাইলের কনফিগারেশন। প্রতিটি উপাদান যা সিস্টেম বা অন্যান্য অ্যাপ্লিকেশন দ্বারা কল করা যেতে পারে, তা ম্যানিফেস্টে স্পষ্টভাবে ঘোষণা করা আবশ্যক। এটি একটি নিরাপত্তা প্রয়োজনীয়তা: স্পষ্ট ঘোষণা ছাড়া উপাদান কল করার জন্য অনুপলব্ধ।

সঠিকভাবে কনফিগার করা ম্যানিফেস্ট ছাড়া অ্যাপ্লিকেশন Google Play বা sideloading-এর মাধ্যমে ইনস্টল করা যায় না। সিস্টেম APK পার্সিংয়ের ধাপে ম্যানিফেস্ট পরীক্ষা করে এবং ত্রুটির ক্ষেত্রে ইনস্টলেশন প্রত্যাখ্যান করে। Google Playও ম্যানিফেস্ট স্ক্যান করে অনিরাপদ কনফিগারেশনের জন্য: exported=true থাকলে intent-filter ছাড়া উপাদানে সতর্কতা জারি করে, এবং targetSdk 34+-এর জন্য বাধ্যতামূলক অনুমতি না থাকলে প্রকাশনা ব্লক হয়। তাই ম্যানিফেস্টের কাঠামো বোঝা Android-ডেভেলপারের জন্য আবশ্যক দক্ষতা।

ম্যানিফেস্টে অ্যাপ্লিকেশনের উপাদান

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

Activity

activity ট্যাগ অ্যাপ্লিকেশনের স্ক্রিন নিবন্ধন করে। exported অ্যাট্রিবিউট নির্ধারণ করে অন্যান্য অ্যাপ্লিকেশন এই Activity চালু করতে পারে কিনা। Android 12 থেকে, intent-filter থাকা সত্ত্বেও exported না থাকলে বিল্ড ত্রুটি ঘটে — এটি একটি নিরাপত্তা প্রয়োজনীয়তা। এন্ট্রি পয়েন্ট action MAIN এবং category LAUNCHER সহ intent-filter-এর মাধ্যমে নির্ধারিত হয়। প্রতিটি Activity-এর অনন্য android:name থাকতে হবে, যা পূর্ণ বা আপেক্ষিক ক্লাস নামের সাথে সঙ্গতিপূর্ণ।

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:windowSoftInputMode="adjustResize">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Service

service ট্যাগ ব্যাকগ্রাউন্ড সার্ভিস নির্ধারণ করে। Android 8 থেকে, ব্যাকগ্রাউন্ড সার্ভিসের কঠোর সীমাবদ্ধতা রয়েছে: foreground service-এর জন্য আইকন সহ বাধ্যতামূলক নোটিফিকেশন প্রয়োজন যা ব্যবহারকারীর কাছে দৃশ্যমান, এবং bound service শুধুমাত্র সংশ্লিষ্ট ক্লায়েন্ট থাকা অবস্থায় কাজ করে। নোটিফিকেশন ছাড়া ব্যাকগ্রাউন্ডে চলা সার্ভিসগুলি অ্যাপ্লিকেশন ব্যাকগ্রাউন্ড মোডে যাওয়ার কয়েক মিনিট পরে সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে বন্ধ হয়। দীর্ঘস্থায়ী কাজের জন্য Service-এর পরিবর্তে WorkManager ব্যবহার করুন।

<service
    android:name=".SyncService"
    android:exported="false"
    android:foregroundServiceType="dataSync" />

BroadcastReceiver

receiver ট্যাগ সিস্টেম বা কাস্টম ব্রডকাস্ট বার্তার রিসিভার ঘোষণা করে। Android 8 থেকে, বেশিরভাগ অন্তর্নিহিত ব্রডকাস্ট আর ম্যানিফেস্টে স্থিরভাবে ঘোষিত রিসিভারগুলিতে বিতরণ করা হয় না। পরিবর্তে, কোডে Context.registerReceiver-এর মাধ্যমে গতিশীলভাবে রিসিভার নিবন্ধন করার পরামর্শ দেওয়া হয়। ব্যতিক্রম是一些 সিস্টেম ব্রডকাস্ট, যেমন BOOT_COMPLETED, যেগুলির জন্য এখনও ম্যানিফেস্টে স্থির নিবন্ধন প্রয়োজন।

<receiver
    android:name=".ConnectivityReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

Android-এ অনুমতি (Permissions)

Android-এ প্রতিটি বিপজ্জনক অনুমতির জন্য ম্যানিফেস্টে uses-permission ট্যাগের মাধ্যমে ঘোষণা প্রয়োজন। Android 6 থেকে, বিপজ্জনক অনুমতি ব্যবহারকারীর সাথে ডায়ালগের মাধ্যমে রানটাইমে অনুরোধ করা হয়, কিন্তু ম্যানিফেস্টে ঘোষণা বাধ্যতামূলক থাকে। এটি ছাড়া requestPermissions মেথড SecurityException ব্যতিক্রম ছুঁড়ে। সাধারণ স্তরের অনুমতি, যেমন INTERNET এবং ACCESS_NETWORK_STATE, ইনস্টলেশনের সময় স্বয়ংক্রিয়ভাবে প্রদান করা হয়।

uses-permission-sdk-23 ট্যাগ শুধুমাত্র Android 6.0+ এ প্রয়োজনীয় অনুমতি নির্দেশ করে। এটি পুরানো সংস্করণগুলির সাথে সামঞ্জস্য বজায় রাখতে অস্তিত্বহীন অনুমতি অনুরোধ না করেই সাহায্য করে। উদাহরণস্বরূপ, POST_NOTIFICATIONS শুধুমাত্র Android 13+ এ উপলব্ধ, তাই এটি uses-permission-sdk-33-এর মাধ্যমে নির্দেশ করা উচিত যাতে পুরানো ডিভাইসে অজানা অনুমতি ত্রুটি না হয়। uses-permission-এ maxSdkVersion অ্যাট্রিবিউট Android-এর নতুন সংস্করণে অ্যাপ্লিকেশন আপডেট করার সময় অপ্রয়োজনীয় অনুমতি স্বয়ংক্রিয়ভাবে প্রত্যাহার করতে দেয়।

সাধারণ স্তরের অনুমতি (INTERNET, ACCESS_NETWORK_STATE) ইনস্টলেশনের সময় স্বয়ংক্রিয়ভাবে প্রদান করা হয় এবং রানটাইম অনুরোধের প্রয়োজন হয় না। এগুলিও uses-permission-এর মাধ্যমে ঘোষণা করা হয়, কিন্তু ব্যবহারকারীকে ডায়ালগে দেখানো হয় না। অন্যান্য অ্যাপ্লিকেশন থেকে অ্যাপ্লিকেশন উপাদানগুলিতে অ্যাক্সেস নিয়ন্ত্রণের জন্য permission-protected components প্রক্রিয়া ব্যবহার করা হয়: Activity বা Service স্তরে কাস্টম অনুমতি নির্ধারণ করা যায় যা বাইরে থেকে উপাদান কল করার সময় সিস্টেম দ্বারা পরীক্ষা করা হবে। এটি আন্তঃপ্রক্রিয়া যোগাযোগের জন্য নিরাপত্তার একটি অতিরিক্ত স্তর নিশ্চিত করে।

Intent Filters এবং ডিপলিংক

ম্যানিফেস্টে intent-filter ট্যাগ ঘোষণা করে কোন অন্তর্নিহিত ইনটেন্ট উপাদান প্রক্রিয়া করতে পারে। এটি সেই প্রক্রিয়া যার মাধ্যমে Android সিস্টেম বা কাস্টম অ্যাকশনকে অ্যাপ্লিকেশনের সাথে সংযুক্ত করে। Intent filter তিনটি উপাদান নিয়ে গঠিত: action (কর্ম), category (বিভাগ) এবং data (ডেটা)। তিনটিই সঠিকভাবে বর্ণনা করার জন্য সংযুক্ত করা যেতে পারে কোন ইনটেন্ট উপাদান পাবে। সিস্টেম সর্বাধিক নির্দিষ্ট ফিল্টারের ভিত্তিতে উপযুক্ত উপাদান নির্বাচন করে।

<activity android:name=".DeepLinkActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="itsectr.com"
            android:pathPrefix="/app" />
    </intent-filter>
</activity>

autoVerify অ্যাট্রিবিউট Android App Links যাচাই সক্ষম করে: সিস্টেম ডোমেনের মালিকানা নিশ্চিত করতে সার্ভারের সাথে যোগাযোগ করে। যাচাই ছাড়া, ডিপলিংকগুলি স্ট্যান্ডার্ড chooser ডায়ালগের মাধ্যমে কাজ করে যেখানে ব্যবহারকারী লিংক খুলতে কোন অ্যাপ্লিকেশন ব্যবহার করবেন তা নির্বাচন করে। সফল যাচাইয়ের পরে লিংকগুলি ডায়ালগ ছাড়াই সরাসরি অ্যাপ্লিকেশনে খোলে। Google Search Consoleও autoVerify ব্যবহার করে ডিপ লিংক ইন্ডেক্স করতে এবং অনুসন্ধান ফলাফলে প্রদর্শন করতে।

action.VIEW এবং DEFAULT ও BROWSABLE বিভাগ সহ ফিল্টারগুলি ব্রাউজার, ইমেল এবং অন্যান্য অ্যাপ্লিকেশন থেকে লিংক প্রক্রিয়া করে। এটি Android-এ ডিপলিংক বাস্তবায়নের প্রধান প্রক্রিয়া। কাস্টম URL স্কিম সমর্থনের জন্য, যেমন myapp://, host ছাড়া scheme নির্দেশ করাই যথেষ্ট। তবে Google কাস্টম স্কিমের পরিবর্তে HTTPS ডিপলিংক ব্যবহারের পরামর্শ দেয় কারণ সেগুলি বেশি নিরাপদ এবং অতিরিক্ত অনুমতির প্রয়োজন হয় না। কাস্টম স্কিমগুলি একই স্কিম নিবন্ধিত যেকোনো অ্যাপ্লিকেশন দ্বারা আটকানো যেতে পারে।

অ্যাপ্লিকেশন অ্যাট্রিবিউট এবং মেটাডেটা

রুট manifest ট্যাগে প্যাকেজ, সংস্করণ এবং SDK-এর অ্যাট্রিবিউট থাকে। application ট্যাগ গ্লোবাল সেটিংস সংরক্ষণ করে: থিম, আইকন, লেবেল এবং ডিবাগিং ফ্ল্যাগ। manifest অ্যাট্রিবিউট প্যাকেজ স্তরে ভার্সনিং নির্ধারণ করে, এবং application অ্যাট্রিবিউট সামগ্রিকভাবে অ্যাপ্লিকেশনের চেহারা এবং আচরণ নির্ধারণ করে। মানগুলি @-সিনট্যাক্সের মাধ্যমে রিসোর্স রেফারেন্স বা স্ট্রিং লিটারেল হতে পারে।

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.itsectr.myapp"

    <uses-sdk
        android:minSdkVersion="24"
        android:targetSdkVersion="34" />

    <application
        android:label="MyApp"
        android:icon="@mipmap/ic_launcher"
        android:theme="@style/Theme.MyApp"
        android:supportsRtl="true"
        android:allowBackup="true">
        <!--  অ্যাপ্লিকেশনের উপাদানসমূহ  -->
    </application>
</manifest>

application-এর ভিতরে meta-data ট্যাগ নির্বিচারে কী-মান জোড়া সংরক্ষণ করতে দেয়। এটি থার্ড-পার্টি লাইব্রেরি কনফিগারেশনের জন্য সুবিধাজনক: API কী, endpoint ঠিকানা এবং কার্যকারিতা ফ্ল্যাগ। meta-data থেকে ডেটা রানটাইমে PackageManager.getApplicationInfo().metaData-এর মাধ্যমে অ্যাক্সেসযোগ্য। উদাহরণস্বরূপ, Firebase এবং Google Maps সোর্স কোডে হার্ডকোডিং ছাড়াই অ্যাক্সেস কী পাঠাতে meta-data ব্যবহার করে। পরিবর্তে, কীগুলি ম্যানিফেস্টে নির্ধারিত হয় এবং বিভিন্ন বিল্ড ফ্লেভারের জন্য ভিন্ন হতে পারে।

android:extractNativeLibs অ্যাট্রিবিউট APK থেকে নেটিভ লাইব্রেরি নিষ্কাশন নিয়ন্ত্রণ করে। targetSdk 34+ সহ অ্যাপ্লিকেশনের জন্য এই অ্যাট্রিবিউট স্পষ্টভাবে নির্দেশ করা আবশ্যক, অন্যথায় বিল্ড INSTALL_FAILED_INVALID_APK ত্রুটির সাথে ব্যর্থ হতে পারে। extractNativeLibs=false হলে, নেটিভ লাইব্রেরি আনপ্যাক না করেই APK-এর ভিতরে থাকে, যা ইনস্টল করা অ্যাপ্লিকেশনের আকার কমায়, কিন্তু লাইব্রেরি লোড করার সময় বাড়ায়। বেশিরভাগ আধুনিক অ্যাপ্লিকেশনের জন্য ব্যবহারকারীর ডিস্কের স্থান কমাতে extractNativeLibs=false সুপারিশ করা হয়।

android:networkSecurityConfig অ্যাট্রিবিউট নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ফাইল নির্ধারণ করতে দেয়। এটি বিশেষ করে targetSdk 28+ সহ অ্যাপ্লিকেশনের জন্য গুরুত্বপূর্ণ, যেখানে HTTP ট্রাফিক ডিফল্টরূপে ব্লক করা থাকে। কনফিগারেশন ফাইল বিশ্বস্ত সার্টিফিকেট, HTTP সংযোগের জন্য ডোমেন এবং সার্টিফিকেট পিনিং নিয়ম নির্ধারণ করে। এটি অপ্রচলিত android:usesCleartextTraffic অ্যাট্রিবিউট প্রতিস্থাপন করে এবং OS স্তরে সংযোগ নিরাপত্তা ব্যবস্থাপনার আরও নমনীয় প্রক্রিয়া প্রদান করে।

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