Docs: Changes to source.android.com

  - 173948031 Add OWNERS.android file for find-owners plugin. Used by G... by Billy Lamberta <blamb@google.com>
  - 173776667 Update debuggerd docs for O. by Android Partner Docs <noreply@android.com>
  - 173720411 Add section for faster native methods. by Billy Lamberta <blamb@google.com>
  - 173689528 Devsite localized content from translation request fe9324... by Android Partner Docs <noreply@android.com>
  - 173689519 Devsite localized content from translation request 2d4a7b... by Android Partner Docs <noreply@android.com>
  - 173558006 Devsite localized content from translation request 923cb2... by Android Partner Docs <noreply@android.com>
  - 173409559 Devsite localized content from translation request 5edac3... by Android Partner Docs <noreply@android.com>
  - 173409556 Devsite localized content from translation request cb5732... by Android Partner Docs <noreply@android.com>
  - 173409550 Devsite localized content from translation request cf8a60... by Android Partner Docs <noreply@android.com>
  - 173268562 Devsite localized content from translation request 4cfd64... by Android Partner Docs <noreply@android.com>
  - 173209155 Update build numbers for Oreo DR releases by Android Partner Docs <noreply@android.com>
  - 173187065 Devsite localized content from translation request 6733e6... by Android Partner Docs <noreply@android.com>
  - 173150380 Add parentheses after .bash_profile function name for rea... by Christina Nguyen <cqn@google.com>

PiperOrigin-RevId: 173948031
Change-Id: Ia1ad2f2bed814cbd407cca162c700496fde40da7

4 files changed, 293 insertions, 156 deletions

diff --git a/en/devices/tech/dalvik/improvements.html b/en/devices/tech/dalvik/improvements.html
index aa41a1f0..9317e336 100644
--- a/en/devices/tech/dalvik/improvements.html
+++ b/en/devices/tech/dalvik/improvements.html
@@ -22,131 +22,161 @@
   -->
 
 <p>
-The Android runtime (ART) has been improved significantly in the Android 8.0
-release. The list below summarizes enhancements device manufacturers can expect
-in ART.
+  The Android runtime (ART) has been improved significantly in the Android 8.0
+  release. The list below summarizes enhancements device manufacturers can expect
+  in ART.
 </p>
 
 <h2 id="concurrent-compacting-gc">Concurrent compacting garbage collector</h2>
 
-<p>As announced at Google I/O, ART features a new concurrent compacting garbage
-collector (GC) in Android 8.0. This collector compacts the heap every time GC
-runs and while the app is running, with only one short pause for processing
-thread roots. Here are its benefits:</p>
+<p>
+  As announced at Google I/O, ART features a new concurrent compacting garbage
+  collector (GC) in Android 8.0. This collector compacts the heap every time GC
+  runs and while the app is running, with only one short pause for processing
+  thread roots. Here are its benefits:
+</p>
 
 <ul>
-  <li>GC always compacts the heap: 32% smaller heap sizes on average compared
-    to Android 7.0.</li>
-  <li>Compaction enables thread local bump pointer object allocation:
-    Allocations are 70% faster than in Android 7.0.</li>
-  <li>Offers 85% smaller pause times for the H2 benchmark compared to the
-    Android 7.0 GC.</li>
-  <li>Pause times no longer scale with heap size; apps should be able to use
-    large heaps without worrying about jank.</li>
+  <li>
+    GC always compacts the heap: 32% smaller heap sizes on average compared to
+    Android 7.0.
+  </li>
+  <li>
+    Compaction enables thread local bump pointer object allocation: Allocations
+    are 70% faster than in Android 7.0.
+  </li>
+  <li>
+    Offers 85% smaller pause times for the H2 benchmark compared to the Android
+    7.0 GC.
+  </li>
+  <li>
+    Pause times no longer scale with heap size; apps should be able to use large
+    heaps without worrying about jank.
+  </li>
   <li>GC implementation detail - Read barriers:
     <ul>
-      <li>Read barriers are a small amount of work done for each object field
-        read.</li>
-      <li>These are optimized in the compiler, but might slow down some use
-        cases.</li>
+      <li>
+        Read barriers are a small amount of work done for each object field read.
+      </li>
+      <li>
+        These are optimized in the compiler, but might slow down some use cases.
+      </li>
     </ul>
 </ul>
 
 <h2 id="loop-optimizations">Loop optimizations</h2>
 
 <p>
-A wide variety of loop optimizations are employed by ART in the Android 8.0
-release:
-</p>
-   <ul>
-     <li>Bounds check eliminations
-       <ul>
-         <li>Static: ranges are proven to be within bounds at compile-time
-         <li>Dynamic: run-time tests ensure loops stay within bounds (deopt otherwise)
-       </ul>
-     <li>Induction variable eliminations
-       <ul>
-         <li>Remove dead induction
-         <li>Replace induction that is used only after the loop by closed-form expressions
-       </ul>
-     <li>Dead code elimination inside the loop-body, removal of whole loops that
-become dead
-     <li>Strength reduction
-     <li>Loop transformations: reversal, interchanging, splitting, unrolling,
-unimodular, etc.
-     <li>SIMDization (also called vectorization)</li>
-   </ul>
-
-<p>
-The loop optimizer resides in its own optimization pass in the ART compiler.
-Most loop optimizations are similar to optimizations and simplification
-elsewhere. Challenges arise with some optimizations that rewrite the CFG in a
-more than usual elaborate way, because most CFG utilities (see nodes.h) focus on
-building a CFG, not rewriting one.
+  A wide variety of loop optimizations are employed by ART in the Android 8.0
+  release:
+</p>
+
+<ul>
+  <li>Bounds check eliminations
+    <ul>
+      <li>Static: ranges are proven to be within bounds at compile-time</li>
+      <li>
+        Dynamic: run-time tests ensure loops stay within bounds (deopt otherwise)
+      </li>
+    </ul>
+  </li>
+  <li>Induction variable eliminations
+    <ul>
+      <li>Remove dead induction</li>
+      <li>
+        Replace induction that is used only after the loop by closed-form
+        expressions
+      </li>
+    </ul>
+  </li>
+  <li>
+    Dead code elimination inside the loop-body, removal of whole loops that
+    become dead
+  </li>
+  <li>Strength reduction</li>
+  <li>
+    Loop transformations: reversal, interchanging, splitting, unrolling,
+    unimodular, etc.
+  </li>
+  <li>SIMDization (also called vectorization)</li>
+</ul>
+
+<p>
+  The loop optimizer resides in its own optimization pass in the ART compiler.
+  Most loop optimizations are similar to optimizations and simplification
+  elsewhere. Challenges arise with some optimizations that rewrite the CFG in a
+  more than usual elaborate way, because most CFG utilities (see nodes.h) focus
+  on building a CFG, not rewriting one.
 </p>
 
 <h2 id="class-hierarchy-analysis">Class hierarchy analysis</h2>
 
 <p>
-ART in Android 8.0 uses Class Hierarchy Analysis (CHA), a compiler optimization
-that devirtualizes virtual calls into direct calls based on the information
-generated by analyzing class hierarchies. Virtual calls are expensive since they
-are implemented around a vtable lookup, and they take a couple of dependent
-loads. Also virtual calls cannot be inlined.
-</p>
-
-<p>
-Here is a summary of related enhancements:
-</p>
-   <ul>
-     <li>Dynamic single-implementation method status updating - At the end of class
-linking time, when vtable has been populated, ART conducts an entry-by-entry
-comparison to the vtable of the super class.</li>
-     <li>Compiler optimization - The compiler will take advantage of the
-single-implementation info of a method. If a method A.foo has
-single-implementation flag set, compiler will devirtualize the virtual call into
-a direct call, and further try to inline the direct call as a result.</li>
-     <li>Compiled code invalidation - Also at the end of class linking time when
-single-implementation info is updated, if method A.foo that previously had
-single-implementation but that status is now invalidated, all compiled code that
-depends on the assumption that method A.foo has single-implementation needs to
-have their compiled code invalidated.</li>
-     <li>Deoptimization - For live compiled code that's on stack, deoptimization will
-be initiated to force the invalidated compiled code into interpreter mode to
-guarantee correctness. A new mechanism of deoptimization which is a hybrid of
-synchronous and asynchronous deoptimization will be used.</li>
+  ART in Android 8.0 uses Class Hierarchy Analysis (CHA), a compiler optimization
+  that devirtualizes virtual calls into direct calls based on the information
+  generated by analyzing class hierarchies. Virtual calls are expensive since
+  they are implemented around a vtable lookup, and they take a couple of
+  dependent loads. Also virtual calls cannot be inlined.
+</p>
+
+<p>Here is a summary of related enhancements:</p>
+
+<ul>
+  <li>
+    Dynamic single-implementation method status updating - At the end of class
+    linking time, when vtable has been populated, ART conducts an entry-by-entry
+    comparison to the vtable of the super class.
+  </li>
+  <li>Compiler optimization - The compiler will take advantage of the
+    single-implementation info of a method. If a method A.foo has
+    single-implementation flag set, compiler will devirtualize the virtual call
+    into a direct call, and further try to inline the direct call as a result.
+  </li>
+  <li>
+    Compiled code invalidation - Also at the end of class linking time when
+    single-implementation info is updated, if method A.foo that previously had
+    single-implementation but that status is now invalidated, all compiled code
+    that depends on the assumption that method A.foo has single-implementation
+    needs to have their compiled code invalidated.
+  </li>
+  <li>
+    Deoptimization - For live compiled code that's on stack, deoptimization will
+    be initiated to force the invalidated compiled code into interpreter mode to
+    guarantee correctness. A new mechanism of deoptimization which is a hybrid of
+    synchronous and asynchronous deoptimization will be used.
+  </li>
 </ul>
 
 <h2 id="inline-caches-in-oat-files">Inline caches in .oat files</h2>
 
 <p>
-ART now employs inline caches and optimizes the call sites for which enough data
-exists. The inline caches feature records additional runtime information into
-profiles and uses it to add dynamic optimizations to ahead of time compilation.
+  ART now employs inline caches and optimizes the call sites for which enough
+  data exists. The inline caches feature records additional runtime information
+  into profiles and uses it to add dynamic optimizations to ahead of time compilation.
 </p>
 
 <h2 id="dexlayout">Dexlayout</h2>
 
 <p>
-Dexlayout is a library introduced in Android 8.0 to analyze dex files and reorder
-them according to a profile. Dexlayout aims to use runtime profiling information
-to reorder sections of the dex file during idle maintenance compilation on
-device. By grouping together parts of the dex file that are often accessed
-together, programs can have better memory access patterns from improved
-locality, saving RAM and shortening start up time.
+  Dexlayout is a library introduced in Android 8.0 to analyze dex files and
+  reorder them according to a profile. Dexlayout aims to use runtime profiling
+  information to reorder sections of the dex file during idle maintenance
+  compilation on device. By grouping together parts of the dex file that are
+  often accessed together, programs can have better memory access patterns from
+  improved locality, saving RAM and shortening start up time.
 </p>
 
 <p>
-Since profile information is currently available only after apps have been run,
-dexlayout is integrated in dex2oat's on-device compilation during idle
-maintenance.
+  Since profile information is currently available only after apps have been run,
+  dexlayout is integrated in dex2oat's on-device compilation during idle
+  maintenance.
 </p>
 
 <h2 id="dex-cache-removal">Dex cache removal</h2>
 
 <p>
-Up to Android 7.0, the DexCache object owned four large arrays, proportional to the
-number of certain elements in the DexFile, namely:
+  Up to Android 7.0, the DexCache object owned four large arrays, proportional to
+  the number of certain elements in the DexFile, namely:
 </p>
 
 <ul>
@@ -172,60 +202,145 @@ number of certain elements in the DexFile, namely:
 <h2 id="interpreter-performance">Interpreter performance</h2>
 
 <p>
-Interpreter performance significantly improved in the Android 7.0 release with the
-introduction of "mterp" - an interpreter featuring a core fetch/decode/interpret
-mechanism written in assembly language.  Mterp is modelled after the fast Dalvik
-interpreter, and supports arm, arm64, x86, x86_64, mips and mips64.  For
-computational code, Art's mterp is roughly comparable to Dalvik's fast
-interpreter.  However, in some situations it can be significantly - and even
-dramatically - slower:
+  Interpreter performance significantly improved in the Android 7.0 release with
+  the introduction of "mterp" - an interpreter featuring a core
+  fetch/decode/interpret mechanism written in assembly language.  Mterp is
+  modelled after the fast Dalvik interpreter, and supports arm, arm64, x86,
+  x86_64, mips and mips64.  For computational code, Art's mterp is roughly
+  comparable to Dalvik's fast interpreter.  However, in some situations it can be
+  significantly - and even dramatically - slower:
 </p>
 
-   <ol>
-     <li>Invoke performance.</li>
-     <li>String manipulation, and other heavy users of methods recognized as
-intrinsics in Dalvik.</li>
-     <li>Higher stack memory usage.</li>
-   </ol>
+<ol>
+  <li>Invoke performance.</li>
+  <li>
+    String manipulation, and other heavy users of methods recognized as
+    intrinsics in Dalvik.
+  </li>
+  <li>Higher stack memory usage.</li>
+</ol>
 
-<p>
-Android 8.0 addresses these issues.
-</p>
+<p>Android 8.0 addresses these issues.</p>
 
 <h2 id="more-inlining">More inlining</h2>
 
 <p>
-Since Android 6.0, ART can inline any call within the same dex files, but could
-only inline leaf methods from different dex files. There were two reasons for
-this limitation:
+  Since Android 6.0, ART can inline any call within the same dex files, but could
+  only inline leaf methods from different dex files. There were two reasons for
+  this limitation:
 </p>
 
-   <ol>
-     <li>Inlining from another dex file requires to use the dex cache of that other
-dex file, unlike same dex file inlining, which could just re-use the dex cache
-of the caller. The dex cache is needed in compiled code for a couple of
-instructions like static calls, string load, or class load.
-     <li>The stack maps are only encoding a method index within the current dex
-file.</li>
-   </ol>
+<ol>
+  <li>
+  Inlining from another dex file requires to use the dex cache of that other
+  dex file, unlike same dex file inlining, which could just re-use the dex cache
+  of the caller. The dex cache is needed in compiled code for a couple of
+  instructions like static calls, string load, or class load.
+  <li>
+    The stack maps are only encoding a method index within the current dex file.
+  </li>
+</ol>
    
-<p>
-To address these limitations, Android 8.0:
-</p>
+<p>To address these limitations, Android 8.0:</p>
 
-   <ol>
-     <li>Removes dex cache access from compiled code (also see section "Dex cache
+<ol>
+  <li>Removes dex cache access from compiled code (also see section "Dex cache
 removal")</li>
-     <li>Extends stack map encoding.</li>
-   </ol>
+  <li>Extends stack map encoding.</li>
+</ol>
 
 <h2 id="synchronization-improvements">Synchronization improvements</h2>
+ 
+<p>
+  The ART team tuned the MonitorEnter/MonitorExit code paths, and reduced our
+  reliance on traditional memory barriers on ARMv8, replacing them with newer
+  (acquire/release) instructions where possible.
+</p>
+
+<h2 id="faster-native-methods">Faster native methods</h2>
+
+<p>
+  Faster native calls to the Java Native Interface (JNI) are available using
+  the <a class="external"
+href="https://android.googlesource.com/platform/libcore/+/master/dalvik/src/main/java/dalvik/annotation/optimization/FastNative.java"
+><code>@FastNative</code></a> and <a class="external"
+href="https://android.googlesource.com/platform/libcore/+/master/dalvik/src/main/java/dalvik/annotation/optimization/CriticalNative.java"
+><code>@CriticalNative</code></a> annotations. These built-in ART runtime
+  optimizations speed up JNI transitions and replace the now deprecated
+  <em>!bang&nbsp;JNI</em> notation. The annotations have no effect on non-native
+  methods and are only available to platform Java Language code on the
+  <code>bootclasspath</code> (no Play Store updates).
+</p>
 
 <p>
-The ART team tuned the MonitorEnter/MonitorExit code paths, and reduced our
-reliance on traditional memory barriers on ARMv8, replacing them with newer
-(acquire/release) instructions where possible.
+  The <code>@FastNative</code> annotation supports non-static methods. Use this
+  if a method accesses a <code>jobject</code> as a parameter or return value.
 </p>
 
+<p>
+  The <code>@CriticalNative</code> annotation provides an even faster way to run
+  native methods, with the following restrictions:
+</p>
+
+<ul>
+  <li>
+    Methods must be static—no objects for parameters, return values, or an
+    implicit <code>this</code>.
+  </li>
+  <li>Only primitive types are passed to the native method.</li>
+  <li>
+    The native method does not use the <code>JNIEnv</code> and
+    <code>jclass</code> parameters in its function definition.
+  </li>
+  <li>
+    The method must be registered with <code>RegisterNatives</code> instead of
+    relying on dynamic JNI linking.
+  </li>
+</ul>
+
+<aside class="caution">
+  <p>
+    The <code>@FastNative</code> and <code>@CriticalNative</code> annotations
+    disable garbage collection while executing a native method. Do not use with
+    long-running methods, including usually-fast, but generally unbounded,
+    methods.
+  </p>
+  <p>
+    Pauses to the garbage collection may cause deadlock. Do not acquire locks
+    during a fast native call if the locks haven't been released locally (i.e.
+    before returning to managed code). This does not apply to regular JNI calls
+    since ART considers the executing native code as suspended.
+  </p>
+</aside>
+
+<p>
+  <code>@FastNative</code> can improve native method performance up to 3x, and 
+  <code>@CriticalNative</code> up to 5x. For example, a JNI transition measured
+  on a Nexus 6P device:
+</p>
+
+<table>
+  <tr>
+    <th>Java Native Interface (JNI) invocation</th>
+    <th>Execution time (in nanoseconds)</th>
+  </tr>
+  <tr>
+    <td>Regular JNI</td>
+    <td>115</td>
+  </tr>
+  <tr>
+    <td><em>!bang JNI</em></td>
+    <td>60</td>
+  </tr>
+  <tr>
+    <td><code>@FastNative</code></td>
+    <td>35</td>
+  </tr>
+  <tr>
+    <td><code>@CriticalNative</code></td>
+    <td>25</td>
+  </tr>
+</table>
+
 </body>
 </html>
diff --git a/en/devices/tech/debug/index.html b/en/devices/tech/debug/index.html
index 702b7a14..67b2fee2 100644
--- a/en/devices/tech/debug/index.html
+++ b/en/devices/tech/debug/index.html
@@ -35,8 +35,10 @@ characters. This meant that to create a wrap property with the name of the app,
 it was necessary to truncate the name to fit. In Android O and later, this
 limit is much greater and should require no truncation.</p>
 
-<p>This page covers use of <code>debuggerd</code>, a daemon process for
-collecting error information after applications crash. Other pages explore system services with
+<p>This page covers the basics surrounding crash dumps found in logcat output.
+Other pages have far more detail about
+<a href="/devices/tech/debug/native-crash.html">diagnosing native crashes</a>,
+exploring system services with
 <a
    href="https://developer.android.com/studio/command-line/dumpsys.html">
   <code>dumpsys</code></a>, viewing
@@ -46,26 +48,28 @@ collecting error information after applications crash. Other pages explore syste
 <a href="/devices/tech/debug/asan.html">AddressSanitizer</a> to detect memory
 bugs in native code, evaluating
 <a href="/devices/tech/debug/eval_perf.html"> performance issues</a> (includes
-<a href="/devices/tech/debug/systrace">systrace</a>), and using
-<a href="/devices/tech/debug/gdb.html">GNU Project debugger (GDB)</a> and
+<a href="/devices/tech/debug/systrace">systrace</a>), and using the
+<a href="/devices/tech/debug/gdb.html">GNU debugger (GDB)</a> and
 other debugging tools.</p>
 
-<h2 id=debuggerd>Using debuggerd</h2>
+<h2 id=debuggerd>Crash dumps</h2>
 
-<p>The <code>debuggerd</code> process dumps registers and unwinds the stack.
-When a dynamically linked executable starts, several signal handlers are
-registered that connect to <code>debuggerd</code> (or <code>debuggerd64)</code>
-in the event that signals (such as SIGSEGV or SIGABRT) are sent to the process.</p>
+<p>When a dynamically linked executable starts, several signal handlers are
+registered that, in the event of a crash, cause a basic crash dump to be written to logcat
+and a more detailed "tombstone" file to be written to <code>/data/tombstones/</code>.
+The tombstone is a file with extra data about the crashed process. In particular, it contains
+stack traces for all the threads in the crashing process (not just the thread that caught the
+signal), a full memory map, and a list of all open file descriptors.</p>
 
-<p>It's possible for <code>debuggerd</code> to attach only if nothing else is
+Before Android 8.0, crashes were handled by the
+<code>debuggerd</code> and <code>debuggerd64</code> daemons. In Android O and later,
+<code>crash_dump32</code> and <code>crash_dump64</code> are spawned as needed.</p>
+
+<p>It's possible for the crash dumper to attach only if nothing else is
 already attached, which means using tools such as <code>strace</code> or
-<code>gdb</code> will prevent <code>debuggerd</code> from working. You can also
-explicitly prevent <code>debuggerd</code> from attaching by calling
-<code>prctl(PR_SET_DUMPABLE, 0)</code>, which can be useful when you need to
-opt out of crash reporting.</p>
+<code>gdb</code> will prevent crash dumps from occurring.</p>
 
-<p>Example <code>debuggerd</code> output (with timestamps and extraneous
-information removed):</p>
+<p>Example output (with timestamps and extraneous information removed):</p>
 
 <pre class="devsite-click-to-copy">
 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
@@ -90,18 +94,13 @@ backtrace:
 Tombstone written to: /data/tombstones/tombstone_06
 </pre>
 
-<p>The last line of <code>debuggerd</code> output dumps a summary to the log and
-writes a full <em>tombstone</em> to disk. The tombstone is simply a file with
-extra data about the crashed process; it contains information that can be
-helpful in debugging a crash, in particular the stack traces for all threads in
-the crashing process (not just the thread that caught the signal) and a full
-memory map.</p>
+<p>The last line of output gives the location of the full <em>tombstone</em> on disk.</p>
 
-<p>Assuming the unstripped binaries can be found, you can get a more detailed
-unwind with line number information by pasting the above example into
+<p>Assuming you have the unstripped binaries available, you can get a more detailed
+unwind with line number information by pasting the stack into
 <code>development/scripts/stack</code>:</p>
 
-<p class="key-point"><strong>Tip:</strong> For convenience, if you've lunched
+<p class="key-point"><strong>Tip:</strong> For convenience, if you've run <code>lunch</code>
 <code>stack</code> will be on your $PATH already so you don't need to give the
 full path.</p>
 
@@ -109,7 +108,7 @@ full path.</p>
 development/tools/stack
 </pre>
 
-<p>Example output:</p>
+<p>Example output (based on the logcat output above):</p>
 <pre class="devsite-click-to-copy">
 Reading native crash info from stdin
 03-02 23:53:49.477 17951 17951 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
@@ -156,8 +155,7 @@ Stack Trace:
 
 <p class="note"><strong>Note:</strong> Some system libraries are built with
 <code>LOCAL_STRIP_MODULE := keep_symbols</code> to provide usable backtraces
-directly from <code>debuggerd</code> without taking up anywhere near as much
-space as an unstripped version.</p>
+directly without taking up anywhere near as much space as an unstripped version.</p>
 
 <p>You can also <code>stack</code> an entire tombstone. Example:</p>
 <pre class="devsite-terminal devsite-click-to-copy">
@@ -170,8 +168,8 @@ For more information about diagnosing native crashes and tombstones, see
 
 <h2 id="tombstone">Getting a stack trace/tombstone from a running process</h2>
 
-<p>You can also use <code>debuggerd</code> on a running process. From the
-command line, invoke <code>debuggerd</code> using a process ID (PID) to dump the
+<p>You can also use the <code>debuggerd</code> tool to get a stack dump from a running process.
+From the command line, invoke <code>debuggerd</code> using a process ID (PID) to dump a
 full tombstone to <code>stdout</code>. To get just the stack for every thread in
 the process, include the <code>-b</code> or <code>--backtrace</code> flag.</p>
 
diff --git a/en/source/build-numbers.html b/en/source/build-numbers.html
index e9809170..eb112273 100644
--- a/en/source/build-numbers.html
+++ b/en/source/build-numbers.html
@@ -208,6 +208,30 @@ site:</p>
   </thead>
   <tbody>
     <tr>
+      <td>OPD3.170816.012</td>
+      <td>android-8.0.0_r24</td>
+      <td>Oreo</td>
+      <td>Pixel 2 XL, Pixel 2</td>
+    </tr>
+    <tr>
+      <td>OPD1.170816.012</td>
+      <td>android-8.0.0_r23</td>
+      <td>Oreo</td>
+      <td>Pixel 2 XL, Pixel 2</td>
+    </tr>
+    <tr>
+      <td>OPD1.170816.011</td>
+      <td>android-8.0.0_r22</td>
+      <td>Oreo</td>
+      <td>Pixel 2 XL, Pixel 2</td>
+    </tr>
+    <tr>
+      <td>OPD1.170816.010</td>
+      <td>android-8.0.0_r21</td>
+      <td>Oreo</td>
+      <td>Pixel 2 XL, Pixel 2</td>
+    </tr>
+    <tr>
       <td>OPR5.170623.007</td>
       <td>android-8.0.0_r17</td>
       <td>Oreo</td>
diff --git a/en/source/initializing.html b/en/source/initializing.html
index 505b647e..611d0e4c 100644
--- a/en/source/initializing.html
+++ b/en/source/initializing.html
@@ -270,7 +270,7 @@ To mount the image when you execute <code>mountAndroid</code>:
 
 <pre class="devsite-click-to-copy">
 # mount the android file image
-function mountAndroid { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
+function mountAndroid() { hdiutil attach ~/android.dmg -mountpoint /Volumes/android; }
 </pre>
 
 <p class="note"><strong>Note:</strong> If your system created a