Android Gradle Plugin 3.4.0 (אפריל 2019)
כדי להשתמש בגרסה הזו של הפלאגין ל-Android, צריך:
גרסת מינימום | גרסת ברירת המחדל | הערות | |
---|---|---|---|
Gradle | 5.1.1 | 5.1.1 | מידע נוסף זמין במאמר בנושא עדכון Gradle. כשמשתמשים ב-Gradle 5.0 ומעלה, גודל ה-heap של זיכרון הדמון של Gradle יורד מ-1GB ל-512MB. יכול להיות שהדבר יוביל לרגרסיה בביצועי ה-build. כדי לשנות את הגדרת ברירת המחדל הזו, צריך לציין את גודל הערימה של Gradle daemon בקובץ gradle.properties של הפרויקט. |
SDK Build Tools | 28.0.3 | 28.0.3 | מתקינים או מגדירים SDK Build Tools. |
העדכון הקטן הזה תומך בתאימות להגדרות ברירת מחדל ולתכונות חדשות של חבילות גלויות ב-Android 11.
פרטים נוספים זמינים בהערות הגרסה 4.0.1.
3.4.2 (יולי 2019)
העדכון הקטן הזה תומך ב-Android Studio 3.4.2 וכולל תיקוני באגים שונים ושיפורי ביצועים. כדי לראות רשימה של תיקוני באגים חשובים, אפשר לקרוא את הפוסט שקשור לכך ב בלוג של עדכוני גרסה.
3.4.1 (מאי 2019)
העדכון הקטן הזה תומך ב-Android Studio 3.4.1 וכולל תיקוני באגים שונים ושיפורי ביצועים. כדי לראות רשימה של תיקוני באגים חשובים, אפשר לקרוא את הפוסט שקשור לכך ב בלוג של עדכוני גרסה.
תכונות חדשות
-
הגדרות חדשות של תלות בבדיקת lint: ההתנהגות של
lintChecks
השתנתה, והוצגה הגדרת תלות חדשה,lintPublish
, כדי לתת לכם יותר שליטה על בדיקות ה-lint שנכללות בספריות Android.-
lintChecks
: זוהי הגדרה קיימת שצריך להשתמש בה לבדיקות Lint שרוצים להריץ רק כשמבצעים build של הפרויקט באופן מקומי. אם השתמשתם בעבר בהגדרת התלותlintChecks
כדי לכלול בדיקות lint ב-AAR שפורסם, אתם צריכים להעביר את התלויות האלה להגדרה החדשהlintPublish
שמתוארת בהמשך. -
lintPublish
: משתמשים בהגדרה החדשה הזו בפרויקטים של ספריות לבדיקות lint שרוצים לכלול ב-AAR שפורסם, כמו שמוצג בהמשך. כלומר, הפרויקטים שמשתמשים בספרייה שלכם יפעילו גם את בדיקות ה-lint האלה.
בדוגמת הקוד הבאה נעשה שימוש בשתי הגדרות של תלות בפרויקט מקומי של ספריית Android.
dependencies { // Executes lint checks from the ':lint' project at build time. lintChecks project(':lint') // Packages lint checks from the ':lintpublish' in the published AAR. lintPublish project(':lintpublish') }
dependencies { // Executes lint checks from the ':lint' project at build time. lintChecks(project(":lint")) // Packages lint checks from the ':lintpublish' in the published AAR. lintPublish(project(":lintpublish")) }
-
באופן כללי, אמור להיות שיפור במהירות הבנייה של משימות אריזה וחתימה. אם אתם מבחינים בירידה בביצועים שקשורה למשימות האלה, אתם מוזמנים לדווח על באג.
-
שינויים בהתנהגות
-
הוצאה משימוש של הפלאגין של תכונת האפליקציות ללא התקנה ב-Android אזהרה: אם אתם עדיין משתמשים בפלאגין
com.android.feature
כדי לבנות את האפליקציה ללא התקנה, תקבלו אזהרה על הוצאה משימוש בפלאגין Android Gradle 3.4.0. כדי לוודא שתוכלו להמשיך ליצור אפליקציה ללא התקנה בגרסאות עתידיות של הפלאגין, צריך להעביר את האפליקציה לשימוש בפלאגין של תכונה דינמית. הפלאגין הזה מאפשר גם לפרסם את האפליקציה המותקנת ואת האפליקציה ללא התקנה מקובץ Android App Bundle יחיד. -
הכלי R8 מופעל כברירת מחדל: הכלי R8 משלב את הפעולות הבאות בשלב אחד: הסרת סוכר, צמצום, טשטוש, אופטימיזציה ו-dexing. התוצאה היא שיפורים משמעותיים בביצועי הבנייה. הכלי R8 הוצג בתוסף Android Gradle בגרסה 3.3.0, וכעת הוא מופעל כברירת מחדל גם בפרויקטים של אפליקציות וגם בפרויקטים של ספריות Android באמצעות תוסף בגרסה 3.4.0 ומעלה.
בתמונה הבאה מוצגת סקירה כללית של תהליך ההידור לפני שהוצג R8.

עכשיו, עם R8, כל הפעולות האלה – desugaring, shrinking, obfuscating, optimizing ו-dexing (D8) – מתבצעות בשלב אחד, כפי שמוצג בהמשך.

חשוב לזכור: R8 מיועד לעבוד עם כללי ProGuard הקיימים, כך שסביר להניח שלא תצטרכו לבצע פעולות כלשהן כדי ליהנות מהיתרונות של R8. עם זאת, מכיוון שמדובר בטכנולוגיה שונה מ-ProGuard, שנועדה במיוחד לפרויקטים של Android, יכול להיות שהכיווץ והאופטימיזציה יגרמו להסרת קוד ש-ProGuard לא היה מסיר. לכן, במצב הלא סביר הזה, יכול להיות שתצטרכו להוסיף כללים נוספים כדי שהקוד הזה יישאר בפלט של הבנייה.
אם נתקלתם בבעיות בשימוש ב-R8, כדאי לעיין בשאלות הנפוצות בנושא תאימות ל-R8 כדי לבדוק אם יש פתרון לבעיה. אם הפתרון לא מתועד, אפשר לדווח על באג.
כדי להשבית את R8, מוסיפים אחת מהשורות הבאות לקובץ gradle.properties
של הפרויקט:
# Disables R8 for Android Library modules only.
android.enableR8.libraries = false
# Disables R8 for all modules.
android.enableR8 = false
הערה: אם מגדירים את הערך useProguard
ל-false
בקובץ build.gradle
של מודול האפליקציה עבור סוג מסוים של build, הפלאגין Android Gradle משתמש ב-R8 כדי לכווץ את הקוד של האפליקציה עבור סוג ה-build הזה, גם אם משביתים את R8 בקובץ gradle.properties
של הפרויקט.
-
הוצאה משימוש של
ndkCompile
: אם מנסים להשתמש ב-ndkBuild
כדי לקמפל את הספריות המקוריות, מוצגת שגיאת בנייה. במקום זאת, צריך להשתמש ב-CMake או ב-ndk-build כדי להוסיף קוד C ו-C++ לפרויקט.
בעיות מוכרות
-
בשלב הזה, אנחנו לא אוכפים את השימוש הנכון בשמות חבילות ייחודיים, אבל בגרסאות מאוחרות יותר של הפלאגין נהיה יותר מחמירים בנושא. בגרסה 3.4.0 של הפלאגין Android Gradle, אפשר להוסיף את השורה הבאה לקובץ
gradle.properties
כדי להפעיל את האפשרות לבדוק אם הפרויקט כולל שמות חבילות מקובלים.android.uniquePackageNames = true
מידע נוסף על הגדרת שם חבילה באמצעות הפלאגין של Android Gradle זמין במאמר בנושא הגדרת מזהה האפליקציה.