במערכת ה-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.
- רשומות מניפסט
- אפשר לציין ערכים למאפיינים מסוימים של קובץ המניפסט בתצורה של הווריאנט של ה-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, בלי צורך להעלות כמה פריטי מידע שנוצרו בתהליך פיתוח (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
ה-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
(ל-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")
מגניב
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 }
קובץ ה-build ברמת המודול
הקובץ build.gradle.kts
(ל-DSL של Kotlin) או הקובץ build.gradle
(ל-DSL של Groovy) ברמת המודול נמצא בכל ספרייה project/module/
. היא מאפשרת לקבוע הגדרות build למודול הספציפי שבו הוא נמצא. קביעת
הגדרות ה-build האלה מאפשרת לספק אפשרויות אריזה בהתאמה אישית, כמו
סוגי build נוספים וטעמים נוספים של מוצרים, ולשנות את ההגדרות
בקובץ המניפסט של האפליקציה ב-main/
או בסקריפט ה-build ברמה העליונה.
הגדרות Android SDK
קובץ ה-build של האפליקציה ברמת המודול כולל הגדרות שמציינות את גרסאות ה-SDK ל-Android שבהן נעשה שימוש במהלך הידור, בחירת התנהגויות הפלטפורמה וציון הגרסה המינימלית שבה האפליקציה צריכה לפעול.
-
compileSdk
-
הרכיב
compileSdk
קובע אילו ממשקי API ל-Android ול-Java יהיו זמינים במהלך הידור של קוד המקור. כדי להשתמש בתכונות העדכניות של Android, צריך להשתמש ב-Android SDK העדכני ביותר בזמן ההידור.יכול להיות שחלק מממשקי ה-API של פלטפורמת Android לא יהיו זמינים ברמות API ישנות יותר. אתם יכולים להגביל באופן מותנה את השימוש בתכונות חדשות יותר או להשתמש בספריות תאימות של AndroidX כדי להשתמש בתכונות חדשות יותר ברמות API נמוכות יותר של Android.
כל Android SDK מספק קבוצת משנה של ממשקי API ל-Java לשימוש באפליקציה. בטבלה שבמאמר באיזה ממשקי API של Java אפשר להשתמש בקוד המקור של Java או Kotlin מוצגת רמת ה-API של Java שזמינה בהתאם לגרסה של Android SDK. ממשקי ה-API החדשים יותר של Java נתמכים בגרסאות קודמות של Android באמצעות הסרת סוכר, שצריך להפעיל ב-build.
אם יש התנגשויות בין
compileSdk
לגרסה הנוכחית של Android Studio, של AGP או של דרישות התלות בספריות של הפרויקט, יוצגו אזהרות ב-Android Studio. -
minSdk
-
המדיניות
minSdk
מציינת את הגרסה הנמוכה ביותר של Android שבה רוצים שהאפליקציה תתמוך. ההגדרהminSdk
מגבילה את המכשירים שיכולים להתקין את האפליקציה.כדי לתמוך בגרסאות ישנות יותר של Android, יכול להיות שתצטרכו להוסיף בדיקות מותנות לקוד או להשתמש יותר בספריות התאימות של AndroidX. כדאי לשקול את עלות התחזוקה של תמיכה בגרסאות ישנות יותר מול אחוז המשתמשים שעדיין משתמשים בגרסאות הישנות האלה. כדי לראות את האחוזים הנוכחיים של השימוש בגרסאות, אפשר לעיין בתרשים הגרסאות באשף הפרויקטים החדשים ב-Android Studio.
כשעורכים את הקוד ב-Android Studio או מפעילים בדיקות במהלך ה-build, הכלי lint ייתן אזהרות לגבי ממשקי API שבהם אתם משתמשים ושאינם זמינים ב-
minSdk
. כדי לתקן את הבעיות האלה, צריך להגדיר תכונות חדשות כמותנות או להשתמש ב-Appcompat
לתאימות לאחור. -
targetSdk
-
השדה
targetSdk
משמש לשני יעדים:- הוא מגדיר את ההתנהגות של האפליקציה בסביבת זמן הריצה.
- הוא מאשר את גרסת Android שבה ביצעתם את הבדיקה.
אם עובדים במכשיר עם גרסת Android חדשה יותר מזו של
targetSdk
, מערכת Android מפעילה את האפליקציה במצב תאימות שמתנהג באופן דומה לגרסה הנמוכה יותר שצוינה ב-targetSdk
. לדוגמה, כשהוצג מודל ההרשאות בסביבת זמן הריצה ב-API 23, לא כל האפליקציות היו מוכנות לאמץ אותו באופן מיידי. אם מגדירים את הערך שלtargetSdk
לערך 22, האפליקציות האלה יכולות לפעול במכשירי API 23 בלי להשתמש בהרשאות בתחילת ההפעלה, ויכול להיות שהן יוכלו להשתמש בתכונות שכלולות בגרסה האחרונה שלcompileSdk
. מדיניות הפצה של Google Play אוכפת כללי מדיניות נוספים ברמת ה-API לטירגוט.הערך של
targetSdk
חייב להיות קטן מהערך שלcompileSdk
או שווה לו.
הערה: הערכים של compileSdk
ושל targetSdk
לא חייבים להיות זהים. חשוב לזכור את העקרונות הבסיסיים הבאים:
compileSdk
נותן לכם גישה לממשקי API חדשיםtargetSdk
מגדיר את התנהגות האפליקציה בסביבת זמן הריצהtargetSdk
חייב להיות קטן מ-compileSdk
או שווה לו
סקריפט build לדוגמה של מודול אפליקציה
סקריפט לדוגמה ליצירת מודול של אפליקציית Android, שמציג כמה מההגדרות והרכיבים הבסיסיים של DSL:
Kotlin
/** * 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']) }
קובצי מאפיינים של Gradle
Gradle כוללת גם שני קובצי מאפיינים שנמצאים בספריית הפרויקט ברמה הבסיסית (root), שבהם אפשר להשתמש כדי לציין הגדרות לערכת הכלים ל-build של Gradle:
-
gradle.properties
- כאן אפשר להגדיר הגדרות Gradle ברמת הפרויקט, כמו גודל האשפה המקסימלי של הדימון של Gradle. מידע נוסף זמין במאמר סביבת build.
-
local.properties
-
הגדרת מאפייני הסביבה המקומית למערכת ה-build, כולל:
ndk.dir
– הנתיב ל-NDK. המאפיין הזה יצא משימוש. כל הגרסאות שהורדתם של NDK מותקנות בתיקייהndk
שבתוך התיקייה Android SDK.sdk.dir
– הנתיב ל-Android SDK.cmake.dir
– הנתיב ל-CMake.ndk.symlinkdir
– ב-Android Studio 3.5 ואילך, יוצר קישור ל-NDK שיכול להיות קצר יותר מהנתיב של ה-NDK שהותקן.
מיפוי מחדש של NDK לנתיב קצר יותר (Windows בלבד)
ב-Windows, הכלים בתיקיית NDK המותקנת, כמו ld.exe
, מסתיימים בנתיב ארוך. הכלים לא תומכים היטב בנתיבים ארוכים.
כדי ליצור נתיב קצר יותר, בקובץ local.properties
מגדירים את המאפיין ndk.symlinkdir
כך שיבקש מהפלאגין של Android Gradle ליצור קישור ל-NDK. הנתיב של הקישור הלא פורמלי יכול להיות קצר יותר מהתיקייה הקיימת של NDK.
לדוגמה, ndk.symlinkdir = C:\
יוצר את הקישור הבא:
C:\ndk\19.0.5232133
סנכרון הפרויקט עם קובצי Gradle
כשמבצעים שינויים בקובצי ההגדרה של ה-build בפרויקט, צריך לסנכרן את קובצי הפרויקט ב-Android Studio כדי שאפשר יהיה לייבא את השינויים בהגדרות ה-build ולהריץ כמה בדיקות כדי לוודא שההגדרות לא יוצרות שגיאות build.
כדי לסנכרן את קובצי הפרויקט, לוחצים על Sync Now (סנכרון עכשיו) בסרגל ההתראות שמופיע כשאתם מבצעים שינוי, כמו שמוצג באיור 2, או לוחצים על Sync Project (סנכרון הפרויקט) בסרגל התפריטים. אם מערכת Android Studio תזהה שגיאות בתצורה – לדוגמה, קוד המקור משתמש בתכונות API שזמינות רק ברמת API גבוהה יותר מ-compileSdkVersion
– הבעיה תתואר בחלון Messages.
קבוצות מקורות
מערכת Android Studio מקבצת באופן לוגי את קוד המקור ואת המשאבים של כל מודול לקבוצות מקורות. כשיוצרים מודול חדש, מערכת Android Studio יוצרת קבוצת מקורות main/
בתוך המודול. קבוצת המקור main/
של מודול כוללת את הקוד והמשאבים שבהם נעשה שימוש בכל הווריאנטים של ה-build שלו.
ספריות נוספות של קבוצות מקורות הן אופציונליות, ו-Android Studio לא יוצרת אותן באופן אוטומטי כשמגדירים וריאנטים חדשים של גרסאות build. עם זאת, יצירת קבוצות מקורות, בדומה ל-main/
, עוזרת לארגן קבצים ומשאבים ש-Gradle צריך להשתמש בהם רק כשמפתחים גרסאות מסוימות של האפליקציה:
-
src/main/
- קבוצת המקור הזו כוללת קוד ומשאבים שמשותפים לכל הווריאציות של ה-build.
-
src/buildType/
- יצירת קבוצת המקור הזו כדי לכלול קוד ומשאבים רק לסוג build ספציפי.
-
src/productFlavor/
-
יוצרים את קבוצת המקורות הזו כדי לכלול קוד ומשאבים רק למוצר מסוים.
הערה: אם מגדירים את ה-build כך שיכלול שילוב של כמה טעמים של מוצרים, אפשר ליצור ספריות של קבוצות מקורות לכל שילוב של טעמים של מוצרים בין מאפייני הטעם:
src/productFlavor1ProductFlavor2/
. -
src/productFlavorBuildType/
- יוצרים את קבוצת המקורות הזו כדי לכלול קוד ומשאבים רק לגרסה ספציפית של build.
לדוגמה, כדי ליצור את הגרסה 'fullDebug' של האפליקציה, מערכת ה-build ממזגת קוד, הגדרות ומשאבים מקבוצות המקור הבאות:
-
src/fullDebug/
(קבוצת המקור של וריאנט ה-build) -
src/debug/
(קבוצת המקור של סוג ה-build) -
src/full/
(קבוצת המקור בטעם המוצר) -
src/main/
(קבוצת המקור הראשית)
הערה: כשיוצרים קובץ חדש או ספרייה חדשה ב-Android Studio, צריך להשתמש באפשרויות התפריט קובץ > חדש כדי ליצור אותם לפי קבוצת מקור ספציפית. קבוצות המקור שאפשר לבחור מבוססות על הגדרות ה-build, ו-Android Studio יוצרת באופן אוטומטי את הספריות הנדרשות אם הן עדיין לא קיימות.
אם קבוצות מקור שונות מכילות גרסאות שונות של אותו קובץ, Gradle משתמש בסדר העדיפויות הבא כדי להחליט באיזה קובץ להשתמש. קבוצות המקור בצד ימין מבטלות את הקבצים וההגדרות של קבוצות המקור בצד שמאל:
גרסת build > סוג build > סוג המוצר > קבוצת המקור הראשית > יחסי תלות בספריות
כך Gradle יכולה להשתמש בקבצים שספציפיים לווריאנט ה-build שניסית ליצור, תוך שימוש חוזר בפעילויות, בלוגיקה של אפליקציה ומשאבים שמשותפים לגרסאות אחרות של האפליקציה.
כשממזגים כמה מניפסטים, Gradle משתמש באותו סדר עדיפות כדי שכל וריאנט build יוכל להגדיר רכיבים או הרשאות שונים במניפסט הסופי. למידע נוסף על יצירת קבוצות מקורות בהתאמה אישית, קראו את המאמר יצירת קבוצות מקורות.
קטלוגים של גרסאות
אם ה-build מכיל כמה מודולים עם יחסי תלות משותפים, או שיש לכם כמה פרויקטים עצמאיים עם יחסי תלות משותפים, מומלץ להשתמש בקטלוג גרסאות או ב-BOM כדי לציין את הגרסאות המשותפות.
מערכות build אחרות
אפשר ליצור אפליקציות ל-Android באמצעות Bazel, אבל אין תמיכה רשמית בכך. Android Studio לא תומכת רשמית בפרויקטים של Bazel.
כדי להבין טוב יותר את המגבלות הנוכחיות של ה-build באמצעות Bazel, כדאי לעיין בבעיות הידועות.