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

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

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

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

নেটিভ ডিপেন্ডেন্সি যোগ ও পরিচালনা করার নির্দেশনার জন্য (যা সচরাচর দেখা যায় না), নেটিভ ডিপেন্ডেন্সি দেখুন।

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

  1. প্রজেক্ট ভিউতে gradle ডিরেক্টরির অধীনে অথবা অ্যান্ড্রয়েড ভিউতে Gradle Scripts- এর অধীনে থাকা libs.versions.toml নামক ভার্সন ক্যাটালগ ফাইলের [versions] সেকশনে আপনার কাঙ্ক্ষিত ডিপেন্ডেন্সির ভার্সনের জন্য একটি অ্যালিয়াস যোগ করুন।

    [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 ) ব্যবহার করে একটি লাইব্রেরি ডিপেন্ডেন্সি ঘোষণা করতে পারেন। প্রতিটি ডিপেন্ডেন্সি কনফিগারেশন, ডিপেন্ডেন্সিটি কীভাবে ব্যবহার করতে হবে সে সম্পর্কে গ্রেডলকে ভিন্ন ভিন্ন নির্দেশনা প্রদান করে। নিচের সারণিতে আপনার অ্যান্ড্রয়েড প্রজেক্টে একটি ডিপেন্ডেন্সির জন্য ব্যবহারযোগ্য প্রতিটি কনফিগারেশন বর্ণনা করা হয়েছে।

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

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

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

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

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

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

দ্রষ্টব্য: আপনি অ্যান্ড্রয়েড আর্কাইভ (AAR) নির্ভরতার সাথে ` compileOnly কনফিগারেশন ব্যবহার করতে পারবেন না।

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

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

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

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

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

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

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

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

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

  • যদি কোনো প্রসেসর কোটলিন সিম্বল প্রসেসর হিসেবে উপলব্ধ থাকে, তবে সেটিকে ksp ডিপেন্ডেন্সি হিসেবে ব্যবহার করুন। কোটলিন সিম্বল প্রসেসর ব্যবহারের বিস্তারিত জানতে 'Kotlin Symbol Processor' থেকে 'Migrate from kapt to ksp' দেখুন।
  • যদি প্রসেসরটি কোটলিন সিম্বল প্রসেসর হিসেবে উপলব্ধ না থাকে:
    • আপনার প্রজেক্টে যদি কোটলিন সোর্স থাকে (তবে জাভা সোর্সও থাকতে পারে), তাহলে তা অন্তর্ভুক্ত করতে kapt ব্যবহার করুন ।
    • আপনার প্রজেক্টে যদি শুধু জাভা সোর্স ব্যবহৃত হয়, তবে তা অন্তর্ভুক্ত করতে annotationProcessor ব্যবহার করুন।

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

lintChecks

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

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

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

কোটলিন 

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.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 চেয়ে উচ্চতর অগ্রাধিকার সম্পন্ন।

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

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

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

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

এসডিকে অন্তর্দৃষ্টি

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

  • এসডিকে-গুলো তাদের নির্মাতাদের দ্বারা সেকেলে হিসেবে চিহ্নিত করা হয়েছে।
  • এসডিকেগুলো প্লে-এর নীতিমালা লঙ্ঘন করে।
  • এসডিকেগুলোতে পরিচিত নিরাপত্তা দুর্বলতা রয়েছে।
  • এসডিকে-গুলো তাদের নির্মাতাদের দ্বারা অপ্রচলিত ঘোষণা করা হয়েছে।

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

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

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

কোটলিন 

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' লাইব্রেরির ১২.৩ সংস্করণের উপর একটি নির্ভরতা ঘোষণা করে। রিমোট বাইনারি নির্ভরতা ঘোষণাটি নিম্নলিখিতটির একটি সংক্ষিপ্ত রূপ:

কোটলিন 

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

গ্রুভি 

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

বিল্ড ফাইলটি 'mylibrary' নামের একটি অ্যান্ড্রয়েড লাইব্রেরি মডিউলের উপর নির্ভরতাও ঘোষণা করে; এই নামটি অবশ্যই আপনার 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'
}