page.title=Android Code-Lines
doc.type=source
@jd:body
<p>The Android Open Source Project maintains a complete software stack intended
to be ported by OEMs and other device implementors to run on actual hardware.
Accordingly, we maintain a number of "code lines" to clearly separate the
current stable version of Android from unstable experimental work.</p>
<p>The chart below depicts at a conceptual level how AOSP manages code and
releases. We're referring to these as "code lines" instead of "branches"
simply because at any given moment there may be more than one branch extant
for a given "code line".  For instance, when a release is cut, sometimes that
will become a new branch in git, and sometimes not, based on the needs of the
moment.</p>
<img src="{@docRoot}images/code-lines.png"/>
<h3>Notes and Explanations</h3>
<ul>
<li>A <i>release</i> corresponds to a formal version of the Android platform, such
as 1.5, 2.1, and so on. Generally speaking, a release of the platform
corresponds to a version of the <code>SdkVersion</code> field used in
AndroidManifest.xml files, and defined in <code>frameworks/base/api</code> in
the source tree.</li>
<li>An <i>upstream</i> project is an open-source project from which the Android
stack is pulling code. These include obvious projects such as the Linux kernel
and WebKit, but over time we are migrating some of the semi-autonomous
Android projects (such as Dalvik, the Android SDK tools, Bionic, and so on) to
work as "upstream" projects. Generally, these projects are developed entirely in
the public tree. For some upstream projects, development is done by contributing
directly to the upstream project itself. See
<a href="{@docRoot}source/submit-patches.html#upstream-projects">Upstream Projects</a>
for details. In both cases, snapshots will be periodically pulled into releases.</li>
<li>The diagram refers to "Eclair" and "FroYo"; however, they are simply
placeholders, and the diagram actually reflects the overall release and
branching strategy.</li>
<li>At all times, a release code-line (which may actually consist of
more than one actual branch in git) is considered the sole canonical source
code for a given Android platform version. OEMs and other groups building devices
should pull only from a release branch.</li>
<li>We will set up "experimental" code-lines to capture changes from
the community, so that they can be iterated on, with an eye toward stability.</li>
<li>Changes that prove stable will eventually be pulled into a release
branch. Note that this will only apply to bug fixes, app improvements, and
other things that do not affect the APIs of the platform.</li>
<li>Changes will be pulled into release branches from upstream projects
(including the Android "upstream" projects) as necessary.</li>
<li>The "n+1"th version (that is, next major version of the framework and
platform APIs) will be developed by Google internally. See below for
details.</li>
<li>Changes will be pulled from upstream, release, and experimental branches
into Google's private branch as necessary.</li>
<li>When the platform APIs for the next version have stabilized and been fully
tested, Google will cut a release of the next platform version. (This
specifically refers to a new <code>SdkVersion</code>.) This will also
correspond to the internal code-line being made a public release branch, and the
new current platform code-line.</li>
<li>When a new platform version is cut, a corresponding experimental
code-line will be created at the same time.</li>
</ul>
<h3>About Private Code-Lines</h3>
<p>The source management strategy above includes a code-line that Google will
keep private. The reason for this is to focus attention on the current public
version of Android.</p>
<p>OEMs and other device builders naturally want to ship devices with the
latest version of Android. Similarly, application developers don't want to
deal with more extant platform versions than strictly necessary.  Meanwhile,
Google retains responsibility for the strategic direction of Android as a
platform and a product. Our approach is based on focusing on a small number of
flagship devices to drive features, and secure protections of Android-related
intellectual property.</p>
<p>As a result, Google frequently has possession of confidential
information of third parties, and we must refrain from revealing sensitive
features until we've secured the appropriate protections. Meanwhile, there are
real risks to the platform arising from having too many platform versions
extant at once. For these reasons, we have structured the open-source project
-- including third-party contributions -- to focus on the currently-public
stable version of Android. "Deep development" on the next version of the
platform will happen in private, until it's ready to become an official
release.</p>
<p>We recognize that many contributors will disagree with this approach. We
respect that others may have a different point of view; however, this is the
approach that we feel is best, and the one we've chosen to implement.</p>