বিল্ড ডিপেন্ডেন্সি যোগ করুন

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

লাইব্রেরি বা প্লাগ-ইন ডিপেন্ডেন্সি যোগ করুন

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

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

নিচের উদাহরণে, একটি রিমোট বাইনারি ডিপেন্ডেন্সি (Jetpack Macrobenchmark লাইব্রেরি), লোকাল লাইব্রেরি মডিউল ডিপেন্ডেন্সি (myLibrary) এবং একটি প্লাগ-ইন ডিপেন্ডেন্সি (Android Gradle প্লাগ-ইন) প্রোজেক্টে যোগ করা হয়েছে। আপনার প্রোজেক্টে এইসব ডিপেন্ডেন্সি যোগ করার সাধারণ ধাপগুলি এখানে দেওয়া হল:

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

    [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. যেসব মডিউলের ডিপেন্ডেন্সি প্রয়োজন, সেগুলির বিল্ড স্ক্রিপ্টে ডিপেন্ডেন্সি অ্যালিয়াসের রেফারেন্স যোগ করুন। বিল্ড স্ক্রিপ্ট থেকে রেফারেন্স দেওয়ার সময়, উপনামের আন্ডারস্কোর ও ড্যাশকে ডটে কনভার্ট করুন। আমাদের মডিউল-লেভেল বিল্ড স্ক্রিপ্ট এইরকম দেখতে হবে:

    Kotlin

    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 প্রোজেক্টে ডিপেন্ডেন্সির জন্য ব্যবহার করতে পারেন এমন প্রতিটি কনফিগারেশনের বিবরণ নিম্নলিখিত সারণীতে দেওয়া হয়েছে।

কনফিগারেশন আচরণ
implementation Gradle কম্পাইল ক্লাসপাথে ডিপেন্ডেন্সি যোগ করে এবং বিল্ড আউটপুটে ডিপেন্ডেন্সি প্যাকেজ করে। আপনার মডিউল implementation ডিপেন্ডেন্সি কনফিগার করলে, এটি Gradle-কে জানায় যে আপনি চান না যে মডিউলটি কম্পাইল করার সময় অন্য মডিউলে ডিপেন্ডেন্সি লিক করুক। অর্থাৎ, বর্তমান মডিউলের উপর নির্ভর করে এমন অন্যান্য মডিউলের জন্য ডিপেন্ডেন্সি উপলভ্য করা হয়নি।

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

api Gradle, কম্পাইল ক্লাসপাথ ও বিল্ড আউটপুটে ডিপেন্ডেন্সি যোগ করে। কোনও মডিউলে api ডিপেন্ডেন্সি থাকলে, এটি Gradle-কে জানায় যে মডিউলটি ট্রানজিটিভভাবে সেই ডিপেন্ডেন্সি অন্যান্য মডিউলে এক্সপোর্ট করতে চায়, যাতে রানটাইম ও কম্পাইল টাইম, উভয় ক্ষেত্রেই এটি উপলভ্য থাকে।

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

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

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

মনে রাখবেন: আপনি Android Archive (AAR) ডিপেন্ডেন্সির সাথে compileOnly কনফিগারেশন ব্যবহার করতে পারবেন না।

runtimeOnly রানটাইমে ব্যবহারের জন্য Gradle শুধুমাত্র বিল্ড আউটপুটে ডিপেন্ডেন্সি যোগ করে। অর্থাৎ, এটি কম্পাইল ক্লাসপাথে যোগ করা হয় না। এটি Android-এ খুব কমই ব্যবহার করা হয়, তবে সাধারণত সার্ভার অ্যাপ্লিকেশনে লগিং ইমপ্লিমেন্টেশন প্রদান করতে ব্যবহার করা হয়। যেমন, একটি লাইব্রেরি এমন একটি লগিং API ব্যবহার করতে পারে যাতে কোনও ইমপ্লিমেন্টেশন অন্তর্ভুক্ত থাকে না। সেই লাইব্রেরির গ্রাহকরা এটিকে একটি implementation ডিপেন্ডেন্সি হিসেবে যোগ করতে পারেন এবং ব্যবহারের জন্য প্রকৃত লগিং ইমপ্লিমেন্টেশনের জন্য একটি runtimeOnly ডিপেন্ডেন্সি অন্তর্ভুক্ত করতে পারেন।
ksp
kapt
annotationProcessor

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

এই ধরনের ডিপেন্ডেন্সি যোগ করতে, আপনাকে অবশ্যই ksp, kapt বা annotationProcessor কনফিগারেশন ব্যবহার করে অ্যানোটেশন প্রসেসর ক্লাসপাথে এটি যোগ করতে হবে। এইসব কনফিগারেশন ব্যবহার করলে, অ্যানোটেশন প্রসেসর ক্লাসপাথ থেকে কম্পাইল ক্লাসপাথ আলাদা করে বিল্ড পারফর্ম্যান্স উন্নত করা হয়। Gradle যদি কম্পাইল ক্লাসপাথে অ্যানোটেশন প্রসেসর খুঁজে পায়, তাহলে এটি কম্পাইল এড়ানো বন্ধ করে দেয়, যা বিল্ড টাইমকে নেতিবাচকভাবে প্রভাবিত করে (Gradle 5.0 এবং তার পরবর্তী ভার্সন কম্পাইল ক্লাসপাথে খুঁজে পাওয়া অ্যানোটেশন প্রসেসরকে উপেক্ষা করে)।

Android Gradle প্লাগ-ইন ধরে নেয় যে কোনও ডিপেন্ডেন্সি হল একটি অ্যানোটেশন প্রসেসর যদি এর JAR ফাইলে নিম্নলিখিত ফাইল থাকে:

META-INF/services/javax.annotation.processing.Processor

প্লাগ-ইন যদি কম্পাইল ক্লাসপাথে থাকা কোনও অ্যানোটেশন প্রসেসর শনাক্ত করে, তাহলে এটি একটি বিল্ড এরর তৈরি করে।

ksp হল একটি Kotlin সিম্বল প্রসেসর এবং এটি Kotlin কম্পাইলার দ্বারা রান করা হয়।

kapt এবং apt হল আলাদা টুল যা Kotlin বা Java কম্পাইলার এক্সিকিউট করার আগে অ্যানোটেশন প্রসেস করে।

কোন কনফিগারেশন ব্যবহার করবেন তা সিদ্ধান্ত নেওয়ার সময়, নিম্নলিখিত বিষয়গুলি বিবেচনা করুন:

  • Kotlin সিম্বল প্রসেসর হিসেবে কোনও প্রসেসর উপলভ্য থাকলে, সেটি ksp ডিপেন্ডেন্সি হিসেবে ব্যবহার করুন। Kotlin সিম্বল প্রসেসর ব্যবহার করার ব্যাপারে বিস্তারিত জানতে, kapt থেকে ksp-তে মাইগ্রেট করুন লিঙ্ক দেখুন।
  • প্রসেসরটি Kotlin সিম্বল প্রসেসর হিসেবে উপলভ্য না হলে:
    • আপনার প্রোজেক্টে Kotlin সোর্স থাকলে (তবে Java সোর্সও থাকতে পারে), এটি অন্তর্ভুক্ত করতে kapt ব্যবহার করুন।
    • আপনার প্রোজেক্টে শুধু Java সোর্স ব্যবহার করা হলে, এটি অন্তর্ভুক্ত করতে annotationProcessor ব্যবহার করুন।

অ্যানোটেশন প্রসেসর ব্যবহার করার ব্যাপারে আরও তথ্য পেতে, অ্যানোটেশন প্রসেসর যোগ করুন দেখুন।

lintChecks

আপনার Android অ্যাপ প্রোজেক্ট তৈরি করার সময় Gradle-এর মাধ্যমে লিন্ট চেক করার জন্য লাইব্রেরি অন্তর্ভুক্ত করতে এই কনফিগারেশন ব্যবহার করুন।

মনে রাখবেন, যেসব AAR-এ lint.jar ফাইল থাকে, সেগুলি অটোমেটিক ওই lint.jar ফাইলে উল্লেখ করা চেক রান করবে; আপনাকে আলাদা করে lintChecks ডিপেন্ডেন্সি যোগ করতে হবে না। এটি আপনাকে একটি একক নির্ভরতায় লাইব্রেরি এবং সংশ্লিষ্ট লিন্ট চেক সংজ্ঞায়িত করতে দেয়, যাতে গ্রাহকরা আপনার লাইব্রেরি ব্যবহার করার সময় আপনার চেকগুলি চালানো হয়।

lintPublish Android লাইব্রেরি প্রোজেক্টে এই কনফিগারেশন ব্যবহার করে লিন্ট চেক অন্তর্ভুক্ত করুন যা আপনি চান যে Gradle একটি lint.jar ফাইলে কম্পাইল করুক এবং আপনার AAR-এ প্যাকেজ করুক। এর ফলে, আপনার AAR ব্যবহার করে এমন প্রোজেক্টগুলিও সেই লিন্ট চেকগুলি প্রয়োগ করে। আপনি যদি আগে প্রকাশিত AAR-এ লিন্ট চেক অন্তর্ভুক্ত করার জন্য lintChecks ডিপেন্ডেন্সি কনফিগারেশন ব্যবহার করে থাকেন, তাহলে আপনাকে সেইসব ডিপেন্ডেন্সি মাইগ্রেট করে তার পরিবর্তে lintPublish কনফিগারেশন ব্যবহার করতে হবে।

Kotlin

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 কনফিগারেশন ব্যবহার করে শুধুমাত্র আপনার "ফ্রি" প্রোডাক্ট ফ্লেভারে রিমোট বাইনারি ডিপেন্ডেন্সি যোগ করতে, এটি ব্যবহার করুন:

Kotlin

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

গ্ৰুভি

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

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

Kotlin

// 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 ডিপেন্ডেন্সি যোগ করতে , এটি দেখতে এইরকম হয়:

Kotlin

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.6.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.6.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-এর থেকে বেশি অগ্রাধিকার আছে।

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

Play Console-এর জন্য ডিপেন্ডেন্সি সংক্রান্ত তথ্য

আপনার অ্যাপ তৈরি করার সময়, 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 Studio, ভার্সন ক্যাটালগ ফাইল এবং প্রজেক্ট স্ট্রাকচার ডায়ালগ-এ লিন্ট সংক্রান্ত সতর্কতা দেখায়, যখন নিম্নলিখিত সমস্যাগুলি Google Play SDK Index-এ সর্বজনীন SDK-এর ক্ষেত্রে প্রযোজ্য হয়:

  • SDK-এর লেখক সেগুলিকে পুরনো হিসেবে চিহ্নিত করেছেন।
  • SDK-গুলি Play নীতি লঙ্ঘন করে।
  • SDK-তে নিরাপত্তা সংক্রান্ত দুর্বলতা আছে বলে জানা গেছে।
  • SDK-এর লেখক সেটির ব্যবহার বন্ধ করে দিয়েছেন।

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

ভার্সন ক্যাটালগ ছাড়াই বিল্ড ডিপেন্ডেন্সি যোগ করুন

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

Kotlin

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" লাইব্রেরির ১২.৩ ভার্সনের উপর নির্ভরতা ঘোষণা করে। রিমোট বাইনারি ডিপেন্ডেন্সি ঘোষণা নিম্নলিখিতগুলির জন্য শর্টহ্যান্ড:

Kotlin

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

গ্ৰুভি

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

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

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

Kotlin

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

গ্ৰুভি

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

আপনার যদি সিঙ্গল-মডিউল প্রোজেক্ট থাকে, তাহলে আপনি মডিউল-লেভেল বিল্ড স্ক্রিপ্টে স্পষ্টভাবে ভার্সন উল্লেখ করতে পারেন এবং প্রোজেক্ট-লেভেল বিল্ড স্ক্রিপ্ট খালি রাখতে পারেন:

Kotlin

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

গ্ৰুভি

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