Android Open-Source Project on devices

197 views
Skip to first unread message

Jean-Baptiste Queru

unread,
Sep 26, 2009, 1:12:30 AM9/26/09
to android-...@googlegroups.com
All right, it's been an memorable week, let's try to move on and be
constructive and talk about how we can make Android better for
everyone.

I explained about readers and writers last week:
http://groups.google.com/group/android-platform/browse_thread/thread/88a7e52e8dd85c5a

As a quick reminder, readers get code from the Android Open-Source
Project to do things with it in private, while writers contribute
patches. Tonight I'll expand a bit on that notion.

Since this is android-platform, I'll focus on the "writer" side of things.

As writers, we're also readers: in order to create good changes, it's
necessary to be able to test those changes (and also to dogfood them,
i.e. to use them exactly the same way a user would use them). So, in
truth, it's a fundamental part of contributing to the Android
Open-Source Project to be able to contribute to it.

The primary target form factor for Android is a phone. That means
that, deep inside, a fundamental part of allowing writers to play
their part is to allow the Android Open-Source Project to be used on
phones. And, by that, I don't just mean that it needs to compile and
boot, i mean that it has to be usable as a day-to-day phone. Right
now, it's not. The range of applications is too limited, the
applications that are in there don't all work, and there are quite a
few system glitches along the way.

Another aspect is that it makes no sense to expect every contributor
to have to apply the same set of manual patches to get to a basic
working state. Android Open-Source Project should be usable "out of
the box" on commonly available hardware.

For now, I still think that the hardware of choice for AOSP is the
ADP1 (i.e. the HTC Dream hardware, i.e. the G1).

So, as a starting point before we can seriously talk about "heavier"
contributions, let's make the Android Open-Source Project work
reasonably on ADP1. In the short term, I believe that it makes the
most sense to start with cupcake, given that we'll have the official
ADP1 1.5 images to compare with.

I have access to the makefiles and other configuration files that are
used to build the official ADP1 images, which will allow to replicate
a similar setup in AOSP.

Who's with me?

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.

Al Sutton

unread,
Sep 26, 2009, 2:11:01 AM9/26/09
to android-platform
I'm on board, but I think we need to define what we're looking to do.

Are we looking to replace current apps with royalty free alternatives
(e.g. Market with AndAppStore), or are we looking to make everything
open source (e.g. replace Market with something that everyone can see
the source)?

Al.

--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

On Sep 26, 6:12 am, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.
>
> I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...

PhaseBurn

unread,
Sep 26, 2009, 2:51:48 AM9/26/09
to android-platform
I'm on board with you, sir... My compiler is your compiler!

On Sep 25, 10:12 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.
>
> I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...

Jey Michael

unread,
Sep 26, 2009, 2:56:06 AM9/26/09
to android-...@googlegroups.com
> Another aspect is that it makes no sense to expect every contributor
> to have to apply the same set of manual patches to get to a basic
> working state. Android Open-Source Project should be usable "out of
> the box" on commonly available hardware.

Of course. After repo syncing, we should just have to do
make & fastboot img files on our G1.

Is that practical or am I over-simplifying?
-Jey

Joe LaPenna

unread,
Sep 26, 2009, 3:05:05 AM9/26/09
to android-...@googlegroups.com
On Fri, Sep 25, 2009 at 11:56 PM, Jey Michael <jey.m...@gmail.com> wrote:
> Of course.   After repo syncing, we should just have to do
> make &  fastboot img files on our G1.
>
> Is that practical or am I over-simplifying?
> -Jey

Jey,

I think thats the start of it. Further enhancements would allow the
community to develop system image configurations containing their
preferred set of system apps with that image, much like various
Makefile tunings that happen in the build steps now.

Message has been deleted

Travis Swanston

unread,
Sep 26, 2009, 1:22:41 AM9/26/09
to android-platform


I'd love to play whatever small role I can, especially if people are
interested in someone testing and cleaning up the build process for
the Magic platform (I don't have a Dream/ADP1 at the moment).

-t

RyeBrye

unread,
Sep 26, 2009, 2:07:55 AM9/26/09
to android-platform


On Sep 25, 11:12 pm, Jean-Baptiste Queru <j...@android.com> wrote:

> As writers, we're also readers: in order to create good changes, it's
> necessary to be able to test those changes (and also to dogfood them,
> i.e. to use them exactly the same way a user would use them). So, in
> truth, it's a fundamental part of contributing to the Android
> Open-Source Project to be able to contribute to it.

Precisely. Open source contributions are (often) powered by selfish
bastards who want to improve things for >themselves<. The nature of
software means that such improvements can be shared freely for a
marginal expense of time.

> The primary target form factor for Android is a phone. That means
> that, deep inside, a fundamental part of allowing writers to play
> their part is to allow the Android Open-Source Project to be used on
> phones. And, by that, I don't just mean that it needs to compile and
> boot, i mean that it has to be usable as a day-to-day phone. Right
> now, it's not. The range of applications is too limited, the
> applications that are in there don't all work, and there are quite a
> few system glitches along the way.


> Another aspect is that it makes no sense to expect every contributor
> to have to apply the same set of manual patches to get to a basic
> working state. Android Open-Source Project should be usable "out of
> the box" on commonly available hardware.

Are you talking about rebuilding hardware libraries for the
proprietary bits on the current phones? I'm no expert, but I can only
imagine the years and years of highly trained computer scientists that
would be necessary to make the LEDs on my phone turn on and off - so I
fully understand why Qualcomm / HTC / Whoever it was decided to make
the lights.so proprietary... Are we to steal fire from the gods and
power our own LEDs with our OWN code?


> For now, I still think that the hardware of choice for AOSP is the
> ADP1 (i.e. the HTC Dream hardware, i.e. the G1).

I agree. It seems geeks like the combination of GSM and a nice
hardware keyboard - so until a better device comes out, the G1 will be
the workhorse of the android geek..


> So, as a starting point before we can seriously talk about "heavier"
> contributions, let's make the Android Open-Source Project work
> reasonably on ADP1. In the short term, I believe that it makes the
> most sense to start with cupcake, given that we'll have the official
> ADP1 1.5 images to compare with.

The official ADP1 images, of course, contain magic bits (gmail,
contacts, youtube, etc) that we don't have and aren't allowed to
redistribute. To recreate a functioning ADP1 are you suggesting we
will be extractinng those bits from an ADP1 image / recreating those
bits / temporarily ignoring that those bits exist in the first place?

> I have access to the makefiles and other configuration files that are
> used to build the official ADP1 images, which will allow to replicate
> a similar setup in AOSP.

I'm curious - with the official ADP1 build do they have some kind of
golden ADP1 that was handed down form Zeus himself from which you plug
into the master build system and then push a button to extract the
divine binaries? Or do they give you guys code? I know you can't
release said code - because... like I mentioned above... if we knew
how to power the LEDs, the next step would be putting them out of
business by making our own phones in our basements... or even worse -
their competitors might learn how to toggle LEDs and then they'd lose
their edge.


> Who's with me?
>
> JBQ

I'm down with it.

Let me clarify what you are suggesting as a first step:

Current steps are (doing this from memory, I might get it wrong)
1. Repo init
2. Repo sync
3. Edit manifests (if necessary)
4. Repo sync
5. do your lunch thing to get your setup for your device
6. extract those magic binaries
7. Pause and reflect on how privileged you are to now have such secret
binaries on your build machine.
8. Build
... (this can take some time, find something else to do)
9. Flash an image on your phone in fastboot (or whatever)

As a first step, which part are you intending to focus on to make it
better for the ADP1 / Dream. Removing some steps to make the initial
process easier? Adding some code to make the end result better?

At the risk of getting too far off topic - governance of such a
project might eventually become an issue. There is a conflict of
interest for Google having a good open source build. It would harm the
GFE (Google Fon Experience) more than just letting some modder
redistribute the apps - it would make it so nobody would want to pay
for the GFE when they could get a better alternative for free. So...
It might be in Google's best interests for some parts of this project
to be taken outside of Google and be built using the GPL or something
so that people might still want to pay for the GFE since if the stuff
that eventually comes out of the oss project is better than the GFE
that Google provides for a fee - at least the GPL could scare them
into still paying google money.

Let me know what some of the first steps are - I can work on cranking
on some builds and flashing them on my phone this weekend.

As much as I like dogfood, I can't say I'm willing to run the AOSP as
my main build for a while (I'm partial to actually having my phone
work) - but I'd be willing to work out build issues and flash the
images on my phone and restore them back... (which brings me to
another point - why not work on integrating nandroid into the aosp?
IMHO that's part of a minimal viable product for any build I'm going
to use is an easy ability to backup and restore the entire phone
state... there's a reason it was one of the first tools developed by
the modding community - it's essential to our day to day activities
for tinkering with these devices)

Anyway... I'll stop now so I don't ramble and get it off topic.

Ryan Gardner
aka "RyeBrye"

Stericson

unread,
Sep 26, 2009, 2:16:23 AM9/26/09
to android-platform
Absolutely, I'm on board.

Stericson

unread,
Sep 26, 2009, 2:19:33 AM9/26/09
to android-platform
I'm on board as well, while just starting to gain a real
understanding of Android I am willing to lend a hand to any project
that will make Android better.

On Sep 26, 12:12 am, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.
>
> I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...

Gray

unread,
Sep 26, 2009, 2:24:37 AM9/26/09
to android-platform
I'm in, although as I posted on my blog, if google doesn't like us
using their apps, I think the change to a new service could be one for
the better. E.G. the ones provided at: http://developer.yahoo.com/everything.html
. I'm sure they would welcome the publicity.

DelsaDj

unread,
Sep 26, 2009, 2:31:26 AM9/26/09
to android-platform
Hi if you need some design help or some music (yes music :P for
notification, ringers.. etc..) I'm here...

W open source

Nico de Vries

unread,
Sep 26, 2009, 2:46:25 AM9/26/09
to android-platform
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.

Isn't it too soon for that yet? Although in theory it will be possible
to replace all proprietary Google applications, it will take some
serious effort to achieve that. Also it is highly unlikely that taking
this aproach would result in something which would become as popular
as CyanogenMod.

We have to be realistic about this. A huge part of what makes Android
viable as a platform is Google. If you take Google out of the picture
(or more accurately if Google takes itself out of the picture) is
there enough left to create something successful? There are platforms
like OpenMoko which are completely operational already. If Google
stays at it's current position it might be more effective to join
forces with existing open source mobile platforms instead of trying to
create a new one.

IMHO it is too soon to draw conclusions yet. There is a big chance
Google comes to its senses and figures out a better approach to this
than their current one. They are smart people. Let's wait a little,
see what happens and they decide how to move on.

amiuhle

unread,
Sep 26, 2009, 3:02:17 AM9/26/09
to android-platform
I think this is a great Idea and I'll be glad to join.

The only thing that is hard to replace is the market though. Of
course, there are already other alternitives, but not every developer
will submit their Apps to several different markets.

Since there are Websites that display Android Market content, it can't
be too hard to reverse engineer the communication between the Market
and Google. But I've noticed that there aren't any sites that offer
the .apk files for download (which is good, I wouldn't want everyone
to be able to download my apk and redistribute it or whatever). Does
anyone know if the apks aren't available anywhere because the site
developers think so too, or because it's not possible?

I'll do some network sniffing tonight or tomorrow, but if anyone has
experience with this, he could help...

amiuhle

On 26 Sep., 07:12, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.
>
> I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...

DelsaDj

unread,
Sep 26, 2009, 3:02:55 AM9/26/09
to android-platform
I'm with you..if need some graphics help...
I made an idea of Android Open-Source Project logo
http://3.bp.blogspot.com/_Ui-2G1RM6GQ/ScP8ejcn5PI/AAAAAAAABBA/mVaJFHHiyKc/s1600-h/tutto.png
:P
Hope you like it :D

Ahmed.S

unread,
Sep 26, 2009, 7:12:28 AM9/26/09
to android-platform
@Jiri: There are two sides of this "Cyanogen disaster", one where
Google makes their point clear that closed source apps should not be
distributed with non-Google exp roms (e.g. CM, Jacs, Xrom, etc), while
the xda-community in particular is up in arms because the very roms
being distributed, granted with closed source apps, are for the very
Google Experience devices that are already licensed and paid for (G1,
MyTouch).
The problem perhaps comes from those G1/myTouch roms being distributed
to non-Google Experience devices. The latter term is still to date
debated in the community. Bottom line, Google has an excellent pool of
bleeding edge testers at their finger tips in the xda-dev community.
They should really tap into this resource and make things official
i.e. some level of licensing agreement for non-profit orgs.

@JBQ: I am in agreement on this approach, but having a common
Application Market instead of a hodge podge of slideme, Anda.pk, etc
is polluting the over all Android experience. AOSP, however, should
otherwise be available out of the box with basic phone features (SMS/
MMS, Voice, Contacts) and Google application features such as Youtube,
Gmail/Email, Sync, etc. These might not have been a necessity in the
past, but having been spoilt initially with the G1, most users will
seek alternatives at the least.
Over the course of the last year, Android has evolved a lot, and some
of the Free Apps in the market have really become permanent downloads
on every new wipe or new setup (Real Phone Backup aka Nandroid, SMS
Backup, etc). There should be room to include critical functionality
for developers, specially the ability to fully backup their system, a
functionality which is only served by a cooked recovery image. There's
so much more to write about, but this should suffice for now.

Fred Grott

unread,
Sep 26, 2009, 8:52:11 AM9/26/09
to android-...@googlegroups.com
Count me in..

Jean-Baptiste Queru

unread,
Sep 26, 2009, 9:59:50 AM9/26/09
to android-...@googlegroups.com
At the technical level, I think that we'll be exploring a few directions:

-the port(s): like Jey said, in an ideal world we'd be able to repo
sync, make, and fastboot onto a G1 (or on any other device that is or
becomes relevant for AOSP). I'm in a position to take care of the repo
sync part, and we can improve the "make" part itself (fastboot is
already working).

-the current set of apps: we will properly configure the set of apps
that are built in the default AOSP build (e.g. we're missing the Email
app), and we'll configure them and fix the bugs that prevent them from
working properly in the existing configuration.

-apps that aren't currently into AOSP: I think that we'll be looking
at a few options:

(1) working with the existing Google apps as they exist on the ADP1,
within the limits set by the license for those apps as can be found on
HTC's web site (and that obviously prevents redistributing images, so
it creates its own set of concerns).

(2) including or creating some new redistributable binaries that are
hosted in AOSP.

(3) including or creating some new open-source components that are
hosted in AOSP.


To expicitly answer Al's question, I'm open to having non-open-source
bits in there, but I'll look at a few aspects:
-the conditions under which those bits are redistributable.
-how essential those bits are to the operation of other components,
and especially open-source components.
-whether there exist practical open-source replacements.


About Gray's question and writing apps that would access non-Google
equivalents of the ADP1 apps: I think that the people who'll get
involved here are more likely to have Google accounts than just about
any other account, i.e. that apps that interoperate with Google are
likely to be more valuable than apps that interoperate with other
services. Also, to be frank, Google pays the bill for a lot of Android
(including my own salary).


About amiuhle comments on the way Market works: let's not go down the
line of reverse-engineering the Market protocol or any other
undocumented Google protocol for the purposes of AOSP. If Google makes
Market available for community images, we'll use that. If we can use
the Market app without making unauthorized copies, we'll use that. If
Google documents the protocol itself (along with whatever keys might
be necessary), we'll use that. If it's practical to consider
alternative sources for apps, we'll use that (and that's not mutually
exclusive with using Market).

Jean-Baptiste Queru

unread,
Sep 26, 2009, 10:27:03 AM9/26/09
to android-...@googlegroups.com
On Fri, Sep 25, 2009 at 11:07 PM, RyeBrye <rye...@gmail.com> wrote:

> Are you talking about rebuilding hardware libraries for the
> proprietary bits on the current phones? I'm no expert, but I can only
> imagine the years and years of highly trained computer scientists that
> would be necessary to make the LEDs on my phone turn on and off - so I
> fully understand why Qualcomm / HTC / Whoever it was decided to make
> the lights.so proprietary... Are we to steal fire from the gods and
> power our own LEDs with our OWN code?

I'd be fine re-using the existing files if that can be done within the
limits sets by the respective license (or, better, if that can be done
without copying said files at all).

> The official ADP1 images, of course, contain magic bits (gmail,
> contacts, youtube, etc) that we don't have and aren't allowed to
> redistribute. To recreate a functioning ADP1 are you suggesting we
> will be extractinng those bits from an ADP1 image / recreating those
> bits / temporarily ignoring that those bits exist in the first place?

I know that the devil is in the details, but my master plan is to that
those apps are already on the ADP1 (or can be put there legally), so
all we need to do is to change the rest of the system around those
apps without touching the apps themselves.

> I'm curious - with the official ADP1 build do they have some kind of
> golden ADP1 that was handed down form Zeus himself from which you plug
> into the master build system and then push a button to extract the
> divine binaries? Or do they give you guys code? I know you can't
> release said code - because... like I mentioned above... if we knew
> how to power the LEDs, the next step would be putting them out of
> business by making our own phones in our basements... or even worse -
> their competitors might learn how to toggle LEDs and then they'd lose
> their edge.

I some cases, Google has source code access to those files. In most
cases though, we only get binaries, and we consider those as
prebuilts, using makefiles that aren't fundamentally different from
the ones in dream-open (though a bit more verbose). The big difference
is that we (Google) can store the actual files in the source
repository.

> Current steps are (doing this from memory, I might get it wrong)
> 1. Repo init
> 2. Repo sync
> 3. Edit manifests (if necessary)
> 4. Repo sync
> 5. do your lunch thing to get your setup for your device
> 6. extract those magic binaries
> 7. Pause and reflect on how privileged you are to now have such secret
> binaries on your build machine.
> 8. Build
> ...  (this can take some time, find something else to do)
> 9. Flash an image on your phone in fastboot (or whatever)
>
> As a first step, which part are you intending to focus on to make it
> better for the ADP1 / Dream. Removing some steps to make the initial
> process easier? Adding some code to make the end result better?

I cleaned up the initial setup, so that there's no need for two syncs
or manually editing manifests.

> At the risk of getting too far off topic - governance of such a
> project might eventually become an issue. There is a conflict of
> interest for Google having a good open source build. It would harm the
> GFE (Google Fon Experience) more than just letting some modder
> redistribute the apps - it would make it so nobody would want to pay
> for the GFE when they could get a better alternative for free. So...
> It might be in Google's best interests for some parts of this project
> to be taken outside of Google and be built using the GPL or something
> so that people might still want to pay for the GFE since if the stuff
> that eventually comes out of the oss project is better than the GFE
> that Google provides for a fee - at least the GPL could scare them
> into still paying google money.

I'll assume here that the changes that make a good open-source build
will be made, somewhere, by someone. Google has no interest in seeing
those changes be made on a forked version of Android: the closer those
are made to AOSP, the more Google can use those changes in
Google-Experience devices. Google will want to be able to specifically
mark the code drops that come from the internal repository and match
official releases, and such a mechanism already exists today.

> Let me know what some of the first steps are - I can work on cranking
> on some builds and flashing them on my phone this weekend.
>
> As much as I like dogfood, I can't say I'm willing to run the AOSP as
> my main build for a while (I'm partial to actually having my phone
> work) - but I'd be willing to work out build issues and flash the
> images on my phone and restore them back... (which brings me to
> another point - why not work on integrating nandroid into the aosp?
> IMHO that's part of a minimal viable product for any build I'm going
> to use is an easy ability to backup and restore the entire phone
> state... there's a reason it was one of the first tools developed by
> the modding community - it's essential to our day to day activities
> for tinkering with these devices)

I'm cool with a full-system-backup utility as part of the suite of
development tool. That's a very legitimate tool for the exact use case
that you're mentioning.

>
> Ryan Gardner
> aka "RyeBrye"

William

unread,
Sep 26, 2009, 9:53:37 AM9/26/09
to android-platform
I can't program but I will gladly test the Roms for bugs and report
them on a MyTouch3G and a DreamG1

rich0

unread,
Sep 26, 2009, 10:12:02 AM9/26/09
to android-platform
On Sep 26, 2:11 am, Al Sutton <a...@funkyandroid.com> wrote:
> Are we looking to replace current apps with royalty free alternatives
> (e.g. Market with AndAppStore), or are we looking to make everything
> open source (e.g. replace Market with something that everyone can see
> the source)?

My fear with the latter approach is that this will be a purely
experimental project for a very long time (perhaps a year) - with
almost zero end-user participation. If you want to get rid of the
closed binary hardware drivers, market, google sync, etc, that could
become a real mess if you did it all at once.

Here is a different approach:

1. You check out the source distribution.
2. You add in specific binary blobs (with the distro indicating what
versions/md5sums are supported of each). Where you get them is your
own business (ideally from your own phone).
3. The build has a nice interface for configuring it, and is highly
automated.

The source distro should be tagged with releases as if it were an
actual end-product - we don't want end-users running HEAD.

As open-source alternatives become available you can begin reducing
the footprint of binary blobs. However, the final product is usable
at all stages and involves no unlicensed distribution of code.

There is really nothing to keep completely end-users locked out
either. Stable source releases could be created with simple GUIs that
automate their use (for any major OS). Users would just follow some
packaged instructions, and scripts would direct them to the
appropriate websites to get the SDK or whatever they need, help them
root their device, direct them through the bootloader flashing, copy
off the needed proprietary drivers, take backups, and then build the
new firmware. In the beginning this would of course be manual, but
there is no reason most of it couldn't be automated other than hitting
agree on some EULAs for the SDK/etc.

Mr. Moe

unread,
Sep 26, 2009, 10:19:03 AM9/26/09
to android-platform
I have an extra G1 that I am keeping as a back up in the event my
MYtouch takes a dump, but if you guys need a tester, I am definitely
in to help test on my Rooted G1.

On Sep 25, 10:12 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.
>
> I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...

Anthony

unread,
Sep 26, 2009, 10:25:19 AM9/26/09
to android-platform
We're all with you, JBQ.

On Sep 26, 12:12 am, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.
>
> I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...

Jean-Baptiste Queru

unread,
Sep 26, 2009, 10:41:41 AM9/26/09
to android-...@googlegroups.com
Some good ideas in there. I'd love to use recovery as the primary tool
to do whatever steps need to be done by each individual user (if only
for the simple reason that we only need to write it once!).

How about something like this:

-the recovery script verifies that all the files it wants to preserve
are present and have the proper checksums.
-it then deleted all the other files.
-finally, it writes the distributable files as were downloaded by the
user in a single update.zip.

I'm not an expert in what recovery can and cannot do right now, but
this really only sounds like a special case of an incremental update,
so it might be possible handle this with the stock recovery code.

JBQ

Disconnect

unread,
Sep 26, 2009, 10:43:01 AM9/26/09
to android-...@googlegroups.com
(What Ryebrye said)

In the interests of actual open source, will you be accepting patches
with GPL/LGPL licenses? I don't think anyone would find it fair to do
a bunch of coding to replace proprietary blobs, only to have it get
sucked right back into the closed source tree..

Jean-Baptiste Queru

unread,
Sep 26, 2009, 10:52:26 AM9/26/09
to android-...@googlegroups.com
I'm not fundamentally opposed to it. There's a precedent for (L)GPL
code hosted by AOSP that doesn't get merged into Google's tree (some
of the alsa code).

If such code adds independent functionality, that should be fine. If
such code replaces/augments some existing non-(L)GPL code, we'll need
to be careful that the non-(L)GPL variant should still work as well.

Of course, using (L)GPL code raises the bar for such code to be
included in mainstream consumer devices, so I'd feel more comfortable
if the additional "cost" of using (L)GPL code was justified by the
additional functionality of the code in question.

JBQ

Disconnect

unread,
Sep 26, 2009, 10:58:43 AM9/26/09
to android-...@googlegroups.com
The bar is already raised - (L)GPL code on our side just matches it.
("You can't use our bins without permission but we'll feel free to
take your source, thanks..")

Fred Grott

unread,
Sep 26, 2009, 11:11:42 AM9/26/09
to android-...@googlegroups.com
Disconnect: "You can't use our bins without permission but we'll feel free to
take your source, thanks.."

That opinion is not  born out by facts and lets keep on topic here as its more constructive..

And please remember there are some FSF, ASF and other open source org members in conversation on this thread..I  happen to be a FSF member..

Disconnect

unread,
Sep 26, 2009, 11:58:48 AM9/26/09
to android-...@googlegroups.com
On Sat, Sep 26, 2009 at 11:11 AM, Fred Grott <fred....@gmail.com> wrote:
> Disconnect: "You can't use our bins without permission but we'll feel free
> to take your source, thanks.."
>
> That opinion is not  born out by facts and lets keep on topic here as its
> more constructive..

Lets see what others say, but personally I have no desire to permit
google to have it's cake and eat it too - if we are forced to make
open reimplementations for existing closed parts of the "open"
platform, they should remain open and not be incorporated into the
closed source binaries.  We're not talking about extending/expanding
the platform. We're talking about REDOING work that has already been
done and has been locked away.

If there is no intent to carry that source into the closed binaries,
then there is no reason to care that it is under a more restrictive
license (so long as the license permits it to be distributed - we have
enough unredistributable mess already.)

And I missed it if there was an answer to Ryebrye's questions - are we
talking about email/calendar/provisioning/.. or are we talking about
the elephant^W hardware interfaces like rild?

> And please remember there are some FSF, ASF and other open source org
> members in conversation on this thread..I  happen to be a FSF member..

..Thats nice? (I'm missing the point of that.)

Adolfo

unread,
Sep 26, 2009, 12:24:50 PM9/26/09
to android-platform
I apologize in advance if this has already been suggested in different
words, but at this time I am just thinking selfishly of the next
immediate step. First of all id like to bring my adp back to
compliance with Google's TOS.
On the other hand, on of my favorite parts of testing CM was running
the 1 click updater to see if any new builds were out. The simplicity
of not having to wipe, etc. was great.

So basically what I'm getting at is what if there was a similar app
for updating the adp with the latest sdk source, un-modded? To keep up
with testing the latest sources, but also in keeping with Google's TOS?

Jean-Baptiste Queru

unread,
Sep 26, 2009, 12:29:10 PM9/26/09
to android-...@googlegroups.com
I think that's a fair point. I'm not a historian, but I seem to recall
that GNU & GPL were originally created in similar conditions (or at
least out of similar concerns), and there's no need to re-invent that
wheel.

JBQ

Al Sutton

unread,
Sep 26, 2009, 12:49:25 PM9/26/09
to android-...@googlegroups.com
I think one of the key decision is do we just want to re-do the closed
source parts?

I'm sure a lot of people would be equally interested in a HotMail
client, Maps powered by Yahoo, etc., etc.

Al.
--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

Jean-Baptiste Queru

unread,
Sep 26, 2009, 1:03:17 PM9/26/09
to android-...@googlegroups.com
As much as possible I'd like to start by re-using the existing apps.
It's been clearly established that they can't be redistributed, but
using in an ADP1 the apps that were meant to be used in an ADP1,
without modifying them or copying them, by just changing the system
under their "feet", sounds like the fastest way to get to a level of
functionality similar to what cyanogen had managed to put together.

On Saturday, September 26, 2009, Al Sutton <a...@funkyandroid.com> wrote:
>
> I think one of the key decision is do we just want to re-do the closed
> source parts?
>
> I'm sure a lot of people would be equally interested in a HotMail
> client, Maps powered by Yahoo, etc., etc.
>
> Al.
> --
>
> * Looking for Android Apps? - Try http://andappstore.com/ *
>
> ======
> Funky Android Limited is registered in England & Wales with the
> company number  6741909. The registered head office is Kemp House,
> 152-160 City Road, London,  EC1V 2NX, UK.
>
> The views expressed in this email are those of the author and not
> necessarily those of Funky Android Limited, it's associates, or it's
> subsidiaries.
>
> On 26 Sep 2009, at 16:58, Disconnect wrote:
>
>>
>> On Sat, Sep 26, 2009 at 11:11 AM, Fred Grott <fred....@gmail.com>
>> wrote:
>>> Disconnect: "You can't use our bins without permission but we'll
>>> feel free
>>> to take your source, thanks.."
>>>
>>> That opinion is

--

Al Sutton

unread,
Sep 26, 2009, 1:08:27 PM9/26/09
to android-...@googlegroups.com
Have we got a definitive list of all the apps we're talking about?

Al.
--

* Looking for Android Apps? - Try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number 6741909. The registered head office is Kemp House,
152-160 City Road, London, EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.

Jean-Baptiste Queru

unread,
Sep 26, 2009, 1:32:03 PM9/26/09
to android-...@googlegroups.com
Off-hand, the list of Google apps should be more-or-less: market,
gmail, maps, gtalk, setupwizard, and the sync back-ends for them.

The build process generates the list of the files for every build.
I'll get the list of files for the ADP1 and we can compare it to
what's build in AOSP and start from there.

JBQ

On Saturday, September 26, 2009, Al Sutton <a...@funkyandroid.com> wrote:
>
> Have we got a definitive list of all the apps we're talking about?
>
> Al.
> --
>
> * Looking for Android Apps? - Try http://andappstore.com/ *
>
> ======
> Funky Android Limited is registered in England & Wales with the
> company number  6741909. The registered head office is Kemp House,
> 152-160 City Road, London,  EC1V 2NX, UK.
>
> The views expressed in this email are those of the author and not
> necessarily those of Funky Android Limited, it's associates, or it's
> subsidiaries.
>
> On 26 Sep 2009, at 18:03, Jean-Baptiste Queru wrote:
>
>>
>> As much as possible I'd like to start by re-using the existing apps.
>> It's been clearly established that they can't be redistributed, but
>> using in an ADP1 the apps that were meant to be used in an ADP1,
>> without modifying them or copying them, by just changing the system
>> under their "feet", sounds like the fastest way to get to a level of

>> functionality similar to what cyanogen had ma--~-

Ryan Gardner

unread,
Sep 26, 2009, 1:45:44 PM9/26/09
to android-...@googlegroups.com

Don't forget youtube! (I need my keyboard cat and android hitler videos!)

On Sep 26, 2009 11:32 AM, "Jean-Baptiste Queru" <j...@android.com> wrote:


Off-hand, the list of Google apps should be more-or-less: market,
gmail, maps, gtalk, setupwizard, and the sync back-ends for them.

The build process generates the list of the files for every build.
I'll get the list of files for the ADP1 and we can compare it to
what's build in AOSP and start from there.

JBQ

On Saturday, September 26, 2009, Al Sutton <a...@funkyandroid.com> wrote: >

> Have we got a definitive list of all the apps we're talking about? > > Al. > -- > > * Looking for ...

>> functionality similar to what cyanogen had ma--~-

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

Jean-Baptiste Queru

unread,
Sep 26, 2009, 2:01:58 PM9/26/09
to android-...@googlegroups.com
Oh, oops, yeah! I guess that everybody now knows that I don't use
youtube much on the phone.

Anyway, I'd bet that there are some more that I forgot, it's such a
large system that it's pretty much impossible to remember every single
file... and that's why we have the build system generate the file list
each time.

JBQ

On Saturday, September 26, 2009, Ryan Gardner <rye...@gmail.com> wrote:
> Don't forget youtube! (I need my keyboard cat and android hitler videos!)

> On Sep 26, 2009 11:32 AM, "Jean-Baptiste Queru" <j...@android.com <javascript:_e({}, 'cvml', 'j...@android.com');>> wrote:
>
>
> Off-hand, the list of Google apps should be more-or-less: market,
> gmail, maps, gtalk, setupwizard, and the sync back-ends for them.
>
> The build process generates the list of the files for every build.
> I'll get the list of files for the ADP1 and we can compare it to
> what's build in AOSP and start from there.
>
> JBQ
>

> On Saturday, September 26, 2009, Al Sutton <a...@funkyandroid.com <javascript:_e({}, 'cvml', 'a...@funkyandroid.com');>> wrote:
>>
>> Have we got a definitive list of all the apps we're talking about?
>>
>> Al.
>> --
>>
>> * Looking for ...>> functionality similar to what cyanogen had ma--~-
>

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

Questions sent directly to me that have no reason for being private

Shane Isbell

unread,
Sep 26, 2009, 10:55:13 AM9/26/09
to android-platform
We are willing to open-source SlideME Market client (SAM). We are all
heavily into open-source. Henrique, our portal architect, is the
project lead for the Drupal AWS module project and puts all of our AWS
integration code here (http://bit.ly/j6Ci). I'm also founder of Masa
Maven plugins for Android - http://code.google.com/p/masa/

SAM has always been the one piece we have had trouble generating an
developer interest for. We started as open-source (http://
code.google.com/p/slideme/) but eventually closed it down due to no
community interest. If there is community interest (and by this I mean
people willing to work on the code because they see a need), I'll re-
open it as ASL 2.0. The code needs TLC and there is a lot of room
feature improvements. Of course with this, we would publish the specs
for our catalog interaction.

Henrique can expose any APIs from our portal that the community would
need for additional features such as comment and ratings, which I
haven't had time to add (I also handle a lot of the business side of
SlideME).

SAM has already passed QA at HTC and is distributed on-device in some
regions. You can see some screenshots here: http://slideme.org/sam SAM
supports catalog screenshots, video, paid applications, etc. I think
we do a lot of things better than Android Market and with community
development, I can see it going much, much further.


Thanks,
Shane

wpc

unread,
Sep 26, 2009, 11:15:46 AM9/26/09
to android-platform
I will lend my hand if this project need a java developer. :-)

My suggestion is after remove close source stuff from the build, and
before we have replacement for them, there should be an instruction
somewhere to help end user get them by themselves. ( I hope an
instruction isn't illegal. :-)), so we do not redistribute it but user
still can still use the rom very soon.


On Sep 26, 1:12 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> All right, it's been an memorable week, let's try to move on and be
> constructive and talk about how we can make Android better for
> everyone.
>
> I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...

Andy

unread,
Sep 26, 2009, 11:23:49 AM9/26/09
to android-platform
I am with you as well.

I may not be a programmer (still learning), but i will gladly test
software.


On Sep 26, 12:12 am, Jean-Baptiste Queru <j...@android.com> wrote

schwiz

unread,
Sep 26, 2009, 11:40:27 AM9/26/09
to android-platform
I like what you are doing here, I feel like we have about a years
setback here but I appreciate your effort, I myself am a very green
developer, only a sophomore in undergrad school but I am enthusiastic
and more than willing to help where ever possible.

cmisak - www.cmisak.com

unread,
Sep 26, 2009, 11:48:55 AM9/26/09
to android-platform
I'm in, not sure i'm as gifted in programming as the others in this
post but I am a graphic designer and love to beta / alpha test

I'll throw everything I can into this project.



On Sep 26, 9:43 am, Disconnect <dc.disconn...@gmail.com> wrote:
> (What Ryebrye said)
>
> In the interests of actual open source, will you be accepting patches
> with GPL/LGPL licenses? I don't think anyone would find it fair to do
> a bunch of coding to replace proprietary blobs, only to have it get
> sucked right back into the closed source tree..
>
>
>
> On Sat, Sep 26, 2009 at 1:12 AM, Jean-Baptiste Queru <j...@android.com> wrote:
>
> > All right, it's been an memorable week, let's try to move on and be
> > constructive and talk about how we can make Android better for
> > everyone.
>
> > I explained about readers and writers last week:
> >http://groups.google.com/group/android-platform/browse_thread/thread/...

Dan Ballance

unread,
Sep 26, 2009, 1:06:07 PM9/26/09
to android-...@googlegroups.com

I think trying to re-create the closed google binaries might be a mistake because I think it could be pretty de-motivating work and if it doesn't seem new and exciting it may be difficult to recruit developrs to volunteer to do the work.

Maybe we should be looking to innovate a bit and take a different angle. That way we don't create a poor man's google clone but do something radical and new - where the open source scene shines at it's best?

Google Wave is an open technology, is it not? What about developing a wave client and getting in there quick with something new?

Just a thought, following the group with great interest,

Dan :-)

On 26 Sep 2009 17:49, "Al Sutton" <a...@funkyandroid.com> wrote:


I think one of the key decision is do we just want to re-do the closed
source parts?

I'm sure a lot of people would be equally interested in a HotMail
client, Maps powered by Yahoo, etc., etc.

Al.
--

* Looking for Android Apps? - Try http://andappstore.com/ *

====== Funky Android Limited is registered in England & Wales with the company number 6741909. The...

coolbho3k

unread,
Sep 26, 2009, 1:19:49 PM9/26/09
to android-platform
This thread contains a list of relevant APKs and framework files. I'm
not sure if it's complete.

http://forum.xda-developers.com/showthread.php?t=564744
> >>> On Sat, Sep 26, 2009 at 11:11 AM, Fred Grott <fred.gr...@gmail.com>

David Chang

unread,
Sep 26, 2009, 1:37:58 PM9/26/09
to android-...@googlegroups.com
I'm new to the thread, but I'm definitely up for giving a helping hand with some code. 
One question: Are the calendar and contact list synchronization options closed source?

jer

unread,
Sep 26, 2009, 2:01:46 PM9/26/09
to android-platform
On Sep 26, 9:49 am, Al Sutton <a...@funkyandroid.com> wrote:

> I'm sure a lot of people would be equally interested in a HotMail  
> client, Maps powered by Yahoo, etc., etc.

Pretty early on yesterday I saw people calling for sending a nice
clear F-U to Google by replacing all the Google bits with Bing/MSN/
etc. This idea initially made me mad, because it seemed so
unconstructive and petty. However, it has now occurred to me that
Yahoo has a contacts API, an IM client, email etc as well as
Microsoft, and that people would probably really like to be able to
choose a service other than Google's for use on their phone. To the
point that even manufacturers and carriers might like being able to
choose that decision at deployment time.

I think abstracting things such that other services could be routinely
added as they arise would be a really, really slick thing to have.

Emilian Trela

unread,
Sep 26, 2009, 2:15:41 PM9/26/09
to android-...@googlegroups.com

Sorry guys... i tell short. .. i think problem is with "Google honor" donut from cyan, i think is better.  This is problem.  Shy shy and shy

On 2009 9 26 20:02, "Jean-Baptiste Queru" <j...@android.com> wrote:


Oh, oops, yeah! I guess that everybody now knows that I don't use
youtube much on the phone.

Anyway, I'd bet that there are some more that I forgot, it's such a
large system that it's pretty much impossible to remember every single
file... and that's why we have the build system generate the file list
each time.

JBQ

On Saturday, September 26, 2009, Ryan Gardner <rye...@gmail.com> wrote: > Don't forget youtube! (I...

> On Sep 26, 2009 11:32 AM, "Jean-Baptiste Queru" <j...@android.com <javascript:_e({}, 'cvml', 'jbq@a...

> On Saturday, September 26, 2009, Al Sutton <a...@funkyandroid.com <javascript:_e({}, 'cvml', 'al@fun...

Questions sent directly to me that have no reason for being private will likely get ignored or forwa...

You received this message because you are subscribed to the Google Groups "android-platform" group. ...

Fred Grott

unread,
Sep 26, 2009, 2:35:18 PM9/26/09
to android-...@googlegroups.com
what are the chances we can coordinate with FSF' replicant project?

http://groups.fsf.org/wiki/LibrePlanet:LibrePlanetItalia/replicant

Mark Murphy

unread,
Sep 26, 2009, 3:18:00 PM9/26/09
to android-...@googlegroups.com
Sheesh. I go offline for ~24 hours and a movement erupts while I'm gone.
Clearly, the solution for all Android's woes is for me to take more
transatlantic flights... ;-)

JBQ, thank you very much for this initiative. I owe you a case of something.

I'm certainly open for helping @ the app-replacement level -- I haven't
touched C code in nearly a decade and still have nightmares, being
attacked by dangling pointers and such.

I also may be able to help with documentation, as I've been known to
write a bit, off and on.

Just point me in a direction.

Dan Ballance wrote:
> Google Wave is an open technology, is it not? What about developing a
> wave client and getting in there quick with something new?

The simplest Wave client is an HTML5-compliant browser and the stock
Wave client. Wave is definitely designed with HTML5 in mind; it's
unclear to me if a full-featured non-browser client is even practical.

That being said, I don't know where mobile WebKit stands vis a vis HTML5
compliance, and where Android is vis a vis mobile WebKit versions.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android App Developer Books: http://commonsware.com/books.html

Mark Murphy

unread,
Sep 26, 2009, 3:25:06 PM9/26/09
to android-...@googlegroups.com
Al Sutton wrote:
> I think one of the key decision is do we just want to re-do the closed
> source parts?
>
> I'm sure a lot of people would be equally interested in a HotMail
> client, Maps powered by Yahoo, etc., etc.

I'm sure they would be, but why can't those be just ordinary Android apps?

I'm far from a firmware expert (and I mean *really* far), but I would
think the driver issue is the more critical nut to crack, per some of
Disconnect's posts.

Josh Steiner

unread,
Sep 26, 2009, 4:10:33 PM9/26/09
to android-...@googlegroups.com
Now this is awesome, so much excitement so soon.  I'll commit to at least building from AOSP and trying to dogfood this a little bit, maybe do a bit of QA and hopefully a little coding as I'm able.

-Josh

On Fri, Sep 25, 2009 at 10:12 PM, Jean-Baptiste Queru <j...@android.com> wrote:

All right, it's been an memorable week, let's try to move on and be
constructive and talk about how we can make Android better for
everyone.

I explained about readers and writers last week:
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private

Pascal Merle

unread,
Sep 26, 2009, 6:37:43 PM9/26/09
to android-platform
> In the short term, I believe that it makes the
> most sense to start with cupcake, given that we'll have the official
> ADP1 1.5 images to compare with.

I don't think it's worthwhile to be able to re-build former versions
of the ROMs.
Of course you could try some modifications, but you want to test the
actual master trunk.

Extracting/preserving the Google apps will not help then. You need
access to the development versions of them, already adapted to new
changes in the API etc.

It would be interesting to know where cyanogen got his images of the
closed source apps from. Maybe leaked from some preview devices? So we
will probably don't get around including open source replacements for
the basic components:

- G1 proprietary drivers
- Market
- Contacts/Calender sync.
- Maps

Pascal Merle

unread,
Sep 26, 2009, 7:20:45 PM9/26/09
to android-platform
> Don't forget youtube! (I need my keyboard cat and android hitler videos!)

Seriously there is no need for that app. You can watch your videos
from the youtube website without any problems thru opencore.

Gergely Kis

unread,
Sep 26, 2009, 8:02:46 PM9/26/09
to android-...@googlegroups.com
Hi,

As far as I know, currently the "building for dream" process has an
"officially supported" step to extract the necessary binaries (Dream
specific drivers) from the actual device. Is this process only allowed
for those exact files, or could be extended to also support the apk
files of the closed, non-redistributable apps?

I was thinking about the following process:

Building:
- add a new build target which creates a sort of intermediate build
result. Basically everything, except for the non-redistributable files
in a zip
- extract the non-redistributable files from the phone, and build
- distribute the intermediate build result

Installing:
- a special setup tool could be created which would have a nice GUI
for end users. It would take the intermediate build result + downloads
the non-redistributable files and builds the actual flashable images
- Install the resulting image as usual. (As an option the setup tool
could integrate fastboot support to provide a nicer interface for end
users.)

Wouldn't this be easier, than trying to add special handling to the
recovery process, just to work around a licensing limitation?

Best Regards,
Gergely

On Sat, Sep 26, 2009 at 4:41 PM, Jean-Baptiste Queru <j...@android.com> wrote:
>
> Some good ideas in there. I'd love to use recovery as the primary tool
> to do whatever steps need to be done by each individual user (if only
> for the simple reason that we only need to write it once!).
>
> How about something like this:
>
> -the recovery script verifies that all the files it wants to preserve
> are present and have the proper checksums.
> -it then deleted all the other files.
> -finally, it writes the distributable files as were downloaded by the
> user in a single update.zip.
>
> I'm not an expert in what recovery can and cannot do right now, but
> this really only sounds like a special case of an incremental update,
> so it might be possible handle this with the stock recovery code.
>
> JBQ
>
> On Sat, Sep 26, 2009 at 7:12 AM, rich0 <freem...@gmail.com> wrote:
>>
>> On Sep 26, 2:11 am, Al Sutton <a...@funkyandroid.com> wrote:
>>> Are we looking to replace current apps with royalty free alternatives
>>> (e.g. Market with AndAppStore), or are we looking to make everything
>>> open source (e.g. replace Market with something that everyone can see
>>> the source)?
>>
>> My fear with the latter approach is that this will be a purely
>> experimental project for a very long time (perhaps a year) - with
>> almost zero end-user participation.  If you want to get rid of the
>> closed binary hardware drivers, market, google sync, etc, that could
>> become a real mess if you did it all at once.
>>
>> Here is a different approach:
>>
>> 1.  You check out the source distribution.
>> 2.  You add in specific binary blobs (with the distro indicating what
>> versions/md5sums are supported of each).  Where you get them is your
>> own business (ideally from your own phone).
>> 3.  The build has a nice interface for configuring it, and is highly
>> automated.
>>
>> The source distro should be tagged with releases as if it were an
>> actual end-product - we don't want end-users running HEAD.
>>
>> As open-source alternatives become available you can begin reducing
>> the footprint of binary blobs.  However, the final product is usable
>> at all stages and involves no unlicensed distribution of code.
>>
>> There is really nothing to keep completely end-users locked out
>> either.  Stable source releases could be created with simple GUIs that
>> automate their use (for any major OS).  Users would just follow some
>> packaged instructions, and scripts would direct them to the
>> appropriate websites to get the SDK or whatever they need, help them
>> root their device, direct them through the bootloader flashing, copy
>> off the needed proprietary drivers, take backups, and then build the
>> new firmware.  In the beginning this would of course be manual, but
>> there is no reason most of it couldn't be automated other than hitting
>> agree on some EULAs for the SDK/etc.

Jim Ancona

unread,
Sep 26, 2009, 8:40:34 PM9/26/09
to android-platform
I'm a contributor to the Android-on-Freerunner project (http://
code.google.com/p/android-on-freerunner/) which has a similar goal,
creating a usable open source Android distribution for the Openmoko
Neo Freerunner, a phone with a completely open source software stack
(see http://openmoko.org/). We have a working, but somewhat buggy,
Cupcake release out, with none of the proprietary bits. I'm happy to
help contribute to this new initiative, and of course I'm hopeful we
will be able to use some of the code produced by this project in our
distro.

Since I don't have an ADP1, I won't be able to contribute to the low
level hardware-specific code. In addition to the proprietary apps,
also missing are a number of APIs and providers that are necessary for
the apps that are in the distribution useful. For example, the open
source Calendar app apparently needs bits that aren't included in
order to function.

I've been working on an open source clone of the Google Maps API.
Since it's not clear (to me anyway) whether I can legally access
Google Maps tiles, I have been targeting Open Street Maps instead. I'd
be happy to contribute the maps work to the project.

Thanks JBQ, for kicking this off! I'm looking forward to getting
involved.

Jim Ancona
http://code.google.com/p/android-on-freerunner/

Jer Warren

unread,
Sep 26, 2009, 3:30:00 PM9/26/09
to android-...@googlegroups.com
On Sat, Sep 26, 2009 at 12:25 PM, Mark Murphy <mmu...@commonsware.com> wrote:

Al Sutton wrote:
> I think one of the key decision is do we just want to re-do the closed
> source parts?
>
> I'm sure a lot of people would be equally interested in a HotMail
> client, Maps powered by Yahoo, etc., etc.

I'm sure they would be, but why can't those be just ordinary Android apps?

I'm far from a firmware expert (and I mean *really* far), but I would
think the driver issue is the more critical nut to crack, per some of
Disconnect's posts.

I'm more interested in seeing core contact syncing stuff abstracted out, which will take more than an app.  Sure, you could make a Yahoo Contacts app, but having the option at the Android level to use it in favor of Google Contacts sync would be incredibly valuable to some people.

dubspecialist

unread,
Sep 26, 2009, 4:55:13 PM9/26/09
to android-platform
Lets just say it is OK to include Market, wouldn't that require the
build to go through CTS ? My understanding was that the pre-req to
have an OEM include Market on their non-google exp device was the CTS
requirement. So is Market inclusion a non-starter for AOSP ?


On Sep 26, 3:02 am, amiuhle <timouhlm...@googlemail.com> wrote:
> I think this is a great Idea and I'll be glad to join.
>
> The only thing that is hard to replace is the market though. Of
> course, there are already other alternitives, but not every developer
> will submit their Apps to several different markets.
>
> Since there are Websites that display Android Market content, it can't
> be too hard to reverse engineer the communication between the Market
> and Google. But I've noticed that there aren't any sites that offer
> the .apk files for download (which is good, I wouldn't want everyone
> to be able to download my apk and redistribute it or whatever). Does
> anyone know if the apks aren't available anywhere because the site
> developers think so too, or because it's not possible?
>
> I'll do some network sniffing tonight or tomorrow, but if anyone has
> experience with this, he could help...
>
> amiuhle
>
> On 26 Sep., 07:12, Jean-Baptiste Queru <j...@android.com> wrote:
>
> > All right, it's been an memorable week, let's try to move on and be
> > constructive and talk about how we can make Android better for
> > everyone.
>
> > I explained about readers and writers last week:http://groups.google.com/group/android-platform/browse_thread/thread/...
> > reasonably on ADP1. In the short term, I believe that it makes the
> > most sense to start with cupcake, given that we'll have the official
> > ADP1 1.5 images to compare with.
>
> > I have access to the makefiles and other configuration files that are
> > used to build the official ADP1 images, which will allow to replicate
> > a similar setup in AOSP.
>
> > Who's with me?
>
> > JBQ
>

dubspecialist

unread,
Sep 26, 2009, 5:03:09 PM9/26/09
to android-platform
Doesn't Google require OEM's to pass CTS if they plan to include
Market in their non gx device ? If this stance does not change,
inclusion of Market in AOSP ROM might be a non starter correct ?

Gray

unread,
Sep 26, 2009, 5:15:19 PM9/26/09
to android-platform
As for package management, anybody thought of a port of apt to the G1
with a user frontend? Like Cydia did on the iphone?

On Sep 26, 7:43 am, Disconnect <dc.disconn...@gmail.com> wrote:
> (What Ryebrye said)
>
> In the interests of actual open source, will you be accepting patches
> with GPL/LGPL licenses? I don't think anyone would find it fair to do
> a bunch of coding to replace proprietary blobs, only to have it get
> sucked right back into the closed source tree..
>
>
>

AhronZombi

unread,
Sep 26, 2009, 5:25:03 PM9/26/09