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.
Continue Reading »
Tags: Android, Ant, Barcode Scanner, building, Droid, Eclipse, subversion, success, Windows, ZXing
