KindleFire - breaking out

I am the proud owner now of a Kindle Fire - a nice $200 7inch Android pad that arrives with very close couplings to Amazon who produced it. You cannot for example use the Google Android Market - only the Amazon version - and this market insists that you have a US addressed credit card even for free apps.

So the goal here, much described in many sites, is to make the Fire more usable but hopefully to retain the rather nice Amazon look and feel. This posting is a summary of my way through the various sites and the "gotchas" that I had to work around.

These are the main steps:

• Root the device - some later steps require superuser access so the aim here is to install SuperUser.apk
• Install the GoogleServicesFramework.apk which runs in the background on the Fire
• Install Vending.apk which is the Android Market application.

Rooting the Fire

There are many possibilities but the one I preferred also allowed me to install a recovery image. This image, which the Fire boots into and waits a while for a key press before a normal boot, allows complete system images to be backed up and restored.  This means that the native state of the Fire can be saved in case anything goes wrong.

The Kindle_Fire_Utility provides a pretty self-explanatory interface to setting up the root access and recovery image. The only problem I had was finding that "Fastboot" did not work on the Fire - best left alone!

The utility looks like this and the two options required are 

• 3 Install permanent root with Superuser
• 5 Install latest TWRP recovery

If all goes well the Fire should boot into a screen with a yellow triangle. Doing nothing leads to Kindle Fire after a pause. Pressing the Power button leads to a totally touch based recovery console.

Installing the GoogleServiceFramework

My first download would not install through ADB.

Bricked!

Well it had to happen. I began to fiddle around inside my Eken M003 aPad, using ADB as described in my previous post, and after changing something (trying to install a new copy of busybox the elementary Linux on top of which the whole Android experience is built) I ended up with a device that would not start up - a brick by any other name.

This is a situation that is not hard to recover from on an Android device. The key is the SD card which can be inserted - if this contains a directory named script, with the appropriate contents, the device will detect that and pause before entering update mode and a count down will be displayed on the screen. Hit a key (mine has no keys!) or pull the SD card if you do not want to proceed.

The next screen will display a series of messages as the environment is prepared for upgrade.

If all is going well (more on that later) the changes to the Android file system will be copied onto your device. This could include new applications or data. Anything really.

The one absolutely critical thing is not to run out of battery whilst this is happening and this, courtesy of a dodgy mains power connection, is exactly what happened. At this point this device was really truly lost. As far as I could tell the boot ROM code on the CPU daughter board had become corrupted and this simply cannot be replaced. The device went in the garbage! 

Java - some gotchas with NetBeans generated JAR files

The problem
JAR files are a great way to distribute Java applications. A single file contains everything and is easy to use with a double-click. However making everything work from the JAR is another question and here are two problem areas. NetBeans 6.9.1 is being used to build the project.

Library classes
Class files in a library (often a JAR or ZIP file) are placed by the NetBeans build process in a folder named lib alongside the application JAR. The JAR manifest adds the location to its classpath entry and hence, when the JAR is executed Java knows where to find the library code. I could not find a way to force NetBeans to simply add these classes (as if they had just been compiled!) to the root of the JAR.

Everything is fine though if you use the Java jar program to update the JAR before distributing with a couple of provisos to do with the way that jar handles things:

• We are using  jar -uf    ... to update the JAR file with the entire contents of the directories of classes. You have to execute this from the directory in which dir1 etc are stored - jar does not correctly handle paths added to the locations of directories to be added. Since NetBeans uses a dist directory within the project folder for its distribution JAR it makes sense to do all this from the "project root" and to place the directories of library classes right there
• An example - we want to add the entire tree of classes under sunsoft to the application JAR file at dist/netsim.jar:
• jar -uf dist\netsim.jar sunsoft

Resources from the application JAR file

This is much written about but a few things do not work as they ought. The basic idea is to use the class getResource() method to access whatever it is (picture, sound etc) - by using this call, which will include Java's knowledge of how the class was loaded, the same code should work from a JAR or with normal execution.

getResource() returns the URL that describes the resource's location which can then be passed on to the appropriate loader for a sound or an image or whatever. getResource() takes a single parameter with is the "path" to the resource. For a program that will simply work from a JAR or from the file system this "path" needs to make sense within the JAR file as well as in the file system.

The critical thing is use a leading forward slash - so for example getResource("/card.jpg") will return the URL of the JPG whether it is in the root of the JAR file or simply in the file system alongside the directories containing the application classes (the "root" of the program I suppose)

There is one more NetBeans problem. NetBean is smart enough to place resources from its src directory in the root of the application JAR file when it builds -but they not then seen by getResource().

To make things work they must be manually re-added using jar as above. If the resources are small you can live with the duplicate copies - if they are large delete the NetBeans copies first - in NetBeans file view.

adb on a cheap aPad

So you have an aPad but it is a cheap one.

A "real" Android phone can be USB connected to a host (Windows, Linux or Mac) and should be detected as an "Android phone". If you have downloaded the adb (Android development bridge) USB drivers these should be automatically installed and your development environment (Elcipse is preferred) should then see the device as a potential test environment.

That's the theory. In practice my M003 device does not seem to implement the appropriate USB "slave" code for an adb connection. In this USB scenario your development machine is the USB host (normal big USB connectors) and the device is the USB slave (usually some other USB connector). This means that a USB connection is not possible.

What then?

adb also supports a TCPIP connection on port 5555. This connection fortunately is implemented. This can be confirmed using the Linux nmap command (nmap -A [ip address of device]) which will confirm that port 5555 is indeed listening - waiting for a connection.

• The Android development kit must be downloaded and installed
• Java is required
• adb is found in the tools directory of the SDK
• To connect to the device use adb connect [ip address of device]
• To confirm the connection use adb devices
• To confirm privileged access to the device use adb shell which will provide a prompt (from the device!) at which you will have sufficient access to write to the file system. Try creating a file.
• Your UID is 2000 which is the shell ID. Getting to be root is going to be harder

More to follow

Trying out an aPad

The iPad has been echoed as the aPad - a much cheaper (nearer $100) device that uses the open source, Google Android operating system rather than all the proprietary Apple stuff.


I got mine from Tradestead where you will see some unbelievable prices. The device is an Eken M003. It runs Android 1.6 (up to version 2.1 at the time of this post).


The exciting thing about an aPad is the potential to start developing Android apps so this leads to some initial problems to resolve about which I will post in the future:

• root access to the device
  Making changes requires more privileged access than is given by default so this needs to happen
• adb access
  adb (Android development bridge) is the application that the android developer kit provides for access from a development machine (Linux, Windows or Mac) to a device - my M003 in this case
• Uprading the Android version
  The essential issue here is that the device is not wrecked - there must be a recovery path

Striving for the ultimate bootable USB

Many people are working on this, many with a deeper understanding than me, but here is my take.

The requirement as I see it is for a USB key from which an arbitrary USB-bootable machine can be booted which can then load any one of a number of images. The most frequent requirement I have seen is to adjust the partitioning on a PC and the System Rescue CD works well for this but there are many other possible solutions. For each solution there will be an ISO image available so this leads the first requirement:

Requirement 1: Multiple bootable ISO images are easily added to boot menu

This approach is well-implemented by the folk at Pendrivelinux  who provide a program that will setup a USB stick that boots and displays a GRUB menu. The GRUB4DOS menu language is extensive and powerful enough to support booting from many different ISO images which simply need to be copied to the key. As a last resort (because certain images get confused about drives during booting) the image can be expanded onto the key in which case it is almost bound to work.

There is one major problem in this approach. There are two ways that a USB drive can be formatted:

1. As if it were a hard drive 
   The USB drive has a MBR (Master Boot Record) with a partition table and the usually single partition is marked as active (bootable) and has a Boot Sector that launches whatever OS is installed on that drive.
   This is the default way in which USB keys end up being formatted in Linux and Windows.
   From the Linux point of view this partition is referred to as /dev/sd[some letter]1 (number one!). To discover what the letter is run the Linux command dmesg just after you insert the stick - there will be references to sd[some letter] in the messages displayed. So for example:
   - dmesg shows that the device is sdd
   - The whole USB stick is then referred to as /dev/sdd
   - The first (usually only) partition is referred to as /dev/sdd1. GRUB menus will refer to this location using the GRUB terminology (hd0,0)
2. As if it were a floppy drive
   This is often described as a superfloppy. There is no MBR and partition table - the OS on the drive is booted through an appropriate VBR (Volume Boot Record) or boot sector on the drive.
   Formatting in this way is harder - in Linux you need to use the command:
   mkfs -I /dev/sd[some letter] for a Linux format or
   mkfs.vfat -I /dev/sd[some letter] for a VFAT format
   The -I option forces the raw device to be formatted
   GRUB menus will refer to this location using the GRUB terminology (fd0)

The ability of a particular machine BIOS to boot from a USB stick may depend on whether the stick is formatted as a hard disk or floppy. This is beyond my ability to test broadly but so far 2 out of 3 have required superfloppy formatted USB sticks to boot. I will keep trying other machines as I come across them and updating this post.  I have been told by Lance at pendrivelinux that it will be older BIOS's that impose the superfloppy restriction but I have come across it on an eeePC 901.

This leads to the second requirement:

Requirement 2: USB format (superfloppy/hard disk) should support as many machines as possible

This leads to a problem with the default Pendrivelinux approach. A Pendrive MULTIBOOT USB boots Syslinux which is very minimal Linux which can then launch other programs. In MULTIBOOT Syslinux is configured to run GRUB.EXE which then displays the menu of operating systems. This works just fine on a hard disk formatted USB stick. GRUB.EXE defaults to looking for a menu on (hd0,0) and when this is the stick all is well.

Booting from a superfloppy formatted USB stick fails to find the menu at (hd0,0)  and has to be told manually (with the GRUB command root (fd0) ) where the menu is. In theory this can be corrected through an entry in the syslinux.cfg file:

kernel grub.exe

append --config-file (fd0)/menu.lst

but in the MULTIBOOT environment this directive is not passed through to GRUB.EXE

This posting really concerns a solution to that problem (there is an experimental download on the pendrivelinux site that takes this approach) :

1. Make MULTIBOOT directly run GRUB.EXE
   The problem described above is a Syslinux one and the following changes can make the USB stick directly boot GRUB.EXE:
1. Use BOOTICE.EXE to install a GRUB.EXE bootsector on ynloadour superfloppy formatted USB stick. 
2. This bootsector looks for the file GRLDR on the USB stick
3. GRLDR runs GRUB.EXE but the version (0.4.4) from MULTIBOOT has problems locating ISO files with the find --set-root command so replace it with a newer GRUB.EXE
4. All reference to Syslinux can then be removed from the USB stick - they are no longer needed
2. Modify the boot menu for the (fd0) environmentThe boot menu is contained in the file menu.lst and contains many references to (hd0,0) - these should all be replaced with (fd0). It then remains to try out, and possibly adapt the entries provided. I place all the entries which I have not yet fixed in a separate file menu.extra  and then reference these as a sub-menu through and entry in menu.lst:
   
3. title Uninstalled & untested options
4. configfile (fd0)/menu.extra