סקירה כללית של העברת פיצ'רים ב-Play

מודל אספקת האפליקציות של Google Play משתמש ב-Android App Bundles כדי ליצור ולספק קובצי APK שעברו אופטימיזציה לכל תצורת מכשיר של משתמש, כך שהמשתמשים מורידים רק את הקוד והמשאבים שהם צריכים כדי להפעיל את האפליקציה.

‫הפצת פיצ'רים ב-Play משתמשת ביכולות מתקדמות של קובצי AAB, ומאפשרת להעביר תכונות מסוימות של האפליקציה באופן מותנה או להוריד אותן על פי דרישה. כדי לעשות את זה, קודם צריך להפריד את התכונות האלה מאפליקציית הבסיס למודולים של תכונות.

הגדרת build של מודול של תכונות

כשיוצרים מודול של תכונות חדש באמצעות Android Studio, סביבת הפיתוח המשולבת (IDE) מחילה את פלאגין Gradle הבא על הקובץ build.gradle של המודול.

// The following applies the dynamic-feature plugin to your feature module.
// The plugin includes the Gradle tasks and properties required to configure and build
// an app bundle that includes your feature module.

plugins {
  id 'com.android.dynamic-feature'
}

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

מה לא לכלול בהגדרת ה-build של מודול התכונות

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

• הגדרות חתימה: חתימה על חבילות של אפליקציות מתבצעת באמצעות הגדרות חתימה שאתם מציינים במודול הבסיס.
• המאפיין minifyEnabled: אפשר להפעיל את כיווץ הקוד לכל פרויקט האפליקציה רק מתוך הגדרות ה-build של מודול הבסיס. לכן, צריך להשמיט את המאפיין הזה ממודולים של תכונות. עם זאת, אפשר לציין כללי ProGuard נוספים לכל מודול של תכונות.
• versionCode ו-versionName: כשיוצרים קובץ AAB, מערכת Gradle משתמשת בפרטי גרסת האפליקציה שמסופקים על ידי מודול הבסיס. צריך להשמיט את המאפיינים האלה מקובץ build.gradle של מודול התכונות.

יצירת קשר עם מודול הבסיס

כש-Android Studio יוצר מודול של תכונות, הוא מוסיף את המאפיין android.dynamicFeatures לקובץ build.gradle של מודול בסיסי, וכך הופך את מודול של תכונות לגלוי למודול בסיסי, כמו שמוצג בהמשך:

// In the base module’s build.gradle file.
android {
    ...
    // Specifies feature modules that have a dependency on
    // this base module.
    dynamicFeatures = [":dynamic_feature", ":dynamic_feature2"]
}

בנוסף, Android Studio כולל את מודול הבסיס כתלות של מודול התכונות, כפי שמוצג בהמשך:

// In the feature module’s build.gradle file:
...
dependencies {
    ...
    // Declares a dependency on the base module, ':app'.
    implementation project(':app')
}

ציון כללי ProGuard נוספים

למרות שרק בתצורת build של מודול הבסיס מופעלת האפשרות לכיווץ קוד בפרויקט האפליקציה, אפשר לספק כללי ProGuard מותאמים אישית לכל מודול של תכונות באמצעות המאפיין proguardFiles, כמו שמוצג בהמשך.

android.buildTypes {
     release {
         // You must use the following property to specify additional ProGuard
         // rules for feature modules.
         proguardFiles 'proguard-rules-dynamic-features.pro'
     }
}

הערה: כללי ProGuard האלה משולבים עם כללים ממודולים אחרים (כולל מודול בסיסי) משך זמן של תהליך build. לכן, למרות שכל מודול תכונות עשוי לציין קבוצה חדשה של כללים, הכללים האלה חלים על כל המודולים בפרויקט האפליקציה.

פריסת האפליקציה

במהלך פיתוח האפליקציה עם תמיכה במודולים של תכונות, אפשר לפרוס את האפליקציה למכשיר מחובר כמו שפורסים בדרך כלל, על ידי בחירה באפשרות Run > Run מסרגל התפריטים (או על ידי לחיצה על Run בסרגל הכלים).

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

1. בסרגל התפריטים, בוחרים באפשרות Run > Edit Configurations (הפעלה > עריכת הגדרות).
2. בחלונית הימנית של תיבת הדו-שיח Run/Debug Configurations (הגדרות הרצה/ניפוי באגים), בוחרים את ההגדרה הרצויה של Android App (אפליקציית Android).
3. בכרטיסייה כללי, בקטע תכונות דינמיות להטמעה, מסמנים את התיבה לצד כל מודול של תכונות שרוצים לכלול כשמטמיעים את האפליקציה.
4. לוחצים על אישור.

כברירת מחדל, Android Studio לא פורס את האפליקציה באמצעות קובצי App Bundle. במקום זאת, סביבת הפיתוח המשולבת (IDE) יוצרת ומתקינה במכשיר קובצי APK שעברו אופטימיזציה למהירות פריסה, ולא לגודל ה-APK. כדי להגדיר את Android Studio כך שיבצע build ויפרוס קובצי APK וחוויות מיידיות מקובץ AAB, צריך לשנות את הגדרות ההרצה או הניפוי באגים.

שימוש במודולים של פיצ'רים להפצה מותאמת אישית

יתרון ייחודי של מודולי תכונות הוא היכולת להתאים אישית את האופן והזמן שבהם תכונות שונות של האפליקציה מורידות למכשירים עם Android 5.0 (רמת API‏ 21) ומעלה. לדוגמה, כדי לצמצם את גודל ההורדה הראשוני של האפליקציה, אפשר להגדיר פיצ'רים מסוימים כך שההורדה שלהם תהיה על פי דרישה, או רק במכשירים שתומכים ביכולות מסוימות, כמו היכולת לצלם תמונות או תמיכה בתכונות של מציאות רבודה.

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

נניח שיש לכם אפליקציה שמאפשרת למשתמשים לקנות ולמכור מוצרים בזירת מסחר אונליין. אפשר להפוך כל אחת מהפונקציות הבאות של האפליקציה למודול תכונות נפרד:

• התחברות לחשבון ויצירת חשבון
• עיון ב-Marketplace
• העלאת פריט למכירה
• עיבוד תשלומים

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

אפשרות משלוח	התנהגות	תרחיש שימוש לדוגמה	תחילת העבודה
העברה בזמן ההתקנה	מודולים של תכונות שלא מגדירים אף אחת מאפשרויות המסירה שמתוארות למעלה מורידים כברירת מחדל בזמן התקנת האפליקציה. התנהגות כזו חשובה כי היא מאפשרת לכם לאמץ אפשרויות מתקדמות של משלוח בהדרגה. לדוגמה, אפשר להפיק תועלת מהפיכת התכונות של האפליקציה למודולריות ולהפעיל הפצה על פי דרישה רק אחרי שמטמיעים באופן מלא הורדות על פי דרישה באמצעות ספריית הפצת פיצ'רים ב-Play. בנוסף, האפליקציה יכולה לבקש להסיר תכונות בשלב מאוחר יותר. לכן, אם אתם צריכים תכונות מסוימות בזמן התקנת האפליקציה, אבל לא אחרי זה, אתם יכולים לצמצם את גודל ההתקנה על ידי בקשה להסיר את התכונה מהמכשיר.	אם באפליקציה יש פעילויות הדרכה מסוימות, כמו מדריך אינטראקטיבי לקנייה ולמכירה של פריטים בשוק, אפשר לכלול את התכונה הזו כברירת מחדל בהתקנת האפליקציה. עם זאת, כדי להקטין את גודל האפליקציה אחרי ההתקנה, האפליקציה יכולה לבקש למחוק את התכונה אחרי שהמשתמש סיים את ההדרכה.	הפיכת האפליקציה למודולרית באמצעות מודולים של תכונות שלא מוגדרות להם אפשרויות מתקדמות של מסירה. כדי ללמוד איך להקטין את נפח האפליקציה המותקנת על ידי הסרת מודולים מסוימים של תכונות שהמשתמש כבר לא צריך, אפשר לקרוא את המאמר בנושא ניהול מודולים מותקנים.
משלוח על פי דרישה	ההרשאה מאפשרת לאפליקציה לבקש ולהוריד מודולים של תכונות לפי הצורך.	אם רק 20% מהמשתמשים באפליקציית השוק מפרסמים פריטים למכירה, כדאי להפוך את הפונקציונליות של צילום תמונות, כולל תיאור הפריט ופרסום הפריט למכירה, לזמינה להורדה לפי דרישה. כך תוכלו לצמצם את גודל ההורדה הראשוני עבור רוב המשתמשים. כלומר, אתם יכולים להגדיר שמודול התכונות של פונקציית המכירה באפליקציה יורד רק כשמשתמש מביע עניין בהעלאת פריטים למכירה ב-Marketplace. בנוסף, אם המשתמש לא מוכר יותר פריטים אחרי תקופה מסוימת, האפליקציה יכולה להקטין את הגודל שלה במכשיר על ידי בקשה להסיר את התכונה.	יוצרים מודול של תכונות ומגדירים העברה לפי דרישה. לאחר מכן, האפליקציה יכולה להשתמש בספריית הפצת פיצ'רים ב-Play כדי לבקש להוריד את המודול לפי דרישה.
הצגה מותנית	מאפשר להגדיר דרישות מסוימות ממכשיר המשתמש, כמו תכונות חומרה, אזור ושפה ורמת API מינימלית, כדי לקבוע אם תכונה מודולרית תורד בזמן התקנת האפליקציה.	אם לאפליקציית השוק יש פוטנציאל להגיע לקהל גלובלי, יכול להיות שתצטרכו לתמוך באמצעי תשלום שפופולריים רק באזורים מסוימים או בקרב קהלים מקומיים. כדי לצמצם את גודל ההורדה הראשוני של האפליקציה, אפשר ליצור מודולים נפרדים של תכונות לעיבוד סוגים מסוימים של אמצעי תשלום, ולהגדיר שהם יותקנו באופן מותנה במכשיר של המשתמש בהתאם ללוקאל הרשום שלו.	יוצרים מודול של תכונות ומגדירים הצגה מותנית.
משלוח מיידי	Google Play ללא התקנה מאפשר למשתמשים ליצור אינטראקציה עם האפליקציה שלכם בלי להתקין אותה במכשיר. במקום זאת, הם יכולים להתנסות באפליקציה באמצעות הלחצן 'אפשר לנסות עכשיו' בחנות Google Play או באמצעות כתובת URL שאתם יוצרים. הדרך הזו להצגת תוכן מקלה עליכם להגביר את המעורבות באפליקציה. בעזרת מסירה מיידית, אתם יכולים להשתמש ב-Google Play ללא התקנה כדי לאפשר למשתמשים ליהנות באופן מיידי מתכונות מסוימות באפליקציה שלכם בלי להתקין אותה.	אפשר לשקול לכלול משחק שכולל את כמה הרמות הראשונות של המשחק במודול של תכונות קל משקל. אפשר להפעיל את המודול באופן מיידי כדי שהמשתמשים יוכלו לנסות את המשחק באופן מיידי באמצעות קישור לכתובת URL או לחצן 'לניסיון', בלי להתקין את האפליקציה.	יוצרים מודול של תכונות ומגדירים הפצה מיידית. לאחר מכן, האפליקציה יכולה להשתמש בספריית הפצת פיצ'רים ב-Play כדי לבקש להוריד את המודול לפי דרישה. חשוב לזכור: חלוקת התכונות של האפליקציה למודולים היא רק הצעד הראשון. כדי לתמוך ב-Google Play ללא התקנה, גודל ההורדה של מודול הבסיסי של האפליקציה ושל תכונה מסוימת בגרסה ללא התקנה צריך לעמוד במגבלות גודל מחמירות. מידע נוסף זמין במאמר איך מקטינים את הגודל של אפליקציה או משחק כדי לאפשר חוויה מיידית.

יצירת URI למשאב

אם רוצים לגשת למשאב שמאוחסן במודול של תכונות באמצעות URI, כך יוצרים URI של משאב במודול של תכונות באמצעות Uri.Builder():

Kotlin

val uri = Uri.Builder()
                .scheme(ContentResolver.SCHEME_ANDROID_RESOURCE)
                .authority(context.getPackageName()) // Look up the resources in the application with its splits loaded
                .appendPath(resources.getResourceTypeName(resId))
                .appendPath(String.format("%s:%s",
                  resources.getResourcePackageName(resId), // Look up the dynamic resource in the split namespace.
                  resources.getResourceEntryName(resId)
                  ))
                .build()

Java

String uri = Uri.Builder()
                .scheme(ContentResolver.SCHEME_ANDROID_RESOURCE)
                .authority(context.getPackageName()) // Look up the resources in the application with its splits loaded
                .appendPath(resources.getResourceTypeName(resId))
                .appendPath(String.format("%s:%s",
                  resources.getResourcePackageName(resId), // Look up the dynamic resource in the split namespace.
                  resources.getResourceEntryName(resId)
                  ))
                .build().toString();

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

כדוגמה לאופן שבו נוצר ה-URI, נניח שיש לכם אפליקציה ומודולים של תכונות עם השמות הבאים:

• שם חבילת האפליקציות: com.example.my_app_package
• שם חבילת המשאבים של התכונה: com.example.my_app_package.my_dynamic_feature

אם resId בקטע הקוד שלמעלה מתייחס למשאב קובץ גולמי בשם my_video במודול של תכונות, אז הקוד Uri.Builder() שלמעלה יפיק את הפלט הבא:

android.resource://com.example.my_app_package/raw/com.example.my_app_package.my_dynamic_feature:my_video

אחרי כן, האפליקציה יכולה להשתמש ב-URI הזה כדי לגשת למשאב של מודול התכונה.

כדי לאמת את הנתיבים ב-URI, אפשר להשתמש בהכלי לניתוח APK כדי לבדוק את קובץ ה-APK של מודול של תכונות ולקבוע את שם החבילה:

איור 1. אפשר להשתמש בכלי לניתוח APK כדי לבדוק את שם החבילה בקובץ משאבים שעבר קומפילציה.

שיקולים לגבי מודולים של תכונות

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

• התקנה של 50 מודולים של תכונות או יותר במכשיר יחיד, באמצעות מסירה מותנית או לפי דרישה, עלולה לגרום לבעיות בביצועים. מודולים שמותקנים בזמן ההתקנה ולא מוגדרים כמודולים שאפשר להסיר, נכללים אוטומטית במודול הבסיסי ונספרים רק כמודול של תכונות אחד בכל מכשיר.
• מומלץ להגביל את מספר המודולים שמוגדרים כניתנים להסרה לאספקה בזמן ההתקנה ל-10 או פחות. אחרת, יכול להיות שזמן ההורדה וההתקנה של האפליקציה יתארך.
• רק מכשירים עם Android בגרסה 5.0 (רמת API‏ 21) ומעלה תומכים בהורדה ובהתקנה של תכונות לפי דרישה. כדי שהתכונה תהיה זמינה בגרסאות קודמות של Android, צריך להפעיל את האיחוד כשיוצרים מודול של תכונות.
• מפעילים את SplitCompat, כדי שהאפליקציה תוכל לגשת למודולים של תכונות שהורדו ומסופקים על פי דרישה.
• במודולים של תכונות לא צריך לציין פעילויות במניפסט עם הערך android:exported שמוגדר ל-true. הסיבה לכך היא שאין ערובה לכך שמודול של תכונות הורד למכשיר כשניסינו להפעיל את ה-Activity מאפליקציה אחרת. בנוסף, האפליקציה צריכה לוודא שתכונה מסוימת הורדה לפני שהיא מנסה לגשת לקוד ולמשאבים שלה. מידע נוסף מופיע במאמר בנושא ניהול מודולים מותקנים.
• מכיוון שהפצת פיצ'רים ב-Play מחייבת אתכם לפרסם את האפליקציה באמצעות קובץ AAB, חשוב שתכירו את הבעיות הידועות שקשורות לקובצי AAB.

מסמך עזר בנושא מניפסט של מודול של תכונות

כשיוצרים מודול של תכונות חדש באמצעות Android Studio, סביבת הפיתוח המשולבת (IDE) כוללת את רוב מאפייני המניפסט שהמודול צריך כדי להתנהג כמו מודול של תכונות. בנוסף, חלק מהמאפיינים מוזרקים על ידי מערכת הבנייה בזמן ההידור, כך שלא צריך לציין או לשנות אותם בעצמכם. בטבלה הבאה מתוארים מאפייני המניפסט שחשובים למודולים של תכונות.

מאפיין	תיאור
<manifest	זוהי אבן בניין <manifest> טיפוסית.
xmlns:dist="http://schemas.android.com/apk/distribution"	מציין dist: מרחב שמות חדש ב-XML שמתואר בהמשך.
split="split_name"	כש-Android Studio יוצר את קובץ ה-AAB, הוא כולל את המאפיין הזה בשבילכם. לכן, אין לכלול את המאפיין הזה או לשנות אותו בעצמכם. המאפיין הזה מגדיר את שם המודול, שהאפליקציה מציינת כשמבקשים מודול על פי דרישה באמצעות ספריית הפצת הפיצ'רים ב-Play. איך Gradle קובע את הערך של המאפיין הזה: כברירת מחדל, כשיוצרים מודול של תכונות באמצעות Android Studio, סביבת הפיתוח המשולבת (IDE) משתמשת במה שמציינים כשם המודול כדי לזהות את המודול כפרויקט משנה של Gradle ב קובץ ההגדרות של Gradle. כשיוצרים את קובץ ה-AAB, מערכת Gradle משתמשת ברכיב האחרון של נתיב הפרויקט המשני כדי להוסיף את מאפיין המניפסט הזה למניפסט של המודול. לדוגמה, אם יוצרים מודול של תכונות חדש בספרייה MyAppProject/features/ ומציינים את השם dynamic_feature1 כשם המודול, סביבת הפיתוח המשולבת מוסיפה את ':features:dynamic_feature1' כפרויקט משנה בקובץ settings.gradle. כשיוצרים את קובץ ה-AAB של האפליקציה, Gradle מוסיף את <manifest split="dynamic_feature1"> למניפסט של המודול.
android:isFeatureSplit="true | false">	כש-Android Studio יוצר את קובץ ה-AAB של האפליקציה, הוא כולל את המאפיין הזה בשבילכם. לכן, לא כדאי לכלול את המאפיין הזה או לשנות אותו באופן ידני. מציין שהמודול הזה הוא מודול של תכונות. במניפסטים במודול הבסיסי ובקובצי ה-APK של ההגדרות, המאפיין הזה מושמט או מוגדר כ-false.
<dist:module	המאפיינים האלה קובעים איך המודול נארז ומופץ כקובצי APK.
‫dist:instant="true | false"	המדיניות הזו קובעת אם המודול צריך להיות זמין דרך Google Play ללא התקנה כחוויית שימוש מיידי. אם האפליקציה כוללת מודול תכונות אחד או יותר שמופעלים כאפליקציה ללא התקנה, צריך להפעיל כאפליקציה ללא התקנה גם את מודול הבסיס. כשמשתמשים ב-Android Studio בגרסה 3.5 ואילך, סביבת הפיתוח המשולבת (IDE) עושה את זה בשבילכם כשיוצרים מודול של תכונות בגרסה ללא התקנה. אי אפשר להגדיר את רכיב ה-XML הזה ל-true וגם להגדיר את <dist:on-demand/>. עם זאת, עדיין אפשר לבקש הורדות על פי דרישה של מודולים של תכונות של גרסה ללא התקנה כחוויות שימוש מיידי באמצעות ספריית הפצת פיצ'רים ב-Play. כשמשתמש מוריד את האפליקציה שלכם ומתקין אותה, המכשיר מוריד ומתקין את מודולי התכונות של האפליקציה בגרסה ללא התקנה, יחד עם קובץ ה-APK הבסיסי, כברירת מחדל.
dist:title="@string/feature_name">	מציינת כותרת של המודול שמוצגת למשתמשים. לדוגמה, יכול להיות שהשם הזה יוצג במכשיר כשמבקשים אישור להורדה. צריך לכלול את משאב המחרוזת של הכותרת הזו בקובץ module_root/src/source_set/res/values/strings.xml של מודול הבסיס.
<dist:fusing dist:include="true | false" />	ההגדרה קובעת אם לכלול את המודול בקובצי APK מרובים שמיועדים למכשירים עם Android מגרסה 4.4 (רמת API 20) ומטה. בנוסף, כשמשתמשים ב- bundletool כדי ליצור קובצי APK מ-קובץ AAB, רק מודולים של תכונות שבהם המאפיין הזה מוגדר ל-true נכללים ב-APK האוניברסלי – שהוא APK מונוליטי שכולל קוד ומשאבים לכל תצורות המכשירים שהאפליקציה תומכת בהן.
<dist:delivery>	האפשרות הזו כוללת הגדרות להתאמה אישית של משלוח מודולים, כמו שמוצג בהמשך. חשוב לזכור שכל מודול תכונות צריך להגדיר רק סוג אחד של אפשרויות משלוח מותאמות אישית.
<dist:install-time>	המדיניות הזו מציינת שהמודול צריך להיות זמין בזמן ההתקנה. זהו אופן הפעולה שמוגדר כברירת מחדל למודולים של תכונות שלא מציינים סוג אחר של אפשרות הצגה מותאמת אישית. מידע נוסף על הורדות בזמן ההתקנה זמין במאמר בנושא הגדרת מסירה בזמן ההתקנה. בצומת הזה אפשר גם לציין תנאים שמגבילים את המודול למכשירים שעומדים בדרישות מסוימות, כמו תכונות המכשיר, המדינה של המשתמש או רמת ה-API המינימלית. מידע נוסף על הגדרת משלוח מותנה
<dist:removable dist:value="true | false" />	אם לא מגדירים את האפשרות הזו או מגדירים אותה לערך false, ‏ bundletool ימזג מודולים של זמן ההתקנה למודול הבסיסי כשיוצר חבילות APK מפוצלות מהחבילה. כתוצאה מהמיזוג יהיו פחות קובצי APK מפוצלים, ולכן ההגדרה הזו עשויה לשפר את ביצועי האפליקציה. כשהערך של removable הוא true: מודולים של זמן ההתקנה לא ימוזגו עם המודול הבסיסי. מגדירים את הערך ל-true אם רוצים להסיר מודולים בעתיד. עם זאת, הגדרת יותר מדי מודולים כניתנים להסרה עלולה להאריך את זמן ההתקנה של האפליקציה. ברירת המחדל היא false. צריך להגדיר את הערך הזה במניפסט רק אם רוצים להשבית את המיזוג של מודול של תכונות. הערה: התכונה הזו זמינה רק כשמשתמשים בפלאגין של Android Gradle מגרסה 4.2 ואילך, או כשמשתמשים בכלי Bundletool מגרסה 1.0 ואילך משורת הפקודה.
</dist:install-time>
<dist:on-demand />	המדיניות הזו מציינת שהמודול צריך להיות זמין להורדה על פי דרישה. כלומר, המודול לא זמין בזמן ההתקנה, אבל יכול להיות שהאפליקציה תבקש להוריד אותו בהמשך. מידע נוסף על הורדות על פי דרישה זמין במאמר בנושא הגדרת משלוח על פי דרישה.
</dist:delivery>
</dist:module>
<application android:hasCode="true | false"> ... </application>	אם מודול של תכונות לא יוצר קובצי DEX – כלומר, הוא לא מכיל קוד שמקומפל בהמשך לפורמט קובץ DEX – צריך לבצע את הפעולות הבאות (אחרת, יכול להיות שתקבלו שגיאות בזמן הריצה): מגדירים את android:hasCode לערך "false" במניפסט של מודול התכונות. מוסיפים את השורות הבאות למניפסט של מודול הבסיס: <application android:hasCode="true" tools:replace="android:hasCode"> ... </application>
... </manifest>

הערה: במודולים של תכונות לא צריך לציין פעילויות במניפסט עם הערך true של android:exported. הסיבה לכך היא שאין ערובה לכך שמודול של תכונות הורד למכשיר כשניסינו להפעיל את ה-Activity מאפליקציה אחרת. בנוסף, האפליקציה צריכה לוודא שתכונה מסוימת הורדה לפני שהיא מנסה לגשת לקוד ולמשאבים שלה. מידע נוסף מופיע במאמר ניהול מודולים מותקנים.

מקורות מידע נוספים

כדי לקבל מידע נוסף על השימוש במודולים של תכונות, אפשר לעיין במקורות המידע הבאים.

פוסטים בבלוגים

• תכונות חדשות שיעזרו לכם לפתח את העסק, להשיק אותו ולהרחיב אותו ב-Google Play
• העדכונים האחרונים של קובץ Android App Bundle, כולל API של שפות נוספות
• Patchwork Plaid — A modularization story

סרטונים

• התאמה אישית של תהליך המסירה באמצעות App Bundle ושיתוף קל של גרסאות build לבדיקה
• כלים חדשים לאופטימיזציה של גודל האפליקציה ולהגדלת מספר ההתקנות ב-Google Play

תנאים והגבלות ואבטחת נתונים

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

אבטחת נתונים

ספריות Play Core הן ממשק זמן הריצה של האפליקציה עם חנות Google Play. לכן, כשמשתמשים ב-Play Core באפליקציה, חנות Play מפעילה תהליכים משלה, כולל טיפול בנתונים כפוף לתנאים ולהגבלות של Google Play. בהמשך מוסבר איך ספריות Play Core מטפלות בנתונים כדי לעבד בקשות ספציפיות מהאפליקציה.

Additional languages API

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

הפצת פיצ'רים ב-Play

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

המטרה שלנו היא להתנהל בשקיפות רבה ככל האפשר. עם זאת, רק אתם אחראים להחליט איך לענות על השאלות בטופס של סעיף אבטחת הנתונים של Google Play בנוגע לאיסוף נתוני משתמשים, לשיתוף שלהם ולשיטות האבטחה של האפליקציה.