Generation of android application version from subversion and git revision
When users encounter problems, one always wants to know exactly which version of the software they are using. When using the version control system and automatic numbering of software versions, such information can be provided to users, and if necessary, simply ask to dictate a line.
About how you can number your android project is written here and here . Both articles considered an example of obtaining a version of a project using 'svn info', and in the first article, the author complains about the lack of SvnAnt , and in the second article, the author notices a problem related to the use of 'svn info'. The problem is that 'svn info' gives inaccurate information about the revision of the working copy.
The following is an example of a solution to this problem in a fairly simple way.
UPD: added script for git.
The bottom line is that the 'svn info' command issues the last commit revision of the elements of the specified directory.
For instance:
Wherein:
The authors of both mentioned articles interpret the utility output as a regular property-file.
Those. the presence of lines of the Revision: 32 type allows them to interpret the data as parameters in the Build And script. Accordingly, the task becomes much more complicated if you execute 'svn -R info' and look for the latest revision in the output file.
The request 'svn -r HEAD info' gives the revision number on the server and not in the working copy, which is also incorrect, because the main condition is not fulfilled - the generation of the current software version. The arguments BASE, COMMITTED and PREV also do not provide an answer to the question - from which version files is the project built?
I was already ready to abandon the method of obtaining the software version described in the article, but in time I remembered another utility 'svnversion'. The format of data output by this utility is as follows:
Those. if I run 'svnversion' in my working copy, then this result will appear:
And if you also modify some file, then:
Actually, the utility produces useful information that I would like to include in the version of the application, but the data output format is not suitable. I had to figure out a little about the syntax of Build Ant scripts ...
Below are instructions on how to add a working version of a subversion or git to your project.
We create the svn-revision.build.xml file in the root of the project. Paste the following contents into it:
It is understood that AndroidManifest.xml is in the same directory as svn-revision.build.xml . If not, then modify line 22. It is also understood that the version of the application looks like 1.2 or 1.2.3 . If not, modify line 23.
Next, create the .externalToolBuilders / AddSvnRevisionToVersion.launch file and add the following lines to it.
Instead of ANDROID-APP, insert the name of your project (see the value of the tag in the .project file ). Next, modify the .project file - after the tag add the script below:
As a result, the first task will add a process that modifies the AndroidManifest.xml file. The file will be updated whenever build is launched, and the process will be launched whenever the release package is built. If the assembly of the release package is automated or you do not use Eclipse, then you must configure your collector to run svn-revision.build.xml .
To get a similar result when using SCV git, replace the svn-revision.build.xml file with the git-revision.build.xml below .
Accordingly, do not forget to fix the AddSvnRevisionToVersion.launch and .project files .
Now, in order to get the software version, you can use this method:
As a result, in my project I got the line 1.0.32: 46M (subversion) and 1.0.58c57 + (git).
About how you can number your android project is written here and here . Both articles considered an example of obtaining a version of a project using 'svn info', and in the first article, the author complains about the lack of SvnAnt , and in the second article, the author notices a problem related to the use of 'svn info'. The problem is that 'svn info' gives inaccurate information about the revision of the working copy.
The following is an example of a solution to this problem in a fairly simple way.
UPD: added script for git.
Problem
The bottom line is that the 'svn info' command issues the last commit revision of the elements of the specified directory.
For instance:
$ svn info
Revision: 32Wherein:
$ svn info ./src/ru/bsrgin/myproject/MyActivity.java
Revision: 45
$ svn -r 32 -v log
Changed paths:
D /some-folder
$ svn -r 45 -v log
Changed paths:
M /src/ru/bsrgin/myproject/MyActivity.javaThe authors of both mentioned articles interpret the utility output as a regular property-file.
Those. the presence of lines of the Revision: 32 type allows them to interpret the data as parameters in the Build And script. Accordingly, the task becomes much more complicated if you execute 'svn -R info' and look for the latest revision in the output file.
The request 'svn -r HEAD info' gives the revision number on the server and not in the working copy, which is also incorrect, because the main condition is not fulfilled - the generation of the current software version. The arguments BASE, COMMITTED and PREV also do not provide an answer to the question - from which version files is the project built?
Decision
I was already ready to abandon the method of obtaining the software version described in the article, but in time I remembered another utility 'svnversion'. The format of data output by this utility is as follows:
4123:4168 mixed revision working copy
4168M modified working copy
4123S switched working copy
4123P partial working copy, from a sparse checkout
4123:4168MS mixed revision, modified, switched working copyThose. if I run 'svnversion' in my working copy, then this result will appear:
$ svnversion
32:46And if you also modify some file, then:
$ svnversion
32:46MActually, the utility produces useful information that I would like to include in the version of the application, but the data output format is not suitable. I had to figure out a little about the syntax of Build Ant scripts ...
Below are instructions on how to add a working version of a subversion or git to your project.
Sequencing
We create the svn-revision.build.xml file in the root of the project. Paste the following contents into it:
Revision: ${svnversion.Revision} It is understood that AndroidManifest.xml is in the same directory as svn-revision.build.xml . If not, then modify line 22. It is also understood that the version of the application looks like 1.2 or 1.2.3 . If not, modify line 23.
Next, create the .externalToolBuilders / AddSvnRevisionToVersion.launch file and add the following lines to it.
Instead of ANDROID-APP, insert the name of your project (see the value of the tag
org.eclipse.ui.externaltools.ExternalToolBuilder full,incremental, LaunchConfigHandle /.externalToolBuilders/AddSvnRevisionToVersion.launch As a result, the first task will add a process that modifies the AndroidManifest.xml file. The file will be updated whenever build is launched, and the process will be launched whenever the release package is built. If the assembly of the release package is automated or you do not use Eclipse, then you must configure your collector to run svn-revision.build.xml .
Git
To get a similar result when using SCV git, replace the svn-revision.build.xml file with the git-revision.build.xml below .
Revision: ${git.Revision} Accordingly, do not forget to fix the AddSvnRevisionToVersion.launch and .project files .
Getting versionName programmatically
Now, in order to get the software version, you can use this method:
public static getApplicationVersion()
{
try {
return getInstance().getApplicationContext().getPackageManager()
.getPackageInfo(getPackageName(), 0).versionName;
}
catch (NameNotFoundException e) {
return "App not installed!";
}
}As a result, in my project I got the line 1.0.32: 46M (subversion) and 1.0.58c57 + (git).