One thing I would like to have is an Open Embedded bitbake recipe for the Android platform layer. What I propose is to:
(1) port the Dalvik VM to a standard linux 2.6 kernel for an ARM target using the Open Embedded toolchain, in the form of a bitbake recipe
(2) provide a GPL verison of the Android Platform API and runtime for an ARM Open Embedded toolchain, in the form of a bitbake recipe
If you examine the Android Architecture below, you will see the areas in blue, the Application Framework and Applications defined. These are the areas that comprise of the public API specification and default Application set defined for Android. While Google has yet to publish the actual specification for Android (they have published APIs, but the Open Handset Alliance hasn't actually published the specs for what constitutes a conformant Android device. My read of the situation is that we only need the layer in blue, to be conformant with the Android specification. This is the layer implemented in the Dalvik bytecode. Google only officially supports and promotes the Java APIs, which are translated into Dalvik bytecode, to execute on the Dalvik VM layer running inside this OS called Android. The native implementation below the blue layer are not part of the spec (or should not be).
This is a hell of a lot of work. So why do it? It solves a problem for people frustrated by (1) android toolchain for systems level development (2) unfamiliar Android's linux distro design as it exists today (3) lack of suppliers of a Free Software version of Android (4) lack ease in generating new configurations build targets (5) lack of roadmap to bring Dalvik VM To standard linux distros like Debian and Redhat. I've done some initial work examining the scope of the porting effort, but would be great to have a core team of folks to work with on this project. Initial approach could be to work backwards. Start by porting to Ubunto or Debian, and get this to a reasonable state running on top of x86, and then move to the harder port, generating the port recipe to the ARM target for the Open Embedded toolchain.
================================================================
Some external validation of this concept, or at least, discussion: comments" title="http://www.engadget.com/2009/05/26/canonical-giving-ubuntu-the-gift-of-android-apps/comments">http://www.engadget.com/2009/05/26/canonical-giving-ubuntu-the-gift-of-a....
================================================================
sidgabriel
Wow. True Dat.
I wrote a short article about that on TheTechnologist.TV: http://thetechnologist.tv/blog/undroid- ... arketplace
Yes. That's lots of work, but could be done. We'd need to get some help, scope out the project really well. Contact the Ubuntu people, get version control and a patch process in place and then push out a very agressive .o1 release and see what bugs and patches come in.
hmm,.. A very good discussion for Thursday night.
Lets all get our initial .02c out here so we can print this thread out Thursday and discuss feasibility.
================================================================
sidgabriel
From OSCON - Android Moblin Ubuntu
http://www.youtube.com/watch?v=XfTMVaKtHEg
================================================================
sidgabriel
After much thought, I have some questions/observations.
1 Is Dalvik worth the work to carve it out?
2 Would the final product meet the *unpublished* Android app capable standard i.e. Will TuneWiki.apk work ok?
3 Should we hold an "Android Expedition" project to scout something like this? A project where we cultivate a list of mysteries in Android architecture that we myth bust our way through one by one?
I want an OS for mobile devices that is free of proprietary concern. That's what I initially thought Android was. Before the API carve out, before Cyanogen. Last week when I was working on the sites and logo, I was visioning that we would eventually have our own .amk extension and a conventional .apk app in the Android Market that enabled android phones to run our .amk apps. To keep the world tidy. You and Coredump9 with his APEX proposal are pointing in the same direction. It's now a matter of alignment, getting the vision out there and drawing in the dev community --because it looks like a lot of work.
It's useful to work from our long term vision in our early group projects. I want to keep Project Tin Man and Apex in the foreground of the Android Makers conversation. I definitely think they should be presented.
That said, there is desire in the group for us to set up a victory and have the members that assemble this Thursday undertake a project together, that can be achieved in the short term, using only the resources we have in the room.
Anticipating division, I think we should position the long term project presentations in a way that doesn't draw available people from short term projects presented.
What do you think? Do you see the same thing?
================================================================
truedat101
Sid, I agree completely, these are huge projects. I would guess the general group's interest is not on some gnarly systems programming and porting project, but on building tangible stuff. So maybe you want to take a straw poll and see what people would like to build.
Long term, there are some big items missing from Android that make it easy for Platform builders to construct new platform configurations, and app builders to design the way they are used to designing. This is where APEX and Tin Man are trying to hit. If you spend even a few hours (ok, like 2 days) building even just the basic console-image for a beagleboard using Open Embedded, you quickly see the power of the Open Embedded toolchain. It's transparent. It has a design methodology. It uses a reasonable build system such that if you understand Python, Make, and autotools, you can almost port anything to work with it. Without a lot of background, any one of us can go and construct a configuration for a beagleboard target with the desired packages as a basis for our work. Android lacks these attributes. Even HTC and Moto had a tough time getting Android to be where they wanted it to be. I wish that Google would have piggy-backed on OE, as Palm did, but clearly they have the Open Source as a business strategy, not for promotion of Software Freedom. That's ok, as they spent a lot of money buying a company and then investing into building an ecosystem around this Android thing.
I don't know that I understand what is being implied building a new application packaging format/extension for android. Does the existing packaging format and metadat lack some feature that we need? Or is this in an effort to create a maker format that we control? I am not clear. Anyway, would be worth digging into more.
================================================================
sidgabriel
I think your ideas are compelling, true to the spirit of the group and timely in industry.
We're going to present everything tomorrow. More presentation than discussion. We'll see what walks in the door and leave plenty of room for ourselves to be blown away. I try to get enough charge in each evening that (in addition to the things we need to get done) anything could happen.
Are you going to present Tin Man? I'm thinking I want to present a project riffing off Tin Man, Apex and Arduino.
Do we have a projector?
Sid
(Credit truedat101, copied from original forum)
