What’s also very interesting is the aftermarket trade in all this.  As others point out, articles like this are not how criminals learn of such things – I’m sure there’s outfits out there buying up old printers, copiers or just the raw drives themselves, selectively, simply to vacuum useful info from them.

Why encryption and wipe-on-completion isn’t mandated is a mystery to me.  An exec suggested it’s a $500 add-on for one company’s products, but to me it should be a fundamental part of the product’s design!  Is it so hard to at least write a routine that overwrites a used/deleted file?  Not at all!  A big, fat “factory wipe” option loudly proclaimed in the manual?  A fraction of a cent’s worth of ink.

Note: encryption would be a good thing, but doing it right would add to hardware and design costs – otherwise the keys (being locally stored) are not much more secure than the data.  It’s far simpler to implement wipe-after-use and wipe-nightly.

See also the CBS video of this:

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.

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?

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.

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).

Flash Drives and The Removable Bit

Something I stumbled upon today was a Lexar utility that can flip the removable bit on a flash drive.  Disclaimer: this may not work for you or could even cause problems! As you may have noticed a flash drive appears as a “removable disk” in explorer, and (as I understand it) cannot be partitioned in XP or lower (Vista doesn’t seem to care as much from what I can tell).Indeed, it works, making the drive go from “removable” to “basic” (that is, fixed or local).

As I was doing all this in Vista with UAC enabled I was alarmed when it appeared that once I flipped the bit there was no flipping it back!  It’s not necessarily bad but I prefer to keep it removable unless otherwise necessary.  After lots of flailing (and finding a few posts alluding to this one-way trip problem – but no answers) I ran the utility via the “Run as administrator” option. This allowed BootIt to see the “fixed” disks (which the flash drive becomes a part of after flipping the bit).  Be VERY careful not to mess with the wrong drive of course! I think Vista is more protective of the fixed disks, thus the unexpected hurdle.

Note: I was able to flip the removable bit on Lexar and A-DATA drives, but I had no luck with my 4GB OCZ Rally2, a Sandisk Cruzer Micro or with an old Pocket Disk brand 128MB drive (handy for small images) which all stayed resolutely removable.

Read more about the Lexar BootIt (Flip the Removable Media Bit) tool here and here (I used v1.07, which I think is the only one out there).

Adding bootable ISO images to UBCD4Win images

It’s pretty easy to add bootable ISO images to UBCD4Win (this is tested with v3.22 and should work with v3.50 equally well).  Today I had LOTS of “fun” dealing with a lost boot manager on my triple-boot laptop (Vista, Ubuntu, Win7, oh my!) and I snagged copies of GParted and Super Grub to try and save the day.  All I did was download them and add the ISOs to the /images tree on the prepared flash drive.  Then I added a couple of entries in /menu.lst as follows:

title Super Grub
map --mem (hd0,0)//Images/super_grub.iso (hd32)
map --hook
chainloader (hd32)
rootnoverify (hd32)

title GParted
map --mem (hd0,0)//Images/gparted-live.iso (hd32)
map --hook
chainloader (hd32)
rootnoverify (hd32)

The ISO names must match what’s in /images, and I’d avoid putting spaces in the names too.  The usual disclaimer applies: I figured this out by trial and error but it worked fine for me.

Super Grub ended up working and saving the day!  GParted, not so much… I had to put it on a CD to get it to fully work.  This is no fault of GParted… as far as I can tell the same problem would affect ANY partition tool. GParted actually got stuck in a repeating loop of attempting to mount a drive and I think it had to do with how the boot process involved resetting the USB hub (thus resetting the flash drive).  Other partition managers that pass through a USB stage also experienced the same issues.  Booting GParted from the CD-RW appears to avoid all that.  I had the same problem when I attemtped to mount and install the Ubuntu 9.04 ISO from that USB drive today… it worked fine from a DVD.  So, while this method works in theory it may not always be practical given the limitations of booting from USB.

What’s nice is that once I have a small stable of utilities like this I can eventually burn the whole thing onto a DVD for near-universal usage (even on machines that won’t boot from flash).  Pretty handy! 

Update: there are better ways to do this menu thing I’m sure… and apparently the CD ISO uses an entirely different menu system for some reason.  So at a minimum /BCDW/BCDW.INI also needs to be updated (but I’m not yet sure what that should look like).

127.0.0.1       localhost
::1             localhost

I made a backup of the file, then I let Defender “clean” it.  OK… it only removed the 127.0.0.1 line (in red above).  Weird: that’s a pretty standard setting and it doesn’t seem like it should be going anywhere.

I searched around for this and found this thread on the matter.  I then used Windows update to get the latest version of the Defender database (it was last checked about 18 hours ago) and reverted the “fix” Defender had made (in Vista you must edit the hosts file with an editor running in Admin mode… as always be careful!)  Sure enough, it found and installed a newer version and a re-scan of the hosts file showed… no problems whatsoever.  Apparently one of Monday’s Defender definition updates might have had a bug in it.

Note: This is NOT to imply this is always a false alarm!  But if the only line that was removed is the standard localhost address as above, update Defender and re-scan.  This “problem” may not be a problem after all.

Now, I wonder how many people screwed up their hosts file today by letting this rather ubiquitous setting get removed?  I can imagine there are some apps that’ll be unhappy not to find a localhost route.  If this post helped you avoid some fun config headaches later please drop a quick comment.

Update: more info at this site about this issue.

I did some searching… turns out there are lots of complaints out there about this sort of issue, but almost nobody posted the correct way to fix it when Vista SP1 and WMP11 are involved.  Most solutions revolved around WMP10 or earlier.  The problem is, for some bizarre reason you can’t manage your licenses in WMP11 (there is no menu item for it and apparently all backup/restore functionality is gone!)  Why?  I have no idea.  Glad I don’t depend on it for anything else!

I uninstalled and reinstalled Netflix… didn’t help.  Lots of suggestions out there to downgrade WMP11 to 10 or such, but those are fraught with caveats.  Reinstall Vista?  Right!  When my furnace won’t work I don’t repaint the living room and redecorate the bedrooms… why should one rebuild the whole system for an isolated failure?  Besides, apparently that doesn’t help either.

Finally, I stumbled across a useful answer! Close IE and run the following command.  CAVEAT: supposedly it resets ALL your DRM license info… beware!  That wasn’t a concern for me (I’m wary of buying any DRM-wrapped media that could evaporate on a whim) but it could be an issue for you.  The command is:

C:\Program Files\Netflix\Netflix Movie Viewer\ResetDRM.exe

After a couple of warning windows (read them carefully!) it completed.  I reopened IE, clicked play on a Netflix movie and instead of crashing it notified me it needed to update something in WMP (as it had done long ago in XP).  I let it, and after that it works like a charm!

Well, almost… looks like it’ll complain about getting a license every time you use it (because of IE’s “protected mode”?  I dunno but I don’t feel safe to disable it).  It seems to work after a prompt, but it makes me think it’ll eventually fail again.

Was all this work worth it though? We’ll see… I don’t trust that it’ll be reliable and if it wasn’t free as part of my Netflix membership I would be very hesitant to use this at all – especially when such DRM “rights” could suddenly disappear tomorrow or, as we see here, every time you use it.  DRM is nothing but a nightmare and apparently it’s only getting worse.  I’d go to Blu-Ray but I don’t want any “Surprise!  DRM doesn’t like your big new monitor!” problems (also reported, which HDCP compatibility supposedly helps but it’s a “gotcha!” I don’t care to risk right now).

References:

http://www.annoyances.org/exec/forum/winvista/t1201447823

What all does one write on a blog that’s purposely sanitized so it won’t offend past, present or future employers? Something intended to be neutral and unassuming? Frankly not a heck of a lot.

*Sigh*