מערכת ה-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.5.0" apply false id("com.android.library") version "8.5.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.5.0' apply false id 'com.android.library' version '8.5.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }
קובץ ה-build ברמת המודול
build.gradle.kts
ברמת המודול (ל-Kotlin DSL) או
הקובץ build.gradle
(ל-Groovy DSL) נמצא בכל
ספריית project/module/
. הוא מאפשר
קביעת הגדרות build למודול הספציפי שבו הוא נמצא. מתבצעת הגדרה
הגדרות ה-build האלה מאפשרות לכם לספק אפשרויות אריזה בהתאמה אישית,
סוגי build נוספים וטעמים נוספים של מוצרים, ואפשרות לעקוף את ההגדרות
main/
קובץ מניפסט של אפליקציה או סקריפט build ברמה העליונה.
הגדרות Android SDK
קובץ ה-build ברמת המודול של האפליקציה שלכם כולל הגדרות שמציינות גרסאות Android SDK שמשמשות להידור, בחירת התנהגויות של הפלטפורמה שמציין את הגרסה המינימלית שבה האפליקציה מופעלת.
-
compileSdk
-
הרכיב
compileSdk
קובע אילו ממשקי API של Android ושל Java זמינים במהלך הידור קוד המקור. כדי להשתמש בגרסה העדכנית ביותר של Android תכונות, יש להשתמש בגרסה העדכנית ביותר של Android SDK בעת הידור.יכול להיות שחלק מממשקי ה-API של פלטפורמת Android לא יהיו זמינים ברמות API ישנות יותר. אפשר הגנה מותנה על שימוש בתכונות חדשות יותר או שימוש ספריות תאימות של AndroidX לשימוש בתכונות חדשות יותר עם גרסאות רמות ה-API ב-Android.
כל ערכת SDK של Android מספקת קבוצת משנה של ממשקי API של Java לשימוש באפליקציה. הטבלה ב באילו ממשקי API של Java אפשר להשתמש בקוד המקור של Java או Kotlin מראה איזו רמת API של Java זמינה על סמך גרסת Android SDK. ממשקי ה-API החדשים יותר של Java נתמכים בגרסאות קודמות של Android דרך הסרת סוכרים, שחייב להיות שמופעל ב-build שלך.
ב-Android Studio מוצגות אזהרות במקרה של התנגשות בין
compileSdk
בגרסה הנוכחית של Android Studio, של AGP או של ספריית הפרויקט והתלות. -
minSdk
-
השדה
minSdk
מציין את גרסת Android הנמוכה ביותר שיש לך שרוצים שהאפליקציה שלכם תתמוך בהם. ההגדרה שלminSdk
מגבילה מכשירים יוכלו להתקין את האפליקציה שלך.יכול להיות שתמיכה בגרסאות קודמות של Android תדרוש יותר בדיקות מותנות בקוד או להשתמש יותר בספריות תאימות של AndroidX. אתם צריכים לשקול את עלות התחזוקה של תמיכה בגרסאות נמוכות יותר ביחס אחוז המשתמשים שעדיין משתמשים בגרסאות נמוכות יותר. לצפייה תרשים הגרסאות באשף הפרויקט החדש ב-Android Studio של אחוזי השימוש הנוכחיים בגרסה.
כשעורכים את הקוד ב-Android Studio או כשמריצים בדיקות במהלך ה-build שלך, איתור השגיאות בקוד יזהיר לגבי ממשקי API שאינם זמינים
minSdk
. עליך לתקן את הבעיות האלה עד הגדרת תכונות חדשות יותר כמותנות או באמצעותAppcompat
לתאימות לאחור. -
targetSdk
-
השדה
targetSdk
משמש לשתי מטרות:- הוא מגדיר את ההתנהגות של האפליקציה בסביבת זמן הריצה.
- היא מאפשרת לאמת באיזו גרסה של Android ביצעתם את הבדיקה.
אם אתה משתמש במכשיר שמותקנת בו גרסת Android גבוהה יותר מ-
targetSdk
, מערכת Android מפעילה את האפליקציה במצב תאימות שמתנהג באופן דומה לגרסה הנמוכה יותר שמצוינתtargetSdk
לדוגמה, כשב-API 23 נוסף סביבת זמן הריצה של ההרשאות, לא כל האפליקציות היו מוכנות ליישם אותו באופן מיידי. אם קובעים במדיניות את הערך 22 שלtargetSdk
, האפליקציות האלה יכולות לפעול מכשירי API 23 בלי להשתמש בהרשאות בתחילת ההפעלה, ויכולים להשתמש בתכונות כלולה בגרסה האחרונה שלcompileSdk
. Google Play אוכפת מדיניות ההפצה כללי מדיניות נוספים ברמת ה-API המטורגטת.הערך של
targetSdk
חייב להיות קטן מ- או שווה לו לסכום שלcompileSdk
.
הערה: הערכים של compileSdk
ושל targetSdk
לא צריכות להיות זהות. חשוב לזכור את העקרונות הבסיסיים הבאים:
compileSdk
מעניקה לך גישה לממשקי API חדשיםtargetSdk
קובע את ההתנהגות של האפליקציה בסביבת זמן הריצהtargetSdk
חייב להיות קטן מ-compileSdk
או שווה לו
דוגמה של סקריפט build של מודול אפליקציה
סקריפט ה-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 כוללת גם שני קובצי מאפיינים שנמצאים בפרויקט הבסיס שאפשר להשתמש בה כדי לציין הגדרות לערכת הכלים לבניית Gradle עצמו:
-
gradle.properties
- כאן אפשר לקבוע את הגדרות Gradle ברמת הפרויקט, כמו גודל הערימה המקסימלי של דימון (daemon) ב-Gradle. למידע נוסף, ראו Build Environment (פיתוח סביבה).
-
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 (סנכרון עכשיו) בקטע
סרגל ההתראות שמופיע כאשר אתה מבצע שינוי, כפי שמוצג
איור 1, או ללחוץ על סנכרון פרויקט
מסרגל התפריטים. אם יימצאו שגיאות ב-Android Studio
להגדרת המודל. לדוגמה, קוד המקור משתמש בתכונות API
זמינה ברמת API גבוהה יותר מזו של
compileSdkVersion
– החלון הודעות מתאר את הבעיה.
![](https://developer.android.com/static/images/tools/as-gradlesync.png?authuser=2&hl=he)
קבוצות מקור
מערכת Android Studio מקבצת באופן לוגי את קוד המקור והמשאבים עבור כל מודול
לקבוצות מקורות. כשיוצרים מודול חדש, Android Studio
יוצרת קבוצת מקור main/
בתוך המודול. קוד
קבוצת מקור אחת (main/
) כוללת את הקוד והמשאבים ששימשו את כל
ליצור וריאציות.
ספריות נוספות של קבוצת המקור הן אופציונליות, ו-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, לוחצים על File > אפשרויות תפריט חדשות ליצירה אותו עבור קבוצת מקור ספציפית. קבוצות המקורות שמתוכן אפשר לבחור מבוססות על בהגדרות ה-build ו-Android Studio יוצר באופן אוטומטי של הספריות הנדרשות, אם הן עדיין לא קיימות.
אם קבוצות מקור שונות מכילות גרסאות שונות של אותו קובץ, Gradle המערכת משתמשת בסדר העדיפות הבא כדי להחליט באיזה קובץ להשתמש. שפת מקור בצד שמאל מחליפים את הקבצים וההגדרות של קבוצות המקור right:
גרסת build > סוג build > טעם המוצר > קבוצת המקור הראשית > של יחסי התלות של ספריות
כך Gradle תוכל להשתמש בקבצים שספציפיים לווריאנט ה-build שלך מנסים לבנות בזמן שימוש חוזר בפעילויות, בלוגיקת אפליקציות משאבים שמשותפים לגרסאות אחרות של האפליקציה.
במהלך מיזוג של מספר נכסים מניפסטים, Gradle משתמשת באותו סדר עדיפות, כך שכל וריאנט של build יכול להגדיר הרשאות או רכיבים שונים במניפסט הסופי. למידה מידע נוסף על יצירת קבוצות מקורות מותאמות אישית זמין במאמר יצירת קבוצות מקור.
קטלוגים של גרסאות
אם ה-build שלך מכיל כמה מודולים עם יחסי תלות נפוצים, או אם יש לכם כמה פרויקטים עצמאיים עם יחסי תלות משותפים, משתמשים קטלוג גרסאות או חיוב חומרים (BOM) אל לציין את הגרסאות הנפוצות.
מערכות פיתוח אחרות
בניית אפליקציות ל-Android באמצעות Bazel היא אבל אין תמיכה רשמית שלו. Android Studio לא פועל באופן רשמי לתמוך בפרויקטים של Bazel.
כדי להבין טוב יותר את המגבלות הנוכחיות של הבנייה עם Bazel, אפשר לעיין בעיות ידועות.