הגדרת ה-build

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

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

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

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

סוגי גרסאות Build

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

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

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

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

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

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

קבצים של תצורת build

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

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

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

קובץ Gradle Wrapper

‫Gradle wrapper ‏ (gradlew) הוא אפליקציה קטנה שכלולה בקוד המקור שלכם ומורידה ומפעילה את Gradle עצמה. כך נוצרת הרצה עקבית יותר של בנייה. המפתחים מורידים את מקור האפליקציה ומריצים את gradlew. הפעולה הזו מורידה את הפצת Gradle הנדרשת ומפעילה את Gradle כדי לבצע build של האפליקציה.

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

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

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.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
}

Groovy

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
}