Version Code: Was es ist, numerischer Identifikator und Updates

Was ist der Version Code in Android

Version Code ist eine ganze Zahl vom Typ Integer, die jedem Build einer Android-Anwendung zugewiesen wird. Im Gegensatz zum Version Name wird der Version Code dem Benutzer nicht angezeigt und wird ausschließlich vom Betriebssystem und Google Play verwendet, um Versionen bei der Installation von Updates zu vergleichen.

Format des Version Code

Version Code muss eine positive ganze Zahl im Bereich von 1 bis 2100000000 sein. Jeder nachfolgende Build muss einen streng größeren Version Code als der vorherige haben. Wenn ein Entwickler einen Build mit Version Code 5 veröffentlicht hat, kann die nächste Veröffentlichung 6, 7 oder eine beliebige Zahl größer als 5 verwenden, aber nicht 4 und nicht erneut 5.

Entstehungsgeschichte

Google führte die Trennung von Version Code und Version Name mit der Veröffentlichung des Android SDK im Jahr 2007 ein. Version Code wurde als Maschinenkennung für den automatischen Versionsvergleich konzipiert, während Version Name als menschenlesbares Etikett gedacht war. Diese Trennung erlaubt es dem Entwickler, die Version nach Belieben zu benennen, während eine strenge Update-Reihenfolge durch den numerischen Code erhalten bleibt.

Wie die Versionierung durch den Version Code funktioniert

Der Vergleichsmechanismus des Version Code ist in das Android-Betriebssystem und den Google Play Store integriert. Bei jeder Veröffentlichung überprüft Google Play, ob der Version Code des neuen Builds größer ist als der Code der installierten Version. Wenn die Bedingung nicht erfüllt ist, wird die Veröffentlichung mit einem Fehler abgelehnt.

Update-Überprüfungsprozess

Wenn ein Gerät Google Play zur Überprüfung auf Updates kontaktiert, vergleicht der Server den Version Code der installierten Anwendung mit dem maximal im Store verfügbaren. Ist der Code auf dem Server größer, werden Download und Installation des Updates gestartet. Der Benutzer sieht den vom Entwickler angegebenen Version Name, aber die Update-Entscheidung wird auf Basis des Version Code getroffen.

Version Code-Inkrement

Entwickler wenden verschiedene Strategien zur Erhöhung des Version Code an. Die einfachste ist die Erhöhung um 1 bei jedem Build. Für CI/CD-Pipelines wird häufig ein Zeitstempel oder die Build-Nummer verwendet: 2026070301 (Jahr-Monat-Tag-Nummer). Wichtig ist, dass der Code monoton steigt und sich zwischen verschiedenen Builds und Google Play-Tracks nicht wiederholt.

• Monotones Inkrement — Erhöhung um 1 bei jedem Commit in den Release-Branch
• Zeitstempel-Format — 20260703 für tägliche Builds, 2026070301 für mehrere Builds pro Tag
• SemVer in Zahlen — 100010000 für Version 1.1.0 (Major 1, Minor 1, Patch 0)
• Build-Nummer — Verwendung der BUILD_NUMBER aus dem CI-System (Jenkins, GitHub Actions)

Unterschiede zwischen Version Code und Version Name

Version Code und Version Name sind zwei unabhängige Felder in build.gradle, die unterschiedliche Funktionen erfüllen. Der Version Code ist ein interner Identifikator für das System, der Version Name ein Marketing-Etikett für den Benutzer. Sie können unabhängig voneinander geändert werden.

Version Name für den Benutzer

Version Name ist eine Zeichenfolge, die in den Anwendungseinstellungen, bei Google Play und in Update-Dialogen angezeigt wird. Der Entwickler kann jedes beliebige Format angeben: 1.0.0, 2.3.1-beta, 3.0-rc1. Der Version Name wird nicht zum Vergleich von Zeichenfolgenversionen verwendet — Google Play verlässt sich immer auf den Version Code.

Abweichungsszenarien

Eine Situation ist möglich, in der der Version Code steigt, während der Version Name gleich bleibt. Zum Beispiel, wenn ein Entwickler einen kritischen Fehler in einem Hotfix-Build behebt, ohne die Funktionalität zu ändern. Der Version Name bleibt 2.0.0, während der Version Code von 5 auf 6 wechselt. Google Play wird ein solches Update korrekt verarbeiten.

// Beispiel: version name ändert sich nicht, Code erhöht sich
android {
    defaultConfig {
        versionCode 6  // War 5 — Hotfix ohne neue Funktionen
        versionName "2.0.0"  // Nicht geändert
    }
}

// Versionsprüfung zur Laufzeit
val code = BuildConfig.VERSION_CODE
val name = BuildConfig.VERSION_NAME
println("Code: $code, Name: $name")

Konfiguration des Version Code in build.gradle

Die Konfiguration des Version Code erfolgt in der build.gradle-Datei des Anwendungsmoduls. Das Feld versionCode akzeptiert eine ganze Zahl und ist Teil des defaultConfig-Blocks. Für verschiedene Flavor-Builds können benutzerdefinierte Werte über das Feld versionCode in der Produktkonfiguration festgelegt werden.

Basiskonfiguration

// 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 ermöglichen die Verwendung unterschiedlicher Version Codes für verschiedene Konfigurationen: Demo-Version, separate Version für Tablets. Wenn im Projekt Flavors verwendet werden, setzt sich der endgültige Version Code aus der Basiszahl und dem Flavor-spezifischen Inkrement zusammen. Google Play verfolgt jede Kombination unabhängig.

Automatisierung des Inkrements über CI

In CI/CD-Pipelines (GitHub Actions, GitLab CI, Jenkins) wird der Version Code oft automatisch basierend auf der Build-Nummer oder dem Datum generiert. Dies eliminiert menschliche Fehler bei manuellen Aktualisierungen. Das Skript liest den aktuellen Version Code aus build.gradle, erhöht ihn und schreibt ihn vor dem Start des Builds zurück.

// Automatisches Inkrement des 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
    }
}

Besonderheiten des Version Code für die Veröffentlichung bei Google Play

Google Play hat strenge Regeln für den Version Code beim Veröffentlichen und Aktualisieren von Anwendungen. Ein Verstoß gegen diese Regeln führt zur Ablehnung des Builds oder zur Unmöglichkeit, ein Update zu veröffentlichen. Der Entwickler muss die Einschränkungen und Code-Management-Strategien in allen Phasen des Lebenszyklus verstehen.

Regel des monotonen Anstiegs

Google Play erlaubt nicht das Hochladen eines APK oder AAB, dessen Version Code kleiner oder gleich dem aktuell veröffentlichten ist. Diese Regel gilt für jeden Track (Production, Beta, Alpha) unabhängig. Wenn in Production ein Build mit Version Code 10 hochgeladen wurde und in Alpha ein Build mit Code 5, kann der Alpha-Track auf 6, 7, 8 oder 9 aktualisiert werden, aber Production bleibt bei 10.

Migration zwischen Tracks

Bei der Promotion eines Builds von Alpha zu Beta und dann zu Production muss der Version Code in jeder Stufe steigen. Wenn die Alpha-Version Code 10 hat, kann Beta 11 und Production 12 verwenden. Sie können keinen Build mit Code 10 in Production ausrollen, wenn Alpha bereits 10 verwendet, selbst wenn Production diesen Code noch nicht gesehen hat.

• Monotones Inkrement — jeder Build in einem Track hat einen größeren Version Code als der vorherige im selben Track
• Track-übergreifendes Bewusstsein — bei der Promotion zwischen Tracks steigt der Version Code sequenziell
• Interne Tests — der interne Test-Track verwendet dieselben Monotonie-Regeln
• Mehrere APKs — das alte Veröffentlichungsformat erforderte einen eindeutigen Version Code für jedes APK

Fehler bei der Angabe des Version Code

Der häufigste Fehler ist die Übereinstimmung des Version Code in verschiedenen Builds, die in denselben Track hochgeladen wurden. Google Play gibt den Fehler APK_VERSION_CODE_ALREADY_EXISTS zurück. Ein weiterer Fehler ist das Überschreiten des Maximalwerts 2100000000, was zu einem Kompilierungsfehler führt. Um Konflikte zu vermeiden, verwenden Sie eine automatische Codegenerierung in Ihrem CI-System, die an die Build-Nummer oder das Build-Datum gebunden ist.

Entwickler machen auch oft den Fehler, den Version Code beim Erstellen eines Hotfix-Releases für einen alternativen Track nicht zu erhöhen. Wenn Production Code 15 hat und der Alpha-Track auf 14 geblieben ist, wird Google Play bei der Promotion von Alpha zu Production den Build ablehnen, da sein Code kleiner ist als der aktuelle Production-Code. Überwachen Sie die Monotonie des Codes in allen Tracks gleichzeitig — dafür ist es praktisch, eine einzige version.properties-Datei zu verwenden, aus der alle Tracks den aktuellen Wert lesen.