Android Version Code Tricks

Să încercăm această opțiune. Mai întâi vom configura aplicația și vom furniza 1 ca versionCode implicit și îl vom suprascrie la 2 pentru toate variantele de ieșire:

Dar apoi, dacă ne uităm în interiorul fișierului BuildConfig vom vedea că codul de versiune este încă setat la 1. Deși dacă ne uităm în AndroidManifest rezultat vom vedea codul de versiune setat corect la 2.
Bug sau caracteristică? Haideți să aflăm ce se întâmplă.

În interiorul codului putem accesa codul de versiune din BuildConfig.VERSION_CODE sau din PackageManager.packageInfo.versionCode:

După ce vom rula codul în Logcat vom vedea exact ceea ce am observat mai sus:

Motivul pentru care se întâmplă acest lucru este că în instrumentele de construcție Android Gradle există două sarcini separate pentru generarea fișierului BuildConfig și pentru procesarea AndroidManifest.

Dacă ne uităm în GenerateBuildConfig vom vedea că proprietatea VERSION_CODE este generată din metoda getVersionCode():

Și că getVersionCodese referă la valoarea stocată în variantConfiguration:

În comparație cu generarea BuildConfig în ProcessApplicationManifest, vedem că codul de versiune este preluat din apkData.

Dacă verificăm variantConfiguration și apkData înainte și după ce am stabilit suprapunerea codului de versiune:

Vom vedea că valoarea din apkData de ieșire a fost modificată, deși valoarea originală din variantConfiguration rămâne aceeași (așa cum era de așteptat):

După cum se menționează în această problemă, se face în mod intenționat din motive de performanță.

Concluzie

Aveți grijă dacă folosiți setVersionCodeOverride, deoarece este posibil să aveți coduri de versiune diferite în BuildConfig și AndroidManifest.

De asemenea, conform documentației, modalitatea recomandată de verificare a codului de versiune este să îl accesați prin PackageManager, nu prin BuildConfig:

Mai bine este să aveți o logică de versionare în afara build.gradle și să o furnizați prin parametrul gradle de către CI-ul dumneavoastră.

De asemenea, este o alegere înțeleaptă să nu vă bazați prea mult în baza dumneavoastră de cod pe BuildConfig.VERSION_CODE. Pentru cazurile de migrare ar fi mai bine să introduceți propria versiune locală (așa cum se face cu bazele de date SQL).

Codificare fericită!