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

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

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

বিল্ড নির্ভরতা যুক্ত এবং পরিচালনা করার সর্বোত্তম উপায় হল সংস্করণ ক্যাটালগ ব্যবহার করা, পদ্ধতিটি নতুন প্রকল্পগুলি ডিফল্টরূপে ব্যবহার করে। এই বিভাগে অ্যান্ড্রয়েড প্রকল্পগুলির জন্য ব্যবহৃত সবচেয়ে সাধারণ ধরনের কনফিগারেশনগুলি কভার করে; আরও বিকল্পের জন্য Gradle ডকুমেন্টেশন পড়ুন। For an example of an app that uses version catalogs, see Now in Android . আপনি যদি ইতিমধ্যেই সংস্করণ ক্যাটালগ ছাড়াই বিল্ড নির্ভরতা সেট আপ করে থাকেন এবং একটি মাল্টি-মডিউল প্রকল্প থাকে, আমরা স্থানান্তর করার পরামর্শ দিই।

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

নিম্নলিখিত উদাহরণে, আমরা আমাদের প্রকল্পে একটি দূরবর্তী বাইনারি নির্ভরতা ( জেটপ্যাক ম্যাক্রোবেঞ্চমার্ক লাইব্রেরি ), স্থানীয় লাইব্রেরি মডিউল নির্ভরতা ( 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
}

    Plugin references include plugins after the catalog name, and version references include versions after the catalog name (version references are uncommon; see Dependencies with same version numbers for examples of version references.) Library references don't include a libraries qualifier, so you can একটি লাইব্রেরি উপনামের শুরুতে versions বা plugins ব্যবহার করবেন না।

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

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

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

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

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

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

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

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

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

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

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

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

অ্যান্ড্রয়েড গ্রেডল প্লাগইন অনুমান করে যে একটি নির্ভরতা একটি টীকা প্রসেসর যদি এর JAR ফাইলে নিম্নলিখিত ফাইল থাকে:

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

যদি প্লাগইনটি কম্পাইল ক্লাসপথে থাকা একটি টীকা প্রসেসর সনাক্ত করে তবে এটি একটি বিল্ড ত্রুটি তৈরি করে।

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

kapt এবং apt হল আলাদা টুল যা কোটলিন বা জাভা কম্পাইলার এক্সিকিউট করার আগে টীকা প্রক্রিয়া করে।

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

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

টীকাগুলি প্রসেসর ব্যবহার সম্পর্কে আরও তথ্যের জন্য, টীকাগুলি প্রসেসর যুক্ত করুন ।

lintChecks

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

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

lintPublish অ্যান্ড্রয়েড লাইব্রেরি প্রকল্পগুলিতে এই কনফিগারেশনটি ব্যবহার করুন লিন্ট চেকগুলি অন্তর্ভুক্ত করতে যা আপনি গ্র্যাডলকে আপনার AAR-এ একটি lint.jar ফাইল এবং প্যাকেজে কম্পাইল করতে চান৷ এটি আপনার 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 মেটাডেটা অন্তর্ভুক্ত করে যা আপনার অ্যাপে কম্পাইল করা লাইব্রেরি নির্ভরতা বর্ণনা করে। আপনার অ্যাপ আপলোড করার সময়, 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'
}