Opened 6 years ago
Closed 6 years ago
#13246 closed Bug Report - General (fixed)
Add Real versionName and versionCode to Android Package
Reported by: | gigem | Owned by: | Mark Spieth |
---|---|---|---|
Priority: | minor | Milestone: | 30.0 |
Component: | Ports - Android | Version: | Master Head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
In the Android package, the versionName is currently set to 1.0 and the versionCode is set to 1. The attached patch adds the real versionName to the package and adds a place holder versionCode. Suggestions on what to use for the versionCode are welcome. Some texts suggest <major> * 10000 + <minor> * 100 + <patch>. Currently, MythTV only uses <major> and <minor>.
Note that the patch assumes that android-package-source/AndroidManifest.xml is already git mv'd to android-package-source/AndroidManifest.xml.in. This is to avoid editing the source controlled, input version.
Attachments (3)
Change History (12)
Changed 6 years ago by
Attachment: | android-version1.patch added |
---|
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
I didn't see any requirements for versionName, though, I didn't really look. I got the impression the versionCode is what really matters to to Google and the Play Store. It's requirement is to be monotonically increasing.
Hmm, our package isn't that much larger than Kodi and that's with debug enabled. I suspect it could be considerably smaller with --comppile=type=release.
Okay. It's easy enough to move AndroidManifest?.xml.in elsewhere.
comment:3 Changed 6 years ago by
Replying to gigem:
Suggestions on what to use for the versionCode are welcome. Some texts suggest <major> * 10000 + <minor> * 100 + <patch>. Currently, MythTV only uses <major> and <minor>.
I think we have to create multiple application names - MythTV29, MythTV30, MythTV31 etc., because we cannot expect everybody to be on the latest version.
That said, the version only has to be unique within MythTV30, MythTV31, etc.
Possibilities
- date and time built - yyyymmddhhmmss
- minor version code number * 1000 plus additional commit number from git describe. Minor version code number will have to be something like this
- "-pre" = 00
- "-rc1" = 01
- "-rc2" = 02
- ".0" = 10
- ".1" = 11
- ".2" = 12
Examples of second method
- v30-Pre-543-g697bf77 = MythTV30 version code 00543
- v29.1-9-g67e8d62 = MythTV29 version code 11009
comment:4 Changed 6 years ago by
I believe the versionCode is only really needed for apps distributed through the Play (or other) Store. I don't know what Google's requirements are beyond it being "monotonically increasing". I have doubts, however, that having a separate app, each with it's own versionCode space, would be acceptable.
Anyway, I think I'm going to punt on this issue for now by hardcoding the versionCode in mythtv/VERSION. We can address this issue when/if we ever try to get the app into the Play Store.
Changed 6 years ago by
Attachment: | android-version2a.patch added |
---|
Changed 6 years ago by
Attachment: | android-version2b.patch added |
---|
comment:6 Changed 6 years ago by
- (2a) Perhaps it would be better to add MYTH_ANDROID_VERSION_CODE on the build command line (-D) so that it can be managed in the build system instead of the code, just like other packaging systems. Not sure of the consequences.
Otherwise looks good.
comment:7 Changed 6 years ago by
Since, AIUI, the versionCode is mainly for released versions, I wanted to put it as close to the real version handling as possible. However, our version name/number handling isn't terribly clear, so I just stuck it in mythversion.h for now. I don't feel strongly about it either way except that it should handled in such a way that isn't easily forgotten to be updated or used.
comment:8 Changed 6 years ago by
I don't know either. I just don't like versions in code.
Whatever you think is good enough.
comment:9 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'm not sure what the requirements are for versioning in submission to the play store. This may need to be researched.
OT: It is also a large apk compared with most and there is some text somewhere that says it may be too large.
Otherwise it looks ok. You cant have the .in file in android-package-source as it will deploy it too. Need a different tree for that.