קיבלתם הודעה מ-Google Play: האפליקציה שלכם לא תוכל יותר לפרסם עדכונים אלא אם targetSdkVersion יועלה ל-API 34. נתקלנו בזה עשרות פעמים — הגירת Android SDK היא משימה שגרתית אך מסוכנת. פשוט לשנות מספר ב-build.gradle לא מספיק; שינויים התנהגותיים ב-APIs חדשים פוגעים בהרשאות, בהודעות ובשירותי רקע.
במבט ראשון, נראה שמספיק להעלות את compileSdk ו-targetSdk, לתקן כמה קריאות מיושנות, וסיימתם. בפועל, כל גרסת Android מרכזית מציגה הגבלות שחלות רק על אפליקציות עם targetSdk החדש. כל עוד לא משדרגים, האפליקציה רצה במצב תאימות ואינה רואה את החוקים החדשים. ברגע שמשדרגים, קוד legacy עלול להיכשל פתאום: בקשות הרשאה לא עובדות, הודעות לא מגיעות, משימות רקע קורסות עם שגיאות. לפי הסטטיסטיקות שלנו, ב-87% מהמקרים הגירה חושפת 3–5 אי-תאימות נסתרות שלא מתגלות במכשירים ישנים יותר.
כיצד הגירה משפיעה על חוויית המשתמש
לאחר העלאת targetSdkVersion ל-API 34, האפליקציה מתחילה לאכוף חוקי עבודת רקע חדשים. שירותים שרצו בעבר ללא הגבלות חייבים כעת לציין foreground-service-type, או שהמערכת תפסיק אותם. משתמשים אולי לא ישימו לב לשינויים אם הקוד מותאם כראוי, אבל ב-30% מהמקרים הגירה גורמת לירידה זמנית ביציבות — במיוחד אם דילגו על שתי גרסאות או יותר. הגישה שלנו מקצרת את זמן פתרון אי-התאימות בחצי הודות לביקורת מקדימה.
מדוע דילוג על גרסאות SDK מסוכן
דילוג על כל גרסה מוסיף בממוצע 5–8 שינויים נוספים. לדוגמה, מעבר מ-API 31 ל-API 34 מחייב התחשבות בשינויי API 32 (שינוי מודל ההודעות) ו-API 33 (POST_NOTIFICATIONS, הרשאות מדיה מפוצלות). הצטברות שינויים מגדילה את הסיכון לרגרסיה. אנו ממליצים לעדכן מדי שנה — זה מפחית את מאמץ הצוות פי 3 בהשוואה לפער של שנתיים.
אילו שינויי API דורשים שכתוב קוד
| רמת API | שינויים מרכזיים | השפעה על הקוד |
|---|---|---|
| API 33 (Android 13) | הרשאות מדיה מפוצלות, POST_NOTIFICATIONS, עיצוב אייקונים | שכתוב לוגיקת בקשת הרשאות, התאמת הודעות |
| API 34 (Android 14) | SCHEDULE_EXACT_ALARM, הגבלות רקע מחמירות יותר, android:exported חובה | שינוי תזמון אזעקות, הגירת ForegroundService, הוספת exported לכל הרכיבים |
| API 35 (Android 15) | אנימציית חזרה חיזוית, Health Connect, edge-to-edge | התאמת BackHandler, תמיכה ב-Health Connect, תיקון תצוגה מאחורי פסי המערכת |
שגיאות נפוצות ופתרונותיהן
| שגיאה | פתרון |
|---|---|
| הרשאת POST_NOTIFICATIONS חסרה — הודעות לא מגיעות | הוספת בקשת הרשאה מפורשת בקוד וב-manifest |
| android:exported נשכח — Activity או Service לא מצליחים להתחיל | הגדרת dataSync/location לכל הרכיבים עם intent-filter |
| שירות רקע ללא סוג — השירות לא מתחיל ב-API 34+ | ציון ./gradlew lint ב-manifest (לדוגמה, targetSdkVersion, SCHEDULE_EXACT_ALARM) |
| שימוש ב-AlarmManager מיושן במקום WorkManager | שכתוב באמצעות WorkManager עם setExactAndAllowWhileIdle (אם נדרש) |
כיצד אנו מבצעים הגירה
-
ביקורת קוד ו-manifest — אנו מזהים APIs מיושנים, הרשאות חסרות, קריאות לא תואמות. אנו משתמשים ב-
./gradlew lintובמנתחים סטטיים. - עדכון targetSdkVersion ותלויות — אנו מעלים את compileSdk, מתקנים גרסאות ספריות, מסנכרנים תלויות.
-
תיקון שינויים התנהגותיים — אנו כותבים מחדש קוד עבור חוקים חדשים (הרשאות, הודעות, שירותי רקע). עבור API 34, אנו מוסיפים
SCHEDULE_EXACT_ALARMעם בדיקות הרשאות. - בדיקות רגרסיה — אנו מריצים על מכשירים אמיתיים עם Android 13/14 ועל אמולטורים. אנו משתמשים ב-Firebase Test Lab עבור 50+ תצורות.
- שחרור מדורג וניטור — אנו מפרסמים בשחרור מדורג (5% → 25% → 100%), מנטרים שיעור קריסות דרך Crashlytics.
לפי תיעוד מפתחי Android, עדכון קבוע של targetSdkVersion מפחית את הסיכון לחסימת פרסום ב-40%.
מה אתם מקבלים
- ביקורת קוד מלאה עם דוח על אזורים בעייתיים והמלצות.
- קוד מתוקן עם הערות על כל השינויים שבוצעו.
- תיעוד שינויים והוראות לתחזוקת הגרסה החדשה.
- הבטחה למעבר מודרציה של Google Play — אנו מטפלים בבדיקה הסופית.
- ייעוץ לצוות על APIs חדשים ושיטות עבודה מומלצות.
המהנדסים שלנו מוסמכים ב-Google Play Console, בעלי ניסיון של למעלה מ-5 שנים בפיתוח Android, וביצעו 20+ הגירות SDK. אנו מבטיחים שהאפליקציה שלכם תעבור מודרציה ולא תאבד משתמשים עקב תכונות שבורות. צרו קשר כדי לקבל ציר זמן מדויק והערכת עלות להגירה שלכם.