বিল্ড নির্ভরতা যোগ করুন

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

একটি লাইব্রেরি বা প্লাগইন নির্ভরতা যোগ করুন

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

নেটিভ নির্ভরতা (সাধারণ নয়) যোগ এবং পরিচালনার নির্দেশিকা জন্য, নেটিভ নির্ভরতা দেখুন।

নিম্নলিখিত উদাহরণে, আমরা আমাদের প্রকল্পে একটি দূরবর্তী বাইনারি নির্ভরতা ( জেটপ্যাক ম্যাক্রোবেঞ্চমার্ক লাইব্রেরি ), স্থানীয় লাইব্রেরি মডিউল নির্ভরতা ( myLibrary ), এবং একটি প্লাগইন নির্ভরতা (Android Gradle প্লাগইন) যোগ করি। আপনার প্রকল্পে এই নির্ভরতাগুলি যোগ করার জন্য এখানে সাধারণ পদক্ষেপগুলি রয়েছে:

1. সংস্করণ ক্যাটালগ ফাইলের [versions] বিভাগে আপনি যে সংস্করণটি চান তার জন্য একটি উপনাম যোগ করুন, যাকে বলা হয় libs.versions.toml ( প্রজেক্ট ভিউতে gradle ডিরেক্টরির অধীনে বা অ্যান্ড্রয়েড ভিউতে গ্রেডল স্ক্রিপ্ট ):

   [versions]
   agp = "8.3.0"
   androidx-macro-benchmark = "1.2.2"
   my-library = "1.4"
   
   [libraries]
   ...
   
   [plugins]
   ...
   

   উপনামে ড্যাশ বা আন্ডারস্কোর অন্তর্ভুক্ত থাকতে পারে। এই উপনামগুলি নেস্টেড মান তৈরি করে যা আপনি বিল্ড স্ক্রিপ্টগুলিতে উল্লেখ করতে পারেন। রেফারেন্সগুলি ক্যাটালগের নাম দিয়ে শুরু হয়, libs.versions.toml এর libs অংশ। একটি একক সংস্করণ ক্যাটালগ ব্যবহার করার সময়, আমরা "libs" এর ডিফল্ট মান রাখার পরামর্শ দিই।

2. libs.versions.toml ফাইলের [libraries] (দূরবর্তী বাইনারি বা স্থানীয় লাইব্রেরি মডিউলগুলির জন্য) বা [plugins] (প্লাগইনগুলির জন্য) বিভাগে নির্ভরতার জন্য একটি উপনাম যোগ করুন।

   [versions]
   ...
   
   [libraries]
   androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" }
   my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" }
   
   [plugins]
   androidApplication = { id = "com.android.application", version.ref = "agp" }
   

   কিছু লাইব্রেরি একটি প্রকাশিত বিল অফ ম্যাটেরিয়ালস (BOM) এ পাওয়া যায় যা লাইব্রেরির পরিবার এবং তাদের সংস্করণগুলিকে গোষ্ঠীভুক্ত করে। আপনি আপনার সংস্করণ ক্যাটালগে একটি BOM অন্তর্ভুক্ত করতে পারেন এবং ফাইলগুলি তৈরি করতে পারেন এবং এটিকে আপনার জন্য সেই সংস্করণগুলি পরিচালনা করতে দিন৷ বিস্তারিত জানার জন্য উপকরণের বিল ব্যবহার দেখুন।

3. নির্ভরতা প্রয়োজন এমন মডিউলের বিল্ড স্ক্রিপ্টে নির্ভরতা উপনামের একটি রেফারেন্স যোগ করুন। আপনি যখন বিল্ড স্ক্রিপ্ট থেকে রেফারেন্স করেন তখন উপনামের আন্ডারস্কোর এবং ড্যাশগুলিকে ডটে রূপান্তর করুন৷ আমাদের মডিউল-স্তরের বিল্ড স্ক্রিপ্টটি দেখতে এইরকম হবে:

   কোটলিন

   plugins {
     alias(libs.plugins.androidApplication)
   }
   
   dependencies {
     implementation(libs.androidx.benchmark.macro)
     implementation(libs.my.library)
   }
   

   গ্রোভি

   plugins {
     alias 'libs.plugins.androidApplication'
   }
   
   dependencies {
     implementation libs.androidx.benchmark.macro
     implementation libs.my.library
   }
   

   প্লাগইন রেফারেন্স ক্যাটালগ নামের পরে plugins অন্তর্ভুক্ত করে, এবং সংস্করণ রেফারেন্স ক্যাটালগ নামের পরে versions অন্তর্ভুক্ত করে (সংস্করণ রেফারেন্সগুলি অস্বাভাবিক; সংস্করণ উল্লেখগুলির উদাহরণগুলির জন্য একই সংস্করণ নম্বর সহ নির্ভরতা দেখুন।) লাইব্রেরি রেফারেন্স libraries যোগ্যতা অন্তর্ভুক্ত করে না, তাই আপনি করতে পারেন একটি লাইব্রেরি উপনামের শুরুতে versions বা plugins ব্যবহার করবেন না।

নির্ভরতা কনফিগার করুন

dependencies ব্লকের ভিতরে, আপনি বিভিন্ন নির্ভরতা কনফিগারেশনের একটি ব্যবহার করে একটি লাইব্রেরি নির্ভরতা ঘোষণা করতে পারেন (যেমন পূর্বে দেখানো implementation )। প্রতিটি নির্ভরতা কনফিগারেশন কিভাবে নির্ভরতা ব্যবহার করতে হয় সে সম্পর্কে বিভিন্ন নির্দেশাবলী সহ Gradle প্রদান করে। নিম্নলিখিত সারণী প্রতিটি কনফিগারেশন বর্ণনা করে যা আপনি আপনার Android প্রকল্পে নির্ভরতার জন্য ব্যবহার করতে পারেন।

dependencies {
  // Executes lint checks from the ":checks" project at build time.
  lintChecks(project(":checks"))
  // Compiles lint checks from the ":checks-to-publish" into a
  // lint.jar file and publishes it to your Android library.
  lintPublish(project(":checks-to-publish"))
}

dependencies {
  // Executes lint checks from the ':checks' project at build time.
  lintChecks project(':checks')
  // Compiles lint checks from the ':checks-to-publish' into a
  // lint.jar file and publishes it to your Android library.
  lintPublish project(':checks-to-publish')
}

একটি নির্দিষ্ট বিল্ড বৈকল্পিক জন্য নির্ভরতা কনফিগার করুন

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

উদাহরণস্বরূপ, implementation কনফিগারেশন ব্যবহার করে শুধুমাত্র আপনার "ফ্রি" পণ্যের স্বাদে একটি দূরবর্তী বাইনারি নির্ভরতা যোগ করতে, এটি ব্যবহার করুন:

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

যাইহোক, যদি আপনি একটি ভেরিয়েন্টের জন্য একটি নির্ভরতা যোগ করতে চান যা একটি পণ্যের স্বাদ এবং একটি বিল্ড টাইপকে একত্রিত করে, তাহলে আপনাকে অবশ্যই কনফিগারেশন নামটি শুরু করতে হবে:

// Initializes a placeholder for the freeDebugImplementation dependency configuration.
val freeDebugImplementation by configurations.creating

dependencies {
    freeDebugImplementation(project(":free-support"))
}

configurations {
    // Initializes a placeholder for the freeDebugImplementation dependency configuration.
    freeDebugImplementation {}
}

dependencies {
    freeDebugImplementation project(":free-support")
}

আপনার স্থানীয় পরীক্ষা এবং যন্ত্রযুক্ত পরীক্ষার জন্য implementation নির্ভরতা যোগ করতে, এটি এইরকম দেখায়:

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1")
}

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
}

যাইহোক, নির্দিষ্ট কনফিগারেশন এই পরিস্থিতিতে অর্থপূর্ণ হয় না। উদাহরণস্বরূপ, যেহেতু অন্যান্য মডিউলগুলি androidTest এর উপর নির্ভর করতে পারে না, আপনি যদি androidTestApi কনফিগারেশন ব্যবহার করেন তবে আপনি নিম্নলিখিত সতর্কতা পাবেন:

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

নির্ভরতা আদেশ

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

উদাহরণস্বরূপ, যদি আপনার প্রকল্প নিম্নলিখিত ঘোষণা করে:

• LIB_A এবং LIB_B এর উপর নির্ভরতা (সেই ক্রমে)
• এবং LIB_A নির্ভর করে LIB_C এবং LIB_D এর উপর (সেই ক্রমে)
• এবং LIB_B ও LIB_C এর উপর নির্ভর করে

তারপর, ফ্ল্যাট নির্ভরতা আদেশটি নিম্নরূপ হবে:

1. LIB_A
2. LIB_D
3. LIB_B
4. LIB_C

এটি নিশ্চিত করে যে LIB_A এবং LIB_B উভয়ই LIB_C ওভাররাইড করতে পারে; এবং LIB_D এখনও LIB_B চেয়ে উচ্চ অগ্রাধিকার কারণ LIB_A (যা এটির উপর নির্ভর করে) LIB_B এর চেয়ে বেশি অগ্রাধিকার রয়েছে।

বিভিন্ন প্রকল্পের উত্স/নির্ভরতাগুলি থেকে কীভাবে মেনিফেস্ট করা হয় সে সম্পর্কে আরও তথ্যের জন্য, একাধিক ম্যানিফেস্ট ফাইল মার্জ করুন দেখুন।

প্লে কনসোলের নির্ভরতার তথ্য

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

ডেটা সংকুচিত হয়, একটি Google Play সাইনিং কী দ্বারা এনক্রিপ্ট করা হয় এবং আপনার রিলিজ অ্যাপের সাইনিং ব্লকে সংরক্ষণ করা হয়। আমরা একটি নিরাপদ এবং ইতিবাচক ব্যবহারকারীর অভিজ্ঞতার জন্য এই নির্ভরতা ফাইলটি রাখার পরামর্শ দিই। আপনি আপনার মডিউলের build.gradle.kts ফাইলে নিম্নলিখিত dependenciesInfo ব্লক অন্তর্ভুক্ত করে অপ্ট আউট করতে পারেন।

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

আমাদের নীতি এবং নির্ভরতা সংক্রান্ত সম্ভাব্য সমস্যা সম্পর্কে আরও তথ্যের জন্য, আপনার অ্যাপে তৃতীয় পক্ষের SDK ব্যবহার করার বিষয়ে আমাদের সহায়তা পৃষ্ঠা দেখুন।

SDK অন্তর্দৃষ্টি

নিম্নলিখিত সমস্যাগুলি প্রযোজ্য হলে Android স্টুডিও Google Play SDK সূচকে সর্বজনীন SDK-এর জন্য সংস্করণ ক্যাটালগ ফাইল এবং প্রোজেক্ট স্ট্রাকচার ডায়ালগে লিন্ট সতর্কতা দেখায়:

• SDKগুলিকে তাদের লেখকরা পুরানো হিসাবে চিহ্নিত করেছেন৷
• SDKগুলি Play নীতি লঙ্ঘন করে৷

সতর্কতাগুলি হল সংকেত যে আপনার সেই নির্ভরতাগুলি আপডেট করা উচিত, কারণ পুরানো সংস্করণগুলি ব্যবহার করা আপনাকে ভবিষ্যতে Google Play Console-এ প্রকাশ করা থেকে আটকাতে পারে৷

সংস্করণ ক্যাটালগ ছাড়া বিল্ড নির্ভরতা যোগ করুন

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

plugins {
    id("com.android.application")
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation("com.example.android:app-magic:12.3")
    // Dependency on a local library module
    implementation(project(":mylibrary"))
}

plugins {
    id 'com.android.application'
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
    // Dependency on a local library module
    implementation project(':mylibrary')
}

এই বিল্ড ফাইলটি "com.example.android" নেমস্পেস গ্রুপের ভিতরে, "app-magic" লাইব্রেরির সংস্করণ 12.3-এর উপর নির্ভরতা ঘোষণা করে। দূরবর্তী বাইনারি নির্ভরতা ঘোষণা নিম্নলিখিত জন্য সংক্ষিপ্ত হয়:

implementation(group = "com.example.android", name = "app-magic", version = "12.3")

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

বিল্ড ফাইলটি "মাইলাইব্রেরি" নামে একটি অ্যান্ড্রয়েড লাইব্রেরি মডিউলের উপর নির্ভরতা ঘোষণা করে; আপনার settings.gradle.kts ফাইলে একটি include: সহ সংজ্ঞায়িত লাইব্রেরির নামের সাথে এই নামটি অবশ্যই মিলবে। আপনি যখন আপনার অ্যাপটি তৈরি করেন, তখন বিল্ড সিস্টেম লাইব্রেরি মডিউল কম্পাইল করে এবং অ্যাপে কম্পাইল করা বিষয়বস্তু প্যাকেজ করে।

বিল্ড ফাইলটি অ্যান্ড্রয়েড গ্রেডল প্লাগইন ( com.application.android ) এর উপর নির্ভরতাও ঘোষণা করে। আপনার যদি একাধিক মডিউল থাকে যা একই প্লাগইন ব্যবহার করে, তবে সমস্ত মডিউল জুড়ে বিল্ড ক্লাসপাথে প্লাগইনের একটি একক সংস্করণ থাকতে পারে। প্রতিটি মডিউল বিল্ড স্ক্রিপ্টে সংস্করণ নির্দিষ্ট করার পরিবর্তে, আপনাকে সংস্করণের সাথে রুট বিল্ড স্ক্রিপ্টে প্লাগইন নির্ভরতা অন্তর্ভুক্ত করতে হবে এবং এটি প্রয়োগ না করার ইঙ্গিত দিতে হবে। apply false যোগ করা গ্র্যাডলকে প্লাগইনটির সংস্করণটি নোট করতে বলে কিন্তু রুট বিল্ডে এটি ব্যবহার না করতে বলে। সাধারণত এই plugins ব্লক ছাড়া রুট বিল্ড স্ক্রিপ্ট খালি থাকে।

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

plugins {
    id ‘com.android.application’ version ‘8.3.0-rc02’ apply false
}

আপনার যদি একটি একক-মডিউল প্রকল্প থাকে তবে আপনি মডিউল-স্তরের বিল্ড স্ক্রিপ্টে স্পষ্টভাবে সংস্করণটি নির্দিষ্ট করতে পারেন এবং প্রকল্প-স্তরের বিল্ড স্ক্রিপ্টটি খালি রাখতে পারেন:

plugins {
    id("com.android.application") version "8.3.0"
}

plugins {
    id 'com.android.application' version '8.3.0-rc02'
}

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

একটি লাইব্রেরি বা প্লাগইন নির্ভরতা যোগ করুন

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

নেটিভ নির্ভরতা (সাধারণ নয়) যোগ এবং পরিচালনার নির্দেশিকা জন্য, নেটিভ নির্ভরতা দেখুন।

নিম্নলিখিত উদাহরণে, আমরা আমাদের প্রকল্পে একটি দূরবর্তী বাইনারি নির্ভরতা ( জেটপ্যাক ম্যাক্রোবেঞ্চমার্ক লাইব্রেরি ), স্থানীয় লাইব্রেরি মডিউল নির্ভরতা ( myLibrary ), এবং একটি প্লাগইন নির্ভরতা (Android Gradle প্লাগইন) যোগ করি। আপনার প্রকল্পে এই নির্ভরতাগুলি যোগ করার জন্য এখানে সাধারণ পদক্ষেপগুলি রয়েছে:

1. সংস্করণ ক্যাটালগ ফাইলের [versions] বিভাগে আপনি যে সংস্করণটি চান তার জন্য একটি উপনাম যোগ করুন, যাকে বলা হয় libs.versions.toml ( প্রজেক্ট ভিউতে gradle ডিরেক্টরির অধীনে বা অ্যান্ড্রয়েড ভিউতে গ্রেডল স্ক্রিপ্ট ):

   [versions]
   agp = "8.3.0"
   androidx-macro-benchmark = "1.2.2"
   my-library = "1.4"
   
   [libraries]
   ...
   
   [plugins]
   ...
   

   উপনামে ড্যাশ বা আন্ডারস্কোর অন্তর্ভুক্ত থাকতে পারে। এই উপনামগুলি নেস্টেড মান তৈরি করে যা আপনি বিল্ড স্ক্রিপ্টগুলিতে উল্লেখ করতে পারেন। রেফারেন্সগুলি ক্যাটালগের নাম দিয়ে শুরু হয়, libs.versions.toml এর libs অংশ। একটি একক সংস্করণ ক্যাটালগ ব্যবহার করার সময়, আমরা "libs" এর ডিফল্ট মান রাখার পরামর্শ দিই।

2. libs.versions.toml ফাইলের [libraries] (দূরবর্তী বাইনারি বা স্থানীয় লাইব্রেরি মডিউলগুলির জন্য) বা [plugins] (প্লাগইনগুলির জন্য) বিভাগে নির্ভরতার জন্য একটি উপনাম যোগ করুন।

   [versions]
   ...
   
   [libraries]
   androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" }
   my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" }
   
   [plugins]
   androidApplication = { id = "com.android.application", version.ref = "agp" }
   

   কিছু লাইব্রেরি একটি প্রকাশিত বিল অফ ম্যাটেরিয়ালস (BOM) এ পাওয়া যায় যা লাইব্রেরির পরিবার এবং তাদের সংস্করণগুলিকে গোষ্ঠীভুক্ত করে। আপনি আপনার সংস্করণ ক্যাটালগে একটি BOM অন্তর্ভুক্ত করতে পারেন এবং ফাইলগুলি তৈরি করতে পারেন এবং এটিকে আপনার জন্য সেই সংস্করণগুলি পরিচালনা করতে দিন৷ বিস্তারিত জানার জন্য উপকরণের বিল ব্যবহার দেখুন।

3. নির্ভরতা প্রয়োজন এমন মডিউলের বিল্ড স্ক্রিপ্টে নির্ভরতা উপনামের একটি রেফারেন্স যোগ করুন। আপনি যখন বিল্ড স্ক্রিপ্ট থেকে রেফারেন্স করেন তখন উপনামের আন্ডারস্কোর এবং ড্যাশগুলিকে ডটে রূপান্তর করুন৷ আমাদের মডিউল-স্তরের বিল্ড স্ক্রিপ্টটি দেখতে এইরকম হবে:

   কোটলিন

   plugins {
     alias(libs.plugins.androidApplication)
   }
   
   dependencies {
     implementation(libs.androidx.benchmark.macro)
     implementation(libs.my.library)
   }
   

   গ্রোভি

   plugins {
     alias 'libs.plugins.androidApplication'
   }
   
   dependencies {
     implementation libs.androidx.benchmark.macro
     implementation libs.my.library
   }
   

   প্লাগইন রেফারেন্স ক্যাটালগ নামের পরে plugins অন্তর্ভুক্ত করে, এবং সংস্করণ রেফারেন্স ক্যাটালগ নামের পরে versions অন্তর্ভুক্ত করে (সংস্করণ রেফারেন্সগুলি অস্বাভাবিক; সংস্করণ উল্লেখগুলির উদাহরণগুলির জন্য একই সংস্করণ নম্বর সহ নির্ভরতা দেখুন।) লাইব্রেরি রেফারেন্স libraries যোগ্যতা অন্তর্ভুক্ত করে না, তাই আপনি করতে পারেন একটি লাইব্রেরি উপনামের শুরুতে versions বা plugins ব্যবহার করবেন না।

নির্ভরতা কনফিগার করুন

dependencies ব্লকের ভিতরে, আপনি বিভিন্ন নির্ভরতা কনফিগারেশনের একটি ব্যবহার করে একটি লাইব্রেরি নির্ভরতা ঘোষণা করতে পারেন (যেমন পূর্বে দেখানো implementation )। প্রতিটি নির্ভরতা কনফিগারেশন কিভাবে নির্ভরতা ব্যবহার করতে হয় সে সম্পর্কে বিভিন্ন নির্দেশাবলী সহ Gradle প্রদান করে। নিম্নলিখিত সারণী প্রতিটি কনফিগারেশন বর্ণনা করে যা আপনি আপনার Android প্রকল্পে নির্ভরতার জন্য ব্যবহার করতে পারেন।

dependencies {
  // Executes lint checks from the ":checks" project at build time.
  lintChecks(project(":checks"))
  // Compiles lint checks from the ":checks-to-publish" into a
  // lint.jar file and publishes it to your Android library.
  lintPublish(project(":checks-to-publish"))
}

dependencies {
  // Executes lint checks from the ':checks' project at build time.
  lintChecks project(':checks')
  // Compiles lint checks from the ':checks-to-publish' into a
  // lint.jar file and publishes it to your Android library.
  lintPublish project(':checks-to-publish')
}

একটি নির্দিষ্ট বিল্ড বৈকল্পিক জন্য নির্ভরতা কনফিগার করুন

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

উদাহরণস্বরূপ, implementation কনফিগারেশন ব্যবহার করে শুধুমাত্র আপনার "ফ্রি" পণ্যের স্বাদে একটি দূরবর্তী বাইনারি নির্ভরতা যোগ করতে, এটি ব্যবহার করুন:

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

যাইহোক, যদি আপনি একটি ভেরিয়েন্টের জন্য একটি নির্ভরতা যোগ করতে চান যা একটি পণ্যের স্বাদ এবং একটি বিল্ড টাইপকে একত্রিত করে, তাহলে আপনাকে অবশ্যই কনফিগারেশন নামটি শুরু করতে হবে:

// Initializes a placeholder for the freeDebugImplementation dependency configuration.
val freeDebugImplementation by configurations.creating

dependencies {
    freeDebugImplementation(project(":free-support"))
}

configurations {
    // Initializes a placeholder for the freeDebugImplementation dependency configuration.
    freeDebugImplementation {}
}

dependencies {
    freeDebugImplementation project(":free-support")
}

আপনার স্থানীয় পরীক্ষা এবং যন্ত্রযুক্ত পরীক্ষার জন্য implementation নির্ভরতা যোগ করতে, এটি এইরকম দেখায়:

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1")
}

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
}

যাইহোক, নির্দিষ্ট কনফিগারেশন এই পরিস্থিতিতে অর্থপূর্ণ হয় না। উদাহরণস্বরূপ, যেহেতু অন্যান্য মডিউলগুলি androidTest এর উপর নির্ভর করতে পারে না, আপনি যদি androidTestApi কনফিগারেশন ব্যবহার করেন তবে আপনি নিম্নলিখিত সতর্কতা পাবেন:

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

নির্ভরতা আদেশ

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

উদাহরণস্বরূপ, যদি আপনার প্রকল্প নিম্নলিখিত ঘোষণা করে:

• LIB_A এবং LIB_B এর উপর নির্ভরতা (সেই ক্রমে)
• এবং LIB_A নির্ভর করে LIB_C এবং LIB_D এর উপর (সেই ক্রমে)
• এবং LIB_B ও LIB_C এর উপর নির্ভর করে

তারপর, ফ্ল্যাট নির্ভরতা আদেশটি নিম্নরূপ হবে:

1. LIB_A
2. LIB_D
3. LIB_B
4. LIB_C

এটি নিশ্চিত করে যে LIB_A এবং LIB_B উভয়ই LIB_C ওভাররাইড করতে পারে; এবং LIB_D এখনও LIB_B চেয়ে উচ্চ অগ্রাধিকার কারণ LIB_A (যা এটির উপর নির্ভর করে) LIB_B এর চেয়ে বেশি অগ্রাধিকার রয়েছে।

বিভিন্ন প্রকল্পের উত্স/নির্ভরতাগুলি থেকে কীভাবে মেনিফেস্ট করা হয় সে সম্পর্কে আরও তথ্যের জন্য, একাধিক ম্যানিফেস্ট ফাইল মার্জ করুন দেখুন।

প্লে কনসোলের নির্ভরতার তথ্য

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

ডেটা সংকুচিত হয়, একটি Google Play সাইনিং কী দ্বারা এনক্রিপ্ট করা হয় এবং আপনার রিলিজ অ্যাপের সাইনিং ব্লকে সংরক্ষণ করা হয়। আমরা একটি নিরাপদ এবং ইতিবাচক ব্যবহারকারীর অভিজ্ঞতার জন্য এই নির্ভরতা ফাইলটি রাখার পরামর্শ দিই। আপনি আপনার মডিউলের build.gradle.kts ফাইলে নিম্নলিখিত dependenciesInfo ব্লক অন্তর্ভুক্ত করে অপ্ট আউট করতে পারেন।

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

আমাদের নীতি এবং নির্ভরতা সংক্রান্ত সম্ভাব্য সমস্যা সম্পর্কে আরও তথ্যের জন্য, আপনার অ্যাপে তৃতীয় পক্ষের SDK ব্যবহার করার বিষয়ে আমাদের সহায়তা পৃষ্ঠা দেখুন।

SDK অন্তর্দৃষ্টি

নিম্নলিখিত সমস্যাগুলি প্রযোজ্য হলে Android স্টুডিও Google Play SDK সূচকে সর্বজনীন SDK-এর জন্য সংস্করণ ক্যাটালগ ফাইল এবং প্রোজেক্ট স্ট্রাকচার ডায়ালগে লিন্ট সতর্কতা দেখায়:

• SDKগুলিকে তাদের লেখকরা পুরানো হিসাবে চিহ্নিত করেছেন৷
• SDKগুলি Play নীতি লঙ্ঘন করে৷

সতর্কতাগুলি হল সংকেত যে আপনার সেই নির্ভরতাগুলি আপডেট করা উচিত, কারণ পুরানো সংস্করণগুলি ব্যবহার করা আপনাকে ভবিষ্যতে Google Play Console-এ প্রকাশ করা থেকে আটকাতে পারে৷

সংস্করণ ক্যাটালগ ছাড়া বিল্ড নির্ভরতা যোগ করুন

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

plugins {
    id("com.android.application")
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation("com.example.android:app-magic:12.3")
    // Dependency on a local library module
    implementation(project(":mylibrary"))
}

plugins {
    id 'com.android.application'
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
    // Dependency on a local library module
    implementation project(':mylibrary')
}

এই বিল্ড ফাইলটি "com.example.android" নেমস্পেস গ্রুপের ভিতরে, "app-magic" লাইব্রেরির সংস্করণ 12.3-এর উপর নির্ভরতা ঘোষণা করে। দূরবর্তী বাইনারি নির্ভরতা ঘোষণা নিম্নলিখিত জন্য সংক্ষিপ্ত হয়:

implementation(group = "com.example.android", name = "app-magic", version = "12.3")

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

বিল্ড ফাইলটি "মাইলাইব্রেরি" নামে একটি অ্যান্ড্রয়েড লাইব্রেরি মডিউলের উপর নির্ভরতা ঘোষণা করে; আপনার settings.gradle.kts ফাইলে একটি include: সহ সংজ্ঞায়িত লাইব্রেরির নামের সাথে এই নামটি অবশ্যই মিলবে। আপনি যখন আপনার অ্যাপটি তৈরি করেন, তখন বিল্ড সিস্টেম লাইব্রেরি মডিউল কম্পাইল করে এবং অ্যাপে কম্পাইল করা বিষয়বস্তু প্যাকেজ করে।

বিল্ড ফাইলটি অ্যান্ড্রয়েড গ্রেডল প্লাগইন ( com.application.android ) এর উপর নির্ভরতাও ঘোষণা করে। আপনার যদি একাধিক মডিউল থাকে যা একই প্লাগইন ব্যবহার করে, তবে সমস্ত মডিউল জুড়ে বিল্ড ক্লাসপাথে প্লাগইনের একটি একক সংস্করণ থাকতে পারে। প্রতিটি মডিউল বিল্ড স্ক্রিপ্টে সংস্করণ নির্দিষ্ট করার পরিবর্তে, আপনাকে সংস্করণের সাথে রুট বিল্ড স্ক্রিপ্টে প্লাগইন নির্ভরতা অন্তর্ভুক্ত করতে হবে এবং এটি প্রয়োগ না করার ইঙ্গিত দিতে হবে। apply false যোগ করা গ্র্যাডলকে প্লাগইনটির সংস্করণটি নোট করতে বলে কিন্তু রুট বিল্ডে এটি ব্যবহার না করতে বলে। সাধারণত এই plugins ব্লক ছাড়া রুট বিল্ড স্ক্রিপ্ট খালি থাকে।

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

plugins {
    id ‘com.android.application’ version ‘8.3.0-rc02’ apply false
}

আপনার যদি একটি একক-মডিউল প্রকল্প থাকে তবে আপনি মডিউল-স্তরের বিল্ড স্ক্রিপ্টে স্পষ্টভাবে সংস্করণটি নির্দিষ্ট করতে পারেন এবং প্রকল্প-স্তরের বিল্ড স্ক্রিপ্টটি খালি রাখতে পারেন:

plugins {
    id("com.android.application") version "8.3.0"
}

plugins {
    id 'com.android.application' version '8.3.0-rc02'
}