I can shed some light. The code for it is here: https://github.com/apache/cordova-android/blob/master/bin/templates/project/build.gradle#L178
There are two times we fiddle with it: 1 - When building multiple architectures (cough crosswalk cough) 2 - When a minSdkVersion is set. Play store requires that each architecture-dependent .apk has a unique versionCode, so that's why we do that. Play store also requires that when using multiple apks, apks with a higher minSdkVersion have higher versionCodes. https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview outlines instructions for building multiple apks: Install xwalk and run: cordova build --release Uninstall xwalk and run: cordova build --release -- --minSdkVersion=21 This gives three apks where versionCode is bigger in the right cases. The reason to not want xwalk for 21 is that it has an updating webview anyways. So, where I was seeing downgrade happen a lot was when going back and forth between xwalk and system webview. Sad that adb can't just deal with it on older devices :S. I think it's fine to just remove the -d flag as you've done. On Tue, Jun 2, 2015 at 11:01 AM, Joe Bowser <bows...@gmail.com> wrote: > I just fixed CB-9080 by removing the fix for CB-8834, since I consider > VERSION_DOWNGRADE to be easily worked around while not launching the > application on older devices is an unacceptable fail state. > > The thing is why is VERSION_DOWNGRADE happening in the first place, and why > are we generating the versionCode? This code should be linear every time > you actually release something to the play store, and otherwise should stay > the same. I know there was a bunch of messing around with it to sync it to > whatever Apple does, but I don't know if that's the right approach here. > > See this form more info on versioning: > http://developer.android.com/tools/publishing/versioning.html > > Can anyone explain more about why we're generating the versionCode the way > we are right now? >
