Version Code: wat is het, numerieke identificatie en updates

Wat is Version Code in Android

Version Code — is een geheel getal van het type Integer dat wordt toegewezen aan elke build van de Android-applicatie. In tegenstelling tot Version Name wordt Version Code niet aan de gebruiker getoond en wordt het uitsluitend gebruikt door het besturingssysteem en Google Play om versies te vergelijken bij het installeren van updates.

Format van Version Code

Version Code moet een positief geheel getal zijn in het bereik van 1 tot 2100000000. Elke volgende build moet een strikt grotere Version Code hebben dan de vorige. Als de ontwikkelaar een build heeft uitgebracht met Version Code 5, kan de volgende publicatie 6, 7 of elk getal groter dan 5 gebruiken, maar niet 4 en niet opnieuw 5.

Geschiedenis van ontstaan

Google introduceerde de splitsing in Version Code en Version Name met de release van de Android SDK in 2007. Version Code was ontworpen als een machine-identificatie voor automatische versievergelijking, terwijl Version Name — als een voor mensen leesbaar label. Deze scheiding stelt de ontwikkelaar in staat om de versie willekeurig te noemen, terwijl een strikte updatervolgorde via de numerieke code behouden blijft.

Hoe versiebeheer via Version Code werkt

Het vergelijkingsmechanisme van Version Code is ingebouwd in het Android-besturingssysteem en de Google Play-winkel. Bij elke publicatie controleert Google Play of de Version Code van de nieuwe build groter is dan de code van de geïnstalleerde versie. Als niet aan de voorwaarde wordt voldaan, wordt de publicatie afgewezen met een fout.

Updatecontroleproces

Wanneer het apparaat contact opneemt met Google Play om te controleren op updates, vergelijkt de server de Version Code van de geïnstalleerde applicatie met de maximale beschikbare in de winkel. Als de code op de server groter is — wordt het downloaden en installeren van de update gestart. De gebruiker ziet de Version Name die door de ontwikkelaar is opgegeven, maar de beslissing over de update wordt genomen op basis van de Version Code.

Increment van Version Code

Ontwikkelaars passen verschillende strategieën toe voor het verhogen van de Version Code. De eenvoudigste is verhoging met 1 bij elke build. Voor CI/CD-pijplijnen worden vaak timestamp of buildnummer gebruikt: 2026070301 (jaar-maand-dag-nummer). Het is belangrijk dat de code monotoon stijgt en niet wordt herhaald tussen verschillende builds en Google Play-tracken.

• Monotone increment — verhoging met 1 bij elke commit naar de release branch
• Timestamp-formaat — 20260703 voor dagelijkse builds, 2026070301 voor meerdere per dag
• SemVer in getallen — 100010000 voor versie 1.1.0 (major 1, minor 1, patch 0)
• Buildnummer — gebruik van BUILD_NUMBER uit CI-systeem (Jenkins, GitHub Actions)

Verschillen tussen Version Code en Version Name

Version Code en Version Name — twee onafhankelijke velden in build.gradle die verschillende functies vervullen. Version Code is een interne identificatie voor het systeem, Version Name is een marketinglabel voor de gebruiker. Ze kunnen onafhankelijk van elkaar veranderen.

Version Name voor de gebruiker

Version Name — is een tekenreeks die wordt weergegeven in de applicatie-instellingen, in Google Play en in updatedialogen. De ontwikkelaar kan elk formaat opgeven: 1.0.0, 2.3.1-beta, 3.0-rc1. Voor het vergelijken van tekstversies wordt Version Name niet gebruikt — Google Play vertrouwt altijd op Version Code.

Afwijkscenario’s

Een situatie is mogelijk waarin Version Code stijgt, maar Version Name ongewijzigd blijft. Bijvoorbeeld, als de ontwikkelaar een kritieke bug repareert in een hotfix-build zonder de functionaliteit te wijzigen. Version Name blijft 2.0.0, en Version Code verandert van 5 naar 6. Google Play zal een dergelijke update correct verwerken.

// Voorbeeld: version name verandert niet, code stijgt
android {
    defaultConfig {
        versionCode 6  // Was 5 — hotfix zonder nieuwe functies
        versionName "2.0.0"  // Niet veranderd
    }
}

// Versies controleren in runtime
val code = BuildConfig.VERSION_CODE
val name = BuildConfig.VERSION_NAME
println("Code: $code, Naam: $name")

Version Code configureren in build.gradle

Configuratie van Version Code gebeurt in het build.gradle-bestand van de applicatiemodule. Het veld versionCode accepteert een geheel getal en bevindt zich in het defaultConfig-blok. Voor verschillende flavour-builds kunnen eigen waarden worden ingesteld via het veld versionCode in de productconfiguratie.

Basisconfiguratie

// 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 maken het mogelijk om verschillende Version Codes te gebruiken voor verschillende configuraties: demo-versie, aparte versie voor tablets. Als er flavors in het project worden gebruikt, bestaat de uiteindelijke Version Code uit het basisgetal en de flavour-specifieke increment. Google Play volgt elke combinatie onafhankelijk.

Automatisering van increment via CI

In CI/CD-pijplijnen (GitHub Actions, GitLab CI, Jenkins) wordt Version Code vaak automatisch gegenereerd op basis van het buildnummer of de datum. Dit elimineert menselijke fouten bij handmatige updates. Het script leest de huidige Version Code uit build.gradle, verhoogt deze en schrijft deze terug voordat de build begint.

// Automatische increment van 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 regels voor publicatie in Google Play

Google Play heeft strikte regels voor Version Code bij het publiceren en updaten van applicaties. Overtreding van deze regels leidt tot afwijzing van de build of het onvermogen om een update uit te brengen. De ontwikkelaar moet de beperkingen en strategieën voor codebeheer in alle fasen van de levenscyclus begrijpen.

Regel van monotone stijging

Google Play staat niet toe dat een APK of AAB wordt geüpload waarvan de Version Code kleiner of gelijk is aan de huidige gepubliceerde. Deze regel werkt voor elke track (production, beta, alpha) onafhankelijk. Als in production een build met Version Code 10 is geüpload en in alpha — met code 5, kan de alpha-track worden bijgewerkt naar 6, 7, 8 of 9, maar production blijft op 10.

Migratie tussen tracks

Bij het promoveren van een build van alpha naar beta en vervolgens naar production, moet Version Code in elke fase stijgen. Als de alpha-versie code 10 heeft, kan beta 11 gebruiken, en production — 12. Het is niet mogelijk om een build met code 10 naar production te rollouten als alpha al 10 gebruikt, zelfs als production het nog niet heeft gezien.

• Monotonous increment — elke build in een track heeft een Version Code groter dan de vorige in dezelfde track
• Cross-track awareness — bij promotie tussen tracks wordt Version Code sequentieel verhoogd
• Internal testing — de interne testtrack gebruikt dezelfde monotoniteitsregels
• Multiple APKs — het oude publicatieformaat vereiste een unieke Version Code voor elke APK

Fouten bij het specificeren van Version Code

De meest voorkomende fout — overeenkomst van Version Code in verschillende builds die naar één track zijn geüpload. Google Play retourneert de fout APK_VERSION_CODE_ALREADY_EXISTS. Een andere fout — overschrijding van de maximale waarde 2100000000, wat leidt tot een compilatiefout. Gebruik automatische codegeneratie in een CI-systeem met koppeling aan het buildnummer of de builddatum om conflicten te voorkomen.

Ontwikkelaars maken ook vaak de fout om Version Code niet te verhogen bij een hotfix-build voor een alternatieve track. Als production code 15 heeft en de alpha-track op 14 is gebleven, zal Google Play bij promotie van alpha naar production de build afwijzen omdat de code kleiner is dan de huidige production. Houd de monotoniteit van de code in alle tracks tegelijkertijd in de gaten — gebruik hiervoor een enkel version.properties-bestand waaruit alle tracks de huidige waarde lezen.