Architecture

Using Blink and V8 engines for rendering and JavaScript execution.

General Introduction: https://www.chromium.org/developers/how-tos/getting-around-the-chrome-source-code/

Multi-Process

Reference: https://www.chromium.org/developers/design-documents/multi-process-architecture/

  • Chromium uses multiple processes to protect the overall application from bugs and glitches in the rendering engine or other components.
  • It also restricts access from each rendering engine process to other processes and to the rest of the system. In some ways, this brings to web browsing the benefits that memory protection and access control brought to operating systems.

Browser process

We refer to the main process that runs the UI and manages renderer and other processes as the “browser process“ or “browser.”

Renderer processes

Likewise, the processes that handle web content are called “renderer processes“ or “renderers.” The renderers use the Blink open-source layout engine for interpreting and laying out HTML.

Sandbox

In Chromium, a sandbox is a security feature that limits the privileges of rendering processes and other critical components to enhance browser security and stability. It isolates these components from the operating system and hardware resources to mitigate the risks posed by malicious code.

MOJO

IPC framework

Mojo is an open-source framework developed by Google for enabling high-performance, cross-language communication between processes. It is designed to facilitate communication between different components, such as between the browser and the rendering engine in the context of Chromium (the open-source project behind Google Chrome).

Key features and concepts of Mojo include:

  1. Message-Passing Architecture: Mojo utilizes a message-passing architecture for communication between different processes. This approach allows components to communicate efficiently without sharing memory, providing better isolation and security.
  2. Cross-Language Support: Mojo supports communication between components written in different programming languages, making it suitable for heterogeneous software systems.
  3. Multiprocess Design: Mojo is particularly well-suited for multiprocess architectures, where different parts of an application or system run in separate processes for improved security and stability.
  4. High Performance: One of Mojo’s primary goals is to provide high-performance communication between processes. This is essential for demanding applications, such as web browsers, where efficient communication between browser components is crucial for a smooth user experience.
  5. Used in Chromium: Google Chrome and other Chromium-based browsers extensively use Mojo for communication between various components, including the browser process, renderer processes, and others. This helps in achieving a modular and secure architecture.
  6. IDL (Interface Definition Language): Mojo uses its own IDL (Interface Definition Language) to define interfaces that components expose to communicate with each other. This IDL helps ensure that communication between components is well-defined and platform-independent.

Mojo is not limited to web browsers, and its modular and high-performance design makes it suitable for various applications and platforms. While it’s closely associated with Chromium, it’s a separate open-source project that can be used independently in other software projects.

Extension

Extensions in Chromium are modular components that allow developers to enhance browser functionality. They enable users to customize their browsing experience by adding new features, modifying browser behavior, and interacting with web pages. Here’s an introduction to extensions in Chromium:

  1. Purpose: Extensions extend the capabilities of the Chromium browser, offering users additional functionalities beyond its core features. They cater to diverse needs, ranging from productivity tools to ad blockers and developer utilities.
  2. Development: Extensions are typically developed using web technologies such as HTML, CSS, and JavaScript. This web-based approach allows developers to leverage their existing skills and frameworks to create powerful extensions.
  3. Features: Extensions can perform various tasks, including adding toolbar buttons, modifying web page content, managing bookmarks, intercepting and modifying network requests, providing notifications, and more. This versatility enables developers to address a wide range of user needs.
  4. Distribution: Developers can distribute their extensions through the Chrome Web Store, where users can easily discover, search, and install extensions. The Chrome Web Store serves as a central marketplace for extensions, facilitating their distribution and discovery.
  5. Permissions: Extensions may require certain permissions to access browser features or user data. When installing an extension, users are informed about the permissions it requests, allowing them to make informed decisions about its installation.
  6. Event-Driven Model: Chromium extensions are event-driven, meaning they can listen for and respond to browser events such as page loads, tab switches, and user actions. This event-driven architecture enables extensions to dynamically interact with the browser and web pages.
  7. Developer Tools Extensions: In addition to enhancing user-facing features, developers can create extensions for Chrome Developer Tools (DevTools) to aid in web development and debugging tasks.

Overall, extensions in Chromium provide a flexible and customizable platform for developers to extend browser functionality and tailor the browsing experience to individual user preferences.

Message Host

Managing the communication between the extension and the native application. It sends and receives messages, starts and stops the native application, and handles any errors that occur during communication.

Content Shell

Mainly for development, test and debugging of Blink engine.

Extension

Architecture

Development

Need a manifest file (manifest.json) that defines its metadata and permissions.It specifies important information below:

  • extension’ name, version, description, icons, permissions
  • background scripts, content scripts, etc…

Content Scripts

  • Content scripts are JavaScript files that run in the context of web pages.
  • They can manipulate the DOM, intercept and modify network requests, and communicate with the background scripts.

Background Scripts

  • Background scripts are long-running scripts that operate independently of any particular web page.
  • They handle events like browser startup, extension installation, and manage global states or perform tasks in the background.

Build System

Ninja

How does the build system work?

The build system in Chromium works with Ninja as its primary build tool. Here’s an overview of how the build system operates with Ninja in the Chromium project:

  1. GN Build Files: Chromium uses GN (Generate Ninja) as its meta-build system. Developers define build configurations and dependencies in GN build files (BUILD.gn). These files specify targets, compiler flags, linker settings, dependencies, and other build-related information.
  2. Generate Ninja Build Files: GN generates Ninja build files (build.ninja) based on the GN build files. Ninja is a fast, scalable build system designed to handle large projects efficiently. The generated Ninja build files contain rules and commands for building each target in the project.
  3. Build Process: When building Chromium, developers invoke Ninja to execute the build. Ninja reads the build.ninja file and executes the build commands in the correct order based on dependencies and build rules specified in the file.
  4. Parallel Building: Ninja supports parallel execution of build tasks, which improves build performance by utilizing multiple CPU cores effectively. This allows Chromium to build quickly, even on machines with a large number of CPU cores.
  5. Incremental Builds: Ninja tracks dependencies between build targets and only rebuilds targets that have changed or have dependencies that have changed since the last build. This incremental build process speeds up development workflows by avoiding unnecessary rebuilds.
  6. Output and Logging: Ninja provides concise output during the build process, displaying the progress of each build task and any errors or warnings encountered. It also generates detailed build logs, which developers can review to troubleshoot build issues.
  7. Cross-Platform Support: Ninja is cross-platform and works on various operating systems, including Linux, macOS, and Windows. This allows developers to use the same build system across different platforms, ensuring consistent build behavior.

Overall, the combination of GN and Ninja in the Chromium project provides a robust and efficient build system capable of handling the complexities of building a large-scale software project like a web browser.

GN

Reference: https://gn.googlesource.com/gn/+/main/docs/quick_start.md

  • BUILD.gn: project’s build configuration files. It would be multi files across projects.

  • args.gn: the global configuration

  • .gni files:

  • Included in GN build files (BUILD.gn) using the import directive.

  • Used to modularize and organize build configurations across multiple GN build files (BUILD.gn)

Extension Overview: Code Perspective

As chromium official README document described, extension system related technical documentation listed below:

Key Components

Browser {#browser}

The browser module is responsible for managing the browser’s main functionality on the desktop platform, it’s mainly used for:

  • Tab Management: The Browser class manages the tabs within a browser window. It uses the TabStripModel class to add, remove, and switch between tabs.
  • Window Management: The Browser class is responsible for creating and managing the browser window. It interacts with the BrowserWindow class, which represents the physical window on the user’s screen.
  • Command Execution: The Browser class handles the execution of user commands. It uses the BrowserCommandController class to handle commands from the user, such as opening a new tab or navigating to a URL.
  • Session Management: The Browser class also manages the browser session. It keeps track of the session ID and handles session restore functionality.
  • Location Bar Management: The Browser class manages the location bar (where you type URLs) through the LocationBarModel class. It provides the current state of the location bar, such as the current URL and whether the page is loading.


For tab management , it use classes below:

  • tab_strip_model
  • tab_group

Tab

Android Platform

Mainly related to tab**_**android class.

  • URL and Title Access: The TabAndroid class provides methods to access the URL and title of the tab. This is done through methods like GetURL() and GetTitle().
  • User Interaction: The TabAndroid class provides methods to check if the tab is interactable by the user. This is done through the IsUserInteractable() method.
  • Synced Tab Delegate Access: The TabAndroid class provides methods to access the synced tab delegate, which is used for syncing tab information across devices. This is done through the GetSyncedTabDelegate() method.
  • Incognito Mode Check: The TabAndroid class provides methods to check if the tab is in incognito mode. This is done through the IsIncognito() method.
  • Last Shown Timestamp Access: The TabAndroid class provides methods to access the last shown timestamp of the tab. This is done through the GetLastShownTimestamp() method.

Other Platform

Using browser class to manage tabs.

Profile

Profile: This is the main class for user profiles. It represents a user profile and provides methods to access various aspects of the profile, such as the profile’s preferences, browsing history, and extensions.

ProfileManager: This class manages all the profiles in a browser session. It provides methods to create, delete, and switch between profiles. It also handles events related to profiles, such as a profile being created or deleted.

ProfileIOData: This class contains the I/O-related data for a profile. This includes things like the profile’s cookie store and network request context.

ProfileObserver: This is an interface for classes that want to observe events related to profiles. Classes that implement this interface can register with the ProfileManager to receive notifications when profiles are created, deleted, etc.

TestingProfile: This is a subclass of Profile used for testing. It provides a way to create a profile with mock data for use in tests.

IncognitoProfile: This is a subclass of Profile that represents an incognito (private browsing) profile. It overrides certain methods of the Profile class to provide the special behavior of incognito profiles, such as not saving browsing history.

API

API Files

  • chrome/common/extensions/api/api_sources.gni
  • extensions/common/api/schema.gni

API Source Code

chrome/browser/extensions/api:
Multiple APIs are enumerated here. Determining which ones need to be preserved and rewritten on the Android platform. The following interfaces may require special attention：

  • citrix_xxx
  • content_xxx
  • declarative_xxx
  • processes
  • profile_management
  • omnibox
  • tabs
  • web_xxx

Build Status Update

GN

To make gn gen successfully and exclude or add some targets, I have modified some gn files. To clarify this change in detail, it would be listed by directory.

  • apps

  • chrome/browser

  • BUILD.gn

  • apps

  • app_service

  • link_capturing

  • platform_apps

  • controlled_frame

  • extensions

  • ui

  • web_applications

  • app_service

  • extensions

  • media/router/discovery

  • resources

  • ui/web_applications

  • ui/web_applications/diagnostics

  • web_applications

  • chrome/common

  • chrome/common/apps/platform_apps

  • chrome/test

  • chrome/test

  • components

  • guest_view/browser

  • guest_view/renderer

  • keep_alive_registry

  • web_modal

  • extensions

  • BUILD.gn

  • buildflags/buildflags.gni

  • browser

  • browser/api

  • common

  • services/device/public/cpp/hid

  • ui

  • ui/webui/resources

  • cr_components

  • app_management

  • customize_color_scheme_mode

  • customize_themes

  • help_bubbles

  • most_visited

  • theme_color_picker

  • js

  • include_polymer.gni

  • webui/resources/cr_components/managed_footnote

Note:
Modules written in black color, it’s to allow build for android and make gn build successfully:

Modules written in orange color, it’s to exclude targets:

Targets

Excluded Targets
chrome/browser component folder:

  • ui/views
  • web_applications
  • platform_apps

chrome/browser/extensions component folder:

  • api

  • tabs

  • tab_capture

  • tab_groups

  • api/passwords_private

  • chrome_app_xxxx.h/cc

  • extensions_error_xxxx.h/cc

  • extensions_icon_manager.h/cc

  • extensions_install_xxxx.h/cc

  • extensions_menu_xxxx.h/cc

  • external_xxxx.h/cc (external_component_loadar, external_install_error, external_loader…)

  • waring_badge_xxxx.h/cc

  • webstore_xxxx.h/cc

  • window_controller_xxxx.h/cc

  • preinstalled_apps.h/cc

extensions component folder:

  • app_window

  • extension_frame_xxx.h/cc ???

  • common_manifest_handlers.cc/h ???

  • install_xxx.h/c

  • command.cc/h

  • api

  • hid

  • usb

  • webstore_private

  • commands

Targets Needed

API

Two files define the interface details provided by extensions:

  • chrome/common/extensions/api/api_sources.gni
  • extensions/common/api/schema.gni

Build


To build an APK for the Android platform in the CEB project, the steps mentioned above should be followed. Currently, the build process is stuck in the linking phase.

How to Debug

Refer to this Debug Guide: https://docs.google.com/document/d/1jz0qmEv5GDA_wljmUNNBcXPdqwixTV4baalMUU9g7vw/edit#heading=h.rqrix0ihob95

Scheme

To make extensions working on the Android platform, Tab and Profile management should be implemented well.

Tab

For desktop platform, tab management is implemented using browser , tab**_strip_**model and profile classes in chrome/browser/extensions/extension_tab_util.cc

However, on the Android platform, tab management is lacking. Only the following methods are covered in tab_android.cc.


We need to add more implementations (using JNI to call Java methods) for tab management, including:

Profile

profile**_**manager.h/cc cover all implementation for all platforms, but for some specified operations on the android platform, there is one file called profile_manager_android.h/cc(using JNI to call java implementation) to do this, including:

API

Sort out APIs used in ceb-ts-extension module, determining which ones need to be preserved and rewritten.

Reference

https://lldb.llvm.org/use/tutorial.html