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

অ্যান্ড্রয়েড বিল্ড সিস্টেম অ্যাপের রিসোর্স ও সোর্স কোড কম্পাইল করে সেগুলোকে APK বা অ্যান্ড্রয়েড অ্যাপ বান্ডেলে প্যাকেজ করে, যা আপনি পরীক্ষা, ডেপ্লয়, সাইন এবং ডিস্ট্রিবিউট করতে পারেন।

Gradle বিল্ড ওভারভিউ এবং অ্যান্ড্রয়েড বিল্ড স্ট্রাকচার -এ আমরা বিল্ডের ধারণা এবং একটি অ্যান্ড্রয়েড অ্যাপের কাঠামো নিয়ে আলোচনা করেছি। এখন বিল্ড কনফিগার করার সময় এসেছে।

অ্যান্ড্রয়েড বিল্ড পরিভাষাকোষ

Gradle এবং Android Gradle প্লাগইন আপনাকে আপনার বিল্ডের নিম্নলিখিত দিকগুলো কনফিগার করতে সাহায্য করে:

নির্মাণের ধরণ

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

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

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

পণ্যের স্বাদ

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

বিভিন্ন নির্মাণ

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

ম্যানিফেস্ট এন্ট্রি

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

নির্ভরশীলতা

বিল্ড সিস্টেম আপনার লোকাল ফাইল সিস্টেম এবং রিমোট রিপোজিটরি থেকে প্রোজেক্টের ডিপেন্ডেন্সিগুলো পরিচালনা করে। এর মানে হলো, আপনাকে ম্যানুয়ালি আপনার ডিপেন্ডেন্সিগুলোর বাইনারি প্যাকেজ খুঁজে, ডাউনলোড করে এবং আপনার প্রোজেক্ট ডিরেক্টরিতে কপি করতে হবে না। আরও জানতে, ‘বিল্ড ডিপেন্ডেন্সি যোগ করুন ’ দেখুন।

স্বাক্ষর

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

কোড এবং রিসোর্স সংকোচন

বিল্ড সিস্টেম আপনাকে প্রতিটি বিল্ড ভ্যারিয়েন্টের জন্য একটি ভিন্ন ProGuard রুলস ফাইল নির্দিষ্ট করার সুযোগ দেয়। আপনার অ্যাপ বিল্ড করার সময়, বিল্ড সিস্টেম তার বিল্ট-ইন শ্রিংকিং টুল, যেমন R8, ব্যবহার করে আপনার কোড এবং রিসোর্স সঙ্কুচিত করার জন্য উপযুক্ত নিয়মাবলী প্রয়োগ করে। আপনার কোড এবং রিসোর্স সঙ্কুচিত করা আপনার APK বা AAB ফাইলের আকার কমাতে সাহায্য করতে পারে।

একাধিক APK সমর্থন

বিল্ড সিস্টেম আপনাকে স্বয়ংক্রিয়ভাবে বিভিন্ন APK তৈরি করতে দেয়, যেগুলোর প্রতিটিতে একটি নির্দিষ্ট স্ক্রিন ডেনসিটি বা অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABI)-এর জন্য শুধুমাত্র প্রয়োজনীয় কোড এবং রিসোর্স থাকে। আরও তথ্যের জন্য একাধিক APK তৈরি করুন দেখুন। তবে, একটি একক AAB প্রকাশ করাই প্রস্তাবিত পদ্ধতি, কারণ এটি স্ক্রিন ডেনসিটি এবং ABI-এর পাশাপাশি ভাষা অনুসারে বিভাজনের সুবিধা দেয় এবং গুগল প্লে-তে একাধিক আর্টিফ্যাক্ট আপলোড করার প্রয়োজনীয়তা এড়িয়ে চলে। ২০২১ সালের আগস্টের পরে জমা দেওয়া সমস্ত নতুন অ্যাপের জন্য AAB ব্যবহার করা বাধ্যতামূলক।

অ্যান্ড্রয়েড বিল্ডে জাভা সংস্করণ

আপনার সোর্স কোড জাভা, কোটলিন বা উভয়টিতেই লেখা হোক না কেন, আপনার বিল্ডের জন্য বেশ কয়েকটি জায়গায় আপনাকে অবশ্যই একটি JDK বা জাভা ল্যাঙ্গুয়েজ ভার্সন বেছে নিতে হবে। বিস্তারিত জানতে অ্যান্ড্রয়েড বিল্ডে জাভা ভার্সনগুলো দেখুন।

বিল্ড কনফিগারেশন ফাইল

কাস্টম বিল্ড কনফিগারেশন তৈরি করতে আপনাকে এক বা একাধিক বিল্ড কনফিগারেশন ফাইলে পরিবর্তন করতে হবে। এই প্লেইন-টেক্সট ফাইলগুলো কোটলিন স্ক্রিপ্ট ব্যবহার করে বিল্ড লজিক বর্ণনা ও পরিচালনা করার জন্য একটি ডোমেইন-স্পেসিফিক ল্যাঙ্গুয়েজ (DSL) ব্যবহার করে, যা কোটলিন ভাষারই একটি সংস্করণ। এছাড়াও, আপনার বিল্ড কনফিগার করার জন্য আপনি গ্রুভি (Groovy ) ব্যবহার করতে পারেন, যা জাভা ভার্চুয়াল মেশিন (JVM)-এর জন্য একটি ডাইনামিক ল্যাঙ্গুয়েজ।

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

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

গ্রেডল র‍্যাপার ফাইল

গ্রেডল র‍্যাপার ( gradlew ) হলো আপনার সোর্স কোডের সাথে অন্তর্ভুক্ত একটি ছোট অ্যাপ্লিকেশন, যা গ্রেডলকে ডাউনলোড ও চালু করে। এটি আরও সামঞ্জস্যপূর্ণ বিল্ড এক্সিকিউশন নিশ্চিত করে। ডেভেলপাররা অ্যাপ্লিকেশন সোর্স ডাউনলোড করে gradlew রান করেন। এটি প্রয়োজনীয় গ্রেডল ডিস্ট্রিবিউশন ডাউনলোড করে এবং আপনার অ্যাপ্লিকেশনটি বিল্ড করার জন্য গ্রেডল চালু করে।

gradle/wrapper/gradle-wrapper.properties ফাইলে distributionUrl একটি প্রপার্টি থাকে, যা বর্ণনা করে আপনার বিল্ড চালানোর জন্য গ্রেডলের কোন সংস্করণটি ব্যবহার করা হবে।

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

গ্রেডল সেটিংস ফাইল

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

বেশিরভাগ প্রোজেক্টের ক্ষেত্রে, ফাইলটি ডিফল্টরূপে নিম্নলিখিতের মতো দেখতে হয়:

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. Here we
      * define the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
      google()
      mavenCentral()
  }
}
rootProject.name = "My Application"
include(":app")

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. Here we
      * define the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "My Application"
include ':app'

শীর্ষ-স্তরের বিল্ড ফাইল

শীর্ষ-স্তরের build.gradle.kts ফাইল (Kotlin DSL-এর জন্য) অথবা build.gradle ফাইল (Groovy DSL-এর জন্য) প্রজেক্টের রুট ডিরেক্টরিতে অবস্থিত। এটি সাধারণত আপনার প্রজেক্টের মডিউলগুলোতে ব্যবহৃত প্লাগইনগুলোর সাধারণ সংস্করণগুলো নির্ধারণ করে।

নিম্নলিখিত কোড নমুনাটি একটি নতুন প্রজেক্ট তৈরি করার পরে টপ-লেভেল বিল্ড স্ক্রিপ্টের ডিফল্ট সেটিংস এবং DSL উপাদানগুলি বর্ণনা করে:

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id("com.android.application") version "9.2.0" apply false
    id("com.android.library") version "9.2.0" apply false
    id("org.jetbrains.kotlin.android") version "2.3.10" apply false
}

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id 'com.android.application' version '9.2.0' apply false
    id 'com.android.library' version '9.2.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.3.10' apply false
}

মডিউল-স্তরের বিল্ড ফাইল

মডিউল-স্তরের build.gradle.kts (Kotlin DSL-এর জন্য) অথবা build.gradle (Groovy DSL-এর জন্য) ফাইলটি প্রতিটি project / module / ডিরেক্টরিতে অবস্থিত। এটি আপনাকে নির্দিষ্ট মডিউলের জন্য বিল্ড সেটিংস কনফিগার করার সুযোগ দেয়। এই বিল্ড সেটিংস কনফিগার করার মাধ্যমে আপনি কাস্টম প্যাকেজিং অপশন, যেমন অতিরিক্ত বিল্ড টাইপ এবং প্রোডাক্ট ফ্লেভার, প্রদান করতে পারেন এবং main/ অ্যাপ ম্যানিফেস্ট বা টপ-লেভেল বিল্ড স্ক্রিপ্টের সেটিংস ওভাররাইড করতে পারেন।

অ্যান্ড্রয়েড এসডিকে সেটিংস

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

compileSdk

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

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

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

যদি আপনাকে একটি নির্দিষ্ট মাইনর এপিআই লেভেলের সাথে কম্পাইল করতে হয়, তাহলে বর্ধিত compileSdk ব্লক সিনট্যাক্স ব্যবহার করুন এবং একটি minorApiLevel নির্দিষ্ট করে দিন:

কোটলিন

    android {
        compileSdk {
            version = release(36) {
                minorApiLevel = 1
            }
        }
    }
    

গ্রুভি

    android {
        compileSdk {
            version = release(36) {
                minorApiLevel = 1
            }
        }
    }
    

আপনার compileSdk Android Studio-র বর্তমান সংস্করণ, AGP, বা আপনার প্রোজেক্টের লাইব্রেরি নির্ভরতার প্রয়োজনীয়তার সাথে সাংঘর্ষিক হলে Android Studio সতর্কবার্তা প্রদর্শন করে।

minSdk

minSdk অ্যান্ড্রয়েডের সর্বনিম্ন সংস্করণ নির্দিষ্ট করে, যা আপনার অ্যাপ সমর্থন করবে। minSdk সেট করার মাধ্যমে কোন কোন ডিভাইসে আপনার অ্যাপ ইনস্টল করা যাবে তা সীমাবদ্ধ করা হয়।

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

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

targetSdk

targetSdk দুটি উদ্দেশ্য পূরণ করে:

1. এটি আপনার অ্যাপ্লিকেশনের রানটাইম আচরণ নির্ধারণ করে।
2. এটি প্রমাণ করে যে আপনি অ্যান্ড্রয়েডের কোন সংস্করণের সাথে পরীক্ষাটি করেছেন।

আপনি যদি এমন কোনো ডিভাইসে আপনার অ্যাপ চালান যা আপনার targetSdk এর চেয়ে উচ্চতর অ্যান্ড্রয়েড সংস্করণ ব্যবহার করছে, তাহলে অ্যান্ড্রয়েড আপনার অ্যাপটিকে এমন একটি কম্প্যাটিবিলিটি মোডে চালায় যা আপনার targetSdk এ নির্দেশিত নিম্নতর সংস্করণের মতোই আচরণ করে। উদাহরণস্বরূপ, যখন API 23 রানটাইম পারমিশন মডেল চালু করেছিল, তখন সব অ্যাপ তাৎক্ষণিকভাবে এটি গ্রহণ করার জন্য প্রস্তুত ছিল না। targetSdk 22-এ সেট করার মাধ্যমে, সেই অ্যাপগুলো রানটাইম পারমিশন ব্যবহার না করেই API 23 ডিভাইসগুলোতে চলতে পারত এবং সর্বশেষ compileSdk সংস্করণে অন্তর্ভুক্ত ফিচারগুলো ব্যবহার করতে পারত। Google Play ডিস্ট্রিবিউশন পলিসি টার্গেট API লেভেলের উপর অতিরিক্ত নীতি প্রয়োগ করে।

targetSdk এর মানের সাথে compileSdk এর মানের কোনো সম্পর্ক নেই। উদাহরণস্বরূপ, targetSdk এর মান compileSdk চেয়ে বেশি, সমান বা কম হতে পারে।

নমুনা অ্যাপ-মডিউল বিল্ড স্ক্রিপ্ট

এই নমুনা অ্যান্ড্রয়েড অ্যাপ মডিউল বিল্ড স্ক্রিপ্টটি কিছু মৌলিক DSL উপাদান এবং সেটিংসের রূপরেখা তুলে ধরেছে:

/**
 * The first section in the build configuration applies the Android Gradle plugin
 * to this build and makes the android block available to specify
 * Android-specific build options.
 */

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

/**
 * Locate (and possibly download) a JDK used to build your kotlin
 * source code. This also acts as a default for sourceCompatibility,
 * targetCompatibility and jvmTarget. Note that this does not affect which JDK
 * is used to run the Gradle build itself, and does not need to take into
 * account the JDK version required by Gradle plugins (such as the
 * Android Gradle Plugin)
 */
kotlin {
    jvmToolchain(11)
}

/**
 * The android block is where you configure all your Android-specific
 * build options.
 */

android {

    /**
     * The app's namespace. Used primarily to access app resources.
     */

    namespace = "com.example.myapp"

    /**
     * compileSdk specifies the Android API level Gradle should use to
     * compile your app. This means your app can use the API features included in
     * this API level and lower.
     */

    compileSdk = 36

    /**
     * The defaultConfig block encapsulates default settings and entries for all
     * build variants and can override some attributes in main/AndroidManifest.xml
     * dynamically from the build system. You can configure product flavors to override
     * these values for different versions of your app.
     */

    defaultConfig {

        // Uniquely identifies the package for publishing.
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdk = 23

        // Specifies the API level used to test the app.
        targetSdk = 36

        // Defines the version number of your app.
        versionCode = 1

        // Defines a user-friendly version name for your app.
        versionName = "1.0"
    }

    /**
     * The buildTypes block is where you can configure multiple build types.
     * By default, the build system defines two build types: debug and release. The
     * debug build type is not explicitly shown in the default build configuration,
     * but it includes debugging tools and is signed with the debug key. The release
     * build type applies ProGuard settings and is not signed by default.
     */

    buildTypes {

        /**
         * By default, Android Studio configures the release build type to enable code
         * shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
         */

        getByName("release") {
            isMinifyEnabled = true // Enables code shrinking for the release build type.
            proguardFiles(
                getDefaultProguardFile("proguard-android.txt"),
                "proguard-rules.pro"
            )
        }
    }

    /**
     * The productFlavors block is where you can configure multiple product flavors.
     * This lets you create different versions of your app that can
     * override the defaultConfig block with their own settings. Product flavors
     * are optional, and the build system does not create them by default.
     *
     * This example creates a free and paid product flavor. Each product flavor
     * then specifies its own application ID, so that they can exist on the Google
     * Play Store or an Android device simultaneously.
     *
     * If you declare product flavors, you must also declare flavor dimensions
     * and assign each flavor to a flavor dimension.
     */

    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            dimension = "tier"
            applicationId = "com.example.myapp.free"
        }

        create("paid") {
            dimension = "tier"
            applicationId = "com.example.myapp.paid"
        }
    }

    /**
     * To override source and target compatibility (if different from the
     * toolchain JDK version), add the following. All of these
     * default to the same value as kotlin.jvmToolchain. If you're using the
     * same version for these values and kotlin.jvmToolchain, you can
     * remove these blocks.
     */
    //compileOptions {
    //    sourceCompatibility = JavaVersion.VERSION_11
    //    targetCompatibility = JavaVersion.VERSION_11
    //}
    //kotlinOptions {
    //    jvmTarget = "11"
    //}
}

/**
 * The dependencies block in the module-level build configuration file
 * specifies dependencies required to build only the module itself.
 * To learn more, go to Add build dependencies.
 */

dependencies {
    implementation(project(":lib"))
    implementation("androidx.appcompat:appcompat:1.7.1")
    implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}

/**
 * The first line in the build configuration applies the Android Gradle plugin
 * to this build and makes the android block available to specify
 * Android-specific build options.
 */

plugins {
    id 'com.android.application'
}

/**
 * Locate (and possibly download) a JDK used to build your kotlin
 * source code. This also acts as a default for sourceCompatibility,
 * targetCompatibility and jvmTarget. Note that this does not affect which JDK
 * is used to run the Gradle build itself, and does not need to take into
 * account the JDK version required by Gradle plugins (such as the
 * Android Gradle Plugin)
 */
kotlin {
    jvmToolchain 11
}

/**
 * The android block is where you configure all your Android-specific
 * build options.
 */

android {

    /**
     * The app's namespace. Used primarily to access app resources.
     */

    namespace 'com.example.myapp'

    /**
     * compileSdk specifies the Android API level Gradle should use to
     * compile your app. This means your app can use the API features included in
     * this API level and lower.
     */

    compileSdk 36

    /**
     * The defaultConfig block encapsulates default settings and entries for all
     * build variants and can override some attributes in main/AndroidManifest.xml
     * dynamically from the build system. You can configure product flavors to override
     * these values for different versions of your app.
     */

    defaultConfig {

        // Uniquely identifies the package for publishing.
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdk 23

        // Specifies the API level used to test the app.
        targetSdk 36

        // Defines the version number of your app.
        versionCode 1

        // Defines a user-friendly version name for your app.
        versionName "1.0"
    }

    /**
     * The buildTypes block is where you can configure multiple build types.
     * By default, the build system defines two build types: debug and release. The
     * debug build type is not explicitly shown in the default build configuration,
     * but it includes debugging tools and is signed with the debug key. The release
     * build type applies ProGuard settings and is not signed by default.
     */

    buildTypes {

        /**
         * By default, Android Studio configures the release build type to enable code
         * shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
         */

        release {
              minifyEnabled true // Enables code shrinking for the release build type.
              proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    /**
     * The productFlavors block is where you can configure multiple product flavors.
     * This lets you create different versions of your app that can
     * override the defaultConfig block with their own settings. Product flavors
     * are optional, and the build system does not create them by default.
     *
     * This example creates a free and paid product flavor. Each product flavor
     * then specifies its own application ID, so that they can exist on the Google
     * Play Store or an Android device simultaneously.
     *
     * If you declare product flavors, you must also declare flavor dimensions
     * and assign each flavor to a flavor dimension.
     */

    flavorDimensions "tier"
    productFlavors {
        free {
            dimension "tier"
            applicationId 'com.example.myapp.free'
        }

        paid {
            dimension "tier"
            applicationId 'com.example.myapp.paid'
        }
    }

    /**
     * To override source and target compatibility (if different from the
     * tool chain JDK version), add the following. All of these
     * default to the same value as kotlin.jvmToolchain. If you're using the
     * same version for these values and kotlin.jvmToolchain, you can
     * remove these blocks.
     */
    //compileOptions {
    //    sourceCompatibility JavaVersion.VERSION_11
    //    targetCompatibility JavaVersion.VERSION_11
    //}
    //kotlinOptions {
    //    jvmTarget = '11'
    //}
}

/**
 * The dependencies block in the module-level build configuration file
 * specifies dependencies required to build only the module itself.
 * To learn more, go to Add build dependencies.
 */

dependencies {
    implementation project(":lib")
    implementation 'androidx.appcompat:appcompat:1.7.1'
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

গ্রেডল প্রোপার্টি ফাইল

গ্রেডলে দুটি প্রপার্টিজ ফাইলও অন্তর্ভুক্ত থাকে, যা আপনার রুট প্রজেক্ট ডিরেক্টরিতে অবস্থিত এবং এগুলি ব্যবহার করে আপনি গ্রেডল বিল্ড টুলকিটের নিজস্ব সেটিংস নির্দিষ্ট করতে পারেন:

gradle.properties

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

local.properties

বিল্ড সিস্টেমের জন্য স্থানীয় পরিবেশের বৈশিষ্ট্যগুলো কনফিগার করে, যার মধ্যে নিম্নলিখিতগুলো অন্তর্ভুক্ত:

• ndk.dir - এনডিকে (NDK)-এর পাথ। এই প্রপার্টিটি এখন আর ব্যবহৃত হয় না। ডাউনলোড করা এনডিকে-এর যেকোনো সংস্করণ অ্যান্ড্রয়েড এসডিকে (Android SDK) ডিরেক্টরির ভেতরের ndk ডিরেক্টরিতে ইনস্টল করা হয়।
• sdk.dir - অ্যান্ড্রয়েড এসডিকে-এর পাথ।
• cmake.dir - CMake-এর পথ।
• ndk.symlinkdir - অ্যান্ড্রয়েড স্টুডিও ৩.৫ এবং তার পরবর্তী সংস্করণগুলোতে, এটি NDK-এর একটি সিমলিঙ্ক তৈরি করে যা ইনস্টল করা NDK পাথের চেয়ে ছোট হতে পারে।

NDK-কে একটি সংক্ষিপ্ত পাথে রিম্যাপ করুন (শুধুমাত্র উইন্ডোজের জন্য)

উইন্ডোজে, ইনস্টল করা NDK ফোল্ডারের টুলগুলো, যেমন ld.exe , দীর্ঘ পাথ ব্যবহার করে। টুলগুলো দীর্ঘ পাথ ভালোভাবে সাপোর্ট করে না।

একটি সংক্ষিপ্ত পাথ তৈরি করতে, local.properties ফাইলে ndk.symlinkdir প্রপার্টিটি সেট করুন, যাতে অ্যান্ড্রয়েড গ্রেডল প্লাগইন NDK-এর একটি সিমলিঙ্ক তৈরি করে। এই সিমলিঙ্কের পাথটি বিদ্যমান NDK ফোল্ডারের চেয়ে ছোট হতে পারে। উদাহরণস্বরূপ, ndk.symlinkdir = C:\ এর ফলে নিম্নলিখিত সিমলিঙ্কটি তৈরি হবে: C:\ndk\19.0.5232133

প্রজেক্টটি গ্রেডল ফাইলের সাথে সিঙ্ক করুন

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

আপনার প্রোজেক্ট ফাইলগুলো সিঙ্ক করতে, কোনো পরিবর্তন করার পর প্রদর্শিত নোটিফিকেশন বারে থাকা ‘Sync Now’- তে ক্লিক করুন (যেমনটি চিত্র ২-এ দেখানো হয়েছে), অথবা ‘Sync Project’-এ ক্লিক করুন। মেনু বার থেকে। যদি অ্যান্ড্রয়েড স্টুডিও আপনার কনফিগারেশনে কোনো ত্রুটি খুঁজে পায় — উদাহরণস্বরূপ, আপনার সোর্স কোডে এমন এপিআই ফিচার ব্যবহৃত হয়েছে যা কেবল আপনার compileSdkVersion চেয়ে উচ্চতর এপিআই লেভেলে উপলব্ধ — তাহলে মেসেজেস উইন্ডোটি সমস্যাটি বর্ণনা করে।

উৎস সেট

অ্যান্ড্রয়েড স্টুডিও প্রতিটি মডিউলের সোর্স কোড এবং রিসোর্সগুলোকে যৌক্তিকভাবে সোর্স সেটে ভাগ করে। যখন আপনি একটি নতুন মডিউল তৈরি করেন, অ্যান্ড্রয়েড স্টুডিও সেই মডিউলের মধ্যে একটি main/ সোর্স সেট তৈরি করে। একটি মডিউলের main/ সোর্স সেটে তার সমস্ত বিল্ড ভ্যারিয়েন্ট দ্বারা ব্যবহৃত কোড এবং রিসোর্স অন্তর্ভুক্ত থাকে।

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

src/main/

এই সোর্স সেটে সকল বিল্ড ভ্যারিয়েন্টের জন্য সাধারণ কোড এবং রিসোর্স অন্তর্ভুক্ত রয়েছে।

src/ buildType /

শুধুমাত্র একটি নির্দিষ্ট বিল্ড টাইপের জন্য কোড ও রিসোর্স অন্তর্ভুক্ত করতে এই সোর্স সেটটি তৈরি করুন।

src/ productFlavor /

শুধুমাত্র একটি নির্দিষ্ট প্রোডাক্ট ফ্লেভারের জন্য কোড ও রিসোর্স অন্তর্ভুক্ত করতে এই সোর্স সেটটি তৈরি করুন।

দ্রষ্টব্য: আপনি যদি একাধিক প্রোডাক্ট ফ্লেভার একত্রিত করার জন্য আপনার বিল্ড কনফিগার করেন, তাহলে আপনি ফ্লেভার ডাইমেনশনগুলোর মধ্যে প্রতিটি প্রোডাক্ট ফ্লেভারের সংমিশ্রণের জন্য সোর্স সেট ডিরেক্টরি তৈরি করতে পারেন: src/ productFlavor1 ProductFlavor2 / ।

src/ productFlavorBuildType /

শুধুমাত্র একটি নির্দিষ্ট বিল্ড ভ্যারিয়েন্টের জন্য কোড ও রিসোর্স অন্তর্ভুক্ত করতে এই সোর্স সেটটি তৈরি করুন।

উদাহরণস্বরূপ, আপনার অ্যাপের 'fullDebug' সংস্করণ তৈরি করতে, বিল্ড সিস্টেম নিম্নলিখিত উৎস সেটগুলো থেকে কোড, সেটিংস এবং রিসোর্স একত্রিত করে:

• src/fullDebug/ (বিল্ড ভ্যারিয়েন্ট সোর্স সেট)
• src/debug/ (বিল্ড টাইপ সোর্স সেট)
• src/full/ (পণ্যের ফ্লেভারের উৎস সেট)
• src/main/ (প্রধান উৎস সেট)

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

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

বিল্ড ভ্যারিয়েন্ট > বিল্ড টাইপ > প্রোডাক্ট ফ্লেভার > মূল সোর্স সেট > লাইব্রেরি নির্ভরতা

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

একাধিক ম্যানিফেস্ট মার্জ করার সময়, গ্রেডল একই প্রায়োরিটি অর্ডার ব্যবহার করে, ফলে প্রতিটি বিল্ড ভ্যারিয়েন্ট চূড়ান্ত ম্যানিফেস্টে ভিন্ন ভিন্ন কম্পোনেন্ট বা পারমিশন সংজ্ঞায়িত করতে পারে। কাস্টম সোর্স সেট তৈরি করার বিষয়ে আরও জানতে, ‘সোর্স সেট তৈরি করুন’ পড়ুন।

সংস্করণ ক্যাটালগ

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

অন্যান্য বিল্ড সিস্টেম

বেজেল ব্যবহার করে অ্যান্ড্রয়েড অ্যাপ তৈরি করা সম্ভব, কিন্তু এটি আনুষ্ঠানিকভাবে সমর্থিত নয়। অ্যান্ড্রয়েড স্টুডিও আনুষ্ঠানিকভাবে বেজেল প্রজেক্ট সমর্থন করে না।

Bazel দিয়ে বিল্ড করার বর্তমান সীমাবদ্ধতাগুলো আরও ভালোভাবে বুঝতে, জ্ঞাত সমস্যাগুলো দেখুন।