הגדרת ה-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 היא תוצר של סוג build וסוג מוצר, והיא ההגדרה שבה Gradle משתמש כדי ליצור את האפליקציה. באמצעות גרסאות 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 שונות, שכל אחת מהן מכילה רק את הקוד והמשאבים הנדרשים לצפיפות מסך ספציפית או לממשק בינארי של אפליקציה (ABI). למידע נוסף, ראו יצירת כמה חבילות APK. עם זאת, מומלץ להשיק קובץ AAB יחיד, כי הוא מאפשר לפצל לפי שפה בנוסף לצפיפות המסך ול-ABI, בלי צורך להעלות כמה פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ל-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 (ל-DSL של Kotlin) או הקובץ settings.gradle (ל-DSL של Groovy) נמצאים בספריית השורש של הפרויקט. קובץ ההגדרות הזה מגדיר את ההגדרות של המאגר ברמת הפרויקט, ומציין ל-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 ברמה העליונה (ל-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
}

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