ניהול גרסאות הוא רכיב קריטי בשדרוג ובתחזוקה של האפליקציה את האסטרטגיה שלנו. ניהול גרסאות חשוב מהסיבות הבאות:
- המשתמשים צריכים לקבל מידע ספציפי על גרסת האפליקציה מותקנת במכשירים שלהם וגרסאות השדרוג הזמינות להם בתהליך ההתקנה.
- אפליקציות אחרות – כולל אפליקציות אחרות שפרסמתם בתור חבילה – צריך לשלוח שאילתה למערכת לגבי גרסת האפליקציה קביעת תאימות ולזהות יחסי תלות.
- יכול להיות שהשירותים שבהם האפליקציות שלך מתפרסמות יצטרכו גם לשלוח שאילתה לאפליקציה לגבי הגרסה שלה כדי שיוכלו להציג את הגרסה משתמשים. ייתכן ששירות הפרסום יצטרך לבדוק את גרסת האפליקציה כדי קביעת תאימות ויצירת יחסי שדרוג/שדרוג לאחור.
מערכת Android משתמשת בפרטי הגרסה של האפליקציה כדי להגן נגד שדרוגים לאחור. המערכת לא משתמשת בפרטי גרסת האפליקציה כדי לאכוף הגבלות על שדרוגים או תאימות של אפליקציות צד שלישי. האפליקציה צריכה לאכוף הגבלות על גרסאות ולספר עליהן למשתמשים.
מערכת Android אוכפת תאימות לגרסת המערכת, כפי שמבוטאת
מההגדרה minSdk
בקובצי ה-build. ההגדרה הזו
מאפשרת לאפליקציה לציין את ממשק ה-API המינימלי של המערכת שהוא תואם לו.
מידע נוסף על הדרישות לגבי API זמין
ראו ציון דרישות לגבי רמת ה-API.
דרישות ניהול הגרסאות משתנות בין פרויקטים שונים. עם זאת, מפתחים רבים מתעניינים ניהול גרסאות סמנטי הוא בסיס טוב אסטרטגיית ניהול גרסאות.
הגדרת פרטי הגרסה של האפליקציה
כדי להגדיר את פרטי הגרסה של האפליקציה, צריך להגדיר ערכים לגרסה בהגדרות בקובצי ה-build של Gradle:
מגניב
android { namespace 'com.example.testapp' compileSdk 33 defaultConfig { applicationId "com.example.testapp" minSdk 24 targetSdk 33 versionCode 1 versionName "1.0" ... } ... } ...
Kotlin
android { namespace = "com.example.testapp" compileSdk = 33 defaultConfig { applicationId = "com.example.testapp" minSdk = 24 targetSdk = 33 versionCode = 1 versionName = "1.0" ... } ... } ...
הגדרות הגרסה
קובעים ערכים לשתי הגדרות הגרסה הזמינות: versionCode
וגם
versionName
.
versionCode
- מספר שלם חיובי המשמש כמספר גרסה פנימי.
הנתון הזה עוזר לקבוע אם גרסה אחת היא עדכנית יותר
בהשוואה מאחרת, כאשר מספרים גבוהים יותר מציינים גרסאות עדכניות יותר. הדבר
לא מספר הגרסה שמוצג למשתמשים. שמספר זה נקבע על ידי
ההגדרה
versionName
. מערכת Android משתמשת בייחוס ערך שלversionCode
להגנה מפני שדרוגים לאחור על ידי מניעה משתמשים מהתקנת APK עםversionCode
שגודלו נמוך מ- את הגרסה שמותקנת כרגע במכשיר.הערך הוא מספר שלם חיובי כדי שאפליקציות אחרות יוכלו להעריך באופן פרוגרמטי אותו - כדי לבדוק קשר גומלין של שדרוג או שדרוג לאחור, לדוגמה. אפשר מגדירים את הערך לכל מספר שלם חיובי. אבל צריך לוודא בכל גרסה רציפה של האפליקציה יש ערך גבוה יותר.
הערה: הערך הכי גדול שמאפשר ל-Google Play
versionCode
הוא 2100000000.לא ניתן להעלות APK לחנות Play עם
versionCode
שיש לך שכבר נעשה בו שימוש בגרסה קודמת.הערה: במצבים מסוימים, ייתכן שתרצו יש להעלות גרסה של האפליקציה עם
versionCode
פחות מהרגיל את הגרסה העדכנית ביותר. לדוגמה, אם אתה מפרסם מספר חבילות APK, ייתכן טווחיversionCode
שהוגדרו מראש לחבילות APK ספציפיות. מידע נוסף על הקצאת ערכים שלversionCode
למספר חבילות APK. ניתן לעיין במאמר הבא: הקצאת קודי גרסאות.בדרך כלל, מפרסמים את הגרסה הראשונה של האפליקציה עם
versionCode
מוגדר ל-1, ולאחר מכן להגדיל את הערך באופן מונוטוני עם כל גרסה, בין אם הגרסה מהווה הפצה משנית. המשמעות היא שהערך שלversionCode
לא דומות בהכרח לגרסת ההפצה של האפליקציה גלוי למשתמש. אסור להציג את הגרסה הזו באפליקציות ובשירותי פרסום למשתמשים. versionName
מחרוזת המשמשת כמספר הגרסה שמוצג משתמשים. ניתן לציין את ההגדרה הזו כמחרוזת גולמית או כהפניה משאב מחרוזות.
הערך הוא מחרוזת, כך שאפשר לתאר את גרסת האפליקציה בתור <major>.<minor>.<point> או כל סוג אחר של מזהה גרסה מוחלט או יחסי. הערך
versionName
הוא הערך היחיד יוצגו למשתמשים.
הגדרה של ערכי גרסאות
אפשר להגדיר ערכי ברירת מחדל להגדרות האלה על ידי הכללתם בקטע
בלוק defaultConfig {}
, בתוך הבלוק android {}
בלוק הקובץ build.gradle
או build.gradle.kts
של המודול. אפשר
לאחר מכן לשנות את ערכי ברירת המחדל לגרסאות שונות של האפליקציה על ידי הגדרת
לסוגים שונים של גרסאות build או לטעמים של מוצרים. בקובץ הבא אפשר לראות את
ההגדרות של versionCode
וגם versionName
בלוק defaultConfig {}
, וגם הבלוק productFlavors {}
.
במהלך ה-build, הערכים האלה ממוזגים עם קובץ המניפסט של האפליקציה.
מגניב
android { ... defaultConfig { ... versionCode 2 versionName "1.1" } productFlavors { demo { ... versionName "1.1-demo" } full { ... } } }
Kotlin
android { ... defaultConfig { ... versionCode = 2 versionName = "1.1" } productFlavors { create("demo") { ... versionName = "1.1-demo" } create("full") { ... } } }
בבלוק defaultConfig {}
של הדוגמה הזו, הפרמטר
הערך versionCode
מציין שה-APK הנוכחי מכיל את
את הגרסה השנייה של האפליקציה, והמחרוזת versionName
מציינת
שהיא תוצג למשתמשים כגרסה 1.1. הקובץ הזה גם מגדיר שני טעמים של מוצרים,
'demo' ו'מלא'. מאז "ההדגמה" טעם המוצר מגדיר את versionName
כ-
'1.1-demo', 'הדגמה' ה-build משתמש בversionName
הזה במקום בערך ברירת המחדל.
הגרסה ה"מלאה" קבוצת הטעם של המוצר לא מגדירה את versionName
, אז
משתמשת בערך ברירת המחדל '1.1'.
הערה: אם גרסת האפליקציה מוגדרת באפליקציה ישירות
רכיב <manifest>
, ערכי הגרסה ב-build של Gradle
לשנות את ההגדרות שבמניפסט. בנוסף, הגדרת
בקובצי ה-build של Gradle, אפשר לציין ערכים שונים
גרסאות שונות של האפליקציה. כדי לשפר את הגמישות וכדי להימנע
להחלפה אפשרית במקרה שהמניפסט ממוזג, יש להסיר את
מהרכיב <manifest>
ומגדירים
את ההגדרות של הגרסה בקובצי ה-build של Gradle.
ה-framework של Android מספק API שמאפשר לשלוח שאילתות למערכת
כדי לקבל מידע על הגרסה של האפליקציה. כדי לקבל פרטי גרסה,
להשתמש
אמצעי תשלום אחד (
PackageManager.getPackageInfo(java.lang.String, int)
).
ציון הדרישות לגבי רמת ה-API
אם לאפליקציה נדרשת גרסה מינימלית ספציפית של Android
אפשר לציין את דרישת הגרסה הזו כהגדרות ברמת ה-API
בקובץ build.gradle
או build.gradle.kts
של האפליקציה. במהלך ה-build
ההגדרות האלה ימוזגו לקובץ המניפסט של האפליקציה. ציון רמת ה-API
מבטיחות שאפשר להתקין את האפליקציה רק במכשירים
שפועלת בהם גרסה תואמת של פלטפורמת Android.
הערה: אם אתם מציינים דרישות לגבי רמת ה-API ישירות
בקובץ המניפסט של האפליקציה, ההגדרות המתאימות בקובצי ה-build י
לשנות את ההגדרות בקובץ המניפסט. בנוסף, הגדרת
בקובצי ה-build של Gradle, אפשר לציין ערכים שונים
גרסאות שונות של האפליקציה. כדי לשפר את הגמישות וכדי להימנע
להחלפה אפשרית במקרה שהמניפסט ממוזג, יש להסיר את
מהרכיב <uses-sdk>
ומגדירים את ה-API
במקום זאת, בהגדרות של הרמה בקובצי ה-build של Gradle.
יש שתי הגדרות זמינות ברמת ה-API:
minSdk
– הגרסה המינימלית של פלטפורמת Android שבה האפליקציה תפעל, לפי מזהה רמת ה-API של הפלטפורמה.targetSdk
– רמת ה-API שבה האפליקציה מיועדת לפעול. במקרים מסוימים, הפעולות האלה מאפשרות האפליקציה להשתמש באלמנטים או בהתנהגויות של מניפסט שהוגדרו ביעד ברמת ה-API, במקום להגביל את השימוש רק באלה שהוגדרו לרמת ה-API המינימלית.
כדי לציין את דרישות ברירת המחדל לגבי רמת ה-API ב-build.gradle
או
build.gradle.kts
, מוסיפים אחת או יותר מההגדרות של רמת ה-API
בלוק defaultConfig{}
, בתוך הבלוק android {}
. אפשר
גם לשנות את ערכי ברירת המחדל
של האפליקציה על ידי הוספת ההגדרות כדי לבנות סוגים או טעמים של מוצרים.
הקובץ הבא מציין ברירת מחדל
ההגדרות של minSdk
וגם targetSdk
חסימה של defaultConfig {}
וביטול חסימה של minSdk
לטעם אחד של מוצר:
מגניב
android { ... defaultConfig { ... minSdk 21 targetSdk 33 } productFlavors { main { ... } afterNougat { ... minSdk 24 } } }
Kotlin
android { ... defaultConfig { ... minSdk = 21 targetSdk = 33 } productFlavors { create("main") { ... } create("afterNougat") { ... minSdk = 24 } } }
כשמתכוננים להתקנת האפליקציה, המערכת בודקת את הערך של
את ההגדרות האלה ומשווה אותן לגרסת המערכת. אם
הערך minSdk
גדול מגרסת המערכת,
מונעת את ההתקנה של האפליקציה.
אם לא תציינו את ההגדרות האלה, המערכת תצא מנקודת הנחה שהאפליקציה
תואמות לכל גרסאות הפלטפורמה. הפעולה הזו זהה להגדרה של minSdk
לערך
1
.
מידע נוסף זמין במאמר מהי רמת API? להגדרות build של Gradle, ראו הגדרת וריאנטים של build.