Home | History | Annotate | Download | only in source
      1 <html devsite>
      2   <head>
      3     <title>Codelines, Branches, and Releases</title>
      4     <meta name="project_path" value="/_project.yaml" />
      5     <meta name="book_path" value="/_book.yaml" />
      6   </head>
      7   <body>
      8   <!--
      9       Copyright 2017 The Android Open Source Project
     10 
     11       Licensed under the Apache License, Version 2.0 (the "License");
     12       you may not use this file except in compliance with the License.
     13       You may obtain a copy of the License at
     14 
     15           http://www.apache.org/licenses/LICENSE-2.0
     16 
     17       Unless required by applicable law or agreed to in writing, software
     18       distributed under the License is distributed on an "AS IS" BASIS,
     19       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     20       See the License for the specific language governing permissions and
     21       limitations under the License.
     22   -->
     23 
     24 
     25 
     26 <p>
     27   The Android Open Source Project (AOSP) maintains a complete software stack to be ported by
     28   OEMs and other device implementors and run on their own hardware. To maintain the quality of
     29   Android, Google has contributed full-time engineers, product managers, user interface designers,
     30   quality assurance testers, and all the other roles required to bring modern devices to market.
     31 </p>
     32 
     33 <p>
     34   Accordingly, we maintain a number of "code lines" to clearly separate the current stable
     35   version of Android from unstable experimental work. We roll the open source administration
     36   and maintenance of the Android code lines into the larger product development cycle.
     37 </p>
     38 
     39 <p>
     40   The chart below depicts at a conceptual level how AOSP manages code and releases. We're
     41   referring to these as "code lines" instead of "branches" simply because at any given moment
     42   there may be more than one branch for a given "code line". For instance, when a
     43   release is cut, it may or may not become a new branch based on the needs of the moment.
     44 </p>
     45 <ol>
     46   <li>
     47 	<p>
     48 	  At any given moment, there is a current latest release of the Android platform. This
     49 	  typically takes the form of a branch in the tree.
     50 	</p>
     51   </li>
     52   <li>
     53 	<p>
     54 	  Device builders and contributors work with the current latest release, fixing bugs,
     55 	  launching new devices, experimenting with new features, and so on.
     56 	</p>
     57   </li>
     58   <li>
     59 	<p>
     60 	  In parallel, Google works internally on the next version of the Android platform and
     61 	  framework according to the product's needs and goals. We develop the next
     62 	  version of Android by working with a device partner on a flagship device whose
     63 	  specifications are chosen to push Android in the direction we believe it should go.
     64 	</p>
     65   </li>
     66   <li>
     67 	<p>
     68 	  When the "n+1"th version is ready, it will be published to the public source tree and
     69 	  become the new latest release.
     70 	</p>
     71   </li>
     72 </ol>
     73   <img src="/images/code-lines.png" alt="code-line diagram" id="figure1" >
     74 <p class="img-caption">
     75   <strong>Figure 1.</strong> AOSP code and releases
     76 </p>
     77 <h2 id="terms-and-caveats">
     78   Terms and Caveats
     79 </h2>
     80 <ul>
     81   <li>
     82 	<p>
     83 	  A <em>release</em> corresponds to a formal version of the Android platform, such as 1.5,
     84 	  2.1, and so on. Generally speaking, a release of the platform corresponds to the version in
     85 	  the <code>SdkVersion</code> field of AndroidManifest.xml files and defined within
     86 	  <code>frameworks/base/api</code> in the source tree.
     87 	</p>
     88   </li>
     89   <li>
     90 	<p>
     91 	  An <em>upstream</em> project is an open source project from which the Android stack is
     92 	  pulling code. These include obvious projects such as the Linux kernel and WebKit.
     93 	  Over time we are migrating some of the semi-autonomous Android projects (such as ART,
     94 	  the Android SDK tools, Bionic, and so on) to work as "upstream" projects. Generally,
     95 	  these projects are developed entirely in the public tree. For some upstream projects,
     96 	  development is done by contributing directly to the upstream project itself. See <a href=
     97 	  "submit-patches.html#upstream-projects">Upstream Projects</a> for details. In both cases,
     98 	  snapshots will be periodically pulled into releases.
     99 	</p>
    100   </li>
    101   <li>
    102 	<p>
    103 	  At all times, a release code-line (which may actually consist of more than one actual
    104 	  branch in git) is considered the sole canonical source code for a given Android platform
    105 	  version. OEMs and other groups building devices should pull only from a release branch.
    106 	</p>
    107   </li>
    108   <li>
    109 	<p>
    110 	  "Experimental" code-lines are established to capture changes from the community so they can
    111           be iterated on with an eye toward stability.
    112 	</p>
    113   </li>
    114   <li>
    115 	<p>
    116 	  Changes that prove stable will eventually be pulled into a release branch. Note this
    117 	  applies only to bug fixes, application improvements, and other changes that do not affect the
    118 	  APIs of the platform.
    119 	</p>
    120   </li>
    121   <li>
    122 	<p>
    123 	  Changes will be pulled into release branches from upstream projects (including the
    124 	  Android "upstream" projects) as necessary.
    125 	</p>
    126   </li>
    127   <li>
    128 	<p>
    129 	  The "n+1"th version (that is, next major version of the framework and platform APIs) will
    130 	  be developed by Google internally. See <a href=
    131           "#about-private-code-lines">About Private Codelines</a> for details.
    132 	</p>
    133   </li>
    134   <li>
    135 	<p>
    136 	  Changes will be pulled from upstream, release, and experimental branches into Google's
    137 	  private branch as necessary.
    138 	</p>
    139   </li>
    140   <li>
    141 	<p>
    142 	  When the platform APIs for the next version have stabilized and been fully tested, Google
    143 	  will cut a release of the next platform version. (This specifically refers to a new
    144 	  <code>SdkVersion</code>.) This will also correspond to the internal code-line being made
    145 	  a public release branch, and the new current platform code-line.
    146 	</p>
    147   </li>
    148   <li>
    149 	<p>
    150 	  When a new platform version is cut, a corresponding experimental code-line will be
    151 	  created at the same time.
    152 	</p>
    153   </li>
    154 </ul>
    155 
    156 <h2 id="about-private-code-lines">
    157   About Private Codelines
    158 </h2>
    159 <p>
    160   The source management strategy above includes a code-line that Google will keep private. The
    161   reason for this is to focus attention on the current public version of Android.
    162 </p>
    163 <p>
    164   OEMs and other device builders naturally want to ship devices with the latest version of
    165   Android. Similarly, application developers don't want to deal with more platform
    166   versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic
    167   direction of Android as a platform and a product. Our approach focuses on a small number of
    168   flagship devices to drive features while securing protections of Android-related intellectual
    169   property. 
    170 </p>
    171 <p>
    172   As a result, Google frequently has possession of confidential information from third parties.
    173   And we must refrain from revealing sensitive features until we've secured the appropriate
    174   protections. In addition, there are real risks to the platform arising from having too many
    175   platform versions extant at once. For these reasons, we have structured the open source
    176   project -- including third-party contributions -- to focus on the currently-public stable
    177   version of Android. "Deep development" on the next version of the platform will happen in
    178   private until it's ready to become an official release.
    179 </p>
    180 <p>
    181   We recognize many contributors will disagree with this approach. We respect others
    182   may have a different point of view; however, this is the approach we feel is best, and
    183   the one we've chosen to implement.
    184 </p>
    185 
    186   </body>
    187 </html>
    188