বিল্ড ভেরিয়েন্ট কনফিগার করুন

এই পৃষ্ঠাটি আপনাকে দেখায় কিভাবে আপনি একটি একক প্রকল্প থেকে আপনার অ্যাপের বিভিন্ন সংস্করণ তৈরি করতে বিল্ড ভেরিয়েন্ট কনফিগার করতে পারেন এবং কীভাবে আপনার নির্ভরতা এবং সাইনিং কনফিগারেশনগুলি সঠিকভাবে পরিচালনা করবেন।

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

বিল্ড ভেরিয়েন্টগুলি আপনার বিল্ডের ধরন এবং পণ্যের স্বাদে কনফিগার করা সেটিংস, কোড এবং সংস্থানগুলিকে একত্রিত করতে নিয়মের একটি নির্দিষ্ট সেট ব্যবহার করে গ্রেডলের ফলাফল। যদিও আপনি বিল্ড ভেরিয়েন্টগুলি সরাসরি কনফিগার করেন না, আপনি বিল্ডের ধরন এবং পণ্যের স্বাদগুলি কনফিগার করেন যা তাদের গঠন করে।

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

বিল্ড প্রকারগুলি কনফিগার করুন

আপনি মডিউল-স্তরের build.gradle.kts ফাইলের android ব্লকের ভিতরে বিল্ড প্রকারগুলি তৈরি এবং কনফিগার করতে পারেন। আপনি যখন একটি নতুন মডিউল তৈরি করেন, তখন Android স্টুডিও স্বয়ংক্রিয়ভাবে ডিবাগ এবং রিলিজ বিল্ডের ধরন তৈরি করে। যদিও বিল্ড কনফিগারেশন ফাইলে ডিবাগ বিল্ড টাইপ প্রদর্শিত হয় না, তবে অ্যান্ড্রয়েড স্টুডিও এটিকে debuggable true দিয়ে কনফিগার করে। এটি আপনাকে নিরাপদ অ্যান্ড্রয়েড ডিভাইসে অ্যাপটিকে ডিবাগ করতে দেয় এবং জেনেরিক ডিবাগ কীস্টোর দিয়ে অ্যাপ সাইনিং কনফিগার করতে দেয়।

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

কোটলিন

android {
    defaultConfig {
        manifestPlaceholders["hostName"] = "www.example.com"
        ...
    }
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")
        }

        getByName("debug") {
            applicationIdSuffix = ".debug"
            isDebuggable = true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        create("staging") {
            initWith(getByName("debug"))
            manifestPlaceholders["hostName"] = "internal.example.com"
            applicationIdSuffix = ".debugStaging"
        }
    }
}

গ্রোভি

android {
    defaultConfig {
        manifestPlaceholders = [hostName:"www.example.com"]
        ...
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
            debuggable true
        }

        /**
         * The `initWith` property lets you copy configurations from other build types,
         * then configure only the settings you want to change. This one copies the debug build
         * type, and then changes the manifest placeholder and application ID.
         */
        staging {
            initWith debug
            manifestPlaceholders = [hostName:"internal.example.com"]
            applicationIdSuffix ".debugStaging"
        }
    }
}

দ্রষ্টব্য: আপনি যখন একটি বিল্ড কনফিগারেশন ফাইলে পরিবর্তন করেন, তখন Android স্টুডিওর প্রয়োজন হয় যে আপনি নতুন কনফিগারেশনের সাথে আপনার প্রকল্পটি সিঙ্ক করুন৷ আপনার প্রজেক্ট সিঙ্ক করতে, নোটিফিকেশন বারে Sync Now- এ ক্লিক করুন যা আপনি যখন কোনও পরিবর্তন করেন বা সিঙ্ক প্রজেক্টে ক্লিক করেন টুলবার থেকে। যদি অ্যান্ড্রয়েড স্টুডিও আপনার কনফিগারেশনে কোনো ত্রুটি লক্ষ্য করে, তাহলে বার্তা উইন্ডোটি সমস্যাটি বর্ণনা করতে দেখায়।

আপনি বিল্ড প্রকারের সাথে কনফিগার করতে পারেন এমন সমস্ত বৈশিষ্ট্য সম্পর্কে আরও জানতে, BuildType রেফারেন্স পড়ুন।

পণ্যের স্বাদ কনফিগার করুন

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

দ্রষ্টব্য: আপনাকে এখনও main/ ম্যানিফেস্ট ফাইলে package বৈশিষ্ট্য ব্যবহার করে একটি প্যাকেজের নাম উল্লেখ করতে হবে। R শ্রেণীতে উল্লেখ করতে বা কোনো আপেক্ষিক কার্যকলাপ বা পরিষেবা নিবন্ধন সমাধানের জন্য আপনাকে অবশ্যই আপনার উত্স কোডে সেই প্যাকেজের নামটি ব্যবহার করতে হবে। এটি আপনাকে আপনার সোর্স কোড পরিবর্তন না করেই প্রতিটি পণ্যের স্বাদকে প্যাকেজিং এবং বিতরণের জন্য একটি অনন্য আইডি দিতে applicationId ব্যবহার করতে দেয়।

সমস্ত স্বাদ অবশ্যই একটি নামযুক্ত স্বাদের মাত্রার অন্তর্গত হতে হবে, যা পণ্যের স্বাদের একটি গ্রুপ। আপনি একটি স্বাদ মাত্রা সব স্বাদ বরাদ্দ করা আবশ্যক; অন্যথায়, আপনি নিম্নলিখিত বিল্ড ত্রুটি পাবেন।

  Error: All flavors must now belong to a named flavor dimension.
  The flavor 'flavor_name' is not assigned to a flavor dimension.

যদি একটি প্রদত্ত মডিউল শুধুমাত্র একটি স্বাদের মাত্রা নির্দিষ্ট করে, তাহলে Android Gradle প্লাগইন স্বয়ংক্রিয়ভাবে মডিউলের সমস্ত স্বাদকে সেই মাত্রায় বরাদ্দ করে।

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

নিম্নলিখিত কোড নমুনা "সংস্করণ" নামে একটি স্বাদের মাত্রা তৈরি করে এবং "ডেমো" এবং "সম্পূর্ণ" পণ্যের স্বাদ যোগ করে। এই স্বাদগুলি তাদের নিজস্ব applicationIdSuffix এবং versionNameSuffix প্রদান করে:

কোটলিন

android {
    ...
    defaultConfig {...}
    buildTypes {
        getByName("debug"){...}
        getByName("release"){...}
    }
    // Specifies one flavor dimension.
    flavorDimensions += "version"
    productFlavors {
        create("demo") {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension = "version"
            applicationIdSuffix = ".demo"
            versionNameSuffix = "-demo"
        }
        create("full") {
            dimension = "version"
            applicationIdSuffix = ".full"
            versionNameSuffix = "-full"
        }
    }
}

গ্রোভি

android {
    ...
    defaultConfig {...}
    buildTypes {
        debug{...}
        release{...}
    }
    // Specifies one flavor dimension.
    flavorDimensions "version"
    productFlavors {
        demo {
            // Assigns this product flavor to the "version" flavor dimension.
            // If you are using only one dimension, this property is optional,
            // and the plugin automatically assigns all the module's flavors to
            // that dimension.
            dimension "version"
            applicationIdSuffix ".demo"
            versionNameSuffix "-demo"
        }
        full {
            dimension "version"
            applicationIdSuffix ".full"
            versionNameSuffix "-full"
        }
    }
}

দ্রষ্টব্য: আপনার যদি একটি লিগ্যাসি অ্যাপ (আগস্ট 2021 সালের আগে তৈরি) থাকে যা আপনি Google Play-তে APK ব্যবহার করে বিতরণ করেন, Google Play-তে একাধিক APK সমর্থন ব্যবহার করে আপনার অ্যাপ বিতরণ করার জন্য, সমস্ত ভেরিয়েন্টে একই applicationId মান বরাদ্দ করুন এবং প্রতিটি ভেরিয়েন্টকে একটি ভিন্ন versionCode দিন . আপনার অ্যাপের বিভিন্ন রূপকে Google Play-তে আলাদা অ্যাপ হিসেবে বিতরণ করতে, আপনাকে প্রতিটি ভেরিয়েন্টে একটি আলাদা applicationId বরাদ্দ করতে হবে।

আপনি আপনার পণ্যের স্বাদগুলি তৈরি এবং কনফিগার করার পরে, বিজ্ঞপ্তি বারে এখন সিঙ্ক করুন ক্লিক করুন৷ একবার সিঙ্ক সম্পূর্ণ হলে, গ্রেডল স্বয়ংক্রিয়ভাবে আপনার বিল্ডের ধরন এবং পণ্যের স্বাদের উপর ভিত্তি করে বিল্ড ভেরিয়েন্ট তৈরি করে এবং <product-flavor><Build-Type> অনুসারে তাদের নাম দেয়। উদাহরণস্বরূপ, আপনি যদি "ডেমো" এবং "সম্পূর্ণ" পণ্যের স্বাদ তৈরি করেন এবং ডিফল্ট "ডিবাগ" এবং "রিলিজ" বিল্ডের ধরন রাখেন, তাহলে Gradle নিম্নলিখিত বিল্ড ভেরিয়েন্টগুলি তৈরি করে:

• demoDebug
• demoRelease
• fullDebug
• fullRelease

কোন বিল্ড ভেরিয়েন্টটি তৈরি এবং চালানো হবে তা নির্বাচন করতে, বিল্ড > বিল্ড ভেরিয়েন্ট নির্বাচন করুন এবং মেনু থেকে একটি বিল্ড ভেরিয়েন্ট নির্বাচন করুন। প্রতিটি বিল্ড বৈকল্পিককে নিজস্ব বৈশিষ্ট্য এবং সংস্থানগুলির সাথে কাস্টমাইজ করা শুরু করতে, আপনাকে এই পৃষ্ঠায় বর্ণিত উত্স সেটগুলি তৈরি এবং পরিচালনা করতে হবে৷

বিল্ড ভেরিয়েন্টের জন্য অ্যাপ্লিকেশন আইডি পরিবর্তন করুন

আপনি যখন আপনার অ্যাপের জন্য একটি APK বা AAB তৈরি করেন, তখন বিল্ড টুলগুলি নিম্নলিখিত উদাহরণে দেখানো হয়েছে, build.gradle.kts ফাইল থেকে defaultConfig ব্লকে সংজ্ঞায়িত অ্যাপ্লিকেশন আইডি দিয়ে অ্যাপটিকে ট্যাগ করে। যাইহোক, যদি আপনি Google Play Store-এ "ফ্রি" এবং "প্রো" সংস্করণের মতো আলাদা তালিকা হিসাবে প্রদর্শিত হওয়ার জন্য আপনার অ্যাপের বিভিন্ন সংস্করণ তৈরি করতে চান, তাহলে আপনাকে আলাদা আলাদা বিল্ড ভেরিয়েন্ট তৈরি করতে হবে যার প্রত্যেকটির আলাদা অ্যাপ্লিকেশন আইডি আছে।

এই ক্ষেত্রে, প্রতিটি বিল্ড বৈকল্পিককে একটি পৃথক পণ্যের স্বাদ হিসাবে সংজ্ঞায়িত করুন। productFlavors ব্লকের প্রতিটি স্বাদের জন্য, আপনি applicationId বৈশিষ্ট্যটি পুনরায় সংজ্ঞায়িত করতে পারেন, অথবা আপনি applicationIdSuffix ব্যবহার করে ডিফল্ট অ্যাপ্লিকেশন আইডিতে একটি সেগমেন্ট যুক্ত করতে পারেন, যেমনটি এখানে দেখানো হয়েছে:

কোটলিন

android {
    defaultConfig {
        applicationId = "com.example.myapp"
    }
    productFlavors {
        create("free") {
            applicationIdSuffix = ".free"
        }
        create("pro") {
            applicationIdSuffix = ".pro"
        }
    }
}

গ্রোভি

android {
    defaultConfig {
        applicationId "com.example.myapp"
    }
    productFlavors {
        free {
            applicationIdSuffix ".free"
        }
        pro {
            applicationIdSuffix ".pro"
        }
    }
}

এইভাবে, "ফ্রি" পণ্যের স্বাদের জন্য অ্যাপ্লিকেশন আইডি হল "com.example.myapp.free"৷

আপনি আপনার বিল্ড টাইপের উপর ভিত্তি করে একটি সেগমেন্ট যুক্ত করতে applicationIdSuffix ব্যবহার করতে পারেন, যেমনটি এখানে দেখানো হয়েছে:

কোটলিন

android {
    ...
    buildTypes {
        getByName("debug") {
            applicationIdSuffix = ".debug"
        }
    }
}

গ্রোভি

android {
    ...
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
    }
}

যেহেতু Gradle প্রোডাক্ট ফ্লেভারের পরে বিল্ড টাইপ কনফিগারেশন প্রয়োগ করে, তাই "ফ্রি ডিবাগ" বিল্ড ভেরিয়েন্টের অ্যাপ্লিকেশন আইডি হল "com.example.myapp.free.debug"। আপনি যখন একই ডিভাইসে ডিবাগ এবং রিলিজ বিল্ড করতে চান তখন এটি কার্যকর, কারণ দুটি অ্যাপের একই অ্যাপ্লিকেশন আইডি থাকতে পারে না।

আপনার যদি একটি লিগ্যাসি অ্যাপ (আগস্ট 2021 সালের আগে তৈরি) থাকে যা আপনি Google Play-তে APK ব্যবহার করে বিতরণ করেন এবং আপনি একই অ্যাপের তালিকা ব্যবহার করে একাধিক APK বিতরণ করতে চান যেগুলির প্রত্যেকটি আলাদা ডিভাইস কনফিগারেশনকে লক্ষ্য করে, যেমন API স্তর, তাহলে আপনি প্রতিটি বিল্ড ভেরিয়েন্টের জন্য একই অ্যাপ্লিকেশান আইডি ব্যবহার করতে হবে তবে প্রতিটি APKকে আলাদা versionCode দিতে হবে। আরও তথ্যের জন্য, একাধিক APK সমর্থন সম্পর্কে পড়ুন। AABs ব্যবহার করে প্রকাশনা প্রভাবিত হয় না, কারণ এটি একটি একক আর্টিফ্যাক্ট ব্যবহার করে যা ডিফল্টরূপে একটি একক সংস্করণ কোড এবং অ্যাপ্লিকেশন আইডি ব্যবহার করে।

টিপ: আপনি যদি আপনার ম্যানিফেস্ট ফাইলে অ্যাপ্লিকেশন আইডি উল্লেখ করতে চান, আপনি যেকোনো ম্যানিফেস্ট অ্যাট্রিবিউটে ${applicationId} প্লেসহোল্ডার ব্যবহার করতে পারেন। একটি বিল্ড করার সময়, Gradle এই ট্যাগটিকে প্রকৃত অ্যাপ্লিকেশন আইডি দিয়ে প্রতিস্থাপন করে। আরও তথ্যের জন্য, ম্যানিফেস্টে বিল্ড ভেরিয়েবল ইনজেক্ট করুন ।

গন্ধ মাত্রা সঙ্গে একাধিক পণ্য স্বাদ একত্রিত

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

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

নিম্নলিখিত কোড নমুনাটি API স্তরের উপর ভিত্তি করে "সম্পূর্ণ" এবং "ডেমো" পণ্যের স্বাদগুলিকে গোষ্ঠীভুক্ত করতে একটি "মোড" স্বাদের মাত্রা তৈরি করতে এবং একটি "এপিআই" ফ্লেভারের মাত্রা তৈরি করতে flavorDimensions বৈশিষ্ট্য ব্যবহার করে:

কোটলিন

android {
  ...
  buildTypes {
    getByName("debug") {...}
    getByName("release") {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions += listOf("api", "mode")

  productFlavors {
    create("demo") {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension = "mode"
      ...
    }

    create("full") {
      dimension = "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    create("minApi24") {
      dimension = "api"
      minSdk = 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.
      versionCode = 30000 + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi24"
      ...
    }

    create("minApi23") {
      dimension = "api"
      minSdk = 23
      versionCode = 20000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi23"
      ...
    }

    create("minApi21") {
      dimension = "api"
      minSdk = 21
      versionCode = 10000  + (android.defaultConfig.versionCode ?: 0)
      versionNameSuffix = "-minApi21"
      ...
    }
  }
}
...

গ্রোভি

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list the dimensions determines their priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property, with the first dimension having a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion 24
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level.

      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion 23
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion 21
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

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

একটি উদাহরণ হিসাবে পূর্ববর্তী বিল্ড কনফিগারেশন ব্যবহার করে, Gradle নিম্নলিখিত নামকরণ স্কিম সহ মোট 12টি বিল্ড ভেরিয়েন্ট তৈরি করে:

• বিল্ড ভেরিয়েন্ট: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
• সংশ্লিষ্ট APK: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
যেমন,
বিল্ড ভেরিয়েন্ট: minApi24DemoDebug
সংশ্লিষ্ট APK: app-minApi24-demo-debug.apk

সোর্স সেট ডিরেক্টরিগুলি ছাড়াও আপনি প্রতিটি পণ্যের স্বাদের জন্য তৈরি করতে পারেন এবং বৈকল্পিক তৈরি করতে পারেন, আপনি পণ্যের স্বাদের প্রতিটি সংমিশ্রণের জন্য উত্স সেট ডিরেক্টরিও তৈরি করতে পারেন। উদাহরণস্বরূপ, আপনি src/demoMinApi24/java/ ডিরেক্টরিতে জাভা উত্সগুলি তৈরি করতে এবং যোগ করতে পারেন, এবং গ্রেডল শুধুমাত্র সেই উত্সগুলি ব্যবহার করে যখন একটি ভেরিয়েন্ট তৈরি করে যা এই দুটি পণ্যের স্বাদকে একত্রিত করে।

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

ফিল্টার বৈকল্পিক

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

উদাহরণ হিসাবে পূর্ববর্তী বিভাগ থেকে বিল্ড কনফিগারেশন ব্যবহার করে, ধরুন আপনি অ্যাপের ডেমো সংস্করণের জন্য শুধুমাত্র API স্তর 23 এবং উচ্চতর সমর্থন করার পরিকল্পনা করছেন। আপনি "minApi21" এবং "ডেমো" পণ্যের স্বাদকে একত্রিত করে এমন সমস্ত বিল্ড বৈকল্পিক কনফিগারেশন ফিল্টার করতে variantFilter ব্লক ব্যবহার করতে পারেন:

কোটলিন

android {
  ...
  buildTypes {...}

  flavorDimensions += listOf("api", "mode")
  productFlavors {
    create("demo") {...}
    create("full") {...}
    create("minApi24") {...}
    create("minApi23") {...}
    create("minApi21") {...}
  }
}

androidComponents {
    beforeVariants { variantBuilder ->
        // To check for a certain build type, use variantBuilder.buildType == "<buildType>"
        if (variantBuilder.productFlavors.containsAll(listOf("api" to "minApi21", "mode" to "demo"))) {
            // Gradle ignores any variants that satisfy the conditions above.
            variantBuilder.enable = false
        }
    }
}
...

গ্রোভি

android {
  ...
  buildTypes {...}

  flavorDimensions "api", "mode"
  productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
      def names = variant.flavors*.name
      // To check for a certain build type, use variant.buildType.name == "<buildType>"
      if (names.contains("minApi21") && names.contains("demo")) {
          // Gradle ignores any variants that satisfy the conditions above.
          setIgnore(true)
      }
  }
}
...

একবার আপনি আপনার বিল্ড কনফিগারেশনে একটি বৈকল্পিক ফিল্টার যোগ করলে এবং বিজ্ঞপ্তি বারে এখন সিঙ্ক করুন ক্লিক করুন, Gradle আপনার নির্দিষ্ট শর্ত পূরণ করে এমন কোনো বিল্ড ভেরিয়েন্টকে উপেক্ষা করে। বিল্ড ভেরিয়েন্টগুলি আর মেনুতে উপস্থিত হয় না যখন আপনি বিল্ড > মেনু বার থেকে বিল্ড ভেরিয়েন্ট বা বিল্ড ভেরিয়েন্টে ক্লিক করেন টুল উইন্ডো বারে।

সোর্স সেট তৈরি করুন

ডিফল্টরূপে, অ্যান্ড্রয়েড স্টুডিও আপনার সমস্ত বিল্ড ভেরিয়েন্টের মধ্যে শেয়ার করতে চান এমন সবকিছুর জন্য main/ উৎস সেট এবং ডিরেক্টরি তৈরি করে। যাইহোক, আপনি ঠিক কোন ফাইলগুলি Gradle কম্পাইল করে এবং নির্দিষ্ট বিল্ডের ধরন, পণ্যের স্বাদ, পণ্যের স্বাদের সংমিশ্রণ ( গন্ধের মাত্রা ব্যবহার করার সময়) এবং বিল্ড ভেরিয়েন্টগুলির জন্য প্যাকেজগুলি ঠিক করে তা নিয়ন্ত্রণ করতে আপনি নতুন উত্স সেট তৈরি করতে পারেন।

উদাহরণস্বরূপ, আপনি main/ উৎস সেটে মৌলিক কার্যকারিতা নির্ধারণ করতে পারেন এবং বিভিন্ন ক্লায়েন্টের জন্য আপনার অ্যাপের ব্র্যান্ডিং পরিবর্তন করতে পণ্যের স্বাদের উৎস সেট ব্যবহার করতে পারেন, অথবা শুধুমাত্র ডিবাগ বিল্ড টাইপ ব্যবহার করে এমন বিল্ড ভেরিয়েন্টের জন্য বিশেষ অনুমতি এবং লগিং কার্যকারিতা অন্তর্ভুক্ত করতে পারেন।

গ্রেডল আশা করে যে উত্স সেট ফাইল এবং ডিরেক্টরিগুলি একটি নির্দিষ্ট উপায়ে সংগঠিত হবে, main/ উত্স সেটের অনুরূপ। উদাহরণস্বরূপ, গ্রেডল আশা করে যে কোটলিন বা জাভা ক্লাস ফাইলগুলি যেগুলি আপনার "ডিবাগ" বিল্ড টাইপের জন্য নির্দিষ্ট সেগুলি src/debug/kotlin/ বা src/debug/java/ ডিরেক্টরিতে অবস্থিত।

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

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: debugCompile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Kotlin sources: [app/src/debug/kotlin, app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

এই আউটপুট দেখতে, নিম্নলিখিত হিসাবে এগিয়ে যান:

1. টুল উইন্ডো বারে Gradle ক্লিক করুন।

2. MyApplication > Tasks > android- এ নেভিগেট করুন এবং sourceSets-এ ডাবল-ক্লিক করুন।

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

   1. ফাইল > সেটিংস > পরীক্ষামূলক ( অ্যান্ড্রয়েড স্টুডিও > সেটিংস > ম্যাকওএসে পরীক্ষামূলক ) ক্লিক করুন।
   2. Gradle সিঙ্কের সময় Gradle টাস্ক লিস্ট তৈরি করবেন না তা অনির্বাচন করুন।
3. Gradle টাস্কটি কার্যকর করার পরে, রান উইন্ডোটি আউটপুট প্রদর্শনের জন্য খোলে।

দ্রষ্টব্য: টাস্ক আউটপুট আপনাকে দেখায় কিভাবে আপনি আপনার অ্যাপের জন্য পরীক্ষা চালানোর জন্য যে ফাইলগুলি ব্যবহার করতে চান তার জন্য সোর্স সেটগুলি সংগঠিত করবেন, যেমন test/ এবং androidTest/ টেস্টিং সোর্স সেট ৷

আপনি যখন একটি নতুন বিল্ড ভেরিয়েন্ট তৈরি করেন, তখন অ্যান্ড্রয়েড স্টুডিও আপনার জন্য সোর্স সেট ডিরেক্টরি তৈরি করে না, তবে এটি আপনাকে সাহায্য করার জন্য কয়েকটি বিকল্প দেয়। উদাহরণস্বরূপ, আপনার "ডিবাগ" বিল্ড টাইপের জন্য java/ ডিরেক্টরি তৈরি করতে:

1. প্রকল্প ফলকটি খুলুন এবং ফলকের শীর্ষে থাকা মেনু থেকে প্রকল্প দৃশ্যটি নির্বাচন করুন।
2. MyProject/app/src/ এ নেভিগেট করুন।
3. src ডিরেক্টরিতে ডান-ক্লিক করুন এবং নতুন > ডিরেক্টরি নির্বাচন করুন।
4. গ্রেডল সোর্স সেটের অধীনে মেনু থেকে, ফুল/জাভা নির্বাচন করুন।
5. এন্টার টিপুন।

অ্যান্ড্রয়েড স্টুডিও আপনার ডিবাগ বিল্ড টাইপের জন্য একটি সোর্স সেট ডিরেক্টরি তৈরি করে এবং তারপর এটির ভিতরে java/ ডিরেক্টরি তৈরি করে। বিকল্পভাবে, যখন আপনি একটি নির্দিষ্ট বিল্ড ভেরিয়েন্টের জন্য আপনার প্রকল্পে একটি নতুন ফাইল যোগ করেন তখন Android স্টুডিও আপনার জন্য ডিরেক্টরি তৈরি করতে পারে।

উদাহরণস্বরূপ, আপনার "ডিবাগ" বিল্ড টাইপের জন্য একটি মান XML ফাইল তৈরি করতে:

1. প্রকল্প ফলকে, src ডিরেক্টরিতে ডান-ক্লিক করুন এবং নতুন > XML > মান XML ফাইল নির্বাচন করুন।
2. XML ফাইলের নাম লিখুন বা ডিফল্ট নাম রাখুন।
3. টার্গেট সোর্স সেটের পাশের মেনু থেকে, ডিবাগ নির্বাচন করুন।
4. শেষ ক্লিক করুন.

যেহেতু "ডিবাগ" বিল্ড টাইপ টার্গেট সোর্স সেট হিসাবে নির্দিষ্ট করা হয়েছিল, Android স্টুডিও যখন XML ফাইল তৈরি করে তখন স্বয়ংক্রিয়ভাবে প্রয়োজনীয় ডিরেক্টরি তৈরি করে৷ ফলস্বরূপ ডিরেক্টরি গঠন চিত্র 1 এর মত দেখাচ্ছে।

চিত্র 1. "ডিবাগ" বিল্ড টাইপের জন্য নতুন উৎস সেট ডিরেক্টরি।

অ্যাক্টিভ সোর্স সেটের আইকনে একটি সবুজ সূচক থাকে যাতে তারা সক্রিয় তা দেখায়। debug সোর্স সেটটি [main] এর সাথে প্রত্যয়িত হয় তা দেখাতে যে এটি main উৎস সেটে একত্রিত হবে।

একই পদ্ধতি ব্যবহার করে, আপনি পণ্যের স্বাদের জন্য সোর্স সেট ডিরেক্টরিও তৈরি করতে পারেন, যেমন src/demo/ , এবং src/demoDebug/ মতো ভেরিয়েন্ট তৈরি করতে পারেন। অতিরিক্তভাবে, আপনি টেস্টিং সোর্স সেট তৈরি করতে পারেন যা নির্দিষ্ট বিল্ড ভেরিয়েন্টকে লক্ষ্য করে, যেমন src/androidTestDemoDebug/ । আরও জানতে, উৎস সেট পরীক্ষা করা সম্পর্কে পড়ুন।

ডিফল্ট সোর্স সেট কনফিগারেশন পরিবর্তন করুন

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

sourceSets ব্লক অবশ্যই android ব্লকে থাকতে হবে। আপনাকে সোর্স ফাইলগুলিকে স্থানান্তর করতে হবে না; আপনাকে শুধুমাত্র মডিউল-স্তরের build.gradle.kts ফাইলের সাপেক্ষে পাথ(গুলি) সহ Gradle প্রদান করতে হবে, যেখানে Gradle প্রতিটি সোর্স সেট কম্পোনেন্টের জন্য ফাইল খুঁজে পেতে পারে। আপনি কোন উপাদানগুলি কনফিগার করতে পারেন এবং আপনি সেগুলিকে একাধিক ফাইল বা ডিরেক্টরিতে ম্যাপ করতে পারেন কিনা তা জানতে, Android Gradle প্লাগইন API রেফারেন্স দেখুন।

নিম্নলিখিত কোড নমুনাটি app/other/ ডিরেক্টরি থেকে উত্সগুলিকে main উত্স সেটের নির্দিষ্ট উপাদানগুলিতে ম্যাপ করে এবং androidTest উত্স সেটের রুট ডিরেক্টরি পরিবর্তন করে:

কোটলিন

android {
  ...
  // Encapsulates configurations for the main source set.
  sourceSets.getByName("main") {
    // Changes the directory for Java sources. The default directory is
    // 'src/main/java'.
    java.setSrcDirs(listOf("other/java"))

    // If you list multiple directories, Gradle uses all of them to collect
    // sources. Because Gradle gives these directories equal priority, if
    // you define the same resource in more than one directory, you receive an
    // error when merging resources. The default directory is 'src/main/res'.
    res.setSrcDirs(listOf("other/res1", "other/res2"))

    // Note: Avoid specifying a directory that is a parent to one
    // or more other directories you specify. For example, avoid the following:
    // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
    // Specify either only the root 'other/res1' directory or only the
    // nested 'other/res1/layouts' and 'other/res1/strings' directories.

    // For each source set, you can specify only one Android manifest.
    // By default, Android Studio creates a manifest for your main source
    // set in the src/main/ directory.
    manifest.srcFile("other/AndroidManifest.xml")
    ...
  }

  // Create additional blocks to configure other source sets.
  sourceSets.getByName("androidTest") {
      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot("src/tests")
      ...
  }
}
...

গ্রোভি

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // If you list multiple directories, Gradle uses all of them to collect
      // sources. Because Gradle gives these directories equal priority, if
      // you define the same resource in more than one directory, you receive an
      // error when merging resources. The default directory is 'src/main/res'.
      res.srcDirs = ['other/res1', 'other/res2']

      // Note: Avoid specifying a directory that is a parent to one
      // or more other directories you specify. For example, avoid the following:
      // res.srcDirs = ['other/res1', 'other/res1/layouts', 'other/res1/strings']
      // Specify either only the root 'other/res1' directory or only the
      // nested 'other/res1/layouts' and 'other/res1/strings' directories.

      // For each source set, you can specify only one Android manifest.
      // By default, Android Studio creates a manifest for your main source
      // set in the src/main/ directory.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying the
      // configuration below for the androidTest source set, Gradle looks for Java
      // sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

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

সোর্স সেট দিয়ে তৈরি করুন

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

1. src/demoDebug/ (ভেরিয়েন্ট সোর্স সেট তৈরি করুন)
2. src/debug/ (বিল্ড টাইপ সোর্স সেট)
3. src/demo/ (পণ্যের স্বাদ উৎস সেট)
4. src/main/ (প্রধান উৎস সেট)

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

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

অগ্রাধিকার ক্রম নির্ধারণ করে যে কোন উৎস সেটে উচ্চতর অগ্রাধিকার রয়েছে যখন Gradle কোড এবং সংস্থানগুলিকে একত্রিত করে। কারণ demoDebug/ উৎস সেট ডিরেক্টরিতে সম্ভবত সেই বিল্ড ভেরিয়েন্টের জন্য নির্দিষ্ট ফাইল রয়েছে, যদি demoDebug/ একটি ফাইল অন্তর্ভুক্ত করে যা debug/ এও সংজ্ঞায়িত করা হয়, Gradle ফাইলটিকে demoDebug/ উৎস সেটে ব্যবহার করে। একইভাবে, গ্রেডল বিল্ড টাইপের ফাইল দেয় এবং প্রোডাক্ট ফ্লেভার সোর্স main/ এ একই ফাইলের তুলনায় উচ্চ অগ্রাধিকার সেট করে। নিম্নলিখিত বিল্ড নিয়মগুলি প্রয়োগ করার সময় Gradle এই অগ্রাধিকার আদেশটি বিবেচনা করে:

• kotlin/ বা java/ ডিরেক্টরির সমস্ত সোর্স কোড একটি একক আউটপুট তৈরি করতে একসাথে কম্পাইল করা হয়।

  দ্রষ্টব্য: একটি প্রদত্ত বিল্ড ভেরিয়েন্টের জন্য, Gradle একটি বিল্ড ত্রুটি নিক্ষেপ করে যদি এটি একই Kotlin বা Java ক্লাস সংজ্ঞায়িত করে এমন দুটি বা ততোধিক উৎস সেট ডিরেক্টরির সম্মুখীন হয়। উদাহরণস্বরূপ, একটি ডিবাগ অ্যাপ তৈরি করার সময়, আপনি src/debug/Utility.kt এবং src/main/Utility.kt উভয়কে সংজ্ঞায়িত করতে পারবেন না, কারণ গ্রেডল বিল্ড প্রক্রিয়া চলাকালীন এই দুটি ডিরেক্টরিই দেখে এবং একটি "ডুপ্লিকেট ক্লাস" ত্রুটি ছুড়ে দেয় . আপনি যদি বিভিন্ন ধরনের বিল্ডের জন্য Utility.kt এর বিভিন্ন সংস্করণ চান, প্রতিটি বিল্ড টাইপকে অবশ্যই ফাইলের নিজস্ব সংস্করণ সংজ্ঞায়িত করতে হবে এবং এটিকে main/ উৎস সেটে অন্তর্ভুক্ত করতে হবে না।

• ম্যানিফেস্টগুলিকে একক ম্যানিফেস্টে একত্রিত করা হয়৷ অগ্রাধিকার পূর্ববর্তী উদাহরণে তালিকা হিসাবে একই ক্রমে দেওয়া হয়. অর্থাৎ, একটি বিল্ড টাইপের জন্য ম্যানিফেস্ট সেটিংস একটি পণ্যের স্বাদের জন্য ম্যানিফেস্ট সেটিংসকে ওভাররাইড করে, ইত্যাদি। আরও জানতে, ম্যানিফেস্ট মার্জিং সম্পর্কে পড়ুন।
• values/ ডিরেক্টরির ফাইলগুলিকে একত্রিত করা হয়। যদি দুটি ফাইলের একই নাম থাকে, যেমন দুটি strings.xml ফাইল, অগ্রাধিকার পূর্ববর্তী উদাহরণে তালিকার মতো একই ক্রমে দেওয়া হয়। অর্থাৎ, বিল্ড টাইপ সোর্স সেটের একটি ফাইলে সংজ্ঞায়িত মানগুলি পণ্যের স্বাদে একই ফাইলে সংজ্ঞায়িত মানগুলিকে ওভাররাইড করে এবং আরও অনেক কিছু।
• res/ এবং asset/ ডিরেক্টরীতে সম্পদ একসাথে প্যাকেজ করা হয়। যদি দুই বা ততোধিক উৎস সেটে একই নামে সংজ্ঞায়িত সম্পদ থাকে, তাহলে অগ্রাধিকার পূর্ববর্তী উদাহরণে তালিকার মতো একই ক্রমে দেওয়া হয়।
• Gradle অ্যাপ তৈরি করার সময় লাইব্রেরি মডিউল নির্ভরতার সাথে অন্তর্ভুক্ত সংস্থান এবং ম্যানিফেস্টগুলিকে সর্বনিম্ন অগ্রাধিকার দেয়।

নির্ভরতা ঘোষণা করুন

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

কোটলিন

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    "freeImplementation"(project(":mylibrary"))

    // 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("com.android.support.test.espresso:espresso-core:3.6.1")
}

গ্রোভি

dependencies {
    // Adds the local "mylibrary" module as a dependency to the "free" flavor.
    freeImplementation project(":mylibrary")

    // 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 'com.android.support.test.espresso:espresso-core:3.6.1'
}

নির্ভরতা কনফিগার করার বিষয়ে আরও তথ্যের জন্য, বিল্ড নির্ভরতা যুক্ত করুন দেখুন।

বৈকল্পিক-সচেতন নির্ভরতা ব্যবস্থাপনা ব্যবহার করুন

অ্যান্ড্রয়েড গ্রেডল প্লাগইন 3.0.0 এবং উচ্চতর একটি নতুন নির্ভরতা প্রক্রিয়া অন্তর্ভুক্ত করে যা একটি লাইব্রেরি ব্যবহার করার সময় স্বয়ংক্রিয়ভাবে ভেরিয়েন্টের সাথে মেলে। এর মানে হল একটি অ্যাপের debug ভেরিয়েন্ট স্বয়ংক্রিয়ভাবে একটি লাইব্রেরির debug ভেরিয়েন্ট ব্যবহার করে, ইত্যাদি। এটি স্বাদগুলি ব্যবহার করার সময়ও কাজ করে: একটি অ্যাপের freeDebug ভেরিয়েন্ট একটি লাইব্রেরির freeDebug বৈকল্পিক গ্রাস করবে।

প্লাগইনটি সঠিকভাবে বৈকল্পিকগুলির সাথে মেলানোর জন্য, আপনাকে নিম্নলিখিত বিভাগে বর্ণিত মিলযুক্ত ফলব্যাকগুলি প্রদান করতে হবে, যেখানে সরাসরি মিল সম্ভব নয়।

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

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

বৈকল্পিক মিলের সাথে সম্পর্কিত বিল্ড ত্রুটিগুলি সমাধান করুন

প্লাগইনটিতে ডিএসএল উপাদান রয়েছে যাতে আপনি নিয়ন্ত্রণ করতে সাহায্য করেন যে কীভাবে গ্রেডল এমন পরিস্থিতিতে সমাধান করে যেখানে একটি অ্যাপ এবং নির্ভরতার মধ্যে সরাসরি বৈকল্পিক মিল সম্ভব নয়।

নিম্নে ভেরিয়েন্ট-সচেতন নির্ভরতা ম্যাচিং সম্পর্কিত সমস্যাগুলির একটি তালিকা এবং ডিএসএল বৈশিষ্ট্যগুলি ব্যবহার করে কীভাবে সেগুলি সমাধান করা যায়:

• আপনার অ্যাপটিতে একটি বিল্ড টাইপ রয়েছে যা একটি লাইব্রেরি নির্ভরতা করে না।

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

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

  একটি প্রদত্ত বিল্ড টাইপের জন্য বিকল্প মিলগুলি নির্দিষ্ট করতে matchingFallbacks ব্যবহার করুন, যেমনটি এখানে দেখানো হয়েছে:

  কোটলিন

  // In the app's build.gradle.kts file.
  android {
      buildTypes {
          getByName("debug") {}
          getByName("release") {}
          create("staging") {
              // Specifies a sorted list of fallback build types that the
              // plugin can try to use when a dependency does not include a
              // "staging" build type. You may specify as many fallbacks as you
              // like, and the plugin selects the first build type that's
              // available in the dependency.
              matchingFallbacks += listOf("debug", "qa", "release")
          }
      }
  }

  গ্রোভি

  // In the app's build.gradle file.
  android {
      buildTypes {
          debug {}
          release {}
          staging {
              // Specifies a sorted list of fallback build types that the
              // plugin can try to use when a dependency does not include a
              // "staging" build type. You may specify as many fallbacks as you
              // like, and the plugin selects the first build type that's
              // available in the dependency.
              matchingFallbacks = ['debug', 'qa', 'release']
          }
      }
  }
  

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

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

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

  অ্যাপের "ফ্রি" পণ্যের স্বাদের জন্য বিকল্প মিলগুলি নির্দিষ্ট করতে matchingFallbacks ব্যবহার করুন, যেমনটি এখানে দেখানো হয়েছে:

  কোটলিন

  // In the app's build.gradle.kts file.
  android {
      defaultConfig{
      // Don't configure matchingFallbacks in the defaultConfig block.
      // Instead, specify fallbacks for a given product flavor in the
      // productFlavors block, as shown below.
    }
      flavorDimensions += "tier"
      productFlavors {
          create("paid") {
              dimension = "tier"
              // Because the dependency already includes a "paid" flavor in its
              // "tier" dimension, you don't need to provide a list of fallbacks
              // for the "paid" flavor.
          }
          create("free") {
              dimension = "tier"
              // Specifies a sorted list of fallback flavors that the plugin
              // can try to use when a dependency's matching dimension does
              // not include a "free" flavor. Specify as many
              // fallbacks as you like; the plugin selects the first flavor
              // that's available in the dependency's "tier" dimension.
              matchingFallbacks += listOf("demo", "trial")
          }
      }
  }
  

  গ্রোভি

  // In the app's build.gradle file.
  android {
      defaultConfig{
      // Don't configure matchingFallbacks in the defaultConfig block.
      // Instead, specify fallbacks for a given product flavor in the
      // productFlavors block, as shown below.
    }
      flavorDimensions 'tier'
      productFlavors {
          paid {
              dimension 'tier'
              // Because the dependency already includes a "paid" flavor in its
              // "tier" dimension, you don't need to provide a list of fallbacks
              // for the "paid" flavor.
          }
          free {
              dimension 'tier'
              // Specifies a sorted list of fallback flavors that the plugin
              // can try to use when a dependency's matching dimension does
              // not include a "free" flavor. Specify as many
              // fallbacks as you like; the plugin selects the first flavor
              // that's available in the dependency's "tier" dimension.
              matchingFallbacks = ['demo', 'trial']
          }
      }
  }
  

• একটি লাইব্রেরি নির্ভরতা একটি স্বাদের মাত্রা অন্তর্ভুক্ত করে যা আপনার অ্যাপে নেই।

  উদাহরণস্বরূপ, একটি লাইব্রেরি নির্ভরতা একটি "minApi" মাত্রার জন্য স্বাদ অন্তর্ভুক্ত করে, কিন্তু আপনার অ্যাপে শুধুমাত্র "স্তরের" মাত্রার জন্য স্বাদ অন্তর্ভুক্ত করা হয়। আপনি যখন আপনার অ্যাপের "freeDebug" সংস্করণ তৈরি করতে চান, তখন প্লাগইনটি নির্ভরতার "minApi23Debug" বা "minApi18Debug" সংস্করণ ব্যবহার করবে কিনা তা জানে না।

  মনে রাখবেন যে আপনার অ্যাপে যখন লাইব্রেরি নির্ভরতা নয় এমন একটি স্বাদের মাত্রা অন্তর্ভুক্ত করে তখন কোনো সমস্যা নেই। কারণ প্লাগইন নির্ভরশীলতার মধ্যে বিদ্যমান মাত্রার স্বাদের সাথে মেলে। উদাহরণস্বরূপ, যদি একটি নির্ভরতা ABI-এর জন্য একটি মাত্রা অন্তর্ভুক্ত না করে, তাহলে আপনার অ্যাপের "freeX86Debug" সংস্করণটি নির্ভরতার "freeDebug" সংস্করণ ব্যবহার করবে।

  প্রতিটি অনুপস্থিত মাত্রা থেকে নির্বাচন করার জন্য প্লাগইনটির ডিফল্ট স্বাদ নির্দিষ্ট করতে defaultConfig ব্লকে missingDimensionStrategy ব্যবহার করুন, যেমনটি নিম্নলিখিত নমুনায় দেখানো হয়েছে। এছাড়াও আপনি productFlavors ব্লকে আপনার নির্বাচনগুলিকে ওভাররাইড করতে পারেন, তাই প্রতিটি স্বাদ একটি অনুপস্থিত মাত্রার জন্য একটি ভিন্ন ম্যাচিং কৌশল নির্দিষ্ট করতে পারে।

  কোটলিন

  // In the app's build.gradle.kts file.
  android {
      defaultConfig{
      // Specifies a sorted list of flavors that the plugin can try to use from
      // a given dimension. This tells the plugin to select the "minApi18" flavor
      // when encountering a dependency that includes a "minApi" dimension.
      // You can include additional flavor names to provide a
      // sorted list of fallbacks for the dimension.
      missingDimensionStrategy("minApi", "minApi18", "minApi23")
      // Specify a missingDimensionStrategy property for each
      // dimension that exists in a local dependency but not in your app.
      missingDimensionStrategy("abi", "x86", "arm64")
      }
      flavorDimensions += "tier"
      productFlavors {
          create("free") {
              dimension = "tier"
              // You can override the default selection at the product flavor
              // level by configuring another missingDimensionStrategy property
              // for the "minApi" dimension.
              missingDimensionStrategy("minApi", "minApi23", "minApi18")
          }
          create("paid") {}
      }
  }
  

  গ্রোভি

  // In the app's build.gradle file.
  android {
      defaultConfig{
      // Specifies a sorted list of flavors that the plugin can try to use from
      // a given dimension. This tells the plugin to select the "minApi18" flavor
      // when encountering a dependency that includes a "minApi" dimension.
      // You can include additional flavor names to provide a
      // sorted list of fallbacks for the dimension.
      missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
      // Specify a missingDimensionStrategy property for each
      // dimension that exists in a local dependency but not in your app.
      missingDimensionStrategy 'abi', 'x86', 'arm64'
      }
      flavorDimensions 'tier'
      productFlavors {
          free {
              dimension 'tier'
              // You can override the default selection at the product flavor
              // level by configuring another missingDimensionStrategy property
              // for the 'minApi' dimension.
              missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
          }
          paid {}
      }
  }
  

আরও তথ্যের জন্য, অ্যান্ড্রয়েড গ্রেডল প্লাগইন ডিএসএল রেফারেন্সে matchingFallbacks এবং missingDimensionStrategy দেখুন।

সাইনিং সেটিংস কনফিগার করুন

Gradle আপনার রিলিজ বিল্ডের APK বা AAB সাইন করে না যদি না আপনি এই বিল্ডের জন্য একটি সাইনিং কনফিগারেশন স্পষ্টভাবে সংজ্ঞায়িত করেন। যদি আপনার কাছে এখনও সাইনিং কী না থাকে, তাহলে অ্যান্ড্রয়েড স্টুডিও ব্যবহার করে একটি আপলোড কী এবং কীস্টোর তৈরি করুন ।

Gradle বিল্ড কনফিগারেশন ব্যবহার করে আপনার রিলিজ বিল্ড টাইপের জন্য সাইনিং কনফিগারেশন ম্যানুয়ালি কনফিগার করতে:

1. একটি কীস্টোর তৈরি করুন। একটি কীস্টোর হল একটি বাইনারি ফাইল যাতে ব্যক্তিগত কীগুলির একটি সেট থাকে। আপনাকে অবশ্যই আপনার কীস্টোর একটি নিরাপদ এবং নিরাপদ জায়গায় রাখতে হবে।
2. একটি ব্যক্তিগত কী তৈরি করুন। বিতরণের জন্য আপনার অ্যাপে স্বাক্ষর করতে একটি ব্যক্তিগত কী ব্যবহার করা হয় এবং অ্যাপের সাথে কখনই অন্তর্ভুক্ত করা হয় না বা অননুমোদিত তৃতীয় পক্ষের কাছে প্রকাশ করা হয় না।

3. মডিউল-স্তরের build.gradle.kts ফাইলে সাইনিং কনফিগারেশন যোগ করুন:

   কোটলিন

   ...
   android {
       ...
       defaultConfig {...}
       signingConfigs {
           create("release") {
               storeFile = file("myreleasekey.keystore")
               storePassword = "password"
               keyAlias = "MyReleaseKey"
               keyPassword = "password"
           }
       }
       buildTypes {
           getByName("release") {
               ...
               signingConfig = signingConfigs.getByName("release")
           }
       }
   }

   গ্রোভি

   ...
   android {
       ...
       defaultConfig {...}
       signingConfigs {
           release {
               storeFile file("myreleasekey.keystore")
               storePassword "password"
               keyAlias "MyReleaseKey"
               keyPassword "password"
           }
       }
       buildTypes {
           release {
               ...
               signingConfig signingConfigs.release
           }
       }
   }

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

পরিবেশ ভেরিয়েবল থেকে এই পাসওয়ার্ডগুলি পেতে:

কোটলিন

storePassword = System.getenv("KSTOREPWD")
keyPassword = System.getenv("KEYPWD")

গ্রোভি

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

বিকল্পভাবে, আপনি একটি স্থানীয় বৈশিষ্ট্য ফাইল থেকে কীস্টোর লোড করতে পারেন। নিরাপত্তার কারণে, উৎস নিয়ন্ত্রণে এই ফাইলটি যোগ করবেন না। পরিবর্তে, প্রতিটি বিকাশকারীর জন্য এটি স্থানীয়ভাবে সেট আপ করুন। আরও জানতে, আপনার বিল্ড ফাইল থেকে স্বাক্ষর তথ্য সরান পড়ুন।

আপনি এই প্রক্রিয়াটি সম্পূর্ণ করার পরে, আপনি আপনার অ্যাপটি বিতরণ করতে এবং Google Play-এ প্রকাশ করতে পারেন৷

সতর্কতা: আপনার কীস্টোর এবং প্রাইভেট কী একটি নিরাপদ এবং সুরক্ষিত জায়গায় রাখুন এবং নিশ্চিত করুন যে আপনার কাছে সেগুলির নিরাপদ ব্যাকআপ আছে। আপনি যদি প্লে অ্যাপ সাইনিং ব্যবহার করেন এবং আপনি আপনার আপলোড কী হারিয়ে ফেলেন, আপনি প্লে কনসোল ব্যবহার করে রিসেটের অনুরোধ করতে পারেন। আপনি যদি প্লে অ্যাপ সাইনিং ছাড়াই কোনো অ্যাপ প্রকাশ করেন (আগস্ট 2021 সালের আগে তৈরি অ্যাপের জন্য) এবং আপনি আপনার অ্যাপ সাইনিং কী হারিয়ে ফেলেন, তাহলে আপনি আপনার অ্যাপে কোনো আপডেট প্রকাশ করতে পারবেন না, কারণ আপনাকে অবশ্যই আপনার অ্যাপের সব সংস্করণে সাইন ইন করতে হবে একই কী।

Wear OS অ্যাপে সাইন ইন করা হচ্ছে

Wear OS অ্যাপ প্রকাশ করার সময়, ঘড়ির APK এবং ঐচ্ছিক ফোন APK উভয়কেই একই কী দিয়ে স্বাক্ষর করতে হবে। Wear OS অ্যাপের প্যাকেজিং এবং সাইনিং সম্পর্কে আরও তথ্যের জন্য, Wear অ্যাপের প্যাকেজ এবং বিতরণ দেখুন।