Version Code: vad är det, numerisk identifierare och uppdateringar

Vad är Version Code i Android

Version Code — är ett heltal av typen Integer som tilldelas varje byggnad av Android-applikationen. Till skillnad från Version Name visas inte Version Code för användaren och används enbart av operativsystemet och Google Play för att jämföra versioner vid installation av uppdateringar.

Format för Version Code

Version Code måste vara ett positivt heltal inom intervallet 1 till 2100000000. Varje efterföljande byggnad måste ha en Version Code som är strikt större än den föregående. Om utvecklaren har publicerat en byggnad med Version Code 5, kan nästa publicering använda 6, 7 eller vilket tal som helst större än 5, men inte 4 och inte 5 igen.

Uppkomsthistoria

Google införde uppdelningen i Version Code och Version Name med lanseringen av Android SDK 2007. Version Code utformades som en maskinidentifierare för automatisk versionsjämförelse, medan Version Name — som en människoläsbar etikett. Denna uppdelning gör det möjligt för utvecklaren att namnge versionen godtyckligt, samtidigt som en strikt uppdateringsordning bibehålls genom den numeriska koden.

Hur versionshantering genom Version Code fungerar

Jämförelsemekanismen för Version Code är inbyggd i Android-operativsystemet och Google Play-butiken. Vid varje publicering kontrollerar Google Play om Version Code för den nya byggnationen är större än koden för den installerade versionen. Om villkoret inte uppfylls avvisas publiceringen med ett fel.

Uppdateringskontrollprocess

När enheten kontaktar Google Play för att kontrollera uppdateringar, jämför servern Version Code för den installerade applikationen med den maximala tillgängliga i butiken. Om koden på servern är större — startas nedladdning och installation av uppdateringen. Användaren ser Version Name som angivits av utvecklaren, men beslutet om uppdatering fattas baserat på Version Code.

Ökning av Version Code

Utvecklare tillämpar olika strategier för att öka Version Code. Den enklaste är ökning med 1 vid varje byggnad. För CI/CD-pipelines används ofta timestamp eller byggnummer: 2026070301 (år-månad-dag-nummer). Det är viktigt att koden ökar monotont och inte upprepas mellan olika byggnader och Google Play-spår.

• Monoton ökning — ökning med 1 vid varje commit till release-grenen
• Timestamp-format — 20260703 för dagliga byggen, 2026070301 för flera per dag
• SemVer i siffror — 100010000 för version 1.1.0 (major 1, minor 1, patch 0)
• Byggnummer — användning av BUILD_NUMBER från CI-system (Jenkins, GitHub Actions)

Skillnader mellan Version Code och Version Name

Version Code och Version Name — två oberoende fält i build.gradle som utför olika funktioner. Version Code är en intern identifierare för systemet, Version Name är en marknadsföringsetikett för användaren. De kan ändras oberoende av varandra.

Version Name för användaren

Version Name — är en sträng som visas i applikationsinställningarna, i Google Play och i uppdateringsdialogrutor. Utvecklaren kan ange vilket format som helst: 1.0.0, 2.3.1-beta, 3.0-rc1. För att jämföra textversioner används inte Version Name — Google Play förlitar sig alltid på Version Code.

Avvikelsescenarier

En situation är möjlig där Version Code ökar men Version Name förblir oförändrat. Till exempel, om utvecklaren reparerar ett kritiskt fel i en hotfix-byggnad utan att ändra funktionaliteten. Version Name förblir 2.0.0, och Version Code ändras från 5 till 6. Google Play kommer att hantera en sådan uppdatering korrekt.

// Exempel: version name ändras inte, code ökar
android {
    defaultConfig {
        versionCode 6  // Var 5 — hotfix utan nya funktioner
        versionName "2.0.0"  // Ändrades inte
    }
}

// Kontroll av versioner i runtime
val code = BuildConfig.VERSION_CODE
val name = BuildConfig.VERSION_NAME
println("Kod: $code, Namn: $name")

Konfigurera Version Code i build.gradle

Konfiguration av Version Code görs i filen build.gradle för applikationsmodulen. Fältet versionCode accepterar ett heltal och finns i blocket defaultConfig. För olika flavour-byggen kan egna värden ställas in via fältet versionCode i produktkonfigurationen.

Grundkonfiguration

// build.gradle.kts — Kotlin DSL
android {
    defaultConfig {
        applicationId "com.example.app"
        versionCode 15
        versionName "2.1.0"
    }

    flavorDimensions +"version"
    productFlavors {
        create("demo") {
            versionCode 1015
        }
        create("full") {
            versionCode 2015
        }
    }
}

Product flavors gör det möjligt att använda olika Version Code för olika konfigurationer: demoversion, separat version för surfplattor. Om flavors används i projektet består den slutliga Version Code av basnumret och den flavour-specifika ökningen. Google Play följer varje kombination oberoende.

Automatisering av ökning genom CI

I CI/CD-pipelines (GitHub Actions, GitLab CI, Jenkins) genereras Version Code ofta automatiskt baserat på byggnumret eller datumet. Detta eliminerar mänskliga fel vid manuell uppdatering. Skriptet läser aktuell Version Code från build.gradle, ökar den och skriver tillbaka den innan bygget påbörjas.

// Automatisk ökning av Version Code
import java.util.Properties
import java.io.FileInputStream

val versionProps = Properties()
versionProps.load(FileInputStream("version.properties"))

val versionCode = versionProps.getProperty("VERSION_CODE").toInt() + 1
versionProps.setProperty("VERSION_CODE", versionCode.toString())

android {
    defaultConfig {
        versionCode = versionCode
    }
}

Version Code-regler för publicering i Google Play

Google Play har strikta regler för Version Code vid publicering och uppdatering av applikationer. Brott mot dessa regler leder till avvisning av bygget eller oförmåga att lansera en uppdatering. Utvecklaren måste förstå begränsningarna och strategierna för kodhantering i alla skeden av livscykeln.

Regel om monoton ökning

Google Play tillåter inte uppladdning av APK eller AAB vars Version Code är mindre än eller lika med den för närvarande publicerade. Denna regel gäller för varje spår (production, beta, alpha) oberoende. Om en byggnad med Version Code 10 har laddats upp i production och i alpha med kod 5, kan alpha-spåret uppdateras till 6, 7, 8 eller 9, men production förblir på 10.

Migrering mellan spår

Vid befordran av en byggnad från alpha till beta och sedan till production måste Version Code öka i varje steg. Om alphaversionen har kod 10 kan beta använda 11 och production 12. Det går inte att rulla ut en byggnad med kod 10 till production om alpha redan använder 10, även om production ännu inte har sett den.

• Monotonous increment — varje byggnad i ett spår har Version Code större än den föregående i samma spår
• Cross-track awareness — vid befordran mellan spår ökas Version Code sekventiellt
• Internal testing — spåret för intern testning använder samma monotonitetsregler
• Multiple APKs — det gamla publiceringsformatet krävde unik Version Code för varje APK

Fel vid angivande av Version Code

Det vanligaste felet — att Version Code sammanfaller i olika byggnader som laddats upp till ett spår. Google Play returnerar felet APK_VERSION_CODE_ALREADY_EXISTS. Ett annat fel — överskridande av maxvärdet 2100000000, vilket orsakar ett kompileringsfel. För att undvika konflikter, använd automatisk kodgenerering i CI-systemet kopplat till byggnumret eller byggdatumet.

Utvecklare gör också ofta misstaget att inte öka Version Code vid hotfix-byggnad för ett alternativt spår. Om production har kod 15 och alpha-spåret har stannat på 14, kommer Google Play vid befordran av alpha till production att avvisa bygget eftersom dess kod är mindre än den aktuella production. Övervaka monotoniteten hos koden i alla spår samtidigt — för detta är det praktiskt att använda en enda version.properties-fil som alla spår läser det aktuella värdet från.