android_webview Integration of /content into android.
base Common code shared between all sub-projects.
build Build Configurations shared by all projects
cc chrome Compositor implementations
components components for Content Module layer
content Core code for multi-process sandboxed browser
net Network libraries for Chromium
sandbox Sandbox for preventing hacked renderer from modified system.
skia skia Graphics library, some classes in ui/gfx wrap skia
third_party External libaries such as blink, decoders, compression, ...
ui ● /gfx: Shared graphics lib, base of Chromium UI grp.
● /views: frameworks for UI; rendering, layout, event
○ ALSO CHECK! chrome/browser/ui/view
webkit WebKit glues & some web features
Historical changes of
Chromium Dependency Diagram
Dependency diagram: V2
Dependency diagram: V3
/chrome OR /android_webview OR ...
Dependency diagram: V3
/chrome OR /android_webview OR ...
Network libraries for
Common code to be
shared between all
Shared codes between
All the web platform
features, HW acc. except
● Facades over src/content to integrate into
■ Java Resource on Android
■ JNI on Chromium for Android
● WARNING! Use jar_file_jni_generator.gypi for generating
JNI of system classes instead of
■ Organization of code for Android WebView
● Common code shared betweeen sub-projects
○ e.g. String manipulations, file, …
○ Adding things under /base, only if that code must be
shared between more than 1 other top-level project.
● Build-related configuration shared by all
● Wrapper of gyp for chromium build
● Everything starts at here!!!
○ JNI generator for user-defined class
○ JNI generator for system class
● Chrome compositor implementations
■ GPU Accelerated Compositing in Chrome
■ Compositing in Blink/Webcore [slide]
■ Compositor Thread Architecture
NOTE: Implementations in ‘cc’ don’t have whole part in above references.
● Features for reusing across # of targets
○ for browser features, NOT the web!
■ e.g. Bookmarks, autofill, autocomplete, search
engine, history, …
○ By default, depend only on the lower layers of the
Chromium codebase( /base, /net, etc)
■ Individually, allow additional dependencies on the
content API and IPC
○ Directory & Subdirectories
■ Directory could have
● DEPS : Dependencies such as rules, include_dir, ...
● Components need to live in different processes should
separate the code into different subdirectories.
components/foo DEPS, OWNERS, foo.gypi
components/foo/browser Code that needs the browser process
components/foo/renderer IPC constants, ...
components/foo/common Code that needs renderer process
○ Directory & Subdirectories (cont’d)
■ Subdirectory should have DEPS file
● with the relevant restrictions in place
○ i.e. only components/*/browser should be allowed to
#include from content/public/browser.
○ Naming conventions
■ namespace = the name of the component.
● e.g. //components/foo
○ code should be in the foo:: namespace
■ 'android' subdirectory with a Java source
● SHOULD BE: code structure = package name
○ Structure of layered components
○ Life of a browser component
● Core code for multi-process sandboxed
○ The core code needed to render a page using a
multi-process sandboxed browser.
○ Includes all the web platform features and GPU
acceleration except Chrome features.
● The goal
○ Being able to build a browser by starting with
content, and then pick and choose Chrome features.
● Historical motivation
○ Consensus was reached to move the core
Chrome code into srccontent.
■ Hard to figure out what the "best" way, because
the APIs and features were together in the same
■ To add a clear separation between the core
pieces of the code that render a page using a
■ Not chrome features!!
● IPC(Inter-Process Communication) module
for communcation between chromium
○ Multi-process architecture
● New project for isolating components of
chromium multi-process architecture that are
concerned with ‘Process management’,
○ 3Q 2013, started & in progress
○ Similar with ‘IDL’ based generating & binding
● Currently, out of our focus :)
● The neworking library developed for
○ can be used seperately from Chromium.
■ see also: chrome/common/net
○ Mostly single-threaded cross-platform library
primarily for resource fetching
● Code layout
base net utilities. e.g. host resolution, cookies, network change detection, SSL.
disk_cache Cache for web resources.
websockets WebSockets implementation.
url_request URLRequest, URLRequestContext, URLRequestJob implementations.
spdy SPDY implementation.
socket_stream socket streams for WebSockets
socket Cross-platform implementations of TCP sockets, "SSL sockets", and socket pools.
proxy Proxy (SOCKS and HTTP) configuration, resolution, script fetching, etc.
● To prevent a hacked renderer from
○ C++ library for the creation of sandboxed processes
■ processes that execute within a very restrictive
■ The only resources sandboxed processes can
freely use are CPU cycles and memory.
● e.g. Chromium renderers are sandboxed processes.
● Google’s skia graphics library
○ /skia has configurations only.
■ Skia implemetation is located in
○ See also: some wrappers in /ui/gfx
● All third-party libraries that Chrome used.
■ webkit fork, known as ‘blink’
● Not only C/C++, Java libraries
○ You can find js project or python tools in this
● Contains discrete components used to build
Chromium’s user interfaces
○ each subdir has to have isolated component.
● Shared graphics classes.
● These form the base of Chromium’s UI Graphics
● A simple framework for doing UI development, providing
rendering, layout and event handling.
○ Most of the browser UI is implemented in this.
○ Contains the base objects.
● See also:
○ except Chrome for iOS
■ The iOS security model does not allow an app to
execute native code from writeable memory.
■ Memory is either writeable or executable (but
■ However, V8 is a pure compiler, and doesn't
have an interpreter.
○ Project Home:
● All of Chromium's Webkit related stuff
○ But, currently there’re quite many actions are that
moving to out of ‘/webkit’
■ e.g. /content, /chrome, …
○ Will be deprecated? Maybe?!