מודל הצגת האפליקציות של Google Play משתמש בחבילות Android App Bundle כדי ליצור ולהציג חבילות APK שעברו אופטימיזציה בהתאם להגדרות המכשיר של כל משתמש. כך, המשתמשים מורידים רק את הקוד והמשאבים הנדרשים להפעלת האפליקציה.
התכונה Play Feature Delivery משתמשת ביכולות המתקדמות של חבילות App Bundle, ומאפשרת להעביר תכונות מסוימות של האפליקציה באופן מותנה או להוריד אותן על פי דרישה. כדי לעשות זאת, קודם צריך להפריד את התכונות האלה מהאפליקציה הבסיסית וליצור מהן מודולים של תכונות.
הגדרת build של מודול תכונות
כשיוצרים מודול תכונות חדש באמצעות Android Studio, סביבת הפיתוח המשולבת מחילה את פלאגין 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/Debug Configurations, בוחרים את ההגדרה הרצויה של Android App.
- בקטע Dynamic features to deploy (תכונות דינמיות לפריסה) בכרטיסייה General (כללי), מסמנים את התיבה לצד כל מודול תכונות שרוצים לכלול בפריסה של האפליקציה.
- לוחצים על אישור.
כברירת מחדל, Android Studio לא פורסת את האפליקציה באמצעות חבילות אפליקציות. במקום זאת, סביבת הפיתוח המשולבת יוצרת ומתקינה במכשיר חבילות APK שעברו אופטימיזציה למהירות הפריסה, ולא לגודל חבילת ה-APK. כדי להגדיר את Android Studio ליצור ולפרוס חבילות APK וחוויית שימוש מיידיות מתוך חבילת אפליקציות, משנים את הגדרת ההרצה/ניפוי הבאגים.
שימוש במודולים של פיצ'רים להפצה מותאמת אישית
יתרון ייחודי של מודולים של תכונות הוא היכולת להתאים אישית את האופן והמועד שבו תכונות שונות של האפליקציה יורדו למכשירים עם Android מגרסה 5.0 (רמת API 21) ואילך. לדוגמה, כדי לצמצם את גודל ההורדה הראשוני של האפליקציה, אפשר להגדיר פיצ'רים מסוימים כך שההורדה שלהם תהיה על פי דרישה, או רק במכשירים שתומכים ביכולות מסוימות, כמו היכולת לצלם תמונות או תמיכה בתכונות של מציאות רבודה.
כשאתם מעלים את האפליקציה כ-App Bundle, כברירת מחדל אתם מקבלים הורדות שעברו אופטימיזציה גבוהה. עם זאת, כדי להשתמש באפשרויות מתקדמות יותר של העברת תכונות שניתנות להתאמה אישית, אתם צריכים להגדיר את התכונות של האפליקציה ולבצע מודולריזציה שלהן באמצעות מודולים של תכונות. כלומר, מודולים של תכונות מספקים את אבני הבניין ליצירת תכונות מודולריות שאפשר להגדיר כל אחת מהן להורדה לפי הצורך.
כדאי לחשוב על אפליקציה שמאפשרת למשתמשים לקנות ולמכור מוצרים בזירת מסחר אונליין. אפשר לחלק כל אחת מהפונקציות הבאות של האפליקציה למודולים נפרדים של תכונות:
- התחברות לחשבון ויצירת חשבון
- עיון ב-Marketplace
- הצגת פריט למכירה
- עיבוד תשלומים
בטבלה הבאה מפורטות אפשרויות ההעברה השונות עם תמיכה במודולים, ואופן השימוש בהן כדי לבצע אופטימיזציה של גודל ההורדה הראשוני של אפליקציית זירת המסחר לדוגמה.
אפשרות משלוח | התנהגות | תרחיש לדוגמה | תחילת העבודה |
---|---|---|---|
העברה בזמן ההתקנה | מודולים של תכונות שלא מגדירים אף אחת מאפשרויות ההעברה שמתוארות למעלה, מורידים כברירת מחדל בזמן התקנת האפליקציה. זוהי התנהגות חשובה כי היא מאפשרת לכם להשתמש באפשרויות העברה מתקדמות בהדרגה. לדוגמה, תוכלו להפיק תועלת מחלוקה של התכונות של האפליקציה למודולים ולהפעיל העברה על פי דרישה רק אחרי שתטמיעו באופן מלא הורדות על פי דרישה באמצעות ספריית Play Feature Delivery.
בנוסף, האפליקציה יכולה לבקש להסיר תכונות במועד מאוחר יותר. לכן, אם אתם זקוקים לתכונות מסוימות בזמן התקנת האפליקציה, אבל לא לאחר מכן, תוכלו לבקש להסיר את התכונה מהמכשיר כדי לצמצם את גודל ההתקנה. |
אם האפליקציה כוללת פעילויות הדרכה מסוימות, כמו מדריך אינטראקטיבי בנושא קנייה ומכירה של פריטים בזירת המסחר, תוכלו לכלול את התכונה הזו כברירת מחדל בהתקנת האפליקציה.
עם זאת, כדי לצמצם את גודל האפליקציה לאחר ההתקנה, האפליקציה יכולה לבקש למחוק את התכונה אחרי שהמשתמש ישלים את האימון. |
פיתוח האפליקציה בתצורת מודול באמצעות מודולים של תכונות שלא מגדירים אפשרויות העברה מתקדמות.
במאמר ניהול המודולים המותקנים מוסבר איך להקטין את נפח האפליקציה המותקנת על ידי הסרת מודולים מסוימים של תכונות שהמשתמשים אולי כבר לא צריכים. |
מסירה על פי דרישה | מאפשרת לאפליקציה לבקש ולהוריד מודולים של תכונות לפי הצורך. | אם רק 20% מהמשתמשים באפליקציית זירת המסחר מפרסמים פריטים למכירה, אסטרטגיה טובה לצמצום גודל ההורדה הראשונית עבור רוב המשתמשים היא להפוך את הפונקציונליות של צילום תמונות, כולל תיאור הפריט והוספת פריט למכירה, לזמינה להורדה על פי דרישה. כלומר, אפשר להגדיר את מודול התכונות של פונקציית המכירה באפליקציה כך שיוריד רק כשמשתמש מראה עניין בהוספת פריטים למכירה בזירת המסחר.
בנוסף, אם המשתמש לא מוכר יותר פריטים לאחר פרק זמן מסוים, האפליקציה יכולה לבקש להסיר את התכונה כדי לצמצם את גודל ההתקנה שלה. |
יוצרים מודול תכונה ומגדירים העברה על פי דרישה. לאחר מכן, האפליקציה יכולה להשתמש בספריית העברת התכונות של Play כדי לבקש להוריד את המודול על פי דרישה. |
העברה מותנית | מאפשר לכם לציין דרישות מסוימות של מכשירי משתמשים, כמו מאפייני חומרה, מקום ותרבות וכן רמת API מינימלית, כדי לקבוע אם תכונה מודולרית תורד בזמן התקנת האפליקציה. | אם לאפליקציית זירת המסחר יש פוטנציאל גלובלי, יכול להיות שתצטרכו לתמוך באמצעי תשלום שפופולריים רק באזורים או בקהילות מסוימים. כדי לצמצם את גודל ההורדה הראשוני של האפליקציה, אפשר ליצור מודולים נפרדים של תכונות לעיבוד סוגים מסוימים של אמצעי תשלום, ולהתקין אותם באופן מותנה במכשיר של המשתמש על סמך האזור הגיאוגרפי הרשום שלו. | יוצרים מודול תכונות ומגדירים העברה מותנית. |
משלוח מיידי | Google Play ללא התקנה מאפשר למשתמשים לקיים אינטראקציה עם האפליקציה שלכם בלי צורך להתקין אותה במכשיר. במקום זאת, הם יכולים להשתמש באפליקציה באמצעות הלחצן 'לניסיון' בחנות Google Play או באמצעות כתובת URL שתיצרו. כך קל יותר להגביר את המעורבות באפליקציה.
בעזרת העברה מיידית, תוכלו להשתמש ב-Google Play Instant כדי לאפשר למשתמשים ליהנות באופן מיידי מתכונות מסוימות באפליקציה שלכם, בלי צורך בהתקנה. |
נניח משחק שכולל את כמה הרמות הראשונות של המשחק במודול תכונות קל. אפשר להפעיל את המודול הזה באופן מיידי כדי שהמשתמשים יוכלו לשחק במשחק באופן מיידי דרך קישור לכתובת URL או דרך הלחצן 'לניסיון', בלי להתקין את האפליקציה. | יוצרים מודול תכונות ומגדירים העברה מיידית. לאחר מכן, האפליקציה יכולה להשתמש בספריית העברת התכונות של Play כדי לבקש להוריד את המודול על פי דרישה.
חשוב לזכור שיצירת מודולים של תכונות האפליקציה באמצעות מודולים של תכונות היא רק השלב הראשון. כדי לתמוך ב-Google Play Instant, גודל ההורדה של המודול הבסיסי של האפליקציה ושל תכונה מסוימת שתומכת באפשרות 'פתיחה מיידית' צריך לעמוד במגבלות גודל מחמירות. מידע נוסף זמין במאמר איך מפעילים חוויות מיידיות על ידי צמצום הגודל של האפליקציה או המשחק. |
יצירת 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 של מודול התכונה ולקבוע את שם החבילה:
שיקולים לגבי מודולים של תכונות
בעזרת מודולים של תכונות, אפשר לשפר את מהירות ה-build ואת מהירות הפיתוח, ולהתאים אישית באופן נרחב את המסירה של התכונות של האפליקציה כדי לצמצם את גודל האפליקציה. עם זאת, יש כמה אילוצים ותרחישים קיצוניים שכדאי לזכור כשמשתמשים במודולים של תכונות:
- התקנה של 50 מודולים של תכונות או יותר במכשיר אחד, באמצעות העברה מותנית או העברה על פי דרישה, עלולה לגרום לבעיות בביצועים. מודולים שמתווספים בזמן ההתקנה, ולא מוגדרים כניתנים להסרה, נכללים באופן אוטומטי במודול הבסיסי ונספרים כמודול תכונה אחד בלבד בכל מכשיר.
- כדאי להגביל את מספר המודולים שתגדירו כניתנים להסרה ל-10 מודולים או פחות, לצורך העברה בזמן ההתקנה. אחרת, זמן ההורדה וההתקנה של האפליקציה עשוי להתארך.
- רק במכשירים עם Android מגרסה 5.0 (רמת API 21) ואילך יש תמיכה בהורדה ובהתקנה של תכונות על פי דרישה. כדי שהתכונה תהיה זמינה לגרסאות קודמות של Android, צריך להפעיל את המיזוג כשיוצרים מודול תכונות.
- מפעילים את SplitCompat כדי לאפליקציה תהיה גישה למודול תכונות שהורדתם ונשלח על פי דרישה.
- אסור לציין פעילויות במניפסט של מודולי תכונות עם הערך
true
ב-android:exported
. הסיבה לכך היא שאין ערובה שהמכשיר הוריד את מודול התכונה כשאפליקציה אחרת מנסה להפעיל את הפעילות. בנוסף, האפליקציה צריכה לוודא שהתכונה הורדתה לפני שהיא מנסה לגשת לקוד ולמשאבים שלה. למידע נוסף, קראו את המאמר ניהול המודולים המותקנים. - כדי להשתמש ב-Play Feature Delivery, צריך לפרסם את האפליקציה באמצעות חבילת אפליקציות. לכן חשוב לדעת על הבעיות הידועות שקשורות לחבילות האפליקציות.
מסמך עזר בנושא מניפסט של מודול תכונות
כשיוצרים מודול תכונות חדש באמצעות Android Studio, סביבת הפיתוח המשולבת (IDE) כוללת את רוב מאפייני המניפסט שנדרשים למודול כדי לפעול כמו מודול תכונות. בנוסף, מערכת ה-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 משתמש ברכיב האחרון של נתיב פרויקט המשנה כדי להחדיר את מאפיין המניפסט הזה למניפסט של המודול. לדוגמה, אם יוצרים מודול תכונה חדש בספרייה |
android:isFeatureSplit="true | false"> |
כש-Android Studio יוצר את חבילת האפליקציות, הוא כולל את המאפיין הזה בשבילכם. לכן, אין לכלול את המאפיין הזה או לשנות אותו באופן ידני.
מציין שהמודול הזה הוא מודול תכונות.
במניפסטים שבמודול הבסיסי ובחבילות ה-APK של ההגדרות, המאפיין הזה מושמט או מוגדר כ- |
<dist:module | מגדיר מאפיינים שקובעים איך המודול יאוחסן ויופץ כקובצי APK. |
dist:instant="true | false" |
קובע אם המודול יהיה זמין דרך Google Play ללא התקנה כחוויה מיידית.
אם האפליקציה כוללת מודול תכונות אחד או יותר שפועלים באופן מיידי, צריך להפעיל באופן מיידי גם את המודול הבסיסי. כשמשתמשים ב-Android Studio בגרסה 3.5 ואילך, סביבת הפיתוח עושה זאת בשבילכם כשיוצרים מודול תכונה שפועל באופן מיידי. אי אפשר להגדיר את אלמנט ה-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> | |
</dist:module> | |
<application
android:hasCode="true | false"> ... </application> |
אם מודול התכונה לא יוצר קבצי DEX – כלומר, הוא לא מכיל קוד שיעבור הידור לפורמט קובץ ה-DEX – צריך לבצע את הפעולות הבאות (אחרת, יכול להיות שתקבלו שגיאות זמן ריצה):
|
... </manifest> |
מקורות מידע נוספים
מידע נוסף על השימוש במודולים של תכונות זמין במקורות המידע הבאים.
פוסטים בבלוג
- תכונות חדשות שיעזרו לכם לפתח, לפרסם ולקדם את העסק ב-Google Play
- העדכונים האחרונים של Android App Bundle, כולל ה-API של שפות נוספות
- Patchwork Plaid — A modularization story
סרטונים
- התאמה אישית של העברת הנתונים באמצעות App Bundle ושיתוף קל של גרסאות build לבדיקה
- כלים חדשים לאופטימיזציה של גודל האפליקציה ולהגדלת מספר ההתקנות ב-Google Play
התנאים וההגבלות ובטיחות הנתונים
הגישה לספריית Play Feature Delivery Library או השימוש בה מבטאים את הסכמתכם לתנאים ולהגבלות של Play Core Software Development Kit. לפני שמקבלים גישה לספרייה, צריך לקרוא ולהבין את כל התנאים וההגבלות ותנאי המדיניות החלים.
אבטחת נתונים
ספריות Play Core הן ממשק זמן הריצה של האפליקציה עם חנות Google Play. לכן, כשמשתמשים ב-Play Core באפליקציה, חנות Play מפעילה תהליכים משלה, שכוללים טיפול בנתונים בהתאם לתנאים ולהגבלות של Google Play. בהמשך מוסבר איך ספריות Play Core מטפלות בנתונים כדי לעבד בקשות ספציפיות מהאפליקציה.
API של שפות נוספות
נתונים שנאספים לגבי השימוש | רשימת השפות המותקנות |
מטרת איסוף הנתונים | הנתונים שנאספים משמשים להצגת גרסאות שונות של האפליקציה בשפות שונות, ולשמירה על השפות שהותקנו אחרי עדכון האפליקציה. |
הצפנת נתונים | הנתונים מוצפנים. |
שיתוף נתונים | הנתונים לא מועברים לצדדים שלישיים. |
מחיקת נתונים | הנתונים נמחקים לאחר תקופת שמירה קבועה. |
הפצת פיצ'רים ב-Play
נתונים שנאספים לגבי השימוש |
מטא-נתונים של המכשיר גרסת האפליקציה |
מטרת איסוף הנתונים | הנתונים שנאספים משמשים להצגת המודול הנכון במכשיר, לשמירה על המודולים המותקנים אחרי עדכון, לגיבוי ולשחזור. |
הצפנת נתונים | הנתונים מוצפנים. |
שיתוף נתונים | הנתונים לא מועברים לצדדים שלישיים. |
מחיקת נתונים | הנתונים נמחקים בתום תקופת שמירה קבועה. |
המטרה שלנו היא להתנהל בשקיפות רבה ככל האפשר. עם זאת, רק אתם אחראים להחליט איך לענות על השאלות בטופס אבטחת הנתונים של Google Play בנוגע לאיסוף הנתונים של משתמשי האפליקציה, לשיתוף הנתונים האלה ולנוהלי האבטחה באפליקציה.