Chromium Custom Tabs: Fast Pre-Warming and Shared Cookies

This article explains the underlying mechanisms of Chromium Custom Tabs on Android, focusing on how they allow third-party applications to open web pages rapidly and seamlessly. It covers the architectural design that enables the sharing of cookies between the main browser and the in-app tab, as well as the background Inter-Process Communication (IPC) services that facilitate fast browser pre-warming and resource pre-fetching.

The Core Architecture: Browser Process vs. WebView

To understand how Custom Tabs share cookies and pre-warm pages, it is necessary to distinguish them from the standard Android WebView.

An Android WebView runs inside the third-party application's own process and uses an isolated storage space. Conversely, a Chromium Custom Tab is actually a specialized Activity принадлежащий (belonging) to the user's installed Chromium browser (such as Google Chrome) that is simply rendered on top of the third-party app. Because the Custom Tab is executed by the browser application itself, it inherits all the performance and state advantages of the main browser.

How Shared Cookies Work

Custom Tabs share cookies with the main Chromium browser because they operate within the exact same application context and user profile.

  1. Unified Storage Partition: When a user opens a link in a Custom Tab, the Chromium browser does not create a sandboxed storage environment for the host app. Instead, it accesses its primary SQLite cookie database (the "cookie jar") located in the browser's private app data directory.
  2. Session Continuity: Because the Custom Tab reads from and writes to this central database, any active login sessions, authentication tokens, or site preferences established in the main browser are immediately active in the Custom Tab.
  3. Security Boundary: Although the cookies are used to render the page inside the third-party app's UI flow, the host app cannot access or read the cookies. The rendering and network requests happen strictly inside the Chromium process, maintaining a secure boundary via Android's process isolation.

How Fast Pre-Warming Works

Pre-warming is achieved through Android’s Bound Services mechanism, utilizing the Android Interface Definition Language (AIDL) for background communication between the third-party app and the Chromium browser.

The process relies on the CustomTabsService and follows a strict sequence before the user even taps a link:

1. Binding to the Service

The third-party app uses CustomTabsClient.bindCustomTabsService() to establish a connection with the Chromium browser in the background. Once connected, the app receives a CustomTabsClient instance to send commands to the browser.

2. Warming Up the Browser Engine

The app calls the warmup() method on the client. This triggers the Chromium browser to initialize its main process in the background if it is not already running. Chromium loads its native libraries, initializes the Blink rendering engine, and spins up the network stack. This eliminates the cold-start latency that usually occurs when launching a heavy browser application.

3. Creating a Session

The app calls newSession() to create a CustomTabsSession. This session acts as a unique identifier that pairs the app's pre-warming requests with the eventual intent used to launch the visible Custom Tab. It also ensures that one app cannot interfere with or read the pre-fetched data of another app.

4. Speculative Loading with mayLaunchUrl()

Once the app predicts a user might click a specific link (for example, when a link scrolls into view), it calls mayLaunchUrl() on the active session, passing the target URI. Upon receiving this signal, Chromium executes several optimizations based on the device's current memory and network conditions:

  • DNS Pre-resolution: Chromium resolves the domain name of the target URL to an IP address in advance.
  • TCP/TLS Pre-connection: It establishes the TCP handshake and negotiates the TLS encryption with the target server, saving several round-trips of network latency.
  • Page Pre-fetching: Chromium fetches the main HTML document and discovers critical sub-resources (CSS, JavaScript, and fonts), downloading them directly into the HTTP cache.

When the user finally taps the link, the app fires the CustomTabsIntent. Because the browser engine is already awake, the network connections are open, and the assets are cached in memory, the web page renders almost instantaneously.