גרסת האפליקציה

ניהול גרסאות הוא רכיב קריטי בשדרוג ובתחזוקה של האפליקציה את האסטרטגיה שלנו. ניהול גרסאות חשוב מהסיבות הבאות:

  • המשתמשים צריכים לקבל מידע ספציפי על גרסת האפליקציה מותקנת במכשירים שלהם וגרסאות השדרוג הזמינות להם בתהליך ההתקנה.
  • אפליקציות אחרות – כולל אפליקציות אחרות שפרסמתם בתור חבילה – צריך לשלוח שאילתה למערכת לגבי גרסת האפליקציה קביעת תאימות ולזהות יחסי תלות.
  • יכול להיות שהשירותים שבהם האפליקציות שלך מתפרסמות יצטרכו גם לשלוח שאילתה לאפליקציה לגבי הגרסה שלה כדי שיוכלו להציג את הגרסה משתמשים. ייתכן ששירות הפרסום יצטרך לבדוק את גרסת האפליקציה כדי קביעת תאימות ויצירת יחסי שדרוג/שדרוג לאחור.

מערכת 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.