| 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.0, 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. These will be developed entirely in the public |
| tree, and snapshots will be periodically pulled into releases.</li> |
| <li>The diagram refers to "Eclair" and "Flan"; however, they are simply |
| placeholders, and the diagram actually reflects the overall release and |
| branching strategy.</li> |
| <li>At all times, the 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. OEMs and other groups building devices |
| should pull only from a Release branch.</li> |
| <li>We will be setting up an "Experimental" code-line 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 |
| (include 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.</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 through patents and the like.</p> |
| <p>As a result, Google frequently has possession of confidential |
| information of third parties, and we must refrain from revealing patentable |
| 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> |