Docs: Changes to source.android.com

  - 178962421 Devsite localized content from translation request e87711... by Android Partner Docs <noreply@android.com>
  - 178945337 HIDL doc: Suggest better translation to "reader" by Android Partner Docs <noreply@android.com>
  - 178916026 Devsite localized content from translation request 05a572... by Android Partner Docs <noreply@android.com>
  - 178910606 Devsite localized content from translation request 4f1426... by Android Partner Docs <noreply@android.com>
  - 178909389 Devsite localized content from translation request c6e552... by Android Partner Docs <noreply@android.com>
  - 178909386 Devsite localized content from translation request df62d7... by Android Partner Docs <noreply@android.com>
  - 178857091 Devsite localized content from translation request 6295af... by Android Partner Docs <noreply@android.com>
  - 178856700 updated researcher's twitter link by Android Partner Docs <noreply@android.com>
  - 178815522 Change misleading leading "#" before a shell commnad to m... by Christina Nguyen <cqn@google.com>
  - 178660447 Updating whitelist instructions, some formatting fixes as... by Heidi von Markham <hvm@google.com>
  - 178647210 Incorporate Elliott's clarification updates to the A/B OT... by Christina Nguyen <cqn@google.com>
  - 178643130 Update systrace guide with bigger screenshots and reworke... by Billy Lamberta <blamb@google.com>
  - 178622648 Devsite localized content from translation request af34f0... by Android Partner Docs <noreply@android.com>
  - 178622644 Devsite localized content from translation request 517746... by Android Partner Docs <noreply@android.com>
  - 178482700 Remove outdated JIT recommendations for low ram. by Android Partner Docs <noreply@android.com>
  - 178444767 Updating Git and Repo overview, removing git page by Heidi von Markham <hvm@google.com>
  - 178442891 Add Android 8.0 security enhancements by Danielle Roberts <daroberts@google.com>
  - 178395150 Devsite localized content from translation request bf46b0... by Android Partner Docs <noreply@android.com>
  - 178395145 Devsite localized content from translation request eea056... by Android Partner Docs <noreply@android.com>
  - 178252225 Devsite localized content from translation request b00a9b... by Android Partner Docs <noreply@android.com>
  - 178152122 Add AOSP links to December bulletins by Danielle Roberts <daroberts@google.com>
  - 178140880 Fix link to named anchor by Clay Murphy <claym@google.com>
  - 178116086 Update Oreo MR1's API level. by Android Partner Docs <noreply@android.com>

PiperOrigin-RevId: 178962421
Change-Id: I21bb710ff8e7c4c132c41b0d799edf17c7b2fff1

18 files changed, 165 insertions, 45 deletions

diff --git a/en/devices/tech/debug/images/perf_trace_binder_trans.png b/en/devices/tech/debug/images/perf_trace_binder_trans.png
index 7d9fe135..9eb5b13f 100644
--- a/en/devices/tech/debug/images/perf_trace_binder_trans.png
+++ b/en/devices/tech/debug/images/perf_trace_binder_trans.png
diff --git a/en/devices/tech/debug/images/perf_trace_fence_end.png b/en/devices/tech/debug/images/perf_trace_fence_end.png
index 251701e9..3adbb3d1 100644
--- a/en/devices/tech/debug/images/perf_trace_fence_end.png
+++ b/en/devices/tech/debug/images/perf_trace_fence_end.png
diff --git a/en/devices/tech/debug/images/perf_trace_fences.png b/en/devices/tech/debug/images/perf_trace_fences.png
new file mode 100644
index 00000000..ef65a2ac
--- /dev/null
+++ b/en/devices/tech/debug/images/perf_trace_fences.png
diff --git a/en/devices/tech/debug/images/perf_trace_fm_sf.png b/en/devices/tech/debug/images/perf_trace_fm_sf.png
index 82907f99..c3e4f031 100644
--- a/en/devices/tech/debug/images/perf_trace_fm_sf.png
+++ b/en/devices/tech/debug/images/perf_trace_fm_sf.png
diff --git a/en/devices/tech/debug/images/perf_trace_frame_previous.png b/en/devices/tech/debug/images/perf_trace_frame_previous.png
index 8fdc746b..10a79075 100644
--- a/en/devices/tech/debug/images/perf_trace_frame_previous.png
+++ b/en/devices/tech/debug/images/perf_trace_frame_previous.png
diff --git a/en/devices/tech/debug/images/perf_trace_normal_pipeline.png b/en/devices/tech/debug/images/perf_trace_normal_pipeline.png
index 1ede6584..a588e290 100644
--- a/en/devices/tech/debug/images/perf_trace_normal_pipeline.png
+++ b/en/devices/tech/debug/images/perf_trace_normal_pipeline.png
diff --git a/en/devices/tech/debug/images/perf_trace_pending_frames.png b/en/devices/tech/debug/images/perf_trace_pending_frames.png
index ed514351..19eb501a 100644
--- a/en/devices/tech/debug/images/perf_trace_pending_frames.png
+++ b/en/devices/tech/debug/images/perf_trace_pending_frames.png
diff --git a/en/devices/tech/debug/images/perf_trace_previous_frame.png b/en/devices/tech/debug/images/perf_trace_previous_frame.png
index c1c9bb64..0945299e 100644
--- a/en/devices/tech/debug/images/perf_trace_previous_frame.png
+++ b/en/devices/tech/debug/images/perf_trace_previous_frame.png
diff --git a/en/devices/tech/debug/images/perf_trace_sf_comp_submit.png b/en/devices/tech/debug/images/perf_trace_sf_comp_submit.png
index 03bdea1c..f2033f6b 100644
--- a/en/devices/tech/debug/images/perf_trace_sf_comp_submit.png
+++ b/en/devices/tech/debug/images/perf_trace_sf_comp_submit.png
diff --git a/en/devices/tech/debug/images/perf_trace_sf_latches_pend.png b/en/devices/tech/debug/images/perf_trace_sf_latches_pend.png
index 36ca7314..29d7f188 100644
--- a/en/devices/tech/debug/images/perf_trace_sf_latches_pend.png
+++ b/en/devices/tech/debug/images/perf_trace_sf_latches_pend.png
diff --git a/en/devices/tech/debug/images/perf_trace_sf_wake_sleep.png b/en/devices/tech/debug/images/perf_trace_sf_wake_sleep.png
index a0010382..6797fe3a 100644
--- a/en/devices/tech/debug/images/perf_trace_sf_wake_sleep.png
+++ b/en/devices/tech/debug/images/perf_trace_sf_wake_sleep.png
diff --git a/en/devices/tech/debug/images/perf_trace_sf_woken_et.png b/en/devices/tech/debug/images/perf_trace_sf_woken_et.png
index f1ac8e65..1383d425 100644
--- a/en/devices/tech/debug/images/perf_trace_sf_woken_et.png
+++ b/en/devices/tech/debug/images/perf_trace_sf_woken_et.png
diff --git a/en/devices/tech/debug/images/perf_trace_tl.png b/en/devices/tech/debug/images/perf_trace_tl.png
index 9665d1f2..113f3306 100644
--- a/en/devices/tech/debug/images/perf_trace_tl.png
+++ b/en/devices/tech/debug/images/perf_trace_tl.png
diff --git a/en/devices/tech/debug/images/perf_trace_tl_pxl.png b/en/devices/tech/debug/images/perf_trace_tl_pxl.png
index b922d492..55bc94c9 100644
--- a/en/devices/tech/debug/images/perf_trace_tl_pxl.png
+++ b/en/devices/tech/debug/images/perf_trace_tl_pxl.png
diff --git a/en/devices/tech/debug/images/perf_trace_wake_cpu0.png b/en/devices/tech/debug/images/perf_trace_wake_cpu0.png
index 7f60c837..bf7872a5 100644
--- a/en/devices/tech/debug/images/perf_trace_wake_cpu0.png
+++ b/en/devices/tech/debug/images/perf_trace_wake_cpu0.png
diff --git a/en/devices/tech/debug/images/perf_trace_wake_render_enqueue.png b/en/devices/tech/debug/images/perf_trace_wake_render_enqueue.png
index d6ed95c2..44f4e7fe 100644
--- a/en/devices/tech/debug/images/perf_trace_wake_render_enqueue.png
+++ b/en/devices/tech/debug/images/perf_trace_wake_render_enqueue.png
diff --git a/en/devices/tech/debug/images/perf_traces_fences.png b/en/devices/tech/debug/images/perf_traces_fences.png
deleted file mode 100644
index e8662f7b..00000000
--- a/en/devices/tech/debug/images/perf_traces_fences.png
+++ /dev/null
diff --git a/en/devices/tech/debug/systrace.html b/en/devices/tech/debug/systrace.html
index 036bd6da..6d627421 100644
--- a/en/devices/tech/debug/systrace.html
+++ b/en/devices/tech/debug/systrace.html
@@ -108,9 +108,16 @@ back to sleep, waiting for EventThread wakeup.</li>
 
 <p>Let's walk through the frame beginning at 15409ms:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_normal_pipeline.png"></p>
-<p class="img-caption"><strong>Figure 1.</strong> Normal UI pipeline,
-EventThread running.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_normal_pipeline.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_normal_pipeline.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 1.</strong> Normal UI pipeline, EventThread running.
+  </figcaption>
+</figure>
 
 <p>Figure 1 is a normal frame surrounded by normal frames, so it's a good
 starting point for understanding how the UI pipeline works. The UI thread row
@@ -141,23 +148,45 @@ sleep slice.</p>
 <p>While EventThread is running, the UI thread for TouchLatency becomes
 runnable. To see what woke it, click the blue section:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_tl.png"></p>
-<p class="img-caption"><strong>Figure 2.</strong> UI thread for
-TouchLatency.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_tl.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_tl.png" class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 2.</strong> UI thread for TouchLatency.
+  </figcaption>
+</figure>
 
 <p>Figure 2 shows the TouchLatency UI thread was woken by tid 6843, which
 corresponds to EventThread. The UI thread wakes:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_wake_render_enqueue.png"></p>
-<p class="img-caption"><strong>Figure 3.</strong> UI thread wakes, renders a
-frame, and enqueues it for SurfaceFlinger to consume.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_wake_render_enqueue.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_wake_render_enqueue.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 3.</strong> UI thread wakes, renders a frame, and enqueues it
+    for SurfaceFlinger to consume.
+  </figcaption>
+</figure>
 
 <p>If the <code>binder_driver</code> tag is enabled in a trace, you can select a
 binder transaction to view information on all of the processes involved in that
 transaction:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_binder_trans.png"></p>
-<p class="img-caption"><strong>Figure 4.</strong> Binder transaction.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_binder_trans.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_binder_trans.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 4.</strong> Binder transaction.
+  </figcaption>
+</figure>
 
 <p>Figure 4 shows that, at 15,423.65ms, Binder:6832_1 in SurfaceFlinger becomes
 runnable because of tid 9579, which is TouchLatency's RenderThread. You can also
@@ -166,9 +195,16 @@ see queueBuffer on both sides of the binder transaction.</p>
 <p>During the queueBuffer on the SurfaceFlinger side, the number of pending
 frames from TouchLatency goes from 1 to 2:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_pending_frames.png"></p>
-<p class="img-caption"><strong>Figure 5.</strong> Pending frames goes from 1 to
-2.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_pending_frames.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_pending_frames.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 5.</strong> Pending frames goes from 1 to 2.
+  </figcaption>
+</figure>
 
 <p>Figure 5 shows triple-buffering, where there are two completed frames and the
 app will soon start rendering a third. This is because we've already dropped
@@ -178,33 +214,64 @@ further dropped frames.</p>
 <p>Soon after, SurfaceFlinger's main thread is woken by a second EventThread so
 it can output the older pending frame to the display:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_sf_woken_et.png"></p>
-<p class="img-caption"><strong>Figure 6.</strong> SurfaceFlinger's main thread
-is woken by a second EventThread.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_sf_woken_et.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_sf_woken_et.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 6.</strong> SurfaceFlinger's main thread is woken by a second
+    EventThread.
+  </figcaption>
+</figure>
 
 <p>SurfaceFlinger first latches the older pending buffer, which causes the
 pending buffer count to decrease from 2 to 1:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_sf_latches_pend.png"></p>
-<p class="img-caption"><strong>Figure 7.</strong> SurfaceFlinger first latches
-the older pending buffer.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_sf_latches_pend.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_sf_latches_pend.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 7.</strong> SurfaceFlinger first latches the older pending
+    buffer.
+  </figcaption>
+</figure>
 
 <p>After latching the buffer, SurfaceFlinger sets up composition and submits the
 final frame to the display. (Some of these sections are enabled as part of the
 <code>mdss</code> tracepoint, so they may not be there on your SOC.)</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_sf_comp_submit.png"></p>
-<p class="img-caption"><strong>Figure 8.</strong> SurfaceFlinger sets up
-composition and submits the final frame.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_sf_comp_submit.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_sf_comp_submit.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 8.</strong> SurfaceFlinger sets up composition and submits the
+    final frame.
+  </figcaption>
+</figure>
 
 <p>Next, <code>mdss_fb0</code> wakes on CPU 0. <code>mdss_fb0</code> is the
 display pipeline's kernel thread for outputting a rendered frame to the display.
 We can see <code>mdss_fb0</code> as its own row in the trace (scroll down to
 view).</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_wake_cpu0.png"></p>
-<p class="img-caption"><strong>Figure 9.</strong> <code>mdss_fb0</code> wakes
-on CPU 0.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_wake_cpu0.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_wake_cpu0.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 9.</strong> <code>mdss_fb0</code> wakes on CPU 0.
+  </figcaption>
+</figure>
 
 <p><code>mdss_fb0</code> wakes up, runs for a bit, enters uninterruptible sleep,
 then wakes again.</p>
@@ -224,9 +291,17 @@ browser.</p>
 
 <p>When you first open the systrace, you'll see something like this:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_tl_pxl.png"></p>
-<p class="img-caption"><strong>Figure 10</strong>. TouchLatency running on Pixel
-XL (most options enabled, including mdss and kgsl tracepoints).</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_tl_pxl.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_tl_pxl.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 10</strong>. TouchLatency running on Pixel XL (most options
+    enabled, including mdss and kgsl tracepoints).
+  </figcaption>
+</figure>
 
 <p>When looking for jank, check the FrameMissed row under SurfaceFlinger.
 FrameMissed is a quality-of-life improvement provided by Hardware Composer 2
@@ -236,9 +311,16 @@ case, FrameMissed is correlated with SurfaceFlinger missing one of its
 extremely-regular runtimes and an unchanged pending-buffer count for the app
 (<code>com.prefabulated.touchlatency</code>) at a vsync:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_fm_sf.png"></p>
-<p class="img-caption"><strong>Figure 11</strong>. FrameMissed correlation with
-SurfaceFlinger.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_fm_sf.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_fm_sf.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 11</strong>. FrameMissed correlation with SurfaceFlinger.
+  </figcaption>
+</figure>
 
 <p>Figure 11 shows a missed frame at 15598.29ms. SurfaceFlinger woke briefly at
 the vsync interval and went back to sleep without doing any work, which means
@@ -252,9 +334,17 @@ SurfaceFlinger wakes and immediately goes to sleep. When viewing the number of
 pending frames from TouchLatency, there are two frames (a good clue to help
 figure out what's going on).</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_sf_wake_sleep.png"></p>
-<p class="img-caption"><strong>Figure 12.</strong> SurfaceFlinger wakes and
-immediately goes to sleep.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_sf_wake_sleep.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_sf_wake_sleep.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 12.</strong> SurfaceFlinger wakes and immediately goes to
+    sleep.
+  </figcaption>
+</figure>
 
 <p>Because we have frames in SurfaceFlinger, it's not an app issue. In addition,
 SurfaceFlinger is waking at the correct time, so it's not a SurfaceFlinger
@@ -271,17 +361,31 @@ particular events in SurfaceFlinger depends on your SOC and driver stack, so
 work with your SOC vendor to understand the meaning of fence categories in your
 traces.</p>
 
-<p><img src="/devices/tech/debug/images/perf_traces_fences.png"></p>
-<p class="img-caption"><strong>Figure 13.</strong> <code>mdss_fb0_retire</code>
-fences.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_fences.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_fences.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 13.</strong> <code>mdss_fb0_retire</code> fences.
+  </figcaption>
+</figure>
 
 <p>Figure 13 shows a frame that was displayed for 33ms, not 16.7ms as expected.
 Halfway through that slice, that frame should have been replaced by a new one
 but wasn't. View the previous frame and look for anything interesting:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_frame_previous.png"></p>
-<p class="img-caption"><strong>Figure 14.</strong> Frame previous to busted
-frame.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_frame_previous.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_frame_previous.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 14.</strong> Frame previous to busted frame.
+  </figcaption>
+</figure>
 
 <p>Figure 14 shows 14.482ms a frame. The busted two-frame segment was 33.6ms,
 which is roughly what we would expect for two frames (we render at 60Hz, 16.7ms
@@ -290,8 +394,16 @@ suggests that something is very wrong with the display pipe.</p>
 
 <p>Investigate exactly where that fence ends to determine what controls it:</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_fence_end.png"></p>
-<p class="img-caption"><strong>Figure 15.</strong> Investigate fence end.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_fence_end.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_fence_end.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 15.</strong> Investigate fence end.
+  </figcaption>
+</figure>
 
 <p>A workqueue contains a <code>__vsync_retire_work_handler</code> that is
 running when the fence changes. Looking through the kernel source, you can see
@@ -303,8 +415,16 @@ might not get scheduled accurately.</p>
 <p>Check the previous frame to determine if that contributed; sometimes jitter
 can add up over time and eventually cause us to miss a deadline.</p>
 
-<p><img src="/devices/tech/debug/images/perf_trace_previous_frame.png"></p>
-<p class="img-caption"><strong>Figure 16.</strong> Previous frame.</p>
+<figure>
+  <a href="/devices/tech/debug/images/perf_trace_previous_frame.png"
+     title="Click to enlarge">
+    <img src="/devices/tech/debug/images/perf_trace_previous_frame.png"
+         class="screenshot">
+  </a>
+  <figcaption>
+    <strong>Figure 16.</strong> Previous frame.
+  </figcaption>
+</figure>
 
 <p>The runnable line on the kworker isn't visible because the viewer turns it
 white when it's selected, but the statistics tell the story: 2.3ms of scheduler