build.gradle: এটি কী, সিনট্যাক্স এবং Android-এ কনফিগারেশন

লেখক: IT Sectr প্রকাশিত: 2026-05-31 পড়ার সময়: 9 মিনিট

build.gradle হল Gradle-এ Android প্রজেক্টের প্রধান বিল্ড ফাইল যাতে অ্যাপ্লিকেশন কম্পাইল, প্যাকেজ এবং সাইন করার নির্দেশনা থাকে। প্রজেক্টের প্রতিটি মডিউলের নিজস্ব build.gradle থাকে: একটি প্রজেক্ট স্তরে (project-level) এবং একটি প্রতিটি মডিউলের জন্য (module-level)। Google Android Developers, 2025 অনুসারে, সঠিক build.gradle কনফিগারেশন বিল্ডকে 40% পর্যন্ত দ্রুত করে এবং ডিপেন্ডেন্সি দ্বন্দ্ব দূর করে। সিনট্যাক্স দুটি ভাষা সমর্থন করে: Groovy (build.gradle) এবং Kotlin DSL (build.gradle.kts)।

মূল পয়েন্ট

  • build.gradle হল প্লাগইন সেটিংস, ডিপেন্ডেন্সি এবং Android কনফিগারেশন সহ Gradle বিল্ড ফাইল।
  • Project-level সব মডিউলের জন্য প্লাগইন এবং রিপোজিটরি নির্ধারণ করে।
  • Module-level buildTypes, productFlavors এবং sourceSets সহ android ব্লক ধারণ করে।
  • Groovy vs Kotlin DSL — দুটি সিনট্যাক্স; Kotlin DSL type-safety-র কারণে পছন্দনীয়।
  • dependencies লাইব্রেরি পরিচালনা করে: implementation, api, compileOnly, runtimeOnly।

build.gradle কী?

build.gradle হল Groovy (.gradle এক্সটেনশন) বা Kotlin (.gradle.kts) ভাষায় লেখা একটি বিল্ড স্ক্রিপ্ট যা Android অ্যাপ্লিকেশন কম্পাইলেশনের সকল দিক পরিচালনা করে। Gradle হল একটি স্বয়ংক্রিয় বিল্ড সিস্টেম যা Google 2013 সালে Android-এর জন্য মানক হিসেবে গ্রহণ করে। build.gradle বর্ণনা করে: কোন প্লাগইন প্রয়োগ করা হয়েছে (Android, Kotlin, লাইব্রেরি), কোন ডিপেন্ডেন্সি সংযুক্ত, কোন SDK সংস্করণ ব্যবহার করা হয়েছে, কীভাবে অ্যাপ্লিকেশন সাইন করবেন এবং কোথায় প্রকাশ করবেন।

বিল্ড প্রক্রিয়ায় তিনটি ধাপ অন্তর্ভুক্ত: Initialization (মডিউল আবিষ্কার), Configuration (build.gradle স্ক্রিপ্ট নির্বাহ), Execution (কার্য নির্বাহ)। build.gradle Configuration ধাপের সময় চলে, যখন Gradle টাস্ক গ্রাফ তৈরি করে। এই মুহুর্তে Build Variants নির্ধারিত হয়, ডিপেন্ডেন্সি গণনা করা হয় এবং টাস্ক কনফিগার করা হয়। গুরুত্বপূর্ণ: build.gradle হল কোড, শুধু কনফিগারেশন নয়। এতে শর্ত, লুপ, মেথড কল এবং বাহ্যিক স্ক্রিপ্ট ব্যবহার করা যেতে পারে।

Gradle ফাইলগুলি মডিউল রুটে (app/build.gradle) এবং প্রজেক্ট রুটে (build.gradle) সংরক্ষণ করা হয়। এছাড়াও, Gradle apply from সমর্থন করে — বাহ্যিক Gradle স্ক্রিপ্ট অন্তর্ভুক্ত করা। এটি পুনরাবৃত্তিমূলক লজিককে শেয়ার্ড সেটিংসের ফাইলে বের করার অনুমতি দেয়। Convention Plugins (AGP 7+) আবির্ভাবের সাথে, apply from অপ্রচলিত বলে মনে করা হয় — Convention Plugins মডিউলের মধ্যে কনফিগারেশন পুনঃব্যবহারের একটি type-safe এবং কম্পোজেবল উপায় প্রদান করে।

build.gradle-এর বিবর্তন

2013 সাল থেকে, build.gradle সিনট্যাক্সে উল্লেখযোগ্য পরিবর্তন হয়েছে: ডায়নামিক কনফিগারেশন সহ Groovy থেকে compile-time চেক সহ Kotlin DSL পর্যন্ত। AGP সংস্করণ 1.0 থেকে 8.7 (2025) পর্যন্ত বিবর্তিত হয়েছে। মূল মাইলস্টোন: AGP 3.0 (Java 8 desugar, নতুন variant API), AGP 4.0 (view binding, Java 11), AGP 7.0 (ডিফল্টরূপে Kotlin DSL, Java 11 ন্যূনতম), AGP 8.0 (non-transitive R classes, Kotlin-এ build config), AGP 8.7 (kapt-এর পরিবর্তে KSP, দ্রুত কনফিগারেশন)।

Project-level এবং Module-level build.gradle

Project-level build.gradle (রুট) সব মডিউলের জন্য সাধারণ প্লাগইন, রিপোজিটরি এবং কনফিগারেশন নির্ধারণ করে। প্রধান ব্লক: plugins (Gradle প্লাগইন ঘোষণা), repositories (ডিপেন্ডেন্সি উৎস: mavenCentral, google, jitpack)। রুট build.gradle-এ সাধারণত android ব্লক থাকে না — এটি মডিউলে দেখা যায়। Project-level-এ সমস্ত সাবপ্রজেক্টের সাধারণ কনফিগারেশনের জন্য subprojects ব্লক থাকতে পারে, যদিও Convention Plugins পছন্দনীয়।

Module-level build.gradle (উদাহরণস্বরূপ, app/build.gradle) একটি নির্দিষ্ট মডিউল বর্ণনা করে। যদি মডিউলটি একটি অ্যাপ্লিকেশন হয়, তাহলে এটি com.android.application প্লাগইন প্রয়োগ করে। যদি লাইব্রেরি হয় — com.android.library। Module-level-এ অন্তর্ভুক্ত: android ব্লক (compileSdk, defaultConfig, buildTypes, productFlavors), dependencies ব্লক (মডিউল ডিপেন্ডেন্সি) এবং ঐচ্ছিকভাবে পরীক্ষা এবং প্যাকেজিং কনফিগারেশনের জন্য ব্লক। Module-level project-level-এর পরে চলে এবং সাধারণ সেটিংস ওভাররাইড করতে পারে।

AGP 8.0 থেকে শুরু করে, রুট build.gradle কেন্দ্রীভূত ডিপেন্ডেন্সি সংস্করণ ব্যবস্থাপনার জন্য version catalogs (libs.versions.toml) ব্যবহার করতে পারে। version catalog হল gradle/ ডিরেক্টরিতে একটি ফাইল যাতে সংস্করণ, লাইব্রেরি এবং প্লাগইন থাকে। build.gradle-এ ডিপেন্ডেন্সি libs-এর মাধ্যমে সংযুক্ত হয়: implementation(libs.retrofit)। version catalogs নতুন প্রজেক্টের জন্য বাধ্যতামূলক এবং তিন বা ততোধিক মডিউল বিশিষ্ট সকল প্রজেক্টের জন্য সুপারিশকৃত।

kotlin
// settings.gradle.kts — প্রজেক্ট রুট
pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

// build.gradle.kts (project-level)
plugins {
    id("com.android.application") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "2.0.21" apply false
}

// app/build.gradle.kts (module-level)
plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
    id("com.google.devtools.ksp")
}

android {
    namespace = "com.example.myapp"
    compileSdk = 35

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 35
        versionCode = 1
        versionName = "1.0.0"
    }
}

Groovy vs Kotlin DSL

Groovy হল একটি ডায়নামিক JVM ভাষা যা Gradle-এর মূল সিনট্যাক্স ছিল। Groovy স্ক্রিপ্ট (.gradle) ডায়নামিক টাইপিং ব্যবহার করে: আপনি টাইপ বাদ দিতে পারেন, উদ্ধৃতি সহ বা ছাড়া স্ট্রিং ব্যবহার করতে পারেন, কম্পাইল সময়ে নেই এমন মেথড কল করতে পারেন। Groovy-এর নমনীয়তাই এর ত্রুটি: IDE স্ক্রিপ্ট নির্বাহ না হওয়া পর্যন্ত সিনট্যাক্স এবং টাইপ যাচাই করতে পারে না, যার ফলে ভুল প্যারামিটার নাম বা টাইপের কারণে runtime ত্রুটি হয়।

Kotlin DSL (.gradle.kts) Kotlin-এর স্ট্যাটিক টাইপিং ব্যবহার করে। IDE টাইপ যাচাই করে, অটোকমপ্লিটের মাধ্যমে উপলব্ধ প্যারামিটার সুপারিশ করে এবং সম্পাদনার সময় ত্রুটি হাইলাইট করে। Kotlin DSL Configuration ধাপে ধীর (.kts ফাইল বাইটকোডে কম্পাইল করার কারণে), কিন্তু Google ক্রমাগত কর্মক্ষমতা উন্নত করে: AGP 8.5+ Gradle Configuration Cache এবং Caching Kotlin DSL compilation ব্যবহার করে, যা পার্থক্য 1-2 সেকেন্ডে কমিয়ে আনে।

Google সকল নতুন প্রজেক্টের জন্য Kotlin DSL এবং বিদ্যমান প্রজেক্টের ক্রমিক মাইগ্রেশন সুপারিশ করে। Groovy থেকে Kotlin DSL-এ মাইগ্রেশন সরল: উদ্ধৃতি বন্ধনী দ্বারা প্রতিস্থাপিত হয়, টাইপ যোগ করা হয়, অপারেটর ফাংশনে রূপান্তরিত হয়। বেশিরভাগ লাইব্রেরি তাদের ডকুমেন্টেশনে Kotlin DSL উদাহরণ প্রদান করে। জটিল ক্ষেত্রে (Custom Plugin, Task Graph), Kotlin DSL type-safe API প্রদান করে এবং সেই ত্রুটিগুলি প্রতিরোধ করে যা Groovy-তে শুধুমাত্র runtime-এ আবিষ্কৃত হয়। Version catalogs (libs.versions.toml) উভয় সিনট্যাক্সের সাথে সমানভাবে কাজ করে।

বৈশিষ্ট্যGroovy (.gradle)Kotlin DSL (.gradle.kts)
টাইপিংডায়নামিকস্ট্যাটিক
IDE সমর্থনসীমিতপূর্ণ (অটোকমপ্লিট, টাইপ)
কনফিগারেশন গতিদ্রুত (কম্পাইলেশন নেই)ধীর (.kts কম্পাইলেশন)
ত্রুটিRuntimeCompile-time
সুপারিশশুধু পুরানো প্রজেক্টনতুন প্রজেক্ট এবং মাইগ্রেশন

android ব্লক: অ্যাপ কনফিগারেশন

compileSdk, minSdk এবং targetSdk

android ব্লক module-level build.gradle-এর কেন্দ্রীয় উপাদান। এর ভিতরে কনফিগার করা হয়: namespace (R এবং BuildConfig-এর জন্য), compileSdk, defaultConfig, buildTypes, productFlavors, sourceSets, compileOptions, packaging, bundle। android ব্লকের সকল প্যারামিটার শুধুমাত্র Android মডিউলে প্রযোজ্য। যদি মডিউলটি একটি লাইব্রেরি হয়, তাহলে application-এর পরিবর্তে লাইব্রেরি প্লাগইন ব্যবহার করা হয় এবং android ব্লকে applicationId অনুপস্থিত থাকে।

compileSdk হল SDK সংস্করণ যা দিয়ে কোড কম্পাইল করা হয়। এটি সর্বশেষ Android API-র সমান হওয়া উচিত (লেখার সময় — 35)। minSdk হল সমর্থনের জন্য ন্যূনতম API সংস্করণ। targetSdk হল সেই সংস্করণ যা অ্যাপ্লিকেশন টার্গেট করে (এই সংস্করণের আচরণগত পরিবর্তন প্রয়োগ হয়)। compileSdk এবং targetSdk-এর মধ্যে পার্থক্য: compileSdk উপলব্ধ API নির্ধারণ করে, targetSdk runtime আচরণ নির্ধারণ করে। সুপারিশ: compileSdk = সর্বশেষ, targetSdk = সর্বশেষ - 1 (নতুন পরিবর্তনের সাথে অভিযোজন পরীক্ষার জন্য)।

compileOptions Java সামঞ্জস্য সেট করে: sourceCompatibility এবং targetCompatibility। AGP 8+-এর কম্পাইলেশনের জন্য Java 17+ প্রয়োজন। packaging লাইব্রেরি থেকে ফাইল অন্তর্ভুক্তি পরিচালনা করে: META-INF দ্বন্দ্ব সমাধানের জন্য exclude, merge, pickFirst। buildFeatures ViewBinding, DataBinding, Compose সক্ষম/অক্ষম করে। aaptOptions রিসোর্স প্রক্রিয়াকরণ কনফিগার করে: ignoreAssetsPattern, cruncherEnabled। android ব্লকের প্রতিটি উপাদান বিল্ডের একটি নির্দিষ্ট দিক অপ্টিমাইজ করে।

kotlin
android {
    namespace = "com.example.myapp"
    compileSdk = 35
    buildToolsVersion = "35.0.0"

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 35
        versionCode = 5
        versionName = "2.3.1"

        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        getByName("debug") { isDebuggable = true }
        getByName("release") {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"))
        }
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }

    buildFeatures {
        viewBinding = true
        compose = true
    }
}

ডিপেন্ডেন্সি ব্যবস্থাপনা

BOM (Bill of Materials)

ডিপেন্ডেন্সি build.gradle-এ হল লাইব্রেরি এবং মডিউল যা প্রজেক্টের সাথে সংযুক্ত। dependencies ব্লক android ব্লকের সমান স্তরে থাকে। Gradle একাধিক কনফিগারেশন সমর্থন করে: implementation (লাইব্রেরি এই মডিউলে উপলব্ধ, ট্রানজিটিভ নয়), api (লাইব্রেরি নির্ভরশীল মডিউলের জন্য ট্রানজিটিভভাবে উপলব্ধ), compileOnly (শুধু কম্পাইলেশনের জন্য, APK-তে অন্তর্ভুক্ত নয়), runtimeOnly (শুধু runtime-এ), annotationProcessor / ksp (অ্যানোটেশন প্রসেসর), testImplementation (শুধু পরীক্ষার জন্য), androidTestImplementation (শুধু ইন্সট্রুমেন্টেশন পরীক্ষার জন্য)।

AGP 8.0 থেকে শুরু করে, Non-Transitive R classes — প্রতিটি লাইব্রেরির নিজস্ব R ক্লাস আছে, যা রিসোর্স দ্বন্দ্ব প্রতিরোধ করে। dependencies ব্লকে সঠিক কনফিগারেশন ব্যবহার করা গুরুত্বপূর্ণ: implementation ট্রানজিটিভ ডিপেন্ডেন্সি প্রকাশ করে না, যা বিল্ড দ্রুত করে। api সেগুলি প্রকাশ করে — যখন একটি লাইব্রেরি অন্য লাইব্রেরি থেকে টাইপ এক্সপোর্ট করে তখন ব্যবহার করা হয় (উদাহরণস্বরূপ, Retrofit তার পাবলিক API-তে OkHttp টাইপ ব্যবহার করে)।

সংস্করণ ব্যবস্থাপনার জন্য BOM (Bill of Materials) ব্যবহার করার সুপারিশ করা হয় — একটি বিল্ড ফাইল যা সামঞ্জস্যপূর্ণ লাইব্রেরি সংস্করণ নির্ধারণ করে। Firebase BOM: implementation(platform("com.google.firebase:firebase-bom:33.0.0"))। BOM সংযোগ করার পরে, আপনি সংস্করণ ছাড়া শুধু লাইব্রেরির নাম উল্লেখ করতে পারেন — BOM স্বয়ংক্রিয়ভাবে একটি সামঞ্জস্যপূর্ণ সংস্করণ নির্বাচন করবে। এটি বিভিন্ন লাইব্রেরির ট্রানজিটিভ ডিপেন্ডেন্সির মধ্যে দ্বন্দ্ব দূর করে। BOM Firebase, Compose, Kotlin, Ktor, AndroidX-এর জন্য উপলব্ধ।

kotlin
dependencies {
    // BOM — সংস্করণ ব্যবস্থাপনা
    implementation(platform("androidx.compose:compose-bom:2024.12.01"))
    implementation(platform("com.google.firebase:firebase-bom:33.0.0"))

    // AndroidX এবং Compose
    implementation("androidx.core:core-ktx")
    implementation("androidx.lifecycle:lifecycle-runtime-ktx")
    implementation("androidx.activity:activity-compose")
    implementation("androidx.compose.ui:ui")

    // Network
    implementation("com.squareup.retrofit2:retrofit:2.11.0")
    implementation("com.squareup.okhttp3:okhttp:4.12.0")

    // Firebase (BOM থেকে সংস্করণ)
    implementation("com.google.firebase:firebase-firestore")
    implementation("com.google.firebase:firebase-crashlytics")

    // পরীক্ষা
    testImplementation("junit:junit:4.13.2")
    androidTestImplementation("androidx.test.ext:junit:1.2.1")
}

মাল্টি-মডিউল প্রজেক্টে build.gradle

মাল্টি-মডিউল প্রজেক্টে, প্রতিটি মডিউলের নিজস্ব build.gradle থাকে। একটি মডিউল অন্যটির সাথে সংযোগ করতে সিনট্যাক্স implementation(project(":module-name")) ব্যবহার করা হয়। Gradle স্বয়ংক্রিয়ভাবে মডিউলটি পুনর্নির্মাণ করে যদি এর কনফিগারেশন পরিবর্তিত হয়। মাল্টি-মডিউল আর্কিটেকচার বিল্ড সময় উন্নত করে (ইনক্রিমেন্টাল বিল্ড, সমান্তরালতা) এবং ফিচার মডিউল, কোর মডিউল এবং লাইব্রেরির মধ্যে দায়িত্ব পৃথক করে।

মাল্টি-মডিউল প্রজেক্টের মূল সমস্যা হল কনফিগারেশন ডুপ্লিকেশন। যদি 10টি মডিউলের একই minSdk, compileSdk এবং Compose ডিপেন্ডেন্সি থাকে, তাহলে এটি ভিন্ন build.gradle ফাইলে 10টি কপি। সমাধান হল Convention Plugins (পূর্বে buildSrc)। Convention Plugin হল একটি Gradle প্লাগইন যা Kotlin-এ লেখা এবং মডিউলে প্রয়োগ করা হয়: plugins { id("myapp.android.library") }। প্লাগইনে সাধারণ কনফিগারেশন থাকে এবং পরিবর্তনগুলি অবিলম্বে সমস্ত মডিউলে প্রয়োগ হয়।

Convention Plugins সংগঠিত করার জন্য প্রজেক্ট রুটে build-logic/ ডিরেক্টরি ব্যবহার করা হয়। এতে settings.gradle-এ includeBuild এবং Kotlin প্লাগইন অন্তর্ভুক্ত থাকে। Convention Plugins প্রজেক্টের মধ্যে পুনঃব্যবহারের জন্য maven রিপোজিটরিতে প্রকাশ করা যেতে পারে। Google মাল্টি-মডিউল প্রজেক্টের জন্য মানক হিসেবে Convention Plugins সুপারিশ করে, যা subprojects { } এবং apply from প্রতিস্থাপন করে। Convention Plugins-এ স্যুইচ করলে মডিউলের build.gradle 10-15 লাইনে কমে যায়।

kotlin
// build-logic/src/main/kotlin/AndroidLibraryConventionPlugin.kt
class AndroidLibraryConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        with(target) {
            with(plugins) {
                apply("com.android.library")
                apply("org.jetbrains.kotlin.android")
            }
            extensions.configure<CommonExtension<*, *, *, *>> {
                compileSdk = 35
                defaultConfig { minSdk = 26 }
                compileOptions {
                    sourceCompatibility = JavaVersion.VERSION_17
                    targetCompatibility = JavaVersion.VERSION_17
                }
            }
        }
    }
}

// module/build.gradle.kts — Convention Plugin-এর পরে
plugins {
    id("myapp.android.library")
}

dependencies {
    implementation(project(":core:network"))
}

সচরাচর জিজ্ঞাসিত প্রশ্ন

2025 সালে build.gradle-এর জন্য কোন ভাষা নির্বাচন করা উচিত?

Kotlin DSL (.gradle.kts) হল Google-এর অফিসিয়াল সুপারিশ। স্ট্যাটিক টাইপিং ত্রুটি প্রতিরোধ করে, IDE অটোকমপ্লিট প্রদান করে। Groovy (.gradle) সমর্থিত, কিন্তু Gradle এবং AGP-র নতুন বৈশিষ্ট্যগুলি প্রাথমিকভাবে Kotlin DSL-এ পরীক্ষা করা হয়।

build.gradle-এ namespace কেন প্রয়োজন?

namespace জেনারেটেড ক্লাস (R.java, BuildConfig) এর জন্য প্যাকেজ নির্ধারণ করে। পূর্বে namespace AndroidManifest.xml-এ সেট করা হত। AGP 7+ থেকে শুরু করে, namespace শুধুমাত্র build.gradle-এ উল্লেখ করা হয়। মানটি applicationId-এর সাথে মিলতে হবে (অথবা applicationIdSuffix ব্যবহার করলে ভিন্ন হতে পারে)।

কীভাবে Gradle বিল্ড দ্রুত করবেন?

Gradle Configuration Cache (org.gradle.configuration-cache=true) সক্ষম করুন, Build Cache (org.gradle.caching=true) ব্যবহার করুন, kapt-এর পরিবর্তে KSP-তে যান, মাল্টি-মডিউল প্রজেক্ট ভাগ করুন এবং Convention Plugins ব্যবহার করুন। এছাড়াও অপ্রয়োজনীয় product flavors বন্ধ করুন: debug-এ শুধু একটি flavor বিল্ড করুন।

implementation এবং api-র মধ্যে পার্থক্য কী?

implementation: ডিপেন্ডেন্সি শুধুমাত্র মডিউলের ভিতরে দৃশ্যমান। নির্ভরশীল মডিউল ট্রানজিটিভ ক্লাসে অ্যাক্সেস পায় না। api: ডিপেন্ডেন্সি বাহ্যিকভাবে প্রকাশিত হয়। api ব্যবহার করুন যখন ডিপেন্ডেন্সির টাইপ মডিউলের পাবলিক API-তে ব্যবহার করা হয় (উদাহরণস্বরূপ, Retrofit OkHttp টাইপ এক্সপোর্ট করে)। implementation বিল্ড দ্রুত করে — Gradle implementation ডিপেন্ডেন্সি পরিবর্তন হলে নির্ভরশীল মডিউল পুনর্নির্মাণ করে না।

build.gradle কি iOS-এর জন্য ব্যবহার করা যেতে পারে?

build.gradle হল একটি Android-নির্দিষ্ট ফাইল। iOS-এর জন্য Xcode project (.xcodeproj) এবং Swift Package Manager (Package.swift) ব্যবহার করা হয়। তবে, ক্রস-প্ল্যাটফর্ম টুল (Kotlin Multiplatform, Flutter, React Native) আছে যেখানে build.gradle Android অংশ বিল্ড করতে ব্যবহৃত হয়। KMP-তে, build.gradle Android target কনফিগার করে।

সারাংশ

  • build.gradle হল Android প্রজেক্টের কেন্দ্রীয় বিল্ড ফাইল, যা প্লাগইন, ডিপেন্ডেন্সি এবং কনফিগারেশন পরিচালনা করে।
  • Project-level সাধারণ প্লাগইন এবং রিপোজিটরি নির্ধারণ করে; module-level-এ android ব্লক এবং মডিউল ডিপেন্ডেন্সি থাকে।
  • Kotlin DSL স্ট্যাটিক টাইপিংয়ের কারণে নতুন প্রজেক্টের জন্য সুপারিশকৃত সিনট্যাক্স।
  • android ব্লক compileSdk, defaultConfig, buildTypes, productFlavors এবং sourceSets কনফিগার করে।
  • ডিপেন্ডেন্সি implementation (লুকানো) এবং api (পাবলিক) ব্যবহার করে; BOM ট্রানজিটিভভাবে সংস্করণ পরিচালনা করে।
  • মাল্টি-মডিউল প্রজেক্ট কনফিগারেশন ডুপ্লিকেশন দূর করতে Convention Plugins প্রয়োগ করে।
  • সুপারিশ: পরিষ্কার এবং দ্রুত বিল্ডের জন্য Kotlin DSL, Version Catalogs এবং Convention Plugins-এ মাইগ্রেট করুন।

আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব

IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।

প্রকল্প নিয়ে আলোচনা করুন

আরও পড়ুন