diff --git a/src/devices/automotive.jd b/src/devices/automotive.jd
new file mode 100644
index 0000000..cfcccc9
--- /dev/null
+++ b/src/devices/automotive.jd
@@ -0,0 +1,293 @@
+page.title=Automotive
+@jd:body
+
+<!--
+    Copyright 2016 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>
+
+<img style="float: right; margin: 0px 15px 15px 15px;"
+src="images/ape_fwk_hal_vehicle.png" alt="Android vehicle HAL icon"/>
+
+<p>Many car subsystems interconnect with each other and the in-vehicle
+infotainment (IVI) system via various bus topologies. The exact bus type and
+protocols vary widely between manufacturers (and even between different vehicle
+models of the same brand); examples include Controller Area Network (CAN) bus,
+Local Interconnect Network (LIN) bus, Media Oriented Systems Transport (MOST),
+as well as automotive-grade Ethernet and TCP/IP networks such as BroadR-Reach.
+</p>
+<p>Android Automotive has a hardware abstraction layer (HAL) that provides a
+consistent interface to the Android framework regardless of physical transport
+layer. This vehicle HAL is the interface for developing Android Automotive
+implementations.</p>
+<p>System integrators can implement a vehicle HAL module by connecting
+function-specific platform HAL interfaces (e.g. HVAC) with technology-specific
+network interfaces (e.g. CAN bus). Typical implementations may include a
+dedicated Microcontroller Unit (MCU) running a proprietary real-time operating
+system (RTOS) for CAN bus access or similar, which may be connected via a serial
+link to the CPU running Android Automotive. Instead of a dedicated MCU, it may
+also be possible to implement the bus access as a virtualized CPU. It is up to
+each partner to choose the architecture suitable for the hardware as long as the
+implementation fulfills the interface requirements for the vehicle HAL.</p>
+
+<h2 id=arch>Architecture</h2>
+<p>The vehicle HAL is the interface definition between the car and the vehicle
+network service:</p>
+
+<img src="images/vehicle_hal_arch.png" alt="Android vehicle HAL architecture">
+<p class="img-caption"><strong>Figure 1</strong>. Vehicle HAL and Android
+automotive architecture</p>
+
+<ul>
+<li><strong>Car API</strong>. Contains the APIs such as CarHvacManager,
+CarSensorManager, and CarCameraManager. For details on all supported APIs,
+refer to <code>/platform/packages/services/Car/car-lib</code>.</li>
+<li><strong>CarService</strong>. Located at
+<code>/platform/packages/services/Car/</code>.</li>
+<li><strong>VehicleNetworkService</strong>. Controls vehicle HAL with built-in
+security. Access restricted to system components only (non-system components
+such as third party apps should use car API instead). OEMs can control access
+using <code>vns_policy.xml</code> and <code>vendor_vns_policy.xml</code>.
+Located at <code>/platform/packages/services/Car/vehicle_network_service/</code>;
+for libraries to access the vehicle network, refer to
+<code>/platform/packages/services/Car/libvehiclenetwork/</code>.</li>
+<li><strong>Vehicle HAL</strong>. Interface that defines the properties OEMs can
+implement and contains property metadata (for example, whether the property is
+an int and which change modes are allowed). Located at
+<code>hardware/libhardware/include/hardware/vehicle.h</code>. For a basic
+reference implementation, refer to
+<code>hardware/libhardware/modules/vehicle/</code>.</li>
+</ul>
+
+<h2 id=prop>Vehicle properties</h2>
+<p>The vehicle HAL interface is based on accessing (read, write, subscribe) a
+property, which is an abstraction for a specific function. Properties can be
+read-only, write-only (used to pass information to vehicle HAL level), or read
+and write. Support of most properties is optional.</p>
+<p>Each property is uniquely identified by an int32 key and has a predefined
+type (<code>value_type</code>):</p>
+
+<ul>
+<li><code>INT32</code> (and array), <code>INT64</code>, <code>BOOLEAN</code>,
+<code>FLOAT</code> (and array), string, bytes.</li>
+<li>Zoned type has zone in addition to value.</li>
+</ul>
+
+<h3 id-=zone_type>Zone types</h3>
+<p>The vehicle HAL defines three zone types:</p>
+<ul>
+<li><code>vehicle_zone</code>: Zone based on rows.</li>
+<li><code>vehicle_seat</code>: Zone based on seats.</li>
+<li><code>vehicle_window</code>: Zone based on windows.</li>
+</ul>
+<p>Each zoned property should use pre-defined zone type. If necessary, you can
+use a custom zone type for each property (for details, see
+<a href=#prop_custom>Handling custom properties</a>).</p>
+
+<h3 id=prop_config>Configuring a property</h3>
+<p>Use <code>vehicle_prop_config_t</code> to provide configuration information
+for each property. Information includes:</p>
+<ul>
+<li><code>access</code> (r, w, rw)</li>
+<li><code>change_mode</code> (represents how property is monitored: on change vs
+continuous)</li>
+<li><code>min_value</code> (int32, float, int64), <code>max_value</code> (int32,
+float, int64)</li>
+<li><code>min_sample_rate</code>, <code>max_sample_rate</code></li>
+<li><code>permission_model</code></li>
+<li><code>prop</code> (Property ID, int)</li>
+<li><code>value_type</code></li>
+<li><code>zone_flags</code> (represents supported zones as bit flags)</li>
+</ul>
+<p>In addition, some properties have specific configuration flags to represent
+capability.</p>
+
+<h2 id=interfaces>HAL interfaces</h2>
+<p>The vehicle HAL uses the following interfaces:</p>
+<ul>
+<li><code>vehicle_prop_config_t const *(*list_properties)(..., int*
+num_properties)</code>. List configuration of all properties supported by the
+vehicle HAL. Only supported properties will be used by vehicle network service.
+</li>
+<li><code>(*get)(..., vehicle_prop_value_t *data)</code>. Read the current value
+of the property. For zoned property, each zone may have different value.</li>
+<li><code>(*set)(..., const vehicle_prop_value_t *data)</code>. Write a value to
+property. Result of write is defined per each property.</li>
+<li><code>(*subscribe)(..., int32_t prop, float sample_rate, int32_t
+zones)</code>.<ul>
+<li>Start monitoring property value's change. For zoned property, subscription
+applies to requested zones. Zones = 0 is used to request all zones supported.
+</li>
+<li>Vehicle HAL should call separate callback when the property's value changes
+(=on change) or in const interval (=continuous type).</ul></li>
+<li><code>(*release_memory_from_get)(struct vehicle_hw_device* device,
+vehicle_prop_value_t *data)</code>. Release memory allocated from get call.</ul>
+</li>
+</ul>
+
+<p>The vehicle HAL uses the following callback interfaces:</p>
+<ul>
+<li><code>(*vehicle_event_callback_fn)(const vehicle_prop_value_t
+*event_data)</code>. Notifies vehicle property's value change. Should be done
+only for subscribed properties.</li>
+<li><code>(*vehicle_error_callback_fn)(int32_t error_code, int32_t property,
+int32_t operation).</code> Return global vehicle HAL level error or error per
+each property. Global error causes HAL restart, which can lead to restarting
+other components, including applications.</li>
+</ul>
+
+<h2 id=zone_prop>Handling zone properties</h2>
+<p>A zoned property is equivalent to a collection of multiple properties where
+each sub property is accessible by specified zone value.</p>
+<ul>
+<li><code>get</code> call for zoned property always includes zone in request, so
+only the current value for the requested zone should be returned.</li>
+<li><code>set</code> call for zoned property always includes zone in request, so
+only the requested zone should be changed.</li>
+<li><code>subscribe</code> call includes flags of all zones subscribed. Events
+from un-subscribed zones should not be reported.</li>
+</ul>
+
+<h3 id=get>Get calls</h3>
+<p>During initialization, the value for the property may not be available yet as
+the matching vehicle network message has not yet been received. In such cases,
+the <code>get</code> call should return <code>-EAGAIN</code>. Some properties
+(such as HVAC) have separate on/off power property. Calling <code>get</code> for
+such a property (when powered off) should return a special value
+<code>(VEHICLE_INT_OUT_OF_RANGE_OFF/VEHICLE_FLOAT_OUT_OF_RANGE_OFF)</code>
+rather than returning an error.</p>
+<p>In addition, some properties (such as HVAC temperature) can have a value to
+indicate it is in max power mode rather than in specific temperature value. In
+such cases, use special values to represent such state.</p>
+<ul>
+<li>VEHICLE_INT_OUT_OF_RANGE_MAX/MIN</li>
+<li>VEHICLE_FLOAT_OUT_OF_RANGE_MAX/MIN</li>
+</ul>
+
+<p>Example: get HVAC Temperature</p>
+<img src="images/vehicle_hvac_get.png" alt="Vehicle HAL get HVAC example">
+<p class="img-caption"><strong>Figure 2</strong>. Get HVAC temperature (CD =
+CarService, VNS = VehicleNetworkService, VHAL = Vehicle HAL)</p>
+
+<h3 id=set>Set calls</h3>
+<p>A <code>set</code> call is an asynchronous operation involving event
+notification after a requested change is made. In a typical operation, a
+<code>set</code> call leads to making a change request across vehicle network.
+When the change is performed by the electronic control unit (ECU) owning the
+property, the updated value is returned through vehicle network and the vehicle
+HAL sends an updated value as an event to vehicle network service (VNS).</p>
+<p>Some <code>set</code> calls may require initial data to be ready but during
+initialization, such data may not be available yet. In such cases, the
+<code>set</code> call should return <code>-EAGAIN</code>. Some properties with
+separate power on /off should return <code>-ESHUTDOWN</code> when the property
+is powered off and set cannot be done.</p>
+<p>Until <code>set</code> is made effective, <code>get</code> does not
+necessarily return the same value as what is set. The exception is a property
+with change mode of <code>VEHICLE_PROP_CHANGE_MODE_ON_SET.</code> This property
+notifies change only when it is set by external component outside Android (for
+example, clock properties such as <code>VEHICLE_PROPERTY_UNIX_TIME</code>).</p>
+
+<p>Example: set HVAC Temperature</p>
+<img src="images/vehicle_hvac_set.png" alt="Vehicle HAL set HVAC example">
+<p class="img-caption"><strong>Figure 3</strong>. Set HVAC temperature (CD =
+CarService, VNS = VehicleNetworkService, VHAL = Vehicle HAL)</p>
+
+<h2 id=prop_custom>Handling custom properties</h2>
+<p>To support partner-specific needs, the vehicle HAL allows custom properties
+that are restricted to system apps. Use the following guidelines when working
+with custom properties:</p>
+<ul>
+<li>Key should be in [<code>VEHICLE_PROPERTY_CUSTOM_START,
+VEHICLE_PROPERTY_CUSTOM_END</code>] range. Other ranges are reserved for future
+extension; using such ranges can cause conflicts in future Android releases.</li>
+<li>Use only defined <code>value_type</code>. BYTES type allows passing raw
+data, so this is enough in most cases. Sending big data frequently through
+custom properties can slow down the whole vehicle network access, so be careful
+when you add a big payload.</li>
+<li>Add access policy into <code>vendor_vns_policy.xml</code> (otherwise, all
+access will be rejected).</li>
+<li>Access via <code>VendorExtensionManager</code> (for Java components) or
+via Vehicle Network Service API (for native). Do not modify other car APIs as it
+can lead to compatibility issues in the future.</li>
+</ul>
+
+<h2 id=prop_hvac>Handling HVAC properties</h2>
+<p>You can use the vehicle HAL to control HVAC by setting HVAC-related
+properties. Most HVAC properties are zoned properties, but a few are non-zoned
+(global) properties. Example properties defined include:</p>
+<ul>
+<li><code>VEHICLE_PROPERTY_HVAC_TEMPERATURE_SET</code> (set temperature per each
+zone).</li>
+<li><code>VEHICLE_PROPERTY_HVAC_RECIRC_ON</code> (control recirculation per each
+zone).</li>
+</ul>
+<p>For full list of HVAC properties, search for
+<code>VEHICLE_PROPERTY_HVAC_*</code> in <code>vehicle.h</code>.</p>
+
+<h2 id=prop_sensor>Handling sensor properties</h2>
+<p>Vehicle HAL sensor properties represent real sensor data or policy
+information such as driving status. Some sensor information (such as driving
+status and day/night mode) is accessible by any app without restriction as the
+data is mandatory to build a safe vehicle application. Other sensor information
+(such as vehicle speed) is more sensitive and requires specific permissions that
+users can manage.</p>
+<p>Supported sensor properties include:</p>
+<ul>
+<li><code>DRIVING_STATUS</code> (should support). Represents allowed operations
+in the current driving state. This information is used to block unsafe
+applications while driving.</li>
+<li><code>NIGHT_MODE</code> (should support). Determines day/night mode of
+display.</li>
+<li><code>GEAR_SELECTION/CURRENT_GEAR</code>. Gear selected by driver vs.
+actual gear.</li>
+<li><code>VEHICLE_SPEED</code>. Vehicle speed. Protected with permission.</li>
+<li><code>ODOMETER</code>. Current odometer reading. Protected with permission.
+</li>
+<li><code>FUEL_LEVEL</code>. Current fuel level in %.</li>
+<li><code>FUEL_LEVEL_LOW</code>. Fuel level is low or not (boolean).</li>
+</ul>
+
+<h2 id=security>Security</h2>
+<p>The vehicle HAL supports three levels of security for accessing data:</p>
+<ul>
+<li>System only (controlled by <code>vns_policy.xml</code>)</li>
+<li>Accessible to app with permission (through car service)</li>
+<li>Accessible without permission (through car service)</li>
+</ul>
+<p>Direct access to vehicle properties is allowed only to selected system
+components with vehicle network service acting as the gatekeeper. Most
+applications go through additional gatekeeping by car service (for example, only
+system applications can control HVAC as it requires system permission granted
+only to system apps).</p>
+
+<h2 id=validation>Validation</h2>
+<p>AOSP includes the following testing resources for use in development:</p>
+<ul>
+<li><code>hardware/libhardware/tests/vehicle/vehicle-hal-tool.c</code>.
+Command-line native tool to load vehicle HAL and do simple operations. Useful
+for getting the system up and running in the early stages of development.</li>
+<li><code>packages/services/Car/tests/carservice_test/</code>. Contains car
+service testing with mocked vehicle HAL properties. For each property, expected
+behavior is implemented in the test. This can be a good starting point to
+understand expected behavior.</li>
+<li><code>hardware/libhardware/modules/vehicle/</code>. A basic reference
+implementation.</li>
+</ul>
diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
index 862d6f5..0dc2b03 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -128,6 +128,7 @@
           <li><a href="<?cs var:toroot ?>devices/audio/tv.html">TV Audio</a></li>
         </ul>
       </li>
+      <li><a href="<?cs var:toroot ?>devices/automotive.html">Automotive</a></li>
       <li><a href="<?cs var:toroot ?>devices/bluetooth.html">Bluetooth</a></li>
       <li class="nav-section">
         <div class="nav-section-header">
diff --git a/src/devices/images/ape_fwk_hal_vehicle.png b/src/devices/images/ape_fwk_hal_vehicle.png
new file mode 100644
index 0000000..500934d
--- /dev/null
+++ b/src/devices/images/ape_fwk_hal_vehicle.png
Binary files differ
diff --git a/src/devices/images/vehicle_hal_arch.png b/src/devices/images/vehicle_hal_arch.png
new file mode 100644
index 0000000..8c8a6ab
--- /dev/null
+++ b/src/devices/images/vehicle_hal_arch.png
Binary files differ
diff --git a/src/devices/images/vehicle_hvac_get.png b/src/devices/images/vehicle_hvac_get.png
new file mode 100644
index 0000000..1006db6
--- /dev/null
+++ b/src/devices/images/vehicle_hvac_get.png
Binary files differ
diff --git a/src/devices/images/vehicle_hvac_set.png b/src/devices/images/vehicle_hvac_set.png
new file mode 100644
index 0000000..fcf4683
--- /dev/null
+++ b/src/devices/images/vehicle_hvac_set.png
Binary files differ
diff --git a/src/index.jd b/src/index.jd
index dc0aa44..c3e706f 100644
--- a/src/index.jd
+++ b/src/index.jd
@@ -25,15 +25,13 @@
   <div class="landing-banner">
       <h1 itemprop="name" style="margin-bottom:0;">Welcome to the Android Open Source Project!</h1>
 
-<p>
-Android is an open source software stack for a wide range of mobile devices and
-a corresponding open source project led by Google. This site offers the
+<p>Android is an open source software stack for a wide range of mobile devices
+and a corresponding open source project led by Google. This site offers the
 information and source code you need to create custom variants of the Android
 stack, port devices and accessories to the Android platform, and ensure your
-devices meet compatibility requirements.
-</p>
+devices meet compatibility requirements.</p>
 
-<h2 align="center">Android 6.0 Updates Available &mdash; see details below</h2>
+<h2 align="center">Android 7.0 Updates Available</h2>
   </div>
 
 </div>
@@ -41,8 +39,113 @@
 <div class="wrap">
 
   <div class="landing-docs">
-    <div class="col-8">
+    <div class="col-10">
     <h3>What's New</h3>
+
+<h4>Key Features</h4>
+<p>
+<a href="{@docRoot}devices/tech/dalvik/jit-compiler.html"><strong>Just-in-time
+(JIT) compiler</strong></a> with code profiling to Android runtime (ART)
+continually improves app performance.
+<a href="{@docRoot}security/encryption/file-based.html"><strong>Direct boot and
+file-based encryption</strong></a> allows certain apps to run securely when
+the device is powered on but not unlocked.
+<a href="{@docRoot}devices/tech/display/multi-window.html"><strong>Multi-window</strong></a>
+support enables simultaneous display of multiple apps on a device screen.
+The <a href="{@docRoot}devices/automotive.html"><strong>Vehicle
+HAL</strong></a> enables Android Automotive implementations.</p>
+
+<h4>Security Improvements</h4>
+<p>
+Android now strictly enforces
+<a href="{@docRoot}security/verifiedboot/verified-boot.html"><strong>verified
+boot</strong></a> and requires a
+<a href="{@docRoot}security/overview/app-security.html#certificate-authorities"><strong>same-system
+trusted CA store</strong></a>.
+<a href="{@docRoot}security/apksigning/index.html#v2"><strong>APK signature
+scheme v2</strong></a> performs signature checking across the entire file.
+Security hardening of <a href="{@docRoot}devices/media/framework-hardening.html"><strong>media
+framework</strong></a> and
+<a href="{@docRoot}devices/camera/versioning.html#hardening">camera service</strong></a>
+splits mediaserver into multiple processes with restricted permissions and
+capabilities (may require changes to HAL implementations).
+For more changes, see
+<a href="{@docRoot}security/enhancements/enhancements70.html"><strong>7.0
+security enhancements</strong></a>.</p>
+
+<h4>Audio, Camera, &amp; Graphics Updates</h4>
+<p>
+<a href="{@docRoot}devices/audio/implement-policy.html"><strong>Audio policy
+improvements</strong></a> include changes to policy configuration files, a
+reorganization of audio policy code, and new extensions for audio policy routing
+APIs.
+Android now supports
+<a href="{@docRoot}devices/graphics/arch-vulkan.html"><strong>Vulkan</strong></a>
+(low­-overhead, cross-platform API for high-performance 3D graphics) and
+<a href="{@docRoot}devices/graphics/testing.html"><strong>OpenGL
+3.2</strong></a>; check with your SoC for driver support.
+Enhancements to
+<a href="{@docRoot}devices/camera/versioning.html"><strong>camera3</strong></a>
+support devices with high-end cameras.</p>
+
+<h4>OEM Customizations</h4>
+<p>Users can now
+<a href="{@docRoot}devices/tech/connect/block-numbers.html"><strong>restrict
+calls and texts</strong></a> (impacts apps using blocking features).
+Do-not-disturb (DND) rules can now
+<a href="{@docRoot}devices/tech/display/dnd.html"><strong>suppress visual
+interruptions</strong></a>.</p>
+
+<h4>Android For Work Updates</h4>
+<p>New device administration features include
+<a href="{@docRoot}devices/tech/admin/enterprise-telephony.html"><strong>enterprise
+telephony</strong></a> (cross-profile contact searching and badging, affects
+preloaded Dialer and Contacts apps),
+<a href="{@docRoot}devices/tech/admin/implement.html#HAL_values"><strong>device
+monitoring and health reporting</strong></a> (APIs for apps to query device
+hardware state; device must report correct values in the HAL implementation),
+and
+<a href="{@docRoot}devices/tech/admin/testing-setup.html#troubleshooting"><strong>enterprise
+process logging and device owner triggered bugreports</strong></a> (collect logs
+for user actions on a managed device).</p>
+
+<h4>Power Improvements</h4>
+<p>
+<a href="{@docRoot}devices/tech/power/mgmt.html#doze"><strong>Doze</strong></a>
+now works on devices in motion.
+<a href="{@docRoot}devices/tech/power/mgmt.html#sustained_performance"><strong>Sustained
+performance</strong></a> hints can inform long-running applications of
+device-performance capabilities (requires power HAL changes).
+<a href="{@docRoot}devices/tech/connect/data-saver.html"><strong>Data
+Saver</strong></a> enables restricting background data when on cellular or
+metered networks.
+Android now collects data for
+<a href="{@docRoot}devices/tech/power/values.html#le-bt-scans"><strong>Low
+Energy (LE) scans and Bluetooth</strong></a> traffic.</p>
+
+<h4>Under the Hood</h4>
+<p>Dialer APIs handle all
+<a href="{@docRoot}devices/tech/connect/call-notification.html"><strong>call
+notification</strong></a> logic (instead of sharing with Telecom).
+<a href="{@docRoot}devices/tech/config/namespaces_libraries.html"><strong>Namespaces
+for native libraries</strong></a> prevent apps from using private platform
+native APIs.
+<a href="{@docRoot}source/running.html#flashing-a-device"><strong>Flash
+unlock</strong></a> reports the bootloader's lock status.
+<a href="{@docRoot}devices/tech/connect/ril.html"><strong>Radio
+Interface Layer (RIL)</strong></a> support includes enhancements to error codes,
+versioning, and wakelocks.
+<a href="{@docRoot}devices/tech/config/uicc.html"><strong>UICC carrier
+privilege</strong></a> rules now support Access File Rule (ARF) storage.
+Android now supports the RFID smart card system
+<a href="{@docRoot}devices/tech/connect/felica.html"><strong>Felicity Card
+(FeliCa)</strong></a>.
+Documentation updated for
+<a href="{@docRoot}devices/halref/index.html"><strong>HAL</strong></a>
+and <a href="{@docRoot}reference/packages.html"><strong>TradeFed</strong></a>
+references.</p>
+
+<!--SAVED for FUTURE REFERENCE
 <a href="{@docRoot}source/build-numbers.html">
         <h4>Lollipop and Marshmallow Build Numbers</h4></a>
         <p>New <strong><a
@@ -56,83 +159,49 @@
         <p>Android 6.0 R3, 5.1 R5, and 5.0 R4 Compatibility Test Suite (CTS)
         and CTS Verifier are available for <strong><a
         href="{@docRoot}compatibility/downloads.html">Download</a></strong>.</p>
+-->
+</div>
 
-<a href="{@docRoot}source/initializing.html">
-        <h4>JDK 8 for Latest Platform Development</h4></a>
-        <p>The master branch of Android now requires JDK 8 to build. See <strong><a
-        href="{@docRoot}source/requirements.html">Requirements</a></strong>
-        for a summary of Java versions by Android release. See <strong><a
-        href="{@docRoot}source/initializing.html#installing-the-jdk">Setting up
-        a Linux build environment</a></strong> or <strong><a
-        href="{@docRoot}source/initializing.html#installing-the-mac-jdk">Setting up a
-        Mac OS build environment</a></strong> for update instructions by operating system.</p>
+<div class="col-5">
 
-<a href="{@docRoot}source/read-bug-reports.html">
-        <h4>Reading Bug Reports</h4></a>
-        <p>Android Engineering has written a detailed guide for <strong><a
-        href="{@docRoot}source/read-bug-reports.html">understanding
-        device-generated bug reports</a></strong>. This guide describes and
-        provides examples of common errors and their associated causes, such as
-        <strong><a href="{@docRoot}source/read-bug-reports.html#memory">low
-        memory</a></strong>. It even explains how to establish a <strong><a
-        href="{@docRoot}source/read-bug-reports.html#narrative">narrative</a></strong>
-        of the issue by syncing timelines across logs.</p>
+<h3>Getting Started</h3>
+<a href="{@docRoot}source/index.html"><h4>Explore the Source</h4></a>
+<p>Get the complete Android platform and modify and build it to suit your needs.
+You can also
+<strong><a href="https://android-review.googlesource.com/#/q/status:open">contribute
+to</a></strong> the <strong><a href="https://android.googlesource.com/">Android
+Open Source Project (AOSP) repository</a></strong> to make your changes
+available to everyone else in the Android ecosystem.</p>
 
-<a href="{@docRoot}compatibility/cts/rotation-vector.html">
-        <h4>Rotation Vector CV Crosscheck</h4></a>
-        <p>Instructions now exist for the CTS Verifier <strong><a
-        href="{@docRoot}compatibility/cts/rotation-vector.html">Rotation Vector
-        CV Crosscheck</a></strong> used to properly test the compatibility of rotation
-        vector sensor implementations.</p>
+<a href="{@docRoot}source/index.html"><img border="0"
+src="images/android_framework_small.png" alt="Android framework summary"
+style="display:inline;float:right;margin:5px 10px;width:42%;height:42%"></a>
 
-<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>
-    </div>
+<a href="{@docRoot}devices/index.html"><h4>Port Android to Devices</h4></a>
+<p>Get help porting the latest Android platform to create compelling devices for
+your customers. Includes documentation for HAL interfaces and details on core
+technologies such as Android runtime (ART) and over-the-air (OTA) updates.</p>
 
-    <div class="col-8">
-      <h3>Getting Started</h3>
-      <a href="{@docRoot}source/index.html">
-        <h4>Explore the Source</h4></a>
-        <p>Get the complete Android platform and modify and build it to suit your needs. You can
-        also <strong><a
-        href="https://android-review.googlesource.com/#/q/status:open">contribute
-        to</a></strong> the <strong><a
-        href="https://android.googlesource.com/">Android Open Source Project (AOSP)
-        repository</a></strong> to make your changes available to everyone else
-        in the Android ecosystem.</p>
-<a href="{@docRoot}source/index.html"><img border="0" src="images/android_framework_small.png" alt="Android framework summary" style="display:inline;float:right;margin:5px 10px;width:42%;height:42%"></a>
-      <a href="{@docRoot}devices/index.html">
-        <h4>Port Android to Devices</h4></a>
-        <p>Port the latest Android platform and
-        create compelling devices that your customers want.</p>
+<a href="{@docRoot}security/index.html"><h4>Make Secure</h4></a>
+<p>Follow these examples and instructions to harden your Android devices against
+malicious attacks. Find out how the Android security program works and learn how
+to implement the latest features.</p>
 
-      <a href="{@docRoot}security/index.html">
-        <h4>Make Secure</h4></a>
-	<p>Follow these examples and instructions to harden your Android
-          devices against malicious attacks. Find out how the Android security program
-          works and learn to implement the latest features.</p>
+<a href="{@docRoot}compatibility/index.html"><h4>Get Compatible</h4></a>
+<p>Being Android-compatible lets you offer custom features but still give users
+and developers a consistent and standard experience across all Android-powered
+devices. Android provides guidance and a test suite to verify your Android
+compatibility.</p>
 
-      <a href="{@docRoot}compatibility/index.html">
-        <h4>Get Compatible</h4></a>
-        <p>Being Android-compatible lets you offer custom features but still give users and developers a consistent
-          and standard experience across all Android-powered devices. Android provides guidance
-          and a test suite to verify your Android compatibility.</p>
+<a href="https://android.googlesource.com/platform/docs/source.android.com/">
+<h4>Help this Site</h4></a>
+<p>Use the <strong>Site Feedback</strong> button at the bottom of any page to
+request content improvements or let us know about errors. To contribute your
+own updates to the site or to view a complete list of site changes, use the AOSP
+project
+<strong><a href="https://android.googlesource.com/platform/docs/source.android.com/+log/master">docs/source.android.com.</a></strong></p>
+</div>
 
-      <a href="https://android.googlesource.com/platform/docs/source.android.com/">
-        <h4>Help this Site</h4></a>
-        <p>Use the <strong>Site Feedback</strong> button at the bottom of any
-        page to request improvements to the content or identify errors. In addition,
-        source.android.com is maintained in the Android Open Source Project. See the
-        <strong><a
-        href="https://android.googlesource.com/platform/docs/source.android.com/+log/master">docs/source.android.com
-        project log in AOSP</a></strong> for the complete list of changes to this site.
-        Contribute your own updates to that same project and help maintain source.android.com.</p>
-    </div>
-
-  </div>
+</div>
 
 </div>
diff --git a/src/security/apksigning/index.jd b/src/security/apksigning/index.jd
new file mode 100644
index 0000000..1145191
--- /dev/null
+++ b/src/security/apksigning/index.jd
@@ -0,0 +1,138 @@
+page.title=Application Signing
+@jd:body
+
+<!--
+    Copyright 2016 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>
+Application signing allows developers to identify the author of the application
+and to update their application without creating complicated interfaces and
+permissions. Every application that is run on the Android platform must be <a
+href="https://developer.android.com/studio/publish/app-signing.html">signed by
+the developer</a>. Applications that attempt to install without being signed
+will be rejected by either Google Play or the package installer on the Android
+device.
+</p>
+<p>
+On Google Play, application signing bridges the trust Google has with the
+developer and the trust the developer has with their application. Developers
+know their application is provided, unmodified, to the Android device; and
+developers can be held accountable for behavior of their application.
+</p>
+<p>
+On Android, application signing is the first step to placing an application in
+its Application Sandbox. The signed application certificate defines which user
+ID is associated with which application; different applications run under
+different user IDs. Application signing ensures that one application cannot
+access any other application except through well-defined IPC.
+</p>
+<p>
+When an application (APK file) is installed onto an Android device, the Package
+Manager verifies that the APK has been properly signed with the certificate
+included in that APK. If the certificate (or, more accurately, the public key in
+the certificate) matches the key used to sign any other APK on the device, the
+new APK has the option to specify in the manifest that it will share a UID with
+the other similarly-signed APKs.
+</p>
+<p>
+Applications can be signed by a third-party (OEM, operator, alternative market)
+or self-signed. Android provides code signing using self-signed certificates
+that developers can generate without external assistance or permission.
+Applications do not have to be signed by a central authority. Android currently
+does not perform CA verification for application certificates.
+</p>
+<p>
+Applications are also able to declare security permissions at the Signature
+protection level, restricting access only to applications signed with the same
+key while maintaining distinct UIDs and Application Sandboxes. A closer
+relationship with a shared Application Sandbox is allowed via the <a
+href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">shared
+UID feature</a> where two or more applications signed with same developer key
+can declare a shared UID in their manifest.
+</p>
+<h2>APK signing schemes</h2>
+<p>
+Android supports two application signing schemes, one based on JAR signing (v1
+scheme) and <a href="v2.html">APK Signature Scheme v2 (v2 scheme)</a>, which
+was introduced in Android Nougat (Android 7.0).
+</p>
+<p>
+For maximum compatibility, applications should be signed both with v1 and v2
+schemes. Android Nougat and newer devices install apps signed with v2 scheme
+more quickly than those signed only with v1 scheme. Older Android platforms
+ignore v2 signatures and thus need apps to contain v1 signatures.
+</p>
+<h3 id="v1">JAR signing (v1 scheme)</h3>
+<p>
+APK signing has been a part of Android from the beginning. It is based on <a
+href="https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Signed_JAR_File">
+signed JAR</a>. For details on using this scheme, see the Android Studio documentation on
+<a href="https://developer.android.com/studio/publish/app-signing.html">Signing
+your app</a>.
+</p>
+<p>
+v1 signatures do not protect some parts of the APK, such as ZIP metadata. The
+APK verifier needs to process lots of untrusted (not yet verified) data
+structures and then discard data not covered by the signatures. This offers a
+sizeable attack surface. Moreover, the APK verifier must uncompress all
+compressed entries, consuming more time and memory. To address these issues,
+Android 7.0 introduced APK Signature Scheme v2.
+</p>
+<h3 id="v2">APK Signature Scheme v2 (v2 scheme)</h3>
+<p>
+Android 7.0 introduces APK signature scheme v2 (v2 scheme). The contents of the
+APK are hashed and signed, then the resulting APK Signing Block is inserted
+into the APK. For details on applying the v2 scheme to an application, refer to
+<a href="https://developer.android.com/preview/api-overview.html#apk_signature_v2">APK
+Signature Scheme v2</a> in the Android N Developer Preview.
+</p>
+<p>
+During validation, v2 scheme treats the APK file as a blob and performs signature
+checking across the entire file. Any modification to the APK, including ZIP metadata
+modifications, invalidates the APK signature. This form of APK verification is
+substantially faster and enables detection of more classes of unauthorized
+modifications.
+</p>
+<p>
+The new format is backwards compatible, so APKs signed with the new signature
+format can be installed on older Android devices (which simply ignore the extra
+data added to the APK), as long as these APKs are also v1-signed.
+</p>
+<p>
+  <img src="../images/apk-validation-process.png" alt="APK signature verification process" id="figure1" />
+</p>
+<p class="img-caption"><strong>Figure 1.</strong> APK signature verification
+process (new steps in red)</p>
+
+<p>
+Whole-file hash of the APK is verified against the v2 signature stored in the
+APK Signing Block. The hash covers everything except the APK Signing Block,
+which contains the v2 signature. Any modification to the APK outside of the APK
+Signing Block invalidates the APK's v2 signature. APKs with stripped v2
+signature are rejected as well, because their v1 signature specifies that the
+APK was v2-signed, which makes Android Nougat and newer refuse to verify APKs
+using their v1 signatures.
+</p>
+
+<p>For details on the APK signature verification process, see the <a href="v2.html#verification">
+Verification section</a> of APK Signature Scheme v2.</p>
diff --git a/src/security/apksigning/v2.jd b/src/security/apksigning/v2.jd
new file mode 100644
index 0000000..6a2e7a9
--- /dev/null
+++ b/src/security/apksigning/v2.jd
@@ -0,0 +1,368 @@
+page.title=APK Signature Scheme v2
+@jd:body
+
+<!--
+    Copyright 2016 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>
+APK Signature Scheme v2 is a whole-file signature scheme that increases
+verification speed and <a
+href="#integrity-protected-contents">strengthens integrity guarantees</a> by
+detecting any changes to the protected parts of the APK.
+</p>
+
+<p>
+Signing using APK Signature Scheme v2 inserts an <a
+href="#apk-signing-block">APK Signing Block</a> into the APK file immediately
+before the ZIP Central Directory section. Inside the APK Signing Block, v2
+signatures and signer identity information are stored in an <a
+href="#apk-signature-scheme-v2-block">APK Signature Scheme v2 Block</a>.
+</p>
+
+<p>
+  <img src="../images/apk-before-after-signing.png" alt="APK before and after signing" id="figure1" />
+</p>
+<p class="img-caption"><strong>Figure 1.</strong> APK before and after signing</p>
+
+<p>
+APK Signature Scheme v2 was introduced in Android 7.0 (Nougat). To make
+a APK installable on Android 6.0 (Marshmallow) and older devices, the
+APK should be signed using <a href="index.html#v1">JAR signing</a> before being
+signed with the v2 scheme.
+</p>
+
+
+<h2 id="apk-signing-block">APK Signing Block</h2>
+<p>
+To maintain backward-compatibility with the current APK format, v2 and newer APK
+signatures are stored inside an APK Signing Block, a new container introduced to
+support APK Signature Scheme v2. In an APK file, the APK Signing Block is located
+immediately before the ZIP Central Directory, which is located at the end of the file.
+</p>
+
+<p>
+The block contains ID-value pairs wrapped in a way that makes it easier to
+locate the block in the APK. The v2 signature of the APK is stored as an ID-value
+pair with ID 0x7109871a.
+</p>
+
+<h3 id="apk-signing-block-format">Format</h3>
+<p>
+The format of the APK Signing Block is as follows (all numeric fields are
+little-endian):
+</p>
+
+<ul>
+  <li><code>size of block</code> in bytes (excluding this field) (uint64)</li>
+  <li>Sequence of uint64-length-prefixed ID-value pairs:
+    <ul>
+      <li><code>ID</code> (uint32)</li>
+      <li><code>value</code> (variable-length: length of the pair - 4 bytes)</li>
+    </ul>
+  </li>
+  <li><code>size of block</code> in bytes—same as the very first field (uint64)</li>
+  <li><code>magic</code> “APK Sig Block 42” (16 bytes)</li>
+</ul>
+
+<p>
+APK is parsed by first finding the start of the ZIP Central Directory (by
+finding the ZIP End of Central Directory record at the end of the file, then
+reading the start offset of the Central Directory from the record). The
+<code>magic</code> value provides a quick way to establish that what precedes
+Central Directory is likely the APK Signing Block. The <code>size of
+block</code> value then efficiently points to the start of the block in the
+file.
+</p>
+
+<p>
+ID-value pairs with unknown IDs should be ignored when interpreting the
+block.
+</p>
+
+
+<h2 id="apk-signature-scheme-v2-block">APK Signature Scheme v2 Block</h2>
+<p>
+APK is signed by one or more signers/identities, each represented by a signing
+key. This information is stored as an APK Signature Scheme v2 Block. For each
+signer, the following information is stored:
+</p>
+
+<ul>
+  <li>(signature algorithm, digest, signature) tuples. The digest is stored to
+decouple  signature verification from integrity checking of the APK’s contents.</li>
+  <li>X.509 certificate chain representing the signer’s identity.</li>
+  <li>Additional attributes as key-value pairs.</li>
+</ul>
+
+<p>
+For each signer, the APK is verified using a supported signature from the
+provided list. Signatures with unknown signature algorithms are ignored. It is
+up to each implementation to choose which signature to use when multiple
+supported signatures are encountered. This enables the introduction of stronger
+signing methods in the future in a backward-compatible way. The suggested
+approach is to verify the strongest signature.
+</p>
+
+<h3 id="apk-signature-scheme-v2-block-format">Format</h3>
+<p>
+APK Signature Scheme v2 Block is stored inside the APK Signing Block under ID
+<code>0x7109871a</code>.
+</p>
+
+<p>
+The format of the APK Signature Scheme v2 Block is as follows (all numeric
+values are little-endian, all length-prefixed fields use uint32 for length):
+</p>
+<ul>
+  <li>length-prefixed sequence of length-prefixed <code>signer</code>:
+    <ul>
+      <li>length-prefixed <code>signed data</code>:
+        <ul>
+          <li>length-prefixed sequence of length-prefixed <code>digests</code>:
+            <ul>
+              <li><code>signature algorithm ID</code> (uint32)</li>
+              <li>(length-prefixed) <code>digest</code>—see
+              <a href="#integrity-protected-contents">Integrity-protected Contents</a></li>
+            </ul>
+          </li>
+          <li>length-prefixed sequence of X.509 <code>certificates</code>:
+            <ul>
+              <li>length-prefixed X.509 <code>certificate</code> (ASN.1 DER form)</li>
+            </ul>
+          </li>
+          <li>length-prefixed sequence of length-prefixed <code>additional attributes</code>:
+            <ul>
+              <li><code>ID</code> (uint32)</li>
+              <li><code>value</code> (variable-length: length of the additional
+              attribute - 4 bytes)</li>
+            </ul>
+          </li>
+        </ul>
+      </li>
+      <li>length-prefixed sequence of length-prefixed <code>signatures</code>:
+        <ul>
+          <li><code>signature algorithm ID</code> (uint32)</li>
+          <li>length-prefixed <code>signature</code> over <code>signed data</code></li>
+        </ul>
+      </li>
+      <li>length-prefixed <code>public key</code> (SubjectPublicKeyInfo, ASN.1 DER form)</li>
+    </ul>
+  </li>
+</ul>
+
+<h4 id="signature-algorithm-ids">Signature Algorithm IDs</h4>
+<ul>
+  <li>0x0101—RSASSA-PSS with SHA2-256 digest, SHA2-256 MGF1, 32 bytes of salt,
+      trailer: 0xbc</li>
+  <li>0x0102—RSASSA-PSS with SHA2-512 digest, SHA2-512 MGF1, 64 bytes of salt,
+      trailer: 0xbc</li>
+  <li>0x0103—RSASSA-PKCS1-v1_5 with SHA2-256 digest. This is for build systems
+      which require deterministic signatures.</li>
+  <li>0x0104—RSASSA-PKCS1-v1_5 with SHA2-512 digest. This is for build systems
+      which require deterministic signatures.</li>
+  <li>0x0201—ECDSA with SHA2-256 digest</li>
+  <li>0x0202—ECDSA with SHA2-512 digest</li>
+  <li>0x0301—DSA with SHA2-256 digest</li>
+</ul>
+
+<p>
+All of the above signature algorithms are supported by the Android platform.
+Signing tools may support a subset of the algorithms.
+</p>
+
+<p>
+<strong>Supported keys sizes and EC curves:</strong>
+</p>
+
+<ul>
+  <li>RSA: 1024, 2048, 4096, 8192, 16384</li>
+  <li>EC: NIST P-256, P-384, P-521</li>
+  <li>DSA: 1024, 2048, 3072</li>
+</ul>
+
+<h2 id="integrity-protected-contents">Integrity-protected contents</h2>
+
+<p>
+For the purposes of protecting APK contents, an APK consists of four sections:
+</p>
+
+<ol>
+  <li>Contents of ZIP entries (from offset 0 until the start of APK Signing Block)</li>
+  <li>APK Signing Block</li>
+  <li>ZIP Central Directory</li>
+  <li>ZIP End of Central Directory</li>
+</ol>
+
+<p>
+  <img src="../images/apk-sections.png" alt="APK sections after signing" id="figure2" />
+</p>
+<p class="img-caption"><strong>Figure 2.</strong> APK sections after signing</p>
+
+<p>
+APK Signature Scheme v2 protects the integrity of sections 1, 3, 4, and the
+<code>signed data</code> blocks of the APK Signature Scheme v2 Block contained
+inside section 2.
+</p>
+
+<p>
+The integrity of sections 1, 3, and 4 is protected by one or more digests of
+their contents stored in <code>signed data</code> blocks which are, in
+turn, protected by one or more signatures.
+</p>
+
+<p>
+The digest over sections 1, 3, and 4 is computed as follows, similar to a
+two-level <a href="https://en.wikipedia.org/wiki/Merkle_tree">Merkle tree</a>.
+Each section is split into consecutive 1 MB (2<sup>20</sup> bytes) chunks. The last chunk
+in each section may be shorter. The digest of each chunk is computed over the
+concatenation of byte <code>0xa5</code>, the chunk’s length in bytes
+(little-endian uint32), and the chunk’s contents. The top-level digest is
+computed over the concatenation of byte <code>0x5a</code>, the number of chunks
+(little-endian uint32), and the concatenation of digests of the chunks in the
+order the chunks appear in the APK. The digest is computed in chunked fashion to
+enable to speed up the computation by parallelizing it.
+</p>
+
+<p>
+  <img src="../images/apk-integrity-protection.png" alt="APK digest" id="figure3" />
+</p>
+<p class="img-caption"><strong>Figure 3.</strong> APK digest</p>
+
+<p>
+Protection of section 4 (ZIP End of Central Directory) is complicated by the
+section containing the offset of ZIP Central Directory. The offset changes when
+the size of the APK Signing Block changes, for instance, when a new signature is
+added. Thus, when computing digest over the ZIP End of Central Directory, the
+field containing the offset of ZIP Central Directory must be treated as
+containing the offset of the APK Signing Block.
+</p>
+
+<h2 id="rollback-protections">Rollback Protections</h2>
+<p>
+An attacker could attempt to have a v2-signed APK verified as a v1-signed APK on
+Android platforms that support verifying v2-signed APK. To mitigate this attack,
+v2-signed APKs that are also v1-signed must contain an X-Android-APK-Signed
+attribute in the main section of their META-INF/*.SF files. The value of the
+attribute is a comma-separated set of APK signature scheme IDs (the ID of this
+scheme is 2). When verifying the v1 signature, APK verifier is required to
+reject APKs which do not have a signature for the APK signature scheme the
+verifier prefers from this set (e.g., v2 scheme). This protection relies on the
+fact that contents META-INF/*.SF files are protected by v1 signatures. See the
+section on
+<a href="#v1-verification">JAR signed APK verification</a>.
+</p>
+
+<p>
+An attacker could attempt to strip stronger signatures from the APK Signature
+Scheme v2 Block. To mitigate this attack, the list of signature algorithm IDs
+with which the APK was being signed is stored in the <code>signed data</code>
+block which is protected by each signature.
+</p>
+
+<h2 id="verification">Verification</h2>
+
+In Android 7.0, APKs can be verified according to the APK Signature Scheme v2
+(v2 scheme) or JAR signing (v1 scheme). Older platforms ignore v2 signatures
+and only verify v1 signatures.
+</p>
+
+<p>
+  <img src="../images/apk-validation-process.png" alt="APK signature verification process" id="figure4" />
+</p>
+<p class="img-caption"><strong>Figure 4.</strong> APK signature verification
+process (new steps in red)</p>
+
+<h3 id="v2-verification">APK Signature Scheme v2 verification</h3>
+<ol>
+  <li>Locate the APK Signing Block and verify that:
+    <ol>
+      <li>Two size fields of APK Signing Block contain the same value.</li>
+      <li>ZIP Central Directory is immediately followed by ZIP End of Central
+          Directory record.</li>
+      <li>ZIP End of Central Directory is not followed by more data.</li>
+    </ol>
+  </li>
+  <li>Locate the first APK Signature Scheme v2 Block inside the APK Signing Block.
+      If the v2 Block if present, proceed to step 3. Otherwise, fall back to
+      verifying the APK
+      <a href="#v1-verification">using v1 scheme</a>.</li>
+  <li>For each <code>signer</code> in the APK Signature Scheme v2 Block:
+    <ol>
+      <li>Choose the strongest supported <code>signature algorithm ID</code> from
+      <code>signatures</code>. The strength ordering is up to each
+      implementation/platform version.</li>
+      <li>Verify the corresponding <code>signature</code> from
+      <code>signatures</code> against <code>signed data</code> using <code>public
+      key</code>. (It is now safe to parse <code>signed data</code>.)</li>
+      <li>Verify that the ordered list of signature algorithm IDs in
+      <code>digests</code> and <code>signatures</code> is identical.  (This is to
+      prevent signature stripping/addition.)</li>
+      <li><a href="#integrity-protected-contents">Compute the digest of APK
+      contents</a> using the same digest algorithm as the digest algorithm used by the
+      signature algorithm.</li>
+      <li>Verify that the computed digest is identical to the corresponding
+      <code>digest</code> from <code>digests</code>.</li>
+      <li>Verify that SubjectPublicKeyInfo of the first <code>certificate</code> of
+      <code>certificates</code> is identical to <code>public key</code>.</li>
+    </ol>
+  </li>
+  <li>Verification succeeds if at least one <code>signer</code> was found and
+  step 3 succeeded for each found <code>signer</code>.</li>
+</ol>
+
+<p class="note"><strong>Note</strong>: APK must not be verified using
+the v1 scheme if a failure occurs in step 3 or 4.
+</p>
+
+<h3 id="v1-verification">JAR-signed APK verification (v1 scheme)</h3>
+<p>
+The JAR-signed APK is a
+<a href="https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Signed_JAR_File">standard
+signed JAR</a>, which must contain exactly the entries listed in
+META-INF/MANIFEST.MF and where all entries must be signed by the same set of
+signers. Its integrity is verified as follows:
+</p>
+
+<ol>
+  <li>Each signer is represented by a META-INF/&lt;signer&gt;.SF and
+  META-INF/&lt;signer&gt;.(RSA|DSA|EC) JAR entry.</li>
+  <li>&lt;signer&gt;.(RSA|DSA|EC) is a
+      <a href="https://tools.ietf.org/html/rfc5652">PKCS #7 CMS ContentInfo
+      with SignedData structure</a> whose signature is verified over the
+      &lt;signer&gt;.SF file.</li>
+  <li>&lt;signer&gt;.SF file contains a whole-file digest of the META-INF/MANIFEST.MF
+  and digests of each section of META-INF/MANIFEST.MF. The whole-file digest of
+  the MANIFEST.MF is verified. If that fails, the digest of each MANIFEST.MF
+  section is verified instead.</li>
+  <li>META-INF/MANIFEST.MF contains, for each integrity-protected JAR entry, a
+  correspondingly named section containing the digest of the entry’s uncompressed
+  contents. All these digests are verified.</li>
+  <li>APK verification fails if the APK contains JAR entries which are not listed
+  in the MANIFEST.MF and are not part of JAR signature.</li>
+</ol>
+
+<p>
+The protection chain is thus &lt;signer&gt;.(RSA|DSA|EC) -> &lt;signer&gt;.SF -> MANIFEST.MF
+-> contents of each integrity-protected JAR entry.
+</p>
+
diff --git a/src/security/enhancements/enhancements70.jd b/src/security/enhancements/enhancements70.jd
new file mode 100644
index 0000000..88d4763
--- /dev/null
+++ b/src/security/enhancements/enhancements70.jd
@@ -0,0 +1,53 @@
+page.title=Security Enhancements in Android 7.0
+@jd:body
+<!--
+    Copyright 2016 The Android Open Source Project
+
+    Licensed under the Apache License, Version 2.0 (the "License");
+    you may not use this file except in compliance with the License.
+    You may obtain a copy of the License at
+
+        http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing, software
+    distributed under the License is distributed on an "AS IS" BASIS,
+    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+    See the License for the specific language governing permissions and
+    limitations under the License.
+-->
+
+<p>Every Android release includes dozens of security enhancements to protect
+users. Here are some of the major security enhancements available in Android
+7.0:</p>
+
+<ul>
+  <li><strong>File-based encryption</strong>. Encrypting at the file level,
+  instead of encrypting the entire storage area as a single unit, better
+  isolates and protects individual users and profiles (such as personal and
+  work) on a device.</li>
+  <li><strong>Direct Boot</strong>. Enabled by file-based encryption, Direct
+  Boot allows certain apps such as alarm clock and accessibility features to
+  run when device is powered on but not unlocked.</li>
+  <li><strong>Verified Boot</strong>. Verified Boot is now strictly enforced to
+  prevent compromised devices from booting; it supports error correction to
+  improve reliability against non-malicious data corruption.</li>
+  <li><strong>SELinux</strong>. Updated SELinux configuration and increased
+  seccomp coverage further locks down the application sandbox and reduces attack
+  surface.</li>
+  <li><strong>Library load-order randomization and improved ASLR</strong>.
+  Increased randomness makes some code-reuse attacks less reliable.</li>
+  <li><strong>Kernel hardening</strong>. Added additional memory protection for
+  newer kernels by marking portions of kernel memory as read-only, restricting
+  kernel access to userspace addresses and further reducing the existing attack
+  surface.</li>
+  <li><strong>APK signature scheme v2</strong>. Introduced a whole-file signature
+  scheme that improves verification speed and strengthens integrity guarantees.</li>
+  <li><strong>Trusted CA store</strong>. To make it easier for apps to control
+  access to their secure network traffic, user-installed certificate authorities
+  and those installed through Device Admin APIs are no longer trusted by default
+  for apps targeting API Level 24+. Additionally, all new Android devices must
+  ship with the same trusted CA store.</li>
+  <li><strong>Network Security Config</strong>. Configure network security and TLS
+  through a declarative configuration file.</li>
+</ul>
+
diff --git a/src/security/images/apk-before-after-signing.png b/src/security/images/apk-before-after-signing.png
new file mode 100644
index 0000000..2202f62
--- /dev/null
+++ b/src/security/images/apk-before-after-signing.png
Binary files differ
diff --git a/src/security/images/apk-integrity-protection.png b/src/security/images/apk-integrity-protection.png
new file mode 100644
index 0000000..1b6e317
--- /dev/null
+++ b/src/security/images/apk-integrity-protection.png
Binary files differ
diff --git a/src/security/images/apk-sections.png b/src/security/images/apk-sections.png
new file mode 100644
index 0000000..27b8af5
--- /dev/null
+++ b/src/security/images/apk-sections.png
Binary files differ
diff --git a/src/security/images/apk-validation-process.png b/src/security/images/apk-validation-process.png
new file mode 100644
index 0000000..c0b2b84
--- /dev/null
+++ b/src/security/images/apk-validation-process.png
Binary files differ
diff --git a/src/security/overview/app-security.jd b/src/security/overview/app-security.jd
index 8b011fa..053a5fe 100644
--- a/src/security/overview/app-security.jd
+++ b/src/security/overview/app-security.jd
@@ -307,7 +307,8 @@
 Security Configuration</a> for more details.
 </p>
 <h2 id="application-signing">Application Signing</h2>
-<p>Code signing allows developers to identify the author of the application and to
+<p><a href="{@docRoot}security/apksigning/index.html">Code signing</a>
+  allows developers to identify the author of the application and to
   update their application without creating complicated interfaces and
   permissions. Every application that is run on the Android platform must be
   signed by the developer.  Applications that attempt to install without being
diff --git a/src/security/security_toc.cs b/src/security/security_toc.cs
index aa8f0da..19070eb 100644
--- a/src/security/security_toc.cs
+++ b/src/security/security_toc.cs
@@ -32,6 +32,7 @@
           </a>
         </div>
         <ul>
+          <li><a href="<?cs var:toroot ?>security/enhancements/enhancements70.html">Android 7.0</a></li>
           <li><a href="<?cs var:toroot ?>security/enhancements/enhancements60.html">Android 6.0</a></li>
           <li><a href="<?cs var:toroot ?>security/enhancements/enhancements50.html">Android 5.0</a></li>
           <li><a href="<?cs var:toroot ?>security/enhancements/enhancements44.html">Android 4.4</a></li>
@@ -61,6 +62,16 @@
   </li>
   <li class="nav-section">
     <div class="nav-section-header">
+      <a href="<?cs var:toroot ?>security/apksigning/index.html">
+        <span class="en">Application Signing</span>
+      </a>
+    </div>
+    <ul>
+      <li><a href="<?cs var:toroot ?>security/apksigning/v2.html">APK Signature Scheme v2</a></li>
+    </ul>
+  </li>
+  <li class="nav-section">
+    <div class="nav-section-header">
       <a href="<?cs var:toroot ?>security/authentication/index.html">
         <span class="en">Authentication</span>
       </a>
diff --git a/src/security/selinux/index.jd b/src/security/selinux/index.jd
index 8745f8e..f331a35 100644
--- a/src/security/selinux/index.jd
+++ b/src/security/selinux/index.jd
@@ -33,20 +33,27 @@
 Security-Enhanced Linux (SELinux) is used to further define the boundaries of
 the Android application sandbox.</p>
 
-<p>As part of the Android <a href="{@docRoot}devices/tech/security/index.html">security model</a>, Android uses SELinux to enforce mandatory access control (MAC) over all
-processes, even processes running with root/superuser privileges (a.k.a. Linux
-capabilities). SELinux enhances Android security by confining privileged
-processes and automating security policy creation.</p>
+<p>As part of the Android <a href="{@docRoot}security/index.html">
+security model</a>, Android uses SELinux to enforce mandatory access control
+(MAC) over all processes, even processes running with root/superuser privileges
+(a.k.a. Linux capabilities). SELinux enhances Android security by confining
+privileged processes and automating security policy creation.</p>
 
-<p>Contributions to it have been made by a number of companies and organizations;
-all Android code and contributors are publicly available for review on <a href="https://android.googlesource.com/">android.googlesource.com</a>. With SELinux, Android can better protect and confine system services, control
+<p>Contributions to it have been made by a number
+of companies and organizations; all Android code
+and contributors are publicly available for review on <a
+href="https://android.googlesource.com/">android.googlesource.com</a>. With
+SELinux, Android can better protect and confine system services, control
 access to application data and system logs, reduce the effects of malicious
 software, and protect users from potential flaws in code on mobile devices.</p>
 
-<p>Android includes SELinux in enforcing mode and a corresponding security policy
-that works by default across the <a href="https://android.googlesource.com/">Android Open Source Project</a>. In enforcing mode, illegitimate actions are prevented and all attempted
-violations are logged by the kernel to <code>dmesg</code> and <code>logcat</code>. Android device manufacturers should gather information about errors so they
-may refine their software and SELinux policies before enforcing them.</p>
+<p>Android includes SELinux in enforcing mode and a
+corresponding security policy that works by default across the <a
+href="https://android.googlesource.com/">Android Open Source Project</a>. In
+enforcing mode, illegitimate actions are prevented and all attempted violations
+are logged by the kernel to <code>dmesg</code> and <code>logcat</code>. Android
+device manufacturers should gather information about errors so they may
+refine their software and SELinux policies before enforcing them.</p>
 
 <h2 id=background>Background</h2>
 
@@ -63,38 +70,56 @@
 Per-domain permissive mode also enables policy development for new services
 while keeping the rest of the system enforcing.</p>
 
-<p>In the Android 5.0 (L) release, Android moves to full enforcement of SELinux. This builds
-upon the permissive release of 4.3 and the partial enforcement of 4.4. In
-short, Android is shifting from enforcement on a limited set of crucial domains
-(<code>installd</code>, <code>netd</code>, <code>vold</code> and <code>zygote</code>) to everything (more than 60 domains). This means manufacturers will have to
-better understand and scale their SELinux implementations to provide compatible
-devices. Understand that:</p>
+<p>In the Android 5.0 (L) release, Android moves to full enforcement of
+SELinux. This builds upon the permissive release of 4.3 and the partial
+enforcement of 4.4. In short, Android is shifting from enforcement on a
+limited set of crucial domains (<code>installd</code>, <code>netd</code>,
+<code>vold</code> and <code>zygote</code>) to everything (more than 60
+domains). This means manufacturers will have to better understand and scale
+their SELinux implementations to provide compatible devices. Understand
+that:</p>
+
 
 <ul>
-  <li> Everything is in enforcing mode in the 5.0 release
-  <li> No processes other than <code>init</code> should run in the <code>init</code> domain
-  <li> Any generic denial (for a block_device, socket_device, default_service, etc.)
-indicates that device needs a special domain
+<li>Everything is in enforcing mode in the 5.0 release</li>
+<li> No processes other than <code>init</code> should run in the
+<code>init</code> domain</li>
+<li> Any generic denial (for a block_device, socket_device, default_service,
+etc.) indicates that device needs a special domain</li>
 </ul>
 
 <h2 id=supporting_documentation>Supporting documentation</h2>
 
 <p>See the documentation below for details on constructing useful policies:</p>
 
-<p><a href="http://seandroid.bitbucket.org/PapersandPresentations.html">http://seandroid.bitbucket.org/PapersandPresentations.html</a></p>
+<p><a href="http://seandroid.bitbucket.org/PapersandPresentations.html">
+http://seandroid.bitbucket.org/PapersandPresentations.html</a></p>
 
-<p><a href="https://www.codeproject.com/Articles/806904/Android-Security-Customization-with-SEAndroid">https://www.codeproject.com/Articles/806904/Android-Security-Customization-with-SEAndroid</a></p>
+<p><a href="https://www.codeproject.com/Articles/806904/Android-Security-Customization-with-SEAndroid">
+https://www.codeproject.com/Articles/806904/
+Android-Security-Customization-with-SEAndroid</a></p>
 
-<p><a href="https://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf">https://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf</a></p>
+<p><a href="https://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf">
+https://events.linuxfoundation.org/sites/events/files/slides/
+abs2014_seforandroid_smalley.pdf</a></p>
 
-<p><a href="https://www.internetsociety.org/sites/default/files/02_4.pdf">https://www.internetsociety.org/sites/default/files/02_4.pdf</a></p>
+<p><a href="https://www.internetsociety.org/sites/default/files/02_4.pdf">
+https://www.internetsociety.org/sites/default/files/02_4.pdf</a></p>
 
-<p><a href="http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf">http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf</a></p>
+<p><a href="http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf">
+http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf</a></p>
 
-<p><a href="http://selinuxproject.org/page/ObjectClassesPerms">http://selinuxproject.org/page/ObjectClassesPerms</a></p>
+<p><a href="http://selinuxproject.org/page/ObjectClassesPerms">
+http://selinuxproject.org/page/ObjectClassesPerms</a></p>
 
-<p><a href="https://www.nsa.gov/research/_files/publications/implementing_selinux.pdf">https://www.nsa.gov/research/_files/publications/implementing_selinux.pdf</a></p>
+<p><a href="https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/implementing-selinux-as-linux-security-module-report.pdf">
+https://www.nsa.gov/resources/everyone/digital-media-center/publications/
+research-papers/assets/files/
+implementing-selinux-as-linux-security-module-report.pdf</a></p>
 
-<p><a href="https://www.nsa.gov/research/_files/publications/selinux_configuring_policy.pdf">https://www.nsa.gov/research/_files/publications/selinux_configuring_policy.pdf</a></p>
+<p><a href="https://www.nsa.gov/resources/everyone/digital-media-center/publications/research-papers/assets/files/configuring-selinux-policy-report.pdf">
+https://www.nsa.gov/resources/everyone/digital-media-center/publications/
+research-papers/assets/files/configuring-selinux-policy-report.pdf</a></p>
 
-<p><a href="https://www.gnu.org/software/m4/manual/index.html">https://www.gnu.org/software/m4/manual/index.html</a></p>
+<p><a href="https://www.gnu.org/software/m4/manual/index.html">
+https://www.gnu.org/software/m4/manual/index.html</a></p>