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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
<html devsite>
<head>
<title>Non-A/B System Updates</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>On older Android devices without A/B partitions, the flash space
typically contains the following partitions:
</p>
<dl>
<dt>boot</dt>
<dd>
Contains the Linux kernel and a minimal root filesystem (loaded into
a RAM disk). It mounts system and other partitions and starts the
runtime located on the system partition.
</dd>
<dt>system</dt>
<dd>
Contains system applications and libraries that have source code
available on Android Open Source Project (AOSP). During normal
operation, this partition is mounted read-only; its contents change
only during an OTA update.
</dd>
<dt>vendor</dt>
<dd>
Contains system applications and libraries that do <em>not</em> have
source code available on Android Open Source Project (AOSP). During
normal operation, this partition is mounted read-only; its contents
change only during an OTA update.
</dd>
<dt>userdata</dt>
<dd>
Stores the data saved by applications installed by the user, etc. This
partition is not normally touched by the OTA update process.
</dd>
<dt>cache</dt>
<dd>
Temporary holding area used by a few applications (accessing this
partition requires special app permissions) and for storage of
downloaded OTA update packages. Other programs use this space with the
expectation that files can disappear at any time. Some OTA package
installations may result in this partition being wiped completely.
</dd>
<dt>recovery</dt>
<dd>
Contains a second complete Linux system, including a kernel and the
special recovery binary that reads a package and uses its contents to
update the other partitions.
</dd>
<dt>misc</dt>
<dd>
Tiny partition used by recovery to stash some information away about
what it is doing in case the device is restarted while the OTA package
is being applied.
</dd>
</dl>
<h2 id="life-ota-update">Life of an OTA update</h2>
<p>A typical OTA update contains the following steps:</p>
<ol>
<li>
Device performs regular check in with OTA servers and is notified of
the availability of an update, including the URL of the update
package and a description string to show the user.
</li>
<li>
Update downloads to a cache or data partition, and its cryptographic
signature is verified against the certificates in
<code>/system/etc/security/otacerts.zip</code>. User is prompted to
install the update.
</li>
<li>
Device reboots into recovery mode, in which the kernel and system in
the recovery partition are booted instead of the kernel in the boot
partition.
</li>
<li>
Recovery binary is started by init. It finds command-line arguments
in <code>/cache/recovery/command</code> that point it to the
downloaded package.
</li>
<li>
Recovery verifies the cryptographic signature of the package against
the public keys in <code>/res/keys</code> (part of the RAM disk
contained in the recovery partition).
</li>
<li>
Data is pulled from the package and used to update the boot, system,
and/or vendor partitions as necessary. One of the new files left on
the system partition contains the contents of the new recovery partition.
</li>
<li>Device reboots normally.
<ol style="list-style-type:lower-alpha">
<li>
The newly updated boot partition is loaded, and it mounts and
starts executing binaries in the newly updated system partition.
</li>
<li>
As part of normal startup, the system checks the contents of the
recovery partition against the desired contents (which were
previously stored as a file in <code>/system</code>). They are
different, so the recovery partition is reflashed with the
desired contents. (On subsequent boots, the recovery partition
already contains the new contents, so no reflash is necessary.)
</li>
</ol>
</li>
</ol>
<p>The system update is complete!</p>
<h2 id="migrating">Migrating from previous releases</h2>
<p>
When migrating from Android 2.3/3.0/4.0 release, the major change is
the conversion of all the device-specific functionality from a set of
C functions with predefined names to C++ objects. The following table
lists the old functions and the new methods that serve a roughly equivalent purpose:
</p>
<table>
<tr>
<th>C function</th>
<th>C++ method</th>
</tr>
<tr>
<td>device_recovery_start()</td>
<td>Device::RecoveryStart()</td>
</tr>
<tr>
<td>device_toggle_display()<br />
device_reboot_now()<br />
</td>
<td>RecoveryUI::CheckKey()<br />
(also RecoveryUI::IsKeyPressed())<br />
</td>
</tr>
<tr>
<td>device_handle_key()</td>
<td>Device::HandleMenuKey()</td>
</tr>
<tr>
<td>device_perform_action()</td>
<td>Device::InvokeMenuItem()</td>
</tr>
<tr>
<td>device_wipe_data()</td>
<td>Device::WipeData()</td>
</tr>
<tr>
<td>device_ui_init()</td>
<td>ScreenRecoveryUI::Init()</td>
</tr>
</table>
<p>
Conversion of old functions to new methods should be reasonably
straightforward. Don't forget to add the new <code>make_device()</code>
function to create and return an instance of your new Device subclass.
</p>
</body>
</html>
|
