diff options
| author | Treehugger Robot <treehugger-gerrit@google.com> | 2017-12-14 19:28:06 +0000 |
|---|---|---|
| committer | Gerrit Code Review <noreply-gerritcodereview@google.com> | 2017-12-14 19:28:06 +0000 |
| commit | 1d10de1462c027a2ccfb429e85b1172db6d58e53 (patch) | |
| tree | 02bf4951c677b1321ed7ea0dae7ed0a236f777d0 /en | |
| parent | ec1edb605d9e6f51682a99402a115ad7245e919f (diff) | |
| parent | f2a1d5fd53891b0cb7d2a1c55e4311bc694170cd (diff) | |
| download | source.android.com-1d10de1462c027a2ccfb429e85b1172db6d58e53.tar.gz | |
Merge "Docs: Changes to source.android.com"
Diffstat (limited to 'en')
34 files changed, 847 insertions, 394 deletions
diff --git a/en/devices/tech/config/perms-whitelist.html b/en/devices/tech/config/perms-whitelist.html index 0ec1f21c..c3de0de0 100644 --- a/en/devices/tech/config/perms-whitelist.html +++ b/en/devices/tech/config/perms-whitelist.html @@ -1,6 +1,6 @@ <html devsite> <head> - <title>Privileged Permission Whitelist Requirement</title> + <title>Privileged Permission Whitelisting</title> <meta name="project_path" value="/_project.yaml" /> <meta name="book_path" value="/_book.yaml" /> </head> @@ -20,173 +20,151 @@ See the License for the specific language governing permissions and limitations under the License. --> - <p> - Historically device implementers had little control over which - signature|privileged permissions could be granted to privileged apps. - Privileged applications are system applications that are located in - <code>/system/priv-app</code> directory on the system image. - </p> - - <p> - Starting in Android 8.0, all privileged apps must be explicitly whitelisted in - system configuration XML files in the <code>/etc/permissions</code> directory. - If they are not, then the device will boot, but the device implementation will - not pass CTS. - </p> - - <h2 id="adding-the-whitelists">Adding the whitelists</h2> - - <p> - Permission whitelists for applications can be listed in a single or multiple XML - files located in the <code>frameworks/base/etc/permissions</code> directory, as follows: - </p> - - <ul> - <li><code>/etc/permissions/privapp-permissions-<OEM_NAME>.xml</code> - <li><code>/etc/permissions/privapp-permissions-<DEVICE_NAME>.xml</code>. - </ul> - - <p> - There is no strict rule for organizing content, it can be decided by the device implementer as - long as all applications from <code>/system/priv-app</code> are whitelisted. For - example, Google has a single whitelist for all privileged applications developed - by Google. - </p> - - <p> - The following organization is recommended: - </p> - - <ul> - <li>Permissions for apps that are already included in AOSP tree are listed in - this file: <code>/etc/permissions/privapp-permissions-platform.xml</code> - <li>Permissions for Google applications are listed in this file: - <code>/etc/permissions/privapp-permissions-google.xml </code> - <li>For other applications, use files of the form: - <code> - /etc/permissions/privapp-permissions-<device_name>.xml</code></li> - </ul> - - <h3 id="whitelist-generation-tool">Whitelist generation tool</h3> - - <p> - A whitelist for all applications available on the system image can be - automatically generated using a command-line tool available in AOSP, at the - following location: - </p> - - <pre - class="prettyprint">development/tools/privapp_permissions/privapp_permissions.py</pre> - - <p> - To generate an initial version of device-specific - <code>privapp-permissions.xml</code>, complete the following steps: - - </p> - <ol> - <li>Build a system image, as follows:<br> - <pre class="devsite-click-to-copy"> -<code class="devsite-terminal">. build/envsetup.sh</code> -<code class="devsite-terminal">lunch product_name</code> -<code class="devsite-terminal">make -j</code></pre> - </li> - - <li>Run the following tool to generate a <code>privapp-permissions.xml - </code>file that lists all signature|privileged permissions that are required to - be whitelisted.<br /> - <pre class="devsite-terminal devsite-click-to-copy">development/tools/privapp_permissions/privapp_permissions.py</pre> - - This tool prints XML content that can be used as a single file or split into - multiple files in <code>/etc/permissions</code>.<br><br> - If device already includes whitelists in the <code>/etc/permissions</code> directory, the tool - prints the difference, that is, only the missing signature|privileged - permissions that need to be added to the whitelist. This is also useful for - audit purposes, when a new version of the app is added, the tool will detect the - additional permissions needed. - </li> - <li>Copy the generated files to the <code>/etc/permissions</code> directory, where the system - will read it during boot.</li> - </ol> - <h3 id="whitelist-format">Whitelist format</h3> - <ul> - <li>Since the implementation is already in AOSP, only customization is needed. - <li>Permissions for apps that are included in AOSP tree are already whitelisted - in <code>/etc/permissions/privapp-permissions-platform.xml</code> - </li> - </ul> - - +<p> + Privileged applications are system applications located in the + <code>/system/priv-app</code> directory on the system image. Historically, + device implementers had little control over which signature|privileged + permissions could be granted to privileged apps. Starting in Android 8.0, + implementors can explicitly whitelist privileged apps in the system + configuration XML files in the <code>/etc/permissions</code> directory. Apps + not explicitly listed in these XML files are not granted privileged + permissions. +</p> + +<h2 id="adding-whitelists">Adding whitelists</h2> +<p> + Permission whitelists for applications can be listed in a single or multiple + XML files located in the <code>frameworks/base/etc/permissions</code> + directory as follows: +</p> + +<ul> + <li><code>/etc/permissions/privapp-permissions-<var>OEM_NAME</var>.xml</code> + <li><code>/etc/permissions/privapp-permissions-<var>DEVICE_NAME</var>.xml</code> +</ul> + +<p>There is no strict rule for organizing content. Device implementers can + determine content structure as long as all applications from + <code>/system/priv-app</code> are whitelisted. For example, Google has a + single whitelist for all privileged applications developed by Google. We + recommend the following organization: +</p> + +<ul> + <li>Permissions for apps that are already included in the Android Open Source + Project (AOSP) tree are listed in + <code>/etc/permissions/privapp-permissions-platform.xml</code>.</li> + <li>Permissions for Google applications are listed in + <code>/etc/permissions/privapp-permissions-google.xml</code>.</li> + <li>For other applications, use files of the form: + <code>/etc/permissions/privapp-permissions-<var>DEVICE_NAME</var>.xml</code>. + </li> +</ul> + +<h3 id="generating-whitelists">Generating whitelists</h3> + +<p> + To automatically generate a whitelist for all applications available on the + system image, use the AOSP command line tool at + <code>development/tools/privapp_permissions/privapp_permissions.py</code>. To + generate an initial version of device-specific + <code>privapp-permissions.xml</code>: +</p> + +<ol> + <li>Build a system image: + <pre class="devsite-click-to-copy"> + <code class="devsite-terminal">. build/envsetup.sh</code> + <code class="devsite-terminal">lunch <var>PRODUCT_NAME</var></code> + <code class="devsite-terminal">make -j</code></pre> + </li> + <li>Run the <code>privapp_permissions.py</code> script to generate a + <code>privapp-permissions.xml</code>file that lists all + signature|privileged permissions required to be whitelisted: + <pre class="devsite-terminal devsite-click-to-copy">development/tools/privapp_permissions/privapp_permissions.py</pre> + This tool prints XML content that can be used as a single file or split into + multiple files in <code>/etc/permissions</code>. + If the device already includes whitelists in the + <code>/etc/permissions</code> directory, the tool prints the differences + only (i.e. the missing signature|privileged permissions to be added to the + whitelist). This is also useful for audit purposes: When a new version of + the app is added, the tool detects the additional permissions needed. + </li> + <li>Copy the generated files to the <code>/etc/permissions</code> directory, + where the system will read those files during boot.</li> +</ol> + +<h3 id="customizing-whitelists">Customizing whitelists</h3> + +<p> + AOSP includes a whitelist implementation that can be customized as needed. + Permissions for apps included in AOSP are already whitelisted in + <code>/etc/permissions/privapp-permissions-platform.xml</code>. +</p> + +<p> + By default, the <code>privapp_permissions.py</code> script generates output + that automatically grants any permission requested by a privileged + application. If there are permissions that should be denied, edit the XML to + use a "deny-permission" tag instead of a "permission" tag. Example: +</p> <pre class="prettyprint"><!-- - This XML file declares which signature|privileged permissions should be granted to privileged - applications that come with the platform + This XML file declares which signature|privileged permissions should be + granted to privileged applications that come with the platform --> <permissions> - <privapp-permissions package="com.android.backupconfirm"> - <permission name="android.permission.BACKUP"/> - <permission name="android.permission.CRYPT_KEEPER"/> - </privapp-permissions> - <privapp-permissions package="com.android.cellbroadcastreceiver"> - <permission name="android.permission.INTERACT_ACROSS_USERS"/> - <permission name="android.permission.MANAGE_USERS"/> - <permission name="android.permission.MODIFY_PHONE_STATE"/> - <permission name="android.permission.READ_PRIVILEGED_PHONE_STATE"/> - <permission name="android.permission.RECEIVE_EMERGENCY_BROADCAST"/> - </privapp-permissions> +<privapp-permissions package="com.android.backupconfirm"> + <permission name="android.permission.BACKUP"/> + <permission name="android.permission.CRYPT_KEEPER"/> +</privapp-permissions> +<privapp-permissions package="com.android.cellbroadcastreceiver"> + <!-- don't allow application to interact across users --> + <deny-permission name="android.permission.INTERACT_ACROSS_USERS"/> + <permission name="android.permission.MANAGE_USERS"/> + <permission name="android.permission.MODIFY_PHONE_STATE"/> + <permission name="android.permission.READ_PRIVILEGED_PHONE_STATE"/> + <permission name="android.permission.RECEIVE_EMERGENCY_BROADCAST"/> +</privapp-permissions> ...</pre> - <h3 id="enabling-logs-to-find-missing-permissions">Enabling logs to find missing - permissions</h3> - <p> - When bringing up a new device, we recommend enabling transitional log-mode at - first, as follows: - </p> - <p> - <strong> <code>ro.control_privapp_permission=log</code> </strong> - - <p> - The violations will be reported in the log file, but permissions will still be - granted. This will keep device in a working state, while providing the list of - violations. - </p> - <p> - Error message format is as follows: - </p> - <p> - - <code>PackageManager: Privileged permission {PERMISSION_NAME} for package - {PACKAGE_NAME} - not in privapp-permissions whitelist</code> - </p> - <p> - All violations must be addressed by adding them to whitelists. Otherwise device - will not pass CTS tests. - </p> - <h2 id="cts-tests-for-whitelists">CTS tests for whitelists</h2> - <p> - Your device implementation will not pass CTS if it contains privileged apps that - do not appear in a whitelist at <code>/etc/permissions.</code> - </p> - <p> - <code>The </code>PrivappPermissionsTest.java test enforces the - signature|privileged permission whitelist, as follows: - </p><ul> - <li>Reports the permissions that are granted into the CTS log. - <li>Ensures all priv permissions are exclusively granted to applications - declared in <code><privapp-permissions>,</code> i.e. it will fail if a - privileged application is requesting signature|privileged permission that is not - whitelisted or a whitelisted permission wasn't granted by the system.</li></ul> - <h2 id="run-time-enforcement-of-whitelists">Run-time enforcement of - whitelists</h2> - <p> - Once the whitelists are in place, run-time enforcement can be enabled by setting - a build property <code>ro.control_privapp_permission=enforce</code>. - </p> - <p> - <strong>Note: </strong>Please note that regardless of - <code>ro.control_privapp_permission</code> property state, only devices with - properly whitelisted privileged permissions for all privileged applications will - pass CTS tests. - </p> +<h3 id="finding-missing-permissions">Finding missing permissions</h3> + +<p> + When bringing up a new device, find missing permissions by enabling + transitional log-mode: +</p> + +<pre class="devsite-click-to-copy">ro.control_privapp_permission=log</pre> + +<p> + Violations are reported in the log file, but permissions are still granted. + This keeps the device in a working state while providing the list of + violations. The error message format is as follows: +</p> + +<pre class="devsite-click-to-copy"> +PackageManager: Privileged permission {PERMISSION_NAME} for package {PACKAGE_NAME} - not in privapp-permissions whitelist +</pre> + +<p> + All violations must be addressed by adding the apps to whitelists. If not + added, the apps will not be granted the missing permissions even if they are + in the priv-app path. +</p> + + +<h2 id="enforcing-whitelists">Enforcing whitelists</h2> + +<p> + After whitelists are in place, enable runtime enforcement by setting the build + property <code>ro.control_privapp_permission=enforce</code>. +</p> + +<aside class="note"><strong>Note:</strong> The + <code>ro.control_privapp_permission</code> property state must adhere to + <a href="/compatibility/android-cdd#9_1_permissions">CDD section 9.1 + requirements</a>.</aside> </body> </html> diff --git a/en/devices/tech/debug/images/perf_trace_binder_trans.png b/en/devices/tech/debug/images/perf_trace_binder_trans.png Binary files differindex 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 Binary files differindex 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 Binary files differnew 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differindex 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 Binary files differdeleted 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 diff --git a/en/devices/tech/index.html b/en/devices/tech/index.html index 1e2c200b..aafb7e0b 100644 --- a/en/devices/tech/index.html +++ b/en/devices/tech/index.html @@ -40,7 +40,8 @@ Information</a></p> <h2 id="config">Configuration</h2> <p>Getting the most out of Android requires tuning of the <a -href="/devices/tech/config/kernel.html">kernel</a> and +href="/devices/tech/config/kernel.html">kernel</a>, <a +href="/devices/tech/config/renderer.html">OpenGLRenderer</a>, and more. See the subpages of this section for details. <p><a href="/devices/tech/config/index.html">» Configuration Information</a></p> diff --git a/en/devices/tech/ota/ab_updates.html b/en/devices/tech/ota/ab_updates.html index 5dc04c2a..8f680c6e 100644 --- a/en/devices/tech/ota/ab_updates.html +++ b/en/devices/tech/ota/ab_updates.html @@ -36,14 +36,22 @@ <ul> <li> OTA updates can occur while the system is running, without - interrupting the user (including app optimizations that occur after a - reboot). This means users can continue to use their devices during an - OTA—the only downtime during an update is when the device + interrupting the user. Users can continue to use their devices during + an OTA—the only downtime during an update is when the device reboots into the updated disk partition. </li> <li> - If an OTA fails, the device boots into the pre-OTA disk partition and - remains usable. The download of the OTA can be attempted again. + After an update, rebooting takes no longer than a regular reboot. + </li> + <li> + If an OTA fails to apply (for example, because of a bad flash), the + user will not be affected. The user will continue to run the old OS, + and the client is free to re-attempt the update. + </li> + <li> + If an OTA update is applied but fails to boot, the device will reboot + back into the old partition and remains usable. The client is free to + re-attempt the update. </li> <li> Any errors (such as I/O errors) affect only the <strong>unused</strong> @@ -59,7 +67,8 @@ </li> <li> The cache partition is no longer used to store OTA update packages, so - there is no need for sizing the cache partition. + there is no need to ensure that the cache partition is large enough for + future updates. </li> <li> <a href="/security/verifiedboot/dm-verity.html">dm-verity</a> @@ -72,7 +81,73 @@ <h2 id="overview">About A/B system updates</h2> - <p>A/B system updates affect the following:</p> + <p> + A/B updates require changes to both the client and the system. The OTA + package server, however, should not require changes: update packages + are still served over HTTPS. For devices using Google's OTA + infrastructure, the system changes are all in AOSP, and the client code + is provided by Google Play services. OEMs not using Google's OTA + infrastructure will be able to reuse the AOSP system code but will + need to supply their own client. + </p> + + <p> + For OEMs supplying their own client, the client needs to: + </p> + + <ul> + <li> + Decide when to take an update. Because A/B updates happen in the + background, they are no longer user-initiated. To avoid disrupting + users, it is recommended that updates are scheduled when the device + is in idle maintenance mode, such as overnight, and on Wi-Fi. + However, your client can use any heuristics you want. + </li> + <li> + Check in with your OTA package servers and determine whether an + update is available. This should be mostly the same as your existing + client code, except that you will want to signal that the device + supports A/B. (Google's client also includes a + <strong>Check now</strong> button for users to check for the latest + update.) + </li> + <li> + Call <code>update_engine</code> with the HTTPS URL for your update + package, assuming one is available. <code>update_engine</code> will + update the raw blocks on the currently unused partition as it streams + the update package. + </li> + <li> + Report installation successes or failures to your servers, based on + the <code>update_engine</code> result code. If the update is applied + successfully, <code>update_engine</code> will tell the bootloader to + boot into the new OS on the next reboot. The bootloader will fallback + to the old OS if the new OS fails to boot, so no work is required + from the client. If the update fails, the client needs to decide when + (and whether) to try again, based on the detailed error code. For + example, a good client could recognize that a partial ("diff") OTA + package fails and try a full OTA package instead. + </li> + </ul> + + <p>Optionally, the client can:</p> + + <ul> + <li> + Show a notification asking the user to reboot. If you want to + implement a policy where the user is encouraged to routinely update, + then this notification can be added to your client. If the client + does not prompt users, then users will get the update next time they + reboot anyway. (Google's client has a per-update configurable delay.) + </li> + <li> + Show a notification telling users whether they booted into a new + OS version or whether they were expected to do so but fell back to + the old OS version. (Google's client typically does neither.) + </li> + </ul> + + <p>On the system side, A/B system updates affect the following:</p> <ul> <li> @@ -855,23 +930,6 @@ say). With A/B updates, a failure to apply an update does not affect the currently running system. The update can simply be retried later.</p> - <h3>What does GmsCore do?</h3> - - <p>In Google's A/B implementation, the platform APIs and - <code>update_engine</code> provide the mechanism while GmsCore provides the - policy. That is, the platform knows <em>how</em> to apply an A/B update and all - that code is in AOSP (as mentioned above); but it's GmsCore that decides - <em>what</em> and <em>when</em> to apply.</p> - - <p>If you’re not using GmsCore, you can write your own replacement using the - same platform APIs. The platform Java API for controlling - <code>update_engine</code> is <code>android.os.UpdateEngine</code>: - <code><a href="https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/UpdateEngine.java" class="external-link">frameworks/base/core/java/android/os/UpdateEngine.java</a></code>. - Callers can provide an <code>UpdateEngineCallback</code> to be notified of status - updates: - <code><a href="https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/UpdateEngineCallback.java" class="external-link">frameworks/base/+/master/core/java/android/os/UpdateEngineCallback.java</a></code>. - Refer to the reference files for the core classes to use the interface.</p> - <h3>Which systems on a chip (SoCs) support A/B?</h3> <p>As of 2017-03-15, we have the following information:</p> diff --git a/en/devices/tech/perf/low-ram.html b/en/devices/tech/perf/low-ram.html index 715ff5c1..1a42af85 100644 --- a/en/devices/tech/perf/low-ram.html +++ b/en/devices/tech/perf/low-ram.html @@ -87,23 +87,6 @@ they should turn off specific memory-intensive PRODUCT_PROPERTY_OVERRIDES += ro.config.low_ram=true </pre> -<h3 id="jit">Disable JIT</h3> - - <p>System-wide JIT memory usage is dependent on the number of applications - running and the code footprint of those applications. The JIT establishes a - maximum translated code cache size and touches the pages within it as needed. - JIT costs somewhere between 3M and 6M across a typical running system.<br/> - <br/> - The large apps tend to max out the code cache fairly quickly (which by default - has been 1M). On average, JIT cache usage runs somewhere between 100K and 200K - bytes per app. Reducing the max size of the cache can help somewhat with - memory usage, but if set too low will send the JIT into a thrashing mode. For -the really low-memory devices, we recommend the JIT be disabled entirely.</p> - -<p>This can be achieved by adding the following line to the product makefile:</p> -<pre class="devsite-click-to-copy"> -PRODUCT_PROPERTY_OVERRIDES += dalvik.vm.jit.codecachesize=0 -</pre> <h3 id="launcher">Launcher Configs</h3> diff --git a/en/security/_toc.yaml b/en/security/_toc.yaml index d1fb641a..6b60e14b 100644 --- a/en/security/_toc.yaml +++ b/en/security/_toc.yaml @@ -13,6 +13,8 @@ toc: section: - title: Overview path: /security/enhancements/ + - title: Android 8.0 + path: /security/enhancements/enhancements80 - title: Android 7.0 path: /security/enhancements/enhancements70 - title: Android 6.0 diff --git a/en/security/bulletin/2017-12-01.html b/en/security/bulletin/2017-12-01.html index c841d979..9f2c9b60 100644 --- a/en/security/bulletin/2017-12-01.html +++ b/en/security/bulletin/2017-12-01.html @@ -21,7 +21,7 @@ limitations under the License. --> -<p><em>Published December 4, 2017</em> +<p><em>Published December 4, 2017 | Updated December 6, 2017</em> </p> <p> @@ -33,10 +33,9 @@ your Android version</a>. </p> <p> Android partners are notified of all issues at least a month before publication. -Source code patches for these issues will be released to the Android Open Source -Project (AOSP) repository in the next 48 hours. We will revise this bulletin -with the AOSP links when they are available. -</p> +Source code patches for these issues have been released to the Android Open +Source Project (AOSP) repository and linked from this bulletin. This bulletin +also includes links to patches outside of AOSP.</p> <p> The most severe of these issues is a critical security vulnerability in Media framework that could enable a remote attacker using a specially crafted file to @@ -116,21 +115,21 @@ additional permissions.</p> </tr> <tr> <td>CVE-2017-0807</td> - <td>A-35056974</td> + <td>A-35056974<a href="#asterisk">*</a></td> <td>EoP</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-0870</td> - <td>A-62134807</td> + <td><a href="https://android.googlesource.com/platform/frameworks/minikin/+/22758c3312ada2cf9579c9c379875e3c7eb4b1f7">A-62134807</a></td> <td>EoP</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-0871</td> - <td>A-65281159</td> + <td><a href="https://android.googlesource.com/platform/frameworks/base/+/8e151bf8999345399208d54663f103921ae5e1c6">A-65281159</a></td> <td>EoP</td> <td>High</td> <td>8.0</td> @@ -158,77 +157,79 @@ a privileged process.</p> </tr> <tr> <td>CVE-2017-0872</td> - <td>A-65290323</td> + <td><a href="https://android.googlesource.com/platform/external/skia/+/7a3ba537f7456b4870a983cd9e0a09bb3d478efc">A-65290323</a></td> <td>RCE</td> <td>Critical</td> <td>7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-0876</td> - <td>A-64964675</td> + <td>A-64964675<a href="#asterisk">*</a></td> <td>RCE</td> <td>Critical</td> <td>6.0</td> </tr> <tr> <td>CVE-2017-0877</td> - <td>A-66372937</td> + <td>A-66372937<a href="#asterisk">*</a></td> <td>RCE</td> <td>Critical</td> <td>6.0</td> </tr> <tr> <td>CVE-2017-0878</td> - <td>A-65186291</td> + <td><a href="https://android.googlesource.com/platform/external/libhevc/+/a963ba6ac200ee4222ba4faa7137a69144ba668a">A-65186291</a></td> <td>RCE</td> <td>Critical</td> <td>8.0</td> </tr> <tr> <td>CVE-2017-13151</td> - <td>A-63874456</td> + <td><a href="https://android.googlesource.com/platform/external/libmpeg2/+/4262d8eeee23d169ab0a141f103592f7172d95bc">A-63874456</a></td> <td>RCE</td> <td>Critical</td> <td>6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-13153</td> - <td>A-65280854</td> + <td><a href="https://android.googlesource.com/platform/frameworks/av/+/969f2c97f04a0570a23d4d94b6f0a0642d2224cb">A-65280854</a></td> <td>EoP</td> <td>High</td> <td>8.0</td> </tr> <tr> <td>CVE-2017-0837</td> - <td>A-64340921</td> + <td><a href="https://android.googlesource.com/platform/frameworks/av/+/f759b8c4bcce2d3b3d45551be461f04297fa2bd3">A-64340921</a> + [<a href="https://android.googlesource.com/platform/frameworks/av/+/0957621867279da792808e43144f0c2b670d4c6c">2</a>]</td> <td>EoP</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-0873</td> - <td>A-63316255</td> + <td><a href="https://android.googlesource.com/platform/external/libmpeg2/+/d1a1d7b88203a240488633e3a9b4cde231c3c4e3">A-63316255</a></td> <td>DoS</td> <td>High</td> <td>6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-0874</td> - <td>A-63315932</td> + <td><a href="https://android.googlesource.com/platform/external/libavc/+/252628cffba8702e36b98c193bcd2fe67d8237ee">A-63315932</a></td> <td>DoS</td> <td>High</td> <td>6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-0880</td> - <td>A-65646012</td> + <td><a href="https://android.googlesource.com/platform/external/skia/+/67f9bd2acfd17f64a33ae8ad14806a0c93b921d8">A-65646012</a> + [<a href="https://android.googlesource.com/platform/frameworks/base/+/adb5e0ba6d532c0d52b3bf89a1dbec4e3e7a6fd6">2</a>]</td> <td>DoS</td> <td>High</td> <td>7.0, 7.1.1, 7.1.2</td> </tr> <tr> <td>CVE-2017-13148</td> - <td>A-65717533</td> + <td><a href="https://android.googlesource.com/platform/external/libmpeg2/+/60c4d957db5e18da39ec943f15171547b53305d6">A-65717533</a></td> <td>DoS</td> <td>High</td> <td>6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> @@ -256,35 +257,35 @@ process.</p> </tr> <tr> <td>CVE-2017-13160</td> - <td>A-37160362</td> + <td><a href="https://android.googlesource.com/platform/system/bt/+/68a1cf1a9de115b66bececf892588075595b263f">A-37160362</a></td> <td>RCE</td> <td>Critical</td> <td>7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-13156</td> - <td>A-64211847</td> + <td><a href="https://android.googlesource.com/platform/system/core/+/9dced1626219d47c75a9d37156ed7baeef8f6403">A-64211847</a></td> <td>EoP</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-13157</td> - <td>A-32990341</td> + <td><a href="https://android.googlesource.com/platform/frameworks/base/+/dba1bb07e04b51b1bd0a1251711781e731ce9524">A-32990341</a></td> <td>ID</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-13158</td> - <td>A-32879915</td> + <td><a href="https://android.googlesource.com/platform/frameworks/base/+/dba1bb07e04b51b1bd0a1251711781e731ce9524">A-32879915</a></td> <td>ID</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td>CVE-2017-13159</td> - <td>A-32879772</td> + <td><a href="https://android.googlesource.com/platform/packages/apps/Settings/+/b5e93969a5e0c3a3f07e068dbc763cdd995a0e21">A-32879772</a></td> <td>ID</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> @@ -452,10 +453,10 @@ a privileged process.</p> <table> <col width="17%"> - <col width="19%"> + <col width="21%"> <col width="9%"> <col width="14%"> - <col width="39%"> + <col width="37%"> <tr> <th>CVE</th> <th>References</th> @@ -797,5 +798,10 @@ of other fixes on their devices through their own security websites, such as the <td>December 4, 2017</td> <td>Bulletin published.</td> </tr> + <tr> + <td>1.1</td> + <td>December 6, 2017</td> + <td>Bulletin revised to include AOSP links.</td> + </tr> </table> </body></html> diff --git a/en/security/bulletin/pixel/2017-12-01.html b/en/security/bulletin/pixel/2017-12-01.html index c40844aa..e2dde3a8 100644 --- a/en/security/bulletin/pixel/2017-12-01.html +++ b/en/security/bulletin/pixel/2017-12-01.html @@ -20,7 +20,7 @@ See the License for the specific language governing permissions and limitations under the License. --> -<p><em>Published December 4, 2017 | Updated December 5, 2017</em></p> +<p><em>Published December 4, 2017 | Updated December 6, 2017</em></p> <p> The Pixel / Nexus Security Bulletin contains details of security @@ -78,14 +78,14 @@ additional references are linked to numbers following the bug ID. </tr> <tr> <td>CVE-2017-13154</td> - <td>A-63666573</td> + <td><a href="https://android.googlesource.com/platform/frameworks/av/+/271defe729a10db25b45759c8ccfb5abed24c647">A-63666573</a></td> <td>EoP</td> <td>High</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> </tr> <tr> <td rowspan="2">CVE-2017-0879</td> - <td rowspan="2">A-65025028</td> + <td rowspan="2"><a href="https://android.googlesource.com/platform/frameworks/av/+/26a87d15ef97b35633577f7a97ed39bcaa800585">A-65025028</a></td> <td>ID</td> <td>Moderate</td> <td>7.0, 7.1.1, 7.1.2, 8.0</td> @@ -97,7 +97,7 @@ additional references are linked to numbers following the bug ID. </tr> <tr> <td rowspan="2">CVE-2017-13149</td> - <td rowspan="2">A-65719872</td> + <td rowspan="2"><a href="https://android.googlesource.com/platform/external/libhevc/+/4cf597a518436abf964b020bb97f97e490f80065">A-65719872</a></td> <td>ID</td> <td>Moderate</td> <td>7.0, 7.1.1, 7.1.2, 8.0</td> @@ -109,7 +109,7 @@ additional references are linked to numbers following the bug ID. </tr> <tr> <td rowspan="2">CVE-2017-13150</td> - <td rowspan="2">A-38328132</td> + <td rowspan="2"><a href="https://android.googlesource.com/platform/external/libmpeg2/+/86bfec8d3215dbdabbe79dba128628976ebfc6ef">A-38328132</a></td> <td>ID</td> <td>Moderate</td> <td>7.0, 7.1.1, 7.1.2, 8.0</td> @@ -121,7 +121,7 @@ additional references are linked to numbers following the bug ID. </tr> <tr> <td>CVE-2017-13152</td> - <td>A-62872384</td> + <td><a href="https://android.googlesource.com/platform/frameworks/av/+/b41a527176b659c5ddfc734838df7607a6af80c9">A-62872384</a></td> <td>ID</td> <td>Moderate</td> <td>5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0</td> @@ -730,6 +730,11 @@ bulletin, are not required for declaring a security patch level. <td>December 5, 2017</td> <td>Bulletin updated with link to firmware images and details on functional updates.</td> </tr> + <tr> + <td>1.2</td> + <td>December 6, 2017</td> + <td>Bulletin revised to include AOSP links.</td> + </tr> </table> </body></html> diff --git a/en/security/enhancements/enhancements80.html b/en/security/enhancements/enhancements80.html new file mode 100644 index 00000000..4d499f9e --- /dev/null +++ b/en/security/enhancements/enhancements80.html @@ -0,0 +1,75 @@ +<html devsite> + <head> + <title>Security Enhancements in Android 8.0</title> + <meta name="project_path" value="/_project.yaml" /> + <meta name="book_path" value="/_book.yaml" /> + </head> + <body> + <!-- + Copyright 2017 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 +8.0:</p> + +<ul> + <li><strong>Encryption</strong>. Added support to evict key in work profile.</li> + <li><strong>Verified Boot</strong>. Added Android Verified Boot (AVB). Verified + Boot codebase supporting rollback protection for use in boot loaders added to + AOSP. Recommend bootloader support for rollback protection for the + HLOS. Recommend boot loaders can only be unlocked by user physically interacting + with the device.</li> + <li><strong>Lock screen</strong>. Added support for using tamper-resistant + hardware to verify lock screen credential.</li> + <li><strong>KeyStore</strong>. Required <a href="/security/keystore/attestation">key + attestation</a> for all devices that ship with Android 8.0+. Added <a + href="/security/keystore/attestation#id-attestation">ID + attestation</a> support to improve Zero Touch Enrollment.</li> + <li><strong>Sandboxing</strong>. More <a + href="https://android-developers.googleblog.com/2017/07/shut-hal-up.html">tightly + sandboxed</a> many components using Project Treble's standard interface between + framework and device-specific components. Applied <a + href="https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html">seccomp + filtering</a> to all untrusted apps to reduce the kernel's attack surface. <a + href="https://android-developers.googleblog.com/2017/06/whats-new-in-webview-security.html">WebView</a> + is now run in an isolated process with very limited access to the rest of the + system.</li> + <li><strong>Kernel hardening</strong>. Implemented <a + href="https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html">hardened + usercopy</a>, PAN emulation, read-only after init, and KASLR.</li> + <li><strong>Userspace hardening</strong>. Implemented CFI for the media stack. + App overlays can no longer cover system-critical windows and users have a way to + dismiss them.</li> + <li><strong>Streaming OS update</strong>. Enabled <a + href="/devices/tech/ota/ab_updates#streaming-updates">updates</a> + on devices that are are low on disk space.</li> + <li><strong>Install unknown apps</strong>. Users must <a + href="https://developer.android.com/studio/publish/index.html#publishing-unknown">grant + permission</a> to install apps from a source that isn't a first-party app store.</li> + <li><strong>Privacy</strong>. Android ID (SSAID) has a different value for + each app and each user on the device. For web browser apps, Widevine Client ID + returns a different value for each app package name and web origin. + <code>net.hostname</code> is now empty and the dhcp client no longer sends a + hostname. <code>android.os.Build.SERIAL</code> has been replaced with the + <a href="https://developer.android.com/reference/android/os/Build.html#getSerial()"><code>Build.SERIAL</code> API</a> + which is protected behind a user-controlled permission. Improved MAC address + randomization in some chipsets.</li> +</ul> + + </body> +</html> diff --git a/en/security/overview/acknowledgements.html b/en/security/overview/acknowledgements.html index cafa4e38..8bc07589 100644 --- a/en/security/overview/acknowledgements.html +++ b/en/security/overview/acknowledgements.html @@ -74,7 +74,7 @@ Barbara</td> <td>CVE-2017-0650</td> </tr> <tr> - <td>Baozeng Ding (<a href="https://twitter.com/sploving">@sploving</a>) of + <td>Baozeng Ding (<a href="https://twitter.com/sploving1">@sploving1</a>) of Alibaba Mobile Security Group</td> <td>CVE-2017-0463, CVE-2017-0506, CVE-2017-0711, CVE-2017-0741, CVE-2017-0742, CVE-2017-0751, CVE-2017-0796, CVE-2017-0798, CVE-2017-0800, diff --git a/en/setup/_toc.yaml b/en/setup/_toc.yaml index cccaa49e..b4648b20 100644 --- a/en/setup/_toc.yaml +++ b/en/setup/_toc.yaml @@ -43,8 +43,6 @@ toc: path: /setup/developing - title: Using Repo path: /setup/using-repo - - title: Learning Git - path: /setup/git-resources - title: Adding a New Device path: /setup/add-device - title: Understanding 64-bit Builds diff --git a/en/setup/build-numbers.html b/en/setup/build-numbers.html index 7325803d..b8891600 100644 --- a/en/setup/build-numbers.html +++ b/en/setup/build-numbers.html @@ -41,6 +41,11 @@ API levels and NDK releases provided for convenience:</p> <tbody> <tr> <td>Oreo</td> +<td>8.1.0</td> +<td>API level 27</td> +</tr> +<tr> +<td>Oreo</td> <td>8.0.0</td> <td>API level 26</td> </tr> diff --git a/en/setup/developing.html b/en/setup/developing.html index 59565e75..1b85969d 100644 --- a/en/setup/developing.html +++ b/en/setup/developing.html @@ -1,6 +1,6 @@ <html devsite> <head> - <title>Developing</title> + <title>Overview</title> <meta name="project_path" value="/_project.yaml" /> <meta name="book_path" value="/_book.yaml" /> </head> @@ -21,168 +21,391 @@ limitations under the License. --> +<p> + Working with Android code requires using <strong>Git</strong> (an open-source + version control system) and <strong>Repo</strong> (a Google-built repository + management tool that runs on top of Git). +</p> + +<h2 id="git">Git</h2> + +<p> + Git is designed to handle large projects that are distributed over multiple + repositories. Android uses Git for local operations such as local branching, + commits, diffs, and edits. One of the challenges in setting up the Android + project was figuring out how to best support the outside community—from + the hobbyist community to large OEMs building mass-market consumer devices. We + wanted components to be replaceable, and we wanted interesting components to + have a life of their own outside of Android. We first chose a distributed + revision control system, then narrowed it down to Git. +</p> + +<p> + For more details on Git, refer to + <a href="https://git-scm.com/documentation">Git Documentation</a>. +</p> + +<h2 id="repo">Repo</h2> +<p> + Repo unifies Git repositories when necessary, performs uploads to the + <a href="https://android-review.googlesource.com/">Gerrit revision control + system</a>, and automates parts of the Android development workflow. Repo is + not meant to replace Git, only to make it easier to work with Git in the + context of Android. The repo command is an executable Python script that you + can put anywhere in your path. In working with the Android source files, you + use Repo for across-network operations. For example, with a single Repo + command you can download files from multiple repositories into your local + working directory. +</p> + +<p> + In most situations, you can use Git instead of Repo, or mix Repo and Git + commands to form complex commands. However, using Repo for basic + across-network operations will make your work much simpler. For more details + on Repo, see the <a href="/setup/using-repo.html">Repo Command Reference</a>. +</p> + +<h2 id="other-tools">Other tools</h2> + +<p> + Other tools include + <a href="https://gerrit-review.googlesource.com/Documentation/" class="external">Gerrit</a>, + a web-based code review system for projects that use Git. Gerrit encourages + more centralized use of Git by allowing all authorized users to submit + changes, which are automatically merged if they pass code review. In addition, + Gerrit makes reviewing easier by displaying changes side-by-side in the + browser and enabling inline comments. +</p> +<p> + Finally, + <a href="http://developer.android.com/tools/studio/index.html" class="external">Android + Studio</a> is the official integrated development environment (IDE) for + Android application development. +</p> + +<h2 id="workflow">Workflow</h2> + +<p> + Android development involves the following basic workflow: +</p> -<p>To work with the Android code, you will need to use both Git and Repo. In most situations, you can use Git instead of Repo, or mix Repo and Git commands to form complex commands. Using Repo for basic across-network operations will make your work much simpler, however.</p> -<p><strong>Git</strong> is an open source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits. One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbyist community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.</p> -<p><strong>Repo</strong> is a repository management tool that we built on top of Git. Repo -unifies the many Git repositories when necessary, does the uploads to our -<a href="https://android-review.googlesource.com/">revision control system</a>, and -automates parts of the Android development workflow. Repo is not meant to -replace Git, only to make it easier to work with Git in the context of -Android. The repo command is an executable Python script that you can put -anywhere in your path. In working with the Android source files, you will -use Repo for across-network operations. For example, with a single Repo -command you can download files from multiple repositories into your local -working directory.</p> -<p><strong>Gerrit</strong> is a web-based code review system for projects that use git. Gerrit encourages more centralized use of Git by allowing all authorized users to submit changes, which are automatically merged if they pass code review. In addition, Gerrit makes reviewing easier by displaying changes side by side in-browser and enabling inline comments. </p> -<p><strong>Android Studio</strong> is the official integrated development environment (IDE) for Android application development. See the <a href="http://developer.android.com/tools/studio/index.html">Android Studio Overview</a> for details. - -<h2 id="basic-workflow">Basic Workflow</h2> -<div class="attempt-right" style="width:200px"> - <img src="/images/submit-patches-0.png" alt="basic workflow diagram" height="153px" /> - <p class="img-caption"> - <strong>Figure 1.</strong> Basic Android workflow - </p> -</div> - -<p>The basic pattern of interacting with the repositories is as follows:</p> +<img src="images/git_workflow.png" alt="basic workflow diagram" /> + <figcaption><strong>Figure 1.</strong> Basic Android workflow</figcaption> +<p> </p> <ol> -<li> -<p>Use <code>repo start</code> to start a new topic branch.</p> -</li> -<li> -<p>Edit the files.</p> -</li> -<li> -<p>Use <code>git add</code> to stage changes.</p> -</li> -<li> -<p>Use <code>git commit</code> to commit changes.</p> -</li> -<li> -<p>Use <code>repo upload</code> to upload changes to the review server.</p> -</li> + <li>Start a new topic branch using <code>repo start</code>. + </li> + <li>Edit the files. + </li> + <li>Stage changes using <code>git add</code>. + </li> + <li>Commit changes using <code>git commit</code>. + </li> + <li>Upload changes to the review server using <code>repo upload</code>. + </li> </ol> -<h2 id="task-reference">Task reference</h2> -<p>The task list below shows a summary of how to do common Repo and Git tasks. -For information about using repo to download source, see <a href="/setup/downloading.html">Downloading the Source</a> and -<a href="/setup/using-repo.html">Using Repo</a>.</p> -<h2 id="synchronizing-your-client">Synchronizing your client</h2> -<p>To synchronize the files for all available projects: </p> -<pre class="devsite-terminal devsite-click-to-copy"> -repo sync -</pre> -<p>To synchronize the files for selected projects:</p> + +<h2 id="common-tasks">Common tasks</h2> + +<p> + Working with Git and Repo in the Android code repositories involves + performing the following common tasks: +</p> + +<table> + <tr> + <th>Command</th> + <th>Description</th> + </tr> + <tr> + <td><code>repo init</code></td> + <td>Initializes a new client.</td> + </tr> + <tr> + <td><code>repo sync</code></td> + <td>Syncs client to repositories.</td> + </tr> + <tr> + <td><code>repo start</code></td> + <td>Starts a new branch.</td> + </tr> + <tr> + <td><code>repo status</code></td> + <td>Shows status of current branch.</td> + </tr> + <tr> + <td><code>repo upload</code></td> + <td>Uploads changes to the review server.</td> + </tr> + <tr> + <td><code>git add</code></td> + <td>Stages files.</td> + </tr> + <tr> + <td><code>git commit</code></td> + <td>Commits staged files.</td> + </tr> + <tr> + <td><code>git branch</code></td> + <td>Shows current branches.</td> + </tr> + <tr> + <td><code>git branch [branch]</code></td> + <td>Creates new topic branch.</td> + </tr> + <tr> + <td><code>git checkout [branch]</code></td> + <td>Switches HEAD to specified branch.</td> + </tr> + <tr> + <td><code>git merge [branch]</code></td> + <td>Merges [branch] into current branch.</td> + </tr> + <tr> + <td><code>git diff</code></td> + <td>Shows diff of unstaged changes.</td> + </tr> + <tr> + <td><code>git diff --cached</code></td> + <td>Shows diff of staged changes.</td> + </tr> + <tr> + <td><code>git log</code></td> + <td>Shows history of current branch.</td> + </tr> + <tr> + <td><code>git log m/[codeline]..</code></td> + <td>Shows commits that are not pushed.</td> + </tr> +</table> + +<p> + For information about using Repo to download source, see + <a href="/setup/downloading.html">Downloading the Source</a> and the + <a href="/setup/using-repo.html">Repo Command Reference</a>. +</p> + +<h3 id="synchronizing-clients">Synchronizing clients</h3> + +<p> + To synchronize the files for all available projects: +</p> +<pre class="devsite-terminal devsite-click-to-copy">repo sync</pre> + +<p> + To synchronize the files for selected projects: +</p> <pre class="devsite-terminal devsite-click-to-copy"> repo sync <var>PROJECT0 PROJECT1 ... PROJECTN</var> </pre> -<h2 id="creating-topic-branches">Creating topic branches</h2> -<p>Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature. A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you can isolate one aspect of your work from the others. For an interesting article about using topic branches, see <a href="http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt">Separating topic branches</a>.</p> -<p>To start a topic branch using Repo, navigate into the project to be modified and issue: </p> + +<h3 id="creating-topic-branches">Creating topic branches</h3> + +<p> + Start a topic branch in your local work environment whenever you begin a + change, such as when you begin work on a bug or new feature. A topic branch is + <strong>not</strong> a copy of the original files; it is a pointer to a + particular commit, which makes creating local branches and switching among + them a lightweight operation. By using branches, you can isolate one aspect of + your work from the others. For an interesting article about using topic + branches, refer to <a href="http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt" class="external">Separating + topic branches</a>. +</p> + +<p> + To start a topic branch using Repo, navigate to the project and run: +</p> <pre class="devsite-terminal devsite-click-to-copy"> repo start <var>BRANCH_NAME</var> . </pre> -<p>Please note, the period represents the project in the current working directory. To verify your new branch was created:</p> + +<p> + The trailing period (.) represents the project in the current working + directory. +</p> + +<p> + To verify the new branch was created: +</p> <pre class="devsite-terminal devsite-click-to-copy"> repo status . </pre> -<h2 id="using-topic-branches">Using topic branches</h2> -<p>To assign the branch to a particular project:</p> + +<h3 id="using-topic-branches">Using topic branches</h3> + +<p>To assign the branch to a specific project:</p> <pre class="devsite-terminal devsite-click-to-copy"> repo start <var>BRANCH_NAME PROJECT_NAME</var> </pre> -<p>See <a href="https://android.googlesource.com/">android.googlesource.com</a> for a list of all projects. Again, if you've already navigated into a particular project directory, you may simply pass a period to represent the current project.</p> -<p>To switch to another branch that you have created in your local work environment:</p> +<p>For a list of all projects, refer to + <a href="https://android.googlesource.com/" class="external">android.googlesource.com</a>. +If you've already navigated to the project directory, just use a period to +represent the current project. +</p> + +<p> + To switch to another branch in your local work environment: +</p> <pre class="devsite-terminal devsite-click-to-copy"> git checkout <var>BRANCH_NAME</var> </pre> -<p>To see a list of existing branches:</p> + +<p> + To view a list of existing branches: +</p> <pre class="devsite-terminal devsite-click-to-copy"> git branch </pre> -<p>or </p> + +<p>or</p> + <pre class="devsite-terminal devsite-click-to-copy"> repo branches </pre> -<p>The name of the current branch will be preceded by an asterisk.</p> -<p class="note"><strong>Note:</strong> A bug might be causing <code>repo sync</code> to reset the local topic branch. -If <code>git branch</code> shows * (no branch) after you run <code>repo sync</code>, then run <code>git checkout</code> again.</p> -<h2 id="staging-files">Staging files</h2> -<p>By default, Git notices but does not track the changes you make in a project. In order to tell git to preserve your changes, you must mark them for inclusion in a commit. This is also called "staging". </p> -<p>You can stage your changes by running</p> + +<p> + Both commands return the list of existing branches with the name of the + current branch preceded by an asterisk (*). +</p> + +<aside class="note"><strong>Note:</strong> A bug might cause <code>repo +sync</code> to reset the local topic branch. If <code>git branch</code> shows * +(no branch) after you run <code>repo sync</code>, run <code>git checkout</code> +again.</aside> + +<h3 id="staging-files">Staging files</h3> + +<p> + By default, Git notices but does not track the changes you make in a project. + To tell Git to preserve your changes, you must mark or <em>stage</em> those + changes for inclusion in a commit. +</p> + +<p> + To stage changes: +</p> <pre class="devsite-terminal devsite-click-to-copy"> git add </pre> -<p>which accepts as arguments any files or directories within the project directory. Despite the name, <code>git add</code> does not simply add files to the git repository; it can also be used to stage file modifications and deletions.</p> -<h2 id="viewing-client-status">Viewing client status</h2> -<p>To list the state of your files:</p> + +<p> + This command accepts arguments for files or directories within the project + directory. Despite the name, <code>git add</code> does not simply add files to + the git repository; it can also be used to stage file modifications and + deletions. +</p> + +<h3 id="viewing-client-status">Viewing client status</h3> + +<p> + To list the state of files: +</p> <pre class="devsite-terminal devsite-click-to-copy"> repo status </pre> -<p>To see uncommitted edits:</p> + +<p> + To view uncommitted edits (local edits that are <strong>not</strong> marked for commit): +</p> <pre class="devsite-terminal devsite-click-to-copy"> repo diff </pre> -<p>The <code>repo diff</code> command shows every local edit that you have made that would <em>not</em> go into the commit, if you were to commit right now. To see every edit that would go into the commit if you were to commit right now, you need a Git command, <code>git diff</code>. Before running it, be sure you are in the project directory:</p> + +<p> + To view committed edits (located edits that <strong>are marked</strong> for + commit), ensure you are in the project directory then run <code>git + diff</code> with the <code>cached</code> argument: +</p> <pre class="devsite-click-to-copy"> <code class="devsite-terminal">cd <var>~/WORKING_DIRECTORY/PROJECT</var></code> <code class="devsite-terminal">git diff --cached</code> </pre> -<h2 id="committing-changes">Committing changes</h2> -<p>A commit is the basic unit of revision control in git, consisting of a snapshot of directory structure and file contents for the entire project. Creating a commit in git is as simple as typing</p> + +<img src="images/git_diff.png" alt="diff vs diff-cached" /> + <figcaption><strong>Figure 2.</strong> Uncommitted vs. committed edits. + </figcaption> + +<h3 id="committing-changes">Committing changes</h3> + +<p> + A <em>commit</em> is the basic unit of revision control in Git and consists of + a snapshot of directory structure and file contents for the entire project. To + create a commit in Git: +</p> <pre class="devsite-terminal devsite-click-to-copy"> git commit </pre> -<p>You will be prompted for a commit message in your favorite editor; please provide a helpful message for any changes you submit to the AOSP. If you do not add a log message, the commit will be aborted. </p> -<h2 id="uploading-changes-to-gerrit">Uploading changes to Gerrit</h2> -<p>Before uploading, update to the latest revisions:</p> -<pre class="devsite-terminal devsite-click-to-copy"> -repo sync -</pre> -<p>Next run</p> -<pre class="devsite-terminal devsite-click-to-copy"> -repo upload + +<p> + When prompted for a commit message, provide a short (but helpful) message for + changes submitted to AOSP. If you do not add a commit message, the commit is + aborted. +</p> + +<h3 id="uploading-changes-to-gerrit">Uploading changes to Gerrit</h3> + +<p> + Update to the latest revision, then upload the change: +</p> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">repo sync</code> +<code class="devsite-terminal">repo upload</code> </pre> -<p>This will list the changes you have committed and prompt you to select which branches to upload to the review server. If there is only one branch, you will see a simple <code>y/n</code> prompt.</p> -<h2 id="recovering-sync-conflicts">Recovering sync conflicts</h2> -<p>If a <code>repo sync</code> shows sync conflicts:</p> -<ul> + +<p> + This command returns a list of changes you have committed and prompts you to + select the branches to upload to the review server. If there is only one + branch, you will see a simple <code>y/n</code> prompt. +</p> + +<h3 id="resolving-sync-conflicts">Resolving sync conflicts</h3> + +<p> + If the <code>repo sync</code> command returns sync conflicts: +</p> + +<ol> <li>View the files that are unmerged (status code = U).</li> <li>Edit the conflict regions as necessary.</li> - <li><p>Change into the relevant project directory, run <code>git add</code> and <code>git commit</code> for the files in question, and then "rebase" the changes. For example:</p> + <li>Change to the relevant project directory. Add and commit the affected + files, then rebase the changes: <pre class="devsite-click-to-copy"> <code class="devsite-terminal">git add .</code> <code class="devsite-terminal">git commit</code> <code class="devsite-terminal">git rebase --continue</code> </pre> </li> - <li><p>When the rebase is complete start the entire sync again:</p> -<pre class="devsite-terminal devsite-click-to-copy">repo sync <var>PROJECT0 PROJECT1 ... PROJECTN</var></pre> - </li> -</ul> - -<h2 id="cleaning-up-your-client-files">Cleaning up your client files</h2> -<p>To update your local working directory after changes are merged in Gerrit:</p> + <li>After the rebase completes, start the entire sync again: <pre class="devsite-terminal devsite-click-to-copy"> -repo sync +repo sync <var>PROJECT0 PROJECT1 ... PROJECTN</var> </pre> -<p>To safely remove stale topic branches: </p> -<pre class="devsite-terminal devsite-click-to-copy"> -repo prune + </li> +</ol> + +<h3 id="cleaning-up-client-files">Cleaning up clients</h3> +<p> + After merging changes to Gerrit, update your local working directory then use + <code>repo prune</code> to safely remove stale topic branches: +</p> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">repo sync</code> +<code class="devsite-terminal">repo prune</code> </pre> -<h2 id="deleting-a-client">Deleting a client</h2> -<p>Because all state information is stored in your client, you only need to delete the directory from your filesystem:</p> +<h3 id="deleting-clients">Deleting clients</h3> +<p> + Because all state information is stored in your client, you only need to + delete the directory from your filesystem: +</p> <pre class="devsite-terminal devsite-click-to-copy"> rm -rf <var>WORKING_DIRECTORY</var> </pre> -<p>Deleting a client will <em>permanently delete</em> any changes you have not yet uploaded for review.</p> -<h2 id="git-and-repo-cheatsheet">Git and Repo cheatsheet</h2> -<img src="/images/git-repo-1.png" alt="list of basic git and repo commands" id="figure2" /> -<p class="img-caption"> - <strong>Figure 2.</strong> Basic git and repo commands + +<p> + Deleting a client <em>permanently deletes</em> any changes you have not yet + uploaded for review. </p> </body> diff --git a/en/setup/images/git_diff.png b/en/setup/images/git_diff.png Binary files differnew file mode 100644 index 00000000..09c760ea --- /dev/null +++ b/en/setup/images/git_diff.png diff --git a/en/setup/images/git_workflow.png b/en/setup/images/git_workflow.png Binary files differnew file mode 100644 index 00000000..18ff0f56 --- /dev/null +++ b/en/setup/images/git_workflow.png diff --git a/en/setup/initializing.html b/en/setup/initializing.html index 662862be..4fdb4700 100644 --- a/en/setup/initializing.html +++ b/en/setup/initializing.html @@ -246,8 +246,8 @@ saves space while allowing to grow later as the need arises. Be sure to select "case sensitive, journaled" as the volume format.</p> <p>You can also create it from a shell with the following command:</p> -<pre class="devsite-click-to-copy"> -<span class="no-select"># </span>hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg +<pre class="devsite-click-to-copy devsite-terminal" data-terminal-prefix="# "> +hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/android.dmg </pre> <p>This will create a <code>.dmg</code> (or possibly a @@ -257,8 +257,7 @@ the required formatting for Android development.</p> <p>If you need a larger volume later, you can also resize the sparse image with the following command:</p> -<pre class="devsite-click-to-copy"> -<span class="no-select"># </span>hdiutil resize -size <new-size-you-want>g ~/android.dmg.sparseimage +<pre class="devsite-click-to-copy devsite-terminal" data-terminal-prefix="# ">hdiutil resize -size <new-size-you-want>g ~/android.dmg.sparseimage </pre> <p>For a disk image named <code>android.dmg</code> stored in your home diff --git a/en/setup/site-updates.html b/en/setup/site-updates.html index d55ef9d9..a77ebbda 100644 --- a/en/setup/site-updates.html +++ b/en/setup/site-updates.html @@ -47,7 +47,7 @@ support AAudio's MMAP feature in Android.</p> from the Android runtime (ART) in Android 8.1 and replaced with the <code>WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY</code> option that pre-optimizes the system server jars, as well as the boot classpath. See <a -href="/devices/tech/dalvik/configure#uild_options">Configuring ART</a> for the +href="/devices/tech/dalvik/configure#build_options">Configuring ART</a> for the deprecation notice.</p> <h3 id="biometric-unlock">Biometric unlock security measurements</h3> |
