מודל הצגת האפליקציות של 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. כך שלמרות שכל תכונה לציין קבוצה חדשה של כללים, הכללים האלה יחולו על כל המודולים פרויקט של אפליקציה.
פורסים את האפליקציה
בזמן פיתוח האפליקציה עם תמיכה במודולים של תכונות, אפשר
לפרוס את האפליקציה במכשיר מחובר כמו בדרך כלל על ידי בחירה של
הפעלה > מפעילים מסרגל התפריטים (או לוחצים על הפעלה בשדה
סרגל הכלים).
אם פרויקט האפליקציה כולל מודול של תכונה אחד או יותר, אפשר לבחור אילו תכונות לכלול בעת פריסת האפליקציה, על ידי שינוי את הגדרות ההרצה/ניפוי הבאגים הקיימות, ככה:
- בוחרים באפשרות הפעלה > עורכים את ההגדרות האישיות בסרגל התפריטים.
- בחלונית השמאלית של תיבת הדו-שיח Run/Debug Configuration, בוחרים באפשרות את ההגדרה הרצויה של אפליקציית Android.
- בקטע תכונות דינמיות לפריסה בכרטיסייה כללי, בודקים את לצד כל מודול של תכונה שתרצו לכלול בפריסה של האפליקציה.
- לוחצים על אישור.
כברירת מחדל, ב-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 משתמשת ברכיב האחרון של
בנתיב המשנה של הפרויקט, להחדיר את מאפיין המניפסט הזה
. לדוגמה, אם יוצרים מודול חדש של פיצ'ר
הספרייה |
android:isFeatureSplit="true | false"> |
כשמערכת Android Studio יוצרת את ה-App Bundle, הוא כולל
את המאפיין הזה. לכן, לא כדאי לכלול
או לשנות את המאפיין הזה באופן ידני.
מציין שהמודול הזה הוא מודול של מאפיינים.
מניפסטים במודול הבסיסי ובחבילות ה-APK של ההגדרות
צריך להשמיט את המאפיין הזה או להגדיר אותו לערך |
<dist:module |
רכיב ה-XML החדש מגדיר מאפיינים שקובעים איך המודול ארוז ומופץ כ-APK. |
dist:instant="true | false" |
מציינת אם המודול צריך להיות זמין דרך
Google Play ללא התקנה בתור
חוויה מיידית.
אם האפליקציה כוללת תכונה אחת או יותר שמופעלת ללא התקנה חייבים גם להפעיל מיד את המודול הבסיסי. בזמן השימוש ב-Android Studio מגרסה 3.5 ואילך, סביבת הפיתוח המשולבת (IDE) עושה זאת עבורך ליצור גרסת התקנה מיידית פיצ'ר [feature_Module]. אי אפשר להגדיר את רכיב ה-XML הזה כ- |
dist:title="@string/feature_name" |
מציינת כותרת למודול שמוצגת למשתמש. לדוגמה,
המכשיר עשוי להציג את הכותר הזה כשהוא יבקש הורדה
אישור.
צריך לכלול את משאב המחרוזת עבור הכותר הזה
במודול הבסיסי |
<dist:fusing dist:include="true | false" />
|
המדיניות קובעת אם לכלול את המודול בחבילות APK מרובות
למכשירים שבהם פועלת Android 4.4 (רמת API 20) ומטה.
כמו כן, כאשר
להשתמש ב- |
<dist:delivery> |
כוללת אפשרויות להתאמה אישית של העברת המודול, כפי שמוצג בהמשך. חשוב לזכור שבכל מודול של התכונות צריך להגדיר רק סוג אחד של נתונים את אפשרויות המשלוח המותאמות אישית האלה. |
<dist:install-time> |
מציינת שהמודול צריך להיות זמין בזמן ההתקנה. כאן
ברירת מחדל של מודולים של תכונות שלא מציינים אחרת
סוג של אפשרות הצגה מותאמת אישית.
לקבלת מידע נוסף על הורדות בזמן ההתקנה, אפשר לקרוא את הגדרת מסירה בזמן ההתקנה. הצומת הזה יכול גם לציין תנאים שמגבילים את המודול מכשירים שעומדים בדרישות מסוימות, כמו תכונות המכשיר, מדינה, או רמת API מינימלית. מידע נוסף זמין במאמר הבא: הגדרת שליחה מותנית |
<dist:removable dist:value="true | false" /> |
אם המדיניות מוגדרת לערך כאשר המדיניות ברירת המחדל היא הערה: התכונה הזו זמינה רק כשמשתמשים ב-Android Gradle יישומי פלאגין 4.2 או כאשר משתמשים ב-bundletool v1.0 משורת הפקודה. |
</dist:install-time> |
|
<dist:on-demand/> |
מציינת שהמודול צריך להיות זמין על פי דרישה
להוריד. כלומר, המודול לא זמין בזמן ההתקנה,
עשויה לבקש להוריד אותה מאוחר יותר.
למידע נוסף על הורדות על פי דרישה, אפשר לקרוא הגדרת הצגה על פי דרישה. |
</dist:delivery> |
|
<application
|
אם המודול של התכונה לא יוצר קובצי DEX - כלומר, הוא מכיל
לא קוד שאחר כך יעובד בפורמט של קובץ DEX - צריך לבצע
(אחרת, עלולות להתקבל שגיאות בזמן הריצה):
|
מקורות מידע נוספים
למידע נוסף על השימוש במודולים של תכונות, אפשר לנסות את המשאבים הבאים.
פוסטים בבלוגים
- תכונות חדשות שיעזרו לכם לפתח, לפרסם ולהרחיב את העסק שלכם ב-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 בנוגע לנוהלי האיסוף, השיתוף והאבטחה של נתוני המשתמשים באפליקציה.