ساخت خود را پیکربندی کنید

سیستم ساخت اندروید، منابع برنامه و کد منبع را کامپایل می‌کند و آنها را در APKها یا بسته‌های برنامه اندروید بسته‌بندی می‌کند که می‌توانید آنها را آزمایش، مستقر، امضا و توزیع کنید.

در بخش مرور کلی Gradle build و ساختار build اندروید ، مفاهیم build و ساختار یک برنامه اندروید را مورد بحث قرار دادیم. اکنون زمان پیکربندی build فرا رسیده است.

واژه‌نامه ساخت اندروید

Gradle و افزونه‌ی Android Gradle به شما کمک می‌کنند تا جنبه‌های زیر از ساخت خود را پیکربندی کنید:

انواع ساخت

انواع ساخت، ویژگی‌های خاصی را تعریف می‌کنند که Gradle هنگام ساخت و بسته‌بندی برنامه شما از آنها استفاده می‌کند. انواع ساخت معمولاً برای مراحل مختلف چرخه عمر توسعه شما پیکربندی می‌شوند.

برای مثال، نوع ساخت اشکال‌زدایی (debug build type) گزینه‌های اشکال‌زدایی را فعال می‌کند و برنامه را با کلید اشکال‌زدایی امضا می‌کند، در حالی که نوع ساخت انتشار (release build type) ممکن است برنامه شما را کوچک، مبهم و با یک کلید انتشار برای توزیع امضا کند.

برای ساخت برنامه خود باید حداقل یک نوع ساخت تعریف کنید. اندروید استودیو به طور پیش‌فرض انواع ساخت اشکال‌زدایی و انتشار را ایجاد می‌کند. برای شروع سفارشی‌سازی تنظیمات بسته‌بندی برای برنامه خود، نحوه پیکربندی انواع ساخت را بیاموزید.

طعم‌های محصول

طعم‌های محصول، نسخه‌های مختلفی از برنامه شما را نشان می‌دهند که می‌توانید برای کاربران منتشر کنید، مانند نسخه‌های رایگان و پولی. می‌توانید طعم‌های محصول را طوری سفارشی کنید که از کد و منابع مختلف استفاده کنند و در عین حال بخش‌هایی را که در همه نسخه‌های برنامه شما مشترک هستند، به اشتراک بگذارند و دوباره استفاده کنند. طعم‌های محصول اختیاری هستند و باید آنها را به صورت دستی ایجاد کنید. برای شروع ایجاد نسخه‌های مختلف برنامه خود، نحوه پیکربندی طعم‌های محصول را بیاموزید.

ساخت انواع

یک build variant حاصلِ ترکیبِ build type و product flavor است و پیکربندی‌ای است که Gradle برای ساخت برنامه شما استفاده می‌کند. با استفاده از build variants، می‌توانید نسخه اشکال‌زدایی product flavors خود را در طول توسعه بسازید و نسخه‌های انتشار امضا شده product flavors خود را برای توزیع آماده کنید. اگرچه build variants را مستقیماً پیکربندی نمی‌کنید، اما build types و product flavors که آنها را تشکیل می‌دهند، پیکربندی می‌کنید. ایجاد build types یا product flavors اضافی، build variants اضافی نیز ایجاد می‌کند. برای یادگیری نحوه ایجاد و مدیریت build variants، مرور کلی Configure build variants را مطالعه کنید.

ورودی‌های مانیفست

شما می‌توانید مقادیری را برای برخی از ویژگی‌های فایل مانیفست در پیکربندی نوع ساخت (build variant configuration) مشخص کنید. این مقادیر ساخت، مقادیر موجود در فایل مانیفست را لغو می‌کنند. این قابلیت در صورتی مفید است که بخواهید چندین نوع از برنامه خود را با نام برنامه، حداقل نسخه SDK یا نسخه SDK هدف متفاوت تولید کنید. هنگامی که چندین مانیفست وجود دارد، ابزار ادغام مانیفست ، تنظیمات مانیفست را ادغام می‌کند .

وابستگی‌ها

سیستم ساخت، وابستگی‌های پروژه را از سیستم فایل محلی شما و از مخازن راه دور مدیریت می‌کند. این بدان معناست که نیازی نیست بسته‌های باینری وابستگی‌های خود را به صورت دستی جستجو، دانلود و در دایرکتوری پروژه خود کپی کنید. برای کسب اطلاعات بیشتر، به بخش افزودن وابستگی‌های ساخت مراجعه کنید.

امضا

سیستم ساخت به شما امکان می‌دهد تنظیمات امضا را در پیکربندی ساخت مشخص کنید و می‌تواند به طور خودکار برنامه شما را در طول فرآیند ساخت امضا کند. سیستم ساخت، نسخه اشکال‌زدایی را با یک کلید پیش‌فرض و گواهی‌نامه با استفاده از اعتبارنامه‌های شناخته‌شده امضا می‌کند تا از درخواست رمز عبور در زمان ساخت جلوگیری شود. سیستم ساخت، نسخه انتشار را امضا نمی‌کند مگر اینکه شما به صراحت پیکربندی امضا را برای این ساخت تعریف کنید. اگر کلید انتشار ندارید، می‌توانید آن را همانطور که در بخش «امضای برنامه» توضیح داده شده است، ایجاد کنید. نسخه‌های انتشار امضا شده برای توزیع برنامه‌ها از طریق اکثر فروشگاه‌های برنامه مورد نیاز هستند.

کاهش کد و منابع

سیستم ساخت به شما امکان می‌دهد برای هر نوع ساخت، یک فایل قوانین ProGuard متفاوت تعیین کنید. هنگام ساخت برنامه، سیستم ساخت با استفاده از ابزارهای کوچک‌سازی داخلی خود، مانند R8، مجموعه قوانین مناسبی را برای کاهش کد و منابع شما اعمال می‌کند. کوچک‌سازی کد و منابع می‌تواند به کاهش اندازه APK یا AAB شما کمک کند.

پشتیبانی از چندین فایل APK

سیستم ساخت به شما امکان می‌دهد به طور خودکار APK های مختلفی بسازید که هر کدام فقط شامل کد و منابع مورد نیاز برای تراکم صفحه نمایش خاص یا رابط دودویی برنامه (ABI) هستند. برای اطلاعات بیشتر به ساخت چندین APK مراجعه کنید. با این حال، انتشار یک AAB واحد رویکرد توصیه شده است، زیرا علاوه بر تراکم صفحه نمایش و ABI، امکان تقسیم بر اساس زبان را نیز فراهم می‌کند، در حالی که از نیاز به آپلود چندین اثر در Google Play جلوگیری می‌کند. همه برنامه‌های جدید ارسال شده پس از آگوست 2021 ملزم به استفاده از AAB هستند.

نسخه‌های جاوا در بیلدهای اندروید

چه کد منبع شما به زبان جاوا، کاتلین یا هر دو نوشته شده باشد، در چندین مرحله باید نسخه زبان JDK یا جاوا را برای ساخت خود انتخاب کنید. برای جزئیات بیشتر به نسخه‌های جاوا در ساخت‌های اندروید مراجعه کنید.

ساخت فایل‌های پیکربندی

ایجاد پیکربندی‌های ساخت سفارشی مستلزم ایجاد تغییرات در یک یا چند فایل پیکربندی ساخت است. این فایل‌های متنی ساده از یک زبان خاص دامنه (DSL) برای توصیف و دستکاری منطق ساخت با استفاده از اسکریپت Kotlin استفاده می‌کنند که نوعی از زبان Kotlin است. همچنین می‌توانید از Groovy که یک زبان پویا برای ماشین مجازی جاوا (JVM) است، برای پیکربندی ساخت‌های خود استفاده کنید.

برای شروع پیکربندی ساخت خود نیازی به دانستن Kotlin script یا Groovy ندارید زیرا افزونه Android Gradle اکثر عناصر DSL مورد نیاز شما را معرفی می‌کند. برای کسب اطلاعات بیشتر در مورد افزونه Android Gradle DSL، مستندات مرجع DSL را مطالعه کنید. Kotlin script همچنین به Gradle Kotlin DSL زیربنایی متکی است.

هنگام شروع یک پروژه جدید، اندروید استودیو به طور خودکار برخی از این فایل‌ها را برای شما ایجاد می‌کند و آنها را بر اساس پیش‌فرض‌های معقول پر می‌کند. برای مرور کلی فایل‌های ایجاد شده، به ساختار ساخت اندروید مراجعه کنید.

فایل Gradle Wrapper

پوشش‌دهنده‌ی Gradle ( gradlew ) یک برنامه‌ی کوچک است که همراه با کد منبع شما ارائه می‌شود و خود Gradle را دانلود و اجرا می‌کند. این کار باعث ایجاد اجرای ساخت (build) با ثبات‌تر می‌شود. توسعه‌دهندگان منبع برنامه را دانلود کرده و gradlew را اجرا می‌کنند. این کار توزیع Gradle مورد نیاز را دانلود کرده و Gradle را برای ساخت برنامه‌ی شما اجرا می‌کند.

فایل gradle/wrapper/gradle-wrapper.properties حاوی یک ویژگی به distributionUrl است که نسخه Gradle مورد استفاده برای اجرای build شما را توصیف می‌کند.

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

فایل تنظیمات Gradle

فایل settings.gradle.kts (برای Kotlin DSL) یا فایل settings.gradle (برای Groovy DSL) در دایرکتوری ریشه پروژه قرار دارد. این فایل تنظیمات، تنظیمات مخزن در سطح پروژه را تعریف می‌کند و به 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 "8.13.0" apply false
    id("com.android.library") version "8.13.0" apply false
    id("org.jetbrains.kotlin.android") version "2.2.21" 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 '8.13.0' apply false
    id 'com.android.library' version '8.13.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.2.21' apply false
}

فایل ساخت در سطح ماژول

build.gradle.kts در سطح ماژول (برای Kotlin DSL) یا فایل build.gradle (برای Groovy DSL) در هر دایرکتوری project / module / قرار دارد. این فایل به شما امکان می‌دهد تنظیمات ساخت را برای ماژول خاصی که در آن قرار دارد پیکربندی کنید. پیکربندی این تنظیمات ساخت به شما امکان می‌دهد گزینه‌های بسته‌بندی سفارشی، مانند انواع ساخت اضافی و طعم‌های محصول، و تنظیمات را در main/ app manifest یا اسکریپت ساخت سطح بالا لغو کنید.

تنظیمات SDK اندروید

فایل ساخت سطح ماژول برای برنامه شما شامل تنظیماتی است که نسخه‌های Android SDK مورد استفاده هنگام کامپایل، انتخاب رفتارهای پلتفرم و مشخص کردن حداقل نسخه‌ای که برنامه شما روی آن اجرا می‌شود را نشان می‌دهد.

compileSdk

compileSdk هنگام کامپایل کد منبع شما، تعیین می‌کند که کدام APIهای اندروید و جاوا در دسترس هستند. برای استفاده از جدیدترین ویژگی‌های اندروید، هنگام کامپایل از جدیدترین SDK اندروید استفاده کنید.

ممکن است برخی از APIهای پلتفرم اندروید در سطوح API قدیمی‌تر در دسترس نباشند. می‌توانید به طور مشروط از استفاده از ویژگی‌های جدیدتر جلوگیری کنید یا از کتابخانه‌های سازگاری AndroidX برای استفاده از ویژگی‌های جدیدتر با سطوح API اندروید پایین‌تر استفاده کنید.

هر SDK اندروید زیرمجموعه‌ای از APIهای جاوا را برای استفاده در برنامه شما ارائه می‌دهد. جدول « کدام APIهای جاوا را می‌توانم در کد منبع جاوا یا کاتلین خود استفاده کنم» نشان می‌دهد که کدام سطح API جاوا بر اساس نسخه SDK اندروید در دسترس است. APIهای جدیدتر جاوا از طریق desugaring در نسخه‌های قبلی اندروید پشتیبانی می‌شوند که باید در ساخت شما فعال شود.

اگر compileSdk شما با نسخه فعلی اندروید استودیو، AGP یا الزامات وابستگی کتابخانه پروژه شما مغایرت داشته باشد، اندروید استودیو هشدارهایی را نمایش می‌دهد.

minSdk

minSdk پایین‌ترین نسخه اندروید مورد پشتیبانی برنامه شما را مشخص می‌کند. تنظیم minSdk دستگاه‌هایی را که می‌توانند برنامه شما را نصب کنند، محدود می‌کند.

پشتیبانی از نسخه‌های پایین‌تر اندروید ممکن است نیاز به بررسی‌های شرطی بیشتر در کد شما یا استفاده بیشتر از کتابخانه‌های سازگاری AndroidX داشته باشد. شما باید هزینه نگهداری پشتیبانی از نسخه‌های پایین‌تر را در مقابل درصد کاربرانی که هنوز از آن نسخه‌های پایین‌تر استفاده می‌کنند، بسنجید. برای درصد استفاده از نسخه فعلی، به نمودار نسخه در ویزارد پروژه جدید اندروید استودیو مراجعه کنید.

هنگام ویرایش کد خود در اندروید استودیو یا اجرای بررسی‌ها در طول ساخت، lint در مورد APIهایی که استفاده می‌کنید و در minSdk موجود نیستند، هشدار می‌دهد. شما باید این موارد را با مشروط کردن ویژگی‌های جدیدتر یا با استفاده از Appcompat برای سازگاری با نسخه‌های قبلی، برطرف کنید.

targetSdk

targetSdk دو هدف را دنبال می‌کند:

1. رفتار زمان اجرای برنامه شما را تنظیم می‌کند.
2. این گواهی می‌دهد که شما کدام نسخه از اندروید را روی آن آزمایش کرده‌اید.

اگر برنامه را روی دستگاهی اجرا کنید که از نسخه اندروید بالاتری نسبت به targetSdk شما استفاده می‌کند، اندروید برنامه شما را در حالت سازگاری اجرا می‌کند که مشابه نسخه پایین‌تر مشخص شده در targetSdk شما رفتار می‌کند. برای مثال، وقتی API 23 مدل مجوزهای زمان اجرا را معرفی کرد، همه برنامه‌ها آماده نبودند که بلافاصله آن را بپذیرند. با تنظیم targetSdk روی ۲۲، این برنامه‌ها می‌توانند بدون استفاده از مجوزهای زمان اجرا روی دستگاه‌های API 23 اجرا شوند و از ویژگی‌های موجود در آخرین نسخه compileSdk استفاده کنند. سیاست توزیع Google Play سیاست‌های اضافی را در سطح API هدف اعمال می‌کند.

مقدار 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 = 33

    /**
     * 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 = 21

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

        // 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 33

    /**
     * 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 21

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

        // 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

Gradle همچنین شامل دو فایل ویژگی است که در دایرکتوری ریشه پروژه شما قرار دارند و می‌توانید از آنها برای تعیین تنظیمات مربوط به خود ابزار ساخت Gradle استفاده کنید:

gradle.properties

اینجا جایی است که می‌توانید تنظیمات Gradle در سطح پروژه، مانند حداکثر اندازه heap برای Daemon Gradle را پیکربندی کنید. برای اطلاعات بیشتر، به Build Environment مراجعه کنید.

local.properties

ویژگی‌های محیط محلی را برای سیستم ساخت، از جمله موارد زیر، پیکربندی می‌کند:

• ndk.dir - مسیر NDK. این ویژگی منسوخ شده است. هر نسخه دانلود شده از NDK در پوشه ndk در پوشه SDK اندروید نصب می‌شود.
• sdk.dir - مسیر SDK اندروید.
• cmake.dir - مسیر CMake.
• ndk.symlinkdir - در اندروید استودیو ۳.۵ و بالاتر، یک لینک نمادین به NDK ایجاد می‌کند که می‌تواند کوتاه‌تر از مسیر NDK نصب‌شده باشد.

NDK را به مسیر کوتاه‌تری تغییر مسیر دهید (فقط ویندوز)

در ویندوز، ابزارهای موجود در پوشه NDK نصب شده، مانند ld.exe ، مسیرهای طولانی دارند. این ابزارها به خوبی از مسیرهای طولانی پشتیبانی نمی‌کنند.

برای ایجاد یک مسیر کوتاه‌تر، در local.properties ، ویژگی ndk.symlinkdir طوری تنظیم کنید که از افزونه Android Gradle بخواهد یک پیوند نمادین به NDK ایجاد کند. مسیر آن پیوند نمادین می‌تواند کوتاه‌تر از پوشه NDK موجود باشد. برای مثال، ndk.symlinkdir = C:\ منجر به پیوند نمادین زیر می‌شود: C:\ndk\19.0.5232133

همگام‌سازی پروژه با فایل‌های Gradle

وقتی در فایل‌های پیکربندی ساخت پروژه خود تغییراتی ایجاد می‌کنید، اندروید استودیو از شما می‌خواهد که فایل‌های پروژه خود را همگام‌سازی کنید تا بتواند تغییرات پیکربندی ساخت شما را وارد کند و بررسی‌هایی را انجام دهد تا مطمئن شود پیکربندی شما خطاهای ساخت ایجاد نمی‌کند.

برای همگام‌سازی فایل‌های پروژه خود، همانطور که در شکل ۲ نشان داده شده است، در نوار اعلان که هنگام ایجاد تغییر ظاهر می‌شود، روی «همگام‌سازی اکنون» کلیک کنید، یا روی «همگام‌سازی پروژه» کلیک کنید. از نوار منو. اگر اندروید استودیو هرگونه خطایی در پیکربندی شما پیدا کند - برای مثال، کد منبع شما از ویژگی‌های API استفاده می‌کند که فقط در سطح API بالاتر از compileSdkVersion شما در دسترس هستند - پنجره Messages مشکل را شرح می‌دهد.

مجموعه‌های منبع

اندروید استودیو به طور منطقی کد منبع و منابع هر ماژول را در مجموعه‌های منبع گروه‌بندی می‌کند. وقتی یک ماژول جدید ایجاد می‌کنید، اندروید استودیو یک مجموعه main/ source درون ماژول ایجاد می‌کند. مجموعه main/ source یک ماژول شامل کد و منابعی است که توسط تمام نسخه‌های ساخته شده آن استفاده می‌شود.

دایرکتوری‌های مجموعه منابع اضافی اختیاری هستند و اندروید استودیو هنگام پیکربندی انواع ساخت جدید، آنها را به طور خودکار برای شما ایجاد نمی‌کند. با این حال، ایجاد مجموعه‌های منبع، مشابه main/ ، به سازماندهی فایل‌ها و منابعی کمک می‌کند که Gradle فقط باید هنگام ساخت نسخه‌های خاصی از برنامه شما از آنها استفاده کند:

src/main/

این مجموعه منبع شامل کد و منابع مشترک برای همه انواع ساخت است.

src/ buildType /

این مجموعه منبع را طوری ایجاد کنید که فقط شامل کد و منابع برای یک نوع ساخت خاص باشد.

src/ productFlavor /

این مجموعه منبع را طوری ایجاد کنید که فقط شامل کد و منابع مربوط به یک محصول خاص باشد.

توجه: اگر ساخت خود را طوری پیکربندی می‌کنید که چندین طعم محصول را با هم ترکیب کند ، می‌توانید دایرکتوری‌های مجموعه منبع را برای هر ترکیب از طعم‌های محصول بین ابعاد طعم ایجاد کنید: src/ productFlavor1 ProductFlavor2 / .

src/ productFlavorBuildType /

این مجموعه منبع را طوری ایجاد کنید که فقط شامل کد و منابع برای یک نوع ساخت خاص باشد.

برای مثال، برای تولید نسخه "fullDebug" برنامه شما، سیستم ساخت، کد، تنظیمات و منابع را از مجموعه منابع زیر ادغام می‌کند:

• src/fullDebug/ (مجموعه منبع نوع ساخت)
• src/debug/ (مجموعه منبع نوع ساخت)
• src/full/ (مجموعه منبع طعم محصول)
• src/main/ (مجموعه منابع اصلی)

توجه: وقتی یک فایل یا دایرکتوری جدید در اندروید استودیو ایجاد می‌کنید، از گزینه‌های منوی File > New برای ایجاد آن برای یک مجموعه منبع خاص استفاده کنید. مجموعه‌های منبعی که می‌توانید از بین آنها انتخاب کنید، بر اساس پیکربندی‌های ساخت شما هستند و اندروید استودیو در صورت وجود نداشتن دایرکتوری‌های مورد نیاز، آنها را به طور خودکار ایجاد می‌کند.

اگر مجموعه‌های منبع مختلف شامل نسخه‌های مختلفی از یک فایل باشند، Gradle هنگام تصمیم‌گیری در مورد اینکه از کدام فایل استفاده کند، از ترتیب اولویت زیر استفاده می‌کند. مجموعه‌های منبع در سمت چپ، فایل‌ها و تنظیمات مجموعه‌های منبع در سمت راست را لغو می‌کنند:

نوع ساخت > نوع ساخت > طعم محصول > مجموعه منبع اصلی > وابستگی‌های کتابخانه

این به Gradle اجازه می‌دهد تا از فایل‌هایی که مختص نسخه ساختی هستند که می‌خواهید بسازید، استفاده کند و در عین حال از فعالیت‌ها، منطق برنامه و منابعی که برای سایر نسخه‌های برنامه شما مشترک هستند، استفاده مجدد کند.

هنگام ادغام چندین مانیفست ، Gradle از ترتیب اولویت یکسانی استفاده می‌کند، بنابراین هر نوع ساخت می‌تواند اجزا یا مجوزهای مختلفی را در مانیفست نهایی تعریف کند. برای کسب اطلاعات بیشتر در مورد ایجاد مجموعه‌های منبع سفارشی، بخش «ایجاد مجموعه‌های منبع» را مطالعه کنید.

کاتالوگ‌های نسخه

اگر ساخت شما شامل چندین ماژول با وابستگی‌های مشترک است، یا چندین پروژه مستقل با وابستگی‌های مشترک دارید، توصیه می‌کنیم از یک کاتالوگ نسخه یا لیست مواد (BOM) برای مشخص کردن نسخه‌های مشترک استفاده کنید.

سایر سیستم‌های ساخت

ساخت برنامه‌های اندروید با Bazel امکان‌پذیر است اما رسماً پشتیبانی نمی‌شود. اندروید استودیو رسماً از پروژه‌های Bazel پشتیبانی نمی‌کند.

برای درک بهتر محدودیت‌های فعلی ساخت با Bazel، به مشکلات شناخته‌شده مراجعه کنید.