Snapdragon™ Web Engine Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Snapdragon™ Web Engine Overview
80-NN732-1 A
Confidential and Proprietary – Qualcomm Technologies, Inc.

Restricted Distribution: Not to be distributed to anyone who is not an employee of either Qualcomm or its subsidiaries without the express approval of Qualcomm’s Configuration Management.

NO PUBLIC DISCLOSURE PERMITTED: Please report postings of this document on public servers or websites to: DocCtrlAgent@qualcomm.com.
Restricted Distribution: Not to be distributed to anyone who is not an employee of either Qualcomm or its subsidiaries without the express approval of Qualcomm’s
Configuration Management.
Not to be used, copied, reproduced, or modified in whole or in part, nor its contents revealed in any manner to others without the express written permission of
Qualcomm Technologies, Inc.
Qualcomm reserves the right to make changes to the product(s) or information contained herein without notice. No liability is assumed for any damages arising directly
or indirectly by their use or application. The information provided in this document is provided on an “as is” basis.
This document contains confidential and proprietary information and must be shredded when discarded.
Qualcomm is a trademark of QUALCOMM Incorporated, registered in the United States and other countries. All QUALCOMM Incorporated trademarks are used with
permission. Other product and brand names may be trademarks or registered trademarks of their respective owners.
This technical data may be subject to U.S. and international export, re-export, or transfer (“export”) laws. Diversion contrary to U.S. and international law is strictly
prohibited.
Qualcomm Technologies, Inc.
5775 Morehouse Drive
San Diego, CA 92121
U.S.A.
© 2014 Qualcomm Technologies, Inc.
All rights reserved.
PAGE 2 80-NN732-1 A May 2014 Confidential and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
Revision History
Revision Date Description
A May 2014 Initial release
Contents
 SWE Introduction
 Getting SWE Code, Binaries, and Patches
 High-level Understanding of Code/Projects and Building
 OEM Side Enhancement/Migration/Integration Guide
 Debugging and Triaging SWE Issue
 Additional Information
 References
 Questions?
SWE Introduction
SWE and its Motivation
 What is SWE?
 SWE is Snapdragon™ Web Engine based on Chromium for Android™. For
details, refer to [R1].
 Motivation
 The objective of this version of Chromium Browser Project is to provide an
optimized environment for web developers and embedders targeting Qualcomm
Technologies, Inc.’s (QTI) Snapdragon processors.
 SWE is a non-system WebView based on Chromium. It is intended to fulfill the
needs of a fully-featured browser.
SWE Architecture
Baseline Content Shell
 Baseline is a simple web engine from Google without QTI’s WebTech

changes. It is not a complete browser and does not have QTI WebTech
optimizations.
 Baseline Content Shell APK for Android can be obtained by building the
pure Chromium code for Android. For detailed instructions in
chromium.org website, refer to [R12].
Content Shell
 Content Shell is a minimal application that embeds the Chromium content

module to render web pages. It is a thin layer on top of the Chromium
content API.
 All subsequent references to “Content Shell” in this document refers to
“SWE based content shell” i.e., “Content Shell” will refer to “Chromium
baseline content shell” with QTI’s WebTech changes delivered as part of
Code Aurora chrome4sdp project. It is not a complete browser but has a
minimum shell, minimum UI, and has QTI’s key WebTech optimizations.
SWE Android Browser
 SWE Android Browser is a Chromium baseline with QTI's WebTech

changes and default Android browser User Interface (UI).
Chromium Backend Android

Engine Chrome Applications
Desktop
Chrome Repo
SWE Android Browser

QTI's Optimization
SWE Branches
 SWE released at Code Aurora is under several branches; each branch

can be mapped to a particular Chrome version.
 Sync and build information regarding currently available SWE branches is
published officially at
https://www.codeaurora.org/xwiki/bin/Chromium+for+Snapdragon/Build
SWE branch Chrome version Android version
1847 34 4.4, 4.3
1700 32 4.4, 4.3
1599 30 4.4, 4.3
1500 28 4.4, 4.3
Note: Android version refers to Android releases for which QTI will provide support for SWE Android
browser for that particular SWE branch.
GCC vs LLVM
 Multiple configuration options for building SWE

 For build systems, primary choices are:
 Ninja
 Make
User experience suggests that Ninja has been significantly faster compared to Make and
is considered as the default build system.
 For compiler toolchains, primary choices are:
 GCC
 LLVM
 As part of the build process initialization, user needs to pick a build system
(Ninja* or Make) and a compiler toolchain (llvm* or gcc)
GCC vs LLVM (cont.)
 Ninja vs Make
 Controlled by defining GYP_GENERATORS as Ninja or Make on the gclient
runhooks line.
GYP_GENERATORS=ninja gclient runhooks -v
 LLVM vs GCC
 Controlled by adding clang=1 or clang=0 to GYP_DEFINES on the gclient
runhooks line.
GYP_DEFINES="$GYP_DEFINES clang=1" gclient runhooks –v
 Clang = 1 → LLVM
 Clang = 0 → GCC
SWE vs Chromium Based Webview KitKat Onwards
 KitKat onwards, the default webview (as released in Google’s Android

source code) is based on chromium.org.
 SWE is a minor fork of chromium.org. However, through SWE, QTI
attempts to provide a smartphone to the end user for better web browser
experience through tuning of the following parameters (and which is not
tied to a “particular” Android version):
 Performance
 Javascript engine performance
 Rendering performance (zoom, scroll, fling, etc.)
 HTTP networking stack performance (resource fetching, page load time, etc.)
 Power saving
 Browser memory footprint
 Supports new features
Licenses
 The source code available for download from Code Aurora may be
covered by one or more different licenses. The files in Code Aurora may
contain changes and additions on top of the code from the original source.
These changes and additions are covered under the same license as the
original source. In many cases, the license is explicitly listed at the
beginning of the file. A list of licenses is included for reference purposes
only.
 GPLv2
 BSD
 Apache 2.0
 Chromium may contain additional licenses. See chromium.org for a list of

licenses and additional information. For details, see [R2].
Getting SWE Code, Binaries, and
Patches
SWE Deliverables
 SWE deliverables include:

 Open source changes released at Code Aurora (www.codeaurora.org)
 Snapdragon optimized libraries released as proprietary binaries along with the
SWE package or the libraries can be synced from Qualcomm Innovation Center
(QuIC) Web Technology server (https://webtech-devx.qualcomm.com)
 Refer to slide 18 for the procedure to sync SWE code from Code Aurora.
 Refer to slides 22 and 29 for the list of proprietary libraries used by SWE
Android Browser and related procedure to receive them.
Getting SWE Open Source Code
 Chromium for Snapdragon is a minor fork of chromium.org, the sync and

build process follows closely that of the chromium.org mainline, and has
the same system setup and external dependencies as that project.
 SWE open source code is distributed to OEMs through Code Aurora
forum chrome4sdp (Chromium for Snapdragon) project.
 Ubuntu Linux is the most popular platform for Android related projects.
The instructions on the next slide have been tested on Ubuntu, which is
the recommended platform. However, the instructions must ideally work
on all Linux versions.
Getting SWE Open Source Code (cont.)
 Pre-requisites
1. Install git with normal configurations.
2. Fetch depot_tools.
$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
The above command gets a copy of the depot_tools directory in the directory from where
the command was fired.
3. Add depot_tools to your PATH variable.
$ export PATH="$PATH":<pwd>/depot_tools
 For details, refer to [R3].
Getting SWE Open Source Code (cont.)
 Syncing Code:
1. Update .gclient file in your workspace with appropriate solution content for
sync. Example for 1700 branch, .gclient content should be:
solutions = [
{ "name" : "src",
"url" :
"git://codeaurora.org/quic/chrome4sdp/chromium/src.git@refs/
remotes/origin/1700",
"deps_file" : ".DEPS.git",
"managed" : True,
"safesync_url": "",
},
]
target_os = ["android"]
2. Get the code. Give following command from root of your workspace:
<WorkspaceRoot>$ gclient sync -n --no-nag-max
<WorkspaceRoot>$ cd src
<WorkspaceRoot/src>$ . build/android/envsetup.sh
<WorkspaceRoot/src>$ GYP_GENERATORS=ninja gclient runhooks
Note: The above .gclient is for SWE 1700. For details on other branches, refer to [R4].
Choosing Between LLVM and GCC Versions
 In order to choose LLVM or GCC version explicitly, run the following

commands after running the envsetup.sh (instead of last
GYP_GENERATORS command):
 Build with LLVM
<WorkspaceRoot/src>$ GYP_DEFINES="$GYP_DEFINES clang=1" gclient runhooks -v
 Build with GCC

<WorkspaceRoot/src>$ GYP_DEFINES="$GYP_DEFINES clang=0" gclient runhooks -v
Receiving Proprietary Binaries
 The proprietary binaries are synced to SWE workspace. While syncing the
entire SWE code from Code Aurora, there may be a need to use a
different/updated binary at the OEM end under the following (but not
limited to) circumstances:
 A new binary with a fix for a OEM reported issue.
 OEM’s decision to integrate only a SWE proprietary binaries (say only v8) on
their own Chromium based browser.
 In order to sync only these proprietary binaries, OEMs need to perform the
following steps:
1. Clone the git repository (corresponding to the binary) from the webtech-
devx.qualcomm.com servers. (Refer to slide 23 for the complete repository
path)
2. Checkout a particular hash. Please contact QTI's WebTech Customer
Engineering team to know the exact/latest/applicable hash ID through a
Salesforce case.
Receiving Proprietary Binaries (cont.)
Name webtech-devx.qualcomm.com repository

libswenetxt_plugin.so http://webtech-devx.qualcomm.com/swe/packages/libnetxt.git
libswev8.so http://webtech-devx.qualcomm.com/swe/packages/v8.git
https://webtech-devx.qualcomm.com/swe/packages/skia/include.git
libsweskia.so
https://webtech-devx.qualcomm.com/swe/packages/skia/src.git
Fast_webview_java.jar* https://webtech-devx.qualcomm.com/swe/packages/fast-webview.git
*Introduced in SWE 1847
 For example, to get the headers for libsweskia.so:

<WorkspaceRootForSync>$ git clone https://webtech-
devx.qualcomm.com/swe/packages/skia/include.git
<WorkspaceRootForSync>$ cd include
<WorkspaceRootForSync/include$ git checkout
215d83fb517cd3a9a0040023df833e7aa78d735b
Locating SWE CAF Patches
1. Access the following link for SWE projects git repositories at Code
Aurora:
https://www.codeaurora.org/cgit/quic/chrome4sdp/
2. From the projects list, choose a project of interest (e.g., chromium/blink).
This opens the summary page for the project:
https://www.codeaurora.org/cgit/quic/chrome4sdp/chromium/blink/
3. Choose a branch of interest (e.g., branch 1700). This opens the log for
the project for that particular branch:
https://www.codeaurora.org/cgit/quic/chrome4sdp/chromium/blink/log/?h=1700
SWE Patch Documents (w.r.t. Major Features Added in SWE)
 All feature-wise patches added by QTI have been captured in

“Performance Improvement Patches for Chromium Content Shell”
document. Contact QTI’s WebTech Customer Engineering team through a
Salesforce case to get the latest/applicable version of the document.
 The document identifies the patches under the following high-level
features:
 JavaScript engine optimization
 System performance patches for Chromium Content Shell
 SKIA optimizations for Chromium Content Shell
 DOM core optimizations for Chromium Content Shell
 HTML5/Parallel canvas patches for Chromium Content Shell
 WebGL implementation patches for Chromium Content Shell
 Rendering optimizations for Chromium Content Shell
 Video optimizations for Chromium Content Shell
 HTTP network stack optimization patches for Chromium Content Shell
 Miscellaneous patches
High-level Understanding of
Code/Projects and Building
SWE Sync and Build System (gclient, gyp, etc.)
 gclient is a meta-checkout tool for managing both subversion and git

checkouts. It is similar to the repo tool except that it works on Linux, OS X,
and Windows and supports both svn and git. It is a python script to
manage a workspace of modular dependencies that are checked out
independently from different subversion or git repositories.
 Chromium (and SWE) uses a package of scripts called depot_tools, to
manage interaction with the source code repository. gclient is a utility
within depot_tools.
 .gclient is a python script. It specifies the projects (solutions) to be
fetched, additional hooks to be run when the meta checkout is synced,
and OS-specific dependencies fetch instructions. Each project described
in the solutions array can contain an optional DEPS file that needs to be
processed.
 A DEPS file specifies the dependencies of a project. It is a python script. It
decides the files to be fetched, relative paths of the files, and hooks to run
after sync.
 For details on the above points, refer to [R5].
SWE Sync and Build System (gclient, gyp, etc.) (cont.)
 gyp (Generate your product) is a Chromium’s solution to meet

Chromium’s requirement for a simple and universal cross-platform build
representation. This file provides the source files to be compiled, .gypi
include files, list of targets to be built, dependent libraries, etc. For a
complete understanding of .gyp language specification and user guide,
refer to [R6] and [R7].
List of Binaries Used in SWE
 Apart from the open source performance optimization changes that are
delivered as patches at chrome4sdp (Chromium for Snapdragon) project
on Code Aurora, several optimizations are released to OEMs as
proprietary libraries. Following table lists these libraries:
Name Description Workspace directory
libswenetxt_plugin.so HTTP networking stack optimization src/third_party/libnetxt/lib/target
libswev8.so V8 Javascript engine optimization src/v8/lib/target/
libsweskia.so Skia optimization src/third_party/skia/src/lib/target/Release/
 These libraries are packaged within SWE APKs and are installed on the
device similar to any other third party APKs with libraries.
List of Key Enhancements in SWE
 Following are the key enhancements/features added by QTI for the

regular chrome release:
 V8 Javascript engine optimization
 Benchmark score and performance enhancement of JavaScript processing for browser
 System performance patches
 Reduce app-launch latency and text layout processing
 Reduce power consumption by optimizing Adreno™ interface with browser
 Reduce memory usage through aggressive cache clean-up
 DOM core optimizations
 DOM tree traversal optimization through prefetch
 DOM search and append optimization
List of Key Enhancements in SWE (cont.)
 SKIA optimizations
 Neonizing few filters and blitting routines
 Improve vectorization and parallelization
 Cache compiler option to optimize cache-line-size
 HTML5/Parallel canvas patches
 Improve rendering of canvas content
 FPS improvement
 WebGL implementation patches
 Enable WebGL
(Note: WebGL is not enabled on Android KitKat WebView)
 WebGL content performance Improvement
List of Key Enhancements in SWE (cont.)
 Rendering optimizations
 Improvement of key routines responsible for page rendering
 Support for new features (e.g., enabling deadline scheduling,
capturePictureAsync, etc.)
 Video optimizations
 HTTP network stack optimization patches
 Speeding up page download
 Reduce latency in resource fetching on slower link through early connection
 Object pre-fetch
 Suppression of HTTP headers for uplink traffic reduction
 Warm up the modem
 Power consumption optimization through intelligent management of TCP
messages
 Miscellaneous patches
 WAP support to meet regional OEM requirements
 OMA download
Building SWE With Default V8
1. After the SWE code is synced (Refer to slides 18 to 20 for details), SWE
can be built to generate either “Content Shell” or “SWE Android
Browser”:
<WorkspaceRoot/src>$ ninja -C out/Release content_shell_apk
<WorkspaceRoot/src>$ ninja -C out/Debug content_shell_apk
<WorkspaceRoot/src>$ ninja -C out/Release swe_android_browser_apk
<WorkspaceRoot/src>$ ninja -C out/Debug swe_android_browser_apk
2. This will generate APK at
<WorkspaceRoot/src/out/<Release/Debug>/apks/
Building SWE with a Specific V8 Version
1. When SWE project is synced as mentioned in slides 18 to 20, a prebuilt

version of QTI’s proprietary V8 javascript engine for SWE, i.e.,
libswev8.so is also synced under <WorkspaceRoot>/src/v8/lib.
2. In order to generate “SWE Android Browser” APK or “Content Shell”
APK using a version of libswev8.so other than the default synced
libswev8.so, libswev8.so in <WorkspaceRoot>/src/v8/lib/target needs to
be replaced.
3. After replacing, the required APK can be generated.
Building SWE with Other than Default Proprietary Libraries
1. As explained in slides 22 and 23, there may be a need for a

different/updated version of default proprietary libraries. The new
version of the proprietary libraries can be obtained at the OEM end
either through webtech-devx.qualcomm.com servers or through an SBA
released by the QTI’s CE team.
2. Replace the default *.so present in their respective directories in the
SWE workspace (refer to slide 29), and then fire a build.
3. For libsweskia.so, ensure that the skia headers are also replaced in the
workspace, in case there is a header change.
Disabling/Enabling Features Through Switches
 Chromium has numerous command line flags (or “switches”) that

Chromium (and SWE Android browser) accepts in order to enable
particular features or modify the otherwise default functionality. Set of
switches in the current Chromium release can be found at [R8].
 These switches/flags are a constant string defined in one of the many
switch definition files (both .cc and .java). In order to enable the switch,
the switch is appended to a globally accessible SwitchMap at any/all logic
entry points either in C and java space. Functional logic associated with
the switch/flag can be then turned ON or OFF at runtime depending on the
switch value in the map.
 Major QTI's enhancements/features in SWE are also controlled through
switches. Unfortunately, there is no single file where these switches are
defined or a single file where all the switches get appended to the
SwitchMap. For details, refer to [R9].
Disabling/Enabling Features Through Switches (cont.)
 A list of C files where a switch is defined can be found through the

following command from the root of SWE workspace:
find . -name *switch*.cc
 One such file where most the switch is defined is
content/public/common/content_switches.cc
 In java space, it is generally in
src/content/public/android/java/src/org/chromium/content/common/CommandLine.
java
 One such file where the switch added by QTI gets appended to the
SwitchMap is at
content/browser/android/content_startup_flags.cc
Disabling/Enabling Features Through Switches (cont.)
 Features controlled through switches can be enabled/disabled through

adb (without requiring to do code changes and rebuild). For example, in
order to disable fast webview, a swe_command_line needs to be added
as follows:
$ adb shell cat /data/data/com.android.swe.browser/config/swe-
command-line
swe_command_line --disable-fast-webview
Knowing Expected Benchmarks for a Project
 QTI’s WebTech team is constantly working on improving the browser

benchmark numbers and user experience along with the addition of
support of the latest HTML 5 and CSS features.
 The benchmark depends on the device capabilities, namely (but not
limited to) chipset, memory, resolution, and Android version. OEMs are
requested to contact QTI’s WebTech CE team through a Salesforce case
in order to get any clarifications regarding any of the browser
benchmark/performance/memory footprint related scores with respect to
their device.
 Following are the benchmark and performance tests that QTI uses to
evaluate performance:
 Sunspider  BrowserMark 2.0  Dromaeo
 V8  App-launch latency  IE fishtank
 Vellamo  Peacekeeper  JSGameBench
 Octane  Microsoft Bayou
 Mozilla Kraken  Guimark2
OEM Side
Enhancement/Migration/Integration
Guide
Low-end Memory Devices Customization/Good Practices
 On low-end devices with memory constraints, there may be a need to do a

Performance tuning vs Memory footprint vs Functional features
enablement.
 There is scope for browser memory customization to have a lower
footprint to meet memory constraints on certain devices with limited
resources. Smaller footprint could be achieved through tuning certain
browser parameters such as tile preparation area, maximum number of
sandboxed processes, aggressive gc/clean-up, memory cache size, etc.
 OEMs can contact QTI’s WebTech CE team through a Salesforce case
with their specific concerns/memory requirements to address their issues
accordingly.
 Some functional features (such as WebGL) are better when enabled only
on devices with certain minimum memory requirement. QTI’s WebTech
CE team can give feedback regarding enabling features on specific OEM
devices.
Impact on Webapp Developers
 Presence of SWE Android browser APK on the device will not affect the
behavior of a third partly webapp by default, i.e., the webapp behavior will
be per the implementation and the features as exposed by Google’s
Android through android.webkit.WebView.
 In KitKat, the default WebView (android.webkit.WebView), as released
with Google’s Android source code is also based on chromium.org. The
default WebView on earlier releases (i.e., till Android 4.3) was based on
webkit.org. Google has released a migration guide on how this change is
going to impact webapp developers at:
http://developer.android.com/guide/webapps/migrating.html
 OEMs are recommended to follow the migration guide and contact Google
directly for any functional, performance, or stability issues reported on
third party web applications.
Browser Application Level Customization
 SWE Android browser application code is present at the following location

of your SWE workspace:
src/swe/browser/src/com/android/swe/browser/
 BrowserWebView (BrowserWebView.java) of SWE Android browser
application extends org.codeaurora.swe.WebView (and not
android.webkit.WebView of framework.jar). Hence, SWE Android browser
is able to take advantage of QTI’s SWE key enhancements/features.
Refer to the classes imported via org.codeaurora.swe package within
SWE Android browser application implementation in order to understand
more on how other key SWE enhancements are being used in the
application code.
 OEMs can do application level customization by modifying the
implementation of application code at the location mentioned above. They
can engage with QTI's WebTech Customer Engineering team to discuss
issues through a Salesforce case.
Problem Areas for SWE Cases on Salesforce
 For any SWE issues, OEMs must raise a Salesforce case with the
following problem areas to ensure that the cases get routed to the correct
SWE CE PoC:[1]
Problem Area 1 Multimedia

Problem Area 2 Browser
Problem Area 3 SWE
 Other values for “Problem Area 3” is going to be used for issues on legacy
WebView (android.webkit.WebView on 4.3 or less).
[1] In future, given the WebTech team’s main focus is on SWE, QTI is planning to reorganize Problem Area 3 as:
• Webcore
• V8
• Rendering
• Network stack
• Performance
• Power
• Memory optimization
• SKIA
• Browser UI
• Legacy browser
• Other
With this change, all the PA3 fields except for “Legacy Browser” will be for SWE project. “Legacy Browser” can be used for Android’s (all versions) WebView
queries.
Debugging and Triaging SWE Issue
Information Required from OEMs
 In order to get a complete understanding of a problem and to enable QTI’s

development team to give faster feedback to OEMs, it is recommended that
all SWE OEMs provide the following information while raising a SWE case
through Salesforce:
 Device/Model
 Memory size (RAM)
 Processor/Chipset
 SWE version and/or proprietary lib version if applicable to a case
 Does the issue occur on equivalent version of chrome?
 Does the issue occur on SWE?
 Does the issue occur on Content Shell?
 What are the steps to reproduce?
 Can a video of the procedure be uploaded?
 What is the frequency?
 What is the priority?
 What is the need-by date?
 Is it a stability issue or a functional issue or a performance issue?
 Upload all necessary logs (logcat, if it is a crash → symbols, v8 → blackbox &
tombstone).
 Was issue verified on any other standard device/platform?
 Android version tested on (4.2.1, 4.2.2, etc.)
Basic Triage Overview
 Once an issue is reported, QTI’s WebTech CE engineers perform the

following analysis to identify the correct sub-tech team within QTI
WebTech to whom the issue should be assigned
 QTI’s WebTech CE engineers will also engage the case submitter at the
OEM-side to complete the following analysis:
a. Check SWE Android browser (without OEM changes)
b. Check content shell behavior
c. Check baseline behavior
d. Check chrome/chrome beta behavior
I. If it occurs only in (a) → UI team
II. If it occurs in (a) and (d), put a note on the JIRA that the issue is reproducible on
chrome as well → UI team
III. If it occurs only in (c) → Baseline issue. Lower priority. Assign it to the Project team
area, so that the correct team can look into it when required.
IV. If it occurs only in (a) and (b), assign it to the Webcore team (since QTI does not have
too many commitments coming from Rendering team).
Basic Triage Overview (cont.)
e. If the issue is a pure UI element/navigation issue → Assign it to the UI team

f. If it is a stability issue:
I. Check call-stack
I. If it is an obvious issue, assign it to the tech team.
II. If it is non-obvious, assign it to the integration team.
Narrowing the Source of Problem (Feature-Wise)
 As explained in slides 36 to 38 , certain features/enhancements can be

turned ON or OFF through the switches/flags.
 At certain times, it may be useful to turn ON or OFF certain suspicious
features to narrow down the source of a problem. In order to turn ON/OFF
the switch, all entry points, where the switch is appended to the
SwitchMap (both through java or C space) need to be modified
accordingly.
 This may not be the final solution, but could give a useful insight to the
development team with respect to source and nature of the problem.
Collecting Black Box for libswev8.so Crash
 Black box is a proprietary V8 feature that records information useful for

debugging in case of a crash. It is often referred as a poor man's core file
and has no overhead during execution. Black boxes can be extremely
useful in debugging hard-to-reproduce crashes involving V8 library in the
call stack.
 Steps to activate black box and collect the dumps:
1. Start adb in root mode and remount (in adb shell)
$ adb root
$ adb remount
2. Activate black box recording as follows (in adb shell)
# mkdir -p /data/tombstones/v8-black-box
# chmod 777 /data/tombstones/v8-black-box
3. Black box recording will be enabled the next time V8 starts if the directory
exists and has mode 777. A message in logcat will appear the next time the
browser starts:
“I/v8 ( 1807): black box recording enabled”
4. After a crash (triggered by SIGQUIT, SIGILL, SIGBUS, SIGFPE, or
SIGSEGV), a dump file /data/tombstones/v8-black-box/v8-black-box.1234
(where 1234 is the pid of the crashed process) is created. Pull the dump file
through the adb pull command.
Collecting Black Box for libswev8.so Crash (cont.)
 Points to note:
 The procedure may not work on a non-rooted device as it may not be possible
to create a directory at this location.
 OEMs are requested to give the following information while reporting a V8
crash:
 Black box
 Tombstone crash call stack (matching the pid of the blackbox dump)
 Main logcat preceding the crash
 V8 library information (OEM can simply share the libswev8.so over the case)
Additional Information
Chrome Browser vs Chrome Beta Versions
 Google's Chrome for Android is an edition of Google Chrome released for

the Android system. It is also known as Chrome Stable. APK is available
on Google play for Android 4.0 and above.
 Google Chrome is still evolving and Google Chrome Beta provides latest
Chrome features. APK is available on Google play for Android 4.0 and
above versions. Google Chrome beta for Android may lack some of the
features of Chrome beta version for desktop but may also have additional
features.
Getting Chrome Version
 Version of Chrome (or Chrome Beta) installed on an Android device can

be found by typing the following in the address field of a browser:
chrome://version/
For example, 35.*.*.*
 SWE is a minor fork of the Chromium project and each SWE branch
corresponds to a particular Chrome version (can be known from the
procedure mentioned above). Comparing the behavior on SWE and
respective Chrome version can be used to determine if the issue is a base
Chromium issue or introduced by QTI’s SWE changes.
Chromium Development Calendar and Release Information
 Chrome release plan for 2014 is given below. For details refer to [R10].
Release Week of Branch Point (Monday of the week)
33 Dec 16th, 2013/ Jan 6th, 2014 (TBD)
34 Feb 17th, 2014
35 Mar 31st, 2014
36 May 12th, 2014
37 Jun 23rd, 2014
38 Aug 18th, 2014
39 Sep 29th, 2014
40 Nov 10th, 2014
 Note: Although Chrome is expected to move to release 40 towards the

end of 2014, Android WebView based default Android browser in KitKat
(Android 4.4.2) will still be based on 30. In comparison, SWE Android
browser will continue to move to a higher version of Chrome.
 Information regarding V8 engine version powering current Chrome
releases is also available at chromium.org website. V8 engine is also
expected evolve with newer versions of Chrome. For details, refer to
[R11].
os channel current_version previous_version current_reldate previous_reldate v8_version
android beta 34.0.1847.62 34.0.1847.45 3/13/2014 3/11/2014 3.24.35.14
android stable 34.0.1847.114 33.0.1750.136 4/9/2014 3/11/2014 3.24.35.21
References
Ref. Document
Qualcomm Technologies
Q1 Application Note: Software Glossary for Customers CL93-V3077-1
Resources
R1 http://www.chromium.org/Home
R2 https://www.codeaurora.org/xwiki/bin/Chromium+for+Snapdragon/
R3 http://dev.chromium.org/developers/how-tos/install-depot-tools
R4 https://www.codeaurora.org/xwiki/bin/Chromium+for+Snapdragon/Build
R5 http://dev.chromium.org/developers/how-tos/depottools
R6 https://code.google.com/p/gyp/wiki/GypLanguageSpecification
R7 https://code.google.com/p/gyp/wiki/GypUserDocumentation
R8 http://peter.sh/examples/?/chromium-switches.html
R9 http://www.chromium.org/developers/how-tos/run-chromium-with-flags
R10 http://www.chromium.org/developers/calendar
R11 http://omahaproxy.appspot.com/
References (cont.)
Ref. Document
Resources
R12 http://www.chromium.org/developers/design-documents/multi-process-architecture
R13 http://www.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
R14 http://www.chromium.org/developers/design-documents/inter-process-communication
R15 http://www.chromium.org/developers/design-documents/threading
R16 http://www.chromium.org/developers/how-tos/getting-around-the-chrome-source-code
R17 http://www.chromium.org/developers/code-reading/how-html5-s-filereader-works
R18 http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
R19 http://www.chromium.org/blink
R20 https://docs.google.com/document/d/1UkxPz9GDQXLBZcbw5OeUQpk1VIq_BKhm6BGvWJ5mKdU/edit
R21 http://www.chromium.org/developers
Questions?
https://support.cdmatech.com

Snapdragon™ Web Engine Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Uploaded by

Copyright:

Available Formats

You might also like

Snapdragon™ Web Engine Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Snapdragon™ Web Engine Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Uploaded by

Copyright:

Available Formats

Snapdragon™ Web Engine Overview

Confidential and Proprietary – Qualcomm Technologies, Inc.

Confidential and Proprietary – Qualcomm Technologies, Inc.

Revision Date Description

A May 2014 Initial release

 Baseline is a simple web engine from Google without QTI’s WebTech

 Content Shell is a minimal application that embeds the Chromium content

 SWE Android Browser is a Chromium baseline with QTI's WebTech

Chromium Backend Android

SWE Android Browser

 SWE released at Code Aurora is under several branches; each branch

SWE branch Chrome version Android version

1847 34 4.4, 4.3

1700 32 4.4, 4.3

1599 30 4.4, 4.3

1500 28 4.4, 4.3

 Multiple configuration options for building SWE

 KitKat onwards, the default webview (as released in Google’s Android

 Chromium may contain additional licenses. See chromium.org for a list of

 SWE deliverables include:

 Chromium for Snapdragon is a minor fork of chromium.org, the sync and

 In order to choose LLVM or GCC version explicitly, run the following

 Build with GCC

Name webtech-devx.qualcomm.com repository

*Introduced in SWE 1847

 For example, to get the headers for libsweskia.so:

 All feature-wise patches added by QTI have been captured in

 gclient is a meta-checkout tool for managing both subversion and git

 gyp (Generate your product) is a Chromium’s solution to meet

libswenetxt_plugin.so HTTP networking stack optimization src/third_party/libnetxt/lib/target

libswev8.so V8 Javascript engine optimization src/v8/lib/target/

libsweskia.so Skia optimization src/third_party/skia/src/lib/target/Release/

 Following are the key enhancements/features added by QTI for the

1. When SWE project is synced as mentioned in slides 18 to 20, a prebuilt

1. As explained in slides 22 and 23, there may be a need for a

 Chromium has numerous command line flags (or “switches”) that

 A list of C files where a switch is defined can be found through the

 Features controlled through switches can be enabled/disabled through

 QTI’s WebTech team is constantly working on improving the browser

 On low-end devices with memory constraints, there may be a need to do a

 SWE Android browser application code is present at the following location

Problem Area 1 Multimedia

 In order to get a complete understanding of a problem and to enable QTI’s

 Once an issue is reported, QTI’s WebTech CE engineers perform the

e. If the issue is a pure UI element/navigation issue → Assign it to the UI team

 As explained in slides 36 to 38 , certain features/enhancements can be

 Black box is a proprietary V8 feature that records information useful for

 Google's Chrome for Android is an edition of Google Chrome released for

 Version of Chrome (or Chrome Beta) installed on an Android device can

 Note: Although Chrome is expected to move to release 40 towards the

You might also like