diff --git a/src/compatibility/5.1/android-5.1-cdd.html b/src/compatibility/5.1/android-5.1-cdd.html
index 9b9ff55..f6c4872 100644
--- a/src/compatibility/5.1/android-5.1-cdd.html
+++ b/src/compatibility/5.1/android-5.1-cdd.html
@@ -161,7 +161,7 @@
 
 </div>
 
-<div style="clear: both; page-break-after:always; height:1px"></div>
+<div style="clear: both; page-break-after:always; height:15px"></div>
 
 
 <div id="toc_left_2">
diff --git a/src/compatibility/5.1/android-5.1-cdd.pdf b/src/compatibility/5.1/android-5.1-cdd.pdf
index 78a9857..483f25a 100644
--- a/src/compatibility/5.1/android-5.1-cdd.pdf
+++ b/src/compatibility/5.1/android-5.1-cdd.pdf
Binary files differ
diff --git a/src/compatibility/5.1/android-cdd-body.pdf b/src/compatibility/5.1/android-cdd-body.pdf
index df0552d..37402d3 100644
--- a/src/compatibility/5.1/android-cdd-body.pdf
+++ b/src/compatibility/5.1/android-cdd-body.pdf
Binary files differ
diff --git a/src/compatibility/5.1/android-cdd-cover.css b/src/compatibility/5.1/android-cdd-cover.css
index 7364deb..dcbcc2f 100644
--- a/src/compatibility/5.1/android-cdd-cover.css
+++ b/src/compatibility/5.1/android-cdd-cover.css
@@ -58,7 +58,7 @@
 }
 
 .padding-bottom {
-    padding: 40px 20px 194px 60px;
+    padding: 40px 20px 200px 60px;
 }
 
 .cover-text {
diff --git a/src/compatibility/5.1/android-cdd-cover.pdf b/src/compatibility/5.1/android-cdd-cover.pdf
index 90f12e9..f1e2169 100644
--- a/src/compatibility/5.1/android-cdd-cover.pdf
+++ b/src/compatibility/5.1/android-cdd-cover.pdf
Binary files differ
diff --git a/src/compatibility/5.1/android-cdd-cover_5_1.html b/src/compatibility/5.1/android-cdd-cover_5_1.html
index 25eaefe..a59caf9 100644
--- a/src/compatibility/5.1/android-cdd-cover_5_1.html
+++ b/src/compatibility/5.1/android-cdd-cover_5_1.html
@@ -17,14 +17,14 @@
 
 <tr>
 <td>
-<img src="../images/android-lollipop-mr1.jpg" alt="Lollipop logo" style="border-top: 5px solid orange; border-bottom: 5px solid orange"/>
+<img src="../images/android-lollipop.jpg" alt="Lollipop logo" style="border-top: 5px solid orange; border-bottom: 5px solid orange"/>
 </td>
 </tr>
 
 <tr>
 <td>
 <p class="subtitle">Android 5.1</p>
-<p class="cover-text">Last updated: June 9th, 2015</p>
+<p class="cover-text">Last updated: April 1, 2015</p>
 <p class="cover-text">Copyright &copy; 2015, Google Inc. All rights reserved.</p>
 <p class="cover-text"><a href="mailto:compatibility@android.com">compatibility@android.com</a></p>
 </td>
diff --git a/src/compatibility/android-cdd.pdf b/src/compatibility/android-cdd.pdf
index 78a9857..f29d081 100644
--- a/src/compatibility/android-cdd.pdf
+++ b/src/compatibility/android-cdd.pdf
Binary files differ
diff --git a/src/compatibility/images/android-lollipop-mr1.jpg b/src/compatibility/images/android-lollipop-mr1.jpg
deleted file mode 100644
index c9b757d..0000000
--- a/src/compatibility/images/android-lollipop-mr1.jpg
+++ /dev/null
Binary files differ
diff --git a/src/devices/tech/security/overview/updates-resources.jd b/src/devices/tech/security/overview/updates-resources.jd
index d6b1cb6..5fc3095 100644
--- a/src/devices/tech/security/overview/updates-resources.jd
+++ b/src/devices/tech/security/overview/updates-resources.jd
@@ -2,7 +2,7 @@
 @jd:body
 
 <!--
-    Copyright 2015 The Android Open Source Project
+    Copyright 2014 The Android Open Source Project
 
     Licensed under the Apache License, Version 2.0 (the "License");
     you may not use this file except in compliance with the License.
@@ -23,239 +23,65 @@
   </div>
 </div>
 
-<h2 id=android_security_bug_lifecycle>Android security bug lifecycle</h2>
-
-<p>The Android security team is responsible for managing security vulnerabilities
-discovered in the Android platform and many of the core Android apps bundled
-with Android devices.</p>
-
-<p>The Android security team finds security vulnerabilities through internal
-research and also responds to bugs reported by third parties. Sources of
-external bugs include issues reported through the <a
-href="https://code.google.com/p/android/issues/list">Android Open Source
-Project (AOSP) bug tracker</a>, published and pre-published academic research,
-upstream open source project maintainers, notifications from our device
-manufacturer partners, and publicly disclosed issues posted on blogs or social
-media.</p>
-
-<h2 id=report-issues>Reporting security issues</h2>
-
+<h2 id="reporting-security-issues">Reporting Security Issues</h2>
+<p class="note"><strong>Note:</strong> The preferred way to report security
+issues is sending an email detailing the issue to security@android.com.</p>
 <p>Any developer, Android user, or security researcher can notify the Android
-security team of potential security issues through the AOSP bug tracker <a
-href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security
-bug report</a> template.</p>
+security team of potential security issues. Your message can be encrypted
+using the Android security team PGP key <a href="https://developer.android.com/security_at_android_dot_com.txt">here</a>.</p> 
+<p>Sending an email to security@android.com is preferable to using the
+public Android bug tracker. Bugs marked as security issues are not externally
+visible, but they may eventually be made visible. If you plan to submit a
+patch to resolve a security issue, please contact security@android.com and
+wait for a response before submitting the patch to AOSP.</p>
 
-<p>Bugs marked as security issues are not externally visible, but they may
-eventually be made visible after the issue is evaluated or resolved. If you
-plan to submit a patch or Compatibility Test Suite (CTS) test to resolve a
-security issue, please attach it to the bug report and wait for a response
-before uploading the code to AOSP.</p>
-
-<p>If you need to reach the Android security team for a purpose other than
-reporting a vulnerability, please contact <a
-href="mailto:security@android.com">security@android.com</a>. The Android
-security team has a <a
-href="https://developer.android.com/security_at_android_dot_com.txt">PGP
-key</a> if you need to encrypt your message.</p>
-
-<h2 id=triaging_bugs>Triaging bugs</h2>
-
-<p>The first task in handling a security vulnerability is to identify the severity
-of the bug and which component of Android is affected. The severity determines
-how the issue is prioritized, and the component determines who fixes the bug,
-who is notified, and how the fix gets deployed to users.</p>
-
-<h3 id=severity>Severity</h3>
-
-<p>The severity of a bug generally reflects the potential harm that could occur if
-a bug was successfully exploited. Use the following criteria to determine the
-severity:</p>
-<p class="table-caption" id="severity-criteria">
-  <strong>Table 1.</strong> Severity ratings and associated consequences</p>
-<table>
- <tr>
-    <th>Rating</th>
-    <th>Consequence of successful exploitation</th>
- </tr>
- <tr>
-    <td><strong>Critical</strong></td>
-    <td>
-<ul>
-<li>Remote privileged code execution (execution at a privilege level that
-third-party apps cannot obtain)
-<li>Local permanent device compromise (device cannot be repaired without
-re-flashing the entire operating system, such as a  verified boot or Trusted
-Execution Environment/TEE compromise)
-<li>Remote permanent denial of service (inoperability, either completely permanent
-or requiring re-flashing the device)
-</ul>
-</td>
- </tr>
- <tr>
-    <td><strong>High</strong></td>
-    <td>
-<ul>
-<li>Remote unprivileged code execution (execution at a privilege level that
-third-party apps can obtain through installation)
-<li>Local access to system/signature-level permission data or capabilities without
-permission
-<li>Local permanent denial-of-service (inoperability, either completely permanent
-or requiring re-flashing the device)
-<li>Remote temporary denial-of-service (remote hang or reboot)
-</ul>
-</td>
- </tr>
- <tr>
-    <td><strong>Moderate</strong></td>
-    <td>
-<ul>
-<li>Access to "<a
-href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">dangerous</a>"
-level permission data or capabilities without permission with an app installed
-on the device
-<li>Local temporary denial-of-service (can be resolved only through a factory
-reset)
-</ul>
-</td>
- </tr>
- <tr>
-    <td><strong>Low</strong></td>
-    <td>
-<ul>
-<li>Access to "<a
-href="http://developer.android.com/guide/topics/manifest/permission-element.html#plevel">normal</a>"
-level permission capabilities without permission with an app installed on the
-device
-<li>Local temporary denial-of-service (can be resolved by booting the device into
-Safe Mode and removing the problem application)
-</ul>
-</td>
- </tr>
-</table>
-
-<p>Though there are many types of software bugs outside of the security
-vulnerabilities detailed above, bugs reported are evaluated on a
-case-by-base basis to determine what security impact they have.</p>
-
-<p>The Android security team may also adjust the severity of a vulnerability if it
-is determined the risk to users is higher or lower than the guidelines suggest.
-For example, if a certain piece of data is available only to apps with "system"
-level access but the data itself is not sensitive, the Android security
-team may consider it only a low-severity vulnerability.</p>
-
-<h4 id=local_vs_remote>Local vs. remote</h4>
-
-<p>A remote attack vector indicates the bug could be exploited without installing
-an app or without physical access to the device. This includes bugs that could
-be triggered by browsing to a web page, reading an email, receiving an SMS
-message, or connecting to a hostile network. For the purpose of our severity
-ratings, the Android security team also considers "proximal" attack vectors as
-remote. These include bugs that can be exploited only by an attacker who is
-physically near the target device, for example a bug that requires sending
-malformed Wi-Fi or Bluetooth packets.</p>
-
-<p>Local attacks require the victim to install an app. For the purpose of severity
-ratings, the Android security team also considers physical attack vectors as
-local. These include bugs that can be exploited only by an attacker who has
-physical access to the device, for example a bug in a lock screen or one that
-requires plugging in a USB cable. The Android security team also considers
-NFC-based attacks as local.</p>
-
-<h4 id=high_privilege_levels>Severity of vulnerabilities that affect high privilege levels</h4>
-
-<p>The Android security team will usually drop the severity rating for a bug that
-already requires executing code at a high privilege level. For example, a bug
-in a kernel driver accessible only from a privileged service that
-requires first compromising the service. In this case, the Android security
-team may drop the severity from "high" to "moderate."</p>
-
-<h4 id=severity_of_kernel_compromises>Severity of kernel compromises</h4>
-
-<p>Whether a vulnerability that compromises the kernel is considered "high" or
-"critical" depends on the device and the version of Android. On devices with a
-TEE (or TrustZone) and <a
-href="http://source.android.com/devices/tech/security/verifiedboot/index.html">verified
-boot</a>, a kernel compromise is considered "high" because exploiting it won't
-allow permanently affecting the operation of the device unless a vulnerability is
-discovered in the TEE or verified boot implementation. In general, if the
-result of a compromise can be remediated with a factory reset, it's "high" or
-lower.</p>
-
-<p>However, on older devices without verified boot, a kernel compromise can result
-in permanent device compromise if SELinux is disabled and the system partition
-is modified. On that device, a kernel compromise is considered "critical"
-because remediation requires re-flashing the device's firmware image.</p>
-
-<h3 id=affected_component>Affected component</h3>
-
-<p>The development team responsible for fixing the bug depends on which component
-the bug is in. It could be a core component of the Android platform, a kernel
-driver supplied by an original equipment manufacturer (OEM), or one of the
-pre-loaded apps on Nexus devices.</p>
-
-<p>Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs,
-bugs in certain components, or bugs that are already publicly known may be
-fixed directly in the publicly available AOSP master branch; otherwise they're
-fixed in our internal repositories first.</p>
-
-<p>The component is also a factor in how users get updates. A bug in the framework
-or kernel will require an over-the-air (OTA) firmware update that each OEM will
-need to push. A bug in an app or library published in Google Play (e.g., Gmail,
-Google Play Services, WebView in Lollipop and later versions) can be sent to
-Android users as an update from Google Play. </p>
-
-<h2 id=notifying_partners>Notifying partners</h2>
-
-<p>When a moderate or higher severity security vulnerability in AOSP is fixed,
-we'll notify <a href="http://www.openhandsetalliance.com/">Open Handset
-Alliance</a> members with the details of the issue and provide patches for the
-most recent three Android releases. The Android security team currently
-provides patches for Android versions 4.4 (KitKat), 5.0 (Lollipop), and 5.1
-(Lollipop MR1). This list of backport-supported versions changes with each new
-Android release.</p>
-
-<h2 id=releasing_code_to_aosp>Releasing code to AOSP</h2>
-
-<p>If the security bug is in an AOSP component, the fix will be pushed out to AOSP
-after the OTA is released to users. Fixes for low-severity issues may be
-submitted directly to the AOSP master branch before a fix is available.</p>
-
-<h2 id=android_updates>Receiving Android updates</h2>
-
-<p>Updates to the Android system are generally delivered to devices through
-OTA update packages. These updates may come from the OEM who
-produced the device or the carrier who provides service to the device. Google
-Nexus device updates come from the Google Nexus team after going through a
-carrier technical acceptance (TA) testing procedure. Google also publishes <a
-href="https://developers.google.com/android/nexus/images">Nexus factory
-images</a> that can be side-loaded to devices.</p>
-
-<h2 id=updating_google_services>Updating Google services</h2>
-
-<p>In addition to providing patches for security bugs, the Android security team
-also review security bugs to determine if there are other ways to protect
-users. For example, Google Play scans all applications and will remove any
-application that attempts to exploit a security bug. For applications installed
-from outside of Google Play, devices with Google Play Services may also use the
-<a href="https://support.google.com/accounts/answer/2812853">Verify Apps</a>
-feature to warn users about applications that may be potentially harmful.</p>
-
-<h2 id=other_resources>Other resources</h2>
-
-<p>Information for Android application developers: <a
-href="https://developer.android.com">https://developer.android.com</a></p>
-
-<p>The Android security team can be reached at <a
-href="mailto:security@android.com">security@android.com</a>. Our PGP key: <a
-href="https://developer.android.com/security_at_android_dot_com.txt">https://developer.android.com/security_at_android_dot_com.txt</a></p>
-
+<h2 id="android-updates">Android Updates</h2>
+<p>Android provides system updates for both security and feature related purposes.</p>
+<p>There are two ways to update the code on most Android devices: over-the-air
+  (OTA updates) or side-loaded updates. OTA updates can be rolled out over a
+  defined time period or be pushed to all devices at once, depending on how the
+  OEM and/or carrier would like to push the updates. Side-loaded updates can be
+  provided from a central location for users to download as a zip file to their
+  local desktop machine or directly to their handset. Once the update is copied
+  or downloaded to the SD card on the device, Android will recognize the update,
+  verify its integrity and authenticity, and automatically update the device.</p>
+<p>If a dangerous vulnerability is discovered internally or responsibly reported
+  to Google or the Android Open Source Project, the Android security team will
+  start the following process.</p>
+<ol>
+  <li>The Android team will notify companies who have signed NDAs regarding the
+    problem and begin discussing the solution.</li>
+  <li>The owners of code will begin the fix.</li>
+  <li>The Android team will fix Android-related security issues.</li>
+  <li>When a patch is available, the fix is provided to the NDA companies.</li>
+  <li>The Android team will publish the patch in the Android Open Source Project</li>
+  <li>OEM/carrier will push an update to customers.</li>
+</ol>
+<p>The NDA is required to ensure that the security issue does not become public
+  prior to availabilty of a fix and put users at risk. Many OHA members run their
+  own code on Android devices such as the bootloader, wifi drivers, and the
+  radio. Once the Android Security team is notified of a security issue in this
+  partner code, they will consult with OHA partners to quickly find a fix for the
+  problem at hand and similar problems. However, the OHA member who wrote the
+  faulty code is ultimately responsible for fixing the problem.</p>
+<p>If a dangerous vulnerability is not responsibly disclosed (e.g., if it is
+  posted to a public forum without warning), then Google and/or the Android Open
+  Source Project will work as quickly as possible to create a patch. The patch
+  will released to the public (and any partners) when the patch is tested and
+  ready for use.</p>
+<p>At Google I/O 2011, many of the largest OHA partners committed to providing
+  updates to devices for 18 months after initial shipment. This will provide
+  users with access to the most recent Android features, as well as security
+  updates.</p>
+<p>Any developer, Android user, or security researcher can notify the Android
+  security team of potential security issues by sending email to
+  security@android.com. If desired, communication can be encrypted using the
+  Android security team PGP key available here: <a href="https://developer.android.com/security_at_android_dot_com.txt">https://developer.android.com/security_at_android_dot_com.txt</a>.</p>
+<h2 id="other-resources">Other Resources</h2>
+<p>Information for Android application developers is here: <a href="https://developer.android.com">https://developer.android.com</a>.</p>
+<p>The Android Security team can be reached at <a href="mailto:security@android.com">security@android.com</a>.</p>
 <p>Security information exists throughout the Android Open Source and Developer
-sites. Good places to start:<br>
-<a href="http://source.android.com/devices/tech/security/index.html">http://source.android.com/devices/tech/security/index.html</a><br>
-<a href="https://developer.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a></p>
-
-<p>Security best practices for developers: <a
-href="https://developer.android.com/guide/practices/security.html">https://developer.android.com/guide/practices/security.html</a>.</p>
-
-<p>Community resource for discussion about Android security: <a
-href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a></p>
+  Sites. A good place to start is here: <a href="https://developer.android.com/guide/topics/security/security.html">https://developer.android.com/guide/topics/security/security.html</a>.</p>
+<p>A Security FAQ for developers is located here: <a href="https://developer.android.com/resources/faq/security.html">https://developer.android.com/resources/faq/security.html</a>.</p>
+<p>Security Best Practices for developers is located here: <a href="https://developer.android.com/guide/practices/security.html">https://developer.android.com/guide/practices/security.html</a>.</p>
+<p>A community resource for discussion about Android security exists here: <a href="https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss">https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss</a>.</p>