Android Open-Source Project on devices

[Jean-Baptiste Queru]

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]

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]

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]

> 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]

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.

[Travis Swanston]

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]

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]

Absolutely, I'm on board.

[Stericson]

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]

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]

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]

> 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]

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]

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]

@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]

Count me in..

[Jean-Baptiste Queru]

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]

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]

I can't program but I will gladly test the Roms for bugs and report
them on a MyTouch3G and a DreamG1

[rich0]

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]

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]

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]

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]

(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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

what are the chances we can coordinate with FSF' replicant project?

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

[Mark Murphy]

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]

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]

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:

http://groups.google.com/group/android-platform/browse_thread/thread/88a7e52e8dd85c5a

--
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]

> 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]

> 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]

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]

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]

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]

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]

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]

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]

yes it must be GPL/LGPL or it will fail.

[Gerv]

On Sep 26, 7:01 pm, 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.

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

And Google Voice?

Google Voice and Google Maps are both in the market, so if we get
market support, we don't need to reimplement those for the moment.
Having Maps there is particularly useful.

GMail can, in a pinch, be accessed over IMAP (or POP) using the Email
program. Although currently it sucks. There's an updated version
called K9 Mail, improvements from which could be rolled back into the
open source version. K9 sucks a bit less than Email.

Can we supply a Jabber client instead of Google Talk, and rely on
server-side connectors to connect to the Google Talk network?

Can we do the syncing using something like a SyncML client (https://
android-client.forge.funambol.org/) and a service like goosync if you
still want to store your contacts with Google?

YouTube support might be nice, but I personally could live without it
for quite some time. In the UK, we have iPlayer ;-)

Gerv

[dmikhailenko]

What about binaries and kernel sources published by HTC on there
developer page?
http://developer.htc.com/

[Eric Mill]

I'd like to contribute to the project however I'm able. I'm not gonna
be worth much at C or OS-level decisions, but I can contribute to
application development.

I agree that we should not focus on our effort on reverse engineering
undocumented Google protocols, especially when those protocols can
change under our feet without notice. (Not saying Google would do this
maliciously, just as part of their normal development.)

Here are 3 proposals for apps we can start today.

Maps: Though I'm a total Google Maps fanboy, I'd switch to Yahoo Maps
for my phone if there was a good native client for it. We might get
some Yahoo team members to help out. Let's do one. Proliferation of
a good Yahoo maps client puts pressure on Google, anyhow.

(Side question: Since Google releases Maps through the Market, then if
we can get the Market app released under an open license, would we
need to replace this at all?)

Gmail: Can't we replicate a lot of the app using IMAP? The only
things I can think of that can't be done through IMAP are search, and
marking as spam. Is that all? This is assuming Contacts sync is
still allowed - correct me if it's not. If my assumptions are right,
then let's make a Gmail app that works the same way, but uses IMAP
instead of Google protocols.

IM: GTalk uses Jabber, so there are no undocumented protocols, no need
to reverse engineer. Let's make a good Jabber client that has easy
GTalk integration. Plenty of desktop clients, like Pidgin, have
already done this.

What do you guys think?

-- Eric

On Sep 26, 4:10 pm, Josh Steiner <vitrio...@gmail.com> wrote:
> 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:
>

> >http://groups.google.com/group/android-platform/browse_thread/thread/...

[Travis Swanston]

On Sep 26, 5:02 pm, Gergely Kis <gergely....@gmail.com> wrote:

> 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.

Yup, there's a script that handles that.

> 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 can only quote cyanogen here:

"From what they explained to me, you are not even allowed to copy the
proprietary applications from your device."
http://twitter.com/cyanogen/status/4380960916

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

If I understood you correctly, yes - if the extraction of the closed
apps were deemed permissible.

-t

[sregister]

Great idea. I'm on board. I dont have a adp1 but I do have a magic32b
and can test.

[pro]

Jean,

You know I'm green horn. You helped me about a month or so ago about
the tree documentation I was confused of :-).

I've an openmoko, and I'm getting a HTC G1. Whatever I read about
openmoko, and how it got to android-openmoko it is scary, so yes I'm
with you.

I hope to be able to help in lot of ways from next year ( I need
learning time a bit), but I'm also getting Dboard, so yes I would be
happy to help with anything I could...

One thing though, I would vouch for plans... Once this initial
discussion is over, please create some plans. Initially some of us
like to be follower ( at least me). Then we will try to move the found
fuzi.

Thanks
-pro

[DavidG]

Not sure where this fits in, but replacement apps for Gmail, Market,
YouTube, etc. should access the existing authenticated Google account
securely via permissions rather than asking the user to re-enter their
username/password. Many people, myself included, are very protective
of their Google credentials and if the phone is already tied into the
account there should be no need to re-ask for it. Although I guess
this depends on how the Setup Wizard is implemented. This may be off
topic (sorry if so).. just thought I'd throw in my two cents to
contribute any way I can.

[pro]

In this effort, IMHO -

1) The core could be true open source.
2) Any release should directly be downloaded over the web - like
iTune. An user don't care about partial recursive function, tail
spinning or any such buzzword.
3) The platform should be open to the app developer. Killer
applications will make it a mass market product, nothing else. So apps
should be encouraged to have price tags.
4) It has to have the ability to target multiple vendors ( different
form factor, different arch, different interface - soft or hard
keyboard for example etc...)

then only we could call it a - true handheld alliance !!!

-pro

[Jim Ancona]

On Sep 26, 7:06 pm, Eric Mill <kproject...@gmail.com> wrote:
> (Side question: Since Google releases Maps through the Market, then if
> we can get the Market app released under an open license, would we
> need to replace this at all?)

Maps depends on the proprietary Maps API as well as another
proprietary API that I can't recall right now. So you'd have to
replace those to run the Maps app from Market.

Jim

[Jim Ancona]

On Sep 26, 11:24 pm, DavidG <dgu...@gmail.com> wrote:
> Not sure where this fits in, but replacement apps for Gmail, Market,
> YouTube, etc. should access the existing authenticated Google account
> securely via permissions rather than asking the user to re-enter their
> username/password. Many people, myself included, are very protective
> of their Google credentials and if the phone is already tied into the
> account there should be no need to re-ask for it. Although I guess
> this depends on how the Setup Wizard is implemented. This may be off
> topic (sorry if so).. just thought I'd throw in my two cents to
> contribute any way I can.

The Setup Wizard is not part of the open source distribution, but
you're right that you'd want to have something similar.

Jim

[Jim Ancona]

On Sep 26, 5:44 pm, Gerv <gerv.mark...@gmail.com> wrote:
> Google Voice and Google Maps are both in the market, so if we get
> market support, we don't need to reimplement those for the moment.
> Having Maps there is particularly useful.

You do need the proprietary API that those apps depend on.

> GMail can, in a pinch, be accessed over IMAP (or POP) using the Email
> program. Although currently it sucks. There's an updated version
> called K9 Mail, improvements from which could be rolled back into the
> open source version. K9 sucks a bit less than Email.

The browser-based GMail mobile client, which uses Gears for offline
capabilities, is really good. Try it, you might like it better than
the built-in Email client.

> Can we supply a Jabber client instead of Google Talk, and rely on
> server-side connectors to connect to the Google Talk network?

I'm pretty sure GTalk *is* Jabber under the covers, so that would
work.

Jim

[RS]

Count on me. I can contribute in building, testing and developing
apps.

[Eric Mill]

> > Google Voice and Google Maps are both in the market, so if we get
> > market support, we don't need to reimplement those for the moment.
> > Having Maps there is particularly useful.
>
> You do need the proprietary API that those apps depend on.

Are you saying there are closed-source parts of the SDK that aren't
part of the Maps and Voice .apk's that come through the market?

>
> > GMail can, in a pinch, be accessed over IMAP (or POP) using the Email
> > program. Although currently it sucks. There's an updated version
> > called K9 Mail, improvements from which could be rolled back into the
> > open source version. K9 sucks a bit less than Email.
>
> The browser-based GMail mobile client, which uses Gears for offline
> capabilities, is really good. Try it, you might like it better than
> the built-in Email client.

I definitely prefer it to the built-in Email client, but not to the
built-in Gmail client. And I think we could, in theory anyway, build
an app that works just like the Gmail client, over IMAP. As a
temporary stopgap, maybe it's worth including a shortcut to
mail.google.com on the desktop, or an app that simple puts a window
around it.

-- Eric

[Jean-Baptiste Queru]

I'm not going to be able to reply to each post individually. The
response is overwhelming, and that's a good problem to have. To
everyone who offered some help in different areas: thank you, thank
you, thank you, there's plenty of work to do, we're not going to run
out of tasks. I'm personally excited, as I've been itching to run a
"straight" AOSP build myself but haven't been able to do it on a
constant basis given the nagging issues with it.

To Shane Isbell: I'm sure we can work something out, and your offer to
provide SAM code under ASL2 takes care of one of the greatest hurdles.
I don't have any concern for fragmentation here, since SAM already
exists in the ecosystem, and since the target use case (i.e. a pure
AOSP build) rules out the possibility of using the incumbent Android
Market.

To coolbho3k: the list you linked seems to be more or less "it". I
don't think it's 100% accurate (VoiceDialer is AOSP IIRC), but it's
probably close.

To Fred Grott: Re: replicant project: I personally don't see much
interest in re-creating an open-source version of something that's
already open-source. If they'd like to contribute and we can find some
way that makes sense license-wise (which is likely to be a sticky),
I'll welcome their efforts with open arms. Otherwise, it's their
freedom to spend their time doing what they want, and I respect that.

To Pascal Merle: at the moment 1.5 is the latest version for which
official images are available, so it makes at least a good basis for
comparison between AOSP and ADP1, and most of what we learn there
should carry forward to donut and master.

To Gergely Kis: personally, I think that the least we need to copy
non-AOSP files, the better we'll be.

To David Chang: yes, the sync code for Contacts and Calendar is
non-redistributable Google-proprietary.

To Jim Ancona: I'm pretty sure that accessing the Maps tiles without
using an official Google API is frowned upon, so I wouldn't go that
way. For all the rest, it does sound like you guys have done some work
to get AOSP to work without the Google bits, which is one of the
things I'd like to get to work "out of the box". Finally, the official
Google Talk app for Android doesn't use straight XMPP (I think it uses
something that is smaller, can resists losses of connectivity better,
and is fine-tuned to only have the features necessary to talk to
Google's servers). Hopefuly this is all going to be an opportunity to
make AOSP require fewer changes to run on Freerunner.

To Jer Warren: I know that we (Google) have been refactoring some code
in our internal tree in several applications, which means that it
could be hard to make deep changes to those apps in AOSP and carry
them forward. Since I sit close to the people working on Contacts, I
happen to know that's one such app, and in such a case it might make
sense to try to limit the number of changes we make there (beyond the
obvious "getting it to work"). I can't give an exhaustive list (or
provide details), but I'll try to avoid doing work in AOSP which I
know will need to be eventually thrown away.

To dubspecialist: compatibility testing isn't the only requirement to
get Market, though I have no idea what the other requirements might
be.

To Eric Mill: as far as I remember there's a GData API for contacts
and calendar. As for Google Talk, the challenge with XMPP/Jabber is to
manage the losses of connectivity.

To pro: I'm hoping that I can help organize the efforts to avoid
duplication of tasks (and any other situations that result in code
being thrown away).

JBQ

On Sat, Sep 26, 2009 at 6:59 AM, Jean-Baptiste Queru <j...@android.com> wrote:
> 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).

[Jim Ancona]

On Sep 27, 1:49 am, Eric Mill <kproject...@gmail.com> wrote:
> > > Google Voice and Google Maps are both in the market, so if we get
> > > market support, we don't need to reimplement those for the moment.
> > > Having Maps there is particularly useful.
>
> > You do need the proprietary API that those apps depend on.
>
> Are you saying there are closed-source parts of the SDK that aren't
> part of the Maps and Voice .apk's that come through the market?

I don't have a Google-experience phone, but the SDK emulator image
contains two jars in /system/framework that aren't in the open source
code, com.google.android.maps.jar and
com.google.android.gtalkservice.jar. The Google Maps apk appears to
require both of them. The maps jar presumably implements the Maps API
(see http://code.google.com/android/add-ons/google-apis/reference/index.html)
so any apps that use that API won't work without it. The gtalkservice
jar isn't documented and presumably would have to be reverse-
engineered.

> I definitely prefer it to the built-in Email client, but not to the
> built-in Gmail client.  And I think we could, in theory anyway, build
> an app that works just like the Gmail client, over IMAP.  As a
> temporary stopgap, maybe it's worth including a shortcut to
> mail.google.com on the desktop, or an app that simple puts a window
> around it.

GMail over IMAP is sluggish on a desktop machine--I can't imagine it
on a phone. I'll probably be sticking to the webapp.

Jim

[Ian]

So in reading this information and some interesting stuff on the
unlockr I have a few questions. First off cyanogen twittered that he
had a solution to the problem, i am assuming due to his involvement in
the situation JBQ has a good idea of what this may be, and i'd like to
ask him if he can enlighten us. I look forward to the AOSP being more
complete and functional. However since i am using Cyanogenmod at this
time i would like to get an idea of the future of my phone, for
reference it is a mytouch from t-mobile. I liked 1.5 but love the mod
from cyanogen more, so am extremely interested in future releases from
him, specifically since i do have the Google experience, and thus
should have rights to those proprietary apps.
I entirely understand google's point of view on the situation here, i
just do not agree with the route they took to deal with it. I would
rather that you guys simultaneously asked cyanogen to stop while
providing a solution for him to continue to serve those of us that
already own those applications. I think that would have gone over far
better than this business.

[cooolmagic]

Hi Guys,

I have a free app on market called "Toggle Settings" which essentially
provides quick access to system settings and ability to create
profiles. With 1.5 Google does not allow core system settings like
brightness, wifi, gps etc. to be modified by 3rd party. That has kind
of killed the app(specially profiles) and believe me, my app has >125k
users and they are not at all happy about this.

I know you guys are targeting Google closed-source apps right now, but
I was wondering if we can start on a kind of wrapper app over core
system settings app which has all these features like TS and Locale.
Or I can make TS open source and contribute to the branch.

Frankly, android really needs some app like this, pre-installed.

-abhi

[Andrea Campanella]

For replace the browser maybe we can try to port fennec [1]

[1]http://www.mozilla.org/projects/fennec/1.0a1/releasenotes/
--
Andrea "emuboy" Campanella
emuboy.homelinux.com

[Jean-Baptiste Queru]

To Jim Ancona: there are 2 SDK images, where one can be theoretically
build from AOSP, and one (the "Google add-on") that contains
Google-specific bits. It's possible that some Google bits made it to
the wrong side, but that should be considered a bug that should be
fixed.

To Ian: cyanogen explained his thinking in greater detail here:
http://www.cyanogenmod.com/home/the-current-state and I think that
we're all thinking along the same lines: let's avoid copying and
distributing those files.

To Andrea Campanella: the existing browser is already entirely
open-source, so I don't think that within AOSP we'll be interested in
getting another browser.

To coolmagic: 1.6 includes a desktop widget that takes care of
toggling some settings. It could just be that we want to extend it to
have more settings (or to be more configurable if that makes sense).
If we want to work at the app level instead, we can work directly in
the settings app itself.

JBQ

[Disconnect]

Google talk -supports- jabber. That doesn't mean it -is- jabber (and
long-time listeners may recall that they pulled the jabber API and all
reports since then are that they use a proprietary protocol between
the client and server.)

A jabber client could certainly be tied to gtalk though.

[Disconnect]

Why are we replacing the browser?

[Fred Grott]

we are not..

[Jim Ancona]

On Sep 27, 9:30 am, Jean-Baptiste Queru <j...@android.com> wrote:
> To Jim Ancona: there are 2 SDK images, where one can be theoretically
> build from AOSP, and one (the "Google add-on") that contains
> Google-specific bits. It's possible that some Google bits made it to
> the wrong side, but that should be considered a bug that should be
> fixed.

Sorry, I didn't make myself clear. The emulator I was referring to is
the "Google APIs Profile" version distributed in the SDK download, so
the Google APIs were there legitimately. I was just making the point
that having access to the Market isn't enough--we would also need to
build replacements for those APIs in order to support all Google and
third-party apps.

Jim

>
> To Ian: cyanogen explained his thinking in greater detail here:http://www.cyanogenmod.com/home/the-current-stateand I think that

[Jean-Baptiste Queru]

The system has a mechanism to deal with optional device-specific APIs
like Maps: it's the <uses-library> element in the manifest of each
app. That way, Market can filter out applications that require a
library that doesn't exist on the target device.

Your point is valid: AOSP + Market would not solve all the problems.

JBQ

[Disconnect]

On Sun, Sep 27, 2009 at 10:00 AM, Jean-Baptiste Queru <j...@android.com> wrote:
>
> The system has a mechanism to deal with optional device-specific APIs
> like Maps: it's the <uses-library> element in the manifest of each
> app. That way, Market can filter out applications that require a
> library that doesn't exist on the target device.
>

Which is great, if we have the market app. Given that most people will
be using an alternative market, or straight adb install (so much for
security), is there an accessible mechanism to handle that?

[Andrea Campanella]

On Sun, Sep 27, 2009 at 3:40 PM, Disconnect <dc.dis...@gmail.com> wrote:
>
> Why are we replacing the browser?
>

isn't it closed?

[Mark Murphy]

Andrea Campanella wrote:
> On Sun, Sep 27, 2009 at 3:40 PM, Disconnect <dc.dis...@gmail.com> wrote:
>> Why are we replacing the browser?
>
> isn't it closed?

Not that I can tell:

http://android.git.kernel.org/?p=platform/packages/apps/Browser.git;a=tree

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

_Beginning Android_ from Apress Now Available!

[Shane Isbell]

On Sun, Sep 27, 2009 at 7:51 AM, Disconnect <dc.dis...@gmail.com> wrote:

On Sun, Sep 27, 2009 at 10:00 AM, Jean-Baptiste Queru <j...@android.com> wrote:
>
> The system has a mechanism to deal with optional device-specific APIs
> like Maps: it's the <uses-library> element in the manifest of each
> app. That way, Market can filter out applications that require a
> library that doesn't exist on the target device.
>

Which is great, if we have the market app. Given that most people will
be using an alternative market, or straight adb install (so much for
security), is there an accessible mechanism to handle that?

We still need to add device detection to SAM. But this is how it would work. The FeedsServer contains uses-library information per app.  SAM will detect the device and send it to the FeedsServer (similar to UAProf) .

For each device in the market, FeedsServer will have device capabilities configuration. When the SAM request hits FeedsServer, it matches capabilites to device. FeedsServer sends appropriate application info back to SAM.  SAM displays catalog to user.
 

--
Shane Isbell (Co-founder of SlideME - The Original Market for Android)
http://twitter.com/sisbell
http://twitter.com/slideme

[Jim Ancona]

On Sep 27, 11:04 am, Shane Isbell <shane.isb...@gmail.com> wrote:

> On Sun, Sep 27, 2009 at 7:51 AM, Disconnect <dc.disconn...@gmail.com> wrote:
>
> > On Sun, Sep 27, 2009 at 10:00 AM, Jean-Baptiste Queru <j...@android.com>
> > wrote:
>
> > > The system has a mechanism to deal with optional device-specific APIs
> > > like Maps: it's the <uses-library> element in the manifest of each
> > > app. That way, Market can filter out applications that require a
> > > library that doesn't exist on the target device.
>
> > Which is great, if we have the market app. Given that most people will
> > be using an alternative market, or straight adb install (so much for
> > security), is there an accessible mechanism to handle that?

PackageManager honors <uses-library>. If I try to install an app that
requires one of the proprietary APIs, it fails:
E/PackageManager( 846): Package com.google.android.apps.maps requires
unavailable shared library com.google.android.gtalkservice; ignoring!
W/PackageManager( 846): Package couldn't be installed in /data/app/
com.google.android.apps.maps.apk

> We still need to add device detection to SAM. But this is how it would work.
> The FeedsServer contains uses-library information per app.  SAM will detect
> the device and send it to the FeedsServer (similar to UAProf) .
>
> For each device in the market, FeedsServer will have device capabilities
> configuration. When the SAM request hits FeedsServer, it matches capabilites
> to device. FeedsServer sends appropriate application info back to SAM.  SAM
> displays catalog to user.

Alternatively, is it possible to have the device report which extra
APIs it has? Then you wouldn't need a central database.

Jim

[Shane Isbell]

Yes. It is possible to have the device advertise its capabilities directly within an HTTP header field, but it would still need to be parsed and matched within a FeedServer. At least within the Java ME world, these capabilities included essentially the whole device spec, so it became impractical to embed within the HTTP header, hence use of the UAProf and RDF device profiles.

[Fred Grott]

would there ba ea way to bend UAProf and RDF device profiles towards that purpose?

[Shane Isbell]

On Sun, Sep 27, 2009 at 10:02 AM, Fred Grott <fred....@gmail.com> wrote:

would there ba ea way to bend UAProf and RDF device profiles towards that purpose?

Absolutely, I think following standards (where they aren't patent encumbered) is the best way to go. I've got some code in JVending (open-source implementation of JSR-124) that imports RDF format to its internal format it uses for matching. It has a really powerful matching engine. I can rip that out and import it into a catalog server.

Shane

[Fred Grott]

I have contributed to the WUFRLL device db project before we might want to ask for some feedback from them as well..

[Shane Isbell]

On Sun, Sep 27, 2009 at 10:12 AM, Fred Grott <fred....@gmail.com> wrote:

I have contributed to the WUFRLL device db project before we might want to ask for some feedback from them as well..

I've got a WURFL converter in JVending. They do a good job on maintaining device info.
 

On Sun, Sep 27, 2009 at 12:09 PM, Shane Isbell <shane....@gmail.com> wrote:

On Sun, Sep 27, 2009 at 10:02 AM, Fred Grott <fred....@gmail.com> wrote:

would there ba ea way to bend UAProf and RDF device profiles towards that purpose?

Absolutely, I think following standards (where they aren't patent encumbered) is the best way to go. I've got some code in JVending (open-source implementation of JSR-124) that imports RDF format to its internal format it uses for matching. It has a really powerful matching engine. I can rip that out and import it into a catalog server.

Shane

[Fred Grott]

Good than that answers that part..

[Dianne Hackborn]

On Sat, Sep 26, 2009 at 12:30 PM, Jer Warren <j...@nyquil.org> wrote:

I'm more interested in seeing core contact syncing stuff abstracted out, which will take more than an app.

Sync has always been intended to be separable from the content provider, we just didn't have time to flesh that all out for 1.0.  Cleaning this up is definitely on the list of things to do.  (This is something Google really wants as well, so they can deliver all of their applications and services to a device that doesn't include them by default.  That is after all one of the things Android is supposed to do for Google.)

--

Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Fred Grott]

sounds like  Synch should be our first target as it could spark more dialogue and etc in other areas...plus benefit the whole ecosystem at the same time.

[Eric Mill]

The guys on the XDA forums are trying to start a project to replace
all the closed bits, called "Open Android Alliance". Their Google
Code site for it is here:
http://code.google.com/p/open-android-alliance/

Regarding an Android app that does Gmail over IMAP, it may suck for
desktop apps where you're doing a synchronous "Send/Receive" type of
interaction, but for a mobile app where it's doing background sync
both on send and receive, I don't think the speed difference would be
that big of a deal.

I'd prefer not to found such a project, but I'd happily contribute to
one. If one does emerge out of the Open Android Alliance project
above, that's where I'll put my efforts.

-- Eric

On Sep 27, 4:05 pm, Fred Grott <fred.gr...@gmail.com> wrote:
> sounds like  Synch should be our first target as it could spark more
> dialogue and etc in other areas...plus benefit the whole ecosystem at the
> same time.
>

> On Sun, Sep 27, 2009 at 2:58 PM, Dianne Hackborn <hack...@android.com>wrote:
>
> > On Sat, Sep 26, 2009 at 12:30 PM, Jer Warren <j...@nyquil.org> wrote:
>
> >> I'm more interested in seeing core contact syncing stuff abstracted out,
> >> which will take more than an app.
>
> > Sync has always been intended to be separable from the content provider, we
> > just didn't have time to flesh that all out for 1.0.  Cleaning this up is
> > definitely on the list of things to do.  (This is something Google really
> > wants as well, so they can deliver all of their applications and services to
> > a device that doesn't include them by default.  That is after all one of the
> > things Android is supposed to do for Google.)
>
> > --
> > Dianne Hackborn
> > Android framework engineer

> > hack...@android.com

[Shane Isbell]

On Sun, Sep 27, 2009 at 2:14 PM, Eric Mill <kproj...@gmail.com> wrote:

The guys on the XDA forums are trying to start a project to replace
all the closed bits, called "Open Android Alliance".  Their Google
Code site for it is here:
http://code.google.com/p/open-android-alliance/

I'm not a big fan of starting projects without source code because they tend to die really fast. Where is it all coming from?

[Fred Grott]

does not matter project was set as GPLv3..