There is an undocumented change to version code handling by the Crosswalk and Android build systems based on Cordova CLI 5.1.1. This change was implemented by the Apache Cordova project. This new version of Cordova CLI automatically modifies the android:versionCode when building for Crosswalk and Android. Because our CLI 5.1.1 build system is now more compatible with standard Cordova CLI, this change results in a discrepancy in the way your android:versionCode is handled when building for Crosswalk (15) or Android with CLI 5.1.1 when compared to building with CLI 4.1.2.
If you have never published an app to an Android store this change should have little or no impact for you. This change might affect your attempts to side-load an app onto a device, in which case the simplest solution is to uninstall the previously side-loaded app before installing the new app.
Here's what Cordova CLI 5.1.1 (Cordova-Android 4.x) is doing with the android:versionCode number (which you specify in the App Version Code field within the Build Settings section of the Projects tab):
Cordova-Android 4.x (Intel XDK CLI 5.1.1 for Crosswalk or Android builds) does this:
then, if you are doing a Crosswalk (15) build:
otherwise, if you are performing a standard Android build (non-Crosswalk):
If you HAVE PUBLISHED a Crosswalk app to an Android store this change may impact your ability to publish a newer version of your app! In that case, if you are building for Crosswalk, add 6000 (six with three zeroes) to your existing App Version Code field in the Crosswalk Build Settings section of the Projects tab. If you have only published standard Android apps in the past and are still publishing only standard Android apps you should not have to make any changes to the App Version Code field in the Android Builds Settings section of the Projects tab.
The workaround described above only applies to Crosswalk CLI 5.1.1 builds!
When you build with CLI 4.1.2 (which uses Cordova-Android 3.6) you will get the old Intel XDK behavior where: 60000 and 20000 (six with four zeros and two with four zeroes) are added to the android:versionCode for Crosswalk builds and no change is made to the android:versionCode for standard Android builds.
thank for making it stick post i have question will adding 6000 will fix issue , as crosswalk generated multiple apk with versions like 6000, and 2000
will adding 6000 still give multiple apks with 6000+ and 2000+ values
Here's a scenario to make it easier to understand what will happen:
Notice that you do not get the 60000 and 20000 pattern you got with the previous build system, but you will get two versionCodes that are greater than the previously built versionCodes so both will be accepted into the store as "newer" than the previous entries; and the x86 versionCode is higher than the ARM versionCode, which is necessary to insure the x86 APK gets delivered to x86 devices and the ARM APK gets delivered to ARM devices.
Of course, if you insert those CLI 5.1.1 built APKs into the store and then decide to go back to using CLI 4.1.2 for a future build, you may want to make adjustments to your versionCode field; you don't have to, but if you plan on going back and forth between both build systems, you might want to. :) If you stick with the CLI 5.1.1 build system, going forward, all you'll have to do is increment your versionCode with each new release (eg., 6004, then 6005, etc.).
The 60000 and 20000 thing was something that our build system added to make the multiple APKs work. The Cordova project did not catch up to what we were doing until their CLI 5 release. Unfortunately, they took a slightly different tactic than ours, thus the reason for the incompatibility. There is no guarantee that they will not change again, but I think the changes they do make, if they do, will be easier to digest in a future release.
Hamilton, if I am reading this correctly (and I don't read Portuguese), there is a known issue with the CW15 build system that it does not properly strip the plugin architecture binaries from the APK -- this issue was fixed for the CW7-14 builds, but is not fixed for the CW15 builds. :( Engineering is working on this issue in the CW15 build system.
Build with CW14 under CLI 4.1.2 and you should get the correct results. The problems with the CW7-14 builds were resolved a few days ago, so they are now usable. I believe you're using the SQLite plugin, correct? If so, it is using native libraries in the plugin, thus the reason for this problem.
I'm curious how your prior builds are able to be marked with an API level of 10? What version of Crosswalk did you build those September 23 versions of your apps with?
@Paul> Sorry for the image in Portuguese...
Reading your information, I am trying just now to downgrad to CLI 4.1.2 and CW 14. I need to test everything again. The app was running very well with CLI 5.1.1 and CW 15! I hope that everything is OK, because I need to publish the new version of this app. Do you think that the new version with corrections about this issue will be released soon?
Yes, I am using SQLite plugin for a long time. All my apps use this. And all my apps I set to 10 as minimum version of Android. Just this last one that I changed to 14 according the instructions.
@Paul> bad news...
Changing to CLI 4.1.2 and CW 14, I received a message about downgrade of some plugins (see image 1). I accepted to continue.
After that, o ask to build. Now, there is a error with barcodescanner (version 4.0.2). See image 2.
I tryied again with 4.0.1 and I received the same error. Again with 3.1.2... to 3.0.0...
What happens if I return to CLI 5.1.1 and CW 15 and publish only APK? There is any problem, now or in the future?
My users of this app are very especific (less than 100 on Android). When the issue is corrected I create another version with 2 APKs? What do you think about this option?
Hamilton, using API level of 10 with Crosswalk builds means "I can install on an Android 2.x and 3.x" -- which is not true. If someone tries to run a Crosswalk build on something earlier than Android 4.0 it will fail (I think it crashes, but I'm not sure). Regardless, that's a minor issue. The current build system now prevents that condition.
It looks to me like you're running into some project file corruption issues that we've been experiencing with this release. There is a hotfix that is being released today, I still do not see it in the download, but that version will fix some of these project file corruption issues (although it may require creating a new blank project and copying your stuff into that).
Regarding moving back to CW15, you won't be able to submit both copies of the APK into the store, but you could publish just the ARM version and get by with that. It would mean that anyone using an x86 device would not be able to run the new version (the new version will download onto their device and install, but it will crash when it starts, because the x86 Crosswalk libraries are missing). If your population of users are all ARM-based devices this temporary fix would work. If you have a bunch of x86 device users, may not be such a good idea.
I recommend that you create a new blank project, set it to CLI 4.1.2 and CW14 and copy all of your existing source files into that new blank project and manually add in your plugins into that new project. Let me know if that gets you back to a working CW14 + CLI 4.1.2 project.
With luck, you should see the hotfix update by the end of day. That hotfix, however, will not fix the problem with CW15...
Renato, since your last version code was 1 and you built with CLI 4.1.2. If you uploaded both of your APKs to the store you would have an ARM copy with version code 20001 and an x86 copy with version code 60001. Based on your response from the Google Play it sounds like you only uploaded the ARM copy to the store (you need to upload both files to the store if you want to insure that your app will run on ALL devices).
Since your last version code was 1, built with 4.1.2, and you now are building with CLI 5.1.1, you need to set your version code to 6001 to insure that the new version code is greater than the old version code. In other words:
See this post for a detailed example (in the example I'm using "3" but in advice above I'm using "1"): https://software.intel.com/en-us/forums/intel-xdk/topic/594778#comment-1842109
@Renato -- yes, if you continue to build with CLI 5.1.1 (or higher) your next version code would be 6002, then 6003, etc. If you switch back to CLI 4.1.2 it gets messy (but can be adjusted). If things are working with CLI 5 I recommend staying there, the Cordova project is quickly moving past their CLI 4.x releases, so it will eventually become obsolete. We are providing it to ease the transition to CLI 5, but expect all users to eventually move to CLI 5.x builds.
Do you have any news about APK serving both ARM and X86? I buided a new version of my APP ConfirmAki PRO (CW15 / Cli 5.1.1) and tried to publish today in Google Play. I received again the same warning (versions 131012 and 131014 are for the same range of devices).
I remember that it is a issue in CW15, not in CW14 or before.
In my last version I published only one APK (final 4). Some customers said to me that, in some devices, after the install it requires a Crosswalk runtimer.
If you have any news, please advice me. Thanks.
@Hamilton -- the problem I believe you are referring to has been fixed. The CW15 embedded builds will now only contain x86 or ARM code, not both. For example, the SQLite plugin includes binary code. That problem is now fixed. I'd like to see a copy of the APK files you built for submission to the store. Can you send me the ZIP you downloaded from the CW15 build? Attach it to a post or send a private message with a link where I can download it.
There is a new feature in the CW15 builds that the Crosswalk team added that will automatically cause the APK to download the shared runtime library if the wrong architecture app is installed onto a device. So that is probably what your customer is reporting. For example, you probably only published the ARM file and they ran it on an x86 device.
@Paul> I sent to you (private) the link to the 2 APKs and 3 Google Play Console images.
The GPC only accept 1 version to publish. The other it considers redundant.
@Hamilton, sorry it has taken so long for me to look at this, I've been busy on a bunch of high priority issues and haven't had much time to spend on forum issues. I inspected your APK files and they both contain both ARM and x86 libs, this is why the Google Play store is complaining, so it is a valid complaint by the store.
However, I did a sample build using the SQLite plugin, and CW15, and the resulting APKs I got did not contain both ARM and x86 libraries. I'm not sure why yours has them and mine does not. Please try the build again and inspect the APKs you get back to see if they contain both sets of libraries or only one set of libraries. If you are able to reproduce this we need to understand why yours has the extra libs and mine does not. My guess is that when you do the build again the APKs will be properly stripped of the excess library files and the store will accept your app.
I followed this advice posted earlier:
Here's a scenario to make it easier to understand what will happen:
Google Play comes back and tells me the version has to be higher than 60034 for the ARM APK. It was fine for the x86.
Here is my build log:
Can anybody look at this and tell me why Google Play doesn't accept 60034? It still says it wants a higher version.
What is the version code that your Google dashboard is currently reporting for the version of the app that is already published in the store? Can you provide a screen shot of the dashboard when you are submitting to the store?