This is a genuinely hard technical question about building a Chromium-based mobile browser with Chrome extension support. I want to think through what's actually feasible here, drawing on what I know about how Chromium on Android handles (or rather doesn't handle) the extension APIs that desktop Chrome supports. I recall Kiwi Browser as the key precedent — an open-source fork that specifically added extension support back into Chromium for Android by re-enabling the build flag and stubbing out the missing UI and tab-model integration pieces. Its development was paused, and the maintainer eventually released the source before the project was effectively discontinued. Other examples come to mind too: Microsoft Edge Canary on Android now supports select extensions, Yandex Browser has some extension support, and several smaller forks (Lemur, Quetta, Mises) build on Kiwi's work. I'm also noting the contrast with Samsung Internet's separate ad-blocker API, Firefox's Gecko-based WebExtensions, and Orion on iOS which shims Chrome/Firefox extensions onto WebKit — while iOS itself blocks Chromium-engine browsers entirely outside the EU's DMA exception. Given that, I'm focusing on Android as the realistic target, and thinking through what it'd take technically: enabling extensions in the GN build would break many things since much of the extensions code assumes desktop-only constructs like the `Browser` class, `BrowserWindow`, and `TabStripModel`, none of which exist in the same form on Android's tab management system. I recall Chromium has actually been doing real work here — there's a "desktop Android" effort with a buildflag around bringing extensions to desktop Android, which would require reimplementing things like tab-related extension APIs against Android's `TabModel` instead. I'm trying to recall the exact buildflag names, something like `enable_extensions_core` being the OR of `enable_extensions` and `enable_desktop_android_extensions`. I'm fairly confident these flags exist given the "Extensions on Desktop Android" effort, but I should hedge since I'm working from memory rather than certainty. Now I'm thinking through how extension installation actually works in this context — the Chrome Web Store flow relies on `chrome.webstorePrivate.beginInstallWithManifest3`, which requires the browser to whitelist the webstore site, versus the alternative of pulling the CRX directly from Google's update server URL and installing it manually. I also need to account for CRX3 verification through the sandboxed unpacker, which relies on a utility process to unzip and parse the manifest, plus the broader extension process model where background pages or MV3 service workers run in dedicated renderer processes, which butts up against Android's tighter process limits and OOM kill behavior. Content scripts injection lives in the renderer layer and stays largely cross-platform. For ad blocking specifically, uBlock Origin's classic version relies on MV2's blocking webRequest, which Chrome is phasing out — so supporting it means keeping MV2 alive via policy overrides or feature flags rather than enforcing the deprecation in a fork. For MV3-compatible alternatives, declarativeNetRequest (used by uBO Lite and AdGuard MV3) runs its ruleset matcher in the browser process, which should work fine on Android. For user script managers like Tampermonkey and Violentmonkey, MV3's userScripts API requires a developer mode toggle that the fork could simply expose by default. On the UI side, chrome://extensions is a WebUI page built with Polymer/Lit plus the developerPrivate API — Kiwi already ported this. Extension popups are trickier: on desktop they're views widgets hosting a WebContents, so on Android you'd need to render that popup content in a Java-side bottom sheet or dialog using something like ThinWebView, similar to how Kiwi handled it. Options pages could just open as a regular tab, and the extension install permissions prompt would need a native Android dialog wired up via JNI, since desktop uses a views dialog for that. There's also the whole chrome-extension:// scheme registration to handle — browser client classes, extensions client/renderer client hookups, and a custom URL loader factory to route those requests properly. Each tab needs its own extension web contents observer attached, so I need to make sure TabHelpers::AttachTabHelpers wires up the extension tab helper, observer, and action runner on Android too. Site isolation is trickier since Android only does partial site-per-process, but extension code assumes isolated processes for chrome-extension:// origins — that assumption might break things. Native messaging isn't applicable on Android at all, so that API needs to just be stubbed out. Many other APIs like identity, gcm, enterprise policies, fileSystem, printing, desktopCapture, tabCapture, sidePanel, and tts probably need to be excluded or stubbed via the feature JSON's platform filtering, since `_api_features.json` already supports restricting APIs by platform. I'd need to check whether the `Feature::Platform` enum has been extended to include Android given the recent desktop Android push, or whether that's still missing. Realistically, since WebView can't be used for this and extensions rely heavily on the `//chrome/browser/extensions` layer for Profile-dependent APIs like tabs, windows, bookmarks, and history, the most feasible path forward is forking `chrome_public_apk` rather than trying to build extensions on a lighter embedder atop `//content`. Build requirements are steep too—Chromium's ~100GB source, hours-long Linux builds needing 64GB RAM, and constant rebasing against upstream's 4-week release cycle plus weekly security patches. This exact maintenance burden is what caused Kiwi to fall behind. Compatibility is another hurdle since many extensions assume desktop UI patterns like multiple windows, keyboard shortcuts, or side panels, which Kiwi worked around by mapping `chrome.windows` to a single window and translating `chrome.tabs.create` into its own tab model. On testing, extension APIs rely on desktop-only browser tests, so Android would need instrumentation tests instead. For distribution, Google Play does allow browsers that load extensions—Kiwi shipped this way—since the policy against downloading executable code explicitly exempts JavaScript running inside a browser or WebView interpreter. I'm also weighing legal risks: accessing the Chrome Web Store from a non-Chrome browser might get blocked via UA detection, using the "Chrome" trademark is off-limits, and Google restricted sync API access for third-party forks back in 2021. As a cheaper alternative, I could skip real extension support entirely and instead build native ad blocking using Chromium's existing subresource filter component or URL loader interception, similar to how Brave approaches it. Another option is native userscript injection at document start through render frame hooks, though supporting Tampermonkey's GM_* APIs would need a compatibility shim. I'm also considering forking Kiwi Browser's source directly since that groundwork already exists, even if it's outdated on an older Chromium version. I'm noting Kiwi's `src.next` GitHub repo, which maintains extension support as a set of patches applied on top of upstream Chromium with automated builds — a solid reference point. There's also Google's own upstream effort, `enable_desktop_android_extensions`, which has been landing extension infrastructure for desktop Android in recent Chromium versions, so tracking that progress could be worthwhile too. I also recall there might be an `is_desktop_android` GN flag in the Android build config, tied to the broader "Desktop Android" effort giving Chrome for Android a more desktop-like UI, with `enable_desktop_android_extensions` possibly defaulting from it—I'll mention this as a recent, somewhat experimental upstream addition, with appropriate hedging. On the legal side, Chromium's BSD license requires stripping Google branding and API keys, and you can't call the browser "Chrome." Regarding the Chrome Web Store, its terms are meant for Chrome specifically, but Google has generally tolerated other browsers accessing it (Edge, Brave, Vivaldi, Opera on desktop, and Kiwi did this on Android too) — this isn't strictly illegal but is a fragile arrangement since CWS gates the "add to Chrome" button by user agent, meaning browsers like Kiwi had to spoof a desktop Chrome UA to get store access. I should also flag that CWS is phasing out MV2 extensions, and there's been drama around uBlock Origin's listing status there. Now I need to organize my answer in Chinese covering the concrete development steps and key implementation points the user asked about, starting with a reality-check section about the practical constraints before diving into the technical roadmap. Android is the only viable target since iOS can't ship Chromium outside the EU. Chrome for Android upstream compiles out the extension system entirely, though the platform-independent `//extensions` layer exists — the real gap is desktop-coupled UI code in `//chrome/browser/extensions` and the tab model. I'm thinking through useful precedents like Kiwi Browser (whose patches on GitHub are a solid reference), Edge Canary for Android, Yandex, and Kiwi derivatives like Lemur and Mises, alongside the ongoing upstream "Desktop Android extensions" effort. Realistically this needs a team of 3-5 senior Chromium engineers, 6-12 months to reach a usable beta, with rebase maintenance being the actual long-term burden that burned out Kiwi's solo developer. There's also the MV2 vs MV3 complication for something like uBlock Origin. For the actual build steps I'm outlining the environment setup: Ubuntu 22.04, at least 32GB RAM (64 preferred), around 200GB of SSD space, depot_tools, fetching the Android target via gclient, and building the chrome_public_apk target. I'm figuring out which specific build targets make sense — chrome_public_apk as the simplest starting point versus bundles like monochrome_public_bundle or trichrome_chrome_bundle. I'm also thinking through branch strategy: working off a stable release branch rather than main, and choosing between a patch-series workflow (like Kiwi or Bromite/Cromite use, applying git am patches) versus maintaining a full fork, leaning toward recommending the patch queue approach for long-term maintainability. Now I'm working through branding changes — swapping out theme files, package names, and Google API keys, and deciding whether to disable sync/sign-in or replace it with a custom implementation. Then I'm mapping out the GN build args needed to enable extensions support on Android and anticipating where the build will likely break, particularly around dependencies on browser UI classes like BrowserList and tab strip models that don't exist in the mobile codebase. I'm mapping out the approach of gating desktop-only extension code behind build conditionals while implementing Android-specific paths for essentials, looking at key classes like ChromeExtensionsBrowserClient, ExtensionSystemImpl, and ExtensionService and how much of their desktop dependencies would need reworking. Now I'm thinking through how ExtensionTabUtil should be reimplemented using Android's TabModelList/TabModel/TabAndroid instead of desktop tab abstractions, and how chrome.windows could map each TabModel (normal/incognito) to a window concept via an Android WindowController implementation, plus how tab helper attachment would need to adapt. I'm also mapping out how ChromeContentBrowserClientExtensionsPart handles extension scheme registration, process model decisions, SiteInstance isolation, and the URL loader factories for webRequest, since those hooks would need Android equivalents too. I'm also tracing the API feature files that gate platform availability, the preferences registration path, and how the process manager's background page logic depends on `BrowserList` — something Android would need to replace with an app-foreground signal instead. The rest of the extensions machinery — event routing, registrar, registry, prefs, storage backed by leveldb — looks generic enough to work unchanged, with storage.sync gracefully falling back to local when sync is disabled. I'm also checking that the sandboxed unpacker's dependency on the unzip/data_decoder utility services is already built for Android. The CRX installer, update client, and extension downloader also seem largely platform-agnostic since component updater already relies on them on Android. Now I need to work through the actual install/update flow: handling CRX sideloading on Android via an intent for .crx/.zip files through a file picker into the installer. For the Web Store, one approach is letting the user browse the site with a desktop UA override since it rejects mobile browsers, then wiring up the webstorePrivate API so the store's hosted app (identified by its extension ID) can actually trigger installs. A simpler alternative is intercepting Chrome Web Store detail-page URLs directly, showing a custom install button, and downloading the CRX from Google's update2 endpoint myself — essentially building a curated store UI like Kiwi or Edge do, though this risks running afoul of CWS's terms of service or rate limits if done at scale. For the actual update mechanism, ExtensionUpdater polling the update_url already works fine with the default CWS endpoint. The install prompt itself needs ExtensionInstallPrompt wired to an Android dialog through JNI, plus ChromePermissionMessageProvider for generating the permission strings shown to the user. I should also look at ExtensionManagement policy for blocking specific extensions, and check how MV2 support is gated through the ManifestV2ExperimentManager and related feature flags. Now moving to step 4, the extension UI on the Android/Java side: I need to figure out how to handle the chrome://extensions WebUI and its developerPrivate API, since some of that relies on desktop-only concepts like DevTools inspection windows and install-repair prompts that I'll likely need to stub out. I also need to register this WebUI in the Android WebUI controller factory and figure out the mobile layout approach for the extensions page. For toolbar integration, I'm considering how to expose extension action icons and badge text to Java's AppMenu via JNI, looking at how Kiwi and Edge browsers handled placing extensions in their menus. For popups, I need to implement ExtensionViewHost popup hosting so the chrome.action popup mechanism works properly. For displaying the popup's WebContents, I'm thinking through hosting it in Java via ContentView/ThinWebView within a dialog or bottom sheet, sizing it using the popup's auto-resize behavior but constraining width to screen width on mobile while letting height grow. I also need to handle window.close() calls and links that try to open new tabs. For the options page, I need to handle both the internal extensions options URL and direct chrome-extension:// options.html links, opening them in a tab, and rewrite the existing Browser-based options page opening logic to work with TabModel instead. Then I'm moving on to context menus. Context menus would need a lower-priority Android adaptation, injecting extension menu items into the existing Chrome context menu populator via JNI. I'm also noting install/permission dialogs, MV3 host permission runtime prompts, blocked action UI, incognito toggling per extension, and that DevTools won't work on-device for extension pages (though remote debugging from desktop still works). Then I'm moving to the next step: adapting key extension APIs for Android, starting with tabs/windows as the main effort, followed by webRequest and its blocking variant for MV2. For webRequest, the network-service-based proxying URL loader factory should work generically, but blocking requests round-tripping through the extension renderer per request could be costly on phone CPU/memory — though experience with uBlock Origin on Kiwi suggests it's acceptable, so I'd need the event router infrastructure. declarativeNetRequest should also work generically with its flatbuffer-indexed rulesets and static limits. For scripting/content scripts/userScripts, the renderer side is generic, though userScripts now requires enabling a per-extension "Allow user scripts" developer toggle since Chrome 138. I'm going through the remaining APIs one by one: storage, runtime, alarms, i18n should be straightforward; notifications could map to Android's NotificationDisplayService; cookies and webNavigation are generic with Profile; history/bookmarks have Android equivalents (HistoryService, BookmarkModel) but with some model differences; downloads is trickier since Android's DownloadManagerService differs from desktop's download core, so the API may only partially work; commands (keyboard shortcuts) are meaningless on phone and should be stubbed; and omnibox integration is complicated since Android's omnibox is implemented in Java. I'm also weighing topSites, sessions, management, permissions, idle, power, and privacy as likely feasible, while proxy config could plausibly work through Android's ProxyConfigServiceAndroid and PrefProxyConfigTracker. Identity needs a Google account so I'd drop that, fontSettings and sidePanel should probably be dropped or mapped elsewhere, desktopCapture/tabCapture don't fit mobile, and tabGroups exists on Android but adds complexity so I'd defer it. TTS looks promising though, since Android already has TtsPlatformImplAndroid, so chrome.tts might actually be implementable. Printing, webAuthenticationProxy, and nativeMessaging seem like clear drops for now. On the process side, I need to think about how extension background pages fit into Android's renderer process budget, how low-memory-kill behavior interacts with ProcessManager restarting lazy backgrounds, and why MV3 is preferable to MV2's persistent backgrounds here — tying extension process lifecycle to app foreground/background state via ApplicationStatus, PowerMonitor, and memory pressure signals. I'm also starting to consider how site isolation applies to extension origins. Extension URLs should always get dedicated processes on Android, which the existing ChromeContentBrowserClientExtensionsPart logic already handles, and some extension sites like the Chrome Web Store need a desktop user-agent override on a per-site basis. Then I'm moving into testing considerations — running extensions_unittests and unit_tests for Android, chrome_public_test_apk instrumentation tests, and building a manual test matrix against real-world extensions like uBlock Origin and uBO Lite. For MV3-related testing I'd need Tampermonkey with userScripts support, plus Violentmonkey, Dark Reader, Stylus, and Bypass Paywalls, while Vimium's keyboard-focused features don't really apply here. On performance, cold start matters since InstalledLoader loads manifests synchronously on the UI thread, adding roughly 100ms per extension on a phone in the worst case, and each extension's service worker or background page could add 30-60MB of memory, with webRequest listeners potentially waking the renderer and hurting battery life. Security-wise, extensions carry broad permissions so sideloading poses malware risk, meaning I'd want to require user confirmation and verify CRX signatures. I should also verify CWS signatures for publisher proof, and since Safe Browsing's extension blocklist requires a Google API key I don't have access to, I'd need to build a custom blocklist instead, while keeping chrome-extension:// process isolation intact and avoiding any --disable-web-security shortcuts — this should be fine under Play Store policy since it's just JS. Legally, Chromium is BSD-licensed so I need to strip Chrome/Google branding and API keys, and while Google's tolerance toward CWS usage by other browsers like Edge, Brave, and Kiwi is a good sign, it's not guaranteed, though Play policy around downloading code should be fine for JavaScript. For long-term maintenance, I'm thinking rebasing every 4 weeks for stable releases and weekly for security patches, with automation to help manage that cadence. Now I want to think through how to automate the patch series and CI setup similar to what Kiwi and Cromite do, assign ownership for resolving rebase conflicts, and keep an eye on how upstream is actively refactoring the extensions system for desktop Android, which could help or hurt depending on timing. I also want to put together a concise summary table of key implementation points organized by build layer, browser process, renderer process, Java UI, install/update flow, API adaptation, and operations. And I should consider a lighter-weight alternative if full extension support proves too heavy — something like built-in ad blocking using subresource_filter with a custom ruleset, or integrating Brave's adblock-rust library via FFI, or possibly AdGuard's approach. For that middle path, restricting support to MV3 with a limited API surface (declarativeNetRequest plus a content script subset) seems more mobile-friendly, and would still cover ad blocking use cases like uBO Lite and AdGuard MV3. For userscripts, I'm weighing a native GM_* shim approach — similar to what Via Browser, X Browser, and Lemur do by injecting scripts at document_start and providing GM_xmlhttpRequest through a JS bridge — versus just relying on Tampermonkey/Violentmonkey once full extension support exists, which would make a separate shim unnecessary. I should also detail the Chrome Web Store install flow, including how the CRX download URL is structured with parameters like prodversion and the extension ID, and reference how Kiwi Browser specifically implemented CWS extension support on Android by enabling the extensions flag and patching a significant portion of Chromium's codebase. Kiwi's source lived across two repos — the original full dump and the patch-based src.next, which used GitHub Actions to compile Chromium on free runners. I recall the author announced Kiwi's end-of-life in early 2025, citing that Edge Canary now supports extensions and that he'd collaborated with Microsoft on it — so I'll note Kiwi is discontinued but its patch set remains the most complete public reference, while Edge for Android added Canary extension support in 2024 with a curated allowlist including uBlock Origin. I'm noting the desktop Android extensions groundwork also touches build target splits (core vs non-core) and relevant APK build targets — this seems like the more promising baseline to build on rather than enabling extensions from scratch. Realistically, I'd want to flag that exact file paths may have shifted upstream, so I'd phrase these as "likely current, subject to minor drift." For staffing and timeline, this needs a small team — a few engineers, ideally with real Chromium internals experience in content/browser and JNI/GN — probably three to six months to reach an internal alpha with something like uBlock Origin and Tampermonkey functioning. Beyond that, six to twelve months to public beta, plus one or two permanent engineers just for rebase maintenance going forward. I'm also considering the userscript-runner angle: Tampermonkey's MV3 version needs Chrome's userScripts API (with developer/allow-user-scripts toggle), while Violentmonkey is still largely MV2. So a fork wanting to support these tools well would want to enable userScripts, scripting, declarativeNetRequest, and non-blocking webRequest observation to cover both old and new extension architectures. On top of that, Chrome's been actively deprecating MV2 in stable, gated behind an enterprise policy that expires and internal flags that will eventually force code removal upstream — so maintaining MV2 compatibility in a fork means fighting against Google's own deletion of that code path, which is a real long-term risk. A more practical framing: lean into MV3 (uBO Lite, AdGuard MV3, Tampermonkey MV3) rather than fighting to preserve MV2 uBO. One nice advantage of running your own fork is that `declarativeNetRequest`'s rule caps (static/global/dynamic limits) are just constants in Chromium's source, so you could raise them to make uBO Lite behave closer to full uBO. Similarly, `webRequestBlocking` in MV3 is restricted to policy-installed extensions via a permission feature flag — a fork could lift that restriction, though it's worth weighing compatibility and performance tradeoffs before doing so. On Android specifically, `ExtensionSystem` is registered as a per-profile keyed service through `ExtensionSystemFactory`, wired up in `ChromeBrowserMainExtraPartsProfiles` alongside the other extension-related browser context keyed service factories that need to exist for extensions to function at startup. I'm also thinking through `ChromeExtensionsAPIClient` and how it hooks into desktop-specific features like GuestView delegates for the `` tag, which Android likely doesn't compile since guest view support isn't needed there. I'm also thinking about how ExtensionFunction implementations reference Browser objects, like GetCurrentBrowser, which would need TabModel-based replacements. Similarly, browser_finder.h helpers used across API implementations would need to map onto TabModelList equivalents, though I'm not certain the exact API surface matches one-to-one. Tab identification could route through TabAndroid::FromWebContents and GetAndroidId, while extension-facing tab IDs still come from SessionTabHelper::IdForTab since that's attached on all platforms including Android. I also need ChromeExtensionWebContentsObserver created for extension hosts when ExtensionHost objects are built. I'm also tracing whether the extension scheme is properly registered so chrome-extension:// URLs work from the Android omnibox — checking IsHandledURL, scheme allowlisting via url::AddStandardScheme, and whether Android's Java-side URL handling (IntentHandler, UrlConstants) might block unrecognized schemes before they reach the browser. Beyond that, I need to verify that non-network URL loader factories get registered under the ENABLE_EXTENSIONS flag, and that WebRequestAPI proxying still works generically through WillCreateURLLoaderFactory. There's likely also Java-side flag plumbing needed to fully enable this path on Android. On the Android UI side, I'm mapping out what's needed: a JNI bridge exposing extension management (list, enable/disable, uninstall, actions, popups, options) plus a new ExtensionView implementation for Android to replace the views-based popup hosting, since ExtensionViewHost currently depends on a views-specific ExtensionView. For this Android popup view, I need to wrap WebContents' native Android view, attach it to a Java ContentView inside a Dialog or BottomSheet, and handle auto-resize behavior along with keyboard event stubs. I also need an Android-specific ExtensionInstallUI factory implementation to surface install confirmations as a toast or snackbar, and I should account for how extension error reporting and global error UI would need to be adapted for this platform. On external providers, I'd disable registry/JSON-based external extension providers on Android entirely, and similarly I need to think through install verification—likely disabling the InstallSigner/InstallVerifier network check by default rather than requiring the install-verification flag. Garbage collection and shared module services can stay generic, while app sorting logic is another piece to consider adapting. For app sorting, I'd swap in NullAppSorting instead of ChromeAppSorting. ExtensionSyncService should be excluded since it pulls in sync dependencies the Android system likely omits. Theme extensions don't apply since Android lacks ThemeService, so I'd block "theme" in the manifest feature platform list, and the extension-icon WebUI data source can remain as-is since it's generic. For notifications, chrome.notifications could plausibly work through NotificationDisplayServiceImpl with NotificationPlatformBridgeAndroid, though Android 13+ notification permissions need handling. For downloads, chrome.downloads relies on DownloadManager and DownloadCoreService, both of which exist on Android, though ChromeDownloadManagerDelegate differs enough that some sub-APIs like showDefaultFolder may need special treatment. Now I'm planning the overall structure of my answer: it should be in Chinese, organized with headers, numbered steps, bullet points, a GN args snippet, and a table comparing API adaptation status, plus realistic caveats referencing Kiwi's src.next fork and upstream desktop-android build flags. I'm aiming for a dense, thorough response of a few thousand characters without padding, starting with the boundary conditions—namely that this approach only works on Android since iOS is locked to WebKit. I'm noting that upstream Chromium never enables extensions on Android by default (`enable_extensions` is false there), even though `//extensions` itself is cross-platform; what's missing is the desktop-UI-coupled portions of `//chrome/browser/extensions` plus the entire Android UI layer, and I'm citing prior art like Kiwi Browser's src.next patch set, Edge Android Canary's extension whitelist, Yandex, and other forks as reference points. Since 2024, Google has begun porting extensions to "Desktop Android" upstream, adding buildflags like `enable_extensions_core` and `enable_desktop_android_extensions` along with new `chrome/browser/extensions/desktop_android/` code — still an incomplete subset lacking UI and full API coverage, but it handles much of the compilation groundwork, so I'd recommend building on the latest stable branch and assessing this effort's current state before picking a starting point. I'm also estimating the effort involved: Kiwi was a years-long solo project, while a proper team would need three to five people, including at least one or two deeply familiar with content/ch... Rebase work against Chromium's four-week release cycle and weekly security patches is really the dominant ongoing cost, requiring one to two dedicated engineers long-term after an initial three-to-six month internal build and six-to-twelve month public beta window. On the manifest front, since uBlock Origin depends on MV2's `webRequestBlocking` which upstream is actively removing, I think MV3 should be the primary target (uBO Lite, AdGuard MV3, Tampermonkey 5.x with `userScripts`), keeping MV2 as an optional compatibility layer. Now I'm moving into outlining the development steps, starting with environment setup, code baseline, and engineering structure on Linux. For pulling the code, I'm outlining using depot_tools with `fetch --nohooks chromium`, adding `target_os = ['android']` to `.gclient`, then running `gclient sync` to bring in Android SDK/NDK automatically, and I'm noting the baseline should track a stable branch rather than main. For engineering structure, rather than building one giant fork, I'm recommending a "patch series + automated apply/rebase scripts" approach like Kiwi's src.next or Cromite, with each patch scoped to a single responsibility to make rebase conflicts easier to resolve. I'm also covering de-branding and compliance steps: setting `is_chrome_branded=false`, changing the package name, app name, and icons since it can't be called Chrome, and stripping Google API keys since third-party sync/check-in services have been blocked since 2021 -- plus being mentally prepared for Google potentially blocking the app's user agent on CWS. Before customizing further, I'm suggesting building and running `chrome_public_apk` with default config first to confirm the toolchain works, then showing example GN args for an arm64 non-component release build. Next I'm turning on the extensions build flag and expecting hundreds to thousands of compile errors from browser/renderer/common extension code that still depends on desktop concepts. My strategy is to wrap purely desktop-only pieces -- views dialogs, toolbar containers, Chrome Apps/platform apps -- behind `if (!is_android)` or `#if !BUILDFLAG(IS_ANDROID)` guards to strip them out. I'm mapping out the key classes needing Android adaptations: `ChromeExtensionsBrowserClient` is mostly reusable, but its `ChromeProcessManagerDelegate` needs `BrowserList` window checks replaced with Android's foreground/background `ApplicationStatus`, and `ExtensionSystemImpl` has its own dependencies to untangle. I'm continuing to trace the layer, noting that GuestView-related delegates in `ChromeExtensionsAPIClient` should return null since `` isn't compiled on Android, while the common and renderer-layer clients are largely portable, and now I'm looking at the content-layer hooks in `ChromeContentBrowserClientExtensionsPart` covering process model, site isolation for `chrome-extension://`, effective URL resolution, and URL loader factory registration. Beyond that, I need to confirm the `chrome-extension` scheme is registered via `ChromeContentClient::AddAdditionalSchemes` and properly treated as an internal scheme by Java-side URL handling like `ExternalNavigationHandler` and omnibox parsing, and I'm also tracking the largest chunk of work — mapping tab model utilities like `ExtensionTabUtil` and `ChromeExtensionFunctionDetails` to Android's browser structure. On Android, since there's no `Browser`/`TabStripModel`, I need to rely on `TabModelList`/`TabModel`/`TabAndroid` instead, keeping tab IDs consistent through `SessionTabHelper::IdForTab`, and mapping each `TabModel` (regular or incognito) to a window by implementing an Android version of `WindowController`. I also need to extend `TabHelpers::AttachTabHelpers` on Android to attach the extensions tab helper alongside the existing helpers. Beyond that, I need to make sure KeyedService registration is complete—wiring up `EnsureBrowserContextKeyedServiceFactoriesBuilt()` and the API factories in the extra parts profiles file, plus registering `ExtensionPrefs` in `browser_prefs.cc`. Then for trimming the API surface, I'll need to prune the schema sources list and adjust the `platforms` field across the features JSON files, starting by cutting identity, enterprise, and other platform-inappropriate APIs. I also need to disable install verification since `InstallVerifier`/`InstallSigner` require Google API signing that doesn't make sense on Android, and swap in `NullAppSorting` for `ChromeAppSorting`. For the unpacking pipeline, `SandboxedUnpacker` depends on unzip and data_decoder utility services that Android already has via component updater, so I just need to confirm the GN dependencies are pulled into the Android target. Then there's the renderer process side—checking how `ChromeContentRendererClient` handles extension-related calls. Now moving to the install/update flow, I'm planning to start with local sideloading as the fastest validation path: register intents for `.crx`/`.zip` files with the system file picker, route `.crx` through `CrxInstaller::InstallCrx` for CRX3 verification, and unpack `.zip` via the unzip service into the profile directory before running the unpacked installer. For the Chrome Web Store path, I need to force a desktop UA override on that domain so it doesn't show as unsupported, enabling the `webstorePrivate` API through the built-in webstore component app authorization. Then `WebstoreInstaller` downloads the CRX from the update server and hands it to `CrxInstaller`, with `BeginInstallWithManifest3` triggering a permission confirmation that requires an Android version of `ExtensionInstallPrompt`. A more robust approach would be intercepting CWS detail page URLs to inject a custom install button or build my own curated list, then pull packages directly through the update protocol endpoint and feed them to `CrxInstaller` -- this is essentially what Edge Android does with its whitelist and self-maintained list. For updates, `ExtensionUpdater`/`ExtensionDownloader` polls based on the manifest's `update_url` (defaulting to CWS), which is generic enough to work, though I need to confirm Android's network and battery policies around foreground/Wi-Fi restrictions. The permission prompt itself, `ExtensionInstallPrompt`, is desktop views-based, so it'd need JNI calls into a Java `ModalDialogManager` to render on Android, though the permission text from `ChromePermissionMessageProvider` is shared and reusable. Post-install feedback goes through `ExtensionInstallUI` as a toast or snackbar. The MV2 deprecation policy is gated by `ManifestV2ExperimentManager` and related feature flags, controlling whether MV2 extensions remain usable -- and in a fork, it might be worth loosening the DNR static/dynamic rule limits to give more headroom. For Manifest V3 blocking capabilities to approach the completeness of desktop uBO Lite or AdGuard MV3, since `webRequestBlocking` is normally policy-gated on Chrome, that restriction in `_permission_features.json` could be relaxed (with performance testing). Moving to step 4, the Android UI layer built in Java with JNI: I'm sketching an `ExtensionsBridge` using `@NativeMethods` to expose functions for listing extensions, toggling enable/disable, uninstalling, allowing incognito access, managing action icons/badges, handling action clicks, opening options pages, and loading unpacked extensions. For the management page itself, I'm considering reusing the `chrome://extensions` WebUI along with the `developerPrivate` API. I'm registering this WebUI for Android through `chrome_web_ui_configs.cc`, stubbing out desktop-only features like DevTools inspect and repair within `developerPrivate` -- similar to how Kiwi Browser approached it, since the WebUI already has responsive layout built in. A native Settings Fragment could also work as an alternative. For the toolbar, I'm planning an "Extensions" section in the AppMenu with icons and badges sourced from `ExtensionActionManager`/`ExtensionAction` via `ExtensionActionIconFactory`. For popups, when `ExtensionActionRunner::RunAction` signals `ShowPopup`, I'd use `ExtensionViewHostFactory::CreatePopupHost` to create the host and implement the Android-specific popup rendering. Beyond that, I need to attach the popup host's `WebContents` view to a Java `ContentView` inside a BottomSheet or Dialog, handling auto-resize behavior (fixed width matching screen, height capped at 70% of screen height), `window.close()` calls, and links opening in new tabs. For the options page, I'd open `chrome-extension:///options.html` in a regular tab, requiring a rewrite of `ExtensionTabUtil::OpenOptionsPage` to remove its `Browser` dependency. For context menus, I'd need to extend `ChromeContextMenuPopulator` in Java to support `chrome.contextMenus`. I'm also thinking about runtime host permission requests for MV3 `activeTab`, which need a "click to run" affordance tied to `ExtensionActionRunner`'s blocked actions — otherwise many MV3 extensions simply won't activate on pages. For debugging extension pages on mobile without DevTools, remote debugging via desktop `chrome://inspect` should suffice. Now I'm drafting a prioritized API compatibility list, starting with P0 essentials: `runtime`, `storage`, `alarms`, `i18n`, `permissions`, and `management` should work mostly unchanged, while `tabs` and `windows` will require the heaviest rework to map onto Android's model. Continuing through P0, I'm noting that `scripting`/`content_scripts` and `userScripts` can reuse the renderer largely as-is, though `userScripts` needs a developer-mode toggle since Chrome gates it behind one — I'd add an "allow user scripts" switch in the fork. `declarativeNetRequest` should transfer with adjustable rule limits, `webRequest`/`webRequestBlocking` need care around per-request IPC overhead affecting battery and CPU on mobile, and `webNavigation`/`cookies` should be straightforward. For `action`/`browserAction`/`pageAction`, the data layer can stay shared while the UI presentation gets a custom implementation. Moving into P1, `notifications` should route through Android's `NotificationPlatformBridgeAndroid` with attention to Android 13+ permission requirements, and `history`, `bookmarks`, `topSites`, and `sessions` all have Android equivalents to build on. Now for downloads, contextMenus, proxy, privacy, browsingData, and tts — I'm working through which pieces map cleanly onto Android's existing infrastructure (like `HistoryService`, `BookmarkModel`, prefs-based systems, and `TtsPlatformImplAndroid`) versus which need real rework, like downloads and context menus given Android's different download stack and Java-based menu system. For P2, I'm deciding to cut a batch of APIs that don't fit the Android model well — things like keyboard shortcuts, the omnibox (which is Java-native on Android), side panel, tab groups, identity, GCM, native messaging, capture APIs, font settings, printing, filesystem, enterprise policies, themes, and platform apps/webview. Now I'm moving into the process, performance, and security considerations, starting with how Android's memory constraints limit the render process model. For process lifecycle, I'm reasoning that Android's low-memory killer makes MV2's persistent background pages especially costly on weaker devices, so MV3 service workers should be the priority, with `ProcessManager`'s idle/keepalive timers shortened for mobile and extension processes proactively suspended when the app backgrounds, aligning with `ApplicationStatus`. On startup, I'm noting that `InstalledLoader` synchronously reading manifests could hurt first-frame performance as extension count grows, so deferring that work until after the first tab is interactive, or caching it, seems worthwhile. For memory, each extension's service worker or background page can cost tens of MB, so I'm thinking the UI needs to surface per-extension resource usage and offer a "foreground-only" execution mode. Then I start considering the security implications. Now I'm thinking through security requirements: preserving `chrome-extension://` process isolation, enforcing CRX3 signature verification with CWS publisher proof, requiring explicit confirmation and risk warnings for sideloading, and recognizing that Safe Browsing's extension blocklist relies on Google's API, meaning a self-maintained blocklist or remote config is needed instead -- while avoiding shortcuts like disabling web security flags. On the compliance side, I'm reasoning that Google Play permits browsers to execute JS as an explicit exception to code-download restrictions, but the store listing must disclose third-party extension support; using CWS itself doesn't violate Play policy, though its ToS isn't really written for third-party browsers, so there's a real risk of being blocked by user-agent or API checks. For testing and maintenance, I'm planning to extend `extensions_unittests`/`unit_tests` and add instrumentation tests to `chrome_public_test_apk`, plus build a manual regression checklist covering popular extensions like uBlock Origin, AdGuard, Tampermonkey, Violentmonkey, Dark Reader, and SponsorBlock across install/update/uninstall/incognito/permissions/popup/options/multi-tab scenarios. I'm also outlining a rebase cadence tied to Chromium's four-week stable cycle, with weekly security patches layered on top. Then I'm thinking through a lighter-weight alternative if full extension support proves too heavy: restricting to a MV3 subset (DNR, scripting/userScripts, storage, runtime, tabs) while dropping MV2 and webstorePrivate in favor of a curated store, which would cover most of what uBO Lite, AdGuard MV3, and Tampermonkey MV3 users need at roughly half the maintenance burden. An even lighter option would be skipping the extension system entirely and just baking in native capabilities directly. For ad blocking, I'd integrate Brave's adblock-rust via FFI into the network service's URL loader interceptor layer, or use Chromium's built-in subresource_filter component with custom rule lists. For userscripts, I'd do native injection through RenderFrameObserver hooks at document_start alongside a GM_* compatibility layer, similar to what Via or X browser do -- this whole approach is feasible for a 1-2 person team. Then I'm sketching out milestones, starting with M0 (2-4 weeks) to get Chromium compiling, rebranded, and CI running. After that, M1 (1-2 months) targets getting extensions enabled and sideloading uBO Lite with visible DNR blocking; M2 adds tabs/windows mapping and Tampermonkey support with popup/options pages; M3 tackles Chrome Web Store installation, update flow, permission dialogs, the MV2 decision, and performance tuning; M4 is public beta plus solidifying the rebase workflow. I'm double-checking some technical details for accuracy, like the default build flag configuration for enabling extensions across platforms. Now I'm verifying the manifest package GN arg definition, the scheme registration in ChromeContentClient, and confirming that ChromeContentBrowserClientExtensionsPart exists in the expected location. Also confirming `ManifestV2ExperimentManager`, the manifest V2 deprecation feature flags, `WebRequestProxyingURLLoaderFactory`, and `NotificationPlatformBridgeAndroid` all check out. Continuing to verify Android-specific pieces: `TtsPlatformImplAndroid`, `SessionTabHelper` attaching on Android, `TabModelList`/`TabModel`/`TabAndroid`, and `ApplicationStatus` (Java) with its native `ApplicationStatusListener` counterpart — all confirmed real. I'm also checking that remote debugging via `chrome://inspect` works for Android Chromium builds, which requires enabling USB debugging through Chrome's settings for a fork. I'm also confirming Google Play's policy language on downloading executable code outside Play's update mechanism, the March 2021 shutdown of sync APIs for third-party Chromium browsers, and recalling that Kiwi Browser announced its shutdown around January 2025. I'm double-checking Edge Canary's Android extension support rollout in March 2024, the Chrome Web Store's domain migration to chromewebstore.google.com in December 2023, uBlock Origin's release naming convention, and Tampermonkey's shift from requiring Developer mode to an "Allow User Scripts" toggle in Chrome 138, along with the DNR static rule count limits. Now I'm verifying details about NullAppSorting, InstallSigner's use of a Google API key, and the unzip service's role in component updater for CRX extraction on Android. I'm also recalling that `chrome_web_ui_configs.cc` and `ExtensionsUI` are legitimate paths, and trying to nail down my confidence around `enable_desktop_android_extensions` and `enable_extensions_core` build flags used across BUILD.gn files. I'm also weighing the `is_desktop_android` GN flag and its likely dependency on `enable_desktop_android_extensions`, though I'm not fully certain how they interact. I should note that Profile handling on Android exists too, and that the tabs API file is a large one worth flagging as a reference point. Confirming there's no `Browser` class on desktop-style UI for Android — that lives under `chrome/browser/ui/android/` instead, gated out via BUILD.gn conditions. Native TabModelSelector handles incognito state, and per-site UA overrides like "Request Desktop Site" flow through `RequestDesktopSiteUtils` and `TabAndroid` rather than through desktop's ChromeContentBrowserClient path. I'll write the reply in Simplified Chinese with English technical terms where fitting, aiming for a thorough but not redundant answer covering the practical limits, seven concrete steps, and a compact reference table—organizing it so the boundary caveats come first, then implementation steps, avoiding repeating the same details twice. I'll skip a separate "top 5 risks" recap since the boundary section already covers rebase costs, tab/window mapping, popup hosting, MV2 vs MV3, and CWS dependency, and instead close with a brief milestone plan, reminding the reader to verify actual upstream code against their chosen fork/branch. 这是一个可行但工程量很大的方向（Kiwi Browser、Edge Android、Yandex 都做过），下面按"先讲清边界 → 开发步骤 → 每步的关键实现点 → 替代方案"来梳理。 --- ## 一、先明确几个现实边界 1. **只能做 Android。** iOS 强制使用 WebKit，除欧盟 DMA 场景外无法上架 Chromium 内核浏览器。 2. **Chromium 上游的 Android 版从未启用扩展。** `enable_extensions` 在 Android 上默认为 `false`。`//extensions` 框架层（manifest 解析、进程管理、EventRouter、脚本注入、DNR、webRequest 等）本身是跨平台的；真正缺的是 `//chrome/browser/extensions` 中与桌面 UI（views、`Browser`、`TabStripModel`）耦合的部分，以及全部 Android 侧 UI。 3. **可参考的前例：** - Kiwi Browser：开源，`github.com/kiwibrowser/src.next` 是一套"patch 集 + GitHub Actions 构建"，2025 年初已停止维护，但仍是最完整的公开参考。 - Edge Android（2024 起在 Canary 提供白名单扩展）、Yandex；Lemur/Quetta/Mises 等基本源自 Kiwi。 4. **上游正在帮你干活（重要）：** 2024 年起 Google 为 "Desktop Android" 逐步把扩展移植到 Android，引入了 `enable_extensions_core` / `enable_desktop_android_extensions` 等编译开关（见 `extensions/buildflags/buildflags.gni`），并新增 `chrome/browser/extensions/desktop_android/` 等目录。目前仍是不完整的子集（缺 UI、API 有限），但已经把大量"让扩展代码在 Android 上编过"的脏活做掉了。**强烈建议以最新 stable 分支上这条线的现状作为起点，而不是像 Kiwi 当年那样从零硬开 `enable_extensions`。**（具体开关名和目录以你选定分支的代码为准。） 5. **工作量与成本大头：** 正规团队 3~5 人（至少 1~2 人熟悉 content/chrome 层、GN、JNI），3~6 个月内部可用，6~12 个月公测。之后需要 1~2 人长期专职 rebase——Chromium 每 4 周一个大版本、每周有安全更新，**rebase 才是真正的长期成本**，Kiwi 就是被这个拖垮的。 6. **MV2 vs MV3：** uBlock Origin 完整版依赖 MV2 的 `webRequestBlocking`，而上游正在删除 MV2 代码，长期维护 MV2 的 rebase 成本会越来越高。建议以 **MV3 为主**（uBO Lite、AdGuard MV3、Tampermonkey 5.x 走 `userScripts` API），MV2 作为可选兼容层。 --- ## 二、开发步骤与关键实现点 ### 第 1 步：环境、基线与工程形态 - **机器**：Linux（Ubuntu 22.04/24.04），内存 64GB 起，NVMe ≥ 300GB。arm64 release 全量编译数小时。 - **拉代码**：depot_tools → `fetch --nohooks chromium`，`.gclient` 中加 `target_os = ['android']`，`gclient sync` 会自动带下 Android SDK/NDK。 - **基线**：选 stable 分支（`refs/branch-heads/NNNN`），不要跟 main。 - **工程形态**：不要改出一个巨型 fork，采用 **"patch 系列 + 脚本自动 apply/rebase"**（Kiwi src.next、Cromite 都是这种）。每个 patch 单一职责，rebase 冲突好定位。 - **去品牌与合规**：改包名（`chrome_public_manifest_package`）、应用名、图标（`chrome/app/theme/chromium`）；不能叫 Chrome；不要带 Google API keys（Google 2021 年起已对第三方 Chromium 关闭 Sync 等服务）。 - 先用默认配置把 `chrome_public_apk` 编出来跑起来，确认工具链没问题。 GN args 示例： ```gn target_os = "android" target_cpu = "arm64" is_debug = false is_component_build = false symbol_level = 1 enable_extensions = true # 或先尝试 enable_desktop_android_extensions = true，看能编到什么程度 ``` ### 第 2 步：打开扩展编译开关，让 Browser/Renderer 进程编过预期会遇到几百到上千个编译错误，来源集中在 `chrome/browser/extensions`、`chrome/browser/ui/extensions`、`chrome/browser/apps`、`chrome/renderer/extensions`、`chrome/common/extensions` 对桌面的依赖。策略是：纯桌面内容用 `if (!is_android)` / `#if !BUILDFLAG(IS_ANDROID)` 剔掉（views 对话框、toolbar 容器、Chrome Apps/platform apps、`ExtensionSyncService`、`ExternalProviderImpl`、主题扩展等），必要抽象提供 Android 实现。关键类/文件（路径以近期主干为准）： 1. **嵌入层 Client** - `ChromeExtensionsBrowserClient`：大部分通用。其中 `ChromeProcessManagerDelegate` 用 `BrowserList`"是否有窗口"决定后台页生命周期，Android 改用 `ApplicationStatus` 前后台状态。 - `ExtensionSystem`：`ExtensionSystemImpl` 依赖多，可先用/参考 `DesktopAndroidExtensionSystem`。 - `ChromeExtensionsAPIClient`：GuestView（``）在 Android 不编，相关 delegate 返回空。 - `ChromeExtensionsClient`（common）、`ChromeExtensionsRendererClient`（renderer）基本通用。 2. **Content 层钩子**：`ChromeContentBrowserClientExtensionsPart`（进程模型、`chrome-extension://` 站点隔离、`GetEffectiveURL`、`ExtensionURLLoaderFactory` 注册、`WebRequestAPI::MaybeProxyURLLoaderFactory`）本身在 `#if BUILDFLAG(ENABLE_EXTENSIONS)` 下，开关打开后自动纳入；重点验证 Android 的 partial site isolation 下，扩展 origin 仍然拿到独立渲染进程。 3. **Scheme 注册**：`ChromeContentClient::AddAdditionalSchemes` 注册 `chrome-extension`；Java 侧的 URL 处理（`ExternalNavigationHandler`、omnibox 输入解析）要把它当内部 scheme 放行，否则地址栏打不开扩展页。 4. **Tab 模型映射（最大的一块）**：`ExtensionTabUtil`、`chrome::FindBrowserWithTab`、`ChromeExtensionFunctionDetails`、`tabs_api.cc` 等大量依赖 `Browser`/`TabStripModel`（Android 上根本没有 `Browser` 类）。需要基于 `TabModelList` / `TabModel` / `TabAndroid`（`chrome/browser/ui/android/tab_model/`、`chrome/browser/android/tab_android.h`）重写。tab id 继续用 `sessions::SessionTabHelper::IdForTab`（Android 也挂了这个 helper）。`chrome.windows` 建议把每个 `TabModel`（普通/隐身）映射为一个 window，实现 Android 版 `WindowController`。 5. **Tab helpers**：`TabHelpers::AttachTabHelpers`（`chrome/browser/ui/tab_helpers.cc`）的 Android 分支加上 `extensions::TabHelper`、`ChromeExtensionWebContentsObserver`、`ExtensionActionRunner` 等。 6. **KeyedService 与 Pref 注册**：`chrome_browser_main_extra_parts_profiles.cc` 中确保 `extensions::EnsureBrowserContextKeyedServiceFactoriesBuilt()` 及各 API 的 factory 建齐；`ExtensionPrefs` 等在 `browser_prefs.cc` 注册。 7. **API 清单裁剪**：`chrome/common/extensions/api/api_sources.gni`（schema 列表）+ `_api_features.json` / `_permission_features.json` / `_manifest_features.json` 的 `platforms` 字段。先砍掉 identity、enterprise.*、fileSystem、printing、desktopCapture/tabCapture、sidePanel、commands、nativeMessaging、fontSettings、theme 等，能显著减少编译面。 8. **安装校验**：`InstallVerifier` / `InstallSigner` 要拿 Google API key 向 Google 签名，直接关闭；`AppSorting` 用 `NullAppSorting`。 9. **解包链路**：`SandboxedUnpacker` 依赖 `unzip` / `data_decoder` utility service，Android 上都有（component updater 在用），确认 GN 依赖被拉进 Android target。 10. **Renderer 进程**：`ChromeContentRendererClient` 里的扩展调用（`RenderFrameCreated`、`RunScriptsAtDocumentStart/End/Idle`、`ScriptInjectionManager`、`NativeExtensionBindingsSystem`）都在编译开关下，一般直接可用。 ### 第 3 步：安装 / 更新链路 - **本地侧载（先做，最快验证）**：注册 `.crx` / `.zip` 的 Intent（mime `application/x-chrome-extension`）+ 系统文件选择器。`.crx` 走 `CrxInstaller::InstallCrx`（CRX3 签名校验，`crx_file` 组件），`.zip` 先用 unzip service 解到 profile 目录再 `UnpackedInstaller::Load`。uBO 的 GitHub Release 提供 `.chromium.zip`，Tampermonkey 官网提供 crx，用它们做冒烟。 - **Chrome Web Store，两种路线：** - A. 让 `chromewebstore.google.com` 直接可用：对该域强制桌面 UA（否则页面提示不支持），使 `webstorePrivate` API 生效（`chrome/browser/extensions/api/webstore_private/`，由内置 webstore 组件 app 授权），`WebstoreInstaller` 会从更新服务器下载 CRX 再交给 `CrxInstaller`；`BeginInstallWithManifest3` 会弹权限确认 → 需要 Android 版 `ExtensionInstallPrompt`。 - B. 更稳的做法：拦截 CWS 详情页 URL（`/detail//`）注入自己的"安装"按钮，或做自有精选列表（Edge Android 就是白名单 + 自有列表），直接用更新协议拉包再 `CrxInstaller`： ``` https://clients2.google.com/service/update2/crx?response=redirect&prodversion=<版本>&acceptformat=crx2,crx3&x=id%3D<扩展ID>%26uc ``` - 注意：CWS 的 ToS 并不面向第三方浏览器，有被 UA/接口封禁的风险，要预留自有源作为回退。 - **更新**：`ExtensionUpdater` / `ExtensionDownloader` 按 manifest 的 `update_url` 轮询，通用；加上移动端策略（前台 + Wi-Fi 才检查）。 - **权限弹窗**：`ExtensionInstallPrompt` 的展示层是桌面 views，需要通过 JNI 用 Java `ModalDialogManager` 实现；权限文案来自 `ChromePermissionMessageProvider`，通用。安装成功提示（`ExtensionInstallUI`）用 Snackbar。 - **MV2 政策**：由 `extensions_features::kExtensionManifestV2Disabled/Unsupported` 与 `ManifestV2ExperimentManager` 控制，在 fork 里决定是否放开。 - **fork 的额外自由度**：可以适当放宽 DNR 规则上限（`extensions/common/api/declarative_net_request/constants.*`），让 uBO Lite / AdGuard MV3 拦截能力更接近完整版；也可以放开 MV3 的 `webRequestBlocking`（`_permission_features.json` 中它被限制为策略安装），但要评估性能。 ### 第 4 步：Android UI（Java + JNI） - **JNI 桥**：一个 `ExtensionsBridge`（`@NativeMethods`），提供：扩展列表、启用/禁用、卸载、隐身允许、action 图标与 badge、点击 action、打开 options、加载本地包。 - **管理页**：复用 `chrome://extensions` WebUI（`chrome/browser/ui/webui/extensions/` + `developerPrivate` API），在 `chrome_web_ui_configs.cc` 为 Android 注册；`developerPrivate` 中 DevTools inspect、repair 等桌面功能做 stub。WebUI 自带响应式布局，Kiwi 就是这样做的。也可以写原生 Settings Fragment。 - **工具栏/菜单**：在 AppMenu 增加"扩展"区（图标横排或列表），图标与 badge 来自 `ExtensionActionManager` / `ExtensionAction` / `ExtensionActionIconFactory`。 - **Popup（最需要设计的 UI）**：`ExtensionActionRunner::RunAction` 返回 `ShowPopup` 后，用 `ExtensionViewHostFactory::CreatePopupHost` 创建 host，并实现 Android 版 `ExtensionView`：把 host 的 `WebContents` 的 `ui::ViewAndroid` 挂进 Java `ContentView`，放在 BottomSheet 或 Dialog 中；处理 `ResizeDueToAutoResize`（宽度固定为屏宽，高度自适应、上限约屏高 70%）、`window.close()`、popup 内链接开新 tab。 - **Options 页**：以 tab 打开 `chrome-extension:///options.html`（重写 `ExtensionTabUtil::OpenOptionsPage` 去掉 `Browser` 依赖）。 - **运行时站点访问**：MV3 的 `activeTab` / host 权限需要"扩展请求访问此站点"提示和"点击运行"入口（`ExtensionActionRunner` 的 blocked actions），否则很多 MV3 扩展在页面上不会生效。 - **上下文菜单**（`chrome.contextMenus`）：在 Java `ChromeContextMenuPopulator` 中追加 `MenuManager` 的项（二期）。 - **调试**：手机上没有 DevTools，开放 remote debugging，用桌面 `chrome://inspect` 调扩展页面。 ### 第 5 步：API 适配优先级 | 优先级 | API | 状态 / 说明 | |---|---|---| | P0 | `runtime` `storage` `alarms` `i18n` `permissions` `management` | 通用，基本免改 | | P0 | `tabs` `windows` | 重写 Android 映射，工作量最大 | | P0 | `scripting` + content_scripts、`userScripts` | renderer 侧通用；`userScripts` 在 Chrome 需要开发者模式/开关，fork 里给一个"允许用户脚本"开关（Tampermonkey 5.x 必需） | | P0 | `declarativeNetRequest` | 通用，规则上限可调 | | P0 | `webRequest`（观察）/ `webRequestBlocking`（MV2） | 通用；阻塞式每个请求都要跨进程往返，注意手机 CPU/电量 | | P0 | `webNavigation` `cookies` | 通用 | | P0 | `action` / `browserAction` / `pageAction` | 数据层通用，展示层自实现 | | P1 | `notifications` | 走 `NotificationPlatformBridgeAndroid`，注意 Android 13+ 通知权限 | | P1 | `history` `bookmarks` `topSites` `sessions` | Android 有 `HistoryService`/`BookmarkModel`，小改 | | P1 | `downloads` | Android 下载栈不同，部分实现 | | P1 | `contextMenus` `proxy` `privacy` `browsingData` `tts` | 依赖 Java 菜单/prefs，可用 | | 砍掉 | `commands` `omnibox` `sidePanel` `tabGroups` `identity` `gcm` `nativeMessaging` `desktopCapture` `tabCapture` `printing` `fileSystem` `enterprise.*` `theme` platform apps / `` | 手机上无意义或依赖 Google 服务 | ### 第 6 步：进程模型、性能与安全 - **进程模型**：Android 渲染进程数受内存限制、随时被 LMK 杀。MV2 persistent background 在低端机很痛，优先 MV3 Service Worker；`ProcessManager` 懒后台的 keepalive/idle 参数可针对移动端调短；App 切后台时可主动挂起扩展进程。 - **启动性能**：`InstalledLoader` 启动时同步读所有 manifest，扩展多了会拖首帧，考虑延后到首个 tab 可交互后再加载。 - **内存**：每个扩展 SW/后台页几十 MB，UI 上要能看到扩展占用，并提供"仅前台运行"策略。 - **安全**：保留 `chrome-extension://` 进程隔离；CRX3 签名校验（CWS 包要求 publisher proof）；侧载必须二次确认与风险提示；Safe Browsing 扩展黑名单依赖 Google API，需要自建黑名单/远程配置；别为了省事加 `--disable-web-security` 之类开关。 - **合规**：Google Play"禁止下载可执行代码"的政策明确豁免浏览器中运行的 JavaScript，扩展本身不违规；商店描述需写清可安装第三方扩展。 ### 第 7 步：测试与持续维护 - **自动化**：`extensions_unittests` / `unit_tests`（Android 可跑）；在 `chrome_public_test_apk` 中加扩展相关 instrumentation 测试。 - **手工回归清单**：uBlock Origin（MV2）、uBO Lite、AdGuard MV3、Tampermonkey 5.x、Violentmonkey、Dark Reader、Stylus、SponsorBlock、Return YouTube Dislike；覆盖安装/更新/卸载/隐身/权限提示/popup/options/多 tab 切换。 - **rebase 流程**：每个 Chromium stable（4 周）跟一次，每周安全更新 cherry-pick；CI 自动 apply patches + 编译 + 冒烟。特别关注上游 `chrome/browser/extensions` 的 Desktop Android 重构——它既会帮你，也会频繁与你的 patch 冲突。 --- ## 三、如果全量扩展支持太重：两个轻量替代方案 1. **只支持 MV3 子集**：DNR + `scripting`/`userScripts` + `storage` + `runtime` + 精简版 `tabs`，不做 MV2、不做 `webstorePrivate`，用自有精选源分发。能覆盖 uBO Lite / AdGuard MV3 / Tampermonkey MV3 的绝大部分需求，工作量约减半，rebase 压力小很多。 2. **不做扩展系统，内置能力**：广告拦截接入 Brave 的 `adblock-rust`（MPL 协议，通过 FFI 在 network service 的 `URLLoaderRequestInterceptor` 层拦截）或用 Chromium 自带 `//components/subresource_filter` 加载自定义规则；用户脚本用原生注入（`RenderFrameObserver::DidCreateScriptContext` / `ExecuteScriptInIsolatedWorld` 在 document_start 注入）并实现 GM_* 兼容层（Via、X 浏览器的路线）。适合 1~2 人团队。 --- ## 四、建议的里程碑 - **M0（2~4 周）**：Chromium Android 编译跑通、品牌化、CI 与 patch 流程建立。 - **M1（1~2 月）**：扩展编译开关打开并编过，侧载 uBO Lite 可见拦截效果（验证 DNR + 进程模型 + scheme）。 - **M2（+1~2 月）**：`tabs`/`windows` 映射、Tampermonkey 可用、popup/options/管理页。 - **M3（+1~2 月）**：CWS 安装与更新、权限弹窗、MV2 决策、内存与启动性能调优。 - **M4**：公测，固化 rebase 节奏。如果你能告诉我目标机型档位（低端为主还是旗舰）、团队规模，以及是否一定要完整版 uBlock Origin（决定要不要背 MV2），我可以进一步帮你收敛 API 范围和技术路线。

我想基于chromium开发一个手机浏览器，需要支持chrome的扩展安装，比如：广告拦截，脚本运行等扩展。请列下具体的...