פלאגין Android Gradle 4.0.0 (אפריל 2020)

לגרסה הזו של הפלאגין ל-Android נדרשות התכונות הבאות:

4.0.1 (יולי 2020)

העדכון הקטן הזה תומך בתאימות להגדרות ברירת מחדל חדשות פיצ'רים של package הרשאות גישה ב-Android 11.

בגרסאות קודמות של Android, אפשר היה להציג רשימה של כל המכשירים מהאפליקציות המותקנות במכשיר. החל מ-Android 11 (רמת API 30), מאת לאפליקציות ברירת המחדל יש גישה רק לרשימה מסוננת של החבילות המותקנות. כדי לראות רשימה רחבה יותר של האפליקציות במערכת, עכשיו צריך הוספת רכיב אחד (<queries>) באפליקציה או בספרייה מניפסט של Android.

הפלאגין Android Gradle מגרסה 4.1 ואילך כבר תואם לגרסה החדשה הצהרה בנושא <queries>; אבל גרסאות ישנות יותר תואמת. אם מוסיפים את הרכיב <queries> או אם להתחיל להסתמך על ספרייה או SDK שתומכות בטירגוט ל-Android 11, ייתכן שתיתקלו בשגיאות במיזוג מניפסטים במהלך פיתוח האפליקציה.

כדי לטפל בבעיה, אנחנו משיקים קבוצת תיקונים ל-AGP 3.3 גבוהה יותר. אם אתם משתמשים בגרסה ישנה יותר של AGP, שדרוג לאחת מהגרסאות הבאות:

גרסת המינימום גרסת ברירת המחדל הערות
גרדל 6.1.1 6.1.1 מידע נוסף על עדכון Gradle
כלים לבניית SDK 29.0.2 29.0.2 התקנה או הגדרה של כלים לבניית SDK.

למידע נוסף על התכונה החדשה הזו, אפשר לבקר כאן הרשאות גישה לחבילה ב-Android 11.

תכונות חדשות

הגרסה הזו של הפלאגין Android Gradle כוללת את התכונות החדשות הבאות.

תמיכה בכלי הניתוח לבנייה של Android Studio

החלון של Build Analyzer עוזר לך להבין ולאבחן בעיות של של גרסאות build, כמו אופטימיזציות מושבתות ומשימות שהוגדרו בצורה שגויה. התכונה הזו זמינה כשמשתמשים ב-Android Studio 4.0 ואילך עם פלאגין Android Gradle 4.0.0 ואילך. אפשר לפתוח את Build Analyzer. החלון מ-Android Studio באופן הבא:

  1. אם עדיין לא עשיתם זאת, יוצרים את האפליקציה על ידי בחירה באפשרות Build > (פיתוח >) יצרן פרויקט מסרגל התפריטים.
  2. בוחרים באפשרות תצוגה > Windows בכלי > build מסרגל התפריטים.
  3. בחלון Build, פותחים את החלון Build Analyzer (כלי הניתוח). בדרכים הבאות:
    • לאחר סיום בניית הפרויקט ב-Android Studio, לוחצים על Build בכרטיסייה 'ניתוח נתונים'.
    • לאחר סיום בניית הפרויקט ב-Android Studio, לוחצים על הקישור הצד הימני של החלון Build Output (יצירת פלט).

החלון של Build Analyzer מארגן את הבעיות האפשריות ב-build בעץ שמאלה. אפשר לבדוק כל בעיה וללחוץ עליה כדי לחקור את הפרטים שלה בצד שמאל. כשמערכת Android Studio מנתחת את ה-build, היא מחשבת את הקבוצה של משימות שקבעו את משך ה-build ומספק המחשה ויזואלית עוזרות לכם להבין את ההשפעה של כל אחת מהמשימות האלה. אפשר גם לקבל פרטים לקבלת אזהרות על ידי הרחבת הצומת Warnings (אזהרות).

מידע נוסף זמין במאמר בנושא זיהוי רגרסיות של מהירות build.

שינוי רמת הריכוז של ספריית Java 8 ב-D8 וב-R8

הפלאגין Android Gradle כולל עכשיו תמיכה לשימוש בכמה גרסאות Java 8 ממשקי API של שפה ללא צורך ברמת API מינימלית לאפליקציה.

באמצעות תהליך שנקרא הסרת סוכרים, מהדר DEX, D8, ב-Android Studio 3.0 ומעלה כבר מספקת תמיכה משמעותית בתכונות שפת Java 8 (כמו ביטויי lambda, שיטות ברירת מחדל בממשק, התנסות עם משאבים עוד). ב-Android Studio 4.0, מנוע ההסרה הורחב כדי שיוכל ל-desugar language APIs. כלומר, עכשיו אתם יכולים לכלול ממשקי API שהיו זמינים רק בגרסאות האחרונות של Android ( java.util.streams) באפליקציות שתומכות בגרסאות ישנות של Android.

בגרסה הזו יש תמיכה בקבוצת ממשקי ה-API הבאה:

  • שידורים ברצף (java.util.stream)
  • קבוצת משנה של java.time
  • java.util.function
  • תוספות אחרונות לjava.util.{Map,Collection,Comparator}
  • אופציונלי (java.util.Optional, java.util.OptionalInt ו- java.util.OptionalDouble) ועל כמה כיתות חדשות אחרות שמועילות למעלה ממשקי API
  • כמה תוספות ל-java.util.concurrent.atomic (שיטות חדשות בנושא AtomicInteger, AtomicLong וגם AtomicReference)
  • ConcurrentHashMap (עם תיקוני באגים ב-Android 5.0)

כדי לתמוך בממשקי ה-API לשפות האלה, ב-D8 נוצר קובץ DEX נפרד של ספרייה מכיל הטמעה של ממשקי ה-API החסרים וכולל אותו באפליקציה. תהליך הסרת הסוכר משכתב את קוד האפליקציה כדי שישתמש בספרייה הזו בסביבת זמן ריצה.

כדי להפעיל תמיכה לממשקי ה-API בשפות האלה, צריך לכלול את הפרטים הבאים קובץ build.gradle של מודול האפליקציה:

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }

compileOptions { // Flag to enable support for the new language APIs coreLibraryDesugaringEnabled true // Sets Java compatibility to Java 8 sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } }

dependencies { coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4' }

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled = true
  }

compileOptions { // Flag to enable support for the new language APIs isCoreLibraryDesugaringEnabled = true // Sets Java compatibility to Java 8 sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } }

dependencies { coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4") }

לתשומת ליבכם: ייתכן שתצטרכו לכלול גם את קטע הקוד שלמעלה בקטע של המודול של הספרייה של build.gradle אם

  • הבדיקות האינסטרומנטטיביות של מודול הספרייה משתמשות בממשקי ה-API לשפה האלה ( באופן ישיר, או באמצעות מודול הספרייה או יחסי התלות שלו. ככה עושים את זה: ממשקי ה-API החסרים סופקו ל-APK של הבדיקה האינסטרומנטלית.

  • אתם רוצים להריץ איתור שגיאות בקוד במודול הספרייה בנפרד. המטרה היא לעזור איתור שגיאות בקוד (lint) מזהה שימושים חוקיים בממשקי ה-API של השפה ונמנע מדיווח False אזהרות.

אפשרויות חדשות להפעלה או להשבתה של תכונות build

הפלאגין Android Gradle בגרסה 4.0.0 כולל דרך חדשה לקבוע אילו תכונות build שרוצים להפעיל ולהשבית, כגון 'קישור תצוגה' ו'קישור נתונים'. כשמוסיפים תכונות חדשות, הן מושבתות כברירת מחדל. אפשר ואז להשתמש בבלוק buildFeatures כדי להפעיל רק את התכונות הרצויות, עוזר לבצע אופטימיזציה של ביצועי ה-build בפרויקט. אפשר להגדיר לכל מודול בקובץ build.gradle ברמת המודול, באופן הבא:

android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}
android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}

אפשר גם לציין את הגדרת ברירת המחדל לתכונות האלה בכל המודולים בפרויקט, על ידי הכללת אחד או יותר מהמאפיינים הבאים קובץ gradle.properties, כמו שמוצג בהמשך. כדאי לזכור שעדיין אפשר להשתמש בלוק buildFeatures בקובץ build.gradle ברמת המודול כדי לעקוף אותם הגדרות ברירת המחדל ברמת הפרויקט.

android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true

יחסי תלות בין תכונות

בגרסאות הקודמות של הפלאגין Android Gradle, כל המודולים של התכונות להיות תלויים רק במודול הבסיסי של האפליקציה. כשמשתמשים בפלאגין של Android Gradle 4.0.0, עכשיו ניתן לכלול מודול של תכונות שתלוי בתכונה אחרת של מודל טרנספורמר. כלומר, התכונה :video יכולה להיות תלויה התכונה :camera, שתלויה במודול הבסיסי, כמו שמוצג באיור שלמטה.

תכונה שקשורה ליחסי תלות של תכונות

מודול התכונות :video תלוי בתכונה :camera, שתלוי במודול הבסיס :app.

כלומר, כשהאפליקציה מבקשת להוריד מודול של תכונות, האפליקציה גם מורידה מודולים אחרים של תכונות שהיא תלויה בהם. אחרי יצירה מודולים של פיצ'רים עבור האפליקציה שלכם, תוכלו להצהיר על תלות בתכונה קובץ build.gradle. לדוגמה, המודול :video מצהיר על תלות :camera באופן הזה:

// In the build.gradle file of the ':video' module.
dependencies {
  // All feature modules must declare a dependency
  // on the base module.
  implementation project(':app')
  // Declares that this module also depends on the 'camera'
  // feature module.
  implementation project(':camera')
  ...
}
// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation(project(":app"))
    // Declares that this module also depends on the 'camera'
    // feature module.
    implementation(project(":camera"))
    ...
}

בנוסף, עליך להפעיל את התכונה של תלות בתכונה Android Studio (כדי לתמוך בתכונה במהלך עריכת התצורה של 'הרצה', עבור לדוגמה) על ידי לחיצה על עזרה > עורכים את אפשרויות ה-VM בהתאמה אישית מסרגל התפריטים. כולל:

-Drundebug.feature.on.feature=true

מטא-נתונים של יחסי תלות

במהלך בניית האפליקציה באמצעות הפלאגין Android Gradle מגרסה 4.0.0 ואילך, הפלאגין כוללים מטא-נתונים שמתארים את יחסי התלות האלה, אפליקציה. כשמעלים את האפליקציה, מערכת Play Console בודקת את המטא-נתונים האלה כדי לספק תוכל ליהנות מהיתרונות הבאים:

  • קבלת התראות לגבי בעיות ידועות בערכות SDK ויחסי תלות שבהם האפליקציה משתמשת
  • מקבלים משוב מעשי כדי לפתור את הבעיות האלה

הנתונים נדחסים, מוצפנים באמצעות מפתח החתימה של Google Play ומאוחסנים חסימת החתימה של אפליקציית הגרסה. עם זאת, אפשר לבדוק את המטא-נתונים בספריית הביניים המקומית שלכם בקובצי ה-build שבספרייה הבאה: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt

אם אינך רוצה לשתף את המידע הזה, יש לך אפשרות לבטל את ההסכמה על ידי הוספת בקובץ build.gradle של המודול:

android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}
android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}

ייבוא ספריות מקוריות מיחסי תלות של AAR

עכשיו אפשר לייבא ספריות C/C++ מיחסי התלות של AAR של האפליקציה. כשפועלים לפי שלבי ההגדרה כפי שמתואר בהמשך, Gradle הופכת את ספריות המקור האלו לזמינות באופן אוטומטי להשתמש בו עם מערכת ה-build החיצונית החיצונית שלכם, כמו CMake. לתשומת ליבכם: Gradle בלבד תהפוך את הספריות האלה לזמינות ל-build שלכם; עדיין צריך להגדיר בונים סקריפטים כדי להשתמש בהם.

ספריות מיוצאות בפורמט חבילה Prefab.

כל תלות יכולה לחשוף חבילת Prefab אחת לכל היותר, שמורכבת מאחת או מודולים נוספים. מודול Prefab הוא ספרייה אחת, שיכולה להיות משותפת, סטטית או לכותרת בלבד.

בדרך כלל, שם החבילה תואם לשם הארטיפקט של Maven ולשם המודול תואם לשם הספרייה, אבל לא תמיד הוא נכון. כי חשוב לדעת שם החבילה והמודול של הספריות, ייתכן שתצטרכו לעיין של יחסי התלות כדי לקבוע מהם השמות האלה.

הגדרת מערכת ה-build המקורית החיצונית

כדי לראות את השלבים שצריך לבצע, יש לפעול לפי השלבים הבאים לגבי מערכת ה-build המקורית החיצונית שבהם אתם מתכוונים להשתמש.

כל אחד מיחסי התלות של AAR של האפליקציה שכולל קוד נייטיב חושף קובץ Android.mk שצריך לייבא לפרויקט ndk-build. אתם מייבאים בקובץ הזה באמצעות הפקודה import&endash;module, שמחפשת את הנתיבים לציין באמצעות המאפיין import&endash;add&endash;path בפרויקט ndk-build. עבור לדוגמה, אם האפליקציה מגדירה את libapp.so והיא משתמשת ב-curl, לכלול את הפרטים הבאים בקובץ Android.mk:

  1. ל-CMake:

    add_library(app SHARED app.cpp)

    # Add these two lines. find_package(curl REQUIRED CONFIG) target_link_libraries(app curl::curl)

  2. עבור ndk-build:

    include $(CLEAR_VARS)
    LOCAL_MODULE := libapp
    LOCAL_SRC_FILES := app.cpp
    # Link libcurl from the curl AAR.
    LOCAL_SHARED_LIBRARIES := curl
    include $(BUILD_SHARED_LIBRARY)

    # If you don't expect that your project will be built using versions of the NDK # older than r21, you can omit this block. ifneq ($(call ndk-major-at-least,21),true) $(call import-add-path,$(NDK_GRADLE_INJECTED_IMPORT_PATH)) endif

    # Import all modules that are included in the curl AAR. $(call import-module,prefab/curl)

יחסי תלות מקומיים שכלולים ב-AAR נחשפים לפרויקט CMake באמצעות משתנה CMake_FIND_ROOT_PATH{: .external}. הערך הזה יוגדר באופן אוטומטי על ידי Gradle כאשר ה-CMake מופעל, לכן אם מערכת ה-build שלך משנה את המשתנה הזה, חשוב להוסיף במקום להקצות לו.

כל תלות חושפת חבילת קובצי config{: .external} ל-build של ה-CMake, שאותו לייבא באמצעות הפקודה find_package{: .external}. הפקודה הזו מחפשת קובץ config חבילות שתואמות לשם ולגרסה הנתונים של החבילה, וחושף את היעדים שאליהם היא שייכת שמגדירות לשימוש ב-build שלכם. לדוגמה, אם האפליקציה שלך מגדירה libapp.so והוא משתמש ב-curl, עליך לכלול את הדברים הבאים קובץ CMakeLists.txt:


add_library(app SHARED app.cpp)

# Add these two lines. find_package(curl REQUIRED CONFIG) target_link_libraries(app curl::curl)

עכשיו אפשר לציין #include "curl/curl.h" ב-app.cpp. כשיוצרים את הפרויקט, מערכת ה-build המקורית החיצונית מקשרת באופן אוטומטי את libapp.so מול libcurl.so וחבילות libcurl.so ב-APK או ב-App Bundle. עבור מידע נוסף זמין בדגימה טעונה של curl{:.external}.

שינויים בהתנהגות

כשמשתמשים בגרסה הזו של הפלאגין, יכול להיות שיתרחשו השינויים הבאים: בהתנהגות.

עדכונים לגבי ההגדרות האישיות של חתימת גרסה 1/v2

ההתנהגות של ההגדרות האישיות של חתימת אפליקציות בבלוק signingConfig כוללת השתנה לערך הבא:

חתימה בגרסה 1

  • אם המדיניות v1SigningEnabled מופעלת באופן מפורש, AGP מבצעת חתימת אפליקציה בגרסה 1.
  • אם המשתמש השבית את v1SigningEnabled באופן מפורש, חתימת אפליקציה בגרסה 1 היא לא בוצע.
  • אם המשתמש לא הפעיל חתימה v1 באופן מפורש, ייתכן שהיא תופעל באופן אוטומטי מושבת על סמך minSdk ו-targetSdk.

חתימת גרסה 2

  • אם המדיניות v2SigningEnabled מופעלת באופן מפורש, AGP מבצעת חתימת אפליקציה בגרסה 2.
  • אם המשתמש השבית את v2SigningEnabled באופן מפורש, חתימת אפליקציה בגרסה 2 מושבתת לא בוצע.
  • אם המשתמש לא הפעיל באופן מפורש את חתימת V2, ייתכן שהיא תופעל באופן אוטומטי הושבת על סמך targetSdk.

השינויים האלה יאפשרו ל-AGP לבצע אופטימיזציה של גרסאות build על ידי השבתת מנגנון החתימה על סמך אם המשתמש הפעיל באופן מפורש את הדגלים האלה. לפני כן ניתן היה להשבית את v1Signing, גם אם באופן מפורש מה שעלול להיות מבלבל.

הוסרו יישומי הפלאגין feature ו-instantapp של Android Gradle

הפלאגין Android Gradle 3.6.0 הוצא משימוש את פלאגין התכונות (com.android.feature) והפלאגין של האפליקציה ללא התקנה (com.android.instantapp) ב- מעדיפים להשתמש בפלאגין של תכונה דינמית (com.android.dynamic-feature) כדי ליצור ולאסוף אפליקציות ללא התקנה באמצעות קובצי Android App Bundle.

בפלאגין Android Gradle מגרסה 4.0.0 ואילך, יישומי הפלאגין שהוצאו משימוש הם הוסרה לחלוטין. לכן, כדי להשתמש בפלאגין העדכני של Android Gradle, צריך להעביר האפליקציה ללא התקנה כדי לתמוך באפליקציה ל-Android חבילות. העברת האפליקציות ללא התקנה תאפשר לך לנצל את היתרונות של האפליקציה מקבצים והופכים את המודלים המודולריים של האפליקציה לפשוטים יותר עיצוב.

הערה: כדי לפתוח פרויקטים שמשתמשים ביישומי הפלאגין שהוסרו ב ב-Android Studio מגרסה 4.0 ואילך, צריך להשתמש בפרויקט בפלאגין של Android Gradle 3.6.0 ומטה.

הוסרה התכונה הנפרדת לעיבוד הערות

היכולת להפריד את עיבוד ההערות למשימה ייעודית הוסר. האפשרות הזאת שימשה כדי לשמור הידור מצטבר של Java כאשר מעבדי הערות לא-מצטברים משמש בפרויקטים שפועלים ב-Java בלבד. היא הופעלה באמצעות הגדרה android.enableSeparateAnnotationProcessing עד true ב- קובץ gradle.properties, שכבר לא פועל.

במקום זאת, כדאי לעבור לשימוש בהערות מצטברות מעבדים כדי לשפר את הביצועים, של ביצועי ה-build.

IncludeCompileClasspath הוצא משימוש

הפלאגין Android Gradle לא מחפש יותר מעבדי הערות ולא כולל אותו שמצהירים עליהן בנתיב הכיתה להדר, נכס DSL אחד (annotationProcessorOptions.includeCompileClasspath) כבר לא כולל כל השפעה שהיא. אם תכללו מעבדי הערות בנתיב הכיתה להדר, עשוי לקבל את השגיאה הבאה:

Error: Annotation processors must be explicitly declared now.

כדי לפתור את הבעיה, צריך לכלול מעבדי הערות בחשבון build.gradle קבצים משתמשים בתצורת התלות annotationProcessor. מידע נוסף זמין במאמר הוספת הערה מעבדים.

אריזה אוטומטית של יחסי תלות מוכנים מראש בשימוש על ידי CMake

בגרסאות קודמות של הפלאגין Android Gradle, עליך לציין במפורש לארוז את כל הספריות המובְנות מראש ששימשו את ה-build המקורי החיצוני של CMake באמצעות jniLibs. יכול להיות שיש לך ספריות ספריית src/main/jniLibs של המודול שלך, אולי בחלק מהמקרים ספרייה אחרת שהוגדרה בקובץ build.gradle:

sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.srcDirs = ['libs']
  }
}
sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.setSrcDirs(listOf("libs"))
  }
}

בפלאגין Android Gradle 4.0, אין יותר צורך בהגדרה שלמעלה ויוביל לכשל ב-build:

* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
  > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
    > More than one file was found with OS independent path 'lib/x86/libprebuilt.so'

build מקורי חיצוני נארז עכשיו באופן אוטומטי לכן לארוז את הספרייה באופן מפורש באמצעות jniLibs, משוכפל. כדי להימנע משגיאת ה-build, צריך להעביר את הספרייה שהוגדרה מראש למיקום מחוץ לדומיין jniLibs, או להסיר את ההגדרה של jniLibs ממכשיר build.gradle חדש.

בעיות מוכרות

בקטע הזה מתוארות בעיות ידועות הקיימות בפלאגין Android Gradle גרסה 4.0.0.

תנאי מרוץ במנגנון worker של Gradle

שינויים בפלאגין Android Gradle בגרסה 4.0 יכולים להפעיל מרוץ תהליכים ב-Gradle כשעובדים עם &endash;&endash;no&endash;daemon וגרסאות של Gradle מגרסה 6.3 ומטה, שנתקע אחרי שה-build מסתיים.

הבעיה הזו תיפתר ב-Gradle 6.4.