Merge "Fix id attribute on h3 tag for 4.2.x and earlier instructions"
diff --git a/src/accessories/audio.jd b/src/accessories/audio.jd
index f4a316c..92ce6fe 100644
--- a/src/accessories/audio.jd
+++ b/src/accessories/audio.jd
@@ -48,7 +48,7 @@
href="custom.html#audio-over-usb">Connecting custom audio over USB</a>.</p>
<p>Host mode enables the Android device to drive the USB bus and operate with a
wide range of USB-based peripherals, including audio interfaces. Host mode
-audio is described in <a href="{@docRoot}devices/audio_usb.html">USB Digital Audio</a>
+audio is described in <a href="{@docRoot}devices/audio/usb.html">USB Digital Audio</a>
<h2 id="audio-over-bluetooth">Audio over Bluetooth</h2>
<p>An accessory that connects with Android over Bluetooth can use an Advanced Audio Distribution
diff --git a/src/accessories/headset-spec.jd b/src/accessories/headset-spec.jd
index d87c19a..c9a749e 100644
--- a/src/accessories/headset-spec.jd
+++ b/src/accessories/headset-spec.jd
@@ -24,7 +24,7 @@
</div>
</div>
-<p><em>Version 1.0</em></p>
+<p><em>Version 1.1</em></p>
<p>This document specifies the requirements for headsets and mobile devices to
function uniformly across the Android ecosystem. It is separated into two
@@ -127,7 +127,7 @@
<p>Optional</p>
</td>
<td>
-<p>Reserved (Nexus devices will use this reserved function to launch Google Now
+<p>Reserved (Nexus devices will use this reserved function to launch Google
voice search)</p>
</td>
</tr>
@@ -284,25 +284,40 @@
</tr>
</table>
+<p>In the following diagrams, Button A is mapped to Function A, Button B to
+Function B, and so on.</p>
+
<h3 id=reference_headset_test_circuit_1>Reference Headset Test Circuit 1</h3>
<img src="images/headset-circuit1.png" alt="Reference Headset Test Circuit 1" />
<p class="img-caption"><strong>Figure 1.</strong> Reference headset test circuit 1</p>
-<p class="note"><strong>Note:</strong> Four-segment plug shows CTIA pinout. For
-OMTP pinout, please swap MIC and GND segments.</p>
+<p class="note"><strong>Note:</strong> The above diagram shows the CTIA pinout
+for a 4-segment plug. For the OMTP pinout, switch the positions of the MIC and
+GND segments.</p>
<h3 id=reference_headset_test_circuit_2>Reference Headset Test Circuit 2</h3>
+<p>The second reference circuit shows how the actual resistor values (R1 - R4)
+are altered to meet this specification.</p>
+
<img src="images/headset-circuit2.png" alt="Reference Headset Test Circuit 2" />
<p class="img-caption"><strong>Figure 2.</strong> Reference headset test circuit 2</p>
-<p class="note"><strong>Note:</strong> The second reference circuit above
-illustrates how the actual resistor values (R1 - R4) will change based on the
-microphone capsule resistance to achieve the equivalent impedance values as
-required by the specification. The example above assumes a 5 kOhm microphone
-impedance. Therefore, as an example, to achieve an equivalent R4 impedance of
-135 Ohm, the actual R4 resistor value needs to be 139 Ohms.</p>
+<p>The actual resistance of the buttons parallel with the microphone (R1-R4) is
+based on the microphone capsule resistance (Rmic) and the equivalent impedance
+values (ReqA-ReqD). Use the following formula:</p>
+
+<p><em>Rn=(Rmic*ReqN) / (ReqN-Rmic)</em></p>
+
+<p>Where R<em>n</em> is the actual resistance of a button, Req<em>N</em> is the
+equivalent impedance value of that button (provided), and Rmic is the
+microphone impedance value.</p>
+
+<p>The example above assumes a 5 kohm microphone impedance (Rmic). Therefore, to
+achieve an equivalent R4 impedance of 135 ohm (ReqD), the actual resistor value
+(R4) needs to be 139 ohms.</p>
+
<h2 id=mobile_device_jack_specifications>Mobile Device (Jack) Specifications</h2>
@@ -548,7 +563,7 @@
</tr>
<tr>
<td>
-<p>Minimum output voltage drive capacity </p>
+<p>Maximum output voltage drive</p>
</td>
<td>
<p>150mV </p>
diff --git a/src/accessories/images/headset-circuit1.png b/src/accessories/images/headset-circuit1.png
index c69df98..f3e622a 100644
--- a/src/accessories/images/headset-circuit1.png
+++ b/src/accessories/images/headset-circuit1.png
Binary files differ
diff --git a/src/accessories/images/headset-circuit2.png b/src/accessories/images/headset-circuit2.png
index 67bd5b4..ff6b541 100644
--- a/src/accessories/images/headset-circuit2.png
+++ b/src/accessories/images/headset-circuit2.png
Binary files differ
diff --git a/src/app.yaml b/src/app.yaml
index f8f4788..045fe2d 100644
--- a/src/app.yaml
+++ b/src/app.yaml
@@ -1,38 +1,15 @@
-application: androidsourcedocs-staging
-version: 1
+application: google.com:sourceandroid-staging
+version: 11
runtime: python
api_version: 1
-# This file defines two mutually exclusive
-# hander blocks:
-# - a handler for use on a local dev_appserver
-# during development or non-production doc build
-# - a handler for use on a production gae
-# instance. This handler requires that the
-# docs files in the app have been compressed
-# with divide_and_compress.py and that main.py
-# and gae_shell/ are present.
-#
-# Only one of the handler blocks should be
-# uncommented at any given time. By default,
-# the development handler is exposed.
-
handlers:
-
-# DEVELOPMENT HANDLER
-# (this handler block *must* be commented
-# out before pushing to a production server)
+# re-direct to index.html if no path is given
- url: /
- static_dir: /
+ static_files: index.html
+ upload: index.html
-# PRODUCTION GAE HANDLER
-#- url: /gae_shell/static
-# static_dir: gae_shell/static
-# expiration: 1d
-#
-#- url: /gae_shell/.*
-# script: /gae_shell/shell.py
-# login: admin
-#
-#- url: .*
-# script: main.py
+# access the static resources in the root directory
+- url: /(.*)
+ static_files: \1
+ upload: (.*)
diff --git a/src/compatibility/contact-us.jd b/src/compatibility/contact-us.jd
index b0580ba..f138dbb 100644
--- a/src/compatibility/contact-us.jd
+++ b/src/compatibility/contact-us.jd
@@ -38,7 +38,7 @@
</ul>
<p>To make best use of this list, please first read <em>Getting the Most from
-Our Lists</em> on the <a href="{@docRoot}community/index.html">Community</a>
+Our Lists</em> on the <a href="{@docRoot}source/community/index.html">Community</a>
page. Users looking for help with Android devices should contact their carrier
or manufacturer for help.</p>
diff --git a/src/devices/audio_attributes.jd b/src/devices/audio/attributes.jd
similarity index 100%
rename from src/devices/audio_attributes.jd
rename to src/devices/audio/attributes.jd
diff --git a/src/devices/audio_avoiding_pi.jd b/src/devices/audio/avoiding_pi.jd
similarity index 97%
rename from src/devices/audio_avoiding_pi.jd
rename to src/devices/audio/avoiding_pi.jd
index e884f8c..ec407d7 100644
--- a/src/devices/audio_avoiding_pi.jd
+++ b/src/devices/audio/avoiding_pi.jd
@@ -182,13 +182,8 @@
</p>
<p class="note"><strong>Note:</strong> Atomic operations and their interactions with memory barriers
-<<<<<<< HEAD
-are notoriously badly misunderstood and used incorrectly. These methods are
-included here for completeness but recommend you also read the article
-=======
are notoriously badly misunderstood and used incorrectly. We include these methods
here for completeness but recommend you also read the article
->>>>>>> goog/lmp-dev
<a href="https://developer.android.com/training/articles/smp.html">
SMP Primer for Android</a>
for further information.
diff --git a/src/devices/audio_debugging.jd b/src/devices/audio/debugging.jd
similarity index 98%
rename from src/devices/audio_debugging.jd
rename to src/devices/audio/debugging.jd
index b54cf59..8cee394 100644
--- a/src/devices/audio_debugging.jd
+++ b/src/devices/audio/debugging.jd
@@ -260,7 +260,7 @@
The diagram below shows the relationship of the <code>mediaserver</code> process
and the <code>init</code> process, before <code>media.log</code> is introduced:
</p>
-<img src="audio/images/medialog_before.png" alt="Architecture before media.log" />
+<img src="images/medialog_before.png" alt="Architecture before media.log" />
<p>
Notable points:
</p>
@@ -274,7 +274,7 @@
The diagram below shows the new relationship of the components,
after <code>media.log</code> is added to the architecture:
</p>
-<img src="audio/images/medialog_after.png" alt="Architecture after media.log" />
+<img src="images/medialog_after.png" alt="Architecture after media.log" />
<p>
Important changes:
</p>
diff --git a/src/devices/funplug.jd b/src/devices/audio/funplug.jd
similarity index 86%
rename from src/devices/funplug.jd
rename to src/devices/audio/funplug.jd
index f3e222b..9200556 100644
--- a/src/devices/funplug.jd
+++ b/src/devices/audio/funplug.jd
@@ -32,13 +32,13 @@
that we call the "FunPlug."
The Chrome hardware team designed this circuit and plug for functional testing;
however it has many other uses too. The Android audio team uses it to measure
-<a href="audio_latency_measure.html#measuringRoundTrip">round-trip audio latency</a>,
+<a href="latency_measure.html#measuringRoundTrip">round-trip audio latency</a>,
via the Larsen effect (feedback loop).
</p>
<h2 id="funplugCircuit">FunPlug circuit</h2>
-<img src="audio/images/funplug_circuit.png" alt="FunPlug circuit" />
+<img src="images/funplug_circuit.png" alt="FunPlug circuit" />
<p>
To ensure that the output signal will not overload the microphone input,
@@ -49,5 +49,5 @@
<h2 id="funplugAssembled">FunPlug assembled</h2>
-<img src="audio/images/funplug_assembled.jpg" alt="FunPlug fully assembled" />
+<img src="images/funplug_assembled.jpg" alt="FunPlug fully assembled" />
diff --git a/src/devices/images/audio_hal.png b/src/devices/audio/images/audio_hal.png
similarity index 100%
rename from src/devices/images/audio_hal.png
rename to src/devices/audio/images/audio_hal.png
Binary files differ
diff --git a/src/devices/images/breadboard.jpg b/src/devices/audio/images/breadboard.jpg
similarity index 100%
rename from src/devices/images/breadboard.jpg
rename to src/devices/audio/images/breadboard.jpg
Binary files differ
diff --git a/src/devices/images/display.jpg b/src/devices/audio/images/display.jpg
similarity index 100%
rename from src/devices/images/display.jpg
rename to src/devices/audio/images/display.jpg
Binary files differ
diff --git a/src/devices/images/pcb.jpg b/src/devices/audio/images/pcb.jpg
similarity index 100%
rename from src/devices/images/pcb.jpg
rename to src/devices/audio/images/pcb.jpg
Binary files differ
diff --git a/src/devices/audio_implement.jd b/src/devices/audio/implement.jd
similarity index 98%
rename from src/devices/audio_implement.jd
rename to src/devices/audio/implement.jd
index 4535640..28f06b7 100644
--- a/src/devices/audio_implement.jd
+++ b/src/devices/audio/implement.jd
@@ -96,7 +96,7 @@
<h3 id="codecs">Media codecs</h3>
<p>Ensure the audio codecs your hardware and drivers support are properly declared for your
-product. For details on declaring supported codecs, see <a href="media.html#expose"> Exposing Codecs
+product. For details on declaring supported codecs, see <a href="{@docRoot}devices/media.html#expose">Exposing Codecs
to the Framework</a>.</p>
<h2 id="configuring">Configuring the shared library</h2>
@@ -227,7 +227,7 @@
not enable the noise suppression pre-processing effect. It should not be turned on by default when
recording from this audio source, and you should not enable it in your own audio_effects.conf file.
Turning on the effect by default will cause the device to fail the <a
-href="/compatibility/index.html"> compatibility requirement</a> regardless of whether this was on by
+href="{@docRoot}compatibility/index.html"> compatibility requirement</a> regardless of whether this was on by
default due to configuration file , or the audio HAL implementation's default behavior.</p>
<p>The following example enables pre-processing for the VoIP <code>AudioSource</code> and Camcorder
diff --git a/src/devices/audio.jd b/src/devices/audio/index.jd
similarity index 100%
rename from src/devices/audio.jd
rename to src/devices/audio/index.jd
diff --git a/src/devices/audio_latency.jd b/src/devices/audio/latency.jd
similarity index 98%
rename from src/devices/audio_latency.jd
rename to src/devices/audio/latency.jd
index f4a6367..815f5b9 100644
--- a/src/devices/audio_latency.jd
+++ b/src/devices/audio/latency.jd
@@ -27,7 +27,7 @@
<p>Audio latency is the time delay as an audio signal passes through a system.
For a complete description of audio latency for the purposes of Android
compatibility, see <em>Section 5.5 Audio Latency</em>
- in the <a href="http://source.android.com/compatibility/index.html">Android CDD</a>.
+ in the <a href="{@docRoot}compatibility/index.html">Android CDD</a>.
See <a href="latency_design.html">Design For Reduced Latency</a> for an
understanding of Android's audio latency-reduction efforts.
</p>
diff --git a/src/devices/latency_design.jd b/src/devices/audio/latency_design.jd
similarity index 100%
rename from src/devices/latency_design.jd
rename to src/devices/audio/latency_design.jd
diff --git a/src/devices/audio_latency_measure.jd b/src/devices/audio/latency_measure.jd
similarity index 98%
rename from src/devices/audio_latency_measure.jd
rename to src/devices/audio/latency_measure.jd
index 1c6739b..cd9df27 100644
--- a/src/devices/audio_latency_measure.jd
+++ b/src/devices/audio/latency_measure.jd
@@ -132,7 +132,7 @@
should not be extrapolated.
</p>
-<img src="audio/images/round_trip.png" alt="round-trip measurement" />
+<img src="images/round_trip.png" alt="round-trip measurement" />
<h2 id="measuringInput">Measuring Input Latency</h2>
diff --git a/src/devices/audio_src.jd b/src/devices/audio/src.jd
similarity index 100%
rename from src/devices/audio_src.jd
rename to src/devices/audio/src.jd
diff --git a/src/devices/audio_terminology.jd b/src/devices/audio/terminology.jd
similarity index 98%
rename from src/devices/audio_terminology.jd
rename to src/devices/audio/terminology.jd
index ad24976..b1b12b6 100644
--- a/src/devices/audio_terminology.jd
+++ b/src/devices/audio/terminology.jd
@@ -488,7 +488,7 @@
<dt>AudioResampler</dt>
<dd>
The module within AudioFlinger responsible for
-<a href="audio_src.html">sample rate conversion</a>.
+<a href="src.html">sample rate conversion</a>.
</dd>
<dt>AudioTrack</dt>
@@ -609,7 +609,7 @@
<dt>tee sink</dt>
<dd>
See the separate article on tee sink in
-<a href="audio_debugging.html#teeSink">Audio Debugging</a>.
+<a href="debugging.html#teeSink">Audio Debugging</a>.
</dd>
<dt>tinyalsa</dt>
diff --git a/src/devices/testing_circuit.jd b/src/devices/audio/testing_circuit.jd
similarity index 97%
rename from src/devices/testing_circuit.jd
rename to src/devices/audio/testing_circuit.jd
index 604f85e..040755d 100644
--- a/src/devices/testing_circuit.jd
+++ b/src/devices/audio/testing_circuit.jd
@@ -29,7 +29,7 @@
contains CAD files for an A/V sync and latency testing
printed circuit board (PCB).
The files include a fabrication drawing, EAGLE CAD, schematic, and BOM. See <a
-href="audio_latency.html">Audio Latency</a> for recommended testing methods.
+href="latency.html">Audio Latency</a> for recommended testing methods.
</p>
<p>
diff --git a/src/devices/audio_tv.jd b/src/devices/audio/tv.jd
similarity index 97%
rename from src/devices/audio_tv.jd
rename to src/devices/audio/tv.jd
index 4bcb55e..8cd97b9 100644
--- a/src/devices/audio_tv.jd
+++ b/src/devices/audio/tv.jd
@@ -36,7 +36,7 @@
<p>The TIF then uses AudioPort information for the audio routing API.</p>
-<p><img src="audio/images/ape_audio_tv_tif.png" alt="Android TV Input Framework (TIF)" />
+<p><img src="images/ape_audio_tv_tif.png" alt="Android TV Input Framework (TIF)" />
<p class="img-caption"><strong>Figure 1.</strong> TV Input Framework (TIF)</p>
<h2 id="Requirements">Requirements</h2>
@@ -280,7 +280,7 @@
and the default output (e.g. the speaker). The tuner output does not require decoding, but final
audio output is mixed with software output_stream.</p>
-<p><img src="audio/images/ape_audio_tv_tuner.png" alt="Android TV Tuner Audio Patch" />
+<p><img src="images/ape_audio_tv_tuner.png" alt="Android TV Tuner Audio Patch" />
<p class="img-caption">
<strong>Figure 2.</strong> Audio Patch for TV tuner with speaker output.</p>
@@ -291,6 +291,6 @@
. The output device of all output_streams changes to the HDMI_OUT port, and the TIF manager changes
the sink port of the existing tuner audio patch to the HDMI_OUT port.</p>
-<p><p><img src="audio/images/ape_audio_tv_hdmi_tuner.png" alt="Android TV HDMI-OUT Audio Patch" />
+<p><p><img src="images/ape_audio_tv_hdmi_tuner.png" alt="Android TV HDMI-OUT Audio Patch" />
<p class="img-caption">
-<strong>Figure 3.</strong> Audio Patch for HDMI OUT from live TV.</p>
\ No newline at end of file
+<strong>Figure 3.</strong> Audio Patch for HDMI OUT from live TV.</p>
diff --git a/src/devices/audio_usb.jd b/src/devices/audio/usb.jd
similarity index 98%
rename from src/devices/audio_usb.jd
rename to src/devices/audio/usb.jd
index 8e8fdaf..c01105f 100644
--- a/src/devices/audio_usb.jd
+++ b/src/devices/audio/usb.jd
@@ -151,7 +151,7 @@
such as this is usually required:
</p>
-<img src="audio/images/otg.jpg" style="image-orientation: 90deg;" height="50%" width="50%" alt="OTG">
+<img src="images/otg.jpg" style="image-orientation: 90deg;" height="50%" width="50%" alt="OTG">
<p>
An Android device might not provide sufficient power to operate a
@@ -162,7 +162,7 @@
<a href="http://en.wikipedia.org/wiki/USB_hub">hub</a> such as this:
</p>
-<img src="audio/images/hub.jpg" alt="Powered hub">
+<img src="images/hub.jpg" alt="Powered hub">
<h3 id="accessoryMode">Accessory mode</h3>
@@ -434,7 +434,7 @@
also with headphones.
</p>
-<img src="audio/images/dac.png" alt="DAC comparison">
+<img src="images/dac.png" alt="DAC comparison">
<p>
Which design is better? The answer depends on your needs.
@@ -592,7 +592,7 @@
implementation for USB audio is located here:
<pre>hardware/libhardware/modules/usbaudio/</pre>
The USB audio HAL relies heavily on
-<i>tinyalsa</i>, described at <a href="audio_terminology.html">Audio Terminology</a>.
+<i>tinyalsa</i>, described at <a href="terminology.html">Audio Terminology</a>.
Though USB audio relies on isochronous transfers,
this is abstracted away by the ALSA implementation.
So the USB audio HAL and tinyalsa do not need to concern
diff --git a/src/devices/audio_warmup.jd b/src/devices/audio/warmup.jd
similarity index 100%
rename from src/devices/audio_warmup.jd
rename to src/devices/audio/warmup.jd
diff --git a/src/devices/camera/camera.jd b/src/devices/camera/index.jd
similarity index 100%
rename from src/devices/camera/camera.jd
rename to src/devices/camera/index.jd
diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
index 22fa3d0..05a51d3 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -26,39 +26,39 @@
<ul>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/audio.html">
+ <a href="<?cs var:toroot ?>devices/audio/index.html">
<span class="en">Audio</span>
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/audio_terminology.html">Terminology</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio_implement.html">Implementation</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio_attributes.html">Attributes</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio_warmup.html">Warmup</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/terminology.html">Terminology</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/implement.html">Implementation</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/attributes.html">Attributes</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/warmup.html">Warmup</a></li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/audio_latency.html">
+ <a href="<?cs var:toroot ?>devices/audio/latency.html">
<span class="en">Latency</span>
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/audio_latency_measure.html">Measure</a></li>
- <li><a href="<?cs var:toroot ?>devices/latency_design.html">Design</a></li>
- <li><a href="<?cs var:toroot ?>devices/testing_circuit.html">Light Testing Circuit</a></li>
- <li><a href="<?cs var:toroot ?>devices/funplug.html">FunPlug Audio Dongle</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/latency_measure.html">Measure</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/latency_design.html">Design</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/testing_circuit.html">Light Testing Circuit</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/funplug.html">FunPlug Audio Dongle</a></li>
</ul>
</li>
- <li><a href="<?cs var:toroot ?>devices/audio_avoiding_pi.html">Priority Inversion</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio_src.html">Sample Rate Conversion</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio_debugging.html">Debugging</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio_usb.html">USB Digital Audio</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio_tv.html">TV Audio</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/avoiding_pi.html">Priority Inversion</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/src.html">Sample Rate Conversion</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/debugging.html">Debugging</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/usb.html">USB Digital Audio</a></li>
+ <li><a href="<?cs var:toroot ?>devices/audio/tv.html">TV Audio</a></li>
</ul>
</li>
<li><a href="<?cs var:toroot ?>devices/bluetooth.html">Bluetooth</a></li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/camera/camera.html">
+ <a href="<?cs var:toroot ?>devices/camera/index.html">
<span class="en">Camera</span>
</a>
</div>
@@ -77,18 +77,18 @@
<li><a href="<?cs var:toroot ?>devices/drm.html">DRM</a></li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/tech/storage/index.html">
+ <a href="<?cs var:toroot ?>devices/storage/index.html">
<span class="en">External Storage</span>
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/tech/storage/config.html">Device Specific Configuration</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/storage/config-example.html">Typical Configuration Examples</a></li>
+ <li><a href="<?cs var:toroot ?>devices/storage/config.html">Device Specific Configuration</a></li>
+ <li><a href="<?cs var:toroot ?>devices/storage/config-example.html">Typical Configuration Examples</a></li>
</ul>
</li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/graphics.html">
+ <a href="<?cs var:toroot ?>devices/graphics/index.html">
<span class="en">Graphics</span>
</a>
</div>
@@ -99,21 +99,21 @@
</li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/tech/input/index.html">
+ <a href="<?cs var:toroot ?>devices/input/index.html">
<span class="en">Input</span>
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/tech/input/overview.html">Overview</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/key-layout-files.html">Key Layout Files</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/key-character-map-files.html">Key Character Map Files</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/input-device-configuration-files.html">Input Device Configuration Files</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/migration-guide.html">Migration Guide</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/keyboard-devices.html">Keyboard Devices</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/touch-devices.html">Touch Devices</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/dumpsys.html">Dumpsys</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/getevent.html">Getevent</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/input/validate-keymaps.html">Validate Keymaps</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/overview.html">Overview</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/key-layout-files.html">Key Layout Files</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/key-character-map-files.html">Key Character Map Files</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/input-device-configuration-files.html">Input Device Configuration Files</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/migration-guide.html">Migration Guide</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/keyboard-devices.html">Keyboard Devices</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/touch-devices.html">Touch Devices</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/dumpsys.html">Dumpsys</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/getevent.html">Getevent</a></li>
+ <li><a href="<?cs var:toroot ?>devices/input/validate-keymaps.html">Validate Keymaps</a></li>
</ul>
</li>
<li><a href="<?cs var:toroot ?>devices/media.html">Media</a></li>
@@ -226,13 +226,13 @@
</li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/debugtune.html">
+ <a href="<?cs var:toroot ?>devices/tech/debug/index.html">
<span class="en">Debugging and Tuning</span>
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/tuning.html">Performance Tuning</a></li>
- <li><a href="<?cs var:toroot ?>devices/native-memory.html">Native Memory Usage</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/debug/tuning.html">Performance Tuning</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/debug/native-memory.html">Native Memory Usage</a></li>
</ul>
</li>
@@ -251,7 +251,7 @@
</li>
<li>
- <a href="<?cs var:toroot ?>devices/low-ram.html">
+ <a href="<?cs var:toroot ?>devices/tech/low-ram.html">
<span class="en">Low RAM</span>
</a>
</li>
@@ -261,7 +261,6 @@
<span class="en">Power</span>
</a>
</li>
-
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/tech/security/index.html">
@@ -269,43 +268,60 @@
</a>
</div>
<ul>
- <li>
- <a href="<?cs var:toroot ?>devices/tech/security/acknowledgements.html">
- <span class="en">Acknowledgements</span>
- </a>
- </li>
- <li class="nav-section">
+ <li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/tech/security/enhancements.html">
+ <a href="<?cs var:toroot ?>devices/tech/security/overview/index.html">
+ <span class="en">Overview</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/overview/kernel-security.html">Kernel security</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/overview/app-security.html">App security</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/overview/updates-resources.html">Updates and resources</a></li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/security/enhancements/index.html">
<span class="en">Enhancements</span>
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements50.html">Android 5.0</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements44.html">Android 4.4</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements43.html">Android 4.3</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements42.html">Android 4.2</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements50.html">Android 5.0</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements44.html">Android 4.4</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements43.html">Android 4.3</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements42.html">Android 4.2</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/enhancements/enhancements41.html">Android 4.1</a></li>
</ul>
</li>
- <li>
- <a href="<?cs var:toroot ?>devices/tech/security/best-practices.html">
- <span class="en">Best practices</span>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/overview/acknowledgements.html">Acknowledgements</a></li>
+ </ul>
+ </li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/security/implement.html">
+ <span class="en">Implementation</span>
</a>
- </li>
+ </div>
+ <ul>
<li>
- <a href="<?cs var:toroot ?>devices/tech/security/dm-verity.html">
- <span class="en">dm-verity on boot</span>
- </a>
- </li>
- <li>
- <a href="<?cs var:toroot ?>devices/tech/encryption/index.html">
+ <a href="<?cs var:toroot ?>devices/tech/security/encryption/index.html">
<span class="en">Encryption</span>
</a>
</li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/tech/security/se-linux.html">
- <span class="en">Security-Enhanced Linux</span>
+ <a href="<?cs var:toroot ?>devices/tech/security/secureboot/index.html">
+ <span class="en">Secure Boot</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/secureboot/verified-boot.html">Verified boot</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/secureboot/block-ota.html">Block-based OTA</a></li>
+ </ul>
+ </li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/security/selinux/index.html">
+ <span class="en">Security-Enhanced Linux</span>
</a>
</div>
<ul>
@@ -315,9 +331,9 @@
<li><a href="<?cs var:toroot ?>devices/tech/security/selinux/validate.html">Validation</a></li>
</ul>
</li>
- </ul>
+ </ul>
</li>
-
+ </ul>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/index.html">
diff --git a/src/devices/graphics.jd b/src/devices/graphics/index.jd
similarity index 97%
rename from src/devices/graphics.jd
rename to src/devices/graphics/index.jd
index c8f11e8..52d7e74 100644
--- a/src/devices/graphics.jd
+++ b/src/devices/graphics/index.jd
@@ -73,7 +73,7 @@
<p>The following diagram shows how the key components work together:</p>
-<img src="graphics/images/graphics_surface.png" alt="image-rendering components">
+<img src="images/graphics_surface.png" alt="image-rendering components">
<p class="img-caption"><strong>Figure 1.</strong> How surfaces are rendered</p>
@@ -135,7 +135,7 @@
<p>See the following diagram for a depiction of the Android graphics
pipeline:</p>
-<img src="graphics/images/graphics_pipeline.png" alt="graphics data flow">
+<img src="images/graphics_pipeline.png" alt="graphics data flow">
<p class="img-caption"><strong>Figure 2.</strong> How graphic data flow through
Android</p>
@@ -153,7 +153,7 @@
<p>See the following diagram for the BufferQueue communication process.</p>
-<img src="graphics/images/bufferqueue.png" alt="BufferQueue communication process">
+<img src="images/bufferqueue.png" alt="BufferQueue communication process">
<p class="img-caption"><strong>Figure 3.</strong> BufferQueue communication
process</p>
diff --git a/src/devices/tech/input/dumpsys.jd b/src/devices/input/dumpsys.jd
similarity index 100%
rename from src/devices/tech/input/dumpsys.jd
rename to src/devices/input/dumpsys.jd
diff --git a/src/devices/tech/input/getevent.jd b/src/devices/input/getevent.jd
similarity index 100%
rename from src/devices/tech/input/getevent.jd
rename to src/devices/input/getevent.jd
diff --git a/src/devices/tech/input/index.jd b/src/devices/input/index.jd
similarity index 100%
rename from src/devices/tech/input/index.jd
rename to src/devices/input/index.jd
diff --git a/src/devices/tech/input/input-device-configuration-files.jd b/src/devices/input/input-device-configuration-files.jd
similarity index 100%
rename from src/devices/tech/input/input-device-configuration-files.jd
rename to src/devices/input/input-device-configuration-files.jd
diff --git a/src/devices/tech/input/key-character-map-files.jd b/src/devices/input/key-character-map-files.jd
similarity index 100%
rename from src/devices/tech/input/key-character-map-files.jd
rename to src/devices/input/key-character-map-files.jd
diff --git a/src/devices/tech/input/key-layout-files.jd b/src/devices/input/key-layout-files.jd
similarity index 100%
rename from src/devices/tech/input/key-layout-files.jd
rename to src/devices/input/key-layout-files.jd
diff --git a/src/devices/tech/input/keyboard-devices.jd b/src/devices/input/keyboard-devices.jd
similarity index 100%
rename from src/devices/tech/input/keyboard-devices.jd
rename to src/devices/input/keyboard-devices.jd
diff --git a/src/devices/tech/input/migration-guide.jd b/src/devices/input/migration-guide.jd
similarity index 100%
rename from src/devices/tech/input/migration-guide.jd
rename to src/devices/input/migration-guide.jd
diff --git a/src/devices/tech/input/overview.jd b/src/devices/input/overview.jd
similarity index 100%
rename from src/devices/tech/input/overview.jd
rename to src/devices/input/overview.jd
diff --git a/src/devices/tech/input/touch-devices.jd b/src/devices/input/touch-devices.jd
similarity index 100%
rename from src/devices/tech/input/touch-devices.jd
rename to src/devices/input/touch-devices.jd
diff --git a/src/devices/tech/input/validate-keymaps.jd b/src/devices/input/validate-keymaps.jd
similarity index 97%
rename from src/devices/tech/input/validate-keymaps.jd
rename to src/devices/input/validate-keymaps.jd
index c86c49e..6a907a1 100644
--- a/src/devices/tech/input/validate-keymaps.jd
+++ b/src/devices/input/validate-keymaps.jd
@@ -25,7 +25,7 @@
<pre><code>$ mmm frameworks/base/tools/validatekeymaps
</code></pre>
<p>This command should compile a host tool called validatekeymaps into the
-<code>out/host/&lt;os&gt;/bin</code> directory.</p>
+<code>out/host/<os>/bin</code> directory.</p>
<h2 id="usage">Usage</h2>
<p>If you ran <code>envsetup.sh</code> to set up your development environment, then the
<code>validatekeymaps</code> tool should already be on your path. You can verify
diff --git a/src/devices/tech/storage/config-example.jd b/src/devices/storage/config-example.jd
similarity index 100%
rename from src/devices/tech/storage/config-example.jd
rename to src/devices/storage/config-example.jd
diff --git a/src/devices/tech/storage/config.jd b/src/devices/storage/config.jd
similarity index 100%
rename from src/devices/tech/storage/config.jd
rename to src/devices/storage/config.jd
diff --git a/src/devices/tech/storage/index.jd b/src/devices/storage/index.jd
similarity index 100%
rename from src/devices/tech/storage/index.jd
rename to src/devices/storage/index.jd
diff --git a/src/devices/debugtune.jd b/src/devices/tech/debug/index.jd
similarity index 100%
rename from src/devices/debugtune.jd
rename to src/devices/tech/debug/index.jd
diff --git a/src/devices/native-memory.jd b/src/devices/tech/debug/native-memory.jd
similarity index 100%
rename from src/devices/native-memory.jd
rename to src/devices/tech/debug/native-memory.jd
diff --git a/src/devices/tuning.jd b/src/devices/tech/debug/tuning.jd
similarity index 100%
rename from src/devices/tuning.jd
rename to src/devices/tech/debug/tuning.jd
diff --git a/src/devices/tech/index.jd b/src/devices/tech/index.jd
index 3eed8e9..a844be8 100644
--- a/src/devices/tech/index.jd
+++ b/src/devices/tech/index.jd
@@ -54,7 +54,7 @@
<h2 id="debugging">Debugging and Tuning</h2>
<p>Android is a large and complex system. This section includes tips and tricks
about debugging at the platform level.</p>
-<p><a href="{@docRoot}devices/debugtune.html">» Debugging Information</a></p>
+<p><a href="{@docRoot}devices/tech/debug/index.html">» Debugging Information</a></p>
<h2 id="HAL-technical-information">HAL File Reference</h2>
<p>Android's Hardware Abstraction Layer (HAL) provides the interface between
@@ -72,7 +72,7 @@
<p>Android supports devices with limited memory through various optimizations,
such as improved memory management, reduced system memory, and several
build-time and kernel configuration settings.</p>
-<p><a href="{@docRoot}devices/low-ram.html">» Low RAM Information</a></p>
+<p><a href="{@docRoot}devices/tech/low-ram.html">» Low RAM Information</a></p>
<h2 id="power-technical-information">Power</h2>
<p>Battery usage statistics are tracked by the framework. This involves keeping track of
diff --git a/src/devices/low-ram.jd b/src/devices/tech/low-ram.jd
similarity index 100%
rename from src/devices/low-ram.jd
rename to src/devices/tech/low-ram.jd
diff --git a/src/devices/tech/encryption/index.jd b/src/devices/tech/security/encryption/index.jd
similarity index 96%
rename from src/devices/tech/encryption/index.jd
rename to src/devices/tech/security/encryption/index.jd
index d7e9328..957e9ed 100644
--- a/src/devices/tech/encryption/index.jd
+++ b/src/devices/tech/security/encryption/index.jd
@@ -40,8 +40,10 @@
currently support fast encryption.
<li>Added the <code>forceencrypt</code> flag to encrypt on first boot.
<li>Added support for patterns and encryption without a password.
- <li>Added hardware-backed storage of the encryption key. See <a
- href="#storing_the_encrypted_key">Storing the encrypted key</a> for more details.
+ <li>Added hardware-backed storage of the encryption key using Trusted
+ Execution Environment’s (TEE) signing capability (such as in a TrustZone).
+ See <a href="#storing_the_encrypted_key">Storing the encrypted key</a> for more
+ details.
</ul>
<p class="caution"><strong>Caution:</strong> Devices upgraded to Android 5.0 and then
@@ -50,8 +52,10 @@
<h2 id=how_android_encryption_works>How Android encryption works</h2>
-<p>Android disk encryption is based on <code>dm-crypt</code>, which is a kernel feature that works at the block device layer. Because of
-this, encryption works with Embedded MultiMediaCard<strong> (</strong>eMMC) and similar flash devices that present themselves to the kernel as block
+<p>Android disk encryption is based on <code>dm-crypt</code>, which is a kernel
+feature that works at the block device layer. Because of
+this, encryption works with Embedded MultiMediaCard<strong> (</strong>eMMC) and
+similar flash devices that present themselves to the kernel as block
devices. Encryption is not possible with YAFFS, which talks directly to a raw
NAND flash chip. </p>
@@ -71,10 +75,14 @@
<li>pattern
</ul>
-<p>Upon first boot, the device generates a 128-bit key. This key is then encrypted
-with a default password, and the encrypted key is stored in the crypto
-metadata. The 128-bit key generated is valid until the next factory reset. Upon
-factory reset, a new 128-bit key is generated.</p>
+<p>Upon first boot, the device creates a randomly generated 128-bit master key
+and then hashes it with a default password and stored salt. The default password is: "default_password"
+However, the resultant hash is also signed through a TEE (such as TrustZone),
+which uses a hash of the signature to encrypt the master key.</p>
+
+<p>You can find the default password defined in the Android Open Source Project <a
+href="https://android.googlesource.com/platform/system/vold/+/master/cryptfs.c">cryptfs.c</a>
+file.</p>
<p>When the user sets the PIN/pass or password on the device, only the 128-bit key
is re-encrypted and stored. (ie. user PIN/pass/pattern changes do NOT cause
diff --git a/src/devices/tech/security/enhancements/enhancements41.jd b/src/devices/tech/security/enhancements/enhancements41.jd
new file mode 100644
index 0000000..60ae754
--- /dev/null
+++ b/src/devices/tech/security/enhancements/enhancements41.jd
@@ -0,0 +1,44 @@
+page.title=Security Enhancements in Android 1.5 through 4.1
+@jd:body
+
+<p>
+Android provides a multi-layered security model described in the <a href="{@docRoot}devices/tech/security/index.html">Android
+Security Overview</a>. Each update to Android includes dozens of
+security enhancements to protect users. The following are some of the security
+enhancements introduced in Android versions 1.5 through 4.1:</p>
+
+<dl>
+<dt><strong>Android 1.5</strong></dt>
+<dd><ul>
+<li>ProPolice to prevent stack buffer overruns (-fstack-protector)</li>
+<li>safe_iop to reduce integer overflows</li>
+<li>Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and
+to prevent chunk consolidation attacks. Chunk consolidation attacks are a
+common way to exploit heap corruption.</li>
+<li>OpenBSD calloc to prevent integer overflows during memory allocation</li>
+</ul>
+</dd>
+
+<dt><strong>Android 2.3</strong></dt>
+<dd><ul>
+<li>Format string vulnerability protections (-Wformat-security -Werror=format-security)</li>
+<li>Hardware-based No eXecute (NX) to prevent code execution on the stack and heap</li>
+<li>Linux mmap_min_addr to mitigate null pointer dereference privilege
+escalation (further enhanced in Android 4.1)</li>
+</ul>
+</dd>
+
+<dt><strong>Android 4.0</strong></dt>
+<dd>Address Space Layout Randomization (ASLR) to randomize key locations in memory
+</dd>
+
+<dt><strong>Android 4.1</strong></dt>
+<dd><ul>
+<li>PIE (Position Independent Executable) support</li>
+<li>Read-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)</li>
+<li>dmesg_restrict enabled (avoid leaking kernel addresses)</li>
+<li>kptr_restrict enabled (avoid leaking kernel addresses)</li>
+</ul>
+</dd>
+
+</dl>
diff --git a/src/devices/tech/security/enhancements42.jd b/src/devices/tech/security/enhancements/enhancements42.jd
similarity index 100%
rename from src/devices/tech/security/enhancements42.jd
rename to src/devices/tech/security/enhancements/enhancements42.jd
diff --git a/src/devices/tech/security/enhancements43.jd b/src/devices/tech/security/enhancements/enhancements43.jd
similarity index 100%
rename from src/devices/tech/security/enhancements43.jd
rename to src/devices/tech/security/enhancements/enhancements43.jd
diff --git a/src/devices/tech/security/enhancements44.jd b/src/devices/tech/security/enhancements/enhancements44.jd
similarity index 100%
rename from src/devices/tech/security/enhancements44.jd
rename to src/devices/tech/security/enhancements/enhancements44.jd
diff --git a/src/devices/tech/security/enhancements50.jd b/src/devices/tech/security/enhancements/enhancements50.jd
similarity index 100%
rename from src/devices/tech/security/enhancements50.jd
rename to src/devices/tech/security/enhancements/enhancements50.jd
diff --git a/src/devices/tech/security/enhancements.jd b/src/devices/tech/security/enhancements/index.jd
similarity index 100%
rename from src/devices/tech/security/enhancements.jd
rename to src/devices/tech/security/enhancements/index.jd
diff --git a/src/devices/tech/security/images/device_states.png b/src/devices/tech/security/images/device_states.png
new file mode 100644
index 0000000..bae5ce2
--- /dev/null
+++ b/src/devices/tech/security/images/device_states.png
Binary files differ
diff --git a/src/devices/tech/security/images/verified-boot-ui.png b/src/devices/tech/security/images/verified-boot-ui.png
new file mode 100644
index 0000000..1a16aa0
--- /dev/null
+++ b/src/devices/tech/security/images/verified-boot-ui.png
Binary files differ
diff --git a/src/devices/tech/security/images/verified_boot.png b/src/devices/tech/security/images/verified_boot.png
new file mode 100644
index 0000000..3a64f08
--- /dev/null
+++ b/src/devices/tech/security/images/verified_boot.png
Binary files differ
diff --git a/src/devices/tech/security/best-practices.jd b/src/devices/tech/security/implement.jd
similarity index 98%
rename from src/devices/tech/security/best-practices.jd
rename to src/devices/tech/security/implement.jd
index 94b4984..6b9c80e 100644
--- a/src/devices/tech/security/best-practices.jd
+++ b/src/devices/tech/security/implement.jd
@@ -1,4 +1,4 @@
-page.title=Security best practices
+page.title=Implementing Security
@jd:body
<!--
@@ -39,7 +39,7 @@
software on devices.</p>
<p>Where possible, the Android Security Team will incorporate tests into the
-<a href="http://source.android.com/compatibility/cts-intro.html">Android Compatibility Test
+<a href="{@docRoot}compatibility/cts-intro.html">Android Compatibility Test
Suite</a> (CTS) and
<a href="http://tools.android.com/tips/lint">Android Lint</a> to facilitate adoption of
these best practices. We encourage partners to contribute tests that can help
diff --git a/src/devices/tech/security/index.jd b/src/devices/tech/security/index.jd
index b2982d7..783eef1 100644
--- a/src/devices/tech/security/index.jd
+++ b/src/devices/tech/security/index.jd
@@ -1,8 +1,7 @@
-page.title=Android Security Overview
+page.title=Security
@jd:body
-
<!--
- Copyright 2013 The Android Open Source Project
+ Copyright 2014 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.
@@ -19,821 +18,118 @@
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
- <ol id="auto-toc">
- </ol>
+ <ol id="auto-toc"></ol>
</div>
</div>
<h2 id="introduction">Introduction</h2>
<p>Android is a modern mobile platform that was designed to be truly open. Android
-applications make use of advanced hardware and software, as well as local and
-served data, exposed through the platform to bring innovation and value to
-consumers. To protect that value, the platform must offer an application
-environment that ensures the security of users, data, applications, the device,
-and the network.</p>
-
+ applications make use of advanced hardware and software, as well as local and
+ served data, exposed through the platform to bring innovation and value to
+ consumers. To protect that value, the platform must offer an application
+ environment that ensures the security of users, data, applications, the device,
+ and the network.</p>
<p>Securing an open platform requires a robust security architecture and rigorous
-security programs. Android was designed with multi-layered security that
-provides the flexibility required for an open platform, while providing
-protection for all users of the platform.</p>
-
+ security programs. Android was designed with multi-layered security that
+ provides the flexibility required for an open platform, while providing
+ protection for all users of the platform.</p>
<p>Android was designed with developers in mind. Security controls were designed
-to reduce the burden on developers. Security-savvy developers can easily work
-with and rely on flexible security controls. Developers less familiar with
-security will be protected by safe defaults.</p>
-
+ to reduce the burden on developers. Security-savvy developers can easily work
+ with and rely on flexible security controls. Developers less familiar with
+ security will be protected by safe defaults.</p>
<p>Android was designed with device users in mind. Users are provided visibility
-into how applications work, and control over those applications. This design
-includes the expectation that attackers would attempt to perform common
-attacks, such as social engineering attacks to convince device users to install
-malware, and attacks on third-party applications on Android. Android was
-designed to both reduce the probability of these attacks and greatly limit the
-impact of the attack in the event it was successful.</p>
-
-<p>This document outlines the goals of the Android security program, describes the
-fundamentals of the Android security architecture, and answers the most
-pertinent questions for system architects and security analysts. This document
-focuses on the security features of Android's core platform and does not
-discuss security issues that are unique to specific applications, such as those
-related to the browser or SMS application. Recommended best practices for
-building Android devices, deploying Android devices, or developing applications
-for Android are not the goal of this document and are provided elsewhere.</p>
-
-<h1 id="background">Background</h1>
+ into how applications work, and control over those applications. This design
+ includes the expectation that attackers would attempt to perform common
+ attacks, such as social engineering attacks to convince device users to install
+ malware, and attacks on third-party applications on Android. Android was
+ designed to both reduce the probability of these attacks and greatly limit the
+ impact of the attack in the event it was successful.</p>
+<p>This documentation outlines the goals of the Android security program, describes the
+ fundamentals of the Android security architecture, and answers the most
+ pertinent questions for system architects and security analysts. This document
+ focuses on the security features of Android's core platform and does not
+ discuss security issues that are unique to specific applications, such as those
+ related to the browser or SMS application. Recommended best practices for
+ building Android devices, deploying Android devices, or developing applications
+ for Android are not the goal of this document and are provided elsewhere.</p>
+<h2 id="background">Background</h2>
<p>Android provides an open source platform and application environment for mobile
-devices.</p>
-<p>The main Android platform building blocks are:</p>
-<ul>
-<li>
-<p><strong>Device Hardware</strong>: Android runs on a wide range of hardware configurations
-including smart phones, tablets, and set-top-boxes. Android is
-processor-agnostic, but it does take advantage of some hardware-specific
-security capabilities such as ARM v6 eXecute-Never.</p>
-</li>
-<li>
-<p><strong>Android Operating System</strong>: The core operating system is built on top of
-the Linux kernel. All device resources, like camera functions, GPS data,
-Bluetooth functions, telephony functions, network connections, etc. are
-accessed through the operating system.</p>
-</li>
-<li>
-<p><strong>Android Application Runtime</strong>: Android applications are most often written
-in the Java programming language and run in the Android runtime (ART).
-However, many applications, including core Android services and applications
-are native applications or include native libraries. Both ART and native
-applications run within the same security environment, contained within the
-Application Sandbox. Applications get a dedicated part of the filesystem in
-which they can write private data, including databases and raw files.</p>
-</li>
-</ul>
-<p>Android applications extend the core Android operating system. There are two
-primary sources for applications:</p>
-<ul>
-<li>
-<p><strong>Pre-Installed Applications</strong>: Android includes a set of pre-installed
-applications including phone, email, calendar, web browser, and contacts. These
-function both as user applications and to provide key device capabilities that
-can be accessed by other applications. Pre-installed applications may be part
-of the open source Android platform, or they may be developed by an OEM for a
-specific device.</p>
-</li>
-<li>
-<p><strong>User-Installed Applications</strong>: Android provides an open development
-environment supporting any third-party application. Google Play offers
-users hundreds of thousands of applications.</p>
-</li>
-</ul>
-<p>Google provides a set of cloud-based services that are available to any
-compatible Android device. The primary services are:</p>
-<ul>
-<li>
-<p><strong>Google Play</strong>: Google Play is a collection of services that
-allow users to discover, install, and purchase applications from their Android
-device or the web. Google Play makes it easy for developers to reach Android
-users and potential customers. Google Play also provides community review,
-application <a href="https://developer.android.com/guide/publishing/licensing.html">license
-verification</a>, application security scanning, and other security services.</p>
-</li>
-<li>
-<p><strong>Android Updates</strong>: The Android update service delivers new capabilities and
-security updates to Android devices, including updates through the web or over
-the air (OTA).</p>
-</li>
-<li>
-<p><strong>Application Services</strong>: Frameworks that allow Android applications to use
-cloud capabilities such as (<a href="https://developer.android.com/guide/topics/data/backup.html">backing
-up</a>) application
-data and settings and cloud-to-device messaging
-(<a href="https://developers.google.com/android/c2dm/">C2DM</a>)
-for push messaging.</p>
-</li>
-</ul>
-<p>These services are not part of the Android Open Source Project and are out
-of scope for this document. But they are relevant to the security of most
-Android devices, so a related security document titled “Google Services for
-Android: Security Overview” is available.</p>
-<h2 id="android-security-program-overview">Android Security Program Overview</h2>
-<p>Early on in development, the core Android development team recognized that a
-robust security model was required to enable a vigorous ecosystem of
-applications and devices built on and around the Android platform and supported
-by cloud services. As a result, through its entire development lifecycle,
-Android has been subjected to a professional security program. The Android team
-has had the opportunity to observe how other mobile, desktop, and server platforms
-prevented and reacted to security issues and built a security
-program to address weak points observed in other offerings.</p>
-<p>The key components of the Android Security Program include:</p>
-<ul>
-<li><strong>Design Review</strong>: The Android security process begins early in the
-development lifecycle with the creation of a rich and configurable security
-model and design. Each major feature of the platform is reviewed by engineering
-and security resources, with appropriate security controls integrated into the
-architecture of the system.</li>
-<li><strong>Penetration Testing and Code Review</strong>: During the development of the
-platform, Android-created and open-source components are subject to vigorous
-security reviews. These reviews are performed by the Android Security Team,
-Google’s Information Security Engineering team, and independent security
-consultants. The goal of these reviews is to identify weaknesses and possible
-vulnerabilities well before the platform is open-sourced, and to simulate the
-types of analysis that will be performed by external security experts upon
-release.</li>
-<li><strong>Open Source and Community Review</strong>: The Android Open Source Project enables
-broad security review by any interested party. Android also uses open source
-technologies that have undergone significant external security review,
-such as the Linux kernel. Google Play provides a forum for users and companies
-to provide information about specific applications directly to users.</li>
-<li><strong>Incident Response</strong>: Even with all of these precautions, security issues
-may occur after shipping, which is why the Android project has created a
-comprehensive security response process. A full-time Android security team
-constantly monitors Android-specific and the general security community for
-discussion of potential vulnerabilities. Upon the discovery of legitimate
-issues, the Android team has a response process that enables the rapid
-mitigation of vulnerabilities to ensure that potential risk to all Android
-users is minimized. These cloud-supported responses can include updating the
-Android platform (over-the-air updates), removing applications from Google
-Play, and removing applications from devices in the field.</li>
-</ul>
-<h2 id="android-platform-security-architecture">Android Platform Security Architecture</h2>
-<p>Android seeks to be the most secure and usable operating system for mobile
-platforms by re-purposing traditional operating system security controls to:</p>
-<ul>
-<li>Protect user data</li>
-<li>Protect system resources (including the network)</li>
-<li>Provide application isolation</li>
-</ul>
-<p>To achieve these objectives, Android provides these key security features:</p>
-<ul>
-<li>Robust security at the OS level through the Linux kernel</li>
-<li>Mandatory application sandbox for all applications</li>
-<li>Secure interprocess communication</li>
-<li>Application signing</li>
-<li>Application-defined and user-granted permissions</li>
-</ul>
-<p>The sections below describe these and other security features of the Android
-platform. <em>Figure 1</em> summarizes the security components and considerations of
-the various levels of the Android software stack. Each component assumes that
-the components below are properly secured. With the exception of a small amount
-of Android OS code running as root, all code above the Linux Kernel is
-restricted by the Application Sandbox.</p>
+ devices.</p>
+<p>The sections and pages below describe the security features of the Android
+ platform. <em>Figure 1</em> summarizes the security components and considerations of
+ the various levels of the Android software stack. Each component assumes that
+ the components below are properly secured. With the exception of a small amount
+ of Android OS code running as root, all code above the Linux Kernel is
+ restricted by the Application Sandbox.</p>
<p><img alt="Figure 1: Android software stack" src="images/image00.png" /></p>
<p><em>Figure 1: Android software stack.</em></p>
-<h1 id="system-and-kernel-level-security">System and Kernel Level Security</h1>
-<p>At the operating system level, the Android platform provides the security of
-the Linux kernel, as well as a secure inter-process communication (IPC)
-facility to enable secure communication between applications running in
-different processes. These security features at the OS level ensure that even
-native code is constrained by the Application Sandbox. Whether that code is
-the result of included application behavior or a exploitation of an application
-vulnerability, the system would prevent the rogue application from harming
-other applications, the Android system, or the device itself.</p>
-<h2 id="linux-security">Linux Security</h2>
-<p>The foundation of the Android platform is the Linux kernel. The Linux kernel
-itself has been in widespread use for years, and is used in millions of
-security-sensitive environments. Through its history of constantly being
-researched, attacked, and fixed by thousands of developers, Linux has become a
-stable and secure kernel trusted by many corporations and security
-professionals.</p>
-<p>As the base for a mobile computing environment, the Linux kernel provides
-Android with several key security features, including:</p>
+<p>The main Android platform building blocks are:</p>
<ul>
-<li>A user-based permissions model</li>
-<li>Process isolation</li>
-<li>Extensible mechanism for secure IPC</li>
-<li>The ability to remove unnecessary and potentially insecure parts of the kernel</li>
+ <li>
+ <p><strong>Device Hardware</strong>: Android runs on a wide range of hardware configurations
+ including smart phones, tablets, and set-top-boxes. Android is
+ processor-agnostic, but it does take advantage of some hardware-specific
+ security capabilities such as ARM v6 eXecute-Never.</p>
+ </li>
+ <li>
+ <p><strong>Android Operating System</strong>: The core operating system is built on top of
+ the Linux kernel. All device resources, like camera functions, GPS data,
+ Bluetooth functions, telephony functions, network connections, etc. are
+ accessed through the operating system.</p>
+ </li>
+ <li>
+ <p><strong>Android Application Runtime</strong>: Android applications are most often written
+ in the Java programming language and run in the Dalvik virtual machine.
+ However, many applications, including core Android services and applications
+ are native applications or include native libraries. Both Dalvik and native
+ applications run within the same security environment, contained within the
+ Application Sandbox. Applications get a dedicated part of the filesystem in
+ which they can write private data, including databases and raw files.</p>
+ </li>
</ul>
-<p>As a multiuser operating system, a fundamental security objective of the Linux
-kernel is to isolate user resources from one another. The Linux security
-philosophy is to protect user resources from one another. Thus, Linux:</p>
+<p>Android applications extend the core Android operating system. There are two
+ primary sources for applications:</p>
<ul>
-<li>Prevents user A from reading user B's files</li>
-<li>Ensures that user A does not exhaust user B's memory</li>
-<li>Ensures that user A does not exhaust user B's CPU resources</li>
-<li>Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS,
-bluetooth)</li>
+ <li>
+ <p><strong>Pre-Installed Applications</strong>: Android includes a set of pre-installed
+ applications including phone, email, calendar, web browser, and contacts. These
+ function both as user applications and to provide key device capabilities that
+ can be accessed by other applications. Pre-installed applications may be part
+ of the open source Android platform, or they may be developed by an OEM for a
+ specific device.</p>
+ </li>
+ <li>
+ <p><strong>User-Installed Applications</strong>: Android provides an open development
+ environment supporting any third-party application. Google Play offers
+ users hundreds of thousands of applications.</p>
+ </li>
</ul>
-
-<h2 id="the-application-sandbox">The Application Sandbox</h2>
-<p>The Android platform takes advantage of the Linux user-based protection as a
-means of identifying and isolating application resources. The Android system
-assigns a unique user ID (UID) to each Android application and runs it as that user
-in a separate process. This approach is different from other operating systems
-(including the traditional Linux configuration), where multiple applications
-run with the same user permissions.</p>
-<p>This sets up a kernel-level Application Sandbox. The kernel enforces security
-between applications and the system at the process level through standard Linux
-facilities, such as user and group IDs that are assigned to applications. By
-default, applications cannot interact with each other and applications have
-limited access to the operating system. If application A tries to do something
-malicious like read application B's data or dial the phone without permission
-(which is a separate application), then the operating system protects against
-this because application A does not have the appropriate user privileges. The
-sandbox is simple, auditable, and based on decades-old UNIX-style user
-separation of processes and file permissions.</p>
-<p>Since the Application Sandbox is in the kernel, this security model extends to
-native code and to operating system applications. All of the software above the
-kernel in <em>Figure 1</em>, including operating system libraries, application
-framework, application runtime, and all applications run within the Application
-Sandbox. On some platforms, developers are constrained to a specific
-development framework, set of APIs, or language in order to enforce security.
-On Android, there are no restrictions on how an application can be written that
-are required to enforce security; in this respect, native code is just as
-secure as interpreted code.</p>
-<p>In some operating systems, memory corruption errors generally lead to
-completely compromising the security of the device. This is not the case in
-Android due to all applications and their resources being sandboxed at the OS
-level. A memory corruption error will only allow arbitrary code execution in
-the context of that particular application, with the permissions established by
-the operating system.</p>
-<p>Like all security features, the Application Sandbox is not unbreakable.
-However, to break out of the Application Sandbox in a properly configured
-device, one must compromise the security of the the Linux kernel.</p>
-<h2 id="system-partition-and-safe-mode">System Partition and Safe Mode</h2>
-<p>The system partition contains Android's kernel as well as the operating system
-libraries, application runtime, application framework, and applications. This
-partition is set to read-only. When a user boots the device into Safe Mode,
-only core Android applications are available. This ensures that the user can
-boot their phone into an environment that is free of third-party software.</p>
-
-<h2 id="filesystem-permissions">Filesystem Permissions</h2>
-<p>In a UNIX-style environment, filesystem permissions ensure that one user cannot
-alter or read another user's files. In the case of Android, each application
-runs as its own user. Unless the developer explicitly exposes files to other
-applications, files created by one application cannot be read or altered by
-another application.</p>
-
-<h2 id="se-linux">Security-Enhanced Linux</h2>
-
-<p>Android uses Security-Enhanced
-Linux (SELinux) to apply access control policies and establish an environment of
-mandatory access control (mac). See <a
-href="{@docRoot}devices/tech/security/se-linux.html">Validating
-Security-Enhanced Linux in
-Android</a> for details.</p>
-
-<h2 id="crypto">Cryptography</h2>
-
-<p>
-Android provides a set of cryptographic APIs for use by applications. These
-include implementations of standard and commonly used cryptographic primitives
-such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level
-protocols such as SSL and HTTPS.
-</p>
-
-<p>
-Android 4.0 introduced the
-<a href="http://developer.android.com/reference/android/security/KeyChain.html">KeyChain</a>
-class to allow applications to use the system credential storage for private
-keys and certificate chains.
-</p>
-
-<h2 id="memory-mgmt">Memory Management Security Enhancements</h2>
-
-Android includes many features that make common security issues harder to
-exploit. The Android SDK, compilers, and OS use tools to make common memory
-corruption issues significantly harder to exploit, including:
-
-<dl>
-<dt><strong>Android 1.5</strong></dt>
-<dd><ul>
-<li>ProPolice to prevent stack buffer overruns (-fstack-protector)</li>
-<li>safe_iop to reduce integer overflows</li>
-<li>Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and
-to prevent chunk consolidation attacks. Chunk consolidation attacks are a
-common way to exploit heap corruption.</li>
-<li>OpenBSD calloc to prevent integer overflows during memory allocation</li>
-</ul>
-</dd>
-
-<dt><strong>Android 2.3</strong></dt>
-<dd><ul>
-<li>Format string vulnerability protections (-Wformat-security -Werror=format-security)</li>
-<li>Hardware-based No eXecute (NX) to prevent code execution on the stack and heap</li>
-<li>Linux mmap_min_addr to mitigate null pointer dereference privilege
-escalation (further enhanced in Android 4.1)</li>
-</ul>
-</dd>
-
-<dt><strong>Android 4.0</strong></dt>
-<dd>Address Space Layout Randomization (ASLR) to randomize key locations in memory
-</dd>
-
-<dt><strong>Android 4.1</strong></dt>
-<dd><ul>
-<li>PIE (Position Independent Executable) support</li>
-<li>Read-only relocations / immediate binding (-Wl,-z,relro -Wl,-z,now)</li>
-<li>dmesg_restrict enabled (avoid leaking kernel addresses)</li>
-<li>kptr_restrict enabled (avoid leaking kernel addresses)</li>
-</ul>
-</dd>
-
-<dt><strong>Android 4.2</strong></dt>
-<dd><code>FORTIFY_SOURCE</code> for system code</dd>
-
-</dl>
-
-<h2 id="rooting">Rooting of Devices</h2>
-<p>
-By default, on Android only the kernel and a small subset of the core
-applications run with root permissions. Android does not prevent a user or
-application with root permissions from modifying the operating system, kernel,
-and any other application. In general, root has full access to all
-applications and all application data. Users that change the permissions on an
-Android device to grant root access to applications increase the security
-exposure to malicious applications and potential application flaws.
-</p>
-<p>
-The ability to modify an Android device they own is important to developers
-working with the Android platform. On many Android devices users have the
-ability to unlock the bootloader in order to allow installation of an alternate
-operating system. These alternate operating systems may allow an owner to gain
-root access for purposes of debugging applications and system components or to
-access features not presented to applications by Android APIs.
-</p>
-<p>
-On some devices, a person with physical control of a device and a USB cable is
-able to install a new operating system that provides root privileges to the
-user. To protect any existing user data from compromise the bootloader unlock
-mechanism requires that the bootloader erase any existing user data as part of
-the unlock step. Root access gained via exploiting a kernel bug or security
-hole can bypass this protection.
-</p>
-<p>
-Encrypting data with a key stored on-device does not protect the application
-data from root users. Applications can add a layer of data protection using
-encryption with a key stored off-device, such as on a server or a user
-password. This approach can provide temporary protection while the key is not
-present, but at some point the key must be provided to the application and it
-then becomes accessible to root users.
-</p>
-<p>
-A more robust approach to protecting data from root users is through the use of
-hardware solutions. OEMs may choose to implement hardware solutions that limit
-access to specific types of content such as DRM for video playback, or the
-NFC-related trusted storage for Google wallet.
-</p>
-<p>
-In the case of a lost or stolen device, full filesystem encryption on Android
-devices uses the device password to protect the encryption key, so modifying
-the bootloader or operating system is not sufficient to access user data
-without the user’s device password.
-</p>
-<h2 id="user-sec">User Security Features</h2>
-
-<h3 id="filesystem-encryption">Filesystem Encryption</h3>
-
-<p>Android 3.0 and later provides full filesystem encryption, so all user data can
-be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC
-and ESSIV:SHA256. The encryption key is protected by AES128 using a key
-derived from the user password, preventing unauthorized access to stored data
-without the user device password. To provide resistance against systematic
-password guessing attacks (e.g. “rainbow tables” or brute force), the
-password is combined with a random salt and hashed repeatedly with SHA1 using
-the standard PBKDF2 algorithm prior to being used to decrypt the filesystem
-key. To provide resistance against dictionary password guessing attacks,
-Android provides password complexity rules that can be set by the device
-administrator and enforced by the operating system. Filesystem encryption
-requires the use of a user password, pattern-based screen lock is not supported.</p>
-<p>More details on implementation of filesystem encryption are available at
-<a href="{@docRoot}devices/tech/encryption/index.html">Encryption</a>.</p>
-
-<h2 id="password-protection">Password Protection</h2>
-<p>Android can be configured to verify a user-supplied password prior to providing
-access to a device. In addition to preventing unauthorized use of the device,
-this password protects the cryptographic key for full filesystem encryption.</p>
-<p>Use of a password and/or password complexity rules can be required by a device
-administrator.</p>
-
-<h2 id="device-administration">Device Administration</h2>
-<p>Android 2.2 and later provide the Android Device Administration API, which
-provides device administration features at the system level. For example, the
-built-in Android Email application uses the APIs to improve Exchange support.
-Through the Email application, Exchange administrators can enforce password
-policies — including alphanumeric passwords or numeric PINs — across
-devices. Administrators can also remotely wipe (that is, restore factory
-defaults on) lost or stolen handsets.</p>
-<p>In addition to use in applications included with the Android system, these APIs
-are available to third-party providers of Device Management solutions. Details
-on the API are provided here:
-<a href="https://devel
-oper.android.com/guide/topics/admin/device-admin.html">https://developer.android.com/guide/topics/admin/device-admin.html</a>.</p>
-
-<h1 id="android-application-security">Android Application Security</h1>
-<h2 id="elements-of-applications">Elements of Applications</h2>
-<p>Android provides an open source platform and application environment for mobile
-devices. The core operating system is based on the Linux kernel. Android
-applications are most often written in the Java programming language and run in
-the ART runtime. However, applications can also be written in native
-code. Applications are installed from a single file with the .apk file
-extension.</p>
-<p>The main Android application building blocks are:</p>
+<p>Google provides a set of cloud-based services that are available to any
+ compatible Android device. The primary services are:</p>
<ul>
-<li>
-<p><strong>AndroidManifest.xml</strong>: The
-<a href="https://developer.android.com/guide/topics/manifest/manifes
-t-intro.html">AndroidManifest.xml</a> file is the control file that tells the system what to do with
-all the top-level components (specifically activities, services, broadcast
-receivers, and content providers described below) in an application. This also
-specifies which permissions are required.</p>
-</li>
-<li>
-<p><strong>Activities</strong>: An
-<a href="https://developer.android.com/guide/topics/fundamentals/activities.htm
-l">Activity</a> is, generally, the code for a single, user-focused task. It usually
-includes displaying a UI to the user, but it does not have to -- some
-Activities never display UIs. Typically, one of the application's Activities
-is the entry point to an application.</p>
-</li>
-<li>
-<p><strong>Services</strong>: A
-<a href="https://developer.android.com/guide/topics/fundamentals/services.html">Service</a>
-is a body of code that runs in the background. It can run in its own process,
-or in the context of another application's process. Other components "bind" to
-a Service and invoke methods on it via remote procedure calls. An example of a
-Service is a media player: even when the user quits the media-selection UI, the
-user probably still intends for music to keep playing. A Service keeps the
-music going even when the UI has completed.</p>
-</li>
-<li>
-<p><strong>Broadcast Receiver</strong>: A
-<a href="https://developer.android.com/reference/android/content/Broad
-castReceiver.html">BroadcastReceiver</a> is an object that is instantiated when an IPC mechanism
-known as an
-<a href="https://developer.android.com/reference/android/content/Intent.html">Intent</a>
-is issued by the operating system or another application. An application may
-register a receiver for the low battery message, for example, and change its
-behavior based on that information.</p>
-</li>
+ <li>
+ <p><strong>Google Play</strong>: Google Play is a collection of services that
+ allow users to discover, install, and purchase applications from their Android
+ device or the web. Google Play makes it easy for developers to reach Android
+ users and potential customers. Google Play also provides community review,
+ application <a href="https://developer.android.com/guide/publishing/licensing.html">license
+ verification</a>, application security scanning, and other security services.</p>
+ </li>
+ <li>
+ <p><strong>Android Updates</strong>: The Android update service delivers new capabilities and
+ security updates to Android devices, including updates through the web or over
+ the air (OTA).</p>
+ </li>
+ <li>
+ <p><strong>Application Services</strong>: Frameworks that allow Android applications to use
+ cloud capabilities such as (<a href="https://developer.android.com/guide/topics/data/backup.html">backing
+ up</a>) application
+ data and settings and cloud-to-device messaging
+ (<a href="https://developers.google.com/android/c2dm/">C2DM</a>)
+ for push messaging.</p>
+ </li>
</ul>
-
-<h2 id="the-android-permission-model-accessing-protected-apis">The Android Permission Model: Accessing Protected APIs</h2>
-<p>All applications on Android run in an Application Sandbox, described earlier in this document.
-By default, an Android application can only access a limited range of system
-resources. The system manages Android application access to resources that, if
-used incorrectly or maliciously, could adversely impact the user experience,
-the network, or data on the device.</p>
-<p>These restrictions are implemented in a variety of different forms. Some
-capabilities are restricted by an intentional lack of APIs to the sensitive
-functionality (e.g. there is no Android API for directly manipulating the SIM
-card). In some instances, separation of roles provides a security measure, as
-with the per-application isolation of storage. In other instances, the
-sensitive APIs are intended for use by trusted applications and protected
-through a security mechanism known as Permissions.</p>
-<p>These protected APIs include:</p>
-<ul>
-<li>Camera functions</li>
-<li>Location data (GPS)</li>
-<li>Bluetooth functions</li>
-<li>Telephony functions</li>
-<li>SMS/MMS functions</li>
-<li>Network/data connections</li>
-</ul>
-<p>These resources are only accessible through the operating system. To make use
-of the protected APIs on the device, an application must define the
-capabilities it needs in its manifest. When preparing to install an
-application, the system displays a dialog to the user that indicates the
-permissions requested and asks whether to continue the installation. If the
-user continues with the installation, the system accepts that the user has
-granted all of the requested permissions. The user can not grant or deny
-individual permissions -- the user must grant or deny all of the requested
-permissions as a block.</p>
-<p>Once granted, the permissions are applied to the application as long as it is
-installed. To avoid user confusion, the system does not notify the user again
-of the permissions granted to the application, and applications that are
-included in the core operating system or bundled by an OEM do not request
-permissions from the user. Permissions are removed if an application is
-uninstalled, so a subsequent re-installation will again result in display of
-permissions.</p>
-<p>Within the device settings, users are able to view permissions for applications
-they have previously installed. Users can also turn off some functionality
-globally when they choose, such as disabling GPS, radio, or wi-fi.</p>
-<p>In the event that an application attempts to use a protected feature which has
-not been declared in the application's manifest, the permission failure will
-typically result in a security exception being thrown back to the application.
-Protected API permission checks are enforced at the lowest possible level to
-prevent circumvention. An example of the user messaging when an application is
-installed while requesting access to protected APIs is shown in <em>Figure 2</em>.</p>
-<p>The system default permissions are described at
-<a href="https://developer.android.com/reference/android/Manifest.permission.html">https://developer.android.com/reference/android/Manifest.permission.html</a>.
-Applications may declare their own permissions for other applications to use.
-Such permissions are not listed in the above location.</p>
-<p>When defining a permission a protectionLevel attribute tells the system how the
-user is to be informed of applications requiring the permission, or who is
-allowed to hold a permission. Details on creating and using application
-specific permissions are described at
-<a href="https://develo
-per.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
-<p>There are some device capabilities, such as the ability to send SMS broadcast
-intents, that are not available to third-party applications, but that may be
-used by applications pre-installed by the OEM. These permissions use the
-signatureOrSystem permission.</p>
-<h2 id="how-users-understand-third-party-applications">How Users Understand Third-Party Applications</h2>
-<p>Android strives to make it clear to users when they are interacting with
-third-party applications and inform the user of the capabilities those
-applications have. Prior to installation of any application, the user is shown
-a clear message about the different permissions the application is requesting.
-After install, the user is not prompted again to confirm any permissions.</p>
-<p>There are many reasons to show permissions immediately prior to installation
-time. This is when user is actively reviewing information about the
-application, developer, and functionality to determine whether it matches their
-needs and expectations. It is also important that they have not yet
-established a mental or financial commitment to the app, and can easily compare
-the application to other alternative applications.</p>
-<p>Some other platforms use a different approach to user notification, requesting
-permission at the start of each session or while applications are in use. The
-vision of Android is to have users switching seamlessly between applications at
-will. Providing confirmations each time would slow down the user and prevent
-Android from delivering a great user experience. Having the user review
-permissions at install time gives the user the option to not install the
-application if they feel uncomfortable.</p>
-<p>Also, many user interface studies have shown that over-prompting the user
-causes the user to start saying "OK" to any dialog that is shown. One of
-Android's security goals is to effectively convey important security
-information to the user, which cannot be done using dialogs that the user will
-be trained to ignore. By presenting the important information once, and only
-when it is important, the user is more likely to think about what they are
-agreeing to.</p>
-<p>Some platforms choose not to show any information at all about application
-functionality. That approach prevents users from easily understanding and
-discussing application capabilities. While it is not possible for all users to
-always make fully informed decisions, the Android permissions model makes
-information about applications easily accessible to a wide range of users. For
-example, unexpected permissions requests can prompt more sophisticated users to
-ask critical questions about application functionality and share their concerns
-in places such as <a href="htts://play.google.com">Google Play</a> where they
-are visible to all users.</p>
-<table>
-<tr>
-<td><strong>Permissions at Application Install -- Google Maps</strong></td>
-<td><strong>Permissions of an Installed Application -- gMail</strong></td>
-</tr>
-<tr>
-<td>
-<img alt="Permissions at Application Install -- Google Maps" width=250
-src="images/image_install.png"/>
-</td>
-<td>
-<img alt="Permissions of an Installed Application -- gMail" width=250
-src="images/image_gmail_installed.png"/>
-</td>
-</tr>
-</table>
-
-<p><em>Figure 2: Display of permissions for applications</em></p>
-<h2 id="interprocess-communication">Interprocess Communication</h2>
-<p>Processes can communicate using any of the traditional UNIX-type mechanisms.
-Examples include the filesystem, local sockets, or signals. However, the Linux
-permissions still apply.</p>
-<p>Android also provides new IPC mechanisms:</p>
-<ul>
-<li>
-<p><strong>Binder</strong>: A lightweight capability-based remote procedure call mechanism
-designed for high performance when performing in-process and cross-process
-calls. Binder is implemented using a custom Linux driver. See
-<a href="https://developer
-.android.com/reference/android/os/Binder.html">https://developer.android.com/reference/android/os/Binder.html</a>.</p>
-</li>
-<li>
-<p><strong>Services</strong>: Services (discussed above) can provide interfaces directly
-accessible using binder.</p>
-</li>
-<li>
-<p><strong>Intents</strong>: An Intent is a simple message object that represents an
-"intention" to do something. For example, if your application wants to display
-a web page, it expresses its "Intent" to view the URL by creating an Intent
-instance and handing it off to the system. The system locates some other piece
-of code (in this case, the Browser) that knows how to handle that Intent, and
-runs it. Intents can also be used to broadcast interesting events (such as a
-notification) system-wide. See
-<a href="https://developer.android.com/reference/android/content/Intent.html">https://developer.android.com/reference/android/content/Intent.html</a>.</p>
-</li>
-<li>
-<p><strong>ContentProviders</strong>: A ContentProvider is a data storehouse that provides
-access to data on the device; the classic example is the ContentProvider that
-is used to access the user's list of contacts. An application can access data
-that other applications have exposed via a ContentProvider, and an application
-can also define its own ContentProviders to expose data of its own. See
-<a href="https://developer.android.com/reference/android/content/ContentProvider.html">https://developer.android.com/reference/android/content/ContentProvider.html</a>.</p>
-</li>
-</ul>
-<p>While it is possible to implement IPC using other mechanisms such as network
-sockets or world-writable files, these are the recommended Android IPC
-frameworks. Android developers will be encouraged to use best practices around
-securing users' data and avoiding the introduction of security vulnerabilities.</p>
-<h2 id="cost-sensitive-apis">Cost-Sensitive APIs</h2>
-<p>A cost sensitive API is any function that might generate a cost for the user or
-the network. The Android platform has placed cost sensitive APIs in the list of
-protected APIs controlled by the OS. The user will have to grant explicit
-permission to third-party applications requesting use of cost sensitive APIs.
-These APIs include:</p>
-<ul>
-<li>Telephony</li>
-<li>SMS/MMS</li>
-<li>Network/Data</li>
-<li>In-App Billing</li>
-<li>NFC Access</li>
-</ul>
-
-<p> Android 4.2 adds further control on the use of SMS. Android will provide a
-notification if an application attempts to send SMS to a short code that uses
-premium services which might cause additional charges. The user can choose
-whether to allow the application to send the message or block it.
-</p>
-
-<h2 id="sim-card-access">SIM Card Access</h2>
-<p>Low level access to the SIM card is not available to third-party apps. The OS
-handles all communications with the SIM card including access to personal
-information (contacts) on the SIM card memory. Applications also cannot access
-AT commands, as these are managed exclusively by the Radio Interface Layer
-(RIL). The RIL provides no high level APIs for these commands.</p>
-<h2 id="personal-information">Personal Information</h2>
-<p>Android has placed APIs that provide access to user data into the set of
-protected APIs. With normal usage, Android devices will also accumulate user
-data within third-party applications installed by users. Applications that
-choose to share this information can use Android OS permission checks to
-protect the data from third-party applications.</p>
-<p><img alt="Figure 3: Access to sensitive user data is only available through protected
-APIs" src="images/image03.png" /></p>
-<p><em>Figure 3: Access to sensitive user data is only available through protected
-APIs</em></p>
-<p>System content providers that are likely to contain personal or personally
-identifiable information such as contacts and calendar have been created with
-clearly identified permissions. This granularity provides the user with clear
-indication of the types of information that may be provided to the application.
- During installation, a third-party application may request permission to
-access these resources. If permission is granted, the application can be
-installed and will have access to the data requested at any time when it is
-installed.</p>
-<p>Any applications which collect personal information will, by default, have that
-data restricted only to the specific application. If an application chooses to
-make the data available to other applications though IPC, the application
-granting access can apply permissions to the IPC mechanism that are enforced by
-the operating system.</p>
-<h2 id="sensitive-data-input-devices">Sensitive Data Input Devices</h2>
-<p>Android devices frequently provide sensitive data input devices that allow
-applications to interact with the surrounding environment, such as camera,
-microphone or GPS. For a third-party application to access these devices, it
-must first be explicitly provided access by the user through the use of Android
-OS Permissions. Upon installation, the installer will prompt the user
-requesting permission to the sensor by name.</p>
-<p>If an application wants to know the user's location, the application requires a
-permission to access the user's location. Upon installation, the installer will
-prompt the user asking if the application can access the user's location. At
-any time, if the user does not want any application to access their location,
-then the user can run the "Settings" application, go to "Location & Security",
-and uncheck the "Use wireless networks" and "Enable GPS satellites". This will
-disable location based services for all applications on the user's device.</p>
-<h2 id="device-metadata">Device Metadata</h2>
-<p>Android also strives to restrict access to data that is not intrinsically
-sensitive, but may indirectly reveal characteristics about the user, user
-preferences, and the manner in which they use a device.</p>
-<p>By default applications do not have access to operating system logs,
-browser history, phone number, or hardware / network identification
-information. If an application requests access to this information at install
-time, the installer will prompt the user asking if the application can access
-the information. If the user does not grant access, the application will not be
-installed.</p>
-<h2 id="application-signing">Application Signing</h2>
-<p>Code signing allows developers to identify the author of the application and to
-update their application without creating complicated interfaces and
-permissions. Every application that is run on the Android platform must be
-signed by the developer. Applications that attempt to install without being
-signed will rejected by either Google Play or the package installer on
-the Android device.</p>
-<p>On Google Play, application signing bridges the trust Google has with the
-developer and the trust the developer has with their application. Developers
-know their application is provided, unmodified to the Android device; and
-developers can be held accountable for behavior of their application.</p>
-<p>On Android, application signing is the first step to placing an application in
-its Application Sandbox. The signed application certificate defines which user
-id is associated with which application; different applications run under
-different user IDs. Application signing ensures that one application cannot
-access any other application except through well-defined IPC.</p>
-<p>When an application (APK file) is installed onto an Android device, the Package
-Manager verifies that the APK has been properly signed with the certificate
-included in that APK. If the certificate (or, more accurately, the public key
-in the certificate) matches the key used to sign any other APK on the device,
-the new APK has the option to specify in the manifest that it will share a UID
-with the other similarly-signed APKs.</p>
-<p>Applications can be signed by a third-party (OEM, operator, alternative market)
-or self-signed. Android provides code signing using self-signed certificates
-that developers can generate without external assistance or permission.
-Applications do not have to be signed by a central authority. Android currently
-does not perform CA verification for application certificates.</p>
-<p>Applications are also able to declare security permissions at the Signature
-protection level, restricting access only to applications signed with the same
-key while maintaining distinct UIDs and Application Sandboxes. A closer
-relationship with a shared Application Sandbox is allowed via the
-<a href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">shared UID
-feature</a> where two or more applications signed with same developer key can
-declare a shared UID in their manifest.</p>
-
-<h2 id="app-verification">Application Verification</h2>
-<p>
-Android 4.2 and later support application verification. Users can choose to
-enable “Verify Apps" and have applications evaluated by an application verifier
-prior to installation. App verification can alert the user if they try to
-install an app that might be harmful; if an application is especially bad, it
-can block installation.
-</p>
-
-<h2 id="digital-rights-management">Digital Rights Management</h2>
-<p>The Android platform provides an extensible DRM framework that lets
-applications manage rights-protected content according to the license
-constraints that are associated with the content. The DRM framework supports
-many DRM schemes; which DRM schemes a device supports is left to the device
-manufacturer.</p>
-<p>The <a href="https://developer.android.com/reference/android/drm/package-summary.html">Android DRM
-framework</a>
-is implemented in two architectural layers (see figure below):</p>
-<ul>
-<li>
-<p>A DRM framework API, which is exposed to applications through the Android
-application framework and runs through the ART runtime for standard applications.</p>
-</li>
-<li>
-<p>A native code DRM manager, which implements the DRM framework and exposes an
-interface for DRM plug-ins (agents) to handle rights management and decryption
-for various DRM schemes</p>
-</li>
-</ul>
-<p><img alt="Figure 4: Architecture of Digital Rights Management on Android
-platform" src="images/image02.png" /></p>
-<p><em>Figure 4: Architecture of Digital Rights Management on Android platform</em></p>
-<h1 id="android-updates">Android Updates</h1>
-<p>Android provides system updates for both security and feature related purposes.</p>
-<p>There are two ways to update the code on most Android devices: over-the-air
-(OTA updates) or side-loaded updates. OTA updates can be rolled out over a
-defined time period or be pushed to all devices at once, depending on how the
-OEM and/or carrier would like to push the updates. Side-loaded updates can be
-provided from a central location for users to download as a zip file to their
-local desktop machine or directly to their handset. Once the update is copied
-or downloaded to the SD card on the device, Android will recognize the update,
-verify its integrity and authenticity, and automatically update the device.</p>
-<p>If a dangerous vulnerability is discovered internally or responsibly reported
-to Google or the Android Open Source Project, the Android security team will
-start the following process.</p>
-<ol>
-<li>The Android team will notify companies who have signed NDAs regarding the
-problem and begin discussing the solution.</li>
-<li>The owners of code will begin the fix.</li>
-<li>The Android team will fix Android-related security issues.</li>
-<li>When a patch is available, the fix is provided to the NDA companies.</li>
-<li>The Android team will publish the patch in the Android Open Source Project</li>
-<li>OEM/carrier will push an update to customers.</li>
-</ol>
-<p>The NDA is required to ensure that the security issue does not become public
-prior to availabilty of a fix and put users at risk. Many OHA members run their
-own code on Android devices such as the bootloader, wifi drivers, and the
-radio. Once the Android Security team is notified of a security issue in this
-partner code, they will consult with OHA partners to quickly find a fix for the
-problem at hand and similar problems. However, the OHA member who wrote the
-faulty code is ultimately responsible for fixing the problem.</p>
-<p>If a dangerous vulnerability is not responsibly disclosed (e.g., if it is
-posted to a public forum without warning), then Google and/or the Android Open
-Source Project will work as quickly as possible to create a patch. The patch
-will released to the public (and any partners) when the patch is tested and
-ready for use.</p>
-<p>At Google I/O 2011, many of the largest OHA partners committed to providing
-updates to devices for 18 months after initial shipment. This will provide
-users with access to the most recent Android features, as well as security
-updates.</p>
-<p>Any developer, Android user, or security researcher can notify the Android
-security team of potential security issues by sending email to
-security@android.com. If desired, communication can be encrypted using the
-Android security team PGP key available here:
-<a href="https://developer.android.com/security_at_android_dot_com.txt">https://developer.android.com/security_at_android_dot_com.txt</a>.</p>
-<h1 id="other-resources">Other Resources</h1>
-<p>Information about the Android Open Source Project is available at
-<a href="https://source.android.com">https://source.android.com</a>.</p>
-<p>Information for Android application developers is here:
-<a href="https://developer.android.com">https://developer.android.com</a>.</p>
-<p>The Android Security team can be reached at
-<a href="mailto:security@android.com">security@android.com</a>.</p>
-<p>Security information exists throughout the Android Open Source and Developer
-Sites. A good place to start is here:
-<a href="https://developer.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
-<p>A Security FAQ for developers is located here:
-<a href="https://developer.android.com/resources/faq/security.html">https://developer.android.com/resources/faq/security.html</a>.</p>
-<p>Security Best Practices for developers is located here:
-<a href="https://developer.android.com/guide/practices/security.html">https://developer.android.com/guide/practices/security.html</a>.</p>
-<p>A community resource for discussion about Android security exists here:
-<a href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a>.</p>
+<p>These services are not part of the Android Open Source Project and are out
+ of scope for this document. But they are relevant to the security of most
+ Android devices, so a related security document titled “Google Services for
+ Android: Security Overview” is available.</p>
diff --git a/src/devices/tech/security/acknowledgements.jd b/src/devices/tech/security/overview/acknowledgements.jd
similarity index 93%
rename from src/devices/tech/security/acknowledgements.jd
rename to src/devices/tech/security/overview/acknowledgements.jd
index 2b20e90..a1531e8 100644
--- a/src/devices/tech/security/acknowledgements.jd
+++ b/src/devices/tech/security/overview/acknowledgements.jd
@@ -103,7 +103,7 @@
href="mailto:hanxinhui@pku.edu.cn">hanxinhui@pku.edu.cn</a>)</p>
<p><a href="http://thejh.net/">Jann Horn</a> <a href="https://android-review.googlesource.com/#/c/98197/">
-<img style="vertical-align:middle;" src="images/tiny-robot.png"
+<img style="vertical-align:middle;" src="../images/tiny-robot.png"
alt="Green Droid Patch Symbol"
title="This person contributed code that improved Android security">
</a></p>
@@ -111,21 +111,21 @@
<p>Robert Craig of <a href="https://www.nsa.gov/research/ia_research/">
Trusted Systems Research Group</a>, US National Security Agency
<a href="https://android-review.googlesource.com/#/q/owner:%22Robert+Craig+%253Crpcraig%2540tycho.ncsc.mil%253E%22+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png" alt="Patch Symbol"
+<img style="vertical-align:middle" src="../images/tiny-robot.png" alt="Patch Symbol"
title="This person contributed code that improved Android security"></a></p>
<p>Stephen Smalley of <a href="https://www.nsa.gov/research/ia_research/">
Trusted Systems Research Group</a>, US National Security Agency
<a href=
"https://android-review.googlesource.com/#/q/owner:%22Stephen+Smalley+%253Csds%2540tycho.nsa.gov%253E%22+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png"
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
<p><a href="http://www.linkedin.com/in/billcroberts">
William Roberts</a> (<a href="mailto:bill.c.roberts@gmail.com">bill.c.roberts@gmail.com</a>)
<a href=
"https://android-review.googlesource.com/#/q/owner:bill.c.roberts%2540gmail.com+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png"
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
<p>Scotty Bauer of University of Utah (<a href="mailto:sbauer@eng.utah.edu">sbauer@eng.utah.edu</a>)</p>
@@ -164,7 +164,7 @@
<p>Joshua J. Drake of <a href="http://www.accuvant.com/">Accuvant LABS
</a> (<a href="https://twitter.com/jduck">@jduck</a>)
<a href="https://android-review.googlesource.com/#/q/change:72228+OR+change:72229">
-<img style="vertical-align:middle" src="images/patchreward.png"
+<img style="vertical-align:middle" src="../images/patchreward.png"
alt="Patch Rewards Symbol" title="This person qualified for the Patch Rewards program!"></a></p>
<p>Ruben Santamarta of IOActive
@@ -198,21 +198,21 @@
<p>Robert Craig of <a href="https://www.nsa.gov/research/ia_research/">
Trusted Systems Research Group</a>, US National Security Agency
<a href="https://android-review.googlesource.com/#/q/owner:%22Robert+Craig+%253Crpcraig%2540tycho.ncsc.mil%253E%22+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png" alt="Patch Symbol"
+<img style="vertical-align:middle" src="../images/tiny-robot.png" alt="Patch Symbol"
title="This person contributed code that improved Android security"></a></p>
<p>Stephen Smalley of <a href="https://www.nsa.gov/research/ia_research/">
Trusted Systems Research Group</a>, US National Security Agency
<a href=
"https://android-review.googlesource.com/#/q/owner:%22Stephen+Smalley+%253Csds%2540tycho.nsa.gov%253E%22+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png"
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
<p><a href="http://www.linkedin.com/in/billcroberts">
William Roberts</a> (<a href="mailto:bill.c.roberts@gmail.com">bill.c.roberts@gmail.com</a>)
<a href=
"https://android-review.googlesource.com/#/q/owner:bill.c.roberts%2540gmail.com+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png"
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
<p><a href="http://roeehay.blogspot.com/">Roee Hay</a>
@@ -227,21 +227,21 @@
<p>Robert Craig of <a href="https://www.nsa.gov/research/ia_research/">
Trusted Systems Research Group</a>, US National Security Agency
<a href="https://android-review.googlesource.com/#/q/owner:%22Robert+Craig+%253Crpcraig%2540tycho.ncsc.mil%253E%22+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png" alt="Patch Symbol"
+<img style="vertical-align:middle" src="../images/tiny-robot.png" alt="Patch Symbol"
title="This person contributed code that improved Android security"></a></p>
<p>Stephen Smalley of <a href="https://www.nsa.gov/research/ia_research/">
Trusted Systems Research Group</a>, US National Security Agency
<a href=
"https://android-review.googlesource.com/#/q/owner:%22Stephen+Smalley+%253Csds%2540tycho.nsa.gov%253E%22+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png"
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
<p><a href="http://www.linkedin.com/in/billcroberts">
William Roberts</a> (<a href="mailto:bill.c.roberts@gmail.com">bill.c.roberts@gmail.com</a>)
<a href=
"https://android-review.googlesource.com/#/q/owner:bill.c.roberts%2540gmail.com+status:merged">
-<img style="vertical-align:middle" src="images/tiny-robot.png"
+<img style="vertical-align:middle" src="../images/tiny-robot.png"
alt="Patch Symbol" title="This person contributed code that improved Android security"></a></p>
<p><a href="http://thejh.net/">Jann Horn</a></p>
diff --git a/src/devices/tech/security/overview/app-security.jd b/src/devices/tech/security/overview/app-security.jd
new file mode 100644
index 0000000..4c468cc
--- /dev/null
+++ b/src/devices/tech/security/overview/app-security.jd
@@ -0,0 +1,340 @@
+page.title=Application security
+@jd:body
+
+<!--
+ Copyright 2014 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<h2 id="elements-of-applications">Elements of Applications</h2>
+<p>Android provides an open source platform and application environment for mobile
+ devices. The core operating system is based on the Linux kernel. Android
+ applications are most often written in the Java programming language and run in
+ the Dalvik virtual machine. However, applications can also be written in native
+ code. Applications are installed from a single file with the .apk file
+ extension.</p>
+<p>The main Android application building blocks are:</p>
+<ul>
+ <li>
+ <p><strong>AndroidManifest.xml</strong>: The <a href="https://developer.android.com/guide/topics/manifest/manifes
+t-intro.html">AndroidManifest.xml</a> file is the control file that tells the system what to do with
+ all the top-level components (specifically activities, services, broadcast
+ receivers, and content providers described below) in an application. This also
+ specifies which permissions are required.</p>
+ </li>
+ <li>
+ <p><strong>Activities</strong>: An <a href="https://developer.android.com/guide/topics/fundamentals/activities.htm
+l">Activity</a> is, generally, the code for a single, user-focused task. It usually
+ includes displaying a UI to the user, but it does not have to -- some
+ Activities never display UIs. Typically, one of the application's Activities
+ is the entry point to an application.</p>
+ </li>
+ <li>
+ <p><strong>Services</strong>: A <a href="https://developer.android.com/guide/topics/fundamentals/services.html">Service</a> is a body of code that runs in the background. It can run in its own process,
+ or in the context of another application's process. Other components "bind" to
+ a Service and invoke methods on it via remote procedure calls. An example of a
+ Service is a media player: even when the user quits the media-selection UI, the
+ user probably still intends for music to keep playing. A Service keeps the
+ music going even when the UI has completed.</p>
+ </li>
+ <li>
+ <p><strong>Broadcast Receiver</strong>: A <a href="https://developer.android.com/reference/android/content/Broad
+castReceiver.html">BroadcastReceiver</a> is an object that is instantiated when an IPC mechanism
+ known as an <a href="https://developer.android.com/reference/android/content/Intent.html">Intent</a> is issued by the operating system or another application. An application may
+ register a receiver for the low battery message, for example, and change its
+ behavior based on that information.</p>
+ </li>
+</ul>
+<h2 id="the-android-permission-model-accessing-protected-apis">The Android Permission Model: Accessing Protected APIs</h2>
+<p>All applications on Android run in an Application Sandbox, described earlier in this document.
+ By default, an Android application can only access a limited range of system
+ resources. The system manages Android application access to resources that, if
+ used incorrectly or maliciously, could adversely impact the user experience,
+ the network, or data on the device.</p>
+<p>These restrictions are implemented in a variety of different forms. Some
+ capabilities are restricted by an intentional lack of APIs to the sensitive
+ functionality (e.g. there is no Android API for directly manipulating the SIM
+ card). In some instances, separation of roles provides a security measure, as
+ with the per-application isolation of storage. In other instances, the
+ sensitive APIs are intended for use by trusted applications and protected
+ through a security mechanism known as Permissions.</p>
+<p>These protected APIs include:</p>
+<ul>
+ <li>Camera functions</li>
+ <li>Location data (GPS)</li>
+ <li>Bluetooth functions</li>
+ <li>Telephony functions</li>
+ <li>SMS/MMS functions</li>
+ <li>Network/data connections</li>
+</ul>
+<p>These resources are only accessible through the operating system. To make use
+ of the protected APIs on the device, an application must define the
+ capabilities it needs in its manifest. When preparing to install an
+ application, the system displays a dialog to the user that indicates the
+ permissions requested and asks whether to continue the installation. If the
+ user continues with the installation, the system accepts that the user has
+ granted all of the requested permissions. The user can not grant or deny
+ individual permissions -- the user must grant or deny all of the requested
+ permissions as a block.</p>
+<p>Once granted, the permissions are applied to the application as long as it is
+ installed. To avoid user confusion, the system does not notify the user again
+ of the permissions granted to the application, and applications that are
+ included in the core operating system or bundled by an OEM do not request
+ permissions from the user. Permissions are removed if an application is
+ uninstalled, so a subsequent re-installation will again result in display of
+ permissions.</p>
+<p>Within the device settings, users are able to view permissions for applications
+ they have previously installed. Users can also turn off some functionality
+ globally when they choose, such as disabling GPS, radio, or wi-fi.</p>
+<p>In the event that an application attempts to use a protected feature which has
+ not been declared in the application's manifest, the permission failure will
+ typically result in a security exception being thrown back to the application.
+ Protected API permission checks are enforced at the lowest possible level to
+ prevent circumvention. An example of the user messaging when an application is
+ installed while requesting access to protected APIs is shown in <em>Figure 2</em>.</p>
+<p>The system default permissions are described at <a href="https://developer.android.com/reference/android/Manifest.permission.html">https://developer.android.com/reference/android/Manifest.permission.html</a>.
+ Applications may declare their own permissions for other applications to use.
+ Such permissions are not listed in the above location.</p>
+<p>When defining a permission a protectionLevel attribute tells the system how the
+ user is to be informed of applications requiring the permission, or who is
+ allowed to hold a permission. Details on creating and using application
+ specific permissions are described at <a href="https://develo
+per.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
+<p>There are some device capabilities, such as the ability to send SMS broadcast
+ intents, that are not available to third-party applications, but that may be
+ used by applications pre-installed by the OEM. These permissions use the
+ signatureOrSystem permission.</p>
+<h2 id="how-users-understand-third-party-applications">How Users Understand Third-Party Applications</h2>
+<p>Android strives to make it clear to users when they are interacting with
+ third-party applications and inform the user of the capabilities those
+ applications have. Prior to installation of any application, the user is shown
+ a clear message about the different permissions the application is requesting.
+ After install, the user is not prompted again to confirm any permissions.</p>
+<p>There are many reasons to show permissions immediately prior to installation
+ time. This is when user is actively reviewing information about the
+ application, developer, and functionality to determine whether it matches their
+ needs and expectations. It is also important that they have not yet
+ established a mental or financial commitment to the app, and can easily compare
+ the application to other alternative applications.</p>
+<p>Some other platforms use a different approach to user notification, requesting
+ permission at the start of each session or while applications are in use. The
+ vision of Android is to have users switching seamlessly between applications at
+ will. Providing confirmations each time would slow down the user and prevent
+ Android from delivering a great user experience. Having the user review
+ permissions at install time gives the user the option to not install the
+ application if they feel uncomfortable.</p>
+<p>Also, many user interface studies have shown that over-prompting the user
+ causes the user to start saying "OK" to any dialog that is shown. One of
+ Android's security goals is to effectively convey important security
+ information to the user, which cannot be done using dialogs that the user will
+ be trained to ignore. By presenting the important information once, and only
+ when it is important, the user is more likely to think about what they are
+ agreeing to.</p>
+<p>Some platforms choose not to show any information at all about application
+ functionality. That approach prevents users from easily understanding and
+ discussing application capabilities. While it is not possible for all users to
+ always make fully informed decisions, the Android permissions model makes
+ information about applications easily accessible to a wide range of users. For
+ example, unexpected permissions requests can prompt more sophisticated users to
+ ask critical questions about application functionality and share their concerns
+ in places such as <a href="htts://play.google.com">Google Play</a> where they
+ are visible to all users.</p>
+<table>
+ <tr>
+ <td><strong>Permissions at Application Install -- Google Maps</strong></td>
+ <td><strong>Permissions of an Installed Application -- gMail</strong></td>
+ </tr>
+ <tr>
+ <td><img alt="Permissions at Application Install -- Google Maps" width=250
+src="../images/image_install.png"/></td>
+ <td><img alt="Permissions of an Installed Application -- gMail" width=250
+src="../images/image_gmail_installed.png"/></td>
+ </tr>
+</table>
+<p><em>Figure 2: Display of permissions for applications</em></p>
+<h2 id="interprocess-communication">Interprocess Communication</h2>
+<p>Processes can communicate using any of the traditional UNIX-type mechanisms.
+ Examples include the filesystem, local sockets, or signals. However, the Linux
+ permissions still apply.</p>
+<p>Android also provides new IPC mechanisms:</p>
+<ul>
+ <li>
+ <p><strong>Binder</strong>: A lightweight capability-based remote procedure call mechanism
+ designed for high performance when performing in-process and cross-process
+ calls. Binder is implemented using a custom Linux driver. See <a href="https://developer
+.android.com/reference/android/os/Binder.html">https://developer.android.com/reference/android/os/Binder.html</a>.</p>
+ </li>
+ <li>
+ <p><strong>Services</strong>: Services (discussed above) can provide interfaces directly
+ accessible using binder.</p>
+ </li>
+ <li>
+ <p><strong>Intents</strong>: An Intent is a simple message object that represents an
+ "intention" to do something. For example, if your application wants to display
+ a web page, it expresses its "Intent" to view the URL by creating an Intent
+ instance and handing it off to the system. The system locates some other piece
+ of code (in this case, the Browser) that knows how to handle that Intent, and
+ runs it. Intents can also be used to broadcast interesting events (such as a
+ notification) system-wide. See
+ [https://developer.android.com/reference/android/content/Intent.html](https://developer.android.com/reference/android/content/Intent.html.</p>
+ </li>
+ <li>
+ <p><strong>ContentProviders</strong>: A ContentProvider is a data storehouse that provides
+ access to data on the device; the classic example is the ContentProvider that
+ is used to access the user's list of contacts. An application can access data
+ that other applications have exposed via a ContentProvider, and an application
+ can also define its own ContentProviders to expose data of its own. See <a href="https://developer.android.com/reference/android/content/ContentProvider.html">https://developer.android.com/reference/android/content/ContentProvider.html</a>.</p>
+ </li>
+</ul>
+<p>While it is possible to implement IPC using other mechanisms such as network
+ sockets or world-writable files, these are the recommended Android IPC
+ frameworks. Android developers will be encouraged to use best practices around
+ securing users' data and avoiding the introduction of security vulnerabilities.</p>
+<h2 id="cost-sensitive-apis">Cost-Sensitive APIs</h2>
+<p>A cost sensitive API is any function that might generate a cost for the user or
+ the network. The Android platform has placed cost sensitive APIs in the list of
+ protected APIs controlled by the OS. The user will have to grant explicit
+ permission to third-party applications requesting use of cost sensitive APIs.
+ These APIs include:</p>
+<ul>
+ <li>Telephony</li>
+ <li>SMS/MMS</li>
+ <li>Network/Data</li>
+ <li>In-App Billing</li>
+ <li>NFC Access</li>
+</ul>
+<p> Android 4.2 adds further control on the use of SMS. Android will provide a
+ notification if an application attempts to send SMS to a short code that uses
+ premium services which might cause additional charges. The user can choose
+ whether to allow the application to send the message or block it. </p>
+<h2 id="sim-card-access">SIM Card Access</h2>
+<p>Low level access to the SIM card is not available to third-party apps. The OS
+ handles all communications with the SIM card including access to personal
+ information (contacts) on the SIM card memory. Applications also cannot access
+ AT commands, as these are managed exclusively by the Radio Interface Layer
+ (RIL). The RIL provides no high level APIs for these commands.</p>
+<h2 id="personal-information">Personal Information</h2>
+<p>Android has placed APIs that provide access to user data into the set of
+ protected APIs. With normal usage, Android devices will also accumulate user
+ data within third-party applications installed by users. Applications that
+ choose to share this information can use Android OS permission checks to
+ protect the data from third-party applications.</p>
+<p><img alt="Figure 3: Access to sensitive user data is only available through protected
+APIs" src="../images/image03.png" /></p>
+<p><em>Figure 3: Access to sensitive user data is only available through protected
+ APIs</em></p>
+<p>System content providers that are likely to contain personal or personally
+ identifiable information such as contacts and calendar have been created with
+ clearly identified permissions. This granularity provides the user with clear
+ indication of the types of information that may be provided to the application.
+ During installation, a third-party application may request permission to
+ access these resources. If permission is granted, the application can be
+ installed and will have access to the data requested at any time when it is
+ installed.</p>
+<p>Any applications which collect personal information will, by default, have that
+ data restricted only to the specific application. If an application chooses to
+ make the data available to other applications though IPC, the application
+ granting access can apply permissions to the IPC mechanism that are enforced by
+ the operating system.</p>
+<h2 id="sensitive-data-input-devices">Sensitive Data Input Devices</h2>
+<p>Android devices frequently provide sensitive data input devices that allow
+ applications to interact with the surrounding environment, such as camera,
+ microphone or GPS. For a third-party application to access these devices, it
+ must first be explicitly provided access by the user through the use of Android
+ OS Permissions. Upon installation, the installer will prompt the user
+ requesting permission to the sensor by name.</p>
+<p>If an application wants to know the user's location, the application requires a
+ permission to access the user's location. Upon installation, the installer will
+ prompt the user asking if the application can access the user's location. At
+ any time, if the user does not want any application to access their location,
+ then the user can run the "Settings" application, go to "Location & Security",
+ and uncheck the "Use wireless networks" and "Enable GPS satellites". This will
+ disable location based services for all applications on the user's device.</p>
+<h2 id="device-metadata">Device Metadata</h2>
+<p>Android also strives to restrict access to data that is not intrinsically
+ sensitive, but may indirectly reveal characteristics about the user, user
+ preferences, and the manner in which they use a device.</p>
+<p>By default applications do not have access to operating system logs,
+ browser history, phone number, or hardware / network identification
+ information. If an application requests access to this information at install
+ time, the installer will prompt the user asking if the application can access
+ the information. If the user does not grant access, the application will not be
+ installed.</p>
+<h2 id="application-signing">Application Signing</h2>
+<p>Code signing allows developers to identify the author of the application and to
+ update their application without creating complicated interfaces and
+ permissions. Every application that is run on the Android platform must be
+ signed by the developer. Applications that attempt to install without being
+ signed will rejected by either Google Play or the package installer on
+ the Android device.</p>
+<p>On Google Play, application signing bridges the trust Google has with the
+ developer and the trust the developer has with their application. Developers
+ know their application is provided, unmodified to the Android device; and
+ developers can be held accountable for behavior of their application.</p>
+<p>On Android, application signing is the first step to placing an application in
+ its Application Sandbox. The signed application certificate defines which user
+ id is associated with which application; different applications run under
+ different user IDs. Application signing ensures that one application cannot
+ access any other application except through well-defined IPC.</p>
+<p>When an application (APK file) is installed onto an Android device, the Package
+ Manager verifies that the APK has been properly signed with the certificate
+ included in that APK. If the certificate (or, more accurately, the public key
+ in the certificate) matches the key used to sign any other APK on the device,
+ the new APK has the option to specify in the manifest that it will share a UID
+ with the other similarly-signed APKs.</p>
+<p>Applications can be signed by a third-party (OEM, operator, alternative market)
+ or self-signed. Android provides code signing using self-signed certificates
+ that developers can generate without external assistance or permission.
+ Applications do not have to be signed by a central authority. Android currently
+ does not perform CA verification for application certificates.</p>
+<p>Applications are also able to declare security permissions at the Signature
+ protection level, restricting access only to applications signed with the same
+ key while maintaining distinct UIDs and Application Sandboxes. A closer
+ relationship with a shared Application Sandbox is allowed via the <a href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">shared UID
+ feature</a> where two or more applications signed with same developer key can
+ declare a shared UID in their manifest.</p>
+<h2 id="app-verification">Application Verification</h2>
+<p> Android 4.2 and later support application verification. Users can choose to
+ enable “Verify Apps" and have applications evaluated by an application verifier
+ prior to installation. App verification can alert the user if they try to
+ install an app that might be harmful; if an application is especially bad, it
+ can block installation. </p>
+<h2 id="digital-rights-management">Digital Rights Management</h2>
+<p>The Android platform provides an extensible DRM framework that lets
+ applications manage rights-protected content according to the license
+ constraints that are associated with the content. The DRM framework supports
+ many DRM schemes; which DRM schemes a device supports is left to the device
+ manufacturer.</p>
+<p>The <a href="https://developer.android.com/reference/android/drm/package-summary.html">Android DRM
+ framework</a> is implemented in two architectural layers (see figure below):</p>
+<ul>
+ <li>
+ <p>A DRM framework API, which is exposed to applications through the Android
+ application framework and runs through the Dalvik VM for standard applications.</p>
+ </li>
+ <li>
+ <p>A native code DRM manager, which implements the DRM framework and exposes an
+ interface for DRM plug-ins (agents) to handle rights management and decryption
+ for various DRM schemes</p>
+ </li>
+</ul>
+<p><img alt="Figure 4: Architecture of Digital Rights Management on Android
+platform" src="../images/image02.png" /></p>
+<p><em>Figure 4: Architecture of Digital Rights Management on Android platform</em></p>
diff --git a/src/devices/tech/security/overview/index.jd b/src/devices/tech/security/overview/index.jd
new file mode 100644
index 0000000..e23d734
--- /dev/null
+++ b/src/devices/tech/security/overview/index.jd
@@ -0,0 +1,80 @@
+page.title=Security overview
+@jd:body
+<!--
+ Copyright 2014 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<h2 id="android-security-program-overview">Security Program Overview</h2>
+<p>Early on in development, the core Android development team recognized that a
+ robust security model was required to enable a vigorous ecosystem of
+ applications and devices built on and around the Android platform and supported
+ by cloud services. As a result, through its entire development lifecycle,
+ Android has been subjected to a professional security program. The Android team
+ has had the opportunity to observe how other mobile, desktop, and server platforms
+ prevented and reacted to security issues and built a security
+ program to address weak points observed in other offerings.</p>
+<p>The key components of the Android Security Program include:</p>
+<ul>
+ <li><strong>Design Review</strong>: The Android security process begins early in the
+ development lifecycle with the creation of a rich and configurable security
+ model and design. Each major feature of the platform is reviewed by engineering
+ and security resources, with appropriate security controls integrated into the
+ architecture of the system.</li>
+ <li><strong>Penetration Testing and Code Review</strong>: During the development of the
+ platform, Android-created and open-source components are subject to vigorous
+ security reviews. These reviews are performed by the Android Security Team,
+ Google’s Information Security Engineering team, and independent security
+ consultants. The goal of these reviews is to identify weaknesses and possible
+ vulnerabilities well before the platform is open-sourced, and to simulate the
+ types of analysis that will be performed by external security experts upon
+ release.</li>
+ <li><strong>Open Source and Community Review</strong>: The Android Open Source Project enables
+ broad security review by any interested party. Android also uses open source
+ technologies that have undergone significant external security review,
+ such as the Linux kernel. Google Play provides a forum for users and companies
+ to provide information about specific applications directly to users.</li>
+ <li><strong>Incident Response</strong>: Even with all of these precautions, security issues
+ may occur after shipping, which is why the Android project has created a
+ comprehensive security response process. A full-time Android security team
+ constantly monitors Android-specific and the general security community for
+ discussion of potential vulnerabilities. Upon the discovery of legitimate
+ issues, the Android team has a response process that enables the rapid
+ mitigation of vulnerabilities to ensure that potential risk to all Android
+ users is minimized. These cloud-supported responses can include updating the
+ Android platform (over-the-air updates), removing applications from Google
+ Play, and removing applications from devices in the field.</li>
+</ul>
+<h2 id="android-platform-security-architecture">Platform Security Architecture</h2>
+<p>Android seeks to be the most secure and usable operating system for mobile
+ platforms by re-purposing traditional operating system security controls to:</p>
+<ul>
+ <li>Protect user data</li>
+ <li>Protect system resources (including the network)</li>
+ <li>Provide application isolation</li>
+</ul>
+<p>To achieve these objectives, Android provides these key security features:</p>
+<ul>
+ <li>Robust security at the OS level through the Linux kernel</li>
+ <li>Mandatory application sandbox for all applications</li>
+ <li>Secure interprocess communication</li>
+ <li>Application signing</li>
+ <li>Application-defined and user-granted permissions</li>
+</ul>
diff --git a/src/devices/tech/security/overview/kernel-security.jd b/src/devices/tech/security/overview/kernel-security.jd
new file mode 100644
index 0000000..12ae1bb
--- /dev/null
+++ b/src/devices/tech/security/overview/kernel-security.jd
@@ -0,0 +1,188 @@
+page.title=System and kernel security
+@jd:body
+
+<!--
+ Copyright 2014 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<p>At the operating system level, the Android platform provides the security of
+ the Linux kernel, as well as a secure inter-process communication (IPC)
+ facility to enable secure communication between applications running in
+ different processes. These security features at the OS level ensure that even
+ native code is constrained by the Application Sandbox. Whether that code is
+ the result of included application behavior or a exploitation of an application
+ vulnerability, the system would prevent the rogue application from harming
+ other applications, the Android system, or the device itself.</p>
+<h3 id="linux-security">Linux Security</h3>
+<p>The foundation of the Android platform is the Linux kernel. The Linux kernel
+ itself has been in widespread use for years, and is used in millions of
+ security-sensitive environments. Through its history of constantly being
+ researched, attacked, and fixed by thousands of developers, Linux has become a
+ stable and secure kernel trusted by many corporations and security
+ professionals.</p>
+<p>As the base for a mobile computing environment, the Linux kernel provides
+ Android with several key security features, including:</p>
+<ul>
+ <li>A user-based permissions model</li>
+ <li>Process isolation</li>
+ <li>Extensible mechanism for secure IPC</li>
+ <li>The ability to remove unnecessary and potentially insecure parts of the kernel</li>
+</ul>
+<p>As a multiuser operating system, a fundamental security objective of the Linux
+ kernel is to isolate user resources from one another. The Linux security
+ philosophy is to protect user resources from one another. Thus, Linux:</p>
+<ul>
+ <li>Prevents user A from reading user B's files</li>
+ <li>Ensures that user A does not exhaust user B's memory</li>
+ <li>Ensures that user A does not exhaust user B's CPU resources</li>
+ <li>Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS,
+ bluetooth)</li>
+</ul>
+<h3 id="the-application-sandbox">The Application Sandbox</h3>
+<p>The Android platform takes advantage of the Linux user-based protection as a
+ means of identifying and isolating application resources. The Android system
+ assigns a unique user ID (UID) to each Android application and runs it as that user
+ in a separate process. This approach is different from other operating systems
+ (including the traditional Linux configuration), where multiple applications
+ run with the same user permissions.</p>
+<p>This sets up a kernel-level Application Sandbox. The kernel enforces security
+ between applications and the system at the process level through standard Linux
+ facilities, such as user and group IDs that are assigned to applications. By
+ default, applications cannot interact with each other and applications have
+ limited access to the operating system. If application A tries to do something
+ malicious like read application B's data or dial the phone without permission
+ (which is a separate application), then the operating system protects against
+ this because application A does not have the appropriate user privileges. The
+ sandbox is simple, auditable, and based on decades-old UNIX-style user
+ separation of processes and file permissions.</p>
+<p>Since the Application Sandbox is in the kernel, this security model extends to
+ native code and to operating system applications. All of the software above the
+ kernel in <em>Figure 1</em>, including operating system libraries, application
+ framework, application runtime, and all applications run within the Application
+ Sandbox. On some platforms, developers are constrained to a specific
+ development framework, set of APIs, or language in order to enforce security.
+ On Android, there are no restrictions on how an application can be written that
+ are required to enforce security; in this respect, native code is just as
+ secure as interpreted code.</p>
+<p>In some operating systems, memory corruption errors generally lead to
+ completely compromising the security of the device. This is not the case in
+ Android due to all applications and their resources being sandboxed at the OS
+ level. A memory corruption error will only allow arbitrary code execution in
+ the context of that particular application, with the permissions established by
+ the operating system.</p>
+<p>Like all security features, the Application Sandbox is not unbreakable.
+ However, to break out of the Application Sandbox in a properly configured
+ device, one must compromise the security of the the Linux kernel.</p>
+<h3 id="system-partition-and-safe-mode">System Partition and Safe Mode</h3>
+<p>The system partition contains Android's kernel as well as the operating system
+ libraries, application runtime, application framework, and applications. This
+ partition is set to read-only. When a user boots the device into Safe Mode,
+ only core Android applications are available. This ensures that the user can
+ boot their phone into an environment that is free of third-party software.</p>
+<h3 id="filesystem-permissions">Filesystem Permissions</h3>
+<p>In a UNIX-style environment, filesystem permissions ensure that one user cannot
+ alter or read another user's files. In the case of Android, each application
+ runs as its own user. Unless the developer explicitly exposes files to other
+ applications, files created by one application cannot be read or altered by
+ another application.</p>
+<h3 id="se-linux">Security-Enhanced Linux</h3>
+<p>Android uses Security-Enhanced
+ Linux (SELinux) to apply access control policies and establish an environment of
+ mandatory access control (mac). See <a
+href="{@docRoot}devices/tech/security/selinux/index.html">Validating
+ Security-Enhanced Linux in
+ Android</a> for details.</p>
+<h3 id="crypto">Cryptography</h3>
+<p> Android provides a set of cryptographic APIs for use by applications. These
+ include implementations of standard and commonly used cryptographic primitives
+ such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level
+ protocols such as SSL and HTTPS. </p>
+<p> Android 4.0 introduced the <a href="http://developer.android.com/reference/android/security/KeyChain.html">KeyChain</a> class to allow applications to use the system credential storage for private
+ keys and certificate chains. </p>
+<h3>Rooting of Devices</h3>
+<p> By default, on Android only the kernel and a small subset of the core
+ applications run with root permissions. Android does not prevent a user or
+ application with root permissions from modifying the operating system, kernel,
+ and any other application. In general, root has full access to all
+ applications and all application data. Users that change the permissions on an
+ Android device to grant root access to applications increase the security
+ exposure to malicious applications and potential application flaws. </p>
+<p> The ability to modify an Android device they own is important to developers
+ working with the Android platform. On many Android devices users have the
+ ability to unlock the bootloader in order to allow installation of an alternate
+ operating system. These alternate operating systems may allow an owner to gain
+ root access for purposes of debugging applications and system components or to
+ access features not presented to applications by Android APIs. </p>
+<p> On some devices, a person with physical control of a device and a USB cable is
+ able to install a new operating system that provides root privileges to the
+ user. To protect any existing user data from compromise the bootloader unlock
+ mechanism requires that the bootloader erase any existing user data as part of
+ the unlock step. Root access gained via exploiting a kernel bug or security
+ hole can bypass this protection. </p>
+<p> Encrypting data with a key stored on-device does not protect the application
+ data from root users. Applications can add a layer of data protection using
+ encryption with a key stored off-device, such as on a server or a user
+ password. This approach can provide temporary protection while the key is not
+ present, but at some point the key must be provided to the application and it
+ then becomes accessible to root users. </p>
+<p> A more robust approach to protecting data from root users is through the use of
+ hardware solutions. OEMs may choose to implement hardware solutions that limit
+ access to specific types of content such as DRM for video playback, or the
+ NFC-related trusted storage for Google wallet. </p>
+<p> In the case of a lost or stolen device, full filesystem encryption on Android
+ devices uses the device password to protect the encryption key, so modifying
+ the bootloader or operating system is not sufficient to access user data
+ without the user’s device password. </p>
+<h3>User Security Features</h3>
+<h4 id="filesystem-encryption">Filesystem Encryption</h4>
+<p>Android 3.0 and later provides full filesystem encryption, so all user data can
+ be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC
+ and ESSIV:SHA256. The encryption key is protected by AES128 using a key
+ derived from the user password, preventing unauthorized access to stored data
+ without the user device password. To provide resistance against systematic
+ password guessing attacks (e.g. “rainbow tables” or brute force), the
+ password is combined with a random salt and hashed repeatedly with SHA1 using
+ the standard PBKDF2 algorithm prior to being used to decrypt the filesystem
+ key. To provide resistance against dictionary password guessing attacks,
+ Android provides password complexity rules that can be set by the device
+ administrator and enforced by the operating system. Filesystem encryption
+ requires the use of a user password, pattern-based screen lock is not supported.</p>
+<p>More details on implementation of filesystem encryption are available at <a
+href="/devices/tech/security/encryption/index.html">Encryption</a>.</p>
+<h3 id="password-protection">Password Protection</h3>
+<p>Android can be configured to verify a user-supplied password prior to providing
+ access to a device. In addition to preventing unauthorized use of the device,
+ this password protects the cryptographic key for full filesystem encryption.</p>
+<p>Use of a password and/or password complexity rules can be required by a device
+ administrator.</p>
+<h3 id="device-administration">Device Administration</h3>
+<p>Android 2.2 and later provide the Android Device Administration API, which
+ provides device administration features at the system level. For example, the
+ built-in Android Email application uses the APIs to improve Exchange support.
+ Through the Email application, Exchange administrators can enforce password
+ policies — including alphanumeric passwords or numeric PINs — across
+ devices. Administrators can also remotely wipe (that is, restore factory
+ defaults on) lost or stolen handsets.</p>
+<p>In addition to use in applications included with the Android system, these APIs
+ are available to third-party providers of Device Management solutions. Details
+ on the API are provided at <a
+href="https://developer.android.com/guide/topics/admin/device-admin.html">Device
+Administration</a>.</p>
diff --git a/src/devices/tech/security/overview/updates-resources.jd b/src/devices/tech/security/overview/updates-resources.jd
new file mode 100644
index 0000000..357aa0c
--- /dev/null
+++ b/src/devices/tech/security/overview/updates-resources.jd
@@ -0,0 +1,75 @@
+page.title= Security updates and resources
+@jd:body
+
+<!--
+ Copyright 2014 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc"></ol>
+ </div>
+</div>
+
+<h2 id="android-updates">Android Updates</h2>
+<p>Android provides system updates for both security and feature related purposes.</p>
+<p>There are two ways to update the code on most Android devices: over-the-air
+ (OTA updates) or side-loaded updates. OTA updates can be rolled out over a
+ defined time period or be pushed to all devices at once, depending on how the
+ OEM and/or carrier would like to push the updates. Side-loaded updates can be
+ provided from a central location for users to download as a zip file to their
+ local desktop machine or directly to their handset. Once the update is copied
+ or downloaded to the SD card on the device, Android will recognize the update,
+ verify its integrity and authenticity, and automatically update the device.</p>
+<p>If a dangerous vulnerability is discovered internally or responsibly reported
+ to Google or the Android Open Source Project, the Android security team will
+ start the following process.</p>
+<ol>
+ <li>The Android team will notify companies who have signed NDAs regarding the
+ problem and begin discussing the solution.</li>
+ <li>The owners of code will begin the fix.</li>
+ <li>The Android team will fix Android-related security issues.</li>
+ <li>When a patch is available, the fix is provided to the NDA companies.</li>
+ <li>The Android team will publish the patch in the Android Open Source Project</li>
+ <li>OEM/carrier will push an update to customers.</li>
+</ol>
+<p>The NDA is required to ensure that the security issue does not become public
+ prior to availabilty of a fix and put users at risk. Many OHA members run their
+ own code on Android devices such as the bootloader, wifi drivers, and the
+ radio. Once the Android Security team is notified of a security issue in this
+ partner code, they will consult with OHA partners to quickly find a fix for the
+ problem at hand and similar problems. However, the OHA member who wrote the
+ faulty code is ultimately responsible for fixing the problem.</p>
+<p>If a dangerous vulnerability is not responsibly disclosed (e.g., if it is
+ posted to a public forum without warning), then Google and/or the Android Open
+ Source Project will work as quickly as possible to create a patch. The patch
+ will released to the public (and any partners) when the patch is tested and
+ ready for use.</p>
+<p>At Google I/O 2011, many of the largest OHA partners committed to providing
+ updates to devices for 18 months after initial shipment. This will provide
+ users with access to the most recent Android features, as well as security
+ updates.</p>
+<p>Any developer, Android user, or security researcher can notify the Android
+ security team of potential security issues by sending email to
+ security@android.com. If desired, communication can be encrypted using the
+ Android security team PGP key available here: <a href="https://developer.android.com/security_at_android_dot_com.txt">https://developer.android.com/security_at_android_dot_com.txt</a>.</p>
+<h2 id="other-resources">Other Resources</h2>
+<p>Information for Android application developers is here: <a href="https://developer.android.com">https://developer.android.com</a>.</p>
+<p>The Android Security team can be reached at <a href="mailto:security@android.com">security@android.com</a>.</p>
+<p>Security information exists throughout the Android Open Source and Developer
+ Sites. A good place to start is here: <a href="https://developer.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
+<p>A Security FAQ for developers is located here: <a href="https://developer.android.com/resources/faq/security.html">https://developer.android.com/resources/faq/security.html</a>.</p>
+<p>Security Best Practices for developers is located here: <a href="https://developer.android.com/guide/practices/security.html">https://developer.android.com/guide/practices/security.html</a>.</p>
+<p>A community resource for discussion about Android security exists here: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a>.</p>
diff --git a/src/devices/tech/security/secureboot/block-ota.jd b/src/devices/tech/security/secureboot/block-ota.jd
new file mode 100755
index 0000000..5f93608
--- /dev/null
+++ b/src/devices/tech/security/secureboot/block-ota.jd
@@ -0,0 +1,77 @@
+page.title=Block-Based OTAs
+@jd:body
+
+<!--
+ Copyright 2014 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+
+<h2 id="introduction">Introduction</h2>
+
+<p>You can enable block-based over-the-air (OTA) updates for new devices running Android 5.0. OTA is the mechanism by which OEMs remotely update the system partition of a device:</p>
+<ul>
+<li><b>Android 4.4</b> and earlier versions used file OTA updates, which ensured that devices contained similar file contents, permissions, and modes, but allowed metadata such as timestamps and the layout of the underlying storage to vary between devices based on the update method.</li>
+<li><b>Android 5.0</b> and later versions use block OTA updates to ensure that each device uses the exact same partition. Instead of comparing individual files and computing binary patches, block OTA handles the entire partition as one file and computes a single binary patch, ensuring the resultant partition contains exactly the intended bits. This allows the device system image to achieve the same state via fastboot or OTA.</li>
+</ul>
+<p>Because block OTA ensures that each device uses the same partition, it enables the use of dm-verity to cryptographically sign the system partition. For details on dm-verity, see <a
+href="{@docRoot}devices/tech/security/dm-verity.html">Using dm-verity</a>.</p>
+
+<p class="note"><strong>Note:</strong> You must have a working block OTA system before using dm-verity.</p>
+
+<h2 id="Recommendations">Recommendations</h2>
+
+<p>For devices that launched with Android 4.4 or earlier, use file OTA updates. While is it possible to transition devices by sending a full block OTA of Android 5.0 or later, it requires extensive modifications to the bootloader and the update size is large (block OTA downloads are approximately 20% larger than file OTA downloads).</p>
+<p>For devices launching with Android 5.0 or later, use block OTA updates. New devices shipping with Android 5.0 or later include support for block OTA updates. To generate a block-based OTA, pass the "--block" option to ota_from_target_files.</p>
+<p>Because dm-verity requires bootloader support found only in new devices shipping with Android 5.0 or later, you <i>cannot</i> enable dm-verity for existing devices.</p>
+
+<h2 id="File vs. Block OTAs">File vs. Block OTAs</h2>
+
+<p>During a file-based OTA, Android attempts to change the contents of the system partition at the filesystem layer (on a file-by-file basis). The update is not guaranteed to write files in a consistent order, have a consistent last modified time or superblock, or even place the blocks in the same location on the block device. For this reason, file-based OTAs fail on a dm-verity-enabled device; after the OTA attempt, the device does not boot.</p>
+<p>During a block-based OTA, Android serves the device the difference between the two block images (rather than two sets of files). The update checks a device build against the corresponding build server at the block level (below the filesystem) using one of the following methods:</p>
+<ul>
+<li><b>Full update</b>. Copying the full system image is simple and makes patch generation easy, but also generates large images that can make applying patches expensive.</li>
+<li><b>Incremental update</b>. Using a binary differ tool generates smaller images and makes patch application easy, but is memory-intensive when generating the patch itself.</li>
+</ul>
+
+<p class="note"><strong>Note:</strong> adb fastboot places the exact same bits on the device as a full OTA, so flashing is compatible with block OTA.</p>
+
+<h3 id="Unmodified Systems">Updating Unmodified Systems</h3>
+
+<p>For devices with <i>unmodified</i> system partitions running Android 5.0, the download and install process for a block OTA remains the same as for a file OTA. However, the OTA update itself might include one or more of the following differences:</p>
+<ul>
+<li><b>Increased download size</b>. Full block OTA updates are approximately the same size as full file OTA updates. However, big incremental updates can be 10-20% larger while small incremental updates (i.e. many DM verity checksum changes but few file changes) can be just a few megabytes larger. In general, incremental block OTA updates are larger than incremental file OTA updates due to:
+<ul>
+<li><i>Data preservation</i>. Block-based OTAs preserve more data (file metadata, dm-verity data, ext4 layout, etc.) than file-based OTA.</li>
+<li><i>Binary patch tool differences</i>. File-based OTAs use bsdiff, which is not feasible to run on large files (such as an entire system image). Instead, block-based OTAs use xdelta3, which is faster and requires less memory to process large files, but creates larger patches than bsdiff.</li>
+<li><i>Compression capabilities</i>. When patching some file types (.zip, .apk, .jar, .gz), a file OTA update decompresses the file and computes a patch for the uncompressed data, recompressing it after patching. This can produce substantially smaller patches than a binary patch on compressed data. Block OTA updates do not support file decompression and recompression.</li>
+<li><i>Computation algorithm differences</i>. In a file OTA update, if a file path is identical in both builds, the OTA package contains no data for that file. In a block OTA update, determining little or no change in a file depends on the quality of the patch computation algorithm and layout of file data in both source and target system. For example, images.xdelta3 can locate data similarities only between nearby locations; varying the nearby parameter affects the memory and time required to compute and apply the patch.</li>
+</ul>
+</li>
+<li><b>Sensitivity to faulty flash and RAM</b>. If a file is corrupted, a file OTA succeeds as long as it doesn't touch the corrupted file, but a block OTA fails if it detects any corruption on the system partition.</li>
+</ul>
+
+<h3 id="Modified Systems">Updating Modified Systems</h3>
+<p>For devices with <i>modified</i> system partitions running Android 5.0:</p>
+<ul>
+<li><b>Incremental block OTA updates fail</b>. A system partition might be modified during an adb remount or as a result of malware. File OTA tolerates some changes to the partition, such the addition of files that are not part of the source or target build. However, block OTA does not tolerate additions to the partition, so users will need to install a full OTA (overwriting any system partition modifications) or flash a new system image to enable future OTAs.</li>
+<li><b>Attempts to change modified files cause update failure</b>. For both file and block OTA updates, if the OTA attempts to change a file that has been modified, the OTA update fails.</li>
+<li><b>Attempts to access modified files generate errors </b><i>(dm-verity only)</i>. For both file and block OTA updates, if dm-verity is enabled and the OTA attempts to access modified parts of the system filesystem, the OTA generates an error.</li>
+</ul>
\ No newline at end of file
diff --git a/src/devices/tech/security/dm-verity.jd b/src/devices/tech/security/secureboot/index.jd
similarity index 79%
rename from src/devices/tech/security/dm-verity.jd
rename to src/devices/tech/security/secureboot/index.jd
index e017299..aca3408 100644
--- a/src/devices/tech/security/dm-verity.jd
+++ b/src/devices/tech/security/secureboot/index.jd
@@ -1,8 +1,8 @@
-page.title=dm-verity on boot
+page.title=Secure Boot
@jd:body
<!--
- Copyright 2013 The Android Open Source Project
+ Copyright 2014 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.
@@ -26,7 +26,7 @@
<h2 id="introduction">Introduction</h2>
-<p>Android 4.4 supports verified boot through the optional device-mapper-verity
+<p>Android 4.4 and later supports verified boot through the optional device-mapper-verity
(dm-verity) kernel feature, which provides transparent integrity checking of
block devices. dm-verity helps prevent persistent rootkits that can hold onto
root privileges and compromise devices. This experimental feature helps Android
@@ -48,7 +48,7 @@
modify any of the blocks would be equivalent to breaking the cryptographic hash.
See the following diagram for a depiction of this structure.</p>
-<p><img src="images/dm-verity-hash-table.png" alt="dm-verity-hash-table"/><br/>
+<p><img src="../images/dm-verity-hash-table.png" alt="dm-verity-hash-table"/><br/>
A public key is included on the boot partition, which must be verified
externally by the OEM. That key is used to verify the signature for that hash
and confirm the device's system partition is protected and unchanged.</p>
@@ -63,9 +63,9 @@
<p>Manufacturers use that key to verify the signature on the first-level
bootloader, which in turn verifies the signature on subsequent levels, the
application bootloader and eventually the kernel. Each manufacturer wishing to
-take advantage of verified boot should have a method for verifying the integrity
-of the kernel. Assuming the kernel has been verified, the kernel can look at a
-block device and verify it as it is mounted.</p>
+take advantage of <a href="verified-boot.html">verified boot</a> should have a
+method for verifying the integrity of the kernel. Assuming the kernel has been
+verified, the kernel can look at a block device and verify it as it is mounted.</p>
<p>One way of verifying a block device is to directly hash its contents and compare
them to a stored value. However, attempting to verify an entire block device can
@@ -88,35 +88,14 @@
<h2 id="prerequisites">Prerequisites</h2>
+<h3 id="verified-boot">Establishing a verified boot flow</h3>
+<p>To greatly reduce the risk of compromise, verify the kernel using a key
+burned into the device. For details, see <a href="verified-boot.html">Verified boot</a>.</p>
+
<h3 id="block-otas">Switching to block-oriented OTAs</h3>
-
-<p>To enable dm-verity on your devices, you <strong>must</strong> move from file-based "over the
-air" (OTA) updates to block-oriented OTAs. This is needed because during OTA,
-Android attempts to change the contents of the system partition at the
-filesystem layer.<br/>
-And since OTA works on a file-by-file basis, it is not guaranteed to write files
-in a consistent order, have a consistent last modified time or superblock, or
-even place the blocks in the same location on the block device. For this reason,
-<em>file-based OTAs will fail on a dm-verity-enabled device.</em><strong>The device will
-not boot after OTA.</strong></p>
-
-<p>So you must use block-oriented OTAs. With block-oriented OTAs, you serve the
-device the difference between the two block images rather than the two sets of
-files. Many manufacturers have already moved to block-oriented OTAs to make them
-more reproducible and predictable.</p>
-
-<p>A block-oriented OTA checks a device build against the corresponding build
-server at the block device level, below the filesystem. This can be done in a
-couple of different ways, each with their own benefits and drawbacks:</p>
-
-<ul>
-<li><em>Copy the full system image to the device</em> - This is simple and makes patch
-generation easy. But it also makes the application of those patches quite
-expensive as the resulting images are large.</li>
-<li><em>Employ a binary differ</em> - These tools, such as <code>bsdiff</code>, simplify patch
-application as images are much smaller. But these tools tend to be memory
-intensive and therefore expensive in generating the patches themselves.</li>
-</ul>
+<p>To enable dm-verity for a device, you must use block-based over-the-air
+(OTA) updates to ensure all devices use the same system partition. For details,
+see <a href="block-ota.html">Block-Based OTAs</a>.</p>
<h3 id="config-dm-verity">Configuring dm-verity</h3>
@@ -133,11 +112,11 @@
<ol>
<li>Generate an ext4 system image.</li>
-<li><a href="#heading=h.wiiuowe37q8h">Generate a hash tree</a> for that image.</li>
-<li><a href="#heading=h.cw7mesnrerea">Build a dm-verity table</a> for that hash tree.</li>
-<li><a href="#heading=h.maq6jfk4vx92">Sign that dm-verity table</a> to produce a table
+<li><a href="#hash-tree">Generate a hash tree</a> for that image.</li>
+<li><a href="#mapping-table">Build a dm-verity table</a> for that hash tree.</li>
+<li><a href="#signing">Sign that dm-verity table</a> to produce a table
signature.</li>
-<li><a href="#heading=h.tkceh5wnx7z2">Bundle the table signature</a> and dm-verity table
+<li><a href="#metadata">Bundle the table signature</a> and dm-verity table
into verity metadata.</li>
<li>Concatenate the system image, the verity metadata, and the hash tree.</li>
</ol>
@@ -148,7 +127,7 @@
<h3 id="hash-tree">Generating the hash tree</h3>
-<p>As described in the <a href="#heading=h.q4z3ftrhbehy">Introduction</a>, the hash tree is
+<p>As described in the <a href="#introduction">Introduction</a>, the hash tree is
integral to dm-verity. The
<a href="https://code.google.com/p/cryptsetup/wiki/DMVerity">cryptsetup</a> tool will
generate a hash tree for you. Alternatively, a compatible one is defined here:</p>
@@ -308,7 +287,9 @@
<h2 id="supporting-docs">Supporting documentation</h2>
-<p><a href="https://code.google.com/p/cryptsetup/wiki/DMVerity">cryptsetup - dm-verity: device-mapper block integrity checking
+<p><a href="verified-boot.html">Verified boot</a><br/>
+<a href="block-ota.html">Block-based OTAs</a><br/>
+<a href="https://code.google.com/p/cryptsetup/wiki/DMVerity">cryptsetup - dm-verity: device-mapper block integrity checking
target</a><br/>
<a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot">The Chromium Projects - Verified
Boot</a><br/>
diff --git a/src/devices/tech/security/secureboot/verified-boot.jd b/src/devices/tech/security/secureboot/verified-boot.jd
new file mode 100644
index 0000000..3873009
--- /dev/null
+++ b/src/devices/tech/security/secureboot/verified-boot.jd
@@ -0,0 +1,435 @@
+page.title=Verified boot
+@jd:body
+
+<!--
+ Copyright 2014 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.
+-->
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+ </div>
+</div>
+<h2 id=introduction>Introduction</h2>
+
+<p>This document introduces and describes the process of establishing a
+verified boot flow, which is integral to security measures such as <a
+href="index.html">Secure Boot</a>.</p>
+
+<h2 id=terms>Terms</h2>
+
+<p>Become familiar with the following terms to carry out the implementation
+described later.</p>
+
+<p><strong>Keystore</strong></p>
+
+<p>A keystore is a signed collection of public keys.</p>
+
+<p><strong>OEM key</strong></p>
+
+<p>The OEM key is a fixed key available to the bootloader that must be used to
+verify the keystore.</p>
+
+<p><strong>OEM keystore</strong></p>
+
+<p>The OEM keystore is a fixed keystore available to the bootloader that must
+be used to verify the boot image when a user keystore is not present.</p>
+
+<p><strong>User keystore</strong></p>
+
+<p>The user keystore is a keystore flashed to the device via <code>fastboot
+flash keystore <path></code>. Note this keystore must also support being
+signed with the OEM key for verification purposes.</p>
+
+<p><strong>Hardware-backed keystore</strong></p>
+
+<p>A keystore that employs cryptographic-enabled hardware to decouple Android
+from the actual device security hardware.</p>
+
+<p><strong>Boot state</strong></p>
+
+<p>The boot state of the device describes the level of protection provided to
+the end user if the device boots. Boot states are GREEN, YELLOW, ORANGE, and
+RED.</p>
+
+<p><strong>Device state</strong></p>
+
+<p>The device state indicates whether a device is locked, unlocked, or
+verified.</p>
+
+<h2 id=boot_sequence>Boot sequence</h2>
+
+<h3 id=logical_overview>Logical overview</h3>
+
+<p>A verified device will ultimately boot into one of four states during each
+boot attempt:</p>
+
+<ul>
+ <li>GREEN, indicating a full chain of trust extending from the bootloader
+to the system partition, including the bootloader, keystore, boot partition,
+and system partition.
+ <li>YELLOW, indicating a chain of trust from starting
+at a user-provided keystore and extending up. To enable users to acquire trust
+in their keystore, bootloaders are required to display a partial hash of the
+verifying keystore during boot and prompt the user for confirmation. Rejecting
+this hash leads to the RED state and a reboot into recovery.
+ <li>ORANGE, indicating that a device may be freely modified. Device integrity is left to
+the user to verify out-of-band, and the user can acknowledge this
+before booting. A timer will allow 30 seconds for the user to respond; If the user
+does not respond, the device will continue booting. If the user explicitly
+stops the booting sequence, the device goes into the RED state and reboots into
+recovery.
+ <li>RED, indicating the device has failed
+verification. This must display an error to the user and reboot into recovery.
+If recovery cannot be verified, the device must display an error and fail to
+boot.
+</ul>
+
+<p>The recovery partition must also be verified, and should be verified in the
+exact same way.</p>
+
+<img src="../images/verified_boot.png" alt="Verified boot flow">
+<p class="img-caption"><strong>Figure 1.</strong> Verified boot flow</p>
+
+<h3 id=selecting_a_keystore>Selecting a keystore</h3>
+
+<p>If a user-provided keystore is present, it must be selected for later. If no
+user-provided keystore is present, then the original factory keystore must be
+selected instead. Selection of a keystore is independent of validation of that
+keystore.</p>
+
+<h3 id=booting_into_recovery>Booting into recovery</h3>
+
+<p>The recovery image should be verified in exactly the same manner as the boot
+image prior to booting recovery. If the recovery image does not validate, the
+device must not boot.</p>
+
+<h2 id=device_state>Device state</h2>
+
+<p>The device is required to be in one of three states at all times:</p>
+
+<ul>
+ <li>LOCKED, indicating the device cannot currently be flashed. In
+the image above, a LOCKED device must boot into the GREEN state, YELLOW state,
+or RED state during any attempted boot. It must not be possible to alter the
+OEM key, OEM keystore, or user keystore in the LOCKED state.
+ <li>VERIFIED, indicating someone in physical control of the device may perform limited
+actions intended to change the state of the device but may not break its
+current chain of trust. In Figure 1 above, a VERIFIED device must boot into
+the GREEN state, YELLOW state, or RED state during each attempted boot. It must
+not be possible to alter the OEM key, OEM keystore, or user keystore in the
+VERIFIED state.<br/>
+It must be possible to:
+ <ol>
+ <li>Flash the following partitions:
+ <ul>
+ <li>bootloader
+ <li>boot
+ <li>system
+ <li>vendor
+ <li>recovery
+ </ul>
+ <li>Erase the following partitions:
+ <ul>
+ <li>userdata
+ <li> cache
+ </ul>
+ <li>Flash freely a device in an UNLOCKED state as it is not intended to be verified.
+ </ol>
+</ul>
+
+<p>See an illustration of the transitions between these states in the next
+section.</p>
+
+<h3 id=changing_device_state>Changing device state</h3>
+
+<p>Device state (LOCKED, UNLOCKED, VERIFIED) and boot state (GREEN, YELLOW,
+ORANGE, RED) can usually change independently of one another (with the exception
+being UNLOCKED -> LOCKED | VERIFIED). This section describes how those
+transitions occur. See the diagram below for a depiction of these changes.</p>
+
+<p><strong>Important</strong>: Note <strong>all</strong> state transitions
+require a data wipe.</p>
+
+<img src="../images/device_states.png" alt="Changing device states">
+<p class="img-caption"><strong>Figure 2.</strong> Changing device states</p>
+
+<ul>
+ <li>The UNLOCKED to LOCKED transition requires a data wipe and is done
+via: <code>fastboot oem lock</code> This is anticipated when a user buys a used
+development device. As a result of locking the device, the user should have
+confidence that it is in a state produced by the OEM.
+ <li>The LOCKED to UNLOCKED transition requires a data wipe and is done via: <code>fastboot oem
+unlock</code> This is expected in the case where a developer wishes to disable
+verification on the device.
+ <li>The LOCKED to VERIFIED transition requires a
+data wipe and is done via: <code>fastboot oem verified</code> This is expected
+in the case where a developer wishes to conduct development on the device and
+doesn’t want to wipe data frequently in the process.
+ <li>The VERIFIED to LOCKED transition requires a data wipe and is done via:
+<code>fastboot oem lock</code> This operation is idempotent with the above.
+ <li>The UNLOCKED to VERIFIED transition requires a data wipe and is done via: <code>fastboot oem
+verified</code> This is anticipated when a user wishes to put a development
+device in a more secure state but may not want to prevent themselves from
+flashing new system images.
+ <li>The VERIFIED to UNLOCKED transition requires a data wipe and is done via:
+<code>fastboot oem unlock</code> This operation is idempotent with the above.
+</ul>
+
+<h3 id=changing_boot_state>Changing boot state</h3>
+
+<p>The chart below provides the typical flow for transitioning from each boot
+state in the left column to the boot state in the first row.</p>
+
+<table>
+ <tr>
+ <td></td>
+ <td><p><strong>GREEN</strong></p></td>
+ <td><p><strong>YELLOW</strong></p></td>
+ <td><p><strong>RED</strong></p></td>
+ </tr>
+ <tr>
+ <td><p><strong>GREEN</strong></p></td>
+ <td><p>No change.</p></td>
+ <td><pre>fastboot oem <verified|locked></pre>
+ <pre>fastboot flash keystore <file></pre></td>
+ <td><p>Modify keystore or boot image without unlocking or the corresponding
+change.</p></td>
+ </tr>
+ <tr>
+ <td><p><strong>YELLOW</strong></p></td>
+ <td><pre>fastboot erase keystore</pre>
+ <pre>fastboot oem lock</pre></td>
+ <td><p>No change.</p></td>
+ <td><p>Modify keystore or boot image without unlocking or the corresponding
+change.</p></td>
+ </tr>
+ <tr>
+ <td><p><strong>RED</strong></p></td>
+ <td><pre>fastboot oem unlock</pre>
+ <p>If factory boot image:</p>
+ <pre> fastboot erase keystore</pre>
+ <p>To flash boot image:</p>
+ <pre> fastboot flash boot <file></pre></td>
+ <td><pre>fastboot oem unlock</pre>
+ <p>If custom boot image:</p>
+ <pre>fastboot flash keystore <file></pre>
+ <p>To flash boot image:</p>
+ <pre>fastboot flash boot <file></pre></td>
+ <td><p>No change.</p></td>
+ </tr>
+</table>
+
+<h2 id=oem_bootloader_requirements>OEM bootloader requirements</h2>
+
+<h3 id=verification>Verification</h3>
+
+<p>Each bootloader stage is required to validate the subsequent stages against
+a tamper-protected key.</p>
+
+<h3 id=fastboot>Fastboot</h3>
+
+<h4 id=fastboot_oem_lock>fastboot oem lock</h4>
+
+<p><code>oem lock</code> is required to:</p>
+
+<ul>
+ <li>Wipe data
+ <li>Clear a write-protected bit indicating the device is unlocked
+ <li> Clear a write-protected bit indicating the device is verified
+</ul>
+
+<h4 id=fastboot_oem_unlock>fastboot oem unlock</h4>
+
+<p><code>oem unlock</code> is required to:</p>
+
+<ul>
+ <li>Wipe data
+ <li>Set the bit cleared by <code>oem lock</code>
+ <li>Clear the bit set by <code>oem verified</code>
+</ul>
+
+<h4 id=fastboot_oem_verified>fastboot oem verified</h4>
+
+<p><code>oem verified</code> is required to:</p>
+
+<ul>
+ <li>Wipe data
+ <li>Clear a write-protected bit indicating the device is unlocked
+ <li>Set a write-protected bit indicating the device is verified
+</ul>
+
+<h4 id=fastboot_flash_keystore>fastboot flash keystore</h4>
+
+<p><code>flash keystore <filename></code> is required to:</p>
+
+<ul>
+ <li>Check the bit set by <code>oem unlock</code> and if not set, exit with an error
+ <li> Validate the given keystore against the format provided below
+ <li> Write the given keystore to the write-protected user keystore
+storage area (location to be determined by the OEM)
+</ul>
+
+<h4 id=fastboot_erase_keystore>fastboot erase keystore</h4>
+
+<p><code>erase keystore</code> is required to:</p>
+
+<ul>
+ <li>Check the bit set by <code>oem unlock</code> and if not set, exit with an error
+ <li>Erase the keystore stored in the write-protected user keystore storage area
+</ul>
+
+<p><code>erase keystore</code> must not erase the OEM keystore.</p>
+
+<h4 id=fastboot_flash_partition>fastboot flash <partition></h4>
+
+<p><code>flash <partition> </code> is required to:</p>
+
+<ul>
+ <li>Check the bit set by <code>oem unlock</code>
+ <ul>
+ <li>If this bit is not set, check the bit set by <code>oem verified</code>
+ <ul>
+ <li>If this bit is not set, exit with an error
+ <li>If this bit is set and <partition> is on the list provided
+above, flash the partition as normal
+ </ul>
+ <li>If this bit is set, flash the partition as normal
+ </ul>
+</ul>
+
+<h2 id=boot_state_user_experience>Boot state user experience</h2>
+
+<p>A user in the green state should see no additional user experience (UX)
+besides that required by their current verification state and normal device
+boot. Samples of UX for the other states follow:</p>
+
+<img src="../images/verified-boot-ui.png" alt="Interfaces of verified boot">
+<p class="img-caption"><strong>Figure 3.</strong> Interfaces of verified boot</p>
+
+<h2 id=implementation_details>Implementation details</h2>
+
+<h3 id=key_types_and_sizes>Key types and sizes</h3>
+
+<p>The OEM key is recommended to be an RSA key with a modulus of 2048 bits or
+higher and a public exponent of 65537 (F4). The OEM key is required to be of
+equivalent or greater strength than such a key.</p>
+
+<h3 id=image_format>Image format</h3>
+
+<p>The Android verifiable boot image format is very simple: given a boot image,
+0-pad it to the next page size boundary (if already aligned to a boundary, omit
+this step), generate a signature over the resulting image, and append that
+signature to the end of the image in the format specified below.</p>
+
+<h3 id=signature_format>Signature format</h3>
+
+<p>The signature on an Android-verifiable boot image is an ASN.1 DER-encoded
+message, which can be parsed with a decoder similar to the <a
+href="https://android.googlesource.com/platform/bootable/recovery/+/f4a6ab27b335b69fbc419a9c1ef263004b561265/asn1_decoder.cpp">asn1_decoder.cpp</a>.
+The message format itself is as follows:</p>
+
+<pre>
+AndroidVerifiedBootSignature DEFINITIONS ::=
+ BEGIN
+ FormatVersion ::= INTEGER
+ certificate ::= Certificate OPTIONAL
+ AlgorithmIdentifier ::= SEQUENCE {
+ algorithm OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY algorithm OPTIONAL
+ }
+ AuthenticatedAttributes ::= SEQUENCE {
+ target CHARACTER STRING,
+ length INTEGER
+ }
+
+ Signature ::= OCTET STRING
+END
+</pre>
+
+<p>The certificate field is the full X.509 certificate containing the public
+key used for signing, as defined by <a
+href="http://tools.ietf.org/html/rfc5280#section-4.1.1.2">RFC5280</a> section
+4.1. The remaining structure is similar to that defined by <a
+href="http://tools.ietf.org/html/rfc5280#section-4.1.1.2">RFC5280</a> sections
+4.1.1.2 and 4.1.1.3 with the exception of the <code>AuthenticatedAttributes</code> field.</p>
+
+<p>This field contains the length of the image to be verified as an integer and
+the partition (ie, boot, recovery, etc.) on which the image should be found.</p>
+
+<h3 id=signing_and_verifying_an_image>Signing and verifying an image</h3>
+
+<p>To produce a signed image:</p>
+
+<ol>
+ <li>Generate the unsigned image.
+ <li>0-pad the image to the next page size boundary. (Omit this step if already aligned.)
+ <li>Populate the fields of the <code>AuthenticatedAttributes</code> section
+above based on the padded image and desired target partition.
+ <li>Append the <code>AuthenticatedAttributes</code> structure above to the image.
+ <li>Sign the image.
+</ol>
+
+<p>To verify the image:</p>
+
+<ol>
+ <li>Determine the size of the image to be loaded including padding (eg, by
+reading a header).
+ <li>Read the signature located at the offset above.
+ <li>Validate the contents of the <code>AuthenticatedAttributes</code> field. If
+these values do not validate, treat the issue as a signature validation error.
+ <li>Verify the image and <code>AuthenticatedAttributes</code> sections.
+</ol>
+
+<h3 id=keystore_format>Keystore format</h3>
+
+<p>The Android verified boot keystore format is an ASN.1 DER-encoded document.
+Its specification follows:</p>
+
+<pre>
+AndroidVerifiedBootKeystore DEFINITIONS ::=
+ BEGIN
+ FormatVersion ::= INTEGER
+ KeyBag ::= SEQUENCE {
+ Key ::= SEQUENCE {
+ AlgorithmIdentifier ::= SEQUENCE {
+ algorithm OBJECT IDENTIFIER,
+ parameters ANY DEFINED BY algorithm OPTIONAL
+ }
+ KeyMaterial ::= RSAPublicKey
+ }
+ }
+ Signature ::= AndroidVerifiedBootSignature
+ END
+</pre>
+
+<p>Where RSAPublicKey, AlgorithmIdentifier, and parameters are as specified in
+<a href="http://tools.ietf.org/html/rfc3279#section-2.3.1">RFC3279</a>. Other
+key types specified in RFC3279 section 2.3 may optionally be supported. In
+this case the appropriate type for Key must be used.</p>
+
+<p>Note both OEM keystores and user keystores use this format. This allows
+user keystores to pass verification against the OEM key if they are correctly
+signed, leading to the GREEN state.</p>
+
+<h3 id=keystore_location>Keystore location</h3>
+
+<p>The location of the keystore is not specified here, but that location must
+be known to the bootloader and be both readable and writable by it. Reading should
+happen as per the above; writing a new keystore should be accomplished through
+<code>fastboot flash keystore <path></code>. Sufficient storage must be
+provided for at least one key with storage for additional keys
+recommended.</p>
diff --git a/src/devices/tech/security/selinux/implement.jd b/src/devices/tech/security/selinux/implement.jd
index 9e2e724..1f671fb 100644
--- a/src/devices/tech/security/selinux/implement.jd
+++ b/src/devices/tech/security/selinux/implement.jd
@@ -31,7 +31,7 @@
is out of the scope of this document, but an understanding of how to write
policy rules is now essential when bringing up new Android devices. There is a
great deal of information available regarding SELinux already. See <a
-href="{@docRoot}devices/tech/security/se-linux.html#supporting_documentation">Supporting
+href="{@docRoot}devices/tech/security/selinux/index.html#supporting_documentation">Supporting
documentation</a> for suggested resources.</p>
<h2 id=summary_of_steps>Summary of steps</h2>
diff --git a/src/devices/tech/security/se-linux.jd b/src/devices/tech/security/selinux/index.jd
similarity index 100%
rename from src/devices/tech/security/se-linux.jd
rename to src/devices/tech/security/selinux/index.jd
diff --git a/src/devices/tv/index.jd b/src/devices/tv/index.jd
index 1b8f75f..e60b13b 100644
--- a/src/devices/tv/index.jd
+++ b/src/devices/tv/index.jd
@@ -258,7 +258,7 @@
specific TV Input for picture in picture (PIP) display. Those button presses
are interpreted by the hardware driver supplied by the device manufacturer,
converting hardware scancodes to Android keycodes and passing them to the
-standard Android <a href="http://source.android.com/devices/tech/input/overview.html">input pipeline</a> <code>InputReader</code> and <code>InputDispatcher</code> functions as <a href="http://developer.android.com/reference/android/view/KeyEvent.html">KeyEvents</a>. These in turn trigger events on the TV App if it is in focus. </p>
+standard Android <a href="{@docRoot}devices/input/overview.html">input pipeline</a> <code>InputReader</code> and <code>InputDispatcher</code> functions as <a href="http://developer.android.com/reference/android/view/KeyEvent.html">KeyEvents</a>. These in turn trigger events on the TV App if it is in focus. </p>
<p>Only system TV Inputs are eligible to receive <code>InputEvents</code>, and only if they have the <code>RECEIVE_INPUT_EVENT</code> system permission. The TV Input is responsible to determine which InputEvents
to consume and should allow the TV App to handle the keys it does not need to
diff --git a/src/index.jd b/src/index.jd
index 32e9081..0e7837c 100644
--- a/src/index.jd
+++ b/src/index.jd
@@ -59,13 +59,13 @@
Brand Inquiry Form</a></strong> for answers to branding questions and review
of marketing materials.</p>
-<a href="{@docRoot}devices/audio.html">
+<a href="{@docRoot}devices/audio/index.html">
<h4>Audio gains attributes, USB, latency, and headset documentation</h4></a>
<p>The <strong><a
- href="{@docRoot}devices/audio.html">Audio section</a></strong> now describes <strong><a
- href="{@docRoot}devices/audio_attributes.html">Attributes</a></strong>, <strong><a
- href="{@docRoot}devices/audio_usb.html">USB digital audio</a></strong> support, and <strong><a
- href="{@docRoot}devices/funplug.html">latency tools</a></strong>, while a <strong><a
+ href="{@docRoot}devices/audio/index.html">Audio section</a></strong> now describes <strong><a
+ href="{@docRoot}devices/audio/attributes.html">Attributes</a></strong>, <strong><a
+ href="{@docRoot}devices/audio/usb.html">USB digital audio</a></strong> support, and <strong><a
+ href="{@docRoot}devices/audio/funplug.html">latency tools</a></strong>, while a <strong><a
href="{@docRoot}accessories/headset-spec.html">Wired audio headset
specification</a></strong> can now be found in the <strong><a
href="{@docRoot}accessories/index.html">Accessories section</a></strong>.</p>
diff --git a/src/source/build-numbers.jd b/src/source/build-numbers.jd
index 5f770b9..ba03565 100644
--- a/src/source/build-numbers.jd
+++ b/src/source/build-numbers.jd
@@ -173,50 +173,56 @@
<th>Supported devices</th>
</tr>
<tr>
+ <td>LRX22C</td>
+ <td>android-5.0.1_r1</td>
+ <td>Lollipop</td>
+ <td>Nexus 7 (flo), Nexus 9 (volantis), Nexus 10</td>
+</tr>
+<tr>
<td>LRX21V</td>
- <td>android-5.0.0_r7</td>
+ <td>android-5.0.0_r7.0.1</td>
<td>Lollipop</td>
<td>Nexus Player (fugu)</td>
</tr>
<tr>
<td>LRX21T</td>
- <td>android-5.0.0_r6</td>
+ <td>android-5.0.0_r6.0.1</td>
<td>Lollipop</td>
<td>Nexus 4</td>
</tr>
<tr>
<td>LRX21R</td>
- <td>android-5.0.0_r5.1</td>
+ <td>android-5.0.0_r5.1.0.1</td>
<td>Lollipop</td>
<td>Nexus 9 (volantis)</td>
</tr>
<tr>
<td>LRX21Q</td>
- <td>android-5.0.0_r5</td>
+ <td>android-5.0.0_r5.0.1</td>
<td>Lollipop</td>
<td>Nexus 9 (volantis)</td>
</tr>
<tr>
<td>LRX21P</td>
- <td>android-5.0.0_r4</td>
+ <td>android-5.0.0_r4.0.1</td>
<td>Lollipop</td>
<td>Nexus 7 (flo/grouper), Nexus 10</td>
</tr>
<tr>
<td>LRX21O</td>
- <td>android-5.0.0_r3</td>
+ <td>android-5.0.0_r3.0.1</td>
<td>Lollipop</td>
<td>Nexus 5 (hammerhead), Nexus 6 (shamu)</td>
</tr>
<tr>
<td>LRX21M</td>
- <td>android-5.0.0_r2</td>
+ <td>android-5.0.0_r2.0.1</td>
<td>Lollipop</td>
<td>Nexus Player (fugu)</td>
</tr>
<tr>
<td>LRX21L</td>
- <td>android-5.0.0_r1</td>
+ <td>android-5.0.0_r1.0.1</td>
<td>Lollipop</td>
<td>Nexus 9 (volantis)</td>
</tr>
diff --git a/src/source/building-devices.jd b/src/source/building-devices.jd
index 3c45168..06b4352 100644
--- a/src/source/building-devices.jd
+++ b/src/source/building-devices.jd
@@ -76,6 +76,18 @@
</thead>
<tbody>
<tr>
+<td>shamu</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>fugu</td>
+<td>Press and hold <em>Power</em></td>
+</tr>
+<tr>
+<td>volantis</td>
+<td>Press and hold <em>Volume Down</em>, then press and hold <em>Power</em></td>
+</tr>
+<tr>
<td>hammerhead</td>
<td>Press and hold both <em>Volume Up</em> and <em>Volume Down</em>, then press
and hold <em>Power</em></td>
@@ -204,6 +216,22 @@
</thead>
<tbody>
<tr>
+ <td>Nexus 6</td>
+<td>shamu</td>
+<td>aosp_shamu-userdebug</td>
+</tr>
+</tr>
+<tr>
+ <td>Nexus Player</td>
+<td>fugu</td>
+<td>aosp_fugu-userdebug</td>
+</tr>
+<tr>
+ <td>Nexus 9</td>
+<td>volantis (flounder)</td>
+<td>aosp_flounder-userdebug</td>
+</tr>
+<tr>
<td>Nexus 5 (GSM/LTE)</td>
<td>hammerhead</td>
<td>aosp_hammerhead-userdebug</td>
diff --git a/src/source/building-kernels.jd b/src/source/building-kernels.jd
index 8806d80..7d11614 100644
--- a/src/source/building-kernels.jd
+++ b/src/source/building-kernels.jd
@@ -40,6 +40,24 @@
<th>Build configuration</th>
</tr>
<tr>
+ <td>shamu</td>
+ <td>device/moto/shamu-kernel</td>
+ <td>kernel/msm</td>
+ <td>shamu_defconfig</td>
+ </tr>
+ <tr>
+ <td>fugu</td>
+ <td>device/asus/fugu-kernel</td>
+ <td>kernel/x86_64</td>
+ <td>fugu_defconfig</td>
+ </tr>
+ <tr>
+ <td>volantis</td>
+ <td>device/htc/flounder-kernel</td>
+ <td>kernel/tegra</td>
+ <td>flounder_defconfig</td>
+ </tr>
+ <tr>
<td>hammerhead</td>
<td>device/lge/hammerhead-kernel</td>
<td>kernel/msm</td>
@@ -155,6 +173,7 @@
<h2 id="downloading-sources">Downloading sources</h2>
<p>Depending on which kernel you want,</p>
<pre><code>$ git clone https://android.googlesource.com/kernel/common.git
+$ git clone https://android.googlesource.com/kernel/x86_64.git
$ git clone https://android.googlesource.com/kernel/exynos.git
$ git clone https://android.googlesource.com/kernel/goldfish.git
$ git clone https://android.googlesource.com/kernel/msm.git
@@ -165,16 +184,18 @@
<ul>
<li>The <code>goldfish</code> project contains the kernel sources for the emulated
platforms.</li>
-<li>The <code>msm</code> project has the sources for ADP1, ADP2, Nexus One, Nexus 4,
+<li>The <code>msm</code> project has the sources for ADP1, ADP2, Nexus One, Nexus 4, Nexus 5, Nexus 6,
and can be used as a starting point for work on Qualcomm MSM chipsets.</li>
<li>The <code>omap</code> project is used for PandaBoard and Galaxy Nexus,
and can be used as a starting point for work on TI OMAP chipsets.</li>
<li>The <code>samsung</code> project is used for Nexus S,
and can be used as a starting point for work on Samsung Hummingbird chipsets.</li>
-<li>The <code>tegra</code> project is for Xoom and Nexus 7,
+<li>The <code>tegra</code> project is for Xoom, Nexus 7, Nexus 9,
and can be used as a starting point for work on NVIDIA Tegra chipsets.</li>
<li>The <code>exynos</code> project has the kernel sources for Nexus 10,
and can be used as a starting point for work on Samsung Exynos chipsets.</li>
+<li>The <code>x86_64</code> project has the kernel sources for Nexus Player,
+and can be used as a starting point for work on Intel x86_64 chipsets.</li>
</ul>
<h2 id="downloading-a-prebuilt-gcc">Downloading a prebuilt gcc</h2>
<p>Ensure that the prebuilt toolchain is in your path.</p>
diff --git a/src/source/downloading.jd b/src/source/downloading.jd
index 10b8d0e..9733817 100644
--- a/src/source/downloading.jd
+++ b/src/source/downloading.jd
@@ -151,9 +151,9 @@
for each user, regardless of the IP address.
</p>
<p>
- The first step is to create a password from <a href=
- "https://android.googlesource.com/new-password">the password generator</a> and to save it in
- <code>~/.netrc</code> according to the instructions on that page.
+ The first step is to create a password with <a href=
+ "https://android.googlesource.com/new-password">the password generator</a>
+ and follow the instructions on the password generator page.
</p>
<p>
The second step is to force authenticated access, by using the following manifest URI:
diff --git a/src/source/initializing.jd b/src/source/initializing.jd
index fdbfbfc..2021404 100644
--- a/src/source/initializing.jd
+++ b/src/source/initializing.jd
@@ -241,11 +241,23 @@
<p>Once mounted, you'll do all your work in the "android" volume. You can eject it (unmount it) just like you would with an external drive.</p>
<h3 id="master-branch">Master branch</h3>
<p>To build the latest source in a Mac OS environment, you will need an Intel/x86
-machine running MacOS 10.8 (Mountain Lion), along with Xcode
-4.5.2 and Command Line Tools.</p>
+machine running MacOS 10.8 (Mountain Lion) or later, along with Xcode
+4.5.2 or later including the Command Line Tools.</p>
+
<p>You will also need the <a
href="http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html">Java 7 JDK</a>.
-Select the file: jdk-7u51-macosx-x64.dmg</p>
+Select the file: jdk-7u71-macosx-x64.dmg</p>
+
+<h3 id="branch-50x-and-all-earlier-branches">Branch 5.0.x and earlier branches</h3>
+<p>To build 5.0.x and earlier source in a Mac OS environment, you will need an Intel/x86
+machine running MacOS 10.8 (Mountain Lion), along with Xcode
+4.5.2 and Command Line Tools.</p>
+
+<p>You will also need the <a
+href="http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html">Java 7 JDK</a>.
+Select the file: jdk-7u71-macosx-x64.dmg</p>
+
+<h3 id="branch-44x-and-all-earlier-branches">Branch 4.4.x and earlier branches</h3>
<p>To develop for versions of Android Gingerbread through KitKat, download and
install the Java 6 version of the <a
diff --git a/src/source/submit-patches.jd b/src/source/submit-patches.jd
index c41de25..2bb30a5 100644
--- a/src/source/submit-patches.jd
+++ b/src/source/submit-patches.jd
@@ -30,7 +30,10 @@
<ul>
<li>
<p>Before you follow the instructions on this page, you need to <a href="{@docRoot}source/initializing.html">
-initialize your build environment</a> and <a href="{@docRoot}source/downloading.html">download the source</a>.</p>
+initialize your build environment</a>, <a
+href="{@docRoot}source/downloading.html">download the source</a>, <a
+href="https://android.googlesource.com/new-password">create a
+password</a>, and follow the instructions on the password generator page.</p>
</li>
<li>
<p>For details about Repo and Git, see the <a href="{@docRoot}source/developing.html">Developing</a> section.</p>
@@ -50,20 +53,12 @@
</ul>
<h1 id="for-contributors">For contributors</h1>
<h2 id="authenticate-with-the-server">Authenticate with the server</h2>
-<p>Before you can upload to Gerrit, you need to establish a password that
-will identify you with the server. You only need to do this once.</p>
-<ul>
-<li>
-<p>Sign in on the <a href="https://android-review.googlesource.com/">AOSP Gerrit Server</a>.</p>
-</li>
-<li>
-<p>Go to Settings -> HTTP Password -> Obtain Password</p>
-</li>
-<li>
-<p>Follow the instructions on the subsquent pages, and copy-paste your
-password in <code>~/.netrc</code>. If there are two password lines, copy both.</p>
-</li>
-</ul>
+<p>Before you can upload to Gerrit, you need to <a
+href="https://android.googlesource.com/new-password">establish a password</a>
+that will identify you with the server. Follow the instructions on the password
+generator page. You need to do this only once. See <a
+href="{@docRoot}source/downloading.html#using-authentication">Using
+Authentication</a> for additional details.</p>
<h2 id="start-a-repo-branch">Start a repo branch</h2>
<p>For each change you intend to make, start a new branch within the relevant git repository:</p>
<pre><code>$ repo start NAME .
