MobileKarmicAndroidPackaging

Summary

With the availability of mobile-karmic-android-execution-environment, both the android runtime should be packaged in a rational manner, and Android applications could be packaged for delivery to users through our existing archive.

Release Note

No release note beyond that for mobile-karmic-android-execution-environment is required.

Rationale

Ubuntu users have become familiar with using package management tools to install and uninstall software. This behaviour should be reinforced by making common applications available for use in the Android Environment.

User stories

Alice wants to experiment with Android, and is able to install a base set of applications to better understand what is available.

Assumptions

Design

There is a core issue in that Android does not have a concept of separate users. The execution model does allow multiple instances of the android runtime to execute, however, and, as noted, it should be possible to have each user have a local ~/.android directory or similar file to store per-user-account android application settings. If this is possible to achieve, then we can install android applications in a common directory, such as /usr/share/android. This is an essential assumption to supporting a model for using debian packaging to insall android applications.

There are two issues. First, there are binary android applications for which there may either be no source archive, or that has license restrictions. It can be possible to wrap/convert such Android binary applications into "installable" debs and treat them the way a proprietary codec might be treated.

Others, that are built from valid sources, should be re-built in Debian as native packages. However, this means the build machines and backends must have an Android "jdk" environment available, and an android jdk along with other android specific build tools would also have to be packaged first.

While we can avoid packaging android applications themselves entirely, and let users run native android applications in the android runtime environment itself, this prevents users from running android "widgets" as part of their desktop experience.

Android applications have a basic dependency system based on who can provide "service X". We can at least partially emulate this using virtual packages with Provides: X and Requires: X in our native Debian packages.

Implementation

In theory, we would have a package that is an android root image template, which would generate per user android runtime instances, we would have a jre and other runtime support packages for android, we would have a jdk and dev packages, and we would have deb's for individual android applications themselves, all represented in our existing archive. We would also initially package those default packages Android comes with, as a model for future work.

UI Changes

The add/remove dialog would have a new category for "Android" runtime and applications on UNR.

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

No migration; new functionality

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

How do we handle applications that package native Android "runtime" components as well as the application itself? These may require a lot of porting work. What about "application store"? Should that be available (assuming business relation with google) in the existing Android execution environment or offered as a native tool? If so, how do applications (many might be proprietary) migrate from Application store to a Debian packaged and accessible archive?

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.

CategorySpec

Specs/MobileKarmicAndroidPackaging (last edited 2009-06-19 20:52:01 by cpe-72-226-207-134)