Modify the emulator system.img

As a followup to my earlier post, I thought I would show how to modify the system.img the emulator is using.

This assumes that you are building Android and want to use some of the generated APKs inside the stock emulator.  That isn't the only scenario, but it's the one I am covering here.

First, we need to determine where the images are being loaded from. In this case my AVD is called "ics".

malachi@onyx:~/work/redo_system$ grep sysdir ~/.android/avd/ics.avd/config.ini
image.sysdir.2=system-images/android-14/armeabi-v7a/
image.sysdir.1=add-ons/addon-google_apis-google_inc_-14/images/armeabi-v7a/

Let's grab a local copy of those files

malachi@onyx:~/work/redo_system$ cp $ANDROID_HOME/add-ons/addon-google_apis-google_inc_-14/images/armeabi-v7a/* .

This time around, we are interested in the system.img. Let's unpack it.

malachi@onyx:~/work/redo_system$ mkdir unpacked
malachi@onyx:~/work/redo_system$ cd unpacked/
malachi@onyx:~/work/redo_system/unpacked$ unyaffs ../system.img
end of image

Replace a couple apps

malachi@onyx:~/work/redo_system/unpacked$ cd app
malachi@onyx:~/work/redo_system/unpacked/app$ cp ~/work/ics/out/target/product/SomeProduct/system/app/Contacts.apk .
malachi@onyx:~/work/redo_system/unpacked/app$ cp ~/work/ics/out/target/product/SomeProduct/system/app/ContactsProvider.apk .

Repack the system.img

malachi@onyx:~/work/redo_system/unpacked/app$ cd ../..
malachi@onyx:~/work/redo_system$ rm system.img
malachi@onyx:~/work/redo_system$ ~/work/ics/out/host/linux-x86/bin/mkyaffs2image unpacked system.img

Point our AVD to our new images

malachi@onyx:~/work/redo_system$ nano ~/.android/avd/ics.avd/config.ini
image.sysdir.2=system-images/android-14/armeabi-v7a/
image.sysdir.1=/home/malachi/work/redo_system/

The old userdata may not be compatible with your new apps. Make sure to use -wipe-data:

malachi@onyx:~/work/redo_system$ emulator -avd ics -show-kernel -scale 0.70 -memory 1024 -logcat 'dalvikvm:S,StrictMode:S,*:D' -partition-size 1024 -wipe-data

You are now running a slightly modified emulator...

LVL Testing

 In the beginning, my phone was setup with a Google Apps account (to cut down on the general spam).  When using the Market, it was billing my gmail account for the purchases.

A few months back, the Android Market updated itself from a tabbed list of applications to a Windows-8 combination of application links and general advertisements.  During that change, they enabled the ability to use multiple accounts with the Google Market.  Initially, I was very excited by this prospect.

Unfortunately, while applications were still being purchased with the gmail account - they were now divided into two accounts.  The old ones tied to the App account (which was not allowed to purchase anything anymore due to Google Checkout not being available to the Google Apps users) and the new ones tied to the Gmail account itself.  Why all apps weren't tied to the account that actually paid for them, I have no idea.  I contacted Google about this issue and they suggested that I contact all 184 old application developers and ask them politely to change the email address associated with my purchase.  As an app developer that has no idea how to do this myself, I wasn't about to do that.

Enough back story... onto the issue at hand... the Android Market Licensing...

If you have ever published "Copy Protected" apps in Android, you know that Google started suggesting (with bright red warnings) that you switch to the new LVL approach as the old one was going to go away.  Ok, that makes sense.  I look through the docs (which are a little overwhelming considering what is actually happening) and decided that the best thing I could do is try the sample LVL application first - then worry about securing it after I had it working.

Grabbing the LVL library and sample code from the SDK, I build it and test it.  Results were not very good.  Here are some things I ran into:

• Sometimes it said it was not compatible with my Atrix... then randomly decided to start saying it was compatible.
• When publishing an updated version, both the device and the emulator reported (for about 10 minutes) that licensing was not managed by the market.
• When on a device tied to multiple accounts, it only counted as licensed if the primary account (first one used on the phone) is the one that bought the application.
• If you want to delete the primary account so you can change the order, you have to factory reset the device.
• Oh, and of course, it can't be used on Free applications - which leads to lots of Market entries for demos and keys and trials.

So what to do?  Google says we have to quit using the copy protection scheme. Using LVL will break hundreds if not thousands of my users.  Doesn't sound like there are many options, does it?

Altering system.img, userdata.img and persist.img

If you have started building the Android source tree yourself, you have undoubtedly wondered how to modify the image files.  In this post, we'll look specifically at system.img.  This is based on the work found here.

Let's pretend our directories are:
~/work/android: directory where you did your git, envbuild, lunch/choosecombo from.
~/work/tmp: empty directory for us to play in
~/bin: directory on your path

If you have already done a build, you will find out/target/product/generic/system.img.  This is a YAFFS2 file.

Preparation

In my case, I did not have a way to mount yaffs2 filesystems.  I am sure I could have done some insmods and such; but instead, I chose to just compile this unyaffs.

~/work/tmp$ wget http://unyaffs.googlecode.com/files/unyaffs.c

~/work/tmp$ wget http://unyaffs.googlecode.com/files/unyaffs.h

~/work/tmp$ gcc -o unyaffs unyaffs.c

~/work/tmp$ cp unyaffs ~/bin

~/work/tmp$ rm *

Extracting system.img

~/work/tmp$ cp ~/work/android/out/target/product/generic/system.img .
~/work/tmp$ mkdir tmp2
~/work/tmp$ cd tmp2
~/work/tmp/tmp2$ unyaffs ../system.img

((modify files... for example, etc/init.goldfish.sh))


Rebuilding system.img

~/work/tmp$ rm system.img
~/work/tmp$ ~/work/android/out/host/linux-x86/bin/mkyaffs2image tmp2 system.img

Now you should be able to use the new system.img with your emulator =)


userdata.img and persist.img

These are handled in exactly the same way, just change the filenames.

Altering ramdisk.img

If you have started building the Android source tree yourself, you have undoubtedly wondered how to modify the image files.  In this post, we'll look specifically at ramdisk.img. This is based on the work found here.

Let's pretend our directories are:
~/work/android: directory where you did your git, envbuild, lunch/choosecombo from.
~/work/tmp: empty directory for us to play in

If you have already done a build, you will find out/target/product/generic/ramdisk.img.  This is a gzipped cpio file.
Extracting ramdisk.img

~/work/tmp$ cp ~/work/android/out/target/product/generic/ramdisk.img ./ramdisk.cpio.gz

~/work/tmp$ gzip -d ramdisk.cpio.gz

~/work/tmp$ mkdir tmp2

~/work/tmp$ cd tmp2

~/work/tmp/tmp2$ cpio -i -F ../ramdisk.cpio

((modify files... for example, init.rc or init.goldfish.rc))

Rebuilding ramdisk.img

~/work/tmp/tmp2$ cpio -i -t -F ../ramdisk.cpio | cpio -o -H newc -O ../ramdisk2.cpio

~/work/tmp/tmp2$ cd ..

~/work/tmp$ gzip -c ramdisk2.cpio > ramdisk.img

Now you should be able to use the new ramdisk.img with your emulator =)

Large screen support

I tried to deploy our progress bar demo to a large screen emulator session and found that my app was shrunken.  Thanks to Scott for pointing out the solution.

Add this to your AndroidManifest.xml and it works fine :)

          <supports-screens android:smallScreens="true"
                  android:normalScreens="true"
                  android:largeScreens="true"
                  android:anyDensity="true" />