New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

android:versionCode appended with '8' if numeric, is '28' if specified as string #7205

Closed
kokokenada opened this Issue Jun 13, 2016 · 10 comments

Comments

Projects
None yet
7 participants
@kokokenada

kokokenada commented Jun 13, 2016

In version Meteor 1.3.2.4, running OSX, building Android with "meteor build" CLI command.

In mobile-config.js, if you specify App.setPreference('android:versionCode', 3), the version reported in the .apk file and the release-build/android/project/build/intermediates/manifests/full/release/AndroidManifest.xml, the android:versionCode is 38, not the expected 3. If you specify the App.setPreference('android:versionCode', '3'), (as string instead of a number) the output is 28.

@laosb

This comment has been minimized.

Collaborator

laosb commented Jun 13, 2016

That sounds strange.

@kokokenada

This comment has been minimized.

kokokenada commented Jun 13, 2016

Strange indeed. When I ran into the problem, I searched and found forum post (https://forums.meteor.com/t/issue-wrong-android-versioncode-in-meteor-run-and-build/24015), so others (or at least another) have had this problem.

@joaopiopedreira

This comment has been minimized.

joaopiopedreira commented Jun 13, 2016

I can confirm that this is happening to me too (Meteor 1.2.1 here), although it's not a blocker. Would be nice to have it sorted though.

João Pio Pedreira
/// Sent from a mobile device ///

On 13 Jun 2016, at 01:13, kokokenada notifications@github.com wrote:

In version Meteor 1.3.2.4, running OSX, building Android with "meteor build" CLI command.

In mobile-config.js, if you specify App.setPreference('android:versionCode', 3), the version reported in the .apk file and the release-build/android/project/build/intermediates/manifests/full/release/AndroidManifest.xml, the android:versionCode is 38, not the expected 3. If you specify the App.setPreference('android:versionCode', '3'), (as string instead of a number) the output is 28.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@abernix abernix added Impact:some and removed Impact:few labels Jun 28, 2016

@johnthepink

This comment has been minimized.

Contributor

johnthepink commented Jun 28, 2016

This has been happening to me since at least November 2015. I am setting the build number in mobile-config.js. This is a screenshot from Hockey, the build number was 10, and it became 108 after a meteor build

screenshot 2016-06-28 15 12 51

@abernix

This comment has been minimized.

Member

abernix commented Sep 16, 2016

I'm inclined to believe that this is a problem (or something happening in) Cordova itself as Meteor does practically nothing with the version code besides stick it into the config.xml that Cordova uses.

The typical way to set the android-versionCode (and ios-CFBundleVersion) is by setting buildNumber in the mobile-config.js (with App.info, not setPreference) before building the bundle.

I'm curious if any of you could attach the contents of your .meteor/local/cordova-build/config.xml file after a build to see what Cordova received from Meteor.

@jackkav

This comment has been minimized.

Contributor

jackkav commented Nov 24, 2016

This is fixed in the new cordova-lib update it appears, and can cause the android app install to fail to update from the old version. Requiring a uninstall of the old app, or as a better solution setting buildNumber to 108 in the mobile-config.js
For example:
My android build version is not set in mobile-config.js, so my version is 0.0.1 therefore my automatically generated versionCode is 108 because of the cordova-lib bug, (fixed in 1.4.2).
So I update meteor from 1.4.1.1 to 1.4.2.3 and the number is generated again but without the bug to 10 rather than 108. Since the android apk install no longer force installs with the -d flag, it will follow the android rules of prevent an install of a lower build version and installing over the old version will fail with no error on the device.
To find this error we need to use adb logcat with the android device plugged in. Hardly a fail loudly kind of error, and as such could do with being noted somewhere.

Can't install update of com.myapp update version 10 is older than installed version 108

I would recommend adding a reference either to this issue or a description in the 1.4.2 History.md for others trying to figure out what could prevent the installing over an old version when updating meteor to 1.4.2. Just after this:

The cordova-lib npm package has been updated to 6.3.1, along with cordova-android (5.2.2) and cordova-ios (4.2.1), and various plugins.

The cordova-lib changelog isn't on github and isn't easy to read, so here's hoping this comment at the very least helps someone else who suddenly can't update an android device from 1.4.1 to 1.4.2

apache/cordova-android@9224ab1

@abernix

This comment has been minimized.

Member

abernix commented Nov 24, 2016

@jackkav Thanks so much for following up on this and providing this information.

First, it appears that this was never really a "bug", but more of an intentional way to fix (something for) non-multiarch builds. The change which is removing that functionality is here: apache/cordova-android@dc57941 and you'll see some of the comments confirming that it's a breaking change.

Briefly and paraphrased from the other issue:

It is best if you manage your buildNumber manually. If you read the Cordova source code (apache/cordova-android@dc57941) you might understand better. If you provide buildNumber yourself using Meteor 1.4.2 or higher (which was upgraded for Cordova 6.2) you will avoid all the extra changes that Cordova tries to intelligently make and it will just use your version.

I don't know if there is any good recommendation here aside from "you should set buildNumber". As you'll see in that Cordova commit, there are still changes being made to the build number in some cases (i.e. multiplying by 10). It seems like no matter what Meteor does, there may be problems if you're not setting it yourself.

This issue (and the other) may be helpful enough for those experiencing problems, but I think the suggestion for the History.md might be a good idea. Maybe the wording should be something along the lines of:

Due to changes to how Cordova generates version numbers for iOS and Android apps, you may experience issues with apps updating on user devices. To avoid this, consider managing your buildNumber yourself using App.info('buildNumber', 'XXX'); in mobile-config.js. There are additional considerations if you have been setting android:versionCode or ios-CFBundleVersion so see #7205 and #6978 for more information.

I don't know that this problem will affect everyone though and don't want to make this sound too scary. Thoughts?

@jackkav

This comment has been minimized.

Contributor

jackkav commented Nov 24, 2016

Thanks @abernix for the follow-up. It will only affect those coming from <1.4.2 with no buildNumber manually set and android apps in production. I would imagine those few would appreciate the above warning, before they make the update to 1.4.2. As an aside it I would imagine the android app store will not accept publishing an apk update with a lower build number, but since we aren't using the app store for our production app that may explain why we are getting blocked by this issue while other aren't.

@hwillson

This comment has been minimized.

Member

hwillson commented Feb 17, 2017

Hi guys - I think adding that warning to the History.md makes sense (with a few slight modifications based on #7205 (comment)). Should we move ahead with this to get this issue closed? Happy to submit the change if we're all in agreement. Thanks!

abernix added a commit that referenced this issue Feb 17, 2017

Update the 1.4.2 release notes to clarify Cordova `buildNumber` changes.
Cordova was updated to 6.2.0 in Meteor 1.4.2 and Cordova (itself) changed the way the `buildNumber` was generated.  Some users experienced problems with the various app stores having version number clashes due to this change but Cordova insists it was mandatory.

This was brought up in a discussion on #7205.

Resolves #7205
@abernix

This comment has been minimized.

Member

abernix commented Feb 17, 2017

Thanks for reminding me (And offering), @hwillson. I had forgot about this.

I opened #8390. :)

abernix added a commit that referenced this issue Feb 22, 2017

Update the 1.4.2 release notes to clarify Cordova `buildNumber` chang…
…es. (#8390)

* Update the 1.4.2 release notes to clarify Cordova `buildNumber` changes.

Cordova was updated to 6.2.0 in Meteor 1.4.2 and Cordova (itself) changed the way the `buildNumber` was generated.  Some users experienced problems with the various app stores having version number clashes due to this change but Cordova insists it was mandatory.

This was brought up in a discussion on #7205.

Resolves #7205

abernix added a commit that referenced this issue Mar 1, 2017

Update the 1.4.2 release notes to clarify Cordova `buildNumber` chang…
…es. (#8390)

* Update the 1.4.2 release notes to clarify Cordova `buildNumber` changes.

Cordova was updated to 6.2.0 in Meteor 1.4.2 and Cordova (itself) changed the way the `buildNumber` was generated.  Some users experienced problems with the various app stores having version number clashes due to this change but Cordova insists it was mandatory.

This was brought up in a discussion on #7205.

Resolves #7205
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment