About Eclair on ADP

[Jean-Baptiste Queru]

Based on the feedback that I've received, it's clear that the aspect
that people are most concerned about at the moment is the ability to
run Eclair on actual development hardware, i.e. ADP1 and ION/ADP2
(I'll collectively call those "ADP" from now on).

In a nutshell, getting an AOSP build on ADP hardware to provide the
same level of framework functionality as the official ADP builds
requires proprietary files from a handful of companies.

Until now, we've had an on-again / off-again ability to run AOSP on
ADP, based on the availability of full system images that would match
the source code. Conceptually, we did that by replacing the
open-source components around those proprietary files, which would
stay unchanged.

With the Eclair code drop, we're currently in an off-again phase,
where the most current version of those proprietary files (1.6)
doesn't work with the most current AOSP source code (Eclair), at least
when considered as a whole.

Part of the work that I did in this past week was to dig into that
situation a bit. I spent most of one day trying to get the system to
build at all with the proprietary files in 1.6, and once I managed to
hack it enough to build, it grossly failed to start. From that point,
I didn't try to figure out whether any of the 17 billion combination
of the 1.6 proprietary files would work and I focused on getting the
source code out.

It would be good as a starting point if the companies that own those
files could release them such that each AOSP contributor could build a
fully functional Eclair image for ADP. Extra points for making those
files redistributable such that the AOSP contributions can easily be
deployed to the enthusiast community and therefore get some testing
before being submitted. Much better would be to have access to the
source code of those components, ideally under a fully open-source
license.

We do want those companies to be friendly to us (i.e. the AOSP
community). Let's not behave like enemies toward them, since
negativity toward them is likely to make them turn their backs on us
instead of opening up. Let's also give them a bit of time: several of
them have never made such a release in the Android ecosystem (or
ever), and I've been working much too fast on the first Eclair code
drop for them to be able to keep up. They're used to thinking in
months or years, and the community thinks in hours and days. Let's
keep in mind that it could take those companies a couple of weeks (or,
sadly, a couple of months) to work through whatever needs to happen on
their side before they can give us what we need. I'm just asking those
companies to give the community a sign that they understand our needs
and that they're going to try to help us.

In the meantime, I think that we can deal with some of the issue on
our own within the AOSP community, on two separate fronts:

-I will create a branch in AOSP based on the current state of master
(i.e. Donut + community contributions), in addition to having an
Eclair-based master.

-We will be working together to try to build a functional version of
an Eclair-based master branch that can run on ADP. The one proprietary
file that gave me a very hard time was one of Qualcomm's camera
libraries, and there's got to be a reasonably simple way to just build
a system without camera support. I'm hoping that with a reasonable
level of effort we'll manage to quarantine all such areas and still
have a system working well enough on hardware that AOSP contributions
in the upcoming Eclair-based master tree will be testable on actual
devices.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Armando Ceniceros]

Hi, I managed something similar when I ported the early released emulator build to the dream. I basically got a device that worked in terms of telephony and data access but media playback and indeed camera were not functional. I feel it safe to asume that because we have the kernel source for the msm7k we can access the chip's radio functions, so that leaves (three?) aspects to focus on; media playback, camera, and graphics hardware acceleration (it seems that now the new launcher requires it). An idea I had was to examine how it is that the latest build (1.6) accesses those necessary drivers and then try to get that code to work on the eclair codebase so that we can at least get that basic functionality. If we had some documentation it would help a lot though, do you think the chip manufacturer's would be willing to, if not share the source, at least share some documentation on the files we have so we can get them working on 2.0? Could be a start

--

You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=.

[wimbet]

Mind sharing which companies exactly need to share their proprietary
code? It would be nice to know so we could help encourage them.

[Jean-Baptiste Queru]

While it's not a huge secret, I'd still rather not point fingers quite
that explicitly.

JBQ

> --
>
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=.
>
>
>

[lbcoder]

Hardware vendors who add customized KERNEL code, i.e. GPL.

[Mike Lockwood]

There is no proprietary code in the ADP kernel at all. That would be
a violation of the GPL. The proprietary code in question is all
userspace.

Mike

> --
>
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=.
>
>
>



--

Mike Lockwood
Google android team