11 files changed, 110 insertions, 16 deletions
diff --git a/en/devices/architecture/dto/multiple.html b/en/devices/architecture/dto/multiple.html
index 52f47a46..f431a9d7 100644
--- a/en/devices/architecture/dto/multiple.html
+++ b/en/devices/architecture/dto/multiple.html
@@ -43,12 +43,18 @@ DTs.</figcaption>
 <p>The bootloader should be able to:</p>
 
 <ul>
-<li>read the SoC ID and select the main DT correspondingly, and</li>
-<li>read the board ID and select the overlay DT accordingly.</li>
+<li>Read the SoC ID and select the corresponding main device tree, and</li>
+<li>Read the board ID and select the set of overlay device trees accordingly.
+</li>
 </ul>
 
-<p>Only one main DT and one overlay DT are selected for use at runtime, and the
-selected pair must be compatible.</p>
+<p>Only one main DT should be selected for use at runtime. Multiple overlay DTs
+may be selected but they must be compatible with the chosen main DT. Using
+multiple overlays can help avoid storing one overlay per board within the DTBO
+partition and enable the bootloader to determine the subset of required overlays
+based on the board ID (or possibly by probing the peripherals). For
+example, Board A may need the devices added by the overlays 1, 3, and 5 while
+Board B may need the devices added by the overlays 1, 4, and 5.</p>
 
 <h2 id=partition>Partitioning</h2>
 <p>To partition, determine a bootloader runtime-accessible and trusted location
diff --git a/en/devices/architecture/hidl-cpp/index.html b/en/devices/architecture/hidl-cpp/index.html
index 7d8466cb..28c4aa0a 100644
--- a/en/devices/architecture/hidl-cpp/index.html
+++ b/en/devices/architecture/hidl-cpp/index.html
@@ -117,7 +117,7 @@ a binderized service. Example daemon code (for pure binderized service):</p>
 
 <pre class="prettyprint">
 int main(int /* argc */, char* /* argv */ []) {
-    Nfc nfc = new Nfc();
+    sp<INfc> nfc = new Nfc();
     const status_t status = nfc-&gt;registerAsService();
     if (status != ::android::OK) {
         return 1; // or handle error
diff --git a/en/devices/architecture/hidl-java/index.html b/en/devices/architecture/hidl-java/index.html
index 3b94247e..c4218160 100644
--- a/en/devices/architecture/hidl-java/index.html
+++ b/en/devices/architecture/hidl-java/index.html
@@ -136,7 +136,7 @@ to run the service is:</p>
 import android.hardware.foo.V1_0.IFoo;
 import android.hardware.foo.V1_0.IFooCallback.Stub;
 ....
-class FooCallback extends IFoo.Stub {
+class FooCallback extends IFooCallback.Stub {
     // implement methods
 }
 ....
diff --git a/en/devices/architecture/hidl/versioning.html b/en/devices/architecture/hidl/versioning.html
index 13bce259..52552f0c 100644
--- a/en/devices/architecture/hidl/versioning.html
+++ b/en/devices/architecture/hidl/versioning.html
@@ -112,6 +112,54 @@ types from the older version of the package, and inheritance of a subset of
 old-package interfaces.</li>
 </ul>
 
+<h2 id=structuring>Structuring interfaces</h2>
+
+<p>For a well structured interface, adding new types of functionality that
+are not part of the original design should require a modification to the HIDL
+interface. Conversely, if you can or expect to make a change on both sides of
+the interface that introduces new functionality without changing the interface
+itself, then the interface is not structured.</p>
+
+<p>Treble supports separately-compiled vendor and system components in which the
+<code>vendor.img</code> on a device and the <code>system.img</code> can be
+compiled separately. All interactions between <code>vendor.img</code> and
+<code>system.img</code> must be explicitly and thoroughly defined so they can
+continue to work for many years. This includes many API surfaces, but a major
+surface is the IPC mechanism HIDL uses for interprocess communication on the
+<code>system.img</code>/<code>vendor.img</code> boundary.</p>
+
+<h3 id="structuring-requirements">Requirements</h3>
+<p>All data passed through HIDL must be explicitly defined. To ensure an
+implementation and client can continue to work together even when compiled
+separately or developed on independently, data must adhere to the following
+requirements:</p>
+
+<ul>
+<li>Can be described in HIDL directly (using structs enums, etc.) with
+semantic names and meaning.</li>
+<li>Can be described by a public standard such as ISO/IEC 7816.</li>
+<li>Can be described by a hardware standard or physical layout of hardware.</li>
+<li>Can be opaque data (such as public keys, ids, etc.) if necessary.</li>
+</ul>
+
+<p>If opague data is used, it must be read only by one side of the HIDL
+interface. For example, if <code>vendor.img</code> code gives a component on the
+<code>system.img</code> a string message or <code>vec&lt;uint8_t&gt;</code>
+data, that data cannot be parsed by the <code>system.img</code> itself; it can
+only be passed back to <code>vendor.img</code> to interpret. <strong>When
+passing a value from <code>vendor.img</code> to vendor code on
+<code>system.img</code> or to another device, the format of the data and how it
+is to be interpreted must be exactly described and is still part of the
+interface</strong>.</p>
+
+<h3 id="structuring-guidelines">Guidelines</h3>
+
+<p>You should be able to write an implementation or client of a HAL using only
+the .hal files (i.e. you should not need to look at the Android source or public
+standards). We recommend specifying the exact required behavior. Statements such
+as "an implementation may do A or B" encourage implementations to become
+intertwined with the clients they are developed with.</p>
+
 <h2 id=code-layout>HIDL code layout</h2>
 <p>HIDL includes core and vendor packages.</p>
 
diff --git a/en/devices/tech/config/filesystem.html b/en/devices/tech/config/filesystem.html
index 10b7f0b4..73633943 100644
--- a/en/devices/tech/config/filesystem.html
+++ b/en/devices/tech/config/filesystem.html
@@ -244,7 +244,8 @@ the autogenerated header file by adding to your module's <code>Android.mk</code>
 and including the empty faux library. For example, in <code>Android.mk</code>,
 add the following:</p>
 
-<pre class="prettyprint"> LOCAL_STATIC_LIBRARIES := liboemaids</pre>
+<pre class="prettyprint">LOCAL_HEADER_LIBRARIES := oemaids_headers</pre>
+
 <p>In your C code, <code>#include "generated_oem_aid.h"</code> and start using
 the declared identifiers. For example, in <code>my_file.c</code>, add the
 following: </p>
diff --git a/en/devices/tech/config/namespaces_libraries.html b/en/devices/tech/config/namespaces_libraries.html
index b91cbe23..1e94bf1b 100644
--- a/en/devices/tech/config/namespaces_libraries.html
+++ b/en/devices/tech/config/namespaces_libraries.html
@@ -61,6 +61,26 @@ additional native libraries accessible to apps by putting them under the
 <code>/vendor/etc/public.libraries.txt</code>
 </p>
 
+<p>
+Starting from Android 8.0, vendor public libraries have the following additional
+restrictions and required setups:
+</p>
+
+<ol>
+  <li>The native library in vendor must be properly labeled so it can be
+    accessible to apps. If access is required by any apps (including third
+    party apps), the library must be labeled as <code>same_process_hal_file</code>
+    in a vendor-specific <code>file_contexts</code> file as follows:
+    <pre class="devsite-click-to-copy">/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0</pre>
+    where <code>libnative.so</code> is the name of the native library.
+  </li>
+  <li>The library, either directly or transitively via its dependencies, must not
+    depend on system libraries other than VNDK-SP and LLNDK libraries. The list of
+    VNDK-SP and LLNDK libraries can be found at
+    <code>development/vndk/tools/definition/tool/datasets/eligible-list-&lt;version&gt;-release.csv</code>.
+  </li>
+</ol>
+
 <h2 id="updating-app-non-public">Updating apps to not use non-public native libraries</h2>
 
 <p>
diff --git a/en/devices/tech/config/perms-whitelist.html b/en/devices/tech/config/perms-whitelist.html
index c3de0de0..918f89eb 100644
--- a/en/devices/tech/config/perms-whitelist.html
+++ b/en/devices/tech/config/perms-whitelist.html
@@ -135,7 +135,7 @@
   transitional log-mode:
 </p>
 
-<pre class="devsite-click-to-copy">ro.control_privapp_permission=log</pre>
+<pre class="devsite-click-to-copy">ro.control_privapp_permissions=log</pre>
 
 <p>
   Violations are reported in the log file, but permissions are still granted.
@@ -158,11 +158,11 @@ PackageManager: Privileged permission {PERMISSION_NAME} for package {PACKAGE_NAM
 
 <p>
   After whitelists are in place, enable runtime enforcement by setting the build
-  property <code>ro.control_privapp_permission=enforce</code>.
+  property <code>ro.control_privapp_permissions=enforce</code>.
 </p>
 
 <aside class="note"><strong>Note:</strong> The
-  <code>ro.control_privapp_permission</code> property state must adhere to
+  <code>ro.control_privapp_permissions</code> property state must adhere to
   <a href="/compatibility/android-cdd#9_1_permissions">CDD section 9.1
   requirements</a>.</aside>
 
diff --git a/en/devices/tech/config/uicc.html b/en/devices/tech/config/uicc.html
index 1fa6952c..96c1d360 100644
--- a/en/devices/tech/config/uicc.html
+++ b/en/devices/tech/config/uicc.html
@@ -29,7 +29,7 @@ Android platform loads certificates stored on a UICC and grants permission to
 apps signed by these certificates to make calls to a handful of special APIs.
 </p>
 <p>Android 7.0 extends this feature to support other storage sources, such as
-Access File Rule (ARF), for UICC carrier privilege rules, dramatically
+Access Rule File (ARF), for UICC carrier privilege rules, dramatically
 increasing the number of carriers that can use the APIs. For an API reference,
 see <a href="#carrierconfigmanager">CarrierConfigManager</a>; for instructions,
 see <a href="/devices/tech/config/carrier.html">Carrier
diff --git a/en/devices/tech/ota/ab/index.html b/en/devices/tech/ota/ab/index.html
index 48a9fea5..c2a9c447 100644
--- a/en/devices/tech/ota/ab/index.html
+++ b/en/devices/tech/ota/ab/index.html
@@ -31,6 +31,9 @@
       updates successfully.
     </p>
 
+    <p>For more information about A/B system updates and how they work, see
+      <a href="#slots">Partition selection (slots)</a>.
+
     <p>A/B system updates provide the following benefits:</p>
 
     <ul>
diff --git a/en/devices/tech/ota/index.html b/en/devices/tech/ota/index.html
index 1565e3b2..7b2f0dd0 100644
--- a/en/devices/tech/ota/index.html
+++ b/en/devices/tech/ota/index.html
@@ -35,7 +35,7 @@
       applications installed by the user from Google Play.
     </p>
 
-    <h2 id="ab_updates">A/B updates</h2>
+    <h2 id="ab_updates">A/B (seamless) system updates</h2>
 
       <p>
         Modern A/B devices have two copies of each partition, A and B. Devices
@@ -50,7 +50,7 @@
         </a>.
       </p>
 
-    <h2 id="nonab_updates">Non-A/B updates</h2>
+    <h2 id="nonab_updates">Non-A/B system updates</h2>
 
       <p>
         Older devices have a special recovery partition containing the software
diff --git a/en/devices/tech/perf/boot-times.html b/en/devices/tech/perf/boot-times.html
index a7588301..fb6ad441 100644
--- a/en/devices/tech/perf/boot-times.html
+++ b/en/devices/tech/perf/boot-times.html
@@ -255,17 +255,27 @@ us uncover many meaningful bugs in some Android device drivers).
 Many processes launch during boot, but only components in critical path
 (bootloader > kernel > init > file system mount > zygote > system server)
 directly affect boot time. Profile <strong>initcall</strong> during kernel
-booting to identify peripheral/components that are not critical to the
-start init process, then delay those peripherals/components until later
-in the boot process.
+booting to identify peripheral/components that are slow and not critical
+to start init process, then delay those peripherals/components until later
+in the boot process by moving into loadable kernel modules. Moving to
+asynchronous device/driver probe can also help to parallel slow components
+in kernel > init critical path.
 </p>
 
 <pre
 class="prettyprint">
 BoardConfig-common.mk:
     BOARD_KERNEL_CMDLINE += initcall_debug ignore_loglevel
+
+driver:
+    .probe_type = PROBE_PREFER_ASYNCHRONOUS,
 </pre>
 
+<p class="note">
+<strong>Note:</strong> Driver dependencies must be resolved carefully by adding
+<code>EPROBEDEFER</code> support.
+</p>
+
 <h2 id="optimizing-i-o-efficiency">Optimizing I/O efficiency</h2>
 
 <p>
@@ -422,6 +432,12 @@ early stage init should be deferred to boot completed.</li></ul>
 </li>
 </ul>
 
+<p class="note">
+<strong>Note:</strong> Property service is part of init process, so calling
+<code>setproperty</code> during boot can lead a long delay if init is busy in
+builtin commands.
+</p>
+
 <h3 id="using-scheduler-tuning">Using scheduler tuning</h3>
 
 <p>