‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

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

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

در نمای کلی ساخت Gradle و ساختار ساخت Android، مفاهیم ساخت و ساختار برنامه Android را بررسی کردیم. اکنون زمان پیکربندی ساخت است.

واژه‌نامه ساخت Android

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

انواع ساخت

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

برای مثال، نوع ساخت اشکال‌زدایی گزینه‌های اشکال‌زدایی را فعال می‌کند و برنامه را با کلید اشکال‌زدایی امضا می‌کند، درحالی‌که نوع ساخت نسخه پخش ممکن است برنامه شما را کوچک، مبهم، و با کلید نسخه پخش برای توزیع امضا کند.

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

نسخه‌های ویژه محصول

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

تنوع‌های ساخت

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

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

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

وابستگی‌ها

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

درحال امضا کردن

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

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

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

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

سیستم ساخت به شما امکان می‌دهد به‌طور خودکار APKهای مختلفی بسازید که هرکدام فقط حاوی کد و منابع موردنیاز برای تراکم صفحه‌نمایش خاص یا «میانای دودویی کاربردی» (ABI) باشد. برای اطلاعات بیشتر، ساخت چند APK را ببینید. بااین‌حال، انتشار یک بسته App Bundle Android رویکرد توصیه‌شده است، زیرا علاوه‌بر تراکم صفحه‌نمایش و رابط دودویی نرم‌افزار، امکان تقسیم براساس زبان را نیز ارائه می‌دهد، و درعین‌حال نیاز به بارگذاری چندین آرتیفکت در Google Play را ازبین می‌برد. همه برنامه‌های جدیدی که پس‌از اوت ۲۰۲۱ ارسال می‌شوند باید از AAB استفاده کنند.

نسخه‌های جاوا در ساخت‌های Android

چه کد منبع شما به زبان Java،‏ Kotlin، یا هر دو نوشته شده باشد، چندین مکان وجود دارد که باید نسخه JDK یا زبان Java را برای ساخت خود انتخاب کنید. برای جزئیات، به نسخه‌های Java در ساخت‌های Android مراجعه کنید.

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

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

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

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

فایل Gradle Wrapper

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

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

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 "9.4.0" apply false
    id("com.android.library") version "9.4.0" apply false
    id("org.jetbrains.kotlin.android") version "2.4.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.4.0' apply false
    id 'com.android.library' version '9.4.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.4.10' apply false
}

/** * 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.8.0") 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.8.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }

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

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

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

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

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

محتوا و نمونه کدها در این صفحه مشمول پروانه‌های توصیف‌شده در پروانه محتوا هستند. جاوا و OpenJDK علامت‌های تجاری یا علامت‌های تجاری ثبت‌شده Oracle و/یا وابسته‌های آن هستند.

تاریخ آخرین به‌روزرسانی 2026-10-17 به‌وقت ساعت هماهنگ جهانی.

X
AndroidDev@ را در X دنبال کنید
YouTube
Android Developers را در YouTube ببینید
LinkedIn
Connect with the Android Developers community on LinkedIn

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

واژه‌نامه ساخت Android

نسخه‌های جاوا در ساخت‌های Android

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

فایل Gradle Wrapper

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

کاتلین

شیک

فایل ساخت سطح بالا

کاتلین

شیک

فایل ساخت سطح واحد

تنظیمات کیت توسعه نرم‌افزار Android

کاتلین

شیک

نمونه دستورگان ساختن ماژول برنامه

کاتلین

شیک

فایل‌های ویژگی‌های Gradle

تخصیص مجدد NDK به مسیر کوتاه‌تر (فقط Windows)

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

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

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

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

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

واژه‌نامه ساخت Android

نسخه‌های جاوا در ساخت‌های Android

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

فایل Gradle Wrapper

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

کاتلین

شیک

فایل ساخت سطح بالا

کاتلین

شیک

فایل ساخت سطح واحد

تنظیمات کیت توسعه نرم‌افزار Android

کاتلین

شیک

نمونه دستورگان ساختن ماژول برنامه

کاتلین

شیک

فایل‌های ویژگی‌های Gradle

تخصیص مجدد NDK به مسیر کوتاه‌تر (فقط Windows)

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

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

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

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

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