(1) The Android Open-Source Project ("AOSP") has two goals:
-The primary goal is to release the platform source code as used in
Google-Experience devices ("GEDs") under a set of Open-Source
licenses, so that device manufacturers ("OEMs") can create smartphones
with that source code.
-The secondary goal is to accept code contributions that will be used
to build future GEDs.
Note that being a community project is explicit not a goal. The
licenses and tools used by AOSP are designed to allow people to
maintain their own variants of the source code in parallel to AOSP
without being part of AOSP.
(2) About the practicality of the verification / approval / submission process:
-Because of Google's internal process at the time, it was impractical
to accept external contributions into Cupcake or Donut.
-For Eclair, (almost) all contributions that had been submitted into
the AOSP master up to a certain cutoff date were manually merged into
Google's server to be used for Eclair.
-For future releases starting with Flan, the plan is to make the
merges happen automatically. We'll also try to seamlessly transition
from one release to another, such that contributions can be submitted
continuously and automatically end up in the first release where it's
practical to merge them.
-The issue with uploaded changes not getting reviewed in a timely
manner is primarily an issue of resources. There's no malicious intent
to shut good changes down, but with the dozens of changes that are
uploaded daily it's sadly easy to let some slip through the cracks.
(Wanna help improve the tools? Gerrit is open-source, and Google is
hiring a full-time Android engineer to work on such tools)
-Android, like any software project, has cutoff dates where new
changes can't be accepted any more (typically, there are separate
dates for features an non-critical bugfixes). This is what happened to
the FLAC contribution: it wasn't rejected, it was just too late to
make the cut for Eclair. The mobile industry works with multiple
layers of testing, validation and acceptance, plus has overhead of
manufacturing and the logistics of distribution, so it's impossible to
make the release cycles arbitrarily short, and there's a long delay
between the feature-freeze date and retail availability (it takes on
average 6 months or more from the time a feature is written to the
time it's available at retail).
(3) About the community aspects of AOSP:
-Like I said above, AOSP isn't a community project. It's a project
that's closely related to GEDs, and therefore to Google. It's a
project where the vast majority of development is done behind closed
doors, with no community involvement in the design, implementation and
review processes, and where large lumps of code are thrown over the
proverbial wall on a currently unpredictable schedule. That's just the
way things are.
-Google has explicitly decided to not communicate roadmaps and
schedules, since the highly volatile nature of the industry makes
those change a lot, and too many people read roadmaps and schedules as
if they were commitments. That's the way things are, and people who
want to get involved with AOSP need to work within that constraint.
-So far, it's clear that there's been very little community-visible
development activity outside of the kernel. While many Android
engineers at Google desire to see that change, it's a surprisingly
hard transition to make.
-The same issues of resources that's hurting the verification /
approval / submission process has been similarly hurting the process
around the public bug database. Google is looking for engineers to
help with the Android Open-Source Project.
(4) About the various kinds of Android software around AOSP:
There are quite a few kinds of software related to GEDs that are
relevant to AOSP, but with different relationships to AOSP and
Open-Source in general, and it's helpful to keep the differences in
mind:
-There's the open platform itself. That's the heart of AOSP, that's
more or less the generic build that runs on the emulator after
downloading and building the source code. At the strictest sense of
the term, this is "the" AOSP code.
-There are the device-specific files that are necessary to run AOSP
code directly on hardware, and specifically on the Android Dev Phone 1
("ADP1"). The files necessary to run the AOSP master tree on ADP1
aren't available to the public.
-There are a few areas where the AOSP code relies on non-Open-Source
code that's shipped on GEDs. It'd be good to fix those (e.g. by
removing the dependency or by writing Open-Source replacements for the
non-Open-Source parts).
-There are applications that are written on top of the Android
platform, that use private APIs (which means that they're not
compatible across versions of Android) and that aren't available as
source to AOSP. Those apps are typically Google's and were typically
written at a time when all APIs were public. Those are unrelated to
the open platform as far as AOSP is concerned, and their being
Open-Source or not is totally orthogonal to the issue of Google's
control over AOSP. This very explicitly includes the Market client.
(5) About AOSP and ADP1:
This is a very painful part. The port of Android (and therefore AOSP)
on ADP1 relies on a large number of non-Open-Source components for
which the only available version has to get extracted from the latest
official release of Android for ADP1. At the moment the latest such
release is based on Cupcake, while the AOSP master tree is based on
Donut, and they're incompatible, such that there's currently no way to
run the AOSP master tree on ADP1. This is a horrible situation for
AOSP contributors, as there's no way to try any changes on real
hardware before uploading them (so, no way to dogfood one's own
changes, no way to test performance on real hardware, and no way to
develop around any of the areas that aren't emulated by the emulator).
I and several others at Google have been trying to get the companies
that own those files to release them for AOSP, and all the promises
that we've heard so far have come out empty. From the point of view of
AOSP, this gross inability to provide any kind of supported reference
hardware for community development is a major failure of OHA.
(6) About most Google employees who participate in open Android discussions:
The Google employees who participate in the Android discussions on
this group and other similar groups are almost uniquely engineers. For
all practical purposes, there are no product managers, no project
managers, no partner managers, no UI designers on this group and other
similar groups. Engineers aren't in a position to make decisions or
commitments that fall into the domains of responsibility of those
other groups. Repeating questions and complaints over and over about
schedules, roadmaps, partners, individual features, or anything that
can't be answered by engineers only accomplishes one thing: it annoys
the engineers, but it can't and it doesn't result in any concrete
action. The Android engineers who read this group and other similar
groups and/or who look at the public bug database already know what
the most requested features are on the community side, and we're
really working on them as soon as possible, it just turns out that
there's a constant and very large stream of other work that has a
higher priority.
(7) About apps on removable storage:
Yup, that's a painful part. We (Google) have felt that pain even
before the G1 was released, as even our handful of test apps wouldn't
fit on the internal storage of a Dream. This is one of those areas
where there's always been some higher priority work for the Google
Android engineers who know that area of the code (see my comment above
about decisions and commitments not being made by engineers). There
have been quite a few discussions about this on open-source lists, but
those barely scratched the surface beyond the equivalent of "works for
me" and didn't seem to get into the meat of the problem (making it
work fully is a surprisingly deep issue). The right group to discuss
this is android-platform. Be prepared to think about what happens e.g.
when two apps are installed on two separate SD cards but request the
same UID, or about the way to deal with a factory reset.
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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Android Discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
