Update: You can specify this by modifying
.build. I’ve written about this here.
When you upload your APK to Google Play, and then later you need to upload a newer version, you may run into (I did) a mysterious error that
app version must be greater than X for some arbitrary version
X that you previously uploaded for that app.
It turns out that the
android:versionCode which gets put into the generated
AndroidManifest.xml takes it’s value from the
.build file. I have some beef with this:
- It’s not documented or described anywhere.
- It’s arbitrary. If you clean or delete
export and rebuild, it resets to
Today, the project configuration (
Project.xml) allows you to specify the following attributes on the
version (eg. 1.0)
Could you please add a version code attribute?
I don’t know if there’s a way to generate a consistent version code that doesn’t get cleaned/reset.
If you override AndroidManifest.xml, you’ll be able to set it to whatever you need.
To pass custom values to templates, put
<env name="VAR_NAME" value="123" /> in project.xml, and put
::ENV_VAR_NAME:: in your template file.
I know about overriding the manifest. I consider it a fragile (tightly-coupled) work-around, because new versions of OpenFL could always end up generating different (better) manifest files, and I would be stuck with a snapshot of an older manifest.
Besides, why would I want to override and keep a copy of the whole file, when I really just need one property changed? I can already change everything else I need for publishing to Google Play, by changing the project XML file.
Then make your desired changes to the template (and/or ProjectXMLParser), and submit a pull request.
I believe many platforms have the concept of a build ID, which a universal integer value, which is used as the “true” version value, rather than the string “version” value which the user will see.
If you have recommendations for improving how this is handled, I’m open to it. It’s a tricky thing to decide how to balance between something that will be seen (and committed to version control) or not.
It should not be removed on a
-clean build, but it would be removed if you delete your output directory. Perhaps it could be saved alongside the project file, but I think it was moved to make it less visible.
You can do
<app build="" /> to force a build number, but this is not currently recommended
@singmajesty are you suggesting that the
.build file should be checked in? If that’s the case, why is it in the
If you are willing to change anything, I would suggest:
- Put the
.build file with the project config (
- Document, somewhere, how to control/specify the Android build version
I intend to write a blog post about this shortly; how would I go about getting my blog listed under the “Learning” link on openfl.org?
add build-number in meta tag
meta title=“未命名” package=“a.b.com” version=“1.0.0” build-number=“1” company=“a.b.com” if=“android”
I think I put the .build in the same directory as the project.xml originally, or perhaps used the same name, but with the .build value (such as project.build or project.xml.build), but I got a lot of feedback (if I recall properly) of “What is this file?” and “How do I get rid of it?” and it was sometimes funky when using an editor such as FlashDevelop, that shows the file disappearing or appearing.
Then again, perhaps that was all before I treated it as a hidden file. I don’t think it’s flagged as hidden on Windows, but it could be. Another possible idea (under the export directory would be my first thought) is a more generic “properties” system that could save the build file data, as well as other build properties that might make sense to dynamically perpetuate between builds.
My suggestion is to make it optional: if the developer moves the .build file to the project root, keep it there. But if it isn’t there, default to the export folder.
This will allow people who care to keep it around, while everyone else continues as normal.
I hope this thread, and my blog post on this topic, will serve as sufficient documentation/warning to future developers.
My recommendation to OpenFL consumers @singmajesty is to leave the
.build as-is (don’t check it into source control), but manually change the number to something sufficiently higher if you run into a situation where you can’t publish a newer version of your app.
I’ve tried this
<app build="" /> but it seems this doesn’t work
@JeriX Are you trying to specify the version code? You need to update the
.build file as mentioned in my blog post.
I can’t use
.build file because I’m working on different machines.
But after @singmajesty mentioned this:
I thought maybe I can override
versionCode without overriding
@JeriX why don’t you just commit it to version control then and synch it across machines?
I’ve found this line in lime sources:
case "title", "description", "package", "version", "company", "company-id", "build-number", "company-url":
build-number attribute of
meta tag and it worked perfectly
@singmajesty can you please explain why using
build-number is not recommended?
Because you want your build number to increment over time, not remain static.
Most of the dev time I don’t need it to increment. And when I realy need it to be larger I also need it to refer special git commit. That’s why I made simple bash script that reads current rev count from git repo and updated project xml build-number with it through
You can also do
openfl test linux --meta-build-number=123 or what-have-you. This can be done more easily through a script, I think, than accessing the actual XML (and doesn’t trigger a change to be committed in GIT)