Google’s Android is a very small Linux distribution. Recently I needed to test some applications that were developed by a couple of friends of mine. Rather than run out to T-Mobile I figured I’d just install the new LiveAndroid disk and thought I would write up how to get setup using VMware Fusion and then go about doing some tasks with Android. To get started make sure you’re running the latest Fusion (or Parallels or Q or VirtualBox). Then download two ISO files from http://code.google.com/p/live-android/
liveandroidv0.2.iso.001 and liveandroidv0.2.iso.002.
Once you have downloaded the two ISO files we’re going to need to join them. To do so
cat liveandroidv0.2.iso.001 liveandroidv0.2.iso.002 > liveandroidv0.2.iso
That will take a few seconds to complete. When it’s done, open up VMware and then click on the New button in the lower left corner of the Virtual Machine Library screen. At the New Virtual Machine Assistant, first click on Continue Without Disk and then choose the Use Operating System Installation Disk Image File: option, selecting the ISO file from the browse screen. Once selected, click Choose in the Browse dialog box and then back at the New Virtual Machine Assistant Screen click on Continue.
At the Choose Operating System screen, leave the Operating System and Version fields set to Other and then click on Continue. The Default memory and disk capacity should be fine (256MB of memory and 8GB of disk). The default Shared networking (NAT) option will also have the Android instance able to boot with the network interfaces functional (unlike in my VirtualBox testing), so leave that as-is as well. Click Finish and then the Android virtual machine will start.
Once started you’re going to get an error about the battery. This is not a big deal, click on OK to suppress it. If you can’t find your cursor then look for the faint grey arrow. You can then click on the default home screen applications (Messaging, Dialer, Contacts or Browser) or on the slider to the right of the screen for the rest of the applications (such as the Gallery or the Camera). If you use the space bar you’ll open the dialer (not that you can dial out or anything) and if you use the the Escape key you’ll back out of an application, back to the home screen.
To get to the command line you can use the fn-alt-F1 (the F1, when pressing the fn key is immediately to the right of the Escape key whereas the alt is the same as the option on Mac in that scenario). The fn-alt-F7 combination will switch back from the command line to the home screen.
When you’re at the command line you’ll have a number of options. Because LiveAndroid .2 supports DHCP there’s usually no need for configuration of the network stack, although I did have to configure it manually in VirtualBox. To do so I started with ifconfig, which works similarly in Mac OS X.
ifconfig eth0 192.168.210.30 netmask 255.255.255.0
Then I setup a gateway with the route command:
route add default gw 192.168.210.1 dev eth0
You can also use setprop to define your DNS servers. For example, to set 4.2.2.2 as a DNS server you would use the following:
setprop net.eth0.dns1 4.2.2.2
I also use a proxy so I had to configure that in order to be browsing the old interweb. After a bit of noodling around I realized that Android stores a number of settings in a sqlite database stored in /dat/data/com.android.providers.settings/databases/settings.db. If you remember, I did an article on using sqlite3 with Address Book on Mac OS X awhile back – this is all very similar to that, as sqlite doesn’t really change much (if any) from platform to platform. To open the database in sqlite3, use the following command:
sqlite3 /dat/data/com.android.providers.settings/databases/settings.db
Then type .tables and you should see one called system. We’re going to insert the proxy data into it, in this case inserting proxy.krypted.com:8080 using the command:
insert into system values(99,’http_proxy’,’proxy.krypted.com:8080′);
At this point I’m off to the races with the web browser. Next I have a couple of applications friends have developed that I’d like to install. From the command line this is pretty easy. They put them up on their websites and then I go to /system/app using the following command:
cd /system/app
Next, I use wget to pull down the app (which is in the form of an apk file), assuming that the name of the server is my.server.org and the name of the app is myapp.apk:
wget http://my.server.org/myapp.apk
Once I’ve downloaded the app I’m going to go ahead and create a shortcut key just for that application by adding a line to /etc/bookmarks.xml that reads as follows (which would use the z key to open the app):
<bookmark
package=”com.myapp”
class=com.myapp.class”
shortcut=”z” />
Next, I’m going to flip through all of the tables looking for any other settings back in the settings.db that I’d like to change. To look at the options for each table use ‘select * from’ followed by the table name. So if I wanted to look at the SYSTEM table I could use the following command from within the sqlite3 interactive mode for settings.db:
select * from SYSTEM
You can then find a value and edit it as we did earlier but with update instead of insert.
Many of the common commands and tasks that you might be used to are exposed in android. For example, you can edit the /etc/hosts file to force address resolution. Also, while I’m testing my friends applications I’m also monitoring statistics within my Android instance. This is fairly straight forward in some cases as I can simply cat many of the files located in the /proc directory, such as cpuinfo and loadavg.
Looking at these files through VMware while launching an application exposes some of the underlying security framework. Much like the iPhone, processing for a given application is halted when another application is launched. In Android though, each application is written in Java and each runs both as its own Java virtual machine and with its own UID. This isn’t to say that Android applications are sandboxed from one another as in the iPhone when the Activity (screen) is not in the foreground. Instead, there is a framework for background processing with a service. Many of the built in aspects of Android can run as services, although none of the third party applications I was looking at leveraged this component of the Binder (borrowed from BeOS). Any information shared between different applications works via a Content Provider service. If you look at the path for the sqlite3 database, it’s using providers in the path. This isn’t meant to reference cell phone providers but instead the internal’s content providers.
Each application can be considered a risk to install. Therefore, each application has a corresponding AndroidManifest.xml file which provides the rules that the application has to follow along, permissions and a listing of all of the components of the application (binaries, libraries, scripts, etc). Each application can therefore have a component of itself exposed to other applications (typically used for example if you have a chain of applications with permissions between them), with an additional permission of having an application that publicly makes its data available to others. I could see uses for something like this with photo sharing applications but overall it leaves exposure for the manifest to open communications between applications if compromised. I have not been able to thoroughly test whether input validation is available here, but it’s theoretically possible for an application to either obtain elevated privileges from another or to influence the data in another. Granularity of these permissions is possible but must be configured by the developer. I was able to use one of the applications I was testing to access the contacts on the machine, a bit of a concern, but common. Overall, it’s hard to conceive installing any application without a prior thorough review of the manifest if I were working on a production device.
Android is just a trimmed down Linux. I would expect a Chrome OS to be very similar. I don’t even expect it to have much more or much less (although I would assume it will run gears and all of the dependencies of gears). If you replace the Dialer application in Android with Google Voice and add support for an LDAP client then you would have much of what I might expect out of a NetBook OS. If Android is to be tailored to be a NetBook OS I’d like to see Full Disk Encryption for Android as well, even if most data is stored in the cloud. But then, I’d like to see that for all devices… If Android does offer a snapshot into what Google Chrome will look like then it seems like applications written in Java, whether for Blackberry, Palm Pre or Android would likely fairly easily be ported into the platform and therefore be a sandbox worth pursuing assuming that is the case; because while people seem to love the idea of the cloud at the end of the day they seem to also be hooked on their fat clients.