'Cuff that Droid!

There are many use cases, such as audio guides or kiosks, where you would like to lock down access to the device you are letting members of the public use.

Not surprisingly, this is one area where Android is strongly ahead of iOS, as Androids open architecture and level playing field of "all apps are created equal" means that implementing a locked down "kiosk" mode with Android simply requires building an app that displays full-screen and which has an Intent filter in its Manifest of:
  <category android:name="android.intent.category.HOME"/>

and then setting this app as the new default Home Screen handler the first time the home button is pressed.

In fact the SDK even ships with example code.

Doing this means the user will not be able to "escape" your app, even by powering cycling the device.

Of course there are other possible uses for this facility such as a child lock to allow small children to only access a fixed set of apps on a device.

This is in stark contrast to iOS, where Apple abandoned the simple "Notes only" (aka Museum Mode) mode available in the classic iPods (that was used to create simple locked down audio tour style applications by my organisations) and thereby created a whole cottage industry of custom (ugly) cases  and nicer looking stands:

However things did got a little more complicated when Android Honeycomb was released.

Honeycomb, unlike previous versions of Android, was created specifically as a stop gap measure to work well on large screen tablets and as part of this drive, Google moved to using on screen controls for the Back, Home and Menu functions that had previously been implemented as hardware keys on phone devices.

Because of this, the above technique would longer work. Those on screen buttons were handled by the operating system and no API was provided for Apps to remove or disable them, only dim the display of the control in a "lights out" mode. This was of course done for the very good reason that ap should not be able to prevent the user from always being able to return to the Home-screen or move back through the View stack.

People of course found work arounds, though these required root access to the device, which is often a difficult or fiddly process and will mostly be considered to have voided the devices warranty.

The good news though is that the above difficulties maybe only temporary, as with the release of Icecream Sandwich (Android 4) Google unified the tablet and phone versions and with ICS supporting older devices with hardware keys and therefore, I suspect that there will be a method to fool ICS into thinking its running on device with hardware keys, even when installed on a Honeycomb tablet device without them and without requiring root access, though I have not yet had enough time browsing the ICS AOSP code to confirm this, so stay tuned...