Merge "Make use of keystore and keymaster names consistent. Also fix bugs."
diff --git a/src/compatibility/compatibility_toc.cs b/src/compatibility/compatibility_toc.cs
index c0115e9..6b80c1f 100644
--- a/src/compatibility/compatibility_toc.cs
+++ b/src/compatibility/compatibility_toc.cs
@@ -34,7 +34,16 @@
<ul>
<li><a href="<?cs var:toroot ?>compatibility/cts/setup.html">Set up CTS</a></li>
<li><a href="<?cs var:toroot ?>compatibility/cts/run.html">Run CTS</a></li>
- <li><a href="<?cs var:toroot ?>compatibility/cts/verifier.html">Run CTS Verifier</a></li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>compatibility/cts/verifier.html">
+ <span class="en">Run CTS Verifier</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>compatibility/cts/rotation-vector.html">Rotation Vector Crosscheck</a></li>
+ </ul>
+ </li>
<li><a href="<?cs var:toroot ?>compatibility/cts/interpret.html">Interpret Results</a></li>
<li><a href="<?cs var:toroot ?>compatibility/cts/development.html">Develop CTS</a></li>
</ul>
diff --git a/src/compatibility/cts/images/RVCVXCheck_down.png b/src/compatibility/cts/images/RVCVXCheck_down.png
new file mode 100644
index 0000000..6a5b920
--- /dev/null
+++ b/src/compatibility/cts/images/RVCVXCheck_down.png
Binary files differ
diff --git a/src/compatibility/cts/images/RVCVXCheck_flow.png b/src/compatibility/cts/images/RVCVXCheck_flow.png
new file mode 100644
index 0000000..2a965f4
--- /dev/null
+++ b/src/compatibility/cts/images/RVCVXCheck_flow.png
Binary files differ
diff --git a/src/compatibility/cts/images/RVCVXCheck_next.png b/src/compatibility/cts/images/RVCVXCheck_next.png
new file mode 100644
index 0000000..f804ee1
--- /dev/null
+++ b/src/compatibility/cts/images/RVCVXCheck_next.png
Binary files differ
diff --git a/src/compatibility/cts/images/RVCVXCheck_pass.png b/src/compatibility/cts/images/RVCVXCheck_pass.png
new file mode 100644
index 0000000..8729cb9
--- /dev/null
+++ b/src/compatibility/cts/images/RVCVXCheck_pass.png
Binary files differ
diff --git a/src/compatibility/cts/images/RVCVXCheck_start.png b/src/compatibility/cts/images/RVCVXCheck_start.png
new file mode 100644
index 0000000..50543c0
--- /dev/null
+++ b/src/compatibility/cts/images/RVCVXCheck_start.png
Binary files differ
diff --git a/src/compatibility/cts/images/acircles_pattern.png b/src/compatibility/cts/images/acircles_pattern.png
new file mode 100644
index 0000000..9b92a68
--- /dev/null
+++ b/src/compatibility/cts/images/acircles_pattern.png
Binary files differ
diff --git a/src/compatibility/cts/images/acircles_pattern_reduced.png b/src/compatibility/cts/images/acircles_pattern_reduced.png
new file mode 100644
index 0000000..0b33aec
--- /dev/null
+++ b/src/compatibility/cts/images/acircles_pattern_reduced.png
Binary files differ
diff --git a/src/compatibility/cts/rotation-vector.jd b/src/compatibility/cts/rotation-vector.jd
new file mode 100644
index 0000000..4379de6
--- /dev/null
+++ b/src/compatibility/cts/rotation-vector.jd
@@ -0,0 +1,100 @@
+page.title=Rotation Vector CV Crosscheck
+@jd:body
+
+<!--
+ Copyright 2015 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 class="figure" style="width:214px">
+ <img src="images/acircles_pattern_reduced.png" alt="Test pattern thumbnail" height="166" />
+ <p class="img-caption">
+ <strong>Figure 1.</strong> Thumbnail of test pattern. Download the
+full-resolution image linked above.
+ </p>
+</div>
+<p>This page provides the steps to properly test the compatibility of your <a
+href="https://source.android.com/devices/sensors/sensor-types.html#rotation_vector">rotation
+vector sensor</a> implementation. This test should be run when the device declares
+the TYPE_ROTATION_VECTOR composite sensor feature.</p>
+
+<ol>
+ <li>Install OpenCV Manager on the Android device being tested. You may choose one
+the following options:
+ <ul>
+ <li>Install from <a
+href="https://play.google.com/store/apps/details?id=org.opencv.engine">Google
+Play</a>; search for <em>OpenCV Manager</em> in Google Play if this link is
+outdated.
+ <li>Install from OpenCV SDK from <a
+href="http://opencv.org/downloads.html">OpenCV.org</a>. Please choose
+<strong>OpenCV for Android</strong> with version 3.0.0. You will find the APK
+from the <code>apk</code> folder inside the downloaded archive. Please consult <a
+href="http://developer.android.com/tools/help/adb.html#move">installing an
+application</a> for the command to load APKs onto the Android device from
+computer.
+ </ul>
+ <li>Print out the linked <a href="images/acircles_pattern.png">test pattern</a>,
+disabling any scaling options when printing. The pattern should fit US
+Letter paper in landscape or anything bigger.
+<p class="note"><strong>Note:</strong> The inline picture above is low
+resolution and just for illustration. Please do not directly print it as your
+pattern.</p>
+ <li>Place the pattern on a horizontal surface.
+ <li>Start the <strong>Rotation Vector CV Crosscheck</strong> in the CTS Verifier
+app. Follow the guide to turn on airplane mode, turn off auto rotate, and
+adjust adaptive brightness and location if these changes have
+not been made.<br />
+ <img src="images/RVCVXCheck_start.png" alt="Test initiation" height="533" id="test-start" />
+ <p class="img-caption">
+ <strong>Figure 2.</strong> Initiating the test.
+ </p>
+ <li>When the video preview appears, place the phone three feet (or one meter) over
+the pattern so the main camera is facing the pattern with yellow marker on the
+screen and yellow marker on the pattern aligned at the same corner.<br />
+<img src="images/RVCVXCheck_down.png" alt="Test pattern placement" height="207" id="test-pattern-placement" />
+ <p class="img-caption">
+ <strong>Figure 3.</strong> Placing the test pattern.
+ </p>
+ <li>While keeping the pattern entirely in the camera view, rotate the Android
+device under test (DUT) around the pattern in three different directions, one
+by one (1, 2 and then 3 illustrated in picture below) as prompted by the
+rotation range indicator. Keep movement smooth and steady for the best result.<br />
+ <img src="images/RVCVXCheck_flow.png" alt="Device movement" height="426" id="device-movement" />
+ <p class="img-caption">
+ <strong>Figure 4.</strong> Manipulating the device under test.
+ </p>
+ <li>After the capture, the camera preview will disappear and the analysis process
+will start. Wait patiently for analysis to finish; it usually takes one to five
+minutes depending on the phone performance. The phone will sound and vibrate at
+analysis completion. A numerical result will be presented on screen if the
+analysis is successful.<br />
+ <img src="images/RVCVXCheck_next.png" alt="Test completion" height="533" id="test-complete"/>
+ <p class="img-caption">
+ <strong>Figure 5.</strong> Finishing the test.
+ </p>
+ <li>Click <strong>next</strong> to proceed to the pass/fail screen and review the result.<br />
+ <img src="images/RVCVXCheck_pass.png" alt="Test success" height="533" id="test-success" />
+ <p class="img-caption">
+ <strong>Figure 6.</strong> Passing the test.
+ </p>
+<li>Follow these tips for best results:
+ <ol>
+ <li>Since this is a manual test with complexity, you may want to try it a few times
+for the best results.
+ <li>Accelerometer, gyroscope, and magnetometer should be calibrated before testing
+for good results.
+ <li>See this <a href="https://www.youtube.com/watch?v=MsDVmsH1PaI">video
+tutorial</a> for additional details.
+ </ol>
+</ol>
diff --git a/src/compatibility/downloads.jd b/src/compatibility/downloads.jd
index 117ece0..ff8bcd3 100644
--- a/src/compatibility/downloads.jd
+++ b/src/compatibility/downloads.jd
@@ -30,22 +30,22 @@
<h2 id="android-60">Android 6.0</h2>
<p>Android 6.0 is the release of the development milestone code-named Marshmallow.
The source code for the following tests can be synced with the
-'android-cts-6.0_r1' tag in the open-source tree.</p>
+'android-cts-6.0_r2' tag in the open-source tree.</p>
<ul>
<li><a href="6.0/android-6.0-cdd.pdf">Android 6.0 Compatibility Definition
Document (CDD)</a></li>
<li><a
-href="https://dl.google.com/dl/android/cts/android-cts-6.0_r1-linux_x86-arm.zip">Android
-6.0 R1 Compatibility Test Suite (CTS) - ARM</a></li>
+href="https://dl.google.com/dl/android/cts/android-cts-6.0_r2-linux_x86-arm.zip">Android
+6.0 R2 Compatibility Test Suite (CTS) - ARM</a></li>
<li><a
-href="https://dl.google.com/dl/android/cts/android-cts-6.0_r1-linux_x86-x86.zip">Android
-6.0 R1 Compatibility Test Suite (CTS) - x86</a></li>
+href="https://dl.google.com/dl/android/cts/android-cts-6.0_r2-linux_x86-x86.zip">Android
+6.0 R2 Compatibility Test Suite (CTS) - x86</a></li>
<li><a
-href="https://dl.google.com/dl/android/cts/android-cts-verifier-6.0_r1-linux_x86-arm.zip">Android
-6.0 R1 CTS Verifier - ARM</a></li>
+href="https://dl.google.com/dl/android/cts/android-cts-verifier-6.0_r2-linux_x86-arm.zip">Android
+6.0 R2 CTS Verifier - ARM</a></li>
<li><a
-href="https://dl.google.com/dl/android/cts/android-cts-verifier-6.0_r1-linux_x86-x86.zip">Android
-6.0 R1 CTS Verifier - x86</a></li>
+href="https://dl.google.com/dl/android/cts/android-cts-verifier-6.0_r2-linux_x86-x86.zip">Android
+6.0 R2 CTS Verifier - x86</a></li>
</ul>
<h2 id="android-51">Android 5.1</h2>
diff --git a/src/devices/tech/admin/managed-profiles.jd b/src/devices/tech/admin/managed-profiles.jd
index 483fbe4..8951166 100644
--- a/src/devices/tech/admin/managed-profiles.jd
+++ b/src/devices/tech/admin/managed-profiles.jd
@@ -92,7 +92,7 @@
<p>Managed profiles are implemented as a new kind of secondary user, such that:</p>
<pre>
-uid = 10000 * userid + appid
+uid = 100000 * userid + appid
</pre>
diff --git a/src/devices/tech/config/low-ram.jd b/src/devices/tech/config/low-ram.jd
index d08692a..f6d9566 100644
--- a/src/devices/tech/config/low-ram.jd
+++ b/src/devices/tech/config/low-ram.jd
@@ -26,9 +26,9 @@
<h2 id="intro">Introduction</h2>
-<p>Android now supports devices with 512MB of RAM. This documentation is intended
-to help OEMs optimize and configure Android 4.4 for low-memory devices. Several
-of these optimizations are generic enough that they can be applied to previous
+<p>Android now supports devices with 512MB of RAM. This documentation is intended
+to help OEMs optimize and configure Android 4.4 for low-memory devices. Several
+of these optimizations are generic enough that they can be applied to previous
releases as well.</p>
<h2 id="optimizations">Android 4.4 platform optimizations</h2>
@@ -38,8 +38,8 @@
<li>Validated memory-saving kernel configurations: Kernel Same-page Merging
(KSM), and Swap to ZRAM.</li>
<li>Kill cached processes if about to be uncached and too large.</li>
-<li>Don’t allow large services to put themselves back into A Services (so they
-can’t cause the launcher to be killed).</li>
+<li>Don't allow large services to put themselves back into A Services (so they
+can't cause the launcher to be killed).</li>
<li>Kill processes (even ordinarily unkillable ones such as the current IME)
that get too large in idle maintenance.</li>
<li>Serialize the launch of background services.</li>
@@ -73,31 +73,32 @@
<p>
New memtrack HAL to track graphics memory allocations, additional information
in dumpsys meminfo, clarified summaries in meminfo (for example reported free
-RAM includes RAM of cached processes, so that OEMs don’t try to optimize the
+RAM includes RAM of cached processes, so that OEMs don't try to optimize the
wrong thing).
</p>
<h2 id="build-time">Build-time configuration</h2>
<h3 id="flag">Enable Low Ram Device flag</h3>
-<p>We are introducing a new API called <code>ActivityManager.isLowRamDevice()</code> for applications to determine if they should turn off specific memory-intensive
+<p>We are introducing a new API called
+<code>ActivityManager.isLowRamDevice()</code> for applications to determine if
+they should turn off specific memory-intensive
features that work poorly on low-memory devices.</p>
-<p>For 512MB devices, this API is expected to return: "true" It can be enabled by
+<p>For 512MB devices, this API is expected to return: "true" It can be enabled by
the following system property in the device makefile.<br/>
<code>PRODUCT_PROPERTY_OVERRIDES += ro.config.low_ram=true</code></p>
<h3 id="jit">Disable JIT</h3>
- <p>System-wide JIT memory usage is dependent on the number of applications
- running and the code footprint of those applications. The JIT establishes a
- maximum translated code cache size and touches the pages within it as needed.
+ <p>System-wide JIT memory usage is dependent on the number of applications
+ running and the code footprint of those applications. The JIT establishes a
+ maximum translated code cache size and touches the pages within it as needed.
JIT costs somewhere between 3M and 6M across a typical running system.<br/>
<br/>
- The large apps tend to max out the code cache fairly quickly (which by default
- has been 1M). On average, JIT cache usage runs somewhere between 100K and 200K
- bytes per app. Reducing the max size of the cache can help somewhat with
- memory usage, but if set too low will send the JIT into a thrashing mode. For
-the really low-memory devices, we recommend the JIT be disabled entirely.<code>
-</code></p>
+ The large apps tend to max out the code cache fairly quickly (which by default
+ has been 1M). On average, JIT cache usage runs somewhere between 100K and 200K
+ bytes per app. Reducing the max size of the cache can help somewhat with
+ memory usage, but if set too low will send the JIT into a thrashing mode. For
+the really low-memory devices, we recommend the JIT be disabled entirely.</p>
<p>This can be achieved by adding the following line to the product makefile:<br/>
<code>PRODUCT_PROPERTY_OVERRIDES += dalvik.vm.jit.codecachesize=0</code></p>
@@ -112,93 +113,135 @@
<h3 id="kernel-tuning">Tuning kernel/ActivityManager to reduce direct reclaim </h3>
- <p>Direct reclaim happens when a process or the kernel tries to allocate a page
- of memory (either directly or due to faulting in a new page) and the kernel
- has used all available free memory. This requires the kernel to block the
- allocation while it frees up a page. This in turn often requires disk I/O to
- flush out a dirty file-backed page or waiting for <code>lowmemorykiller</code> to kill a
+ <p>Direct reclaim happens when a process or the kernel tries to allocate a page
+ of memory (either directly or due to faulting in a new page) and the kernel
+ has used all available free memory. This requires the kernel to block the
+ allocation while it frees up a page. This in turn often requires disk I/O to
+ flush out a dirty file-backed page or waiting for <code>lowmemorykiller</code> to kill a
process. This can result in extra I/O in any thread, including a UI thread.</p>
-
- <p>To avoid direct reclaim, the kernel has watermarks that trigger <code>kswapd</code> or
- background reclaim. This is a thread that tries to free up pages so the next
- time a real thread allocates it can succeed quickly.</p>
-
- <p>The default threshold to trigger background reclaim is fairly low, around 2MB
- on a 2GB device and 636KB on a 512MB device. And the kernel reclaims only a
- few MB of memory in background reclaim. This means any process that quickly
- allocates more than a few megabytes is going to quickly hit direct reclaim.</p>
-
-<p>Support for a new kernel tunable is added in the android-3.4 kernel branch as
- patch 92189d47f66c67e5fd92eafaa287e153197a454f ("add extra free kbytes
- tunable"). Cherry-picking this patch to a device's kernel will allow
- ActivityManager to tell the kernel to try to keep 3 full-screen 32 bpp buffers
- of memory free.</p>
-
-<p>These thresholds can be configured via the framework config.xml</p>
-<p><code> <!-- Device configuration setting the /proc/sys/vm/extra_free_kbytes tunable in the kernel (if it exists). A high value will increase the amount of memory that the kernel tries to keep free, reducing allocation time and causing the lowmemorykiller to kill earlier. A low value allows more memory to be used by processes but may cause more allocations to block waiting on disk I/O or lowmemorykiller. Overrides the default value chosen by ActivityManager based on screen size. 0 prevents keeping any extra memory over what the kernel keeps by default. -1 keeps the default. --><br />
-<integer name="config_extraFreeKbytesAbsolute">-1</integer></code></p>
-<code>
-<p> <!-- Device configuration adjusting the /proc/sys/vm/extra_free_kbytes tunable in the kernel (if it exists). 0 uses the default value chosen by ActivityManager. A positive value will increase the amount of memory that the kernel tries to keep free, reducing allocation time and causing the lowmemorykiller to kill earlier. A negative value allows more memory to be used by processes but may cause more allocations to block waiting on disk I/O or lowmemorykiller. Directly added to the default value chosen by ActivityManager based on screen size. --><br />
- <integer name="config_extraFreeKbytesAdjust">0</integer></code>
+ <p>To avoid direct reclaim, the kernel has watermarks that trigger <code>kswapd</code> or
+ background reclaim. This is a thread that tries to free up pages so the next
+ time a real thread allocates it can succeed quickly.</p>
+
+ <p>The default threshold to trigger background reclaim is fairly low, around 2MB
+ on a 2GB device and 636KB on a 512MB device. And the kernel reclaims only a
+ few MB of memory in background reclaim. This means any process that quickly
+ allocates more than a few megabytes is going to quickly hit direct reclaim.</p>
+
+<p>Support for a new kernel tunable is added in the android-3.4 kernel branch as
+ patch 92189d47f66c67e5fd92eafaa287e153197a454f ("add extra free kbytes
+ tunable"). Cherry-picking this patch to a device's kernel will allow
+ ActivityManager to tell the kernel to try to keep 3 full-screen 32 bpp buffers
+ of memory free.</p>
+
+<p>These thresholds can be configured via the framework config.xml</p>
+
+<pre>
+<!-- Device configuration setting the /proc/sys/vm/extra_free_kbytes tunable
+in the kernel (if it exists). A high value will increase the amount of memory
+that the kernel tries to keep free, reducing allocation time and causing the
+lowmemorykiller to kill earlier. A low value allows more memory to be used by
+processes but may cause more allocations to block waiting on disk I/O or
+lowmemorykiller. Overrides the default value chosen by ActivityManager based
+on screen size. 0 prevents keeping any extra memory over what the kernel keeps
+by default. -1 keeps the default. -->
+<integer name="config_extraFreeKbytesAbsolute">-1</integer>
+</pre>
+
+<pre>
+<!-- Device configuration adjusting the /proc/sys/vm/extra_free_kbytes
+tunable in the kernel (if it exists). 0 uses the default value chosen by
+ActivityManager. A positive value will increase the amount of memory that the
+kernel tries to keep free, reducing allocation time and causing the
+lowmemorykiller to kill earlier. A negative value allows more memory to be
+used by processes but may cause more allocations to block waiting on disk I/O
+or lowmemorykiller. Directly added to the default value chosen by
+ActivityManager based on screen size. -->
+<integer name="config_extraFreeKbytesAdjust">0</integer>
+</pre>
<h3 id="lowmem">Tuning LowMemoryKiller</h3>
-
- <p>ActivityManager configures the thresholds of the LowMemoryKiller to match its
- expectation of the working set of file-backed pages (cached pages) required to
- run the processes in each priority level bucket. If a device has high
- requirements for the working set, for example if the vendor UI requires more
+<p>ActivityManager configures the thresholds of the LowMemoryKiller to match its
+expectation of the working set of file-backed pages (cached pages) required to
+run the processes in each priority level bucket. If a device has high
+requirements for the working set, for example if the vendor UI requires more
memory or if more services have been added, the thresholds can be increased. </p>
-<p>The thresholds can be reduced if too much memory is being reserved for file
- backed pages, so that background processes are being killed long before disk
+
+<p>The thresholds can be reduced if too much memory is being reserved for file
+backed pages, so that background processes are being killed long before disk
thrashing would occur due to the cache getting too small.</p>
-<p> <code><!-- Device configuration setting the minfree tunable in the lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to fire earlier, keeping more memory in the file cache and preventing I/O thrashing, but allowing fewer processes to stay in memory. A low value will keep more processes in memory but may cause thrashing if set too low. Overrides the default value chosen by ActivityManager based on screen size and total memory for the largest lowmemorykiller bucket, and scaled proportionally to the smaller buckets. -1 keeps the default. --><br />
- <integer name="config_lowMemoryKillerMinFreeKbytesAbsolute">-1</integer></code></p>
-<p> <code><!-- Device configuration adjusting the minfree tunable in the lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to fire earlier, keeping more memory in the file cache and preventing I/O thrashing, but allowing fewer processes to stay in memory. A low value will keep more processes in memory but may cause thrashing if set too low. Directly added to the default value chosen by ActivityManager based on screen size and total memory for the largest lowmemorykiller bucket, and scaled proportionally to the smaller buckets. 0 keeps the default. --><br />
- <integer name="config_lowMemoryKillerMinFreeKbytesAdjust">0</integer></code></p>
+
+<pre>
+<!-- Device configuration setting the minfree tunable in the lowmemorykiller
+in the kernel. A high value will cause the lowmemorykiller to fire earlier,
+keeping more memory in the file cache and preventing I/O thrashing, but
+allowing fewer processes to stay in memory. A low value will keep more
+processes in memory but may cause thrashing if set too low. Overrides the
+default value chosen by ActivityManager based on screen size and total memory
+for the largest lowmemorykiller bucket, and scaled proportionally to the
+smaller buckets. -1 keeps the default. -->
+<integer name="config_lowMemoryKillerMinFreeKbytesAbsolute">-1</integer>
+</pre>
+
+<pre>
+<!-- Device configuration adjusting the minfree tunable in the
+lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to
+fire earlier, keeping more memory in the file cache and preventing I/O
+thrashing, but allowing fewer processes to stay in memory. A low value will
+keep more processes in memory but may cause thrashing if set too low. Directly
+added to the default value chosen by ActivityManager based on screen
+size and total memory for the largest lowmemorykiller bucket, and scaled
+proportionally to the smaller buckets. 0 keeps the default. -->
+<integer name="config_lowMemoryKillerMinFreeKbytesAdjust">0</integer>
+</pre>
+
<h3 id="ksm">KSM (Kernel samepage merging)</h3>
+<p>KSM is a kernel thread that runs in the background and compares pages in
+memory that have been marked <code>MADV_MERGEABLE</code> by user-space. If two pages are
+found to be the same, the KSM thread merges them back as a single
+copy-on-write page of memory.</p>
- <p>KSM is a kernel thread that runs in the background and compares pages in
- memory that have been marked <code>MADV_MERGEABLE</code> by user-space. If two pages are
- found to be the same, the KSM thread merges them back as a single
- copy-on-write page of memory.</p>
-
- <p>KSM will save memory over time on a running system, gaining memory duplication
- at a cost of CPU power, which could have an impact on battery life. You should
- measure whether the power tradeoff is worth the memory savings you get by
- enabling KSM.</p>
-
- <p>To test KSM, we recommend looking at long running devices (several hours) and
- seeing whether KSM makes any noticeable improvement on launch times and
- rendering times.</p>
-
-<p>To enable KSM, enable <code>CONFIG_KSM</code> in the kernel and then add the following lines to your` <code>init.<device>.rc</code> file:<br>
- <code>write /sys/kernel/mm/ksm/pages_to_scan 100<br>
- write /sys/kernel/mm/ksm/sleep_millisecs 500<br>
-write /sys/kernel/mm/ksm/run 1</code></p>
-<p>Once enabled, there are few utilities that will help in the debugging namely :
- procrank, librank, & ksminfo. These utilities allow you to see which KSM
- memory is mapped to what process, which processes use the most KSM memory.
- Once you have found a chunk of memory that looks worth exploring you can use
- either the hat utility if it's a duplicate object on the dalvik heap. </p>
+<p>KSM will save memory over time on a running system, gaining memory duplication
+at a cost of CPU power, which could have an impact on battery life. You should
+measure whether the power tradeoff is worth the memory savings you get by
+enabling KSM.</p>
+
+<p>To test KSM, we recommend looking at long running devices (several hours) and
+seeing whether KSM makes any noticeable improvement on launch times and
+rendering times.</p>
+
+<p>To enable KSM, enable <code>CONFIG_KSM</code> in the kernel and then add the
+following lines to your` <code>init.<device>.rc</code> file:<br>
+
+<pre>
+write /sys/kernel/mm/ksm/pages_to_scan 100
+write /sys/kernel/mm/ksm/sleep_millisecs 500
+write /sys/kernel/mm/ksm/run 1
+</pre>
+
+<p>Once enabled, there are few utilities that will help in the debugging namely :
+procrank, librank, & ksminfo. These utilities allow you to see which KSM
+memory is mapped to what process, which processes use the most KSM memory.
+Once you have found a chunk of memory that looks worth exploring you can use
+either the hat utility if it's a duplicate object on the dalvik heap. </p>
+
<h3 id="zram">Swap to zRAM</h3>
+<p>zRAM swap can increase the amount of memory available in the system by
+compressing memory pages and putting them in a dynamically allocated swap area
+of memory.</p>
- <p>zRAM swap can increase the amount of memory available in the system by
- compressing memory pages and putting them in a dynamically allocated swap area
- of memory.</p>
-
- <p>Again, since this is trading off CPU time for a small increase in memory, you
- should be careful about measuring the performance impact zRAM swap has on your
- system.</p>
-
+<p>Again, since this is trading off CPU time for a small increase in memory, you
+should be careful about measuring the performance impact zRAM swap has on your
+system.</p>
<p>Android handles swap to zRAM at several levels:</p>
<ul>
- <li>First, the following kernel options must be enabled to use zRAM swap
+ <li>First, the following kernel options must be enabled to use zRAM swap
effectively:
<ul>
<li><code>CONFIG_SWAP</code></li>
@@ -210,51 +253,58 @@
<li>Then, you should add a line that looks like this to your fstab:<br />
<code>/dev/block/zram0 none swap defaults zramsize=<size in bytes>,swapprio=<swap partition priority></code><br />
<code><br />
- zramsize</code> is mandatory and indicates how much uncompressed memory you want
- the zram area to hold. Compression ratios in the 30-50% range are usually
+ zramsize</code> is mandatory and indicates how much uncompressed memory you want
+ the zram area to hold. Compression ratios in the 30-50% range are usually
observed.<br />
<br />
- <code>swapprio</code> is optional and not needed if you don't have more than one swap
+ <code>swapprio</code> is optional and not needed if you don't have more than one swap
area.<br />
<br />
+ You should also be sure to label the associated block device as a swap_block_device
+ in the device-specific <a href="{@docRoot}security/selinux/implement.html">
+ sepolicy/file_contexts</a> so that it is treated properly by SELinux. <br />
+ <code>/dev/block/zram0 u:object_r:swap_block_device:s0</code><br />
+ <br />
</li>
- <li>By default, the Linux kernel swaps in 8 pages of memory at a time. When
- using ZRAM, the incremental cost of reading 1 page at a time is negligible
- and may help in case the device is under extreme memory pressure. To read
- only 1 page at a time, add the following to your init.rc:<br />
- `write /proc/sys/vm/page-cluster 0`</li>
- <li>In your init.rc, after the `mount_all /fstab.X` line, add:<br />
- `swapon_all /fstab.X`</li>
- <li>The memory cgroups are automatically configured at boot time if the
+ <li>By default, the Linux kernel swaps in 8 pages of memory at a time. When
+ using ZRAM, the incremental cost of reading 1 page at a time is negligible
+ and may help in case the device is under extreme memory pressure. To read
+ only 1 page at a time, add the following to your <code>init.rc</code>:<br />
+ <code>write /proc/sys/vm/page-cluster 0</code></li>
+ <li>In your <code>init.rc</code> after the <code>mount_all /fstab.X</code> line, add:<br />
+ <code>swapon_all /fstab.X</code></li>
+ <li>The memory cgroups are automatically configured at boot time if the
feature is enabled in kernel.</li>
- <li>If memory cgroups are available, the ActivityManager will mark lower
- priority threads as being more swappable than other threads. If memory is
- needed, the Android kernel will start migrating memory pages to zRAM swap,
- giving a higher priority to those memory pages that have been marked by
+ <li>If memory cgroups are available, the ActivityManager will mark lower
+ priority threads as being more swappable than other threads. If memory is
+ needed, the Android kernel will start migrating memory pages to zRAM swap,
+ giving a higher priority to those memory pages that have been marked by
ActivityManager. </li>
</ul>
+
<h3 id="carveouts">Carveouts, Ion and Contiguous Memory Allocation (CMA)</h3>
- <p>It is especially important on low memory devices to be mindful about
- carveouts, especially those that will not always be fully utilized -- for
- example a carveout for secure video playback. There are several solutions to
- minimizing the impact of your carveout regions that depend on the exact
- requirements of your hardware.</p>
- <p>If hardware permits discontiguous memory
- allocations, the ion system heap allows memory allocations from system memory,
- eliminating the need for a carveout. It also attempts to make large
- allocations to eliminate TLB pressure on peripherals. If memory regions must
- be contiguous or confined to a specific address range, the contiguous memory
- allocator (CMA) can be used.</p>
-<p>This creates a carveout that the system can also
- use of for movable pages. When the region is needed, movable pages will be
- migrated out of it, allowing the system to use a large carveout for other
- purposes when it is free. CMA can be used directly or more simply via ion by
- using the ion cma heap.</p>
+<p>It is especially important on low memory devices to be mindful about
+carveouts, especially those that will not always be fully utilized -- for
+example a carveout for secure video playback. There are several solutions to
+minimizing the impact of your carveout regions that depend on the exact
+requirements of your hardware.</p>
+
+<p>If hardware permits discontiguous memory allocations, the ion system heap
+allows memory allocations from system memory,
+eliminating the need for a carveout. It also attempts to make large
+allocations to eliminate TLB pressure on peripherals. If memory regions must
+be contiguous or confined to a specific address range, the contiguous memory
+allocator (CMA) can be used.</p>
+
+<p>This creates a carveout that the system can also use of for movable pages.
+When the region is needed, movable pages will be migrated out of it, allowing
+the system to use a large carveout for other purposes when it is free. CMA can
+be used directly or more simply via ion by using the ion cma heap.</p>
<h2 id="app-opts">Application optimization tips</h2>
<ul>
- <li>Review <a
+ <li>Review <a
href="http://developer.android.com/training/articles/memory.html">Managing your
App's Memory</a> and these past blog posts on the same topic:
<ul>
@@ -268,7 +318,7 @@
href="http://tools.android.com/recent/lintperformancechecks">http://tools.android.com/recent/lintperformancechecks</a></li>
</ul>
</li>
- <li>Check/remove any unused assets from preinstalled apps -
+ <li>Check/remove any unused assets from preinstalled apps -
development/tools/findunused (should help make the app smaller).</li>
<li>Use PNG format for assets, especially when they have transparent areas</li>
<li>If writing native code, use calloc() rather than malloc/memset</li>
@@ -284,73 +334,74 @@
<ul>
<li><p>SERVICE - SERVICE_RESTARTING<br/>
- Applications that are making themselves run in the background for their own
- reason. Most common problem apps have when they run in the background too
- much. %duration * pss is probably a good "badness" metric, although this set
- is so focused that just doing %duration is probably better to focus on the
+ Applications that are making themselves run in the background for their own
+ reason. Most common problem apps have when they run in the background too
+ much. %duration * pss is probably a good "badness" metric, although this set
+ is so focused that just doing %duration is probably better to focus on the
fact that we just don't want them running at all.</p></li>
<li><p>IMPORTANT_FOREGROUND - RECEIVER<br/>
- Applications running in the background (not directly interacting with the
- user) for any reason. These all add memory load to the system. In this case
- the (%duration * pss) badness value is probably the best ordering of such
- processes, because many of these will be always running for good reason, and
+ Applications running in the background (not directly interacting with the
+ user) for any reason. These all add memory load to the system. In this case
+ the (%duration * pss) badness value is probably the best ordering of such
+ processes, because many of these will be always running for good reason, and
their pss size then is very important as part of their memory load.</p></li>
<li><p>PERSISTENT<br/>
- Persistent system processes. Track pss to watch for these processes getting
+ Persistent system processes. Track pss to watch for these processes getting
too large.</p></li>
<li><p>TOP<br/>
- Process the user is currently interacting with. Again, pss is the important
+ Process the user is currently interacting with. Again, pss is the important
metric here, showing how much memory load the app is creating while in use.</p></li>
<li><p>HOME - CACHED_EMPTY<br/>
- All of these processes at the bottom are ones that the system is keeping
- around in case they are needed again; but they can be freely killed at any
- time and re-created if needed. These are the basis for how we compute the
- memory state -- normal, moderate, low, critical is based on how many of these
- processes the system can keep around. Again the key thing for these processes
- is the pss; these processes should try to get their memory footprint down as
- much as possible when they are in this state, to allow for the maximum total
- number of processes to be kept around. Generally a well behaved app will have
- a pss footprint that is significantly smaller when in this state than when
+ All of these processes at the bottom are ones that the system is keeping
+ around in case they are needed again; but they can be freely killed at any
+ time and re-created if needed. These are the basis for how we compute the
+ memory state -- normal, moderate, low, critical is based on how many of these
+ processes the system can keep around. Again the key thing for these processes
+ is the pss; these processes should try to get their memory footprint down as
+ much as possible when they are in this state, to allow for the maximum total
+ number of processes to be kept around. Generally a well behaved app will have
+ a pss footprint that is significantly smaller when in this state than when
TOP.</p></li>
<li>
<p>TOP vs. CACHED_ACTIVITY-CACHED_ACTIVITY_CLIENT<em><br/>
- </em>The difference in pss between when a process is TOP vs. when it is in either
- of these specific cached states is the best data for seeing how well it is
- releasing memory when going into the background. Excluding CACHED_EMPTY state
- makes this data better, since it removes situations when the process has
- started for some reasons besides doing UI and so will not have to deal with
+ </em>The difference in pss between when a process is TOP vs. when it is in either
+ of these specific cached states is the best data for seeing how well it is
+ releasing memory when going into the background. Excluding CACHED_EMPTY state
+ makes this data better, since it removes situations when the process has
+ started for some reasons besides doing UI and so will not have to deal with
all of the UI overhead it gets when interacting with the user.</p></li>
</ul>
-
<h2 id="analysis">Analysis</h2>
+
<h3 id="app-startup">Analyzing app startup time</h3>
+<p>Use <code>$ adb shell am start</code> with the <code>-P</code> or
+<code>--start-profiler</code> option to run the profiler when your app starts.
+This will start the profiler almost immediately after your process is forked
+from zygote, before any of your code is loaded into it.</p>
- <p>Use "<code>adb shell am start</code>" with the <code>-P</code> or <code>--start-profiler</code> option to run
- the profiler when your app starts. This will start the profiler almost
- immediately after your process is forked from zygote, before any of your code
-is loaded into it.</p>
<h3 id="bug-reports">Analyze using bugreports </h3>
+<p>Now contains various information that can be used for debugging. The
+services include <code>batterystats</code>, <code>netstats</code>,
+<code>procstats</code>, and <code>usagestats</code>. You can find them with
+lines like this:</p>
- <p>Now contains various information that can be used for debugging. The services
- include <code>batterystats</code>, <code>netstats</code>, <code>procstats</code>, and <code>usagestats</code>. You can
- find them with lines like this:</p>
-
-
-<pre>------ CHECKIN BATTERYSTATS (dumpsys batterystats --checkin) ------
+<pre>
+------ CHECKIN BATTERYSTATS (dumpsys batterystats --checkin) ------
7,0,h,-2558644,97,1946288161,3,2,0,340,4183
7,0,h,-2553041,97,1946288161,3,2,0,340,4183
</pre>
+
<h3 id="persistent">Check for any persistent processes</h3>
-
- <p>Reboot the device and check the processes.<br/>
- Run for a few hours and check the processes again. There should not be any
+<p>Reboot the device and check the processes.<br/>
+Run for a few hours and check the processes again. There should not be any
long running processes.</p>
+
<h3 id="longevity">Run longevity tests</h3>
-
- <p>Run for longer durations and track the memory of the process. Does it
- increase? Does it stay constant? Create Canonical use cases and run longevity tests on these scenarios</p>
+<p>Run for longer durations and track the memory of the process. Does it
+increase? Does it stay constant? Create Canonical use cases and run longevity
+tests on these scenarios</p>
diff --git a/src/devices/tech/power/device.jd b/src/devices/tech/power/device.jd
index 985b9c0..b3d6e30 100644
--- a/src/devices/tech/power/device.jd
+++ b/src/devices/tech/power/device.jd
@@ -47,7 +47,6 @@
<pre>
import android.os.BatteryManager;
-import android.os.ServiceManager;
import android.content.Context;
BatteryManager mBatteryManager =
(BatteryManager)Context.getSystemService(Context.BATTERY_SERVICE);
diff --git a/src/index.jd b/src/index.jd
index bdd7965..4ede719 100644
--- a/src/index.jd
+++ b/src/index.jd
@@ -43,6 +43,47 @@
<div class="landing-docs">
<div class="col-8">
<h3>What's New</h3>
+<a href="{@docRoot}security/bulletin/index.html">
+ <h4>Security Bulletins</h4></a>
+ <p>The Android security team now publishes monthly <strong><a
+ href="{@docRoot}security/bulletin/index.html">Nexus Security
+ Bulletins</a></strong> describing key vulnerabilities fixed in AOSP
+ with links to associated changes.</p>
+
+<a href="{@docRoot}source/build-numbers.html">
+ <h4>Lollipop and Marshmallow Build Numbers</h4></a>
+ <p>New <strong><a
+ href="{@docRoot}source/build-numbers.html#source-code-tags-and-builds">Build Numbers</a></strong>
+ have been published for Lollipop on Nexus 6, Nexus 7 (deb), Nexus 9
+ (volantisg), Nexus 10 and Marshmallow on Nexus 5, Nexus 5X, Nexus 6, Nexus 6P,
+ Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), and Nexus Player.</p>
+
+<a href="{@docRoot}compatibility/downloads.html">
+ <h4>6.0 CTS Downloads</h4></a>
+ <p>Android 6.0 R2 Compatibility Test Suite (CTS) and CTS Verifier are available for <strong><a
+ href="{@docRoot}compatibility/downloads.html#android-60">Download</a></strong>.</p>
+
+<a href="{@docRoot}source/community.html">
+ <h4>Android Resources</h4></a>
+ <p>Android Community now includes a collection of <strong><a
+ href="{@docRoot}source/community.html#resources">Resources</a></strong>
+ for contributors, developers, users, and security experts.</p>
+
+<a href="{@docRoot}devices/tech/power/values.html">
+ <h4>Received Feedback Implemented</h4></a>
+ <p>Thanks to contributors who have submitted input using the
+ <strong>Send Feedback</strong> button, <strong><a
+ href="{@docRoot}devices/tech/power/values.html">Power Values</a></strong> now
+ notes <code>cpu.active</code> represents the power used by the CPU rails when
+ running at different speeds and explains why power profile values are given in
+ current (amps). <strong><a
+ href="{@docRoot}source/building-kernels.html#building">Building
+ Kernels</a></strong> describes how to locate the correct filename for each
+ kernel, while <strong><a
+ href="{@docRoot}compatibility/cts/setup.html#user_builds">Setting up
+ CTS</a></strong> more clearly defines compatible devices for the purposes of
+ testing.</p>
+
<a href="{@docRoot}devices/tech/config/kernel_network_tests.html">
<h4>Kernel Networking Unit Tests</h4></a>
<p><strong><a
@@ -50,62 +91,6 @@
Networking Unit Tests</a></strong> describe a suite of tests provided by
Android engineering to help ensure the device kernel will properly
support the Android networking stack.</p>
-
-<a href="{@docRoot}security/verifiedboot/verified-boot.html">
- <h4>Logging Mode Optional When Verifying Boot</h4></a>
- <p><strong><a
- href="{@docRoot}security/verifiedboot/verified-boot.html#boot_partition">Verifying
- Boot</a></strong> now makes it clear logging mode does not have to be
- implemented, and dm-verity may be kept in enforcing mode.</p>
-
-<a href="{@docRoot}compatibility/cts/setup.html">
- <h4>Bluetooth LE Beacons CTS Guidance</h4></a>
- <p><strong><a
- href="{@docRoot}compatibility/cts/setup.html#ble_beacons">Bluetooth LE
- beacons</a></strong> can be used to test the compatibility of Bluetooth low
- energy features on Android devices.</p>
-
-<a href="{@docRoot}devices/audio/index.html">
- <h4>Audio Data Formats, MIDI Architecture, Related Updates</h4></a>
- <p>New information is available about <strong><a
- href="{@docRoot}devices/audio/data_formats.html">Audio Data Formats</a></strong>
- and the <strong><a
- href="{@docRoot}devices/audio/midi_arch.html">MIDI Architecture</a></strong>.
- Also updated are <strong><a
- href="{@docRoot}devices/audio/latency_measurements.html">Latency Measurements</a></strong>
- and <strong><a
- href="{@docRoot}devices/audio/terminology.html">Audio Terminology</a></strong>.
- It also is noted that Android indirectly <strong><a
- href="{@docRoot}devices/audio/midi.html#for-android">supports MIDI 1.0 via
- an external adapter</a></strong>.</p>
-
-<a href="{@docRoot}compatibility/downloads.html">
- <h4>CTS 5.1 R4 Packages</h4></a>
- <p>Android 5.1 R4 Compatibility Test Suite (CTS) and CTS Verifier
- packages can now be found on <strong><a
- href="{@docRoot}compatibility/downloads.html#android-51">Compatibility
- Downloads</a></strong>.</p>
-
-<a href="{@docRoot}source/build-numbers.html">
- <h4>New Build Numbers for Devices Android 6.0 and 5.1</h4></a>
- <p><strong><a
- href="{@docRoot}source/build-numbers.html#source-code-tags-and-builds">Build
- numbers</a></strong> have been published for Nexus 5X, Nexus 6P, Nexus 5, Nexus
- 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg), and Nexus Player running
- Android 6.0 and Nexus 6, Nexus 7 (deb), Nexus 9 (volantisg), Nexus 10 running
- Android 5.1.</p>
-
-<a href="{@docRoot}devices/input/key-layout-files.html">
- <h4>Received Feedback Implemented</h4></a>
- <p>Thanks to the many contributors who have submitted input using the <strong>Send Feedback</strong> button, <strong><a
- href="{@docRoot}devices/input/key-layout-files.html">Key Layout
- Files</a></strong>, the <strong><a
- href="{@docRoot}source/initializing.html#branch-60x">recommended
- version of Mac OS</a></strong>, the <strong><a
- href="{@docRoot}source/initializing.html#installing-required-packages-ubuntu-1404">package
- set for Ubuntu 14.04</a></strong>, and the <strong><a
- href="{@docRoot}devices/drm.html#drm-rights">DRM rights
- methods</a></strong> have been updated for Android 6.0.</p>
</div>
<div class="col-8">
diff --git a/src/security/bulletin/2015-09-01.jd b/src/security/bulletin/2015-09-01.jd
index 930d5ea..060ae91 100644
--- a/src/security/bulletin/2015-09-01.jd
+++ b/src/security/bulletin/2015-09-01.jd
@@ -148,7 +148,7 @@
<p>In the sections below, we provide details for each of the security
vulnerabilities listed in the <a href="#security_vulnerability_summary">Security Vulnerability Summary</a> above. There is a description of the issue, a severity rationale, and a table
with the CVE, associated bug, severity, affected versions, and date reported.
-Where available, we’ve linked the AOSP commit that addressed the issue to the
+Where available, we’ve linked the AOSP change that addressed the issue to the
bug ID. When multiple changes relate to a single bug, additional AOSP
references are linked to numbers following the bug ID.</p>
diff --git a/src/security/bulletin/2015-10-01.jd b/src/security/bulletin/2015-10-01.jd
index 2e9f112..344cdac 100644
--- a/src/security/bulletin/2015-10-01.jd
+++ b/src/security/bulletin/2015-10-01.jd
@@ -204,7 +204,7 @@
<p>In the sections below, we provide details for each of the security
vulnerabilities listed in the <a href="#security_vulnerability_summary">Security Vulnerability Summary</a> above. There is a description of the issue, a severity rationale, and a table
with the CVE, associated bug, severity, affected versions, and date reported.
-Where available, we’ve linked the AOSP commit that addressed the issue to the
+Where available, we’ve linked the AOSP change that addressed the issue to the
bug ID. When multiple changes relate to a single bug, additional AOSP
references are linked to numbers following the bug ID.</p>
diff --git a/src/security/bulletin/2015-11-01.jd b/src/security/bulletin/2015-11-01.jd
index 046cd0a..0cbada2 100644
--- a/src/security/bulletin/2015-11-01.jd
+++ b/src/security/bulletin/2015-11-01.jd
@@ -140,6 +140,8 @@
<li> Natalie Silvanovich of Google Project Zero: CVE-2015-6608
<li> Qidan He (@flanker_hqd) and Wen Xu (@antlr7) from KeenTeam (@K33nTeam,
http://k33nteam.org/): CVE-2015-6612
+ <li> Guang Gong (龚广) (<a href="https://twitter.com/oldfresher">@oldfresher</a>, higongguang@gmail.com) of <a href="http://www.360.cn">Qihoo 360 Technology CC
+o.Ltd</a>: CVE-2015-6612
<li> Seven Shen of Trend Micro: CVE-2015-6610
</ul>
@@ -149,7 +151,7 @@
<p>In the sections below, we provide details for each of the security
vulnerabilities listed in the <a href="#security_vulnerability_summary">Security Vulnerability Summary</a> above. There is a description of the issue, a severity rationale, and a table
with the CVE, associated bug, severity, affected versions, and date reported.
-Where available, we’ve linked the AOSP commit that addressed the issue to the
+Where available, we’ve linked the AOSP change that addressed the issue to the
bug ID. When multiple changes relate to a single bug, additional AOSP
references are linked to numbers following the bug ID.</p>
diff --git a/src/security/bulletin/2015-12-01.jd b/src/security/bulletin/2015-12-01.jd
new file mode 100644
index 0000000..78391c9
--- /dev/null
+++ b/src/security/bulletin/2015-12-01.jd
@@ -0,0 +1,672 @@
+page.title=Nexus Security Bulletin - December 2015
+@jd:body
+
+<!--
+ Copyright 2015 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><em>Published December 07, 2015 | Updated December 09, 2015</em></p>
+
+<p>We have released a security update to Nexus devices through an over-the-air
+(OTA) update as part of our Android Security Bulletin Monthly Release process.
+The Nexus firmware images have also been released to the <a href="https://developers.google.com/android/nexus/images">Google Developer site</a>. Builds LMY48Z or later and Android 6.0 with Security Patch Level of
+December 1, 2015 or later address these issues. Refer to the <a href="#common_questions_and_answers">Common Questions and Answers</a> section for more details.</p>
+
+<p>Partners were notified about and provided updates for these issues on November
+2, 2015 or earlier. Where applicable, source code patches for these issues have been released to
+the Android Open Source Project (AOSP) repository.</p>
+
+<p>The most severe of these issues is a Critical security vulnerability that could
+enable remote code execution on an affected device through multiple methods
+such as email, web browsing, and MMS when processing media files.</p>
+
+<p>We have had no reports of active customer exploitation of these newly reported
+issues. Refer to the <a href="#mitigations">Mitigations</a> section for details on the <a href="{@docRoot}security/enhancements/index.html">Android security platform protections</a> and service protections such as SafetyNet, which improve the security of the
+Android platform. We encourage all customers to accept these updates to their
+devices.</p>
+
+<h2 id="security_vulnerability_summary">Security Vulnerability Summary</h2>
+
+<p>The table below contains a list of security vulnerabilities, the Common
+Vulnerability and Exposures ID (CVE), and their assessed severity. The <a href="{@docRoot}security/overview/updates-resources.html#severity">severity assessment</a> is based on the effect that exploiting the vulnerability would have on an
+affected device, assuming the platform and service mitigations are disabled for
+development purposes or if successfully bypassed.</p>
+<table>
+ <tr>
+ <th>Issue</th>
+ <th>CVE</th>
+ <th>Severity</th>
+ </tr>
+ <tr>
+ <td>Remote Code Execution Vulnerability in Mediaserver</td>
+ <td>CVE-2015-6616</td>
+ <td>Critical</td>
+ </tr>
+ <tr>
+ <td>Remote Code Execution Vulnerability in Skia</td>
+ <td>CVE-2015-6617</td>
+ <td>Critical</td>
+ </tr>
+ <tr>
+ <td>Elevation of Privilege in Kernel</td>
+ <td>CVE-2015-6619</td>
+ <td>Critical</td>
+ </tr>
+ <tr>
+ <td>Remote Code Execution Vulnerabilities in Display Driver</td>
+ <td>CVE-2015-6633<br>
+ CVE-2015-6634</td>
+ <td>Critical</td>
+ </tr>
+ <tr>
+ <td>Remote Code Execution Vulnerability in Bluetooth</td>
+ <td>CVE-2015-6618</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Elevation of Privilege Vulnerabilities in libstagefright</td>
+ <td>CVE-2015-6620 </td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Elevation of Privilege Vulnerability in SystemUI</td>
+ <td>CVE-2015-6621</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Elevation of Privilege Vulnerability in Native Frameworks Library</td>
+ <td>CVE-2015-6622</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Elevation of Privilege Vulnerability in Wi-Fi</td>
+ <td>CVE-2015-6623</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Elevation of Privilege Vulnerability in System Server</td>
+ <td>CVE-2015-6624</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Information Disclosure Vulnerabilities in libstagefright</td>
+ <td>CVE-2015-6626<br>
+ CVE-2015-6631<br>
+ CVE-2015-6632</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Information Disclosure Vulnerability in Audio</td>
+ <td>CVE-2015-6627</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Information Disclosure Vulnerability in Media Framework</td>
+ <td>CVE-2015-6628</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Information Disclosure Vulnerability in Wi-Fi</td>
+ <td>CVE-2015-6629</td>
+ <td>High</td>
+ </tr>
+ <tr>
+ <td>Elevation of Privilege Vulnerability in System Server</td>
+ <td>CVE-2015-6625</td>
+ <td>Moderate</td>
+ </tr>
+ <tr>
+ <td>Information Disclosure Vulnerability in SystemUI</td>
+ <td>CVE-2015-6630</td>
+ <td>Moderate</td>
+ </tr>
+</table>
+
+
+<p>The <a href="{@docRoot}security/overview/updates-resources.html#severity">severity assessment</a> is based on the effect that exploiting the vulnerability would have on an
+affected device, assuming the platform and service mitigations are disabled for
+development purposes or if successfully bypassed.</p>
+
+<h2 id="mitigations">Mitigations</h2>
+
+
+<p>This is a summary of the mitigations provided by the <a href="{@docRoot}security/enhancements/index.html">Android security platform</a> and service protections such as SafetyNet. These capabilities reduce the
+likelihood that security vulnerabilities could be successfully exploited on
+Android.</p>
+
+<ul>
+ <li> Exploitation for many issues on Android is made more difficult by enhancements
+in newer versions of the Android platform. We encourage all users to update to
+the latest version of Android where possible.</li>
+ <li> The Android Security team is actively monitoring for abuse with Verify Apps and
+SafetyNet which will warn about potentially harmful applications about to be
+installed. Device rooting tools are prohibited within Google Play. To protect
+users who install applications from outside of Google Play, Verify Apps is
+enabled by default and will warn users about known rooting applications. Verify
+Apps attempts to identify and block installation of known malicious
+applications that exploit a privilege escalation vulnerability. If such an
+application has already been installed, Verify Apps will notify the user and
+attempt to remove any such applications.</li>
+ <li> As appropriate, Google Hangouts and Messenger applications do not automatically
+pass media to processes such as mediaserver.</li>
+</ul>
+
+<h2 id="acknowledgements">Acknowledgements</h2>
+
+<p>We would like to thank these researchers for their contributions:</p>
+
+<ul>
+ <li> Abhishek Arya, Oliver Chang, and Martin Barbella of Google Chrome Security
+Team: CVE-2015-6616, CVE-2015-6617, CVE-2015-6623, CVE-2015-6626,
+CVE-2015-6619, CVE-2015-6633, CVE-2015-6634
+ <li> Flanker (<a href="https://twitter.com/flanker_hqd">@flanker_hqd</a>) of <a href="http://k33nteam.org/">KeenTeam</a> (<a href="https://twitter.com/k33nteam">@K33nTeam</a>): CVE-2015-6620
+ <li> Guang Gong (龚广) (<a href="https://twitter.com/oldfresher">@oldfresher</a>, higongguang@gmail.com) of <a href="http://www.360.cn">Qihoo 360 Technology Co.Ltd</a>: CVE-2015-6626
+ <li> Mark Carter (<a href="https://twitter.com/hanpingchinese">@hanpingchinese</a>) of EmberMitre Ltd: CVE-2015-6630
+ <li> Michał Bednarski (<a href="https://github.com/michalbednarski">https://github.com/michalbednarski</a>): CVE-2015-6621
+ <li> Natalie Silvanovich of Google Project Zero: CVE-2015-6616
+ <li> Peter Pi of Trend Micro: CVE-2015-6616, CVE-2015-6628
+ <li> Qidan He (<a href="https://twitter.com/flanker_hqd">@flanker_hqd</a>) and Marco Grassi (<a href="https://twitter.com/marcograss">@marcograss</a>) of <a href="http://k33nteam.org/">KeenTeam</a> (<a href="https://twitter.com/k33nteam">@K33nTeam</a>): CVE-2015-6622
+ <li> Tzu-Yin (Nina) Tai: CVE-2015-6627
+</ul>
+
+<h2 id="security_vulnerability_details">Security Vulnerability Details</h2>
+
+<p>In the sections below, we provide details for each of the security
+vulnerabilities listed in the <a href="#security_vulnerability_summary">Security Vulnerability Summary</a> above. There is a description of the issue, a severity rationale, and a table
+with the CVE, associated bug, severity, affected versions, and date reported.
+When available, we will link the AOSP change that addressed the issue to the
+bug ID. When multiple changes relate to a single bug, additional AOSP
+references are linked to numbers following the bug ID.</p>
+
+<h3 id="remote_code_execution_vulnerabilities_in_mediaserver">Remote Code Execution Vulnerabilities in Mediaserver</h3>
+
+
+<p>During media file and data processing of a specially crafted file,
+vulnerabilities in mediaserver could allow an attacker to cause memory
+corruption and remote code execution as the mediaserver process.</p>
+
+<p>The affected functionality is provided as a core part of the operating system
+and there are multiple applications that allow it to be reached with remote
+content, most notably MMS and browser playback of media.</p>
+
+<p>This issue is rated as a Critical severity due to the possibility of remote
+code execution within the context of the mediaserver service. The mediaserver
+service has access to audio and video streams as well as access to privileges
+that third-party apps cannot normally access.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td rowspan="5">CVE-2015-6616</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/77c185d5499d6174e7a97b3e1512994d3a803151">ANDROID-24630158</a></td>
+ <td>Critical</td>
+ <td>6.0 and below</td>
+ <td>Google Internal</td>
+ </tr>
+ <tr>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/0d35dd2068d6422c3c77fb68f248cbabf3d0b10c">ANDROID-23882800</a></td>
+ <td>Critical</td>
+ <td>6.0 and below</td>
+ <td>Google Internal</td>
+ </tr>
+ <tr>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/dedaca6f04ac9f95fabe3b64d44cd1a2050f079e">ANDROID-17769851</a></td>
+ <td>Critical</td>
+ <td>5.1 and below</td>
+ <td>Google Internal</td>
+ </tr>
+ <tr>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/5d101298d8b0a78a1dc5bd26dbdada411f4ecd4d">ANDROID-24441553</a></td>
+ <td>Critical</td>
+ <td>6.0 and below</td>
+ <td>Sep 22, 2015</td>
+ </tr>
+ <tr>
+ <td><a href="https://android.googlesource.com/platform%2Fexternal%2Flibavc/+/2ee0c1bced131ffb06d1b430b08a202cd3a52005">ANDROID-24157524</a></td>
+ <td>Critical</td>
+ <td>6.0</td>
+ <td>Sep 08, 2015</td>
+ </tr>
+</table>
+
+<h3 id="remote_code_execution_vulnerability_in_skia">Remote Code Execution Vulnerability in Skia</h3>
+
+<p>A vulnerability in the Skia component may be leveraged when processing a
+specially crafted media file, that could lead to memory corruption and remote
+code execution in a privileged process. This issue is rated as a Critical
+severity due to the possibility of remote code execution through multiple
+attack methods such as email, web browsing, and MMS when processing media
+files.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6617</td>
+ <td><a href="https://android.googlesource.com/platform%2Fexternal%2Fskia/+/a1d8ac0ac0af44d74fc082838936ec265216ab60">ANDROID-23648740</a></td>
+ <td>Critical</td>
+ <td>6.0 and below</td>
+ <td>Google internal</td>
+ </tr>
+</table>
+
+<h3 id="elevation_of_privilege_in_kernel">Elevation of Privilege in Kernel</h3>
+
+<p>An elevation of privilege vulnerability in the system kernel could enable a
+local malicious application to execute arbitrary code within the device root
+context. This issue is rated as a Critical severity due to the possibility of a
+local permanent device compromise and the device could only be repaired by
+re-flashing the operating system.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6619</td>
+ <td><a href ="https://android.googlesource.com/device%2Fhtc%2Fflounder-kernel/+/25d3e5d71865a7c0324423fad87aaabb70e82ee4">ANDROID-23520714</a></td>
+ <td>Critical</td>
+ <td>6.0 and below</td>
+ <td>Jun 7, 2015</td>
+ </tr>
+</table>
+
+<h3 id="remote_code_execution_vulnerabilities_in_display_driver">
+Remote Code Execution Vulnerabilities in Display Driver</h3>
+
+<p>There are vulnerabilities in the display drivers that, when processing a media
+file, could cause memory corruption and potential arbitrary code execution in
+the context of the user mode driver loaded by mediaserver. This issue is rated
+as a Critical severity due to the possibility of remote code execution through
+multiple attack methods such as email, web browsing, and MMS when processing
+media files.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6633</td>
+ <td>ANDROID-23987307*</td>
+ <td>Critical</td>
+ <td>6.0 and below</td>
+ <td>Google Internal</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-6634</td>
+ <td><a href="https://android.googlesource.com/platform%2Fhardware%2Fqcom%2Fdisplay/+/25016fd2865943dec1a6b2b167ef85c772fb90f7">ANDROID-24163261</a> [<a href="https://android.googlesource.com/platform%2Fhardware%2Fqcom%2Fdisplay/+/0787bc222a016e944f01492c2dd04bd03c1da6af">2</a>] [<a href="https://android.googlesource.com/platform%2Fhardware%2Fqcom%2Fdisplay/+/95c2601aab7f27505e8b086fdd1f1dce31091e5d">3</a>] [<a href="https://android.googlesource.com/platform%2Fhardware%2Fqcom%2Fdisplay/+/45660529af1f4063a00e84aa2361649e6a9a878c">4</a>]</td>
+ <td>Critical</td>
+ <td>5.1 and below</td>
+ <td>Google Internal</td>
+ </tr>
+</table>
+<p> *The patch for this issue is not in AOSP. The update is contained in the
+latest binary drivers for Nexus devices available from the <a href="https://developers.google.com/android/nexus/drivers">Google Developer site</a>.</p>
+
+<h3 id="remote_code_execution_vulnerability_in_bluetooth">Remote Code Execution Vulnerability in Bluetooth</h3>
+
+<p>A vulnerability in Android's Bluetooth component could allow remote code
+execution. However multiple manual steps are required before this could occur.
+In order to do this it would require a successfully paired device, after the
+personal area network (PAN) profile is enabled (for example using Bluetooth
+Tethering) and the device is paired. The remote code execution would be at the
+privilege of the Bluetooth service. A device is only vulnerable to this issue
+from a successfully paired device while in local proximity.</p>
+
+<p>This issue is rated as High severity because an attacker could remotely execute
+arbitrary code only after multiple manual steps are taken and from a locally
+proximate attacker that had previously been allowed to pair a device.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) </th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6618</td>
+ <td>ANDROID-24595992*</td>
+ <td>High</td>
+ <td>4.4, 5.0, and 5.1</td>
+ <td>Sep 28, 2015</td>
+ </tr>
+</table>
+<p> *The patch for this issue is not in AOSP. The update is contained in the
+latest binary drivers for Nexus devices available from the <a href="https://developers.google.com/android/nexus/drivers">Google Developer site</a>.</p>
+
+<h3 id="elevation_of_privilege_vulnerabilities_in_libstagefright">
+Elevation of Privilege Vulnerabilities in libstagefright</h3>
+
+<p>There are multiple vulnerabilities in libstagefright that could enable a local
+malicious application to execute arbitrary code within the context of the
+mediaserver service. This issue is rated as High severity because it could be
+used to gain elevated capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to a third-party
+applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td rowspan="2">CVE-2015-6620</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/2b8cd9cbb3e72ffd048ffdd1609fac74f61a22ac">ANDROID-24123723</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Sep 10, 2015</td>
+ </tr>
+ <tr>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/77c185d5499d6174e7a97b3e1512994d3a803151">ANDROID-24445127</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Sep 2, 2015</td>
+ </tr>
+</table>
+
+<h3 id="elevation_of_privilege_vulnerability_in_systemui">
+Elevation of Privilege Vulnerability in SystemUI</h3>
+
+<p>When setting an alarm using the clock application, a vulnerability in the
+SystemUI component could allow an application to execute a task at an elevated
+privilege level. This issue is rated as High severity because it could be used
+to gain elevated capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to a third-party
+applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6621</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fbase/+/e70e8ac93807c51240b2cd9afed35bf454ea00b3">ANDROID-23909438</a></td>
+ <td>High</td>
+ <td>5.0, 5.1, and 6.0</td>
+ <td>Sep 7, 2015</td>
+ </tr>
+</table>
+
+<h3 id="information_disclosure_vulnerability_in_native_frameworks_library">Information Disclosure Vulnerability in Native Frameworks Library</h3>
+
+<p>An information disclosure vulnerability in Android Native Frameworks Library
+could permit a bypass of security measures in place to increase the difficulty
+of attackers exploiting the platform. These issues are rated as High severity
+because they could also be used to gain elevated capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to third-party applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6622</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fnative/+/5d17838adef13062717322e79d4db0b9bb6b2395">ANDROID-23905002</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Sep 7, 2015</td>
+ </tr>
+</table>
+
+<h3 id="elevation_of_privilege_vulnerability_in_wi-fi">Elevation of Privilege Vulnerability in Wi-Fi</h3>
+
+<p>An elevation of privilege vulnerability in Wi-Fi could enable a local malicious
+application to execute arbitrary code within the context of an elevated system
+service. This issue is rated as High severity because it could be used to gain
+elevated capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to a third-party application.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6623</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fopt%2Fnet%2Fwifi/+/a15a2ee69156fa6fff09c0dd9b8182cb8fafde1c">ANDROID-24872703</a></td>
+ <td>High</td>
+ <td>6.0</td>
+ <td>Google Internal</td>
+ </tr>
+</table>
+
+
+<h3 id="elevation_of_privilege_vulnerability_in_system_server">Elevation of Privilege Vulnerability in System Server</h3>
+
+
+<p>An elevation of privilege vulnerability in the System Server component could
+enable a local malicious application to gain access to service related
+information. This issue is rated as High severity because it could be used to
+gain elevated capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to third-party applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6624</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/f86a441cb5b0dccd3106019e578c3535498e5315">ANDROID-23999740</a></td>
+ <td>High</td>
+ <td>6.0</td>
+ <td>Google internal</td>
+ </tr>
+</table>
+
+
+<h3 id="information_disclosure_vulnerabilities_in_libstagefright">
+Information Disclosure Vulnerabilities in libstagefright</h3>
+
+<p>There are information disclosure vulnerabilities in libstagefright that during
+communication with mediaserver, could permit a bypass of security measures in
+place to increase the difficulty of attackers exploiting the platform. These
+issues are rated as High severity because they could also be used to gain
+elevated capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to third-party applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6632</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/5cae16bdce77b0a3ba590b55637f7d55a2f35402">ANDROID-24346430</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Google Internal</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-6626</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/8dde7269a5356503d2b283234b6cb46d0c3f214e">ANDROID-24310423</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Sep 2, 2015</td>
+ </tr>
+ <tr>
+ <td>CVE-2015-6631</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/7ed8d1eff9b292b3c65a875b13a549e29654534b">ANDROID-24623447</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Aug 21, 2015</td>
+ </tr>
+</table>
+
+<h3 id="information_disclosure_vulnerability_in_audio">Information Disclosure Vulnerability in Audio</h3>
+
+<p>A vulnerability in the Audio component could be exploited during audio file
+processing. This vulnerability could allow a local malicious application,
+during processing of a specially crafted file, to cause information disclosure.
+This issue is rated as High severity because it could be used to gain elevated
+capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to third-party applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6627</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/8c987fa71326eb0cc504959a5ebb440410d73180">ANDROID-24211743</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Google Internal</td>
+ </tr>
+</table>
+
+<h3 id="information_disclosure_vulnerability_in_media_framework">Information Disclosure Vulnerability in Media Framework</h3>
+
+<p>There is an information disclosure vulnerability in Media Framework that during
+communication with mediaserver, could permit a bypass of security measures in
+place to increase the difficulty of attackers exploiting the platform. This
+issue is rated as High severity because it could also be used to gain elevated
+capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to third-party applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6628</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fav/+/5e7e87a383fdb1fece977097a7e3cc51b296f3a0">ANDROID-24074485</a></td>
+ <td>High</td>
+ <td>6.0 and below</td>
+ <td>Sep 8, 2015</td>
+ </tr>
+</table>
+
+<h3 id="information_disclosure_vulnerability_in_wi-fi">Information Disclosure Vulnerability in Wi-Fi</h3>
+
+<p>A vulnerability in the Wi-Fi component could allow an attacker to cause the
+Wi-Fi service to disclose information. This issue is rated as High severity
+because it could be used to gain elevated capabilities, such as <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">Signature</a> or <a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">SignatureOrSystem</a> permissions privileges, which are not accessible to a third-party
+applications.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6629</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fopt%2Fnet%2Fwifi/+/8b41627f7411306a0c42867fb526fa214f2991cd">ANDROID-22667667</a></td>
+ <td>High</td>
+ <td>5.1 and 5.0</td>
+ <td>Google Internal</td>
+ </tr>
+</table>
+
+<h3 id="elevation_of_privilege_vulnerability_in_system_server19">Elevation of Privilege Vulnerability in System Server</h3>
+
+
+<p>An elevation of privilege vulnerability in the System Server could enable a
+local malicious application to gain access to Wi-Fi service related
+information. This issue is rated as Moderate severity because it could be used
+to improperly gain “<a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">dangerous</a>” permissions.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6625</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fopt%2Fnet%2Fwifi/+/29fa7d2ffc3bba55173969309e280328b43eeca1">ANDROID-23936840</a></td>
+ <td>Moderate</td>
+ <td>6.0</td>
+ <td>Google Internal</td>
+ </tr>
+</table>
+
+<h3 id="information_disclosure_vulnerability_in_systemui">Information Disclosure Vulnerability in SystemUI</h3>
+
+<p>An information disclosure vulnerability in the SystemUI could enable a local
+malicious application to gain access to screenshots. This issue is rated as
+Moderate severity because it could be used to improperly gain “<a href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">dangerous</a>” permissions.</p>
+<table>
+ <tr>
+ <th>CVE</th>
+ <th>Bug(s) with AOSP links</th>
+ <th>Severity</th>
+ <th>Affected versions</th>
+ <th>Date reported</th>
+ </tr>
+ <tr>
+ <td>CVE-2015-6630</td>
+ <td><a href="https://android.googlesource.com/platform%2Fframeworks%2Fbase/+/51c2619c7706575a171cf29819db14e91b815a62">ANDROID-19121797</a></td>
+ <td>Moderate</td>
+ <td>5.0, 5.1, and 6.0</td>
+ <td>Jan 22, 2015</td>
+ </tr>
+</table>
+
+<h3 id="common_questions_and_answers">Common Questions and Answers</h3>
+
+<p>This section will review answers to common questions that may occur after
+reading this bulletin.</p>
+
+<p><strong>1. How do I determine if my device is updated to address these issues?</strong></p>
+
+<p>Builds LMY48Z or later and Android 6.0 with Security Patch Level of
+December 1, 2015 or later address these issues. Refer to the <a href="https://support.google.com/nexus/answer/4457705">Nexus documentation</a> for instructions on how to check the security patch level. Device
+manufacturers that include these updates should set the patch string level to:
+[ro.build.version.security_patch]:[2015-12-01]</p>
+
+<h2 id="revisions">Revisions</h2>
+<ul>
+ <li> December 07, 2015: Originally Published
+ <li> December 09, 2015: Bulletin revised to include AOSP links.
+</ul>
diff --git a/src/security/bulletin/index.jd b/src/security/bulletin/index.jd
index de31a16..d7befcc 100644
--- a/src/security/bulletin/index.jd
+++ b/src/security/bulletin/index.jd
@@ -16,13 +16,6 @@
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>Security has always been a major focus for Android and Google Play: Android was
built from day one with security in mind. Monthly device updates are an
important tool to make and keep Android users safe. This page contains the
@@ -40,6 +33,11 @@
<th>Android Security Patch Level</th>
</tr>
<tr>
+ <td><a href="2015-12-01.html">December 2015</a></td>
+ <td>December 7, 2015</td>
+ <td>December 1, 2015: [2015-12-01]</td>
+</tr>
+<tr>
<td><a href="2015-11-01.html">November 2015</a></td>
<td>November 2, 2015</td>
<td>November 1, 2015: [2015-11-01]</td>
diff --git a/src/security/security_toc.cs b/src/security/security_toc.cs
index f0ba2af..790b8e8 100644
--- a/src/security/security_toc.cs
+++ b/src/security/security_toc.cs
@@ -48,8 +48,9 @@
<a href="<?cs var:toroot ?>security/bulletin/index.html">
<span class="en">Bulletins</span>
</a>
- </div>
+ </div>
<ul>
+ <li><a href="<?cs var:toroot ?>security/bulletin/2015-12-01.html">December 2015</a></li>
<li><a href="<?cs var:toroot ?>security/bulletin/2015-11-01.html">November 2015</a></li>
<li><a href="<?cs var:toroot ?>security/bulletin/2015-10-01.html">October 2015</a></li>
<li><a href="<?cs var:toroot ?>security/bulletin/2015-09-01.html">September 2015</a></li>
@@ -97,7 +98,7 @@
<li><a href="<?cs var:toroot ?>security/selinux/customize.html">Customization</a></li>
<li><a href="<?cs var:toroot ?>security/selinux/validate.html">Validation</a></li>
</ul>
- </li>
+ </li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>security/verifiedboot/index.html">
diff --git a/src/source/build-numbers.jd b/src/source/build-numbers.jd
index 886cc25..f27821e 100644
--- a/src/source/build-numbers.jd
+++ b/src/source/build-numbers.jd
@@ -183,6 +183,24 @@
<th>Supported devices</th>
</tr>
<tr>
+ <td>MMB29M</td>
+ <td>android-6.0.1_r3</td>
+ <td>Marshmallow</td>
+ <td>Nexus 6P, Nexus Player</td>
+</tr>
+<tr>
+ <td>MMB29K</td>
+ <td>android-6.0.1_r1</td>
+ <td>Marshmallow</td>
+ <td>Nexus 5, Nexus 5X, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)</td>
+</tr>
+<tr>
+ <td>MMB29N</td>
+ <td>android-6.0.0_r41</td>
+ <td>Marshmallow</td>
+ <td>Nexus 6P</td>
+</tr>
+<tr>
<td>MDB08M</td>
<td>android-6.0.0_r26</td>
<td>Marshmallow</td>
@@ -219,6 +237,12 @@
<td>Nexus 6P</td>
</tr>
<tr>
+ <td>MRA58X</td>
+ <td>android-6.0.0_r6</td>
+ <td>Marshmallow</td>
+ <td>Nexus 6</td>
+</tr>
+<tr>
<td>MRA58V</td>
<td>android-6.0.0_r5</td>
<td>Marshmallow</td>
@@ -249,6 +273,12 @@
<td>Nexus 6 (For T-Mobile ONLY)</td>
</tr>
<tr>
+ <td>LMY48Z</td>
+ <td>android-5.1.1_r30</td>
+ <td>Lollipop</td>
+ <td>Nexus 6, Nexus 7 (deb), Nexus 9 (volantisg), Nexus 10</td>
+</tr>
+<tr>
<td>LMY48Y</td>
<td>android-5.1.1_r26</td>
<td>Lollipop</td>
diff --git a/src/source/code-style.jd b/src/source/code-style.jd
index dd52b5d..364b0e9 100644
--- a/src/source/code-style.jd
+++ b/src/source/code-style.jd
@@ -1,8 +1,8 @@
-page.title=Code Style Guidelines for Contributors
+page.title=Code Style for Contributors
@jd:body
<!--
- Copyright 2013 The Android Open Source Project
+ Copyright 2015 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.
@@ -24,43 +24,42 @@
</div>
</div>
-<p>The rules below are not guidelines or recommendations, but strict rules.
-Contributions to Android generally <em>will not be accepted</em> if they do not
-adhere to these rules.</p>
-
-<p>Not all existing code follows these rules, but all new code is expected to.</p>
+<p>The code styles below are strict rules, not guidelines or recommendations.
+Contributions to Android that do not adhere to these rules are generally <em>not
+accepted</em>. We recognize that not all existing code follows these rules, but
+we expect all new code to be compliant.</p>
<h2 id="java-language-rules">Java Language Rules</h2>
-<p>We follow standard Java coding conventions. We add a few rules:</p>
+<p>Android follows standard Java coding conventions with the additional rules
+described below.</p>
+
<h3 id="dont-ignore-exceptions">Don't Ignore Exceptions</h3>
-<p>Sometimes it is tempting to write code that completely ignores an exception
-like this:</p>
+<p>It can be tempting to write code that completely ignores an exception, such
+as:</p>
<pre><code>void setServerPort(String value) {
try {
serverPort = Integer.parseInt(value);
} catch (NumberFormatException e) { }
}
</code></pre>
-<p>You must never do this. While you may think that your code will never
-encounter this error condition or that it is not important to handle it,
-ignoring exceptions like above creates mines in your code for someone else to
-trip over some day. You must handle every Exception in your code in some
-principled way. The specific handling varies depending on the case.</p>
+<p>Do not do this. While you may think your code will never encounter this error
+condition or that it is not important to handle it, ignoring exceptions as above
+creates mines in your code for someone else to trigger some day. You must handle
+every Exception in your code in a principled way; the specific handling varies
+depending on the case.</p>
<p><em>Anytime somebody has an empty catch clause they should have a
creepy feeling. There are definitely times when it is actually the correct
thing to do, but at least you have to think about it. In Java you can't escape
the creepy feeling.</em> -<a href="http://www.artima.com/intv/solid4.html">James Gosling</a></p>
<p>Acceptable alternatives (in order of preference) are:</p>
<ul>
-<li>
-<p>Throw the exception up to the caller of your method.</p>
+<li>Throw the exception up to the caller of your method.
<pre><code>void setServerPort(String value) throws NumberFormatException {
serverPort = Integer.parseInt(value);
}
</code></pre>
</li>
-<li>
-<p>Throw a new exception that's appropriate to your level of abstraction.</p>
+<li>Throw a new exception that's appropriate to your level of abstraction.
<pre><code>void setServerPort(String value) throws ConfigurationException {
try {
serverPort = Integer.parseInt(value);
@@ -70,24 +69,22 @@
}
</code></pre>
</li>
-<li>
-<p>Handle the error gracefully and substitute an appropriate value in the
-catch {} block.</p>
+<li>Handle the error gracefully and substitute an appropriate value in the
+catch {} block.
<pre><code>/** Set port. If value is not a valid number, 80 is substituted. */
void setServerPort(String value) {
try {
serverPort = Integer.parseInt(value);
} catch (NumberFormatException e) {
- serverPort = 80; // default port for server
+ serverPort = 80; // default port for server
}
}
</code></pre>
</li>
-<li>
-<p>Catch the Exception and throw a new <code>RuntimeException</code>. This is dangerous:
-only do it if you are positive that if this error occurs, the appropriate
-thing to do is crash.</p>
+<li>Catch the Exception and throw a new <code>RuntimeException</code>. This is
+dangerous, so do it only if you are positive that if this error occurs the
+appropriate thing to do is crash.
<pre><code>/** Set port. If value is not a valid number, die. */
void setServerPort(String value) {
@@ -98,14 +95,13 @@
}
}
</code></pre>
-<p>Note that the original exception is passed to the constructor for
-RuntimeException. If your code must compile under Java 1.3, you will need to
-omit the exception that is the cause.</p>
+<p class="note"><strong>Note</strong> The original exception is passed to the
+constructor for RuntimeException. If your code must compile under Java 1.3, you
+must omit the exception that is the cause.</p>
</li>
-<li>
-<p>Last resort: if you are confident that actually ignoring the exception is
+<li>As a last resort, if you are confident that ignoring the exception is
appropriate then you may ignore it, but you must also comment why with a good
-reason:</p>
+reason:
<pre><code>/** If value is not a valid number, original port number is used. */
void setServerPort(String value) {
try {
@@ -118,33 +114,33 @@
</code></pre>
</li>
</ul>
+
<h3 id="dont-catch-generic-exception">Don't Catch Generic Exception</h3>
-<p>Sometimes it is tempting to be lazy when catching exceptions and do
+<p>It can also be tempting to be lazy when catching exceptions and do
something like this:</p>
<pre><code>try {
- someComplicatedIOFunction(); // may throw IOException
- someComplicatedParsingFunction(); // may throw ParsingException
- someComplicatedSecurityFunction(); // may throw SecurityException
- // phew, made it all the way
-} catch (Exception e) { // I'll just catch all exceptions
+ someComplicatedIOFunction(); // may throw IOException
+ someComplicatedParsingFunction(); // may throw ParsingException
+ someComplicatedSecurityFunction(); // may throw SecurityException
+ // phew, made it all the way
+} catch (Exception e) { // I'll just catch all exceptions
handleError(); // with one generic handler!
}
</code></pre>
-<p>You should not do this. In almost all cases it is inappropriate to catch
-generic Exception or Throwable, preferably not Throwable, because it includes
-Error exceptions as well. It is very dangerous. It means that Exceptions you
-never expected (including RuntimeExceptions like ClassCastException) end up
-getting caught in application-level error handling. It obscures the failure
-handling properties of your code. It means if someone adds a new type of
-Exception in the code you're calling, the compiler won't help you realize you
-need to handle that error differently. And in most cases you shouldn't be
-handling different types of exception the same way, anyway.</p>
-<p>There are rare exceptions to this rule: certain test code and top-level
-code where you want to catch all kinds of errors (to prevent them from showing
-up in a UI, or to keep a batch job running). In that case you may catch
-generic Exception (or Throwable) and handle the error appropriately. You
-should think very carefully before doing this, though, and put in comments
-explaining why it is safe in this place.</p>
+<p>Do not do this. In almost all cases it is inappropriate to catch generic
+Exception or Throwable (preferably not Throwable because it includes Error
+exceptions). It is very dangerous because it means that Exceptions
+you never expected (including RuntimeExceptions like ClassCastException) get
+caught in application-level error handling. It obscures the failure handling
+properties of your code, meaning if someone adds a new type of Exception in the
+code you're calling, the compiler won't help you realize you need to handle the
+error differently. In most cases you shouldn't be handling different types of
+exception the same way.</p>
+<p>The rare exception to this rule is test code and top-level code where you
+want to catch all kinds of errors (to prevent them from showing up in a UI, or
+to keep a batch job running). In these cases you may catch generic Exception
+(or Throwable) and handle the error appropriately. Think very carefully before
+doing this, though, and put in comments explaining why it is safe in this place.</p>
<p>Alternatives to catching generic Exception:</p>
<ul>
<li>
@@ -166,59 +162,58 @@
not catching an exception, don't scowl. Smile: the compiler just made it
easier for you to catch runtime problems in your code.</p>
<h3 id="dont-use-finalizers">Don't Use Finalizers</h3>
-<p>Finalizers are a way to have a chunk of code executed
-when an object is garbage collected.</p>
-<p>Pros: can be handy for doing cleanup, particularly of external resources.</p>
-<p>Cons: there are no guarantees as to when a finalizer will be called,
-or even that it will be called at all.</p>
-<p>Decision: we don't use finalizers. In most cases, you can do what
+<p>Finalizers are a way to have a chunk of code executed when an object is
+garbage collected. While they can be handy for doing cleanup (particularly of
+external resources, there are no guarantees as to when a finalizer will be
+called (or even that it will be called at all).</p>
+<p>Android doesn't use finalizers. In most cases, you can do what
you need from a finalizer with good exception handling. If you absolutely need
it, define a close() method (or the like) and document exactly when that
-method needs to be called. See InputStream for an example. In this case it is
+method needs to be called (see InputStream for an example). In this case it is
appropriate but not required to print a short log message from the finalizer,
as long as it is not expected to flood the logs.</p>
+
<h3 id="fully-qualify-imports">Fully Qualify Imports</h3>
<p>When you want to use class Bar from package foo,there
are two possible ways to import it:</p>
-<ol>
-<li><code>import foo.*;</code></li>
-</ol>
-<p>Pros: Potentially reduces the number of import statements.</p>
-<ol>
-<li><code>import foo.Bar;</code></li>
-</ol>
-<p>Pros: Makes it obvious what classes are actually used. Makes
-code more readable for maintainers. </p>
-<p>Decision: Use the latter for importing all Android code. An explicit
-exception is made for java standard libraries (<code>java.util.*</code>, <code>java.io.*</code>, etc.)
-and unit test code (<code>junit.framework.*</code>)</p>
+<ul>
+<li><code>import foo.*;</code>
+<p>Potentially reduces the number of import statements.</p></li>
+<li><code>import foo.Bar;</code>
+<p>Makes it obvious what classes are actually used and the code is more readable
+for maintainers.</p></li></ul>
+<p>Use <code>import foo.Bar;</code> for importing all Android code. An explicit
+exception is made for java standard libraries (<code>java.util.*</code>,
+<code>java.io.*</code>, etc.) and unit test code
+(<code>junit.framework.*</code>).</p>
+
<h2 id="java-library-rules">Java Library Rules</h2>
<p>There are conventions for using Android's Java libraries and tools. In some
cases, the convention has changed in important ways and older code might use a
deprecated pattern or library. When working with such code, it's okay to
-continue the existing style. When creating new components never use deprecated
-libraries.</p>
+continue the existing style. When creating new components however, never use
+deprecated libraries.</p>
<h2 id="java-style-rules">Java Style Rules</h2>
<h3 id="use-javadoc-standard-comments">Use Javadoc Standard Comments</h3>
-<p>Every file should have a copyright statement at the top. Then a package
-statement and import statements should follow, each block separated by a blank
-line. And then there is the class or interface declaration. In the Javadoc
-comments, describe what the class or interface does.</p>
+<p>Every file should have a copyright statement at the top, followed by package
+and import statements (each block separated by a blank line) and finally the
+class or interface declaration. In the Javadoc comments, describe what the class
+or interface does.</p>
<pre><code>/*
- * Copyright (C) 2013 The Android Open Source Project
+ * Copyright (C) 2015 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
+ * 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
+ * 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
+ * See the License for the specific language governing permissions and
* limitations under the License.
*/
@@ -240,7 +235,7 @@
</code></pre>
<p>Every class and nontrivial public method you write <em>must</em> contain a
Javadoc comment with at least one sentence describing what the class or method
-does. This sentence should start with a 3rd person descriptive verb.</p>
+does. This sentence should start with a third person descriptive verb.</p>
<p>Examples:</p>
<pre><code>/** Returns the correctly rounded positive square root of a double value. */
static double sqrt(double a) {
@@ -249,7 +244,7 @@
</code></pre>
<p>or</p>
<pre><code>/**
- * Constructs a new String by converting the specified array of
+ * Constructs a new String by converting the specified array of
* bytes using the platform's default character encoding.
*/
public String(byte[] bytes) {
@@ -257,40 +252,42 @@
}
</code></pre>
<p>You do not need to write Javadoc for trivial get and set methods such as
-<code>setFoo()</code> if all your Javadoc would say is "sets Foo". If the method does
-something more complex (such as enforcing a constraint or having an important
-side effect), then you must document it. And if it's not obvious what the
-property "Foo" means, you should document it.</p>
-<p>Every method you write, whether public or otherwise, would benefit from
-Javadoc. Public methods are part of an API and therefore require Javadoc.</p>
-<p>Android does not currently enforce a specific style for writing Javadoc
-comments, but you should follow the instructions <a
+<code>setFoo()</code> if all your Javadoc would say is "sets Foo". If the method
+does something more complex (such as enforcing a constraint or has an important
+side effect), then you must document it. If it's not obvious what the property
+"Foo" means, you should document it.
+<p>Every method you write, public or otherwise, would benefit from Javadoc.
+Public methods are part of an API and therefore require Javadoc. Android does
+not currently enforce a specific style for writing Javadoc comments, but you
+should follow the instructions <a
href="http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html">How
to Write Doc Comments for the Javadoc Tool</a>.</p>
<h3 id="write-short-methods">Write Short Methods</h3>
-<p>To the extent that it is feasible, methods should be kept small and
-focused. It is, however, recognized that long methods are sometimes
-appropriate, so no hard limit is placed on method length. If a method exceeds
-40 lines or so, think about whether it can be broken up without harming the
-structure of the program.</p>
+<p>When feasible, keep methods small and focused. We recognize that long methods
+are sometimes appropriate, so no hard limit is placed on method length. If a
+method exceeds 40 lines or so, think about whether it can be broken up without
+harming the structure of the program.</p>
+
<h3 id="define-fields-in-standard-places">Define Fields in Standard Places</h3>
-<p>Fields should be defined either at the top of the file, or immediately before the methods that use them.</p>
+<p>Define fields either at the top of the file or immediately before the
+methods that use them.</p>
+
<h3 id="limit-variable-scope">Limit Variable Scope</h3>
-<p>The scope of local variables should be kept to a minimum. By doing so, you increase the readability and
-maintainability of your code and reduce the likelihood of error. Each variable
-should be declared in the innermost block that encloses all uses of the
-variable.</p>
+<p>Keep the scope of local variables to a minimum. By doing so, you
+increase the readability and maintainability of your code and reduce the
+likelihood of error. Each variable should be declared in the innermost block
+that encloses all uses of the variable.</p>
<p>Local variables should be declared at the point they are first used. Nearly
every local variable declaration should contain an initializer. If you don't
-yet have enough information to initialize a variable sensibly, you should
-postpone the declaration until you do.</p>
-<p>One exception to this rule concerns try-catch statements. If a variable is
-initialized with the return value of a method that throws a checked exception,
-it must be initialized inside a try block. If the value must be used outside
-of the try block, then it must be declared before the try block, where it
-cannot yet be sensibly initialized:</p>
-<pre><code>// Instantiate class cl, which represents some sort of Set
+yet have enough information to initialize a variable sensibly, postpone the
+declaration until you do.</p>
+<p>The exception is try-catch statements. If a variable is initialized with the
+return value of a method that throws a checked exception, it must be initialized
+inside a try block. If the value must be used outside of the try block, then it
+must be declared before the try block, where it cannot yet be sensibly
+initialized:</p>
+<pre><code>// Instantiate class cl, which represents some sort of Set
Set s = null;
try {
s = (Set) cl.newInstance();
@@ -300,12 +297,13 @@
throw new IllegalArgumentException(cl + " not instantiable");
}
-// Exercise the set
+// Exercise the set
s.addAll(Arrays.asList(args));
</code></pre>
-<p>But even this case can be avoided by encapsulating the try-catch block in a method:</p>
+<p>However, even this case can be avoided by encapsulating the try-catch block
+in a method:</p>
<pre><code>Set createSet(Class cl) {
- // Instantiate class cl, which represents some sort of Set
+ // Instantiate class cl, which represents some sort of Set
try {
return (Set) cl.newInstance();
} catch(IllegalAccessException e) {
@@ -317,7 +315,7 @@
...
-// Exercise the set
+// Exercise the set
Set s = createSet(cl);
s.addAll(Arrays.asList(args));
</code></pre>
@@ -332,6 +330,7 @@
doSomethingElse(i.next());
}
</code></pre>
+
<h3 id="order-import-statements">Order Import Statements</h3>
<p>The ordering of import statements is:</p>
<ol>
@@ -339,7 +338,8 @@
<p>Android imports</p>
</li>
<li>
-<p>Imports from third parties (<code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>)</p>
+<p>Imports from third parties (<code>com</code>, <code>junit</code>,
+<code>net</code>, <code>org</code>)</p>
</li>
<li>
<p><code>java</code> and <code>javax</code></p>
@@ -348,47 +348,51 @@
<p>To exactly match the IDE settings, the imports should be:</p>
<ul>
<li>
-<p>Alphabetical within each grouping, with capital letters before lower case letters (e.g. Z before a).</p>
+<p>Alphabetical within each grouping, with capital letters before lower case
+letters (e.g. Z before a).</p>
</li>
<li>
-<p>There should be a blank line between each major grouping (<code>android</code>, <code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>, <code>java</code>, <code>javax</code>).</p>
+<p>Separated by a blank line between each major grouping (<code>android</code>,
+<code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>,
+<code>java</code>, <code>javax</code>).</p>
</li>
</ul>
-<p>Originally there was no style requirement on the ordering. This meant that
-the IDE's were either always changing the ordering, or IDE developers had to
-disable the automatic import management features and maintain the imports by
-hand. This was deemed bad. When java-style was asked, the preferred styles
-were all over the map. It pretty much came down to our needing to "pick an
-ordering and be consistent." So we chose a style, updated the style guide, and
-made the IDEs obey it. We expect that as IDE users work on the code, the
-imports in all of the packages will end up matching this pattern without any
-extra engineering effort.</p>
+<p>Originally, there was no style requirement on the ordering, meaning IDEs were
+either always changing the ordering or IDE developers had to disable the
+automatic import management features and manually maintain the imports. This was
+deemed bad. When java-style was asked, the preferred styles varied wildly and it
+came down to Android needing to simply "pick an ordering and be consistent." So
+we chose a style, updated the style guide, and made the IDEs obey it. We expect
+that as IDE users work on the code, imports in all packages will match this
+pattern without extra engineering effort.</p>
<p>This style was chosen such that:</p>
<ul>
<li>
-<p>The imports people want to look at first tend to be at the top (<code>android</code>)</p>
+<p>The imports people want to look at first tend to be at the top
+(<code>android</code>).</p>
</li>
<li>
-<p>The imports people want to look at least tend to be at the bottom (<code>java</code>)</p>
+<p>The imports people want to look at least tend to be at the bottom
+(<code>java</code>).</p>
</li>
<li>
-<p>Humans can easily follow the style</p>
+<p>Humans can easily follow the style.</p>
</li>
<li>
-<p>IDEs can follow the style</p>
+<p>IDEs can follow the style.</p>
</li>
</ul>
<p>The use and location of static imports have been mildly controversial
-issues. Some people would prefer static imports to be interspersed with the
-remaining imports, some would prefer them reside above or below all other
-imports. Additionally, we have not yet come up with a way to make all IDEs use
-the same ordering.</p>
-<p>Since most people consider this a low priority issue, just use your
-judgement and please be consistent.</p>
+issues. Some people prefer static imports to be interspersed with the
+remaining imports, while some prefer them to reside above or below all
+other imports. Additionally, we have not yet determined how to make all IDEs use
+the same ordering. Since many consider this a low priority issue, just use your
+judgement and be consistent.</p>
+
<h3 id="use-spaces-for-indentation">Use Spaces for Indentation</h3>
-<p>We use 4 space indents for blocks. We never use tabs. When in doubt, be
-consistent with code around you.</p>
-<p>We use 8 space indents for line wraps, including function calls and
+<p>We use four (4) space indents for blocks and never tabs. When in doubt, be
+consistent with the surrounding code.</p>
+<p>We use eight (8) space indents for line wraps, including function calls and
assignments. For example, this is correct:</p>
<pre><code>Instrument i =
someLongExpression(that, wouldNotFit, on, one, line);
@@ -397,6 +401,7 @@
<pre><code>Instrument i =
someLongExpression(that, wouldNotFit, on, one, line);
</code></pre>
+
<h3 id="follow-field-naming-conventions">Follow Field Naming Conventions</h3>
<ul>
<li>
@@ -424,7 +429,7 @@
</code></pre>
<h3 id="use-standard-brace-style">Use Standard Brace Style</h3>
<p>Braces do not go on their own line; they go on the same line as the code
-before them. So:</p>
+before them:</p>
<pre><code>class MyClass {
int func() {
if (something) {
@@ -437,63 +442,63 @@
}
}
</code></pre>
-<p>We require braces around the statements for a conditional. Except, if the
+<p>We require braces around the statements for a conditional. Exception: If the
entire conditional (the condition and the body) fit on one line, you may (but
-are not obligated to) put it all on one line. That is, this is legal:</p>
+are not obligated to) put it all on one line. For example, this is acceptable:</p>
<pre><code>if (condition) {
- body();
+ body();
}
</code></pre>
-<p>and this is legal:</p>
+<p>and this is acceptable:</p>
<pre><code>if (condition) body();
</code></pre>
-<p>but this is still illegal:</p>
+<p>but this is not acceptable:</p>
<pre><code>if (condition)
body(); // bad!
</code></pre>
+
<h3 id="limit-line-length">Limit Line Length</h3>
-<p>Each line of text in your code should be at most 100 characters long.</p>
-<p>There has been lots of discussion about this rule and the decision remains
-that 100 characters is the maximum.</p>
-<p>Exception: if a comment line contains an example command or a literal URL
+<p>Each line of text in your code should be at most 100 characters long. While
+much discussion has surrounded this rule, the decision remains that 100
+characters is the maximum <em>with the following exceptions</em>:</p>
+<ul>
+<li>If a comment line contains an example command or a literal URL
longer than 100 characters, that line may be longer than 100 characters for
-ease of cut and paste.</p>
-<p>Exception: import lines can go over the limit because humans rarely see
-them. This also simplifies tool writing.</p>
+ease of cut and paste.</li>
+<li>Import lines can go over the limit because humans rarely see them (this also
+simplifies tool writing).</li>
+</ul>
+
<h3 id="use-standard-java-annotations">Use Standard Java Annotations</h3>
<p>Annotations should precede other modifiers for the same language element.
Simple marker annotations (e.g. @Override) can be listed on the same line with
the language element. If there are multiple annotations, or parameterized
annotations, they should each be listed one-per-line in alphabetical
-order.<</p>
+order.</p>
<p>Android standard practices for the three predefined annotations in Java are:</p>
<ul>
-<li>
-<p><code>@Deprecated</code>: The @Deprecated annotation must be used whenever the use of the annotated
-element is discouraged. If you use the @Deprecated annotation, you must also
-have a @deprecated Javadoc tag and it should name an alternate implementation.
-In addition, remember that a @Deprecated method is <em>still supposed to
-work.</em></p>
-<p>If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.</p>
+<li><code>@Deprecated</code>: The @Deprecated annotation must be used whenever
+the use of the annotated element is discouraged. If you use the @Deprecated
+annotation, you must also have a @deprecated Javadoc tag and it should name an
+alternate implementation. In addition, remember that a @Deprecated method is
+<em>still supposed to work</em>. If you see old code that has a @deprecated
+Javadoc tag, please add the @Deprecated annotation.
</li>
-<li>
-<p><code>@Override</code>: The @Override annotation must be used whenever a method overrides the
-declaration or implementation from a super-class.</p>
-<p>For example, if you use the @inheritdocs Javadoc tag, and derive from a
-class (not an interface), you must also annotate that the method @Overrides
-the parent class's method.</p>
-</li>
-<li>
-<p><code>@SuppressWarnings</code>: The @SuppressWarnings annotation should only be used under circumstances
-where it is impossible to eliminate a warning. If a warning passes this
-"impossible to eliminate" test, the @SuppressWarnings annotation <em>must</em> be
-used, so as to ensure that all warnings reflect actual problems in the
-code.</p>
+<li><code>@Override</code>: The @Override annotation must be used whenever a
+method overrides the declaration or implementation from a super-class. For
+example, if you use the @inheritdocs Javadoc tag, and derive from a class (not
+an interface), you must also annotate that the method @Overrides the parent
+class's method.</li>
+<li><code>@SuppressWarnings</code>: The @SuppressWarnings annotation should be
+used only under circumstances where it is impossible to eliminate a warning. If
+a warning passes this "impossible to eliminate" test, the @SuppressWarnings
+annotation <em>must</em> be used, so as to ensure that all warnings reflect
+actual problems in the code.
<p>When a @SuppressWarnings annotation is necessary, it must be prefixed with
a TODO comment that explains the "impossible to eliminate" condition. This
will normally identify an offending class that has an awkward interface. For
example:</p>
-<pre><code>// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
+<pre><code>// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
@SuppressWarnings("generic-cast")
List<String> blix = Utility.rotate(blax);
</code></pre>
@@ -501,8 +506,10 @@
refactored to isolate the software elements where the annotation applies.</p>
</li>
</ul>
+
<h3 id="treat-acronyms-as-words">Treat Acronyms as Words</h3>
-<p>Treat acronyms and abbreviations as words in naming variables, methods, and classes. The names are much more readable:</p>
+<p>Treat acronyms and abbreviations as words in naming variables, methods, and
+classes to make names more readable:</p>
<table>
<thead>
<tr>
@@ -533,14 +540,14 @@
</tr>
</tbody>
</table>
-<p>Both the JDK and the Android code bases are very inconsistent with regards
-to acronyms, therefore, it is virtually impossible to be consistent with the
-code around you. Bite the bullet, and treat acronyms as words.</p>
+<p>As both the JDK and the Android code bases are very inconsistent around
+acronyms, it is virtually impossible to be consistent with the surrounding
+code. Therefore, always treat acronyms as words.</p>
<h3 id="use-todo-comments">Use TODO Comments</h3>
<p>Use TODO comments for code that is temporary, a short-term solution, or
-good-enough but not perfect.</p>
-<p>TODOs should include the string TODO in all caps, followed by a colon:</p>
+good-enough but not perfect. TODOs should include the string TODO in all caps,
+followed by a colon:</p>
<pre><code>// TODO: Remove this code after the UrlTable2 has been checked in.
</code></pre>
<p>and</p>
@@ -550,79 +557,67 @@
you either include a very specific date ("Fix by November 2005") or a very
specific event ("Remove this code after all production mixers understand
protocol V7.").</p>
+
<h3 id="log-sparingly">Log Sparingly</h3>
<p>While logging is necessary, it has a significantly negative impact on
-performance and quickly loses its usefulness if it's not kept reasonably
+performance and quickly loses its usefulness if not kept reasonably
terse. The logging facilities provides five different levels of logging:</p>
<ul>
-<li>
-<p><code>ERROR</code>:
-This level of logging should be used when something fatal has happened,
-i.e. something that will have user-visible consequences and won't be
-recoverable without explicitly deleting some data, uninstalling applications,
-wiping the data partitions or reflashing the entire phone (or worse). This
-level is always logged. Issues that justify some logging at the ERROR level
-are typically good candidates to be reported to a statistics-gathering
-server.</p>
+<li><code>ERROR</code>:
+Use when something fatal has happened, i.e. something will have user-visible
+consequences and won't be recoverable without explicitly deleting some data,
+uninstalling applications, wiping the data partitions or reflashing the entire
+device (or worse). This level is always logged. Issues that justify some logging
+at the ERROR level are typically good candidates to be reported to a
+statistics-gathering server.</li>
+<li><code>WARNING</code>:
+Use when something serious and unexpected happened, i.e. something that will
+have user-visible consequences but is likely to be recoverable without data loss
+by performing some explicit action, ranging from waiting or restarting an app
+all the way to re-downloading a new version of an application or rebooting the
+device. This level is always logged. Issues that justify some logging at the
+WARNING level might also be considered for reporting to a statistics-gathering
+server.</li>
+<li><code>INFORMATIVE:</code>
+Use note that something interesting to most people happened, i.e. when a
+situation is detected that is likely to have widespread impact, though isn't
+necessarily an error. Such a condition should only be logged by a module that
+reasonably believes that it is the most authoritative in that domain (to avoid
+duplicate logging by non-authoritative components). This level is always logged.
</li>
-<li>
-<p><code>WARNING</code>:
-This level of logging should used when something serious and unexpected
-happened, i.e. something that will have user-visible consequences but is
-likely to be recoverable without data loss by performing some explicit action,
-ranging from waiting or restarting an app all the way to re-downloading a new
-version of an application or rebooting the device. This level is always
-logged. Issues that justify some logging at the WARNING level might also be
-considered for reporting to a statistics-gathering server.</p>
-</li>
-<li>
-<p><code>INFORMATIVE:</code>
-This level of logging should used be to note that something interesting to
-most people happened, i.e. when a situation is detected that is likely to have
-widespread impact, though isn't necessarily an error. Such a condition should
-only be logged by a module that reasonably believes that it is the most
-authoritative in that domain (to avoid duplicate logging by non-authoritative
-components). This level is always logged.</p>
-</li>
-<li>
-<p><code>DEBUG</code>:
-This level of logging should be used to further note what is happening on the
-device that could be relevant to investigate and debug unexpected behaviors.
-You should log only what is needed to gather enough information about what is
-going on about your component. If your debug logs are dominating the log then
-you probably should be using verbose logging. </p>
-<p>This level will be logged, even
-on release builds, and is required to be surrounded by an <code>if (LOCAL_LOG)</code> or <code>if
-(LOCAL_LOGD)</code> block, where <code>LOCAL_LOG[D]</code> is defined in your class or
-subcomponent, so that there can exist a possibility to disable all such
-logging. There must therefore be no active logic in an <code>if (LOCAL_LOG)</code> block.
-All the string building for the log also needs to be placed inside the <code>if
+<li><code>DEBUG</code>:
+Use to further note what is happening on the device that could be relevant to
+investigate and debug unexpected behaviors. You should log only what is needed
+to gather enough information about what is going on about your component. If
+your debug logs are dominating the log then you probably should be using verbose
+logging.
+<p>This level will be logged, even on release builds, and is required to be
+surrounded by an <code>if (LOCAL_LOG)</code> or <code>if (LOCAL_LOGD)</code>
+block, where <code>LOCAL_LOG[D]</code> is defined in your class or subcomponent,
+so that there can exist a possibility to disable all such logging. There must
+therefore be no active logic in an <code>if (LOCAL_LOG)</code> block. All the
+string building for the log also needs to be placed inside the <code>if
(LOCAL_LOG)</code> block. The logging call should not be re-factored out into a
method call if it is going to cause the string building to take place outside
-of the <code>if (LOCAL_LOG)</code> block. </p>
-<p>There is some code that still says <code>if
-(localLOGV)</code>. This is considered acceptable as well, although the name is
-nonstandard.</p>
+of the <code>if (LOCAL_LOG)</code> block.</p>
+<p>There is some code that still says <code>if (localLOGV)</code>. This is
+considered acceptable as well, although the name is nonstandard.</p>
</li>
-<li>
-<p><code>VERBOSE</code>:
-This level of logging should be used for everything else. This level will only
-be logged on debug builds and should be surrounded by an <code>if (LOCAL_LOGV)</code> block
-(or equivalent) so that it can be compiled out by default. Any string building
-will be stripped out of release builds and needs to appear inside the <code>if (LOCAL_LOGV)</code> block.</p>
+<li><code>VERBOSE</code>:
+Use for everything else. This level will only be logged on debug builds and
+should be surrounded by an <code>if (LOCAL_LOGV)</code> block (or equivalent) so
+it can be compiled out by default. Any string building will be stripped out of
+release builds and needs to appear inside the <code>if (LOCAL_LOGV)</code> block.
</li>
</ul>
<p><em>Notes:</em> </p>
<ul>
-<li>
-<p>Within a given module, other than at the VERBOSE level, an
-error should only be reported once if possible: within a single chain of
+<li>Within a given module, other than at the VERBOSE level, an
+error should only be reported once if possible. Within a single chain of
function calls within a module, only the innermost function should return the
error, and callers in the same module should only add some logging if that
-significantly helps to isolate the issue.</p>
-</li>
-<li>
-<p>In a chain of modules, other than at the VERBOSE level, when a
+significantly helps to isolate the issue.</li>
+<li>In a chain of modules, other than at the VERBOSE level, when a
lower-level module detects invalid data coming from a higher-level module, the
lower-level module should only log this situation to the DEBUG log, and only
if logging provides information that is not otherwise available to the caller.
@@ -634,101 +629,76 @@
framework should not trigger logging higher than the DEBUG level. The only
situations that should trigger logging at the INFORMATIVE level or higher is
when a module or application detects an error at its own level or coming from
-a lower level.</p>
-</li>
-<li>
-<p>When a condition that would normally justify some logging is
+a lower level.</li>
+<li>When a condition that would normally justify some logging is
likely to occur many times, it can be a good idea to implement some
rate-limiting mechanism to prevent overflowing the logs with many duplicate
-copies of the same (or very similar) information.</p>
-</li>
-<li>
-<p>Losses of network connectivity are considered common and fully
-expected and should not be logged gratuitously. A loss of network connectivity
+copies of the same (or very similar) information.</li>
+<li>Losses of network connectivity are considered common, fully expected, and
+should not be logged gratuitously. A loss of network connectivity
that has consequences within an app should be logged at the DEBUG or VERBOSE
level (depending on whether the consequences are serious enough and unexpected
-enough to be logged in a release build).</p>
-</li>
-<li>
-<p>A full filesystem on a filesystem that is accessible to or on
+enough to be logged in a release build).</li>
+<li>A full filesystem on a filesystem that is accessible to or on
behalf of third-party applications should not be logged at a level higher than
-INFORMATIVE.</p>
-</li>
-<li>
-<p>Invalid data coming from any untrusted source (including any
+INFORMATIVE.</li>
+<li>Invalid data coming from any untrusted source (including any
file on shared storage, or data coming through just about any network
connections) is considered expected and should not trigger any logging at a
level higher then DEBUG when it's detected to be invalid (and even then
-logging should be as limited as possible).</p>
-</li>
-<li>
-<p>Keep in mind that the <code>+</code> operator, when used on Strings,
+logging should be as limited as possible).</li>
+<li>Keep in mind that the <code>+</code> operator, when used on Strings,
implicitly creates a <code>StringBuilder</code> with the default buffer size (16
-characters) and potentially quite a few other temporary String objects, i.e.
+characters) and potentially other temporary String objects, i.e.
that explicitly creating StringBuilders isn't more expensive than relying on
-the default '+' operator (and can be a lot more efficient in fact). Also keep
-in mind that code that calls <code>Log.v()</code> is compiled and executed on release
-builds, including building the strings, even if the logs aren't being
-read.</p>
-</li>
-<li>
-<p>Any logging that is meant to be read by other people and to be
+the default '+' operator (and can be a lot more efficient in fact). Keep
+in mind that code that calls <code>Log.v()</code> is compiled and executed on
+release builds, including building the strings, even if the logs aren't being
+read.</li>
+<li>Any logging that is meant to be read by other people and to be
available in release builds should be terse without being cryptic, and should
be reasonably understandable. This includes all logging up to the DEBUG
-level.</p>
-</li>
-<li>
-<p>When possible, logging should be kept on a single line if it
+level.</li>
+<li>When possible, logging should be kept on a single line if it
makes sense. Line lengths up to 80 or 100 characters are perfectly acceptable,
while lengths longer than about 130 or 160 characters (including the length of
-the tag) should be avoided if possible.</p>
-</li>
-<li>
-<p>Logging that reports successes should never be used at levels
-higher than VERBOSE.</p>
-</li>
-<li>
-<p>Temporary logging that is used to diagnose an issue that's
-hard to reproduce should be kept at the DEBUG or VERBOSE level, and should be
-enclosed by if blocks that allow to disable it entirely at compile-time.</p>
-</li>
-<li>
-<p>Be careful about security leaks through the log. Private
+the tag) should be avoided if possible.</li>
+<li>Logging that reports successes should never be used at levels
+higher than VERBOSE.</li>
+<li>Temporary logging used to diagnose an issue that is hard to reproduce should
+be kept at the DEBUG or VERBOSE level and should be enclosed by if blocks that
+allow for disabling it entirely at compile time.</li>
+<li>Be careful about security leaks through the log. Private
information should be avoided. Information about protected content must
definitely be avoided. This is especially important when writing framework
code as it's not easy to know in advance what will and will not be private
-information or protected content.</p>
-</li>
-<li>
-<p><code>System.out.println()</code> (or <code>printf()</code> for native code) should
-never be used. System.out and System.err get redirected to /dev/null, so your
-print statements will have no visible effects. However, all the string
-building that happens for these calls still gets executed.</p>
-</li>
-<li>
-<p><em>The golden rule of logging is that your logs may not
+information or protected content.</li>
+<li><code>System.out.println()</code> (or <code>printf()</code> for native code)
+should never be used. System.out and System.err get redirected to /dev/null, so
+your print statements will have no visible effects. However, all the string
+building that happens for these calls still gets executed.</li>
+<li><em>The golden rule of logging is that your logs may not
unnecessarily push other logs out of the buffer, just as others may not push
-out yours.</em></p>
-</li>
+out yours.</em></li>
</ul>
+
<h3 id="be-consistent">Be Consistent</h3>
<p>Our parting thought: BE CONSISTENT. If you're editing code, take a few
-minutes to look at the code around you and determine its style. If they use
-spaces around their if clauses, you should too. If their comments have little
-boxes of stars around them, make your comments have little boxes of stars
+minutes to look at the surrounding code and determine its style. If that code
+uses spaces around the if clauses, you should too. If the code comments have
+little boxes of stars around them, make your comments have little boxes of stars
around them too.</p>
<p>The point of having style guidelines is to have a common vocabulary of
coding, so people can concentrate on what you're saying, rather than on how
you're saying it. We present global style rules here so people know the
-vocabulary. But local style is also important. If code you add to a a file
+vocabulary, but local style is also important. If the code you add to a file
looks drastically different from the existing code around it, it throws
-readers out of their rhythm when they go to read it. Try to avoid this.</p></p>
+readers out of their rhythm when they go to read it. Try to avoid this.</p>
+
<h2 id="javatests-style-rules">Javatests Style Rules</h2>
-<h3 id="follow-test-method-naming-conventions">Follow Test Method Naming Conventions</h3>
-<p>When naming test methods, you can use an underscore to separate what is
-being tested from the specific case being tested. This style makes it easier
-to see exactly what cases are being tested.</p>
-<p>For example:</p>
+<p>Follow test method naming conventions and use an underscore to separate what
+is being tested from the specific case being tested. This style makes it easier
+to see exactly what cases are being tested. For example:</p>
<pre><code>testMethod_specificCase1 testMethod_specificCase2
void testIsDistinguishable_protanopia() {
@@ -736,4 +706,4 @@
assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
}
-</code></pre>
+</code></pre>
\ No newline at end of file
diff --git a/src/source/community.jd b/src/source/community.jd
index 663da64..9c4a95d 100644
--- a/src/source/community.jd
+++ b/src/source/community.jd
@@ -108,7 +108,8 @@
<h5>Developer resources</h5>
<a href="http://developer.android.com/">Developer.android.com</a><br>
<a href="http://developer.android.com/support.html">Developer support</a><br>
-<a href="http://android-developers.blogspot.com/">Android developers blog</a>
+<a href="http://android-developers.blogspot.com/">Android developers blog</a><br>
+<a href="https://developers.google.com/groups/">Google Developer Groups (GDGs)</a>
<p></p>
<h5>Training</h5>
diff --git a/src/source/source_toc.cs b/src/source/source_toc.cs
index d0e1c68..66b5177 100644
--- a/src/source/source_toc.cs
+++ b/src/source/source_toc.cs
@@ -73,7 +73,7 @@
<li><a href="http://android-review.googlesource.com">View Patches</a></li>
<li><a href="<?cs var:toroot ?>source/life-of-a-bug.html">Life of a Bug</a></li>
<li><a href="<?cs var:toroot ?>source/report-bugs.html">Reporting Bugs</a></li>
- <li><a href="<?cs var:toroot ?>source/code-style.html">Code Style Guidelines</a></li>
+ <li><a href="<?cs var:toroot ?>source/code-style.html">Code Style Rules</a></li>
</ul>
</li>
