‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת ה-build

מערכת ה-build של Android מקמפלת את המשאבים וקוד המקור של האפליקציה, ואורזת אותם בקובצי APK או קובץ Android App Bundle שאפשר לבדוק, לפרוס, לחתום ולהפיץ.

במאמרים סקירה כללית של גרסת build ב-Gradle ומבנה גרסת build ב-Android, דנו במושגים של גרסת build ובמבנה של אפליקציה ל-Android. עכשיו הגיע הזמן להגדיר את גרסת ה-build.

מילון מונחים של גרסאות build ל-Android

‫Gradle והפלאגין של Android Gradle עוזרים להגדיר את ההיבטים הבאים של ה-build:

סוגי גרסאות build

סוגי ה-build מגדירים מאפיינים מסוימים שבהם Gradle משתמש כדי ליצור את ה-build של האפליקציה ולארוז אותה. בדרך כלל, סוגי ה-build מוגדרים לשלבים שונים במחזור החיים של הפיתוח.

לדוגמה, סוג גרסת ה-build לניפוי באגים מפעיל את אפשרויות ניפוי הבאגים וחותם על האפליקציה באמצעות מפתח ניפוי הבאגים, ואילו סוג גרסת ה-build להפצה עשוי לכווץ את האפליקציה, להסתיר אותה ולחתום עליה באמצעות מפתח הפצה לצורך הפצה.

כדי ליצור את האפליקציה, צריך להגדיר לפחות סוג אחד של גרסת build. כברירת מחדל, Android Studio יוצר את סוגי גרסאות ה-build לניפוי באגים ולהפצה. כדי להתחיל להתאים אישית את הגדרות האריזה של האפליקציה, צריך ללמוד איך להגדיר סוגי build.

גרסאות המוצר

גרסאות המוצר מייצגות גרסאות שונות של האפליקציה שאפשר לפרסם למשתמשים, כמו גרסאות חינמיות וגרסאות בתשלום. אתם יכולים להתאים אישית את גרסאות המוצר כדי להשתמש בקוד ובמשאבים שונים, תוך שיתוף ושימוש חוזר בחלקים שמשותפים לכל הגרסאות של האפליקציה. גרסאות המוצר הן אופציונליות, ואתם צריכים ליצור אותן באופן ידני. כדי להתחיל ליצור גרסאות שונות של האפליקציה, אתם יכולים לקרוא איך להגדיר גרסאות מוצר.

וריאנטים של גרסאות build

וריאנט build הוא מכפלה וקטורית (cross product) של סוג ה-build וגרסת המוצר, והוא ההגדרה שבה Gradle משתמש כדי ליצור את האפליקציה. באמצעות וריאנטים של build, אתם יכולים ליצור את גרסת ניפוי הבאגים של גרסאות המוצר במהלך הפיתוח, וגרסאות הפצה חתומות של גרסאות המוצר להפצה. למרות שאתם לא מגדירים וריאנט build באופן ישיר, אתם מגדירים את סוגי ה-build וגרסאות המוצר שיוצרים אותם. יצירה של סוגי build או גרסאות מוצר נוספים יוצרת גם וריאנטים נוספים של build. כדי ללמוד איך ליצור ולנהל וריאנט build, קראו את הסקירה הכללית בנושא הגדרת וריאנט build.

רשומות במניפסט

אפשר לציין ערכים למאפיינים מסוימים של קובץ המניפסט בהגדרות של וריאנט ה-build. ערכי ה-build האלה מבטלים את הערכים הקיימים בקובץ המניפסט. האפשרות הזו שימושית אם רוצים ליצור כמה גרסאות של האפליקציה עם שם אפליקציה שונה, גרסת SDK מינימלית שונה או גרסת SDK שונה לטירגוט. אם יש כמה מניפסטים, כלי המיזוג של המניפסטים ממזג את ההגדרות של המניפסטים.

תלויות

מערכת ה-build מנהלת את יחסי התלות של הפרויקט ממערכת הקבצים המקומית וממאגרים מרוחקים. זה אומר שלא צריך לחפש, להוריד ולהעתיק באופן ידני חבילות בינאריות של יחסי התלות לספריית הפרויקט. מידע נוסף זמין במאמר הוספת יחסי תלות ב-build.

חתימה

מערכת ה-build מאפשרת לציין את הגדרות החתימה בתצורת ה-build, והיא יכולה לחתום באופן אוטומטי על האפליקציה במהלך תהליך ה-build. מערכת ה-build חותמת על גרסת ניפוי הבאגים באמצעות מפתח ואישור שמוגדרים כברירת מחדל, תוך שימוש בפרטי כניסה ידועים כדי למנוע בקשה להזנת סיסמה בזמן ה-build. מערכת ה-build לא חותמת על גרסת ההפצה, אלא אם מגדירים במפורש הגדרת חתימה ל-build הזה. אם אין לכם מפתח הפצה, אתם יכולים ליצור אחד כמו שמתואר במאמר חתימה על האפליקציה. כדי להפיץ אפליקציות ברוב חנויות האפליקציות, צריך גרסאות build להפצה חתומות.

כיווץ קוד ומקורות מידע

מערכת ה-build מאפשרת לציין קובץ כללי ProGuard שונה לכל וריאנט build. כשמפתחים את האפליקציה, מערכת ה-build מחילה את קבוצת הכללים המתאימה כדי לצמצם את הקוד והמשאבים באמצעות הכלים המובנים לצמצום, כמו R8. כיווץ הקוד והמשאבים יכול לעזור להקטין את הגודל של קובץ ה-APK או ה-AAB.

תמיכה בכמה קובצי APK

מערכת ה-build מאפשרת ליצור באופן אוטומטי קובצי APK שונים, שכל אחד מהם מכיל רק את הקוד והמשאבים שנדרשים לצפיפות מסך ספציפית או ל-Application Binary Interface (‏ABI). מידע נוסף זמין במאמר יצירת כמה חבילות APK. עם זאת, הגישה המומלצת היא לפרסם קובץ AAB אחד, כי הוא מאפשר פיצול לפי שפה בנוסף לדחיסות המסך ולממשק ABI, ומונע את הצורך להעלות כמה פריטי מידע שנוצרו בתהליך הפיתוח (artifacts) ל-Google Play. כל האפליקציות החדשות שנשלחות אחרי אוגוסט 2021 צריכות להשתמש ב-AAB.

גרסאות Java ב-builds של Android

לא משנה אם קוד המקור כתוב ב-Java, ב-Kotlin או בשתיהן, יש כמה מקומות שבהם צריך לבחור גרסה של JDK או של שפת Java בשביל ה-build. פרטים נוספים זמינים במאמר גרסאות Java ב-builds של Android.

קובצי תצורת build

כדי ליצור תצורות build בהתאמה אישית, צריך לבצע שינויים בקובץ תצורה אחד או יותר של build. הקבצים האלה הם קובצי טקסט פשוט שמשתמשים בשפה ספציפית לדומיין (DSL) כדי לתאר את לוגיקת ה-build ולשנות אותה באמצעות סקריפט Kotlin, שהוא סוג של שפת Kotlin. אפשר גם להשתמש ב-Groovy, שפה דינמית ל-Java Virtual Machine ‏ (JVM), כדי להגדיר את ה-builds.

אתם לא צריכים לדעת סקריפט Kotlin או Groovy כדי להתחיל להגדיר את ה-build, כי הפלאגין של Android Gradle מציג את רוב רכיבי ה-DSL שאתם צריכים. מידע נוסף על ה-DSL של הפלאגין של Android Gradle זמין במאמרי העזרה של DSL. סקריפט Kotlin מסתמך גם על Gradle Kotlin DSL הבסיסי

כשמתחילים פרויקט חדש, Android Studio יוצר באופן אוטומטי חלק מהקבצים האלה ומאכלס אותם על סמך ברירות מחדל הגיוניות. במאמר מבנה ה-build של Android יש סקירה כללית של הקבצים שנוצרו.

קובץ ה-Gradle Wrapper

ה-Gradle wrapper‏ (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) נמצא בספריית הפרויקט ברמה הבסיסית (root). קובץ ההגדרות הזה מגדיר את הגדרות המאגר ברמת הפרויקט, ומציין ל-Gradle אילו מודולים צריך לכלול כשיוצרים את האפליקציה. בפרויקטים עם כמה מודולים, צריך לציין כל מודול שצריך להיכלל ב-build הסופי.

ברוב הפרויקטים, הקובץ נראה כך כברירת מחדל:

Kotlin

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 ברמה העליונה

הקובץ build.gradle.kts (ל-Kotlin DSL) או הקובץ build.gradle (ל-Groovy DSL) ברמה העליונה נמצא בספריית הפרויקט ברמה הבסיסית (root). בדרך כלל הוא מגדיר את הגרסאות הנפוצות של הפלאגינים שבהם משתמשים המודולים בפרויקט.

דוגמת הקוד הבאה מתארת את הגדרות ברירת המחדל ואת רכיבי ה-DSL בסקריפט ה-build ברמה העליונה אחרי שיוצרים פרויקט חדש:

Kotlin

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']) }

קטלוגים של גרסאות

אם ה-build מכיל כמה מודולים עם יחסי תלות משותפים, או אם יש לכם כמה פרויקטים נפרדים עם יחסי תלות משותפים, מומלץ להשתמש בקטלוג גרסאות או במפרט חומרים (BOM) כדי לציין את הגרסאות המשותפות.

מערכות build אחרות

אפשר לפתח אפליקציות ל-Android באמצעות Bazel, אבל אין תמיכה רשמית בכך. ‫Android Studio לא תומך באופן רשמי בפרויקטים של Bazel.

כדי להבין טוב יותר את המגבלות הנוכחיות של בנייה באמצעות Bazel, קראו את הבעיות המוכרות.

דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן.‏ Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.

עדכון אחרון: 2026-10-17 (שעון UTC).

X
למעקב אחר ‎@AndroidDev ב-X
YouTube
למידע על Android Developers ב-YouTube
LinkedIn
Connect with the Android Developers community on LinkedIn

הגדרת ה-build

מילון מונחים של גרסאות build ל-Android

גרסאות Java ב-builds של Android

קובצי תצורת build

קובץ ה-Gradle Wrapper

קובץ ההגדרות של Gradle

Kotlin

מגניב

קובץ ה-build ברמה העליונה

Kotlin

מגניב

קובץ ה-build ברמת המודול

הגדרות Android SDK

Kotlin

מגניב

סקריפט ליצירת build של מודול של אפליקציה לדוגמה

Kotlin

מגניב

קובצי מאפיינים של Gradle

מיפוי מחדש של ה-NDK לנתיב קצר יותר (Windows בלבד)

סנכרון הפרויקט עם קובצי Gradle

קבוצות מקורות

קטלוגים של גרסאות

מערכות build אחרות

הגדרת ה-build קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מילון מונחים של גרסאות build ל-Android

גרסאות Java ב-builds של Android

קובצי תצורת build

קובץ ה-Gradle Wrapper

קובץ ההגדרות של Gradle

Kotlin

מגניב

קובץ ה-build ברמה העליונה

Kotlin

מגניב

קובץ ה-build ברמת המודול

הגדרות Android SDK

Kotlin

מגניב

סקריפט ליצירת build של מודול של אפליקציה לדוגמה

Kotlin

מגניב

קובצי מאפיינים של Gradle

מיפוי מחדש של ה-NDK לנתיב קצר יותר (Windows בלבד)

סנכרון הפרויקט עם קובצי Gradle

קבוצות מקורות

קטלוגים של גרסאות

מערכות build אחרות

הגדרת ה-build