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

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

Play Feature Delivery משתמש ביכולות מתקדמות של קובצי 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: כשמפתחים את חבילת האפליקציה, 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. בסרגל התפריטים, בוחרים באפשרות הפעלה > עריכת הגדרות.
  2. בחלונית הימנית של תיבת הדו-שיח Run/Debug Configurations, בוחרים את ההגדרה הרצויה של Android App.
  3. בקטע Dynamic features to deploy (תכונות דינמיות לפריסה) בכרטיסייה General (כללי), מסמנים את התיבה לצד כל מודול תכונות שרוצים לכלול בפריסה של האפליקציה.
  4. לוחצים על אישור.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יוצרים מודול תכונה ומגדירים העברה על פי דרישה. לאחר מכן, האפליקציה יכולה להשתמש בספריית העברת התכונות של 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 Analyzer כדי לבדוק את קובץ ה-APK של מודול התכונה ולקבוע את שם החבילה:

צילום מסך של APK Analyzer בבדיקה של תוכן קובץ משאבים שנאסף.

איור 2. שימוש ב-APK Analyzer כדי לבדוק את שם החבילה בקובץ משאבים שנאסף.

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

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

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

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

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

מאפיין תיאור
<manifest
...
זהו הבלוק הטיפוסי של <manifest>.
xmlns:dist="http://schemas.android.com/apk/distribution" מציינת מרחב שמות חדש של XML בפורמט dist:, שמתואר בהמשך.
split="split_name" כש-Android Studio יוצר את חבילת האפליקציות, הוא כולל את המאפיין הזה בשבילכם. לכן, אין לכלול את המאפיין הזה או לשנות אותו בעצמכם.

מגדיר את שם המודול, שהאפליקציה מציינת כששולחת בקשה למודול על פי דרישה באמצעות ספריית Play Feature Delivery Library.

איך Gradle קובע את הערך של המאפיין הזה:

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

כשמפתחים את חבילת האפליקציות, Gradle משתמש ברכיב האחרון של נתיב פרויקט המשנה כדי להחדיר את מאפיין המניפסט הזה למניפסט של המודול. לדוגמה, אם יוצרים מודול חדש של תכונה בספרייה MyAppProject/features/ ומציינים את שם המודול שלו, סביבת הפיתוח המשולבת מוסיפה את ':features:dynamic_feature1' כפרויקט משנה בקובץ settings.gradle. כשמפתחים את חבילת האפליקציה, Gradle מזין את <manifest split="dynamic_feature1"> במניפסט של המודול.

android:isFeatureSplit="true | false"> כש-Android Studio יוצר את חבילת האפליקציות, הוא כולל את המאפיין הזה בשבילכם. לכן, אין לכלול את המאפיין הזה או לשנות אותו באופן ידני.

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

<dist:module אלמנט ה-XML החדש הזה מגדיר מאפיינים שקובעים את אופן האריזה וההפצה של המודול כקובצי APK.
dist:instant="true | false" קובע אם המודול יהיה זמין דרך Google Play ללא התקנה כחוויה מיידית.

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

לא ניתן להגדיר את רכיב ה-XML הזה כ-true תוך הגדרה של <dist:on-demand/>. עם זאת, עדיין תוכלו לבקש הורדות על פי דרישה של מודולי התכונות שהופעלה בהם התכונה 'חוויה מיידית' כחוויות מיידיות באמצעות ספריית Play Feature Delivery. כשמשתמש מוריד את האפליקציה ומתקין אותה, המכשיר מורידים ומתקינים את המודולים של התכונות שפועלות באופן מיידי באפליקציה, יחד עם קובץ ה-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 מפוצלות מה-bundle. כתוצאה מהמיזוג, יהיו פחות חבילות 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, צריך לבצע את הפעולות הבאות (אחרת, יכול להיות שיופיעו שגיאות בזמן הריצה):
  1. מגדירים את android:hasCode לערך "false" במניפסט של מודול התכונה.
  2. מוסיפים את הפרטים הבאים למניפסט של מודול ה-base:
    <application
      android:hasCode="true"
      tools:replace="android:hasCode">
      ...
    </application>

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

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

פוסטים בבלוג

סרטונים

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

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

אבטחת נתונים

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

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

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

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

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

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