דף זה תורגם על ידי Cloud Translation API.

הגדרת ה-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 וסוג מוצר, והיא ההגדרה שבה Gradle משתמש כדי ליצור את האפליקציה. באמצעות גרסאות 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.

תמיכה ב-APKs מרובים

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

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

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

קובצי תצורת build

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

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

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

קובץ Gradle Wrapper

ה-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 אילו מודולים צריך לכלול כשמפתחים את האפליקציה. בפרויקטים עם כמה מודולים, צריך לציין כל מודול שאמור להיכלל בגרסת ה-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")

Groovy

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 ברמה העליונה (ל-DSL של Kotlin) או קובץ build.gradle (ל-DSL של Groovy) נמצא בספריית הבסיס של הפרויקט. בדרך כלל הוא מגדיר את הגרסאות הנפוצות של הפלאגינים שבהם נעשה שימוש על ידי המודולים בפרויקט.

דוגמת הקוד הבאה מתארת את הגדרות ברירת המחדל ואת רכיבי ה-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 "8.7.0" apply false
    id("com.android.library") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "2.0.20" 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.7.0' apply false
    id 'com.android.library' version '8.7.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.0.20' 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 = 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.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 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.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }

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

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

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

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

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

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

עדכון אחרון: 2024-11-04 (שעון UTC).

X
Follow @AndroidDev on X
YouTube
Check out Android Developers on YouTube
LinkedIn
Connect with the Android Developers community on LinkedIn

הגדרת ה-build

מילון מונחים בנושא build של Android

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

קובצי תצורת build

קובץ Gradle Wrapper

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

Kotlin

Groovy

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

Kotlin

מגניב

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

הגדרות Android SDK

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

Kotlin

Groovy

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

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

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

קבוצות מקור

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

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