Google gets it Wrong

Hello  rant on. There are times hen every developer both outside application developers and project contributors want to just strangle Google. This might be one of those times.

On Sept 21st a developer blog post was posted on the android blog about using proguard to obfuscate in oreder to use some LVL features. The proguard supplied files had noticeable errors such as not picking up 3rd party libs in the proguard task amnd a poorly deficient proguard config file.

The corrections to the proguard ant task file can be found in the add-proguard-release.xml file in my AndCooperANT project. You can also find a correct proguard config file were log calls are stripped out and stacktraces and lines kept in the form of the proguard_android_config.txt file(drop box download).

To this date almost 30 days and no correction form Google and no acknowledgement of the errors. Come ON Google we have to get better than THIS! Its bug 11413.

Advertisement

AndCooperANT 0.1.1.1 Release

There is now a download of the AndCooperANT Android Java Application build tool. Its still alpha with the most tested area being the build.xml script. Of course if you find errors report them in the issues section.

Some of the docs are still in flux at the moment let me know in an issue/bug report of the instructions are unclear.

The Philosophy of AndCooperANT

If you visit most android developer forums you find android developers from all areas of development. Some are web developers, some are MS.NET developers, some are java developers, some are JavaEE developers, some are CS students, etc.

Among those many groups there is not a common thread of using a continuous integration build server.  With one exception, if you count the IDE as incremental compiler as the continuous integration server. and why not its small enough to run on a laptop with the android emulator and still have room to run a dev environment dash-board using jetty.

Thus, my philosophy is integrate pmd, checkstyle, classycle, jdepend, javaNCSS, doxygen for native c, jGrouseDoc for javadocs of javascript in assets, and cppcheck reports into one small build system package that is easy to set-up and use along with your favorite IDE for android development.

With some ease of usability in that you should only have four or less files to change per project amounting to less than 6 properties to change per project. Maybe even go further over this next week-end and code a groovy installer that auto-installs everything in a new project with no-mess no-fuss.

Not set as default incremental builder as we want developers to feel that they can run that one target to compile and doc the whole project whenever they want or they can set the whole thing up in their IDE as an incremental builder.

Not all polished all at once but I will get rest of the tools integrated this week and a full common look/feel to the reports that are generated so I can use it my own projects and see where rest of the improvements need to be made.  I did find how to do customizable headers and footers using CSS without having to change or insert new html  elements in the html generated in each report.

If you have not downloaded the corrected add-proguard-release.xml that was corrected from the android dev blog Sept 21st post than visit my github account link at the bottom of this blog and click on AndCooperANT and download that file at the project root folder. Of course no one paid attention to my bug submission yet, maybe I needed to have a bug title that stated Sept21st Dev post wrong?

But, oh well..towards weekend two more alpha and usable releases of AndCooperAnt with me starting to upload zipped copies to github for you to download.

ANT Build Script Up

The ANT Build script is up in this knol, its in alpha form. Later on I will put in up at github.

Android and Google GWT

Now I have an integration decision with AndCooper Android Java Application ANT based build tool. With the webview web code suport in the build tool my diea was at some point to swtitch to Goolge GWT compiler support and keep the non GWT  web tooling support there for those who wil not use Google GWT. The key question is do I make a separate project just for GWT and feed it in or a new set of directories and ANt script code to support GWT JS  generation in the main Android project.

Seems to me that is should be part of the overall Android Project structure and plus if I were say secretly working on a an Android application using Motorola CLiQ-Motorola Blur APIs and the Google Maps APIs it would seem that the Google GWT tooling would be an ideal component in that development work-flow.

AndCooperANT

I should have some screen shots of AndCooperANT in action by tonight. Thus, so why put in several months of constant building application prototypes to test out AndCooper methodologies? Several years back I had a prediction that there would be a rise of top ten developer firms building facebook applications.

During that period I submitted several start-up request to fund proposals to the FB-Fund. although my proposals did not get funding I wanted to understand what common thread produced repeated success among those top ten facebook application development firms. While luck can allow you tot be in the right place at the right time once, processes make sure you get there every time ahead of your competitors.

It is not that marketing did not have a role to play it is that the development process and infrastructure for that set of development processes deceased development time by 50% when compared to their competition. Every Android Developer will have the same exact gem of Android application idea its the on that gets there first with the marketing power behind it which means that the development infrastructure and process that delivers faster than your competitors wins out.

You would not believe the amount of management staff I have run into that does not get the direct relationship between cutting development time by 50% to be at the right time point for marketing and how that directly relates to other business management issues. And it is not just no-name companies some of them are names you recognize like Real Networks, Mozilla, and even sad to say Motorola and Google.

Okay, off my soap box. I should have build number generation working by time I post the screen shots of AndCooperANT in action tonight. Other features, auto adjust logcat to catch only javascript debugging information during the webview debug target execution. Auto obfuscation and compression of JS and CSS for webivew assets. Auto supplying blank JS and CSS files so that by just pairing imports of both un-obfuscated js and css files and the obfuscated version which in debug mode are blank files one can fully debug without manually having to change import statements of both js and css. Setting up certain common code templates at project initialization so that development is easier. Lint analysis of javascript code. Javadoc coverage analysis. Taglets javadoc coverage so that you implement a poor persons code coverage until the EMMA feature is in place. Of course the 50% decrease in development time comes form the inclusion of Test/Unit/Mock targets to full application of the Agile method TDD.

The basic premise here is that you the single developer should not have to fire up a continuous build server to get this power it should be at your finger tips by right clicking the ant build file and doing a run ant configuration and typing in the ant target.

Android Checkstyle checks

Here is the link to the Android Checkstyle set of rules that  am grouping together. In going though all the checkstyle checks I noticed some rules that were not enable in the normal checkstyle checks file that should be enabled for Android development. The added checks are have  a beginning commment so that you can examine them yourself to see if I am right in including them, they are added right after the header module declaration.

Yes, close to an AndCoper preview release..

Android Development At Agile Speeds

One of the obstacles lately that I have run into is how do you describe an Android Agile Enabler Build System such as AndCooper. Usually, i am communicating with managerial people that already have some exposure to such code review items as unit/mock test code coverage, code comment coverage, code correctness measurements, and etc. Thus, you would think in explaining that currently only have of that is supported in that build systems have yet to be built supporting the other half I get this blankness in the conversation on their part and that is after I explain that because unit/mock testing and code coverage testing occurs on device it requires a more integrated build system than just throwing together a few lines of ANT XML scripting.

In other words usually in most code review processes focus around a continuous build process producing code analysis reports used in the code review process. While EMMA reports can be generated off EMMA data produced, the unit/mock test data is not in report form yet as its in either the IDE stdout/console, or the device/emulator. Now you could make the project manager have to know how to start up an emulator and run the build to get the data manually but most managers are busy and thus it should be automated. And quite frankly automating the process so that the developer can use that feedback daily catches errors before they hit the code review process thus saving the whole team development time.

It is quite simple. If you put the right infrastructure in place so that the developer as part of his or her hourly activity can run an automated code review process to use as feedback than there are less items that require correction after the project manager end of day code review. It is not that I do not like explaining it, it is that I am somewhat tired of running into non-caring managers as it has an immediate value to both the costs and that impact on costs towards profits something most project mangers should care about.

Of course it would be nice to encounter a manger that ‘gets it’. Onward, the next few days refactoring the Android Build Life Cycle than the final sequences of testing tasks and than a full preview release.

Gradle Task for Proguard

I use proguard settings specific to Android Java applications so change to fit your needs before using:

task generateProguardConfigFile << { logger.info('Creating andcooper.pro file for obfsucate task') /** * andcooper.pro must have the following text * (the variables are replaced as the fiel is created): * -libraryjars androidJar: externalLibsFolder * -injars outClassesLocation * -outjars obfuscateLocation/classes.min.jar * -keep public class * extends android.app.Activity * -optimizations !code/simplification/cast * -allowaccessmodification * * '\n' goes at end of each line */ andcooperProguardConfig = new file('andcooper.pro') andcooperProguardConfig.withWriter{ writer ->
writer << ‘-libraryjars ’ + androidJar + '; ' + externalLibsFolder + '\n' writer << ‘-injars ' + outClassesLocation + '\n' writer << '-outjars ' + obfuscateLocation + '/classes.min.jar' + '\n' writer << '-keep public class * extends android.app.Activity' + '\n' writer << '-optimizations !code/simplification/cast' + '\n' writer << '-allowaccessmodification' + '\n' } } task obfuscate << { ant.taskdef(resource: 'proguard/ant/task.properties', classpath: configurations.runtime.asPath ) ant.proguard(configuration: 'andcooper.pro') } [/sourcecode] Notice all I am doing is creating the proguard.pro file on-the-fly and than using that in my taskdef via the ANTBuilder.

Android Builds-Gradle Style

The main feature, one of them, of Groovy’s Gradle build framework  is that plug-ins will add task to the life-cycle. Life-cycle in this case is the build life-cycle. Since mobile java builds are different than enterprise java I have had to come up with my own build life cycle definition, which looks like this in Gradle:

gradle.taskGraph.whenReady {taskGraph ->

if (taskGraph.hasTask(':debug')) {
debug.doFirst(dependsOn: 'clean') {
}
debug.doFirst(dependsOn: 'generateJavaClassesFromTemplates') {
}
debug.doFirst(dependsOn: 'processJavaPreprocess') {
}
debug.doFirst(dependsOn: 'processSrcResources') {
}
debug.doFirst(dependsOn: 'compileAidlJavaClasses') {
}
debug.doFirst(dependsOn: 'processPreCompileReports') {
}
debug.doFirst(dependsOn: 'compile') {
}
debug.doFirst(dependsOn: 'processPostCompileReports') {
}
debubg.doFirst(dependsOn: 'processAssetsResources') {
}
debug.doFirst(dependsOn: 'processPackageResources') {
}
debug.doFirst(dependsOn: 'processDex'){
}
debug.doLast(dependsOn: 'appInstall') {
}
} else {
}
if (taskGraph.hasTask(':release')) {
debug.doFirst(dependsOn: 'clean') {
}
debug.doFirst(dependsOn: 'generateJavaClassesFromTemplates') {
}
debug.doFirst(dependsOn: 'processJavaPreprocess') {
}
debug.doFirst(dependsOn: 'processSrcResources') {
}
debug.doFirst(dependsOn: 'compileAidlJavaClasses') {
}
debug.doFirst(dependsOn: 'processPreCompileReports') {
}
debug.doFirst(dependsOn: 'compile') {
}
debug.doFirst(dependsOn: 'obfuscate') {
}
debug.doFirst(dependsOn: 'processPostCompileReports') {
}
debubg.doFirst(dependsOn: 'processAssetsResources') {
}
debug.doFirst(dependsOn: 'processPackageResources') {
}
debug.doFirst(dependsOn: 'processDex'){
}
debug.doLast(dependsOn; 'appProductionSigned') {
}
} else {
}
/**
* mockTestsSomething tasks are defined under the project tag
*/
if (taskGraph.hasTask(':tests:mockAll')) {
debug.doFirst(dependsOn: 'clean') {
}
debug.doFirst(dependsOn: 'generateJavaClassesFromTemplates') {
}
debug.doFirst(dependsOn: 'processJavaPreprocess') {
}
debug.doFirst(dependsOn: 'processSrcResources') {
}
debug.doFirst(dependsOn: 'compileAidlJavaClasses') {
}
debug.doFirst(dependsOn: 'processPreCompileReports') {
}
debug.doFirst(dependsOn: 'compile') {
}
debug.doFirst(dependsOn: 'processPostCompileReports') {
}
debubg.doFirst(dependsOn: 'processAssetsResources') {
}
debug.doFirst(dependsOn: 'processPackageResources') {
}
debug.doFirst(dependsOn: 'processDex'){
}
debug.doFirst(dependsOn: 'appReinstall')) {
}
} else {
}
if (taskGraph.hasTask(':tests:mockFunctional')) {
debug.doFirst(dependsOn: 'clean') {
}
debug.doFirst(dependsOn: 'generateJavaClassesFromTemplates') {
}
debug.doFirst(dependsOn: 'processJavaPreprocess') {
}
debug.doFirst(dependsOn: 'processSrcResources') {
}
debug.doFirst(dependsOn: 'compileAidlJavaClasses') {
}
debug.doFirst(dependsOn: 'processPreCompileReports') {
}
debug.doFirst(dependsOn: 'compile') {
}
debug.doFirst(dependsOn: 'processPostCompileReports') {
}
debubg.doFirst(dependsOn: 'processAssetsResources') {
}
debug.doFirst(dependsOn: 'processPackageResources') {
}
debug.doFirst(dependsOn: 'processDex'){
}
debug.doFirst(dependsOn: 'appReinstall')) {
}
} else {
}
if (taskGraph.hasTask(':tests:mockUnit')) {
debug.doFirst(dependsOn: 'clean') {
}
debug.doFirst(dependsOn: 'generateJavaClassesFromTemplates') {
}
debug.doFirst(dependsOn: 'processJavaPreprocess') {
}
debug.doFirst(dependsOn: 'processSrcResources') {
}
debug.doFirst(dependsOn: 'compileAidlJavaClasses') {
}
debug.doFirst(dependsOn: 'processPreCompileReports') {
}
debug.doFirst(dependsOn: 'compile') {
}
debug.doFirst(dependsOn: 'processPostCompileReports') {
}
debubg.doFirst(dependsOn: 'processAssetsResources') {
}
debug.doFirst(dependsOn: 'processPackageResources') {
}
debug.doFirst(dependsOn: 'processDex'){
}
debug.doFirst(dependsOn: 'appReinstall')) {
}
} else {
}
/**
*  Have to disallow individual task exuciton that is not from
*  the debug, release, and :tests:mockSomething entry points
*
*  we hack it by setting  tasks to false and
*  printing an error message
*/
if (taskGraph.hasTask(':clean')) {
clean.enabled = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskgraph.hasTask(':generateJavaClassesFromTemplates')) {
generateJavaClassesFromTemplates.enabled = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask(':processJavaPreprocess')) {
processJavaPreprocess.enabled = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('processSrcResources') {
processSrcResources.enabled = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('compileAidlJavaClasses') {
compileAidlJavaClasses.enabled = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('processPreCompileReports') {
processPreCompileReports.enabled = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('compile') {
compile.enabled = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('processPostCompileReports') {
processPostCompileReports.enable = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('processAssetsResources') {
processAssetsResources.enable = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('processPackageResources') {
processPackageResources.enable = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('processDex') {
processDex.enable = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('appReinstall') {
appReinstall.enable = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('appInstall') {
appInstall.enable = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}
if (taskGraph.hasTask('obfuscate') {
obfuscate.enable = false
logging.info('sorry please use debug, release, or :tests:MockSomething')
} else {
}

Basically, the only entry points are debug, release, and mockSomething tasks. I kept the dependencies group in the order of execution thus the build is both readable and understandable and functional. Now it is add in the details of all tasks and start testing each task one by one. With the Gradle 0.8 project feature I was able to eliminate the need for a separate build script to be in the tests/src folder and remotely execute that script.

I should optimize my Life-cycle definition by using Goovy switch statements. Than switch to switch statements for the if-else blocks in my configurations block and I should be down to a compact 300 lines and with the other task details filled in about 800 lines. The ANT build script with the same feature set was turning out ot be 300 lines of mind-numbing not easy to read and understand mess.