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.

    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: 32

    Wherein:
    $ 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.java

    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?

    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 copy

    Those. if I run 'svnversion' in my working copy, then this result will appear:
    $ svnversion
    32:46

    And if you also modify some file, then:
    $ svnversion
    32:46M

    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.

    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 tagin the .project file ). Next, modify the .project file - after the tag add the script below:
    org.eclipse.ui.externaltools.ExternalToolBuilderfull,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).

    Also popular now: