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.
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)?
======
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:
> 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.
> 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.
> 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.
> 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.
> 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.
On Fri, Sep 25, 2009 at 10:12 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> 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.
> 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.
On Fri, Sep 25, 2009 at 11:56 PM, Jey Michael <jey.mich...@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.
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).
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.
> 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)?
> ======
> 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.
> > 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.
> > 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.
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:
> 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.
> 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.
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.
> 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.
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:
> 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.
> 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.
> > 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
> On Fri, Sep 25, 2009 at 10:12 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > 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.
> > 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.
@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.
> 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.
> 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.
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).
On Fri, Sep 25, 2009 at 11:07 PM, RyeBrye <ryeb...@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.
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.
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:
> 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.
> 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.
> 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.
> 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.
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.
On Sat, Sep 26, 2009 at 7:12 AM, rich0 <freemanr...@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.
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..
> 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.
> 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.
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.
On Sat, Sep 26, 2009 at 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..
> 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.
>> 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.
>> 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.
|
