עדכון בתוך האפליקציה לאנדרואיד: שילוב עדכון כפוי

עדכוני אפליקציות אנדרואיד מואצים עם In-App Update API

עדכון כפוי לאנדרואיד הוא כלי של Google Play שמספק תיקונים ללא פעולה מצד המשתמש. המשתמשים לא מעדכנים בעצמם. לפי נתוני Play Console, זמן ההתקנה הממוצע הוא כשלושה שבועות. תיקון קריטי ממתין למשתמש 21 ימים. ה-API הזה פותר את הבעיה ישירות. עדכון כפוי באמצעות מצב Immediate מפחית את חלקם של הגרסאות המיושנות ל-5% תוך 48 שעות. לצוות שלנו ניסיון של 7+ שנים בשילוב מנגנוני עדכון לאנדרואיד. יישמנו את הכלי הזה ביותר מ-40 פרויקטים. עלות האינטגרציה הבסיסית מתחילה לאחר ניתוח. מחזור מלא עם בדיקות ו-CI/CD מתומחר בנפרד. צרו קשר לבדיקה: נקצר את זמן אספקת התיקונים הקריטיים לדקות.

באיזה מצב של In-App Update לבחור?

Google Play In-App Update API, הזמין דרך com.google.android.play:app-update-ktx, מספק שני תרחישים. רמת ה-SDK המינימלית לאנדרואיד היא 21. הספרייה שוקלת כ-150 KB ועובדת על אנדרואיד 5.0 ומעלה.

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

עדכון מיידי (Immediate) — ממשק חוסם במסך מלא מ-Google Play. האפליקציה אינה זמינה עד להשלמת העדכון. משמש לתיקונים קריטיים: שינוי סכמת הצפנה, מיגרציית מסד נתונים חובה, ביטול API אחורי ישן. עדכון מיידי מהיר יותר מהמתנה רגילה: ההתקנה אורכת 2-5 דקות, לא 3 שבועות. החיסכון בתמיכה בגרסאות מיושנות מגיע ל-70%. לפי נתוני Google I/O, שיעור ההתקנה בתרחיש Immediate גבוה ב-60-80%.

מה גורם לבעיות ביישום?

הטעות הנפוצה ביותר היא אתחול AppUpdateManager ללא בדיקת זמינות עדכון. המתודה appUpdateManager.appUpdateInfo מחזירה Task<AppUpdateInfo>, ויש להמתין לה באופן אסינכרוני. ניסיונות לקרוא ל-startUpdateFlowForResult ללא AppUpdateInfo מוכן גורמים ל-IllegalStateException בזמן ריצה.

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

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

יישום In-App Update במפתח מלא

האינטגרציה מתחילה בבדיקת סכמת ניהול הגרסאות הנוכחית — אנו מוודאים ש-versionCode עולה באופן מונוטוני ואין התנגשויות בין טעמים. לאחר מכן אנו מוסיפים את התלות וכותבים מחלקת UpdateManager בשכבת הדומיין (ארכיטקטורה נקייה — ה-UI לא יודע על Play Services ישירות).

val appUpdateManager = AppUpdateManagerFactory.create(context)
val appUpdateInfoTask = appUpdateManager.appUpdateInfo
appUpdateInfoTask.addOnSuccessListener { info ->
    if (info.updateAvailability() == UpdateAvailability.UPDATE_AVAILABLE &&
        info.isUpdateTypeAllowed(AppUpdateType.FLEXIBLE)
    ) {
        appUpdateManager.startUpdateFlowForResult(
            info,
            AppUpdateType.FLEXIBLE,
            activity,
            REQUEST_CODE_UPDATE
        )
    }
}

לתרחיש Immediate, אנו מוסיפים val appUpdateManager = AppUpdateManagerFactory.create(context) val appUpdateInfoTask = appUpdateManager.appUpdateInfo appUpdateInfoTask.addOnSuccessListener { info -> if (info.updateAvailability() == UpdateAvailability.UPDATE_AVAILABLE && info.isUpdateTypeAllowed(AppUpdateType.FLEXIBLE) ) { appUpdateManager.startUpdateFlowForResult( info, AppUpdateType.FLEXIBLE, activity, REQUEST_CODE_UPDATE ) } } — עדכון כפוי מופעל רק אם העדכון זמין יותר מ-N ימים. הסף המומלץ הוא 3 עד 7 ימים לשחרורי תכונות. זה מפחית את התסכול של המשתמשים מתיקונים מינוריים.

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

טיפול בביטול עדכון כפוי

עדכון מיידי לא אומר שהמשתמש בהכרח יעדכן. הם יכולים לסגור את האפליקציה — installStatus מחזירה onActivityResult. יש לטפל נכון בענף זה: לרשום את האירוע ואולי להציג דיאלוג המסביר את הצורך בעדכון. במקרים מסוימים, ניתן לעבור לעדכון גמיש אם הדבר מותר. קבלו ייעוץ על יישום In-App Update, ואנו נציע פתרון אישי לאפליקציה שלכם.

בדיקת In-App Update עם FakeAppUpdateManager

RESULT_CANCELED מ-FakeAppUpdateManager מאפשר לדמות את כל המצבים ללא פרסום ב-Play Store. בבדיקות Espresso, ניתן להריץ מחזור מלא: זמינות → התחלת הורדה → השלמה → הפעלה מחדש. לפי תיעוד Google Play In-App Update API, ללא כיסוי זה, באגים נכנסים לייצור. Google Play מציגה UI מעל האפליקציה. בדיקות UI רגילות לא רואות אותו. מחזור הבדיקות ב-CI אורך 4-6 דקות.

תהליך עבודה ולוחות זמנים

1. אנליטיקה — בדיקת ניהול גרסאות, ארכיטקטורה ותלויות נוכחיות (יום אחד).
2. עיצוב — בחירת מצב, קביעת InstallStatus.DOWNLOADED, כתיבת בדיקות אינטגרציה (1-2 ימים).
3. יישום — קוד staleDays, טיפול ב-UpdateManager, רישום לוגים (1-2 ימים).
4. בדיקות — יחידה, אינטגרציה, אוטומציית UI (יום אחד).
5. פריסה — פרסום ל-Internal Testing, אימות על מכשירים אמיתיים (יום אחד).

זמן משוער — בין 2 ל-5 ימי עבודה בהתאם למורכבות הארכיטקטורה.

מה כלול בעבודה

• בדיקת סכמת ניהול גרסאות נוכחית
• יישום onResume עם טיפול בכל המצבים
• בדיקות יחידה ובדיקות UI עם UpdateManager
• אינטגרציה עם CI/CD
• תיעוד תפעולי
• תמיכה למשך שבועיים לאחר השחרור

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