Development & Release Aware Android Apps/Builds

What am I talking about and why would I need this?

Use Case
An Android application that collects data from the client, and then ships this data (via an HTTP POST) to be processed on a server.  This have 2 server locations/endpoints that will process this request:

• "development" environment ("http://www.processme-test.com/development")
• "production" environment ("http://www.processme.com/release")

So the crux of the problem lies in a property (or set of properties) that contain the server url for the post must be different between the development and release version of the android application.


in pseudo code terms:
if (inTestMode()) {
     serverUrl ="http://www.processme-test.com/test";
} else {
     serverUrl ="http://www.processme.com/release";
}
When I first looked into it I wanted a mechanism to find out (programatically) if the APK file was signed with a Development Certificate or not to accomplish this :(.  After looking and searching, I found no mechanism for accessing information about the certificate.  Other folks had recommended doing things like customizing ANT scripts to replace text in some of the source Java files, but I thought that was kind of a hack (and certainly doesn't scale well).  Also the problem with doing this is I would like to avoid having ANY of my non-prod properties classes etc. appear in the release version of the application. (using scripts for replacement  seems error prone) Another property I ran into is Config.DEBUG and I thought I might be able to use this, however in practice it seemed th value for this parameter was always false (even when deploying a development debug build to my Htc incredible). :(

Ideally the solution would be:
1) optimized for development (i.e. make the common case fast) specifically since our team is using eclipse and the majority of my builds (90+%) will be development where the build is signed with a Development certificate
2) simple to script (in ANT or MAVEN) so either the development or release versions can be built with different build targets
3) no development code and properties files should find their way into Prod/Release build
4) scalable to allow multiple properties and strategies for overriding (you always start out having one property (like a server url) but realistically there may be many properties that you want overrides for.

...Long post will be continued next round