הגדרת ה-build
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
מערכת ה-build של Android מהדרת את המשאבים ואת קוד המקור של האפליקציה, ואורזת אותם בחבילות APK או ב-Android App Bundle שאפשר לבדוק, לפרוס, לחתום ולהפיץ.
Gradle והפלאגין של Android Gradle עוזרים לכם להגדיר את ההיבטים הבאים של ה-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 בשביל ה-build. פרטים נוספים זמינים במאמר גרסאות Java בגרסאות build של Android.
קבצים של תצורת build
כדי ליצור הגדרות build מותאמות אישית, ��ריך ל��צע ש��נויים בקובץ הגדרות build אחד או יותר. בקובצי הטקסט הפשוטים האלה נעשה שימוש בשפה ספציפית לדומיין (DSL) כדי לתאר ולשנות את הלוגיקה של ה-build באמצעות סקריפט Kotlin, שהוא ניב של שפת Kotlin. אפשר גם להשתמש ב-Groovy, שהיא שפה דינמית למכונה וירטואלית של Java (JVM), כדי להגדיר את ה-build.
לא צריך לדעת 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 עצמה.
כך מתקבלת הרצה עקבית יותר של ה-build. המפתחים מורידים את מקור האפליקציה ומריצים את gradlew. הפעולה הזו מורידה את הפצת Gradle הנדרשת ומפעילה את Gradle כדי לבצע build של האפליקציה.
הקובץ gradle/wrapper/gradle-wrapper.properties מכיל מאפיין, distributionUrl, שמתאר איזו גרסה של Gradle משמשת להרצת ה-build.
הקובץ 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"9.1.0"applyfalseid("com.android.library")version"9.1.0"applyfalseid("org.jetbrains.kotlin.android")version"2.3.10"applyfalse}
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'9.1.0'applyfalseid'com.android.library'version'9.1.0'applyfalseid'org.jetbrains.kotlin.android'version'2.3.10'applyfalse}
קובץ ה-build ברמת המודול
הקובץ build.gradle.kts (ב-Kotlin DSL) או build.gradle (ב-Groovy DSL) ברמת המודול נמצא בכל ספרייה project/module/. הוא מאפשר לכם להגדיר את הגדרות הבנייה של המודול הספציפי שבו הוא נמצא. הגדרת ההגדרות האלה של build מאפשרת לכם לספק אפשרויות אריזה בהתאמה אישית, כמו סוגי build נוספים וטעמי מוצר, ולבטל הגדרות במניפסט של האפליקציה main/ או בסקריפט build ברמה העליונה.
הגדרות Android SDK
קובץ ה-build ברמת המודול של האפליקציה כולל הגדרות שמציינות את גרסאות Android SDK שמשמשות להידור, לבחירת התנהגויות של הפלטפורמה ולציון הגרסה המינימלית שבה האפליקציה פועלת.
איור 1. Android SDKs in a build
compileSdk
ה-compileSdk קובע אילו ממשקי API של Android ו-Java זמינים כשמבצעים קומפילציה של קוד המקור. כדי להשתמש בתכונות האחרונות של Android, צריך להשתמש ב-Android SDK העדכני ביותר כשמבצעים קומפילציה.
כל Android SDK מספק קבוצת משנה של ממשקי Java API לשימוש באפליקציה.
בטבלה שבמאמר
Which Java APIs can I use in my Java or Kotlin source code
מוצגת רמת Java API שזמינה בהתאם לגרסת Android SDK.
ממשקי ה-API החדשים של Java נתמכים בגרסאות קודמות של Android באמצעות desugaring, שצריך להפעיל ב-build.
אם יש ניגוד בין compileSdk לבין הגרסה הנוכחית של Android Studio, AGP או דרישות התלות של הפרויקט בספרייה, מוצגות אזהרות ב-Android Studio.
minSdk
התג minSdk מציין את הגרסה הכי נמוכה של Android שאתם רוצים שהאפליקציה שלכם תתמוך בה. ההגדרה minSdk מגבילה את המכשירים שבהם אפשר להתקין את האפליקציה.
כדי לתמוך בגרסאות מוקדמות יותר של Android, יכול להיות שתצטרכו להוסיף עוד בדיקות מותנות לקוד או להשתמש יותר בספריות התאימות של AndroidX. כדאי לשקול את עלות התחזוקה של תמיכה בגרסאות ישנות יותר לעומת אחוז המשתמשים שעדיין משתמשים בגרסאות האלה. אפשר לראות את טבלת הגרסאות באשף הפרויקט החדש של Android Studio כדי לראות את אחוזי השימוש בגרסה הנוכחית.
כשעורכים את הקוד ב-Android Studio או מריצים בדיקות במהלך הבנייה, הכלי lint יציג אזהרה לגבי ממשקי API שבהם נעשה שימוש ושלא זמינים ב-minSdk. כדי לפתור את הבעיות האלה, צריך
להתנות את השימוש בתכונות חדשות יותר או להשתמש ב-Appcompat כדי ליצור תאימות לאחור.
targetSdk
הלחצן targetSdk משמש לשתי מטרות:
הוא מגדיר את התנהגות זמן הריצה של האפליקציה.
האישור מציין את גרסת Android שנבדקה.
אם האפליקציה פועלת במכשיר עם גרסת Android חדשה יותר מגרסת targetSdk, מערכת Android מפעילה את האפליקציה במצב תאימות שמתנהג באופן דומה לגרסה הישנה יותר שצוינה בtargetSdk. לדוגמה, כש-API 23 הציג את מודל ההרשאות בזמן ריצה, לא כל האפליקציות היו מוכנות לאמץ אותו באופן מיידי.
אם מגדירים את targetSdk ל-22, האפליקציות האלה יכולות לפעול במכשירים עם API 23 בלי להשתמש בהרשאות בזמן ריצה, ויכולות להשתמש בתכונות שכלולות בגרסה האחרונה של compileSdk. מדיניות ההפצה של Google Play מחייבת
כללי מדיניות נוספים בנושא רמת ה-API לטירגוט.
הערך של targetSdk לא מקושר לערך של compileSdk. לדוגמה, יכול להיות שהערך של targetSdk יהיה גבוה יותר, זהה או נמוך יותר מהערך של compileSdk.
הערה: הערכים של compileSdk ושל targetSdk לא צריכים להיות זהים. חשוב לזכור את העקרונות הבסיסיים הבאים:
מינוי ל-compileSdk נותן לכם גישה לממשקי API חדשים
targetSdk מגדיר את אופן הפעולה של זמן הריצה של האפליקציה
סקריפט לדוגמה של 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=36/** * 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=23// Specifies the API level used to test the app.targetSdk=36// 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.1")implementation(fileTree(mapOf("dir"to"libs","include"tolistOf("*.jar"))))}
Groovy
/** * 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{jvmToolchain11}/** * 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. */compileSdk36/** * 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.minSdk23// Specifies the API level used to test the app.targetSdk36// Defines the version number of your app.versionCode1// 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{minifyEnabledtrue// Enables code shrinking for the release build type.proguardFilesgetDefaultProguardFile('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{implementationproject(":lib")implementation'androidx.appcompat:appcompat:1.7.1'implementationfileTree(dir:'libs',include:['*.jar'])}
קובצי מאפיינים של Gradle
Gradle כולל גם שני קובצי מאפיינים שנמצאים בספריית הפרויקט הבסיסי, שבהם אפשר לציין הגדרות עבור ערכת הכלים לבנייה של Gradle עצמה:
gradle.properties
כאן אפשר להגדיר את הגדרות Gradle ברמת הפרויקט, כמו גודל הערימה המקסימלי של Gradle daemon. מידע נוסף זמין במאמר בנושא סביבת 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, מסתיימים בנתיבים ארוכים. הכלים לא תומכים היטב בנתיבים ארוכים.
כדי ליצור נתיב קצר יותר, מגדירים את המאפיין ndk.symlinkdir ב-local.properties כדי לבקש מהפלאגין של Android Gradle ליצור קישור סמלי ל-NDK. הנתיב של הקישור הסמלי יכול להיות קצר יותר מהתיקייה הקיימת של NDK.
לדוגמה, הפקודה ndk.symlinkdir = C:\ יוצרת את הקישור הסמלי הבא:
C:\ndk\19.0.5232133
סנכרון הפרויקט עם קובצי Gradle
כשמבצעים שינויים בקובצי הגדרות ה-build בפרויקט, צריך לסנכרן את קובצי הפרויקט ב-Android Studio כדי שהמערכת תוכל לייבא את השינויים בהגדרות ה-build ולהריץ כמה בדיקות כדי לוודא שההגדרות לא יוצרות שגיאות ב-build.
כדי לסנכרן את קובצי הפרויקט, לוחצים על סנכרון עכשיו בסרגל ההתראות שמופיע כשמבצעים שינוי, כמו שמוצג באיור 2, או לוחצים על סנכרון הפרויקט מסרגל התפריטים. אם Android Studio מוצא שגיאות בהגדרה – למשל, אם קוד המקור משתמש בתכונות של API שזמינות רק ברמת API גבוהה יותר מרמת compileSdkVersion – הבעיה מתוארת בחלון Messages.
איור 2. מסנכרנים את הפרויקט עם קובצי ההגדרות של ה-build ב-Android Studio.
קבוצות של מקורות
ב-Android Studio, קוד המקור והמשאבים של כל מודול מקובצים באופן לוגי בקבוצות של מקורות. כשיוצרים מודול חדש, Android Studio יוצר main/ קבוצת מקורות בתוך המודול. קבוצת המקור main/ של מודול כוללת את הקוד והמשאבים שמשמשים את כל וריאציות ה-build שלו.
ספריות נוספות של קבוצות מקור הן אופציונליות, ו-Android Studio לא יוצר אותן באופן אוטומטי כשמגדירים וריאציות חדשות של גרסאות build. עם זאת, יצירת קבוצות של קבצים, בדומה ל-main/, עוזרת לארגן קבצים ומשאבים ש-Gradle צריך להשתמש בהם רק כשמבצעים build של גרסאות מסוימות ש�� האפליקציה:
src/main/
קבוצת המקור הזו כוללת קוד ומשאבים שמשותפים לכל וריאציות הבנייה.
src/buildType/
Create this source set to include code and resources only for a specific
build type.
src/productFlavor/
יוצרים את קבוצת המקור הזו כך שתכלול קוד ומשאבים רק לגרסה ספציפית של המוצר.
הערה: אם הגדרתם את הגרסה שלכם לשילוב של כמה טעמים של מוצרים, אתם יכולים ליצור ספריות של ערכות מקור לכל שילוב של טעמים של מוצרים ב��ן ��מ��י הטעם: src/productFlavor1ProductFlavor2/.
src/productFlavorBuildType/
יוצרים את קבוצת המקור הזו כך שתכלול קוד ומשאבים רק עבור וריאציה ספציפית של build.
לדוגמה, כדי ליצור את הגרסה fullDebug של האפליקציה, מערכת ה-build ממזגת קוד, הגדרות ומשאבים ממערכות המקור הבאות:
src/fullDebug/ (מערך המקור של וריאנט ה-build)
src/debug/ (מקור סוג ה-build)
src/full/ (מקור גרסת המוצר)
src/main/ (קבוצת המקורות הראשית)
הערה: כשיוצרים קובץ או ספריה חדשים ב-Android Studio, משתמשים באפשרויות בתפריט File > New (קובץ > חדש) כדי ליצור אותם עבור קבוצת מקורות ספציפית. מערכת Android Studio יוצרת באופן אוטומטי את הספריות הנדרשות אם הן לא קיימות כבר. קבוצות המקורות שניתן לבחור מתוכן מבוססות על הגדרות ה-build.
אם קבוצות שונות של מקורות מכילות גרסאות שונות של אותו קובץ, Gradle משתמש בסדר העדיפות הבא כדי להחליט באיזה קובץ להשתמש. הגדרות המקור
שמופיעות בצד ימין מבטלות את הקבצים וההגדרות של קבוצות המקור שמופיעות
בצד שמאל:
build variant > build type > product flavor > main source set >
library dependencies
כך Gradle יכול להשתמש בקבצים שספציפיים לגרסת ה-build שאתם מנסים ליצור, תוך שימוש חוזר בפעילויות, בלוגיקה של האפליקציה ובמשאבים שמשותפים לגרסאות אחרות של האפליקציה.
כשממזגים כמה קובצי מניפסט, Gradle משתמש באותו סדר עדיפות, כך שכל וריאציה של build יכולה להגדיר רכיבים או הרשאות שונים במניפסט הסופי. מידע נוסף על יצירת קבוצות מקורות מותאמות אישית זמין במאמר יצירת קבוצות מקורות.
קטלוגים של גרסאות
אם ה-build מכיל כמה מודולים עם יחסי תלות משותפים, או אם יש לכם כמה פרויקטים עצמאיים עם יחסי תלות משותפים, מומלץ להשתמש בקטלוג גרסאות או ב-BOM (רשימת חומרים) כדי לציין את הגרסאות המשותפות.
מערכות build אחרות
אפשר ליצור אפליקציות ל-Android באמצעות Bazel, אבל אין תמיכה רשמית בכך. Android Studio לא תומך רשמית בפרויקטים של Bazel.
כדי להבין טוב יותר את המגבלות הנוכחיות של בנייה באמצעות Bazel, אפשר לעיין בבעיות המוכרות.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2026-03-31 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2026-03-31 (שעון UTC)."],[],[]]
מסרגל התפריטים. אם Android Studio מוצא שגיאות בהגדרה – למשל, אם קוד המקור משתמש בתכונות של API שזמינות רק ברמת API גבוהה יותר מרמת 