1<!-- 2 Copyright 2010 The Android Open Source Project 3 4 Licensed under the Apache License, Version 2.0 (the "License"); 5 you may not use this file except in compliance with the License. 6 You may obtain a copy of the License at 7 8 http://www.apache.org/licenses/LICENSE-2.0 9 10 Unless required by applicable law or agreed to in writing, software 11 distributed under the License is distributed on an "AS IS" BASIS, 12 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13 See the License for the specific language governing permissions and 14 limitations under the License. 15--> 16 17# Android Code-Lines # 18 19The Android Open Source Project maintains a complete software stack intended 20to be ported by OEMs and other device implementors to run on actual hardware. 21Accordingly, we maintain a number of "code lines" to clearly separate the 22current stable version of Android from unstable experimental work. 23 24The chart below depicts at a conceptual level how AOSP manages code and 25releases. We're referring to these as "code lines" instead of "branches" 26simply because at any given moment there may be more than one branch extant 27for a given "code line". For instance, when a release is cut, sometimes that 28will become a new branch in git, and sometimes not, based on the needs of the 29moment. 30 31<img src="/images/code-lines.png"/> 32 33## Notes and Explanations ## 34 35- A *release* corresponds to a formal version of the Android platform, such 36as 1.5, 2.1, and so on. Generally speaking, a release of the platform 37corresponds to a version of the `SdkVersion` field used in 38AndroidManifest.xml files, and defined in `frameworks/base/api` in 39the source tree. 40 41- An *upstream* project is an open-source project from which the Android 42stack is pulling code. These include obvious projects such as the Linux kernel 43and WebKit, but over time we are migrating some of the semi-autonomous 44Android projects (such as Dalvik, the Android SDK tools, Bionic, and so on) to 45work as "upstream" projects. Generally, these projects are developed entirely in 46the public tree. For some upstream projects, development is done by contributing 47directly to the upstream project itself. See [Upstream Projects](submit-patches.html#upstream-projects) 48for details. In both cases, snapshots will be periodically pulled into releases. 49 50- The diagram refers to "Eclair" and "FroYo"; however, they are simply 51placeholders, and the diagram actually reflects the overall release and 52branching strategy. 53 54- At all times, a release code-line (which may actually consist of 55more than one actual branch in git) is considered the sole canonical source 56code for a given Android platform version. OEMs and other groups building devices 57should pull only from a release branch. 58 59- We will set up "experimental" code-lines to capture changes from 60the community, so that they can be iterated on, with an eye toward stability. 61 62- Changes that prove stable will eventually be pulled into a release 63branch. Note that this will only apply to bug fixes, app improvements, and 64other things that do not affect the APIs of the platform. 65 66- Changes will be pulled into release branches from upstream projects 67(including the Android "upstream" projects) as necessary. 68 69- The "n+1"th version (that is, next major version of the framework and 70platform APIs) will be developed by Google internally. See below for 71details. 72 73- Changes will be pulled from upstream, release, and experimental branches 74into Google's private branch as necessary. 75 76- When the platform APIs for the next version have stabilized and been fully 77tested, Google will cut a release of the next platform version. (This 78specifically refers to a new `SdkVersion`.) This will also 79correspond to the internal code-line being made a public release branch, and the 80new current platform code-line. 81 82- When a new platform version is cut, a corresponding experimental 83code-line will be created at the same time. 84 85## About Private Code-Lines ## 86 87The source management strategy above includes a code-line that Google will 88keep private. The reason for this is to focus attention on the current public 89version of Android. 90 91OEMs and other device builders naturally want to ship devices with the 92latest version of Android. Similarly, application developers don't want to 93deal with more extant platform versions than strictly necessary. Meanwhile, 94Google retains responsibility for the strategic direction of Android as a 95platform and a product. Our approach is based on focusing on a small number of 96flagship devices to drive features, and secure protections of Android-related 97intellectual property. 98 99As a result, Google frequently has possession of confidential 100information of third parties, and we must refrain from revealing sensitive 101features until we've secured the appropriate protections. Meanwhile, there are 102real risks to the platform arising from having too many platform versions 103extant at once. For these reasons, we have structured the open-source project 104-- including third-party contributions -- to focus on the currently-public 105stable version of Android. "Deep development" on the next version of the 106platform will happen in private, until it's ready to become an official 107release. 108 109We recognize that many contributors will disagree with this approach. We 110respect that others may have a different point of view; however, this is the 111approach that we feel is best, and the one we've chosen to implement. 112 113 114
