קובץ ה-build ברמת המודול

הקובץ build.gradle.kts (ב-Kotlin DSL) או build.gradle (ב-Groovy DSL) ברמת המודול נמצא בכל ספרייה project/module/. הוא מאפשר לכם להגדיר את הגדרות הבנייה של המודול הספציפי שבו הוא נמצא. הגדרת ההגדרות האלה של build מאפשרת לכם לספק אפשרויות אריזה בהתאמה אישית, כמו סוגי build נוספים וטעמי מוצר, ולבטל הגדרות במניפסט של האפליקציה main/ או בסקריפט build ברמה העליונה.

הגדרות Android SDK

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

compileSdk

ה-compileSdk קובע אילו ממשקי API של Android ו-Java זמינים כשמבצעים קומפילציה של קוד המקור. כדי להשתמש בתכונות האחרונות של Android, צריך להשתמש ב-Android SDK העדכני ביותר כשמבצעים קומפילציה.

יכול להיות שחלק מממשקי ה-API של פלטפורמת Android לא יהיו זמינים ברמות API ישנות יותר. אפשר להגביל את השימוש בתכונות חדשות יותר בתנאים מסוימים או להשתמש בספריות התאימות של AndroidX כדי להשתמש בתכונות חדשות יותר עם רמות נמוכות יותר של Android API.

כל 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 משמש לשתי מטרות:

1. הוא מגדיר את התנהגות זמן הריצה של האפליקציה.
2. האישור מציין את גרסת Android שנבדקה.

אם האפליקציה פועלת במכשיר עם גרסת Android חדשה יותר מגרסת targetSdk, מערכת Android מפעילה את האפליקציה במצב תאימות שמתנהג באופן דומה לגרסה הישנה יותר שצוינה בtargetSdk. לדוגמה, כש-API 23 הציג את מודל ההרשאות בזמן ריצה, לא כל האפליקציות היו מוכנות לאמץ אותו באופן מיידי. אם מגדירים את targetSdk ל-22, האפליקציות האלה יכולות לפעול במכשירים עם API 23 בלי להשתמש בהרשאות בזמן ריצה, ויכולות להשתמש בתכונות שכלולות בגרסה האחרונה של compileSdk. מדיניות ההפצה של Google Play מחייבת כללי מדיניות נוספים בנושא רמת ה-API לטירגוט.

הערך של targetSdk לא מקושר לערך של compileSdk. לדוגמה, יכול להיות שהערך של targetSdk יהיה גבוה יותר, זהה או נמוך יותר מהערך של compileSdk.

סקריפט לדוגמה של build של מודול אפליקציה

בסקריפט הבנייה של מודול אפליקציית Android לדוגמה הזה מפורטים חלק מההגדרות והרכיבים הבסיסיים של DSL:

קובצי מאפיינים של 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, או לוחצים על סנכרון הפרויקט 👁 Image
מסרגל התפריטים. אם Android Studio מוצא שגיאות בהגדרה – למשל, אם קוד המקור משתמש בתכונות של API שזמינות רק ברמת API גבוהה יותר מרמת compileSdkVersion – הבעיה מתוארת בחלון Messages.

קבוצות של מקורות

ב-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, אפשר לעיין בבעיות המוכרות.