In my Android app I:
generate an incrementing build number (integer) using a script as part of my build (uses Integer from SVN revision)
I generate an Android resource file with it defined as an integer:
399
I show that on the UI using the resource generated above
I reference the integer in the Manifest for the versionCode element
All that works fine, but when I attempt to upload to Market I get this error:
"The file is invalid: ERROR getting 'android:versionCode' attribute: attribute is not an integer value "
Question:
For Market, does the versionCode have to be a "literal" integer directly inside the manifest, or is there some way to reference an externally generated integer and not be touching my manifest all the time (manually or automatically).
thanks
(BTW: I have just realized that scheme might cause me issues with patch releases, so I will probably generate a bigger number or something, but would still like the answer to this question)
In the end, this is what I have done:
I create a tag in my version control system with the numbe rof the release in this format
X.YY.ZZ where they are all integers, like 1.20.00, and reserve the last two digits for unplanned patch releases maybe made on a branch after a later release is made....
So if I release 1.20.00 then 1.23.00, I can still go back and do a patch release to 1.22.00 called 1.22.01.
I have a build step that gets the tag name and generates a string resource "1.22.00" for Android that I use in the UI. It also generates it as a number 12200 and I use this as the version number.
BUT, I don't try and include this version number directly in the manifest, I set it for the package by setting an ant property for version code that the ant build picks up if defined and uses to create the .apk.
So I get an always increasing integer for Android Market, but a user with an older version can install a patch release, but you cannot install a patch release if you have a newer official release.
i.e. if you have 1.20.00 you can install patch 1.20.01, but if a user has moved onto 1.23.00 they cannot install the 1.20.01 patch...
To set the property you can use;
project.setProperty("version.name", versionName);
project.setProperty("version.code", versionCode);
if those properties are set, then the Android build system (both old and newer) will pick-up the property value and use it, no need to do anything else special.
Just make sure you set it using one of the pre-build/pre-compile ant extension points.
In the new build system (Platform Tools >= 12) in custom_rules.xml I have added
<project name="custom" default="help">
<import file="build_info.xml" />
<target name="-pre-build" depends="build-info" />
</project>
where build_info is my own ant project that calculates the version name/number from the Tag name (if you are building in a tag....).
From everything I've read, Google Play currently requires android:versionCode to be a 32-bit integer, not a resource. Like you, I also initialize android:versionCode with an #integer resource.
To work around the market's limitation, our build script parses the #integer value and injects it directly into android:versionCode for release builds. This was a simple solution for us. There's far more involved ways to achieve this using ant.properties and the build.xml -pre-build option, however, that is beyond my needs.
For more on that, see:
Reference an integer resource for Android manifest versionCode
https://groups.google.com/d/msg/android-developers/1dt0yxyNPsk/c9c6PlG84iwJ
Related
I pushed the android mobile app (developed by Xamarin.Forms using PCL) with the following info on manifest:
I need to push next version, is that enough to update the following image on manifest?
Example:
Version Number: 2 Version Name: 1.0.1
Yes that is basically enough. But the "Version number" for android must be an integer.
versionCode — An integer used as an internal version number. This
number is used only to determine whether one version is more recent
than another, with higher numbers indicating more recent versions.
This is not the version number shown to users...
So just increase your "Version number" (+1) everytime you want to release your app and the playstore knows, that the version changed.
And for "version name":
versionName — A string used as the version number shown to users. This
setting can be specified as a raw string or as a reference to a string
resource.
You can find detailed informations on the android developer page.
For Xamarin.Forms I recommend you to change also the version in the AssemblyInfo.cs - files in your projects (you can find those file in te Properties-Section):
[assembly: AssemblyVersion("1.0.1.0")]
[assembly: AssemblyFileVersion("1.0.1.0")]
This changes are not required, but with this changes, the assembly itselfs knows, that something changed (usefull for building, version check, and so on)
We have a unique situation where we are deploying a Xamarin.Android app to China to 33 app stores. Hence, our solution has 33 application projects, and we setup Jenkins (running on Windows) to package and sign all our apks (otherwise it would be crazy to make builds).
We also need to modify android:versionCode and android:versionName in the manifest file, by using the ${SVN_REVISION} value from Jenkins. Is there a way to pass these values command line to MSBuild?
Normally we would hand edit this value, but it's not possible because of so many application projects.
Our build parameters right now look like this in Jenkins:
/p:Configuration=Release;AndroidKeyStore=True;AndroidSigningKeyStore=ourkeystore.keystore;AndroidSigningStorePass=ourpassword;AndroidSigningKeyAlias=ouralias;AndroidSigningKeyPass=ourpassword /t:SignAndroidPackage
Add this to the end of your *.csproj file, before the ending </Project> tag:
<Target Name="BeforeBuild" Condition=" '$(JENKINS)' == '1' ">
<XmlPoke XmlInputPath="Properties\AndroidManifest.xml" Namespaces="<Namespace Prefix='android' Uri='http://schemas.android.com/apk/res/android' />" Query="manifest/#android:versionCode" Value="$(SVN_REVISION)" />
<XmlPoke XmlInputPath="Properties\AndroidManifest.xml" Namespaces="<Namespace Prefix='android' Uri='http://schemas.android.com/apk/res/android' />" Query="manifest/#android:versionName" Value="2.0.$(SVN_REVISION)" />
</Target>
I have Jenkins configured to pass JENKINS=1 and SVN_REVISION. When it goes to build, it modifies AndroidManifest.xml before the build.
I don't know if this will work on xbuild on a Mac or not, depends on if XmlPoke is implemented. I should do a blog post on this.
No. You'll have to manipulate the android:versionCode and android:versionName yourself. Personally, I use a rake task to handle this particular detail.
I have an XML file that contains some config data for my Android App. In it there is config info that can be used for development and production. E.g. the link to our api can be set as follows:
For production:
<api>api.example.com</api>
For development:
<api>dev.example.com</api>
I keep this config file under /assets/app-config.xml
It is quite a hassle to keep having to remember which setting I have in the XML. Is there a way to automatically configure eclipse/ android so that it uses the production for runtime (export etc.) and the development when in debug mode.
Define multiple resources and use BuildConfig.DEBUG to conditionally get a resource or another:
<string name="url_api">api.example.com</string>
<string name="url_api_dev">dev.example.com</string>
When extracting the resource:
getString(BuildConfig.DEBUG ? R.string.url_api_dev : R.string.url_api);
This constant is set to true as long as you run from Eclipse. When you select the Export Signed Application Package option, it will be set to false.
If you use this method, it is a good idea to be aware of this bug.
Customize your build using ANT
Please refer the following link for more information
http://playaprogrammer.blogspot.com/2013/01/android-build-configuration-tutorial.html
I use this to create test and production builds from single source. You can have different configurations for development, QA, Production...
I've started getting a weird error message when trying to upload a playbook app update to BlackBerry world. I think this problem started after installing version 1.6.1 of their eclipse plugin.
The error message:
"The package version in your .bar manifest file for signals_playbook must be greater than the previous version, but lower than any the next release version added to the vendor portal. . Your .bar manifest file package version must be greater than 3.0. Correct your .bar manifest file and try again to continue."
My AndroidManifest.xml contains:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="ca.rcp.mobile.cror.signals"
android:versionCode="7"
android:versionName="3.1" >
The Manifest file contained within the BAR shows this info:
Archive-Manifest-Version: 1.1
Archive-Created-By: Apk2Bar version 1.6.1
Package-Author: xxxxxxxx
Package-Author-Id: some hash xxxxxxxxx
Package-Name: xxxxx.cror.signals
Package-Id: some hash xxxxxxxxx
Package-Version: 1.0.7.1
Package-Version-Id: some hash xxxxxxxx
Package-Type: application
Package-Architecture: armle-v7
Package-Author-Certificate-Hash: some hash xxxxx
Application-Name: Railway Signals
Application-Id: some hash xxxxxxxx
Application-Version: 1.0.7.1
Application-Version-Id: some hash xxxxxxxxxxx
Application-Requires-System: Tablet OS/2.0.0.7109
My system:
Windows 7 x64 using Eclipse 3.7.2 with latest ADT and updates.
I can see why BlackBerry world is complaining, it thinks the version number is 1.0.7.1. How do I get it to show 3.1.0.0??
I tried editing the manifest file contained within the bar, saving it and resubmitting. But that didn't work (didn't think it would but was worth a try).
Does anyone know where is the 1.0.7.1 coming from?
Can I override it?
Thanks
Rob
We suddenly started having the same problem with our builds. Evidently something changed in the BlackBerry build tools. Try setting the application's android:versionName attribute to a 4-part value (such as 3.1.0.1). BlackBerry has always used this format (major.minor.micro.build) for native apps. It seems that unless your Android manifest has the same format, the BlackBerry build tools fail to parse the versionName attribute and use a fall-back. From what I can tell, the fall-back is to use the value of android:versionCode as the micro version in a default application version code; that is it sets the app version in the .bar file manifest to
1.0.<android:versionCode value>.1
(I sure wouldn't want to be the engineer that had to defend implementing this behavior.)
An alternative approach is to create a custom manifest file that has the app version you want. Create a file named MANIFEST.MF in the same directory as AndroidManifest.xml. Then add the specific .bar manifest entries you want. For instance, it might be:
Archive-Manifest-Version: 1.1
Package-Version: 3.1.0.0
Application-Version: 3.1.0.0
Then open the project properties in Eclipse, navigate to BlackBerry, and for the "Custom BAR Manifest" drop-down, select "Add custom values (merge)".
Thank you, Ted!
There is another link on this topic;
http://supportforums.blackberry.com/t5/BlackBerry-World-Development/The-package-version-in-your-bar-manifest-file-for-New-Bundle/td-p/2754567
We started to notice problem after move to Gradle:
Before
AndroidManifest.xml:
android:versionCode="1312310309" android:versionName="2.28.4"
MANIFEST.MF:
Application-Version: 14.1231.309.0
After
AndroidManifest.xml:
android:versionCode="134" android:versionName="2.30.31402271059"
MANIFEST.MF
Application-Version: 1.0.134.0
I also had the same problem but I fixed it by adding this line in my Android Manifest file android:versionCode="30" previously I had android:versionCode="29" so upgraded it by one .And the problem got fixed for me.
i'm trying to get android running on a gumstix overo system.
since i'm not planning to use the final "product" as a phone, i asked my self if it is possible to exclude applications like the phone/dialer-app from the kernel build-process (any config parameter probably?)
Just remove (or comment) these lines:
<project path="packages/apps/Phone" name="platform/packages/apps/Phone" />
<project path="packages/apps/VoiceDialer" name="platform/packages/apps/VoiceDialer" />
(and others if needed) from the platform manifest (default.xml) :
https://android.googlesource.com/platform/manifest/+/master/default.xml
Removing the app declarations in the repo manifest did not work for me, as there are other libraries that reference them that then fail to compile. The build system approach to this problem is to create/modify your product definition makefile to not include the specific apps.
So, for the overo you probably already have a products/overo.mk product file. You can manually set the PRODUCT_PACKAGES variable to which applications you want to ship. You will also want to take a look at the PRODUCT_POLICY variable, as it defines sets of applications for your product type.
It can take some fiddling to get everything to build correctly, due to interdependencies between applications, but the Android build output does a pretty good job of explaining the problems when they arise.