Resizing VirtualBox VHD

Posted on by
Reply

When I first created my VM for developing, I made the VHD a dynamic hard drive, but limited it to just 30GB. I didn’t think that I could fill that much space just doing Eclipse and Android SDK stuff, but I was obviously wrong. I tried following a couple of blog posts to complete the following steps, which I reference at the bottom of this post.

Step 1: Resize the VHD

I first tried resizing the VHD with the VBoxManage command modifyhd:

VBoxManage modifyhd [vhd or vdi file] --resize [size in MB]

When I tried that command from an elevated command prompt, I got the following error:

VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005) - Server execution failed (extended info not available)
VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running or failed to start.

Running from an un-elevated command line fixed the issue, however after resizing the VHD in this way, the process apparently corrupted my MBR. Thankfully I made a backup and was able to start again. ALWAYS CREATE A BACKUP.

Finally, I gave up and created a new VHD and cloned it using the GParted bootable ISO (see below) and dd from the command line:

# dd if=/dev/sda of=/dev/sdb

This took about 10 minutes for a 20GB VHD (/dev/sda). Once I had them cloned, I resized the guest file system in GParted.

Step 2: Resize the Guest File System

Using GParted, I resized the guest file system in Ubuntu to fill the maximum space available so my development platform can expand as it needs to.

First, I downloaded the GParted bootable ISO. I mounted that in VirtualBox for the guest OS, and booted it up. Since I used that Live CD for the dd operation in step one, I was already there. From here, I simply expanded the partitions to fill the available space. Here is a quick guide on resizing a drive with a swap partition.

After rebooting with the new VHD, all my data is present and I have a lot of room to grow!

Resources:

Android SDK: “no permissions” for HTC EVO LTE

Posted on by
Reply

I’m setting up a new dev environment in an Ubuntu VM. One of the toughest obstacles was getting adb to recognize my HTC EVO without starting adb as root. None of the posted solutions worked for me, but they were helpful, particularly the setup instructions posted by Google under “Configuring USB Access”.

I used the command

$lsusb

and got the following response:

Bus 001 Device 004: ID 0bb4:0ce9 HTC (High Tech Computer Corp.)

I used “0bb4:0ce9″ obtained from the usb listing to modify the lines in /etc/udev/rules.d/51-android.rules to be:

# adb protocol on jewel (EVO LTE)
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0ce9", MODE="0600", OWNER="bradford"
# fastboot protocol on jewel (EVO LTE)
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0ce9", MODE="0600", OWNER="bradford"

I can now access my usb device without root access.

Android SDK: UnknownFormatConversionException

Posted on by
2

I’ve been working on a weird exception for the past couple hours and finally figured it out. Since I couldn’t find any information about this exception I figured I’d post about it.

It happens in my SettingsActivity, which extends SherlockPreferenceActivity. The cause is my string-array of values that have a percent sign in them, and when I set the preference summary that has a percent sign, the OS tries to format that percent sign. There are a few ways to escape the percent signs, but none of them worked. If I used 2 %% signs, it set the summary without an exception, but it showed up as “%%” in the select list. None of the HTML encodings worked either. I even tried to HTML encode the whole string when I set the summary, but I don’t think there is a way to escape the % sign unless you escape it with another %, and that just shows up as “%%” which is unacceptable in my application. So, for now, it will just be “percent”. Lame.

Stack Trace:

FATAL EXCEPTION: main
java.util.UnknownFormatConversionException: Conversion: 
 at java.util.Formatter$FormatSpecifierParser.unknownFormatConversionException(Formatter.java:2304)
 at java.util.Formatter$FormatSpecifierParser.advance(Formatter.java:2298)
 at java.util.Formatter$FormatSpecifierParser.parseConversionType(Formatter.java:2377)
 at java.util.Formatter$FormatSpecifierParser.parseArgumentIndexAndFlags(Formatter.java:2348)
 at java.util.Formatter$FormatSpecifierParser.parseFormatToken(Formatter.java:2281)
 at java.util.Formatter.doFormat(Formatter.java:1069)
 at java.util.Formatter.format(Formatter.java:1040)
 at java.util.Formatter.format(Formatter.java:1009)
 at java.lang.String.format(String.java:1998)
 at java.lang.String.format(String.java:1972)
 at android.preference.ListPreference.getSummary(ListPreference.java:152)

Android SDK: Data exceeds UNCOMPRESS_DATA_MAX

Posted on by
Reply

I’m finishing up my first app (attaBase) and testing it on the minimum API I set: 8. That’s Android 2.2. My app grabs a 4MB CSV file and imports all the DoD locations (Military bases, etc). The problem is, the old APIs (up to 2.3.3 I think) have a limit of 1MB of uncompressed data in the assets folder. So, I had to work around this limitation.

I found a tip on Stack Overflow to zip the file yourself and use a ZipInputStream to unzip it on the fly. Since I’m only ever accessing this large file once in the lifetime of my app, that’s fine. I ended up editing the Stack Overflow answers I link to above to provide examples, but here is my code that accepts a zipped file and unzips it on the fly:

AssetManager am = getAssets();
InputStream is;
ZipInputStream zip;
InputStreamReader isr;
try {
    is = am.open(AttaBaseContract.IMPORT_SOURCE_ZIP);
    zip = new ZipInputStream(is);
    isr = new InputStreamReader(zip);
    zip.getNextEntry();
} catch (IOException e) {
    e.printStackTrace();
    return -1;
}
 
int skipline = 1;
CSVReader reader = new CSVReader(isr, CSVParser.DEFAULT_SEPARATOR, CSVParser.DEFAULT_QUOTE_CHARACTER, CSVParser.DEFAULT_ESCAPE_CHARACTER, skipline);

This is assuming there is only one file in the zip file, because it will only feed the first file to the CSVReader (in this case). This is a nice workaround if you’re trying to make your app compatible to an old API.