1page.title=Android Code-Lines 2doc.type=source 3@jd:body 4<p>The Android Open Source Project maintains a complete software stack intended 5to be ported by OEMs and other device implementors to run on actual hardware. 6Accordingly, we maintain a number of "code lines" to clearly separate the 7current stable version of Android from unstable experimental work.</p> 8<p>The chart below depicts at a conceptual level how AOSP manages code and 9releases. We're referring to these as "code lines" instead of "branches" 10simply because at any given moment there may be more than one branch extant 11for a given "code line". For instance, when a release is cut, sometimes that 12will become a new branch in git, and sometimes not, based on the needs of the 13moment.</p> 14<img src="{@docRoot}images/code-lines.png"/> 15<h3>Notes and Explanations</h3> 16<ul> 17<li>A <i>release</i> corresponds to a formal version of the Android platform, such 18as 1.5, 2.0, and so on. Generally speaking, a release of the platform 19corresponds to a version of the <code>SdkVersion</code> field used in 20AndroidManifest.xml files, and defined in <code>frameworks/base/api</code> in 21the source tree.</li> 22<li>An <i>upstream</i> project is an open-source project from which the Android 23stack is pulling code. These include obvious projects such as the Linux kernel 24and WebKit, but over time we are migrating some of the semi-autonomous 25Android projects (such as Dalvik, the Android SDK tools, Bionic, and so on) to 26work as "upstream" projects. These will be developed entirely in the public 27tree, and snapshots will be periodically pulled into releases.</li> 28<li>The diagram refers to "Eclair" and "Flan"; however, they are simply 29placeholders, and the diagram actually reflects the overall release and 30branching strategy.</li> 31<li>At all times, the Release code-line (which may actually consist of 32more than one actual branch in git) is considered the sole canonical source 33code for a given Android platform. OEMs and other groups building devices 34should pull only from a Release branch.</li> 35<li>We will be setting up an "Experimental" code-line to capture changes from 36the community, so that they can be iterated on, with an eye toward stability.</li> 37<li>Changes that prove stable will eventually be pulled into a Release 38branch. Note that this will only apply to bug fixes, app improvements, and 39other things that do not affect the APIs of the platform.</li> 40<li>Changes will be pulled into Release branches from upstream projects 41(include the Android "upstream" projects) as necessary.</li> 42<li>The "n+1"th version (that is, next major version of the framework and 43platform APIs) will be developed by Google internally. (See below for 44details.)</li> 45<li>Changes will be pulled from upstream, Release, and Experimental branches 46into Google's private branch as necessary.</li> 47<li>When the platform APIs for the next version have stabilized and been fully 48tested, Google will cut a release of the next platform version. (This 49specifically refers to a new <code>SdkVersion</code>.) This will also 50correspond to the internal code-line being made a public Release branch, and the 51new current platform code-line.</li> 52<li>When a new platform version is cut, a corresponding Experimental 53code-line.</li> 54</ul> 55<h3>About Private Code-Lines</h3> 56<p>The source management strategy above includes a code-line that Google will 57keep private. The reason for this is to focus attention on the current public 58version of Android.</p> 59<p>OEMs and other device builders naturally want to ship devices with the 60latest version of Android. Similarly, application developers don't want to 61deal with more extant platform versions than strictly necessary. Meanwhile, 62Google retains responsibility for the strategic direction of Android as a 63platform and a product. Our approach is based on focusing on a small number of 64flagship devices to drive features, and secure protections of Android-related 65intellectual property through patents and the like.</p> 66<p>As a result, Google frequently has possession of confidential 67information of third parties, and we must refrain from revealing patentable 68features until we've secured the appropriate protections. Meanwhile, there are 69real risks to the platform arising from having too many platform versions 70extant at once. For these reasons, we have structured the open-source project 71-- including third-party contributions -- to focus on the currently-public 72stable version of Android. "Deep development" on the next version of the 73platform will happen in private, until it's ready to become an official 74release.</p> 75<p>We recognize that many contributors will disagree with this approach. We 76respect that others may have a different point of view; however, this is the 77approach that we feel is best, and the one we've chosen to implement.</p> 78
