Unlike a desktop app, where one could add a “safe mode” icon for such instances, there are few options in the mobile space. These include:

• Letting the user delete the application data manually via the Settings menu
• Automatically resetting to defaults after a crash
• Attempting to automatically work around the broken area
• Asking the user on restart if they want to reset to defaults
• Falling back to the last known-good configuration

It’s one thing to be a power user, but another to be forced to become one thus the first option isn’t really practical. The second option guarantees recovery but may degrade the user experience (especially if there are lots of settings involved)… it should be a last resort, and a user choice. The third option is nice, but can become quite complex: this works best if settings are checkpointed frequently, but such frequent saves to flash memory are not usually a great idea. In addition, the more complex the fail-safe, the more likely it may cause a triggering exception.

Asking the user first is an important part of any solution, but it requires architecting a fail-safe startup sequence (one that is preference invariant). One can then offer the choice of a “fresh start” or the option of using a backed-up configuration, ensuring that the user has at least a chance of restoring to a previously working state with their settings intact.

A useful pattern for a single-instance app would be the following, using a persistent IsRunning flag:

• App launches
• Load settings
• Check if the IsRunning flag is set: if it is, then the last run exited abnormally (none of the normal exit points were hit which would’ve cleared the flag):
• Clear the IsRunning flag
• Offer to restore from backup / defaults or attempt to continue as-is
• Initialize states and display initial UI presentation
• Save the current settings with a backup name
• Set the IsRunning flag
• Save the settings normally
• On normal app exit / backgrounding, clear the IsRunning flag and save settings normally

There are other things you can do, including instrumenting for crash data collection and presenting the user an option to forward that data (anonymized!) to you for analysis.

Software quality is as much about how well you avoid defects in the first place as it is about how gracefully you recover from them!^† Mistakes happen, especially in apps with complex GUIs. Errors should be as rare as possible, but when errors occur it’s the unrecoverable ones that lead to lost users. Solid error handling and recovery goes a long way towards satisfied users who stick around for the release that irons out the bug they encountered and worked around

^†This is a critical difference between hardware and software quality, especially for smaller shops. If you ship a physically defective device, the typical recourse is a return for repair or replacement – a costly proposition in terms of logistics as well as reworked hardware / waste. The quality patterns for software and hardware have commonalities but are generally quite different in practice: in general, hardware is by its very nature far more costly and less forgiving of quality failures. This is why popular hardware quality initiatives tend to translate poorly to the software space.

Consider apps that are meant to be full-screen, and may be deeply interactive (such as a game). Having the action bar onscreen is not tenable, so one hides it. Whereas before you could use the menu button in the gutter (where “home” and “back” reside and indeed where “menu” appears – only for legacy apps), now you must either code your own button or invent a unique (but intuitive!) gesture to accomplish the end result of opening a custom menu or showing the action bar. If that’s not UI fragmentation I don’t know what is!

Though I find the action bar awkwardly placed and non-intuitive for in-app interactions, I understand the merit of having a unified UI. What I find fault with is the shortsighted decision to effectively remove an important hard button from Android (does anyone miss the “search” button?)

Now we have only two guaranteed (not hideable) buttons left, for the purpose of app navigation: “back” and “home” – along with a third new button for fast task switching (which is a little redundant… long-press on the home button could easily have the same effect without adding buttons). In addition (and likely for the foreseeable future) we have a “menu” button that only appears for legacy apps (thus that space in the toolbar is already “reserved” and will remain so for quite some time).

It’s too bad… there’s a strong argument for always having a “menu” button handy in an always-visible place. Maybe it unhides your action bar, or maybe it opens a custom menu, but removing it doesn’t help matters: it simply encourages a new kind of fragmentation for apps that don’t need an action bar onscreen normally. Now, instead of having a consistent way to perform that “open menu” action everyone gets to do it their own way (or leave the action bar open full-time, which significantly detracts from some apps).

One of many things that I like about Android is that the basic controls (home, menu, back) are intuitive and reasonable, balancing function with minimalism. Contrast this with the one overloaded hard button in another popular OS: much like a one-button mouse, oversimplification leads to confusion, reduced functionality and a fragmented UI as everyone works around the limitation differently according to their app’s design.

The rationale for taking away the menu button – one of the three main “always-visible” navigation and control buttons for Android up to now – defies logic: it fails at reducing fragmentation and funnels developers (and thus users) into an awkward, one-size-fits-all paradigm that is the antithesis of Android. This loss of a “hard” menu button is an unwelcome reduction in basic functionality in an apparent nod to the oversimplification of other OSes. I don’t find fault with the existence of the action bar, but removing the dedicated menu button from the always-visible area of the screen was IMHO extremely shortsighted. Now, instead of having a convenient way to reveal a hidden action bar, one must figure out how to do this for each app that normally hides its action bar. All this for the sake of removing a button that appears anyway for legacy apps.

As part of this, I needed to rebuild the emulator. It was not as straightforward as I’d hoped so I decided to write up a little howto here in case others decide to try rebuilding it on Windows. It’s really not hard at all once you install a few prerequisites! [Note: You'll also find info here about building this via Linux.]

[Edit: As of this post the HEAD is 6e2f62...599648 for platform_external_qemu. While this post-r12 work WILL build in Windows with these procedures, I just found out that the older r12 code (tagged as android-sdk-tools_r12) will NOT build in Windows! You'd need to do r12-based builds in Linux with MinGW installed. It's interesting to see just how much was fixed since SDK r12... including, evidently, the very issue I discovered today! Hopefully SDK r13 gets released soon. Oh look, it's out! Interestingly, unlike r12 there is no corresponding r13 tag for this one... which is part of why I didn't notice it in the Git log (I saw the tools_r13 branch though there are lots of changes after that).]

Note: If you choose other install dirs, adjust the values below accordingly!

Install Python 2.6 or 2.7:

• I used ActivePython 2.7.2.5 x64 (x86 should be equally good)
• Download: http://www.activestate.com/activepython/downloads
• Default bin dir for Python = C:\Python27

Install MinGW (it includes msys now):

• Information: http://www.mingw.org/wiki/MinGW
• Download: http://sourceforge.net/projects/mingw/
• Default bin dir for MinGW = C:\MinGW\bin
• Default bin dir for msys = C:\MinGW\msys\1.0\bin

Install Git: I use msysgit because I also use (and happily recommend!) TortoiseGit 1.7.3.0:

• Information: http://code.google.com/p/msysgit/
• Download: http://code.google.com/p/msysgit/downloads/list
• Git-1.7.4-preview20110204.exe works, 1.7.6 may as well
• Default bin dir for Git = C:\Git\bin

Open a command prompt and ensure your path is set correctly (omit duplicates as necessary, but ensure such entries weren’t eclipsed by other things you’ve installed, like Cygwin):

set PATH=C:\MinGW\msys\1.0\bin;C:\MinGW\bin;C:\Python27;C:\Git\bin;%PATH%

Clone the repository! (Because of the kernel.org outage we’re using the github mirror):

mkdir H:\temp_repo
cd /D H:\temp_repo
git clone https://github.com/android/platform_external_qemu.git

Start bash in the folder with the emulator sources (from this point on commands run at the bash prompt):

cd /D H:\temp_repo\platform_external_qemu
bash

Setting PS1 makes the prompt more verbose than the default “bash-3.1$” prompt:

PS1='\[\e]0;\w\a\]\n\[\e[36m\]\u@\h \[\e[32m\]\w\[\e[0m\]\n\$ '

There’s a small problem if you want the version string in the emulator to be fully formed:

• In Makefile.common, ANDROID_BUILD_ID get set only if BUILD_STANDALONE_EMULATOR == “” – never if BUILD_STANDALONE_EMULATOR == ‘true’ (which is what we’re building here). Here’s a fix for that, at least for the 13.x line of the emulator (line numbers may vary!):
• Broken: line 66: ifeq ($(BUILD_STANDALONE_EMULATOR),)
• Patched: line 66: ifneq ($(BUILD_STANDALONE_EMULATOR),false)
• If in doubt, ignore this tweak! Understand your -version output will not be very informative. That can quickly get annoying if you are building multiple versions…

Set some variables and run the build:

# Customize this as desired
export ANDROID_SDK_TOOLS_REVISION=42
export ANDROID_BUILD_ID=custom

# Inserts your username and the timestamp in the build name
export MY_BUILD_TIMESTAMP=`date +%Y%m%d_%H%M%S`
export BUILD_ID=${USERNAME}
export BUILD_NUMBER=${MY_BUILD_TIMESTAMP}

# Executes the build
./android-rebuild.sh --static 2>&1 | \
   tee build_${USERNAME}-${MY_BUILD_TIMESTAMP}.log

Check the version string of the emulator you just built:

• Run this:
• objs/emulator.exe -version
• See output like this:
• Android emulator version 13.0 (build_id Marty-20110925_042430)

Using the newly-built emulator:

• The objects of interest in objs are:
• emulator.exe, emulator-arm.exe, emulator-x86.exe
• You may need to copy them to android-sdk-windows/tools folder to use them (back up the originals first before replacing them!)

Notes on building via Linux:

As mentioned above, I managed to get all this to work on Windows just fine… technically, no source edits are necessary at this point to make it work. However, when I switched to the android-sdk-tools_r12 tag it failed with:

cc1: error: unrecognized command line option “-mno-cygwin”

Turns out this is a known issue… and in fact it was fixed in a later commit to the emulator code base! (I saw it as I was browsing the overall delta between r12 and the latest.) But, even with that fixed I couldn’t get r12 to build within Windows, so I went to Linux. I was already configured to build CyanogenMod, so everything was in place except MinGW. I installed mingw32, made that one fix to android-rebuild.sh and ran:

./android-rebuild.sh –static –mingw

And it worked just fine!

(Note: the –mingw option is NOT used when building this within Windows… it’s a little confusing because of course we’re using MinGW in Windows, but that’s how it’s coded in their build system.)

Update 1: This procedure works on the zxing-1.4.zip source base.  I’m trying to figure out why it doesn’t want to work easily with the most current SVN code (e.g., rev 1217 or 1220).  I thought it was just some preloading weirdness that caused the Java Stack Overflow errors, then I thought it was Subversion related, but now… now I’m not sure what’s going on but I’ll let you know if I figure it out.

Update 2: Eclipse does NOT like the new version of /android/default.properties at all.  After you create the project folders but before you try creating the project in Eclipse, edit /android/default.properties and change

target=android-4

to

target=Google Inc.:Google APIs:4

That seems to prevent the whole Stack Overflow problem.  I’m not sure why this changed or what the more correct thing to do it but there’s some apparently relevant discussion here. Curiously, despite my reversion of this change I do not see any problem in my test builds here, whether in Eclipse or when using the command-line build as outlined previously.

Update 3: If you comment out the target= line in that file entirely (using “#”) the problem also goes away – be sure to select an SDK level >= 4 though.  Eclipse still forces you to select a Google APIs target, but if you double-click one of the “un-selectable” Android targets (click the text NOT the checkbox!) just right it’ll apparently take the setting and work OK.  Who knows if that works in general – probably not. With an Android target launching the AVD also goes much more smoothly!

Question is, what is it that makes Eclipse insist this is an APIs project when default.properties is not giving it any hints? Or is it a quirk of the SDK? What triggers this, and is it more readily resolved than by doing this?

Update 4: Last update for tonight. Once a project is in Eclipse you can go to Properties -> Android for that project and select a suitable Android target.  As long as you don’t have dependencies on Google APIs it should be fine.  If you /android/AndroidManifest.xml and remove the android:minSdkVersion setting that problem goes away as well (again, select Android 1.6 SDK level 4 to ensure proper operation).

Either it’s Eclipse 3.5.1 or the ADT plugin that’s messing up here.  Regardless, it doesn’t seem to be any flaw in ZXing.  It’s rather annoying to see Eclipse acting like this… are other people seeing this sort of bug?

To summarize: to avoid all these painful problems just plain remove default.properties and edit AndroidManifest.xml before you create a new Eclipse project based on the latest source.  Ensure you select Android 1.6 SDK level 4 for best results.

Also, when you run the app it’s best to just start the AVD first, wiping user data, (or at least uninstalling the old version of your app) and being at the home screen before you “Run As”.  Otherwise, the app’s display ends up rather funky.

Finally, “Build Automatically” may be more trouble than it’s worth, at least for a larger project such as this.  Consider this if your head starts making dents in the wall as you struggle to make sense of Eclipse’s random “out of memory” errors.

In my previous post I referred to a Knol that tells you how to build ZXing for Android (the Barcode Scanner) using the Eclipse IDE.  There are pros and cons to doing this, given that ZXing is normally built from the command line using Ant (and during that build it is optimized using Proguard).

However, my goal is to learn more about Android programming in general and to make it even more interesting, I’m doing it from Windows.  Having the project working in an IDE is preferable for me when it comes to unraveling functional connections and learning how a (quite useful!) Android app is put together.

First of all, that Knol isn’t all that bad.  It helps if you read it carefully (I kept screwing up a particular step), however some of the steps are unclear apparently because the SDK has changed rather substantially since it was first written.  I’ve tried to be ridiculously detailed here so as to eliminate any possible confusion for the novice.

Second, it’s not clear that you need to install anything other than the Eclipse Classic 3.5.1 IDE and the Android SDK to perform this experiment.  I have the JDK, Ant and Proguard as well but they aren’t in my system paths nor is JAVA_HOME set system-wide yet.  Therefore I suspect none of that other stuff is getting referenced in this experiment.  You should have the IDE installed, the Android SDK installed and up-to-date, and the ADT Plugin for Eclipse (found on the SDK page).

Initialize the project in Eclipse

• Obtain the ZXing source tree via zip or SVN as described in the previous posts.  We are only interested in the /android and the /core/src trees.  The rest of the paths and components may be ignored for the purpose of building the Barcode Scanner app for Android.
• Place these in a working area.  For this example I used D:\workspace\zxing
• An important note: the Android SDK Content loader doesn’t immediately start in Eclipse until you attempt to use or create an Adroid project, and it takes a while to load.   Therefore quickly creating a new Android project based on another Android project while the SDK is loading can have unwanted consequences – particularly, Stack Overflows – which is apparently due to a race condition (if the Android SDK Content Loader is still processing when you pick the “based on” tree, bad, bad things happen).  It was a very distracting problem until I realized what was going on.
• Start the Eclipse IDE
  • Close any open projects!
  • Note that Project -> Build Automatically is selected
• From the menu select File -> New -> Project…
• In the new window select Android -> Android Project
• If Build targets are NOT populated at all and there’s activity in the progress tab:
  • Close the New Project window.
  • Wait for the Android SDK Content Loader activity to complete (watch the progress tab!)
  • From the menu select File -> New -> Project… again
  • In the new window select Android -> Android Project again
  • At this point the Build Targets should be properly populated and the progress tab should be idle/empty.
• Give the project a name.  For this example I used “BarExample” and will refer to that going forward.
• Select Create project from existing source
• Browse to where you put the zxing source tree (this will become your workspace!)
• Select the /android subfolder and click OK
• The Build Target will automatically be selected as Google APIs 1.6
  • I’m not entirely sure why this happens – you cannot select Android alone either.  I think this is why you are later warned when trying to launch it that there are no compatible devices.
• The Application name will be auto-filled as CaptureActivity
• Click Finish

Allow it to prebuild.  At this point you’ll have some 250+ errors but the next step should resolve them!

Add the /core/src code to your project:

Hard way #1:

Hard way #2:

A somewhat easier way to do this (avoiding the extra copy) is to put /core/src under /android (thus creating /android/core/src) before you initialize the project!  Then, after you initialize the project you can pick the src folder under the core entry in the project items and select Build Path -> Use as a Source Folder to have the desired effect (it’ll crete an entry called core/src).  I would expect a symlink, correctly applied, would also have the desired effect.  As you can see, the android folder itself is really superfluous here.  [I still think there's got to be an even easier way to gather this all together, without moving ANYTHING around.]

The best way to add /core/src to your project! No symlinks required (and being Windows it’s possible but not easy and besides this is even more minimalist) and it should work seamlessly even if you’re doing thing with Subversion-controlled code.

You’ve already created a project area called zxing (or whatever) and in it are the /android tree and the /core/src tree. Rather than manually or automatically move ANY code, simply do this:

• In the Package Exp tab, right click on the project name (“BarExample”) and select Build Path -> Link Source…
• Browse to and select the src folder in core.
• Change Folder name to srccore (or any other not-in-use folder name you prefer).
• Select Finish
• Let it rebuild automagically

If you were successful, you should see a whole mess of warnings (I see over 170) – but no errors!

To install and test this on the Android Virtual Device:

• Go to the Android SDK and AVD Manager and start your test device
  • I previously created a Droid-compatible device configured as Platform 2.0.1 API Level 6, with a WVGA854 display and a 32M SD card.
  • Select the device and click Start…
  • To avoid weirdness I elected to run with a clean slate and so I selected the “Wipe user data” option
  • The virtual device should start up.
  • You can (and probably should) close the AVD Manager at this point. Leaving the manager on led to an odd “GC overhead limit exceeded” error.
  • Wait patiently for the main screen to appear (it seems to take quite a while and a lot of CPU – is it just me?)
  • You shouldn’t have any other versions of this Barcode app installed at this point.  If you DO you should probably uninstall them first!
• Now, back to Eclipse!
  • In your project, select Run As -> Android Application
  • At this point I get an AVD error telling me “No compatible targets were found”.
  • I selected “No” (I don’t want to create a new target – I already have one!)
  • In the Device Chooser that follows I selected my running 2.0.1 emulator and clicked OK.
  • (I don’t know why this happens – it’s probably the mismatch between my 2.0.1. AVD and the original APIs 1.6 target.)
• The app should upload, install and execute on the virtual device.
• Be sure to rotate your local gravitational reference clockwise by 90° for the optimum viewing experience.  See the January, 2153 quantum multicast of Make: The Virtual Magazine for info on how to construct a portable graviton generator for this purpose.
• It’s not terribly interesting at this point but should work and look normal (not wiping user data and/or letting it launch the app before the screen is “unlocked” had something to do with the display looking rather weird – I’m not sure what was going wrong).
• (Really, why doesn’t the AVD have a rotate function?  It seems pretty fundamental.  Likewise some way to fake camera input – do tell if I’m missing a simple way to do either!)

Like I’ve mentioned, I got various odd little IDE errors as I made my way through all this… perhaps I’m doing something that’s not entirely right or the Eclipse IDE / Android SDK combination isn’t very stable.

But will it blend?  That is, will it work on a physical device?  Heck yeah!

To install and test this on an Android physical device:

• First, uninstall the current Barcode Scanner from your phone (you shouldn’t need to do it each time you cycle through your private test builds, but you DEFINITELY need to if you are switching between the officially signed to the unsigned or debug signed versions!  In short: if you get an installation error uninstall the app and try intalling it again!
• Note: for some bizarre reason after installation the Barcode app may be out of order alphabetically in the Manage applications dialog!  Closing the dialog and going back to it via Settings rectifies this.
• Copy the application’s APK from /android/bin to your phone
• Install the application
• Run the Barcode Scanner!

That’s about it!  I’d expect this to work just as well from a Linux host but I haven’t tested it.

Caveats:

• Proguard isn’t being used in this configuration AFAIK.  Therefore, things aren’t optimized (I’m not yet clear on why that’s necessary – presumably for performance reasons though it seemed to work OK when I tried it).
• AFAIK this is NOT how the ZXing project is normally developed, so if you plan to submit changes to it or otherwise assist with the project you should defer to the project’s standards and procedures.
• This procedure worked fine for me but it may or may not work as well for you, and there may be unexpected side-effects (I haven’t seen any yet but you never know).

It went very smoothly! Here’s the details:

• Install the TortoiseSVN client (then reboot)

• Create a folder to work in (e.g., “D:\zxing-test”)

• Right-click in/on the folder and select “SVN Checkout…”
  - Edit the “Checkout Directory” accordingly
  - I used the info at the ZXing SVN page to get the required URL (http://zxing.googlecode.com/svn/trunk/).  Note that the “zxing-read-only” part caused problems here (it’s not valid syntax for this client). You cannot commit changes without being a member of the group so leave it off when using TortoiseSVN.
  - I did a fully recursive code pull the first time.
  - I selected the HEAD revision of the version tree.

• Time passes as you download quite a helluva lot of code!  Broadband helps…

• For this experiment the last commit version turned out to be revision 1217.  I’m not sure how they manage their changes but it’s always possible you could be unlucky and get a revision level that’ll lead to a broken build.  (Fortunately, tonight’s my lucky night!)  You can specify this when you start the SVN interaction above, or you can “revert” to this version (or any other) later if you prefer.

• Prep and build it!
  - Edit build.properties as I described in my last post.
  - Build the source tree (be sure to set MY_PROJ_ROOT correctly to point to the SVN-derived tree!)  Use the debug target as before (I’ve yet to try the release one though I suspect the lack of signing will cause problems).

And again, voilà!  You’ve got a new build! (I notice the first “clean” build step no longer throws a small error as it did before… it didn’t affect things but it was nice to see that it got fixed).

I loaded the build onto my Droid and installed it (there was no need to uninstall the older version 3.0 I was testing with earlier – I don’t bother with that unless it complains or otherwise fails to install).  On execution the about box shows this is version 3.2 beta 1 (versus the version 3.0 I built earlier and version 3.1 which was the most current in the Android App Market)!  If I’m going to fiddle around, it’s nice to know I’m fiddling with the latest and greatest!

That concludes my coding evening.  Thanks for visiting!

Note: Other projects use Git… I installed TortoiseGit as well but haven’t had a chance to play with it yet.

Tonight I decided to try my hand again at building an Android app – this time, one that should in theory be easy and yet feature-rich enough to learn from.  It was far from the simple experiment it ought to have been, so I’m sharing my experience to hopefully save you the reader some time if you try this yourself!

ZXing is the heart of the Barcode Scanner app for Android.  It’s nifty though it doesn’t take full advantage of my Droid’s camera resolution and there are some other tricks I’d like to see it do (such as activate the flash for improved lighting, replacing the constant autofocus with a forced focus, and perhaps adding some decoding protocols that aren’t supported in the Droid build of this, at least as of Barcode Scanner v3.1).  My main goal was to simply rebuild the app for the Android target via a Windows host, then play around with the code to learn more about Android coding.

I’d recently moved some install folders around so I decided to install the necessary parts from scratch.  Note that I first spent an hour or two trying to use Eclipse 3.5.1 to build this but haven’t gotten it to work (yet).  When I decided to try doing this via “basic principles” it quickly became apparent that this would take a while.

I ran into several issues I won’t bore you with here.  Suffice to say the answers are scattered around Google, either in the ZXing comments, discussions, or its bugs area, and sometimes completely elsewhere.  It became clear that while Windows is supported as a host it’s probably not the primary host they test builds from, so their instructions aren’t very current or coherent for it needed some tweaks, which they’ve made.  (Windows isn’t the most common way to build for Android but it’s quite do-able just the same.)

Here, then, is the distillation of what I learned in order to successfully build the Barcode Scanner app for Android via Windows. This should apply to other Windows versions as well, at least back to XP.  If you are using an x86-based Windows then use x86 installers instead of x64 installers (where there’s a difference).

# This is the setup for a Windows 7 host (64-bit on an Intel CPU)

# Install Sun JDK (jdk-6u18-windows-x##):
 - Source: http://java.sun.com/javase/downloads/index.jsp
    - Select the JDK appropriate to your Windows host (x64 or x86)
 - My root folder: "C:\Program Files\Java\jdk1.6.0_18"

# Install Sun WTK 2.5.2 (sun_java_wireless_toolkit-2.5.2_01-win.exe):
 - Yes, you need this too!
 - Source: http://java.sun.com/products/sjwtoolkit/
    - Select Sun Java Wireless Toolkit 2.5.2_01 for CLDC
 - My root folder: "C:\WTK2.5.2_01"

# WTK is NOT required for the Android target, but part of its folder structure IS, as follows.

# Install ProGuard Java Optimizer (proguard4.4.zip):
 - Source: http://sourceforge.net/projects/proguard/
 - My root folder: "D:\Programming\proguard4.4"

# Copy the proguard.jar file to the expected location in WTK:
 copy D:\Programming\proguard4.4\lib\proguard.jar C:\WTK2.5.2_01\bin
 - If the "C:\WTK2.5.2_01\bin" tree doesn't exist, simply create it and populate it as above
    (again, WTK itself is not required for the Android target)

# Install Apache Ant (apache-ant-1.8.0-bin):
 - Source: http://ant.apache.org/bindownload.cgi
 - My root folder: "D:\Programming\apache-ant-1.8.0"

# Install Google Android SDK (android-sdk_r04-windows):
 - Source: http://developer.android.com/sdk/index.html
 - My root folder: "D:\Programming\android-sdk-windows"

# Run "android-sdk-windows/SDK Setup":
 - Update all packages!

# Fix "dx.bat" for Android SDK pre-2.0 (it's broken in those):
 - More info in this thread
 cd /d D:\Programming\android-sdk-windows
 copy /y platforms\android-1.1\tools\dx.bat platforms\android-1.1\tools\dx.bat.ORIG
 copy /y platforms\android-2.0\tools\dx.bat platforms\android-1.1\tools
 copy /y platforms\android-1.5\tools\dx.bat platforms\android-1.5\tools\dx.bat.ORIG
 copy /y platforms\android-2.0\tools\dx.bat platforms\android-1.5\tools
 copy /y platforms\android-1.6\tools\dx.bat platforms\android-1.6\tools\dx.bat.ORIG
 copy /y platforms\android-2.0\tools\dx.bat platforms\android-1.6\tools

# Install the ZXing codebase (ZXing-1.4.zip):
 - Source: http://code.google.com/p/zxing/downloads/list
 - My root folder: "D:\Test\zxing-1.4"

# Edit "zxing-1.4\build.properties":
 - Note double-backslashes!
 - Update: WTK-home=C:\\WTK2.5.2_01
 - Update: android-home=T:\\Programming\\android-sdk-windows

Now, if all that went well you should be ready to build it!

# Open a "cmd.exe" window to work in.

# Set appropriate environment variables for the tools:
 set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_18
 set path=%PATH%;D:\Programming\android-sdk-windows\tools
 set path=%PATH%;D:\Programming\apache-ant-1.8.0\bin
 set path=%PATH%;%JAVA_HOME%\bin

# Set the environment variable for the root of your project:
 set MY_PROJ_ROOT=D:\Programming\workspace\zxing-1.4

# Running the build (repeat as necessary):
 REM I added this top-level clean step to my process -
 REM It helps when you have tried building from the wrong level!
 cd /d %MY_PROJ_ROOT%  &&  ant clean

 REM Standard build step (see note in android/build.xml)
 cd /d %MY_PROJ_ROOT%\core  &&  ant clean build-no-debug

 REM Debug is the default target - I prefer to name it explicitly
 cd /d %MY_PROJ_ROOT%\android  &&  ant clean debug

 REM OPTIONAL: You can instead build the release version but it's not signed
 cd /d %MY_PROJ_ROOT%\android  &&  ant clean release

# Inspect and use the build output (the APK file is produced if successful):
 - %MY_PROJ_ROOT%\android\bin

At this point you should have successfully built the Barcode Scanner app for Android!

Load it upon your emulator or phone and see how it works. To try it on your phone, you will probably need to uninstall the current version.  Then you will need to check the “Settings -> Applications -> Unknown Sources” box on your phone to install a debug binary like this (As always, be careful when testing in this mode!!)  Copy the APK to your phone and install it.  Voilà!  It worked for me.

Next steps:

• Seeing if I can do this from within Eclipse.  A somewhat outdated Knol suggests this is possible, but I had no luck with it. Done!
• Install a Subversion client to get the latest code and see how that goes (my expertise is with Clearcase and such so this should be interesting). Done!
• Modifying some code! Done!

Disclaimer: I’m NOT attached to the ZXing project at all, I’m just putting this out there in the hopes that it’ll help others have an easier time at this than I did.  I probably cannot help you with any issues you have (especially for other host or target platforms).