Divergence and contributions

Upstream

Cefrium is a port, not a fork. This page states exactly how far it diverges from upstream Chromium and CEF, where every one of those changes lives, and which of them have been sent upstream. If you are evaluating whether this port will survive the next Chromium release, this is the page to read.

Counts for Cefrium SDK 0.12.0. The full CEF patch set that Cefrium inherits is 149 entries; the 36 above are the ones Cefrium adds for Android, and they are the whole of its divergence from the Chromium tree.

Why a port carries patches at all

Chromium on Android is built to be Chrome. It assumes an Activity, a Tab, a browser UI and a Chrome-shaped embedder. CEF on Android has none of those. Most of the 36 patches are therefore not features: they are guards at the points where Chromium reaches for something an embedder does not provide, so the engine degrades instead of aborting the process.

Concretely, the areas touched are chrome (12 files), components (12), base (7), content (6), build (2), services (2), ui (2), gin (1). Every patch is in the repository, one file per change, with a comment saying what it guards and why:

cef/patch/patches/android/ — and the methodology, including how they are regenerated against a new Chromium, in PATCHING-CEFRIUM.md.

Submitted upstream

Changes sent to the upstream projects themselves, where they are publicly reviewable. Only submissions with a public link appear here; this table is a record, not a plan.

Adopted independently by Chromium

One patch Cefrium carried stopped being needed because upstream made the same fix on its own, which is worth recording for what it says about the class of change involved:

• glic_android_jni_headers_dep — a missing //chrome/browser/glic/android:jni_headers build dependency. Chromium 154 added both of the deps this patch supplied, so the patch no longer applied and was removed from the tree. Cefrium found it independently and was carrying it from an earlier milestone.

What stays downstream, and why

Not every patch belongs upstream, and claiming otherwise would waste a reviewer's time:

• Embedder guards that only make sense with CEF. Changes conditioned on ENABLE_CEF, or on CEF's process model, have no meaning in a vanilla Chromium build.
• Android-port plumbing. Build-graph and resource changes that exist because libcef.so is built for aarch64-linux-android.
• The SDK itself. The Java and Compose APIs are not CEF's concern; CEF has no opinion on Android UI frameworks. They live in cefrium_sdk/ and cefrium_compose/.

The port's own code follows CEF's architecture precisely so that the parts which can go upstream are submittable without rewriting them first. That policy is stated in full on the policy page.

Verifying any of this yourself

Nothing here needs to be taken on trust:

• The patches are text files in a public repository, at the path above.
• Each release ships an SBOM declaring the exact engine it embeds, and a NOTICE listing every bundled third-party licence, attached to its release.
• From 0.9.5 the published Maven POM carries cefrium.chromium.version, so a build system can assert which engine it resolved without downloading the artifact.