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