Gradle והפלאגין של Android Gradle עוזרים לכם להגדיר את ההיבטים הבאים של ה-build:
סוגי גרסאות build
סוגי ה-build מגדירים מאפיינים מסוימים שבהם Gradle משתמש בזמן ה-build והאריזה של האפליקציה. בדרך כלל, סוגי ה-build מוגדרים לשלבים שונים במחזור החיים של הפיתוח.
לדוגמה, סוג ה-build לניפוי באגים מאפשר להפעיל אפשרויות לניפוי באגים ולחתום על האפליקציה באמצעות מפתח לניפוי באגים, בעוד שסוג ה-build לגרסה זמינה לציבור עשוי לכווץ, להסתיר ולחתום על האפליקציה באמצעות מפתח גרסה זמינה לציבור לצורך הפצה.
כדי ליצור את האפליקציה, צריך להגדיר לפחות סוג 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.
תמיכה בכמה חבילות APK
מערכת ה-build מאפשרת ליצור באופן אוטומטי חבילות APK שונות, שכל אחת מהן מכילה רק את הקוד והמשאבים הנדרשים לצפיפות מסך ספציפית או לממשק בינארי של אפליקציה (ABI).
מידע נוסף זמין במאמר יצירת כמה חבילות APK. עם זאת, הגישה המומלצת היא
פרסום AAB יחיד, כי הוא מאפשר פיצול לפי שפה, בנוסף לדחיסות המסך ו-ABI, ולהימנע מהצורך להעלות כמה
פריטי מידע שנוצרו בתהליך הפיתוח (Artifact) ל-Google Play. כל האפליקציות החדשות שנשלחות אחרי אוגוסט 2021
חייבות להשתמש ב-AAB.
גרסאות Java בגרסאות build של Android
בין שקוד המקור שלכם נכתב ב-Java, ב-Kotlin או בשתיהן, יש כמה מקומות שבהם עליכם לבחור גרסת JDK או שפת Java ל-build. פרטים נוספים זמינים במאמר גרסאות Java בגרסאות build של Android.
קובצי תצורת build
כדי ליצור הגדרות build בהתאמה אישית, צריך לבצע שינויים בקובץ אחד או יותר של הגדרות build. בקובצי הטקסט האלה נעשה שימוש בשפה ייעודית לדומיין (DSL) כדי לתאר את הלוגיקה של ה-build ולבצע בה שינויים באמצעות סקריפט Kotlin, שהוא גרסה של שפת Kotlin. אפשר גם להשתמש ב-Groovy, שזו שפה דינמית למכונה הווירטואלית של Java (JVM), כדי להגדיר את הגרסאות הבנויות.
לא צריך לדעת את הסקריפט של Kotlin או Groovy כדי להתחיל להגדיר את ה-build, כי הפלאגין של Android Gradle מציג את רוב רכיבי ה-DSL שאתם צריכים. למידע נוסף על ה-DSL של הפלאגין של Android Gradle, קראו את מאמרי העזרה של ה-DSL. הסקריפט Kotlin מסתמך גם על Gradle Kotlin DSL
כשאתם מתחילים פרויקט חדש, מערכת Android Studio יוצרת עבורכם חלק מהקבצים האלה באופן אוטומטי ומאכלסת אותם על סמך הגדרות ברירת מחדל הגיוניות. מבנה ה-build של Android
קובץ ה-Gradle Wrapper
ה-wrapper של Gradle (gradlew) הוא אפליקציה קטנה שכלולה בקוד המקור, שמורידה את Gradle ומפעילה אותו.
כך אפשר לבצע את ה-build בצורה עקבית יותר. המפתחים מורידים את מקור האפליקציה ומריצים את gradlew. הפקודה הזו מאפשרת להוריד את חלוקת Gradle הנדרשת ולהפעיל את Gradle כדי ליצור את האפליקציה.
הקובץ gradle/wrapper/gradle-wrapper.properties מכיל את המאפיין distributionUrl, שמתאר איזו גרסה של Gradle משמשת להרצת ה-build שלכם.
הקובץ settings.gradle.kts (ל-Kotlin DSL) או קובץ settings.gradle (ל-Groovy DSL) נמצאים בספריית הפרויקט ברמה הבסיסית. קובץ ההגדרות הזה מגדיר את ההגדרות של המאגר ברמת הפרויקט, ומציין ל-Gradle אילו מודולים הוא צריך לכלול בזמן ה-build של האפליקציה. בפרויקטים עם כמה מודולים, צריך לציין כל מודול שצריך להיכלל ב-build הסופי.
קובץ build.gradle.kts ברמה העליונה (ל-DSL של Kotlin) או קובץ build.gradle (ל-DSL של Groovy) נמצא בספריית הבסיס של הפרויקט. בדרך כלל הוא מגדיר את הגרסאות הנפוצות של הפלאגינים שבהם נעשה שימוש על ידי המודולים בפרויקט.
דוגמת הקוד הבאה מתארת את הגדרות ברירת המחדל ואת רכיבי ה-DSL בסקריפט ה-build ברמה העליונה אחרי יצירת פרויקט חדש:
build.gradle.kts ברמת המודול (ל-Kotlin DSL) או קובץ build.gradle (ל-Groovy DSL) נמצאים בכל ספרייה של project/module/. היא מאפשרת להגדיר הגדרות build למודול הספציפי שבו היא נמצאת. הגדרת הגדרות ה-build האלה מאפשרת לכם לספק אפשרויות אריזה בהתאמה אישית, כמו סוגים נוספים של build וסוגים נוספים של מוצרים, ולשנות את ההגדרות במניפסט של האפליקציה main/ או בסקריפט ה-build ברמה העליונה.
הגדרות Android SDK
קובץ ה-build ברמת המודול של האפליקציה כולל הגדרות שמציינות את גרסאות Android SDK ששימשו בתהליך ה-compile, את בחירת התנהגויות הפלטפורמה ואת הגרסה המינימלית שבה האפליקציה פועלת.
איור 1. Android SDKs ב-build
compileSdk
הערך של compileSdk קובע אילו ממשקי API של Android ו-Java יהיו זמינים בזמן הידור קוד המקור. כדי להשתמש בתכונות החדשות ביותר של Android, צריך להשתמש ב-Android SDK העדכני ביותר בזמן הידור.
כל 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:
Gradle כולל גם שני קובצי מאפיינים שנמצאים בספריית השורש של הפרויקט, שבהם אפשר לציין הגדרות לערכת הכלים של Gradle ליצירת גרסאות build:
gradle.properties
כאן אפשר להגדיר הגדרות Gradle ברמת הפרויקט, כמו גודל האשפה המקסימלי של הדימון של Gradle. למידע נוסף, ראו פיתוח סביבה.
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.
איור 2. סנכרון הפרויקט עם קובצי התצורה של ה-build ב-Android Studio.
קבוצות מקור
מערכת 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, משתמשים באפשרויות התפריט File (קובץ) > New (חדש) כדי ליצור אותם עבור קבוצת מקורות ספציפית. קבוצות המקור שאפשר לבחור מבוססות על הגדרות ה-build, ו-Android Studio יוצרת באופן אוטומטי את הספריות הנדרשות אם הן עדיין לא קיימות.
אם קבוצות מקור שונות מכילות גרסאות שונות של אותו קובץ, Gradle משתמש בסדר העדיפויות הבא כדי להחליט באיזה קובץ להשתמש. קבוצות המקור בצד ימין מבטלות את הקבצים וההגדרות של קבוצות המקור בצד שמאל:
גרסת build > סוג build > סוג המוצר > קבוצת המקור הראשית >
יחסי תלות בספריות
כך Gradle יכול להשתמש בקבצים שספציפיים לגרסה של ה-build שאתם מנסים ליצור, תוך שימוש חוזר בפעילויות, בלוגיקה של האפליקציה ובמשאבים שקיימים בגרסאות אחרות של האפליקציה.
כשממזגים כמה מניפסטים, Gradle משתמש באותו סדר עדיפות כדי שכל וריאנט build יוכל להגדיר רכיבים או הרשאות שונים במניפסט הסופי. למידע נוסף על יצירת קבוצות מקורות בהתאמה אישית, קראו את המאמר יצירת קבוצות מקורות.
קטלוגים של גרסאות
אם ה-build שלכם מכיל מספר מודולים עם יחסי תלות נפוצים, או שיש לכם כמה פרויקטים עצמאיים עם יחסי תלות נפוצים, מומלץ להשתמש בקטלוג גרסאות או חיוב חומרים (BOM) כדי לציין את הגרסאות הנפוצות.
מערכות פיתוח אחרות
אפשר לפתח אפליקציות ל-Android באמצעות Bazel, אבל אין תמיכה רשמית בהן. ב-Android Studio אין תמיכה רשמית בפרויקטים של Bazel.
כדי להבין טוב יותר את המגבלות הנוכחיות של הבנייה עם Bazel, קראו את הבעיות המוכרות.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.