Ubuntu Wiki

• Launchpad Entry: mobile-karmic-android-execution-environment

• Created: April 28th, 2009

• Contributors: Michael Casadevall, Emmet Hikory

• Packages affected: android, linux

Summary

An envionment allowing for experimentation with the Android user interface, and execution of Android-targeted applications will be made available for use in Ubuntu.

Release Note

Ubuntu now allows execution of Android applications, using the Android Execution Environment.

Rationale

Android is increasingly popular, and there are a growing number of Android-targeted applications that may be interesting to Ubuntu users.

Assumptions

• That the necessary Android kernel patches can be sanely merged into the Ubuntu mainline kernel
• That we want to maintain ABI with Android and use their libc in the Android execution environment
• That android actually uses /dev/fb*
• The filesystem can be opened in a mmap()'able way (used by Android; probably needs to see if it can sanely co-exist with anything else)

Design

Android is not an X11 based environment, nor is it based on a standard userland. Therefore to support Android, we need to keep its execution environment separate from the main system, yet be accessible within Ubuntu

Implementation

Kernel Support

• Some bits of the Android kernel will be merged
  • /dev/binder - acts as an IPC for Android processes

Android Execution Environment

• Premade chroot with Android compiled for host environment (x86, arm, etc.)
  • This chroot will be built as a package. Android will require a new platform that doesn't built a kernel, but builds the rest of the environment in production mode
  • The android chroot will exist as /var/lib/android or something similar
  • Android will be modified to either replace the /dev/fb0 calls into an X11 hook, or otherwise wrap them in a way that allows the framebuffer to shown as a window
• Will be available as an application
  • When run, this application pops open a window that will show the Android desktop
• Android Package Files (apk) should be handled by the host system when double clicked; open source Android can't access google's app marketplace thus installation should be possible from the host side
• Only one AEE instance should be running at a given time
• Apps for managing wifi, network and USB interfaces should be removed to prevent conflicts.

UI Changes

• Window for running Android apps
• Manager for installation of apk's outside the android environment

Code Changes

• Android will need a wrapper slipped under it to rewrite UI calls to a X11 window
• All bits of android that manage networking and wifi should be disabled and removed
• kernel support code will have to be merged in

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

It isn't clear to me that the host can or should handle installing android apps. Though Google's Market is not accessible for the open source android, other markets are (AndAppStore, SlideME, Voeveo etc), and apk's can be installed from web sites. Trying to push an app inside android from the host seems tricky and unnecessary. Hmmm - looks like this is more related to Specs/MobileKarmicAndroidPackaging. NealMcBurnett

BOF Notes

* A prototype running on hardy exists already * Building aginst jaunty or later should not be a problem * Kernel config options need to be enabled to make it fully functional

• /dev/binder driver is used by the applications to do secure IPC, today there
  • is a hack in place in our build to not use this device node
• Everything under drivers/staging/android should be enabled...
• No need for the arch-specific code to be integrated yet.

* The current build does not use the android libc but ubuntus glibc

• The android libc is more limited, for using ubuntu having the libc available
  • in a development environment makes sense so apps rolled for android under ubuntu can actually be natively executed

* Native OS services are currently not available to the android apps (no USB

• device access for example)
• libwrap is supposed to act as a plug to provide the infrastructure for native
  • OS services
• no effort has been made to find a filesystem linking setup yet to access
  • users personal folders like Documents/Music/etc

* OEM Services used to work out all of the above and documented it, the

• documentation will move to the ubuntu wiki

* Focus is only on application execution at the moment, not on the core

• android OS
• Create a GUI to handle binding directories inside and out of the android
  • root directory

* Code parts unrelevant for running the applications should be stripped from the

• packaged source
• Upstream uses multiple git trees to manage android source; do we want to
  • import this into LP some how?

* Initial architectures to support: x86 (maybe amd64) and armel. * Hope is that we get a lot of support and interest from the existing android

• community

* all changes need to be proper upstreamed

NEXT STEPS * cleanup including security audit of binder driver * proper packages * find a way to have a runtime enviroment on a per-user base (currently all users

• can access all files, the system just sits in /usr/share)

OPEN ISSUES

• no possibility to host git trees on LP, merging upstream git into a bzr tree
  • will be painful we should go with the git tree but find a way to publically store it
• Possible security issue with /dev/binder as an exploit to crash to take over
  • the system - Runs under normal user but whole android system expects multiple users
• How to get the desktop item in the menu for android apps
• locale info should be able to be passed into the Android runtime environment
  • and get handled properly there
• Access to certain pieces of phone hardware are currently disabled, access to
  • such HW needs to be enabled on the host and handed through to the execution environment
• every application that gets installed gets a new UID, how do we handle this
  • possibly huge amount of users ?

ACTIONS

• Kernel Team: Enable drivers/staging/android in Karmic
• OEM Services to provide the documentation in a public place
• To engage with Android upstream community for core kernel issues

CategorySpec