From f2a1d5fd53891b0cb7d2a1c55e4311bc694170cd Mon Sep 17 00:00:00 2001 From: Android Partner Docs Date: Wed, 13 Dec 2017 14:54:50 -0800 Subject: Docs: Changes to source.android.com - 178962421 Devsite localized content from translation request e87711... by Android Partner Docs - 178945337 HIDL doc: Suggest better translation to "reader" by Android Partner Docs - 178916026 Devsite localized content from translation request 05a572... by Android Partner Docs - 178910606 Devsite localized content from translation request 4f1426... by Android Partner Docs - 178909389 Devsite localized content from translation request c6e552... by Android Partner Docs - 178909386 Devsite localized content from translation request df62d7... by Android Partner Docs - 178857091 Devsite localized content from translation request 6295af... by Android Partner Docs - 178856700 updated researcher's twitter link by Android Partner Docs - 178815522 Change misleading leading "#" before a shell commnad to m... by Christina Nguyen - 178660447 Updating whitelist instructions, some formatting fixes as... by Heidi von Markham - 178647210 Incorporate Elliott's clarification updates to the A/B OT... by Christina Nguyen - 178643130 Update systrace guide with bigger screenshots and reworke... by Billy Lamberta - 178622648 Devsite localized content from translation request af34f0... by Android Partner Docs - 178622644 Devsite localized content from translation request 517746... by Android Partner Docs - 178482700 Remove outdated JIT recommendations for low ram. by Android Partner Docs - 178444767 Updating Git and Repo overview, removing git page by Heidi von Markham - 178442891 Add Android 8.0 security enhancements by Danielle Roberts - 178395150 Devsite localized content from translation request bf46b0... by Android Partner Docs - 178395145 Devsite localized content from translation request eea056... by Android Partner Docs - 178252225 Devsite localized content from translation request b00a9b... by Android Partner Docs - 178152122 Add AOSP links to December bulletins by Danielle Roberts - 178140880 Fix link to named anchor by Clay Murphy - 178116086 Update Oreo MR1's API level. by Android Partner Docs PiperOrigin-RevId: 178962421 Change-Id: I21bb710ff8e7c4c132c41b0d799edf17c7b2fff1 --- en/devices/tech/config/perms-whitelist.html | 302 ++++++++++----------- .../tech/debug/images/perf_trace_binder_trans.png | Bin 59949 -> 172766 bytes .../tech/debug/images/perf_trace_fence_end.png | Bin 33685 -> 126111 bytes en/devices/tech/debug/images/perf_trace_fences.png | Bin 0 -> 100410 bytes en/devices/tech/debug/images/perf_trace_fm_sf.png | Bin 53172 -> 141090 bytes .../debug/images/perf_trace_frame_previous.png | Bin 32622 -> 100367 bytes .../debug/images/perf_trace_normal_pipeline.png | Bin 50946 -> 159410 bytes .../debug/images/perf_trace_pending_frames.png | Bin 27322 -> 96977 bytes .../debug/images/perf_trace_previous_frame.png | Bin 39283 -> 143859 bytes .../debug/images/perf_trace_sf_comp_submit.png | Bin 49865 -> 111559 bytes .../debug/images/perf_trace_sf_latches_pend.png | Bin 49052 -> 128533 bytes .../tech/debug/images/perf_trace_sf_wake_sleep.png | Bin 42338 -> 117233 bytes .../tech/debug/images/perf_trace_sf_woken_et.png | Bin 52011 -> 147107 bytes en/devices/tech/debug/images/perf_trace_tl.png | Bin 51318 -> 160776 bytes en/devices/tech/debug/images/perf_trace_tl_pxl.png | Bin 70949 -> 265146 bytes .../tech/debug/images/perf_trace_wake_cpu0.png | Bin 33025 -> 106588 bytes .../images/perf_trace_wake_render_enqueue.png | Bin 56546 -> 189613 bytes .../tech/debug/images/perf_traces_fences.png | Bin 29704 -> 0 bytes en/devices/tech/debug/systrace.html | 210 +++++++++++--- en/devices/tech/index.html | 3 +- en/devices/tech/ota/ab_updates.html | 106 ++++++-- en/devices/tech/perf/low-ram.html | 17 -- 22 files changed, 389 insertions(+), 249 deletions(-) create mode 100644 en/devices/tech/debug/images/perf_trace_fences.png delete mode 100644 en/devices/tech/debug/images/perf_traces_fences.png (limited to 'en/devices') 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 @@ - Privileged Permission Whitelist Requirement + Privileged Permission Whitelisting @@ -20,173 +20,151 @@ See the License for the specific language governing permissions and limitations under the License. --> -

- 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 - /system/priv-app directory on the system image. -

- -

- Starting in Android 8.0, all privileged apps must be explicitly whitelisted in - system configuration XML files in the /etc/permissions directory. - If they are not, then the device will boot, but the device implementation will - not pass CTS. -

- -

Adding the whitelists

- -

- Permission whitelists for applications can be listed in a single or multiple XML - files located in the frameworks/base/etc/permissions directory, as follows: -

- -
    -
  • /etc/permissions/privapp-permissions-<OEM_NAME>.xml -
  • /etc/permissions/privapp-permissions-<DEVICE_NAME>.xml. -
- -

- There is no strict rule for organizing content, it can be decided by the device implementer as - long as all applications from /system/priv-app are whitelisted. For - example, Google has a single whitelist for all privileged applications developed - by Google. -

- -

- The following organization is recommended: -

- -
    -
  • Permissions for apps that are already included in AOSP tree are listed in - this file: /etc/permissions/privapp-permissions-platform.xml -
  • Permissions for Google applications are listed in this file: - /etc/permissions/privapp-permissions-google.xml -
  • For other applications, use files of the form: - - /etc/permissions/privapp-permissions-<device_name>.xml
    • -
- -

Whitelist generation tool

- -

- 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: -

- - 
development/tools/privapp_permissions/privapp_permissions.py
- -

- To generate an initial version of device-specific - privapp-permissions.xml, complete the following steps: - -

-
    -
  1. Build a system image, as follows:
    - 
    -. build/envsetup.sh
-lunch product_name
-make -j
    -
    2. - -
  2. Run the following tool to generate a privapp-permissions.xml - file that lists all signature|privileged permissions that are required to - be whitelisted.
    - 
    development/tools/privapp_permissions/privapp_permissions.py
    - - This tool prints XML content that can be used as a single file or split into - multiple files in /etc/permissions.

    - If device already includes whitelists in the /etc/permissions 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. -
    3. -
  3. Copy the generated files to the /etc/permissions directory, where the system - will read it during boot.
    4. -
-

Whitelist format

-
    -
  • Since the implementation is already in AOSP, only customization is needed. -
  • Permissions for apps that are included in AOSP tree are already whitelisted - in /etc/permissions/privapp-permissions-platform.xml -
    • -
- - +

+ Privileged applications are system applications located in the + /system/priv-app 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 /etc/permissions directory. Apps + not explicitly listed in these XML files are not granted privileged + permissions. +

+ +

Adding whitelists

+

+ Permission whitelists for applications can be listed in a single or multiple + XML files located in the frameworks/base/etc/permissions + directory as follows: +

+ +
    +
  • /etc/permissions/privapp-permissions-OEM_NAME.xml +
  • /etc/permissions/privapp-permissions-DEVICE_NAME.xml +
+ +

There is no strict rule for organizing content. Device implementers can + determine content structure as long as all applications from + /system/priv-app are whitelisted. For example, Google has a + single whitelist for all privileged applications developed by Google. We + recommend the following organization: +

+ +
    +
  • Permissions for apps that are already included in the Android Open Source + Project (AOSP) tree are listed in + /etc/permissions/privapp-permissions-platform.xml.
    • +
  • Permissions for Google applications are listed in + /etc/permissions/privapp-permissions-google.xml.
    • +
  • For other applications, use files of the form: + /etc/permissions/privapp-permissions-DEVICE_NAME.xml. +
    • +
+ +

Generating whitelists

+ +

+ To automatically generate a whitelist for all applications available on the + system image, use the AOSP command line tool at + development/tools/privapp_permissions/privapp_permissions.py. To + generate an initial version of device-specific + privapp-permissions.xml: +

+ +
    +
  1. Build a system image: + 
    +    . build/envsetup.sh
+    lunch PRODUCT_NAME
+    make -j
    +
    2. +
  2. Run the privapp_permissions.py script to generate a + privapp-permissions.xmlfile that lists all + signature|privileged permissions required to be whitelisted: + 
    development/tools/privapp_permissions/privapp_permissions.py
    + This tool prints XML content that can be used as a single file or split into + multiple files in /etc/permissions. + If the device already includes whitelists in the + /etc/permissions 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. +
    3. +
  3. Copy the generated files to the /etc/permissions directory, + where the system will read those files during boot.
    4. +
+ +

Customizing whitelists

+ +

+ AOSP includes a whitelist implementation that can be customized as needed. + Permissions for apps included in AOSP are already whitelisted in + /etc/permissions/privapp-permissions-platform.xml. +

+ +

+ By default, the privapp_permissions.py 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: +

<!--
-    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>
     ...
-

Enabling logs to find missing - permissions

-

- When bringing up a new device, we recommend enabling transitional log-mode at - first, as follows: -

-

- ro.control_privapp_permission=log - -

- 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. -

-

- Error message format is as follows: -

-

- - PackageManager: Privileged permission {PERMISSION_NAME} for package - {PACKAGE_NAME} - not in privapp-permissions whitelist -

-

- All violations must be addressed by adding them to whitelists. Otherwise device - will not pass CTS tests. -

-

CTS tests for whitelists

-

- Your device implementation will not pass CTS if it contains privileged apps that - do not appear in a whitelist at /etc/permissions. -

-

- The PrivappPermissionsTest.java test enforces the - signature|privileged permission whitelist, as follows: -

    -
  • Reports the permissions that are granted into the CTS log. -
  • Ensures all priv permissions are exclusively granted to applications - declared in <privapp-permissions>, 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.
-

Run-time enforcement of - whitelists

-

- Once the whitelists are in place, run-time enforcement can be enabled by setting - a build property ro.control_privapp_permission=enforce. -

-

- Note: Please note that regardless of - ro.control_privapp_permission property state, only devices with - properly whitelisted privileged permissions for all privileged applications will - pass CTS tests. -

+

Finding missing permissions

+ +

+ When bringing up a new device, find missing permissions by enabling + transitional log-mode: +

+ +
ro.control_privapp_permission=log
+ +

+ 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: +

+ +
+PackageManager: Privileged permission {PERMISSION_NAME} for package {PACKAGE_NAME} - not in privapp-permissions whitelist
+
+ +

+ 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. +

+ + +

Enforcing whitelists

+ +

+ After whitelists are in place, enable runtime enforcement by setting the build + property ro.control_privapp_permission=enforce. +

+ + 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 Binary files a/en/devices/tech/debug/images/perf_trace_binder_trans.png and b/en/devices/tech/debug/images/perf_trace_binder_trans.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_fence_end.png and b/en/devices/tech/debug/images/perf_trace_fence_end.png differ 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 Binary files /dev/null and b/en/devices/tech/debug/images/perf_trace_fences.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_fm_sf.png and b/en/devices/tech/debug/images/perf_trace_fm_sf.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_frame_previous.png and b/en/devices/tech/debug/images/perf_trace_frame_previous.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_normal_pipeline.png and b/en/devices/tech/debug/images/perf_trace_normal_pipeline.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_pending_frames.png and b/en/devices/tech/debug/images/perf_trace_pending_frames.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_previous_frame.png and b/en/devices/tech/debug/images/perf_trace_previous_frame.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_sf_comp_submit.png and b/en/devices/tech/debug/images/perf_trace_sf_comp_submit.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_sf_latches_pend.png and b/en/devices/tech/debug/images/perf_trace_sf_latches_pend.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_sf_wake_sleep.png and b/en/devices/tech/debug/images/perf_trace_sf_wake_sleep.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_sf_woken_et.png and b/en/devices/tech/debug/images/perf_trace_sf_woken_et.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_tl.png and b/en/devices/tech/debug/images/perf_trace_tl.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_tl_pxl.png and b/en/devices/tech/debug/images/perf_trace_tl_pxl.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_wake_cpu0.png and b/en/devices/tech/debug/images/perf_trace_wake_cpu0.png differ 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 Binary files a/en/devices/tech/debug/images/perf_trace_wake_render_enqueue.png and b/en/devices/tech/debug/images/perf_trace_wake_render_enqueue.png differ 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 Binary files a/en/devices/tech/debug/images/perf_traces_fences.png and /dev/null differ 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.

Let's walk through the frame beginning at 15409ms:

-

-

Figure 1. Normal UI pipeline, -EventThread running.

+
+ + + +
+ Figure 1. Normal UI pipeline, EventThread running. +
+

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.

While EventThread is running, the UI thread for TouchLatency becomes runnable. To see what woke it, click the blue section:

-

-

Figure 2. UI thread for -TouchLatency.

+
+ + + +
+ Figure 2. UI thread for TouchLatency. +
+

Figure 2 shows the TouchLatency UI thread was woken by tid 6843, which corresponds to EventThread. The UI thread wakes:

-

-

Figure 3. UI thread wakes, renders a -frame, and enqueues it for SurfaceFlinger to consume.

+
+ + + +
+ Figure 3. UI thread wakes, renders a frame, and enqueues it + for SurfaceFlinger to consume. +
+

If the binder_driver tag is enabled in a trace, you can select a binder transaction to view information on all of the processes involved in that transaction:

-

-

Figure 4. Binder transaction.

+
+ + + +
+ Figure 4. Binder transaction. +
+

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.

During the queueBuffer on the SurfaceFlinger side, the number of pending frames from TouchLatency goes from 1 to 2:

-

-

Figure 5. Pending frames goes from 1 to -2.

+
+ + + +
+ Figure 5. Pending frames goes from 1 to 2. +
+

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.

Soon after, SurfaceFlinger's main thread is woken by a second EventThread so it can output the older pending frame to the display:

-

-

Figure 6. SurfaceFlinger's main thread -is woken by a second EventThread.

+
+ + + +
+ Figure 6. SurfaceFlinger's main thread is woken by a second + EventThread. +
+

SurfaceFlinger first latches the older pending buffer, which causes the pending buffer count to decrease from 2 to 1:

-

-

Figure 7. SurfaceFlinger first latches -the older pending buffer.

+
+ + + +
+ Figure 7. SurfaceFlinger first latches the older pending + buffer. +
+

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 mdss tracepoint, so they may not be there on your SOC.)

-

-

Figure 8. SurfaceFlinger sets up -composition and submits the final frame.

+
+ + + +
+ Figure 8. SurfaceFlinger sets up composition and submits the + final frame. +
+

Next, mdss_fb0 wakes on CPU 0. mdss_fb0 is the display pipeline's kernel thread for outputting a rendered frame to the display. We can see mdss_fb0 as its own row in the trace (scroll down to view).

-

-

Figure 9. mdss_fb0 wakes -on CPU 0.

+
+ + + +
+ Figure 9. mdss_fb0 wakes on CPU 0. +
+

mdss_fb0 wakes up, runs for a bit, enters uninterruptible sleep, then wakes again.

@@ -224,9 +291,17 @@ browser.

When you first open the systrace, you'll see something like this:

-

-

Figure 10. TouchLatency running on Pixel -XL (most options enabled, including mdss and kgsl tracepoints).

+
+ + + +
+ Figure 10. TouchLatency running on Pixel XL (most options + enabled, including mdss and kgsl tracepoints). +
+

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 (com.prefabulated.touchlatency) at a vsync:

-

-

Figure 11. FrameMissed correlation with -SurfaceFlinger.

+
+ + + +
+ Figure 11. FrameMissed correlation with SurfaceFlinger. +
+

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).

-

-

Figure 12. SurfaceFlinger wakes and -immediately goes to sleep.

+
+ + + +
+ Figure 12. SurfaceFlinger wakes and immediately goes to + sleep. +
+

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.

-

-

Figure 13. mdss_fb0_retire -fences.

+
+ + + +
+ Figure 13. mdss_fb0_retire fences. +
+

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:

-

-

Figure 14. Frame previous to busted -frame.

+
+ + + +
+ Figure 14. Frame previous to busted frame. +
+

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.

Investigate exactly where that fence ends to determine what controls it:

-

-

Figure 15. Investigate fence end.

+
+ + + +
+ Figure 15. Investigate fence end. +
+

A workqueue contains a __vsync_retire_work_handler that is running when the fence changes. Looking through the kernel source, you can see @@ -303,8 +415,16 @@ might not get scheduled accurately.

Check the previous frame to determine if that contributed; sometimes jitter can add up over time and eventually cause us to miss a deadline.

-

-

Figure 16. Previous frame.

+
+ + + +
+ Figure 16. Previous frame. +
+

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

Configuration

Getting the most out of Android requires tuning of the kernel and +href="/devices/tech/config/kernel.html">kernel, OpenGLRenderer, and more. See the subpages of this section for details.

» Configuration Information

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 @@
  • 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.
  • - 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. +
    • +
  • + 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. +
    • +
  • + 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.
  • Any errors (such as I/O errors) affect only the unused @@ -59,7 +67,8 @@
  • 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.
  • dm-verity @@ -72,7 +81,73 @@

    About A/B system updates

    -

    A/B system updates affect the following:

    +

    + 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. +

    + +

    + For OEMs supplying their own client, the client needs to: +

    + +
      +
    • + 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. +
      • +
    • + 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 + Check now button for users to check for the latest + update.) +
      • +
    • + Call update_engine with the HTTPS URL for your update + package, assuming one is available. update_engine will + update the raw blocks on the currently unused partition as it streams + the update package. +
      • +
    • + Report installation successes or failures to your servers, based on + the update_engine result code. If the update is applied + successfully, update_engine 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. +
      • +
    + +

    Optionally, the client can:

    + +
      +
    • + 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.) +
      • +
    • + 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.) +
      • +
    + +

    On the system side, A/B system updates affect the following:

    • @@ -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.

      -

      What does GmsCore do?

      - -

      In Google's A/B implementation, the platform APIs and - update_engine provide the mechanism while GmsCore provides the - policy. That is, the platform knows how to apply an A/B update and all - that code is in AOSP (as mentioned above); but it's GmsCore that decides - what and when to apply.

      - -

      If you’re not using GmsCore, you can write your own replacement using the - same platform APIs. The platform Java API for controlling - update_engine is android.os.UpdateEngine: - frameworks/base/core/java/android/os/UpdateEngine.java. - Callers can provide an UpdateEngineCallback to be notified of status - updates: - frameworks/base/+/master/core/java/android/os/UpdateEngineCallback.java. - Refer to the reference files for the core classes to use the interface.

      -

      Which systems on a chip (SoCs) support A/B?

      As of 2017-03-15, we have the following information:

      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 -

      Disable JIT

      - -

      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.
      -
      - 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.

      - -

      This can be achieved by adding the following line to the product makefile:

      -
      -PRODUCT_PROPERTY_OVERRIDES += dalvik.vm.jit.codecachesize=0
-

      Launcher Configs

      -- cgit v1.2.3