Android Tools 8.0.1, Eclipse and ANT 1.8.1

First, if you are running android tools 8.0.1 from eclipse than everything works fine. Second, to run build using android tools 8.0.1 or higher outside of eclipse you must use ant 1.8.1 or higher. Most Linux version in theri beta/test repos already have compiled ant 1.8.1 binaries to install to run ant 1.8.1 form the command line.

My AndCooperANT set of build is being kept pre-ADT8, the new ADT8 or higher project is named IndianaANT and will be up in days.

Now for some other good news, it appears that ADT 9.0 may be pushed out December 20th as it fixes some minor bug issues. One of the changes is an ant version check in the custom task.

As far as eclipse, it will not have ant version 1.8.1 until very late in the 3.7 testing cycle and I doubt if eclipse 3.6.2 will include ant 1.8.1. Thus, since ADT 8.0.1 runs fine in eclipse without ant being upgraded in eclipse the best option is update your ant install if you run builds outside of your IDE. If you have not switched your build run outside of IDE to ant 1.8.1 you will notice the side effect of 3rd party libs not being included in the dex and that is due to some behavior changes between ant 1.7.1 and ant 1.8.1.

Android PMD 5

PMD 5 comes with some new additions to the Android Rules and a nice new features in that you can define a rulest and stick outside the pmd.jar unlike PMD 4. Thus for an ANT target you have:

 <!-- PMD -->
			    <target name="pmd" >
			    
                           <pmd rulesetfiles="config/androidrules.xml">
			    	            <auxclasspath>
			    	                <pathelement location="${sdk-android-jar}"/>
			    	                <pathelement location="${out.classes.absolute.dir}" />
			    	                <fileset dir="libs">
			    	                    <include name="*.jar" />
			    	                </fileset>
			    	            </auxclasspath>
			    	            <formatter type="xml" toFile="reports/pmd.xml"/>
			    	            <!-- <ruleset>rulesets/java/android.xml</ruleset> -->
			    	            <fileset dir="${source-folder}" includes="**/*.java" />
			    	        </pmd>
			    	    <xslt basedir="reports" destdir="reports"
			    		style="config/reportconfig/andcooper.pmd.xsl">
			    		<param name="project" expression="${project}"/>
			    		<param name="today" expression="${today}"/>  
			    		<param name="rulesets" expression="android"/>
			    		<mapper type="glob" from="pmd.xml" to="pmd.html"/>
                    </xslt>
			    	
					 
					   <echo>pmd report generated and transformed to html</echo>
				</target>
	

Application JavaDoc

There are some javadoc errors that I see when developers attempt to produce javadoc for an Android application project. One, not specifying the android.jar as a classpath parameter and the second is not specifying what Androdi SDK version in th e footer some place:

<target name="javadoc">
	
		<javadoc sourcepathref="javadoc.source" destdir="javadocs" overview="src/overview.html" classpath="${sdk-android-jar}" private="true" windowtitle="${taglets.windowtitle}" additionalparam="">
					<!-- Use a nice documentation title -->
					   <doctitle>
					     AndroidAppANTBuild&lt;/br&gt;
					     API Specification
					   </doctitle>
					     	 <!-- Create a header that contains the taglets logo -->
					     	   <!-- Note the use of the {@docRoot} tag to link to the logo -->
					     	   <header>
					     	     &lt;img
					     	       src="{@docRoot}/resources/logo.png" 
					     	       width="88" height="40" border="0"
					     	     &gt;
					     	   </header>
					<!-- Same for the footer -->
					   <footer>
					     &lt;img 
					       src="{@docRoot}/resources/logo.png" 
					       width="88" height="40"
					     &gt;
					   </footer>
					   <!-- Include a timestamp at the bottom of the docu generated -->
					   <!-- Note the use of ${timestamp} which was created by the -->
					   <!-- <tstamp> task at the start of this target -->
					   <bottom>
					     &lt;p align="right"&gt;
					       &lt;font class="NavBarFont1" size="-1"&gt;
					   	     Android SDK Verion ${sdk.version}&lt;br&gt;
					         ANdroidAppANTBuild&lt;br&gt;
					         API Spec&lt;br&gt;
					         ${TSTAMP} ${DSTAMP}
					       &lt;/font&gt;
					     &lt;/p&gt;
					   </bottom>
			
			</javadoc>
</target>

Remember, there is no separate javadoc for the SDK online so you really can not use a link parameter and thus identifying the SDK version in footer helps.

Android App Build number

Okay, detiails tonight as far as what ant tasks details to use. But here are the steps:

1. use xpath to read in Andorid.manifest vaules

2 Use propertyfile task to set new build number in a property file

3 read that value and use ReplaceRegEx to change it in the andorid.manifest.

If you want you can eliminate step 2 as you would still be using the xpath values to update your api doc to app version etc.

Android Test Project-ADT0.93-0.94

As you know one of the changes to ADT as far as ADT 0.93 and 0.94 was that the Android Test Project would get its own project folder in the Eclipse workspace. Here is how I handle it in ANT build scripts in the output-directories section of the build script:

<if>
		<equals arg1="${test-project}" arg2="${project-name}">
		<then>
			<property name="main-out-folder" value="${test-project-location}/${out-folder}">

		</property>
		<else>
			<property name="main-out-folder" value="../${out-folder}">

		</property>
	</else>

	<property name="main-out-classes" value="${main-out-folder}/classes">

test-project and test-project-location get defined in the local.properties file. The ant task library you wil be using to enable the if task is ant-contrib.

 

Customizing MotoDEVStudio

One of my complaints has been that the underlying platform. Eclipse 3.4, uses ANT 1.0 which has a major bug. Unzip this into your plugins folder and take out the ANT 1.0 plugin folder in your MotoDEvVStudio for Android install. Now when you do soem tasks like declare the task library for JDepend it will be able to pick up the configuration file whereas with ANT 1.7 it was not due to a bug.

My next Android Cointribution-Agile-TDD

I am finishing up my next android contribution. Its a bug fix to fix the ANT support in the SDK by adding the proper ANT targets for unit and mock testing. If you have downloaded my Sdk customization extras you wil want to look at this bug fix as it has new targets added that are very useful. I will be posting a copy to this blog between now and Saturday.

List of new ANT  targets:

-tests.all

-tests.emma

-tests.functional

-tests.unit

-tests.log

-tests.all.breakpoint

-tests.small

-tests.medium

-tests.large

-tests.performance

The post at this blog will contain a link to a code sample showing code for all the tests as an example so everyone can use it as a guide . Still attempting to get sponsored support for covering these Android Agile method subjects so that I can publish some chapters, if you know of a firm that would sponsor this let me know.

WebView Obfuscation Magic

This is what the obfuscation prepaation ANT script code looks like:

<property name="assets-css-obfuscated" value="${assets-folder}/css-obfuscated"></property>
<property name="assets-js-obfuscated" value="${assets-folder}/js-obfuscated"></property>
<property name="assets-js-libs-compressed" value="${assets-folder}/js-libs-compressed"></property>
<property name="project-assets-css-libs" value="${basedir}/project-assets/css-libs"></property>
<property name="project-assets-js-libs-compressed" value="${basedir}/project-assets/js-libs-compressed"></property>
<property name="project-assets-temp-concat" value="${basedir}/project-assets/temp-concat"></property>
 <!--  The assumption is that during testing/dev we want the non obfuscated js/css files to 
 be real but the obfuscated oen sot be empty and reverse that for the 
 production/release. Thus prep step prepares an obfuscated empty file
 concat of the js-libs and the css files.  we assume
 that we plaqce js-libs-compressed libs in the folder
 -->
 <!-- Concat js-libs-compressed into one js-libs-3rdparty file-->
 <concat destfile="${project-assets-temp-concat}/js-compressed-3rdparty.js" force="no">
 <fileset dir="${project-assets-js-libs-compressed}" includes="**/*.js"></fileset>
 </concat>
 <!-- Move js lib file to assets -->
 <copy file="${project-assets-temp-concat}/js-compressed-3rdparty.js" todir="${assets-js-libs-compressed}"></copy>
 <!-- Produce an empty css-obfuscated file and a js-obfuscated file only empty for testing/dev -->
<property name="css-obfuscated-file-name" value="css-obfuscated-file-name.css"></property>
<property name="js-obfuscated-file-name" value="js-obfuscated-file-name.js"></property>
 <concat destfile="${project-assets-temp-concat}/${css-obfuscated-file-name}" force="no">
 <fileset dir="${project-assets-temp-concat}" includes="${css-obfuscated-file-name}"></fileset>
 </concat>
 <copy file="${project-assets-temp-concat}/${css-obfuscated-file-name}" todir="${assets-css-obfuscated}"></copy>
 <concat destfile="${project-assets-temp-concat}/${js-obfuscated-file-name}" force="no">
 <fileset dir="${project-assets-temp-concat}" includes="${js-obfuscated-file-name}"></fileset>
 </concat>
 <copy file="${project-assets-temp-concat}/${js-obfuscated-file-name}" todir="${assets-js-obfuscated}"></copy>
 <delete includeemptydirs="true">
 <fileset dir="${project-assets-temp-concat}"></fileset>
 </delete>

Than during the release.produciton target before the apkbuilder task you make empty css-not-obfuscated.css and js-not-obfuscate.js files and thus your import wil always be:

import css-non-obfuscated.css

import css-bofuscated.css

import js-non-obfuscate.js

import js-0obfuscated.js

import js-compressed-3rdparty.js

Notice that you will always have the import js 3rdparty compressed lib.  Because if you import an empty css or js file nothing happens it will always work right for both testing and production release because of the switching of which one is the empty file. Is not that a cool trick? And you never have to go through the html and change the damn imports every time.  Sure I could have threw together an ANT build script like everyone else but I thought it might be valuable to actually have an Android Build script that supports WebVuiew application development.

Is this trick used in the PhoneGap or QuickConnect or Rhomobile build scripts? Suprisingly, no in fact. This is the quality that needs  to go into a WebView application development book. However, I can not develop the book unless I have side Android App Development contracts. Now, some more details to finish than AndCooper Build Tool 0.1 release.

SignJar Target

Image by netzkobold via Flickr

While I polish the AndCooper release and directions, I will publish some ANT atrget example specific to Android.  How about a signjar task? SignJar:

<target name="signapk-pubkey" depends="release.production" description="signs the app to be published">
 <mkdir dir="${dist-folder}/${TSTAMP}${DSTAMP}"/>
 <signjar destDir="${dist-folder}/${TSTAMP}${DSTAMP}"
 alias="${keystore-alias}" keystore="${android-keystore-location}"
 storepass="${storepass}"
 preservelastmodified="true"
 Jar="${out-folder}/${ant.project.name}.apk" />

 </target>

The release.production target is just the apkbuilder task and you have set to signed not true so that the apk does not get signed witht the debug key. Remember, we do not have a clear standard way of indicating Android application  versions so I name the dist folder by date/time in preparation to indicate the version in some other ways. You may chose to do something very different.

AndCooper ReportWriter Code

I am now on the Report Writer code portion of AndCooper development. On one hand I could easily state that it should  be in groovy and a separate project. The problem is that fragments it in certain ways that I do not like.

If I choose to embedd the groovy code in the ANT script than I can re-use the code in the Android Mobile Build Continuous Integration Server project and everything is right there ready to test rather than run ant scripts from multiple projects. Which means I should set every report to xml and have that as an undelrying requriement that each code analysis/metric tool has to output reports in xml form so that I can transofrm that into an Android Developemnt specialized structure and format.