We continue down our road of not using Eclipse and a customized build.xml file. This is because we pull sources from several trees, and also (a la J2ME) modify some of the source files before we compile them. We also make different modifications depending on whether it is a debug or release build.
The procedure outlined below, and also described in the "android" command generated build.xml file, works well as far as it goes. Having just brought us into 2.01 compliance I thought I'd offer some suggestions: 1. If the rules file called some do-nothing "hook" targets in the command-line "android" generated build.xml, we could do our mods in those hooks without ever touching or copy/pasting the "sacred" android_rules.xml. For example: "-start-debug-build-hook," "-start-release-build-hook," "-start-compile-hook," etc. Note we do need to know the difference between a release and debug build through the whole build process (and not just at signing time). With hook routines, android_rules could be revised and maintained while lowering or eliminating the impact on changes to build.xml. I would think the performance hit on modern machines is irrelevant. This is sort of like "custom build steps" in (ducking) Visual Studio. 2. Adding an "rinstall" target to install release builds would be useful. 3. Making an effort to keep the property names the same in build.xml/build.properties from release to release would be useful. (It seems like a convention for this has been chosen now, so maybe this is moot.) -- Ward At 12:29 PM -0700 4/14/09, Xavier Ducrohet wrote: >Hello, > >The new SDK include multiple versions of the Android platforms. >Because newer versions could have slightly different build steps, we >have decide to keep most of the build logic inside the platforms >themselves. > >Thus, the new build.xml imports a file called android_rules.xml >located inside SDK/platforms/<platform>/templates/ (it might move in >the final SDK but you shouldn't care much). > >This file actually being imported is resolve in the first step of the >build. The custom task <setup /> looks at the value loaded from >"default.properties" which contains the target project (ie which >platform/add-on the project is compiling for), and then import the >proper rules file (after doing some properties init as well). > >If you want to change the rules to make them your own, I'd sugges to >leave android_rules.xml unchanged, and instead copy the rules inside >your build.xml file, *after* the <setup /> task. >Additionally, change the setup task to <setup import="false"/>. This >will let the custom task do the properties init but not do the import. > >Some of the target in the rules files are slightly different than >before, with some using custom tasks as well. This is due to a new >feature to generate multiple APKs from a single project (with >different resources). >You can either ignore this and reuse some of the previous target/task, >or modify the custom task to do what you want (we're pushing the >source used to generate this SDK on the git server today) > >Xav > >On Tue, Apr 14, 2009 at 9:50 AM, Ward Willats <[email protected]> wrote: >> >> 'Round these parts we don't use Eclipse and heavily customize our >> build.xml file. The "android" tool tried to update it and burped out >> a short, confused file. >> >> That's OK. Don't mind doing build.xml by hand and "target-ifying" it, >> but I see what look like a whole set of Android-specific ANT >> tasks/libs (prefs, apkbuilder, jarutil..), of which only <setup> went >> into the new build.xml. >> >> So.....do I have to include any other custom ANT tasks besides >> <setup>? Or can I just use more-or-less the same command lines as >> before with aapt, javac, dx, etc...? >> >> And what are these "rules" setup uses? And where are they included from? >> >> Thanks >> >> -- Ward >> >> > >> > > > >-- >Xavier Ducrohet >Android Engineer, Google. > >--~--~---------~--~----~------------~-------~--~----~ >You received this message because you are subscribed to the Google >Groups "Android Developers" group. >To post to this group, send email to [email protected] >To unsubscribe from this group, send email to >[email protected] >For more options, visit this group at >http://groups.google.com/group/android-developers?hl=en >-~----------~----~----~----~------~----~------~--~--- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
