Android Version Code Tricks

Lassen Sie uns diese Option ausprobieren. Zuerst richten wir die App ein und geben 1 als StandardversionCode an und überschreiben ihn für alle Varianten auf 2:

Aber wenn wir dann in die BuildConfig Datei schauen, sehen wir, dass der Versionscode immer noch auf 1 gesetzt ist. Wenn wir jedoch in das resultierende AndroidManifest schauen, sehen wir, dass der Versionscode korrekt auf 2 gesetzt ist.
Fehler oder Feature? Lassen Sie uns herausfinden, was passiert ist.

Innerhalb des Codes können wir auf den Versionscode von BuildConfig.VERSION_CODE oder von PackageManager.packageInfo.versionCode zugreifen:

Nachdem wir den Code in Logcat ausgeführt haben, werden wir genau das sehen, was wir oben beobachtet haben:

Der Grund, warum das passiert, ist, dass es in den android gradle build tools zwei separate Tasks für die Generierung der BuildConfig-Datei und für die Verarbeitung des AndroidManifestes gibt.

Wenn wir in GenerateBuildConfig schauen, sehen wir, dass die VERSION_CODE-Eigenschaft von der getVersionCode()-Methode generiert wird:

Und dass getVersionCode sich auf den in variantConfiguration gespeicherten Wert bezieht:

Im Gegensatz zur Generierung von BuildConfig in ProcessApplicationManifest sehen wir, dass der Versionscode aus apkData abgerufen wird.

Wenn wir variantConfiguration und apkData überprüfen, bevor und nachdem wir den Versionscode überschreiben:

Wir werden sehen, dass der Wert in der Ausgabe apkData geändert wurde, obwohl der ursprüngliche Wert in variantConfiguration gleich bleibt (wie erwartet):

Wie in dieser Ausgabe angegeben, wird dies absichtlich aus Leistungsgründen gemacht.

Fazit

Seien Sie vorsichtig, wenn Sie setVersionCodeOverride verwenden, da Sie möglicherweise unterschiedliche Versionscodes in BuildConfig und AndroidManifest haben.

Auch laut Dokumentation ist der empfohlene Weg, um den Versionscode zu überprüfen, der Zugriff über den PackageManager, nicht über BuildConfig:

Noch besser ist es, die Versionslogik außerhalb von build.gradle zu haben und sie über Gradle-Parameter von der CI bereitzustellen.

Auch ist es eine kluge Entscheidung, sich in der Codebasis nicht zu sehr auf BuildConfig.VERSION_CODE zu verlassen. Für Migrationsfälle ist es besser, eine eigene lokale Versionierung einzuführen (wie es mit SQL-Datenbanken gemacht wird).

Happy Coding!