הגדרת ה-build

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

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

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

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

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

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

תהליך ה-build

בתהליך ה-build יש הרבה כלים ותהליכים להמרת פרויקט לחבילת אפליקציה ל-Android (APK) או לקובץ Android App Bundle (AAB).

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

לפרויקטים שונים יכולים להיות יעדי build שונים. לדוגמה, ה-builder ספריית הצד השלישי יוצרת את Android Archive (AAR) או Java Archive (JAR) של הספריות. עם זאת, אפליקציה היא סוג הפרויקט הנפוץ ביותר, וגם גרסת ה-build של אפליקציה יוצר APK או AAB לניפוי באגים או לפרסום של האפליקציה שניתן לפרוס, בדיקה או הפצה למשתמשים חיצוניים.

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

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

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

סוגי build

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

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

צריך להגדיר סוג build אחד לפחות כדי לפתח את האפליקציה. מערכת Android Studio יוצרת את סוגי ה-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.
תמיכה ב-APKs מרובים
מערכת ה-build מאפשרת לבנות חבילות APK שונות באופן אוטומטי כל אחת מהן כוללת רק את הקוד והמשאבים הנדרשים לפי דחיסות מסך ספציפית או Application Binary Interface (ABI). מידע נוסף זמין במאמר בניית חבילות APK מרובות. עם זאת, שחרור AAB יחיד הגישה המומלצת, כי היא מאפשרת חלוקה לפי שפה דחיסות המסך ו-ABI, תוך הימנעות מהצורך בהעלאה ארטיפקטים מרובים ב-Google Play. כל האפליקציות החדשות שנשלחו אחרי אוגוסט 2021 נדרשות כדי להשתמש ב-AAB.

גרסאות Java בגרסאות build של Android

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

יצירת קובצי תצורה

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

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

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

└── MyApp/  # Project
    ├── gradle/
    │   └── wrapper/
    │       └── gradle-wrapper.properties
    ├── build.gradle(.kts)
    ├── settings.gradle(.kts)
    └── app/  # Module
    │   ├── build.gradle(.kts)
    │   ├── build/
    │   ├── libs/
    │   └── src/
    │        └── main/  # Source set
    │            ├── java/
    │            │   └── com.example.myapp
    │            ├── res/
    │            │   ├── drawable/
    │            │   ├── values/
    │            │   └── ...
    │            └── AndroidManifest.xml

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

קובץ 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) נמצא ברמה הבסיסית (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. The code below
      * defines 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. The code below
      * defines 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 "8.6.0" apply false
    id("com.android.library") version "8.6.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.23" 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.6.0' apply false
    id 'com.android.library' version '8.6.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}