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

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

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

הגדרת 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 של מודול התכונות:

• הגדרות חתימה: קובצי App Bundle נחתמים באמצעות חתימה שתציינו במודול הבסיסי.
• הנכס minifyEnabled: אפשר הפעלה של כיווץ קוד לכל פרויקט האפליקציה מה-build של המודול הבסיסי בלבד הגדרה אישית. לכן, יש להשמיט את המאפיין הזה של הפיצ'רים האלה. אבל אפשר ציון כללים נוספים של ProGuard לכל מודול של תכונה.
• versionCode ו-versionName: כשיוצרים את ה-App Bundle, 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. כך שלמרות שכל תכונה לציין קבוצה חדשה של כללים, הכללים האלה יחולו על כל המודולים פרויקט של אפליקציה.

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

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

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

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

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

שימוש במודולים של תכונות להעברה מותאמת אישית

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

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

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

• התחברות לחשבון ויצירה שלו
• גלישה בזירת המסחר
• הצבת פריט למכירה
• עיבוד תשלומים

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

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

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

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

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

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

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

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

מאפיין	תיאור
<manifest ...	זה האופציה הרגילה שלך <manifest>.
xmlns:dist="http://schemas.android.com/apk/distribution"	מציינת מרחב שמות חדש של XML מסוג dist: שעומד בדרישות שמתואר בהמשך.
split="split_name"	כשמערכת Android Studio יוצרת את ה-App Bundle, הוא כולל את הפרטים האלה עבורך. לכן, לא כדאי לכלול או לשנות את המאפיין הזה בעצמכם. מגדיר את שם המודול, שאותו האפליקציה שלך מציינת כשמבקשים מודול על פי דרישה דרך ספריית הפיצ'רים של Play. איך Gradle קובעת את הערך של המאפיין הזה: כברירת מחדל, כשיוצרים מודול של תכונות באמצעות ב-Android Studio, בסביבת הפיתוח המשולבת נעשה שימוש במה שציינת שם המודול, לזיהוי המודול כפרויקט משנה של Gradle ב קובץ הגדרות של Gradle. כשבונים את ה-App Bundle, מערכת Gradle משתמשת ברכיב האחרון של בנתיב המשנה של הפרויקט, להחדיר את מאפיין המניפסט הזה . לדוגמה, אם יוצרים מודול חדש של פיצ'ר הספרייה MyAppProject/features/ וציינו ' dynamic_feature1' כשם המודול שלו, סביבת הפיתוח המשולבת (IDE) מוסיפה ':features:dynamic_feature1' כפרויקט משנה קובץ settings.gradle. כשיוצרים את ה-App Bundle, מגרדת ואז מחדירה <manifest split="dynamic_feature1"> במניפסט של המודול.
android:isFeatureSplit="true | false">	כשמערכת Android Studio יוצרת את ה-App Bundle, הוא כולל את המאפיין הזה. לכן, לא כדאי לכלול או לשנות את המאפיין הזה באופן ידני. מציין שהמודול הזה הוא מודול של מאפיינים. מניפסטים במודול הבסיסי ובחבילות ה-APK של ההגדרות צריך להשמיט את המאפיין הזה או להגדיר אותו לערך false.
<dist:module	רכיב ה-XML החדש מגדיר מאפיינים שקובעים איך המודול ארוז ומופץ כ-APK.
dist:instant="true | false"	מציינת אם המודול צריך להיות זמין דרך Google Play ללא התקנה בתור חוויה מיידית. אם האפליקציה כוללת תכונה אחת או יותר שמופעלת ללא התקנה חייבים גם להפעיל מיד את המודול הבסיסי. בזמן השימוש ב-Android Studio מגרסה 3.5 ואילך, סביבת הפיתוח המשולבת (IDE) עושה זאת עבורך ליצור גרסת התקנה מיידית פיצ'ר [feature_Module]. אי אפשר להגדיר את רכיב ה-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" /> </dist:module>	המדיניות קובעת אם לכלול את המודול בחבילות APK מרובות למכשירים שבהם פועלת Android 4.4 (רמת API 20) ומטה. כמו כן, כאשר להשתמש ב-bundletool כדי ליצור חבילות APK מ-App Bundle, לכלול רק מודולים שמגדירים את הנכס הזה ל-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 v1.0 משורת הפקודה.
</dist:install-time>
<dist:on-demand/>	מציינת שהמודול צריך להיות זמין על פי דרישה להוריד. כלומר, המודול לא זמין בזמן ההתקנה, עשויה לבקש להוריד אותה מאוחר יותר. למידע נוסף על הורדות על פי דרישה, אפשר לקרוא הגדרת הצגה על פי דרישה.
</dist:delivery>
<application android:hasCode="true | false"> ... </application>	אם המודול של התכונה לא יוצר קובצי DEX - כלומר, הוא מכיל לא קוד שאחר כך יעובד בפורמט של קובץ DEX - צריך לבצע (אחרת, עלולות להתקבל שגיאות בזמן הריצה): מגדירים את android:hasCode לערך "false" או מניפסט של מודול פיצ'ר. מוסיפים את הפרטים הבאים למניפסט של מודול ה-base: <application android:hasCode="true" tools:replace="android:hasCode"> ... </application>

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

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

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

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

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

סרטונים

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

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

גישה לספרייה להעברת תכונות של Play או שימוש בה מבטאים את הסכמתך ל התנאים וההגבלות של Play Core Software Development Kit. חשוב לקרוא ומבינים את כל התנאים וכללי המדיניות הרלוונטיים לפני הגישה לספרייה.

אבטחת נתונים

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

ממשק API לשפות נוספות

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

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

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

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