Chrome for Android Features Still Missing Tab-Group API

A December 2025 Chromium commit adds support for chrome.tabGroups.get(), an extension method that lets developers query tab-group data, on a surface the commit itself calls "desktop Android." That term doesn't appear defined anywhere else in the supplied commit, so every claim in this piece about where it applies stays tied to that exact phrase (Chromium commit). It's a narrow addition to the list of Chrome for Android features extension developers might want, and it's worth being precise about what it actually delivers.

The method returns only basic group information. Visual data, the commit states, "is not supported yet" and will require more JNI work to add (Chromium commit). The commit also notes that chrome.tabs.group(), the method Chromium's own tests rely on to set up group scenarios, "isn't supported yet on Android." It doesn't say whether that limitation is specific to the "desktop Android" surface where get() now works, or whether it's a broader Android gap that happens to include that surface too (Chromium commit).

Shipping a way to inspect tab groups without a confirmed way to create or manage them isn't a scaled-down version of tab-group support. As of this commit, extensions whose whole purpose is organizing tab groups can't be built on this API alone. That argument stays scoped deliberately to this one API on this one named surface, not to a sweeping verdict on Chrome for Android's extension ecosystem.

What the tab-group API can and can't do right now

get() works because engineers finished a piece of underlying plumbing first. With the TabListInterface and JNI bridge already in place, the commit presents enabling get() as the next step (Chromium commit). That's completed groundwork, not a stub rushed out ahead of schedule.

What that groundwork buys a developer, as of December 2025, is narrow:

• Enabled: chrome.tabGroups.get() on the surface Chromium names "desktop Android," returning basic group information about an existing group (Chromium commit).
• Not supported on Android: chrome.tabs.group(), the method for creating a group or moving a tab into one. The commit doesn't specify whether this exclusion covers "desktop Android" specifically or Android generally (Chromium commit).
• Not supported yet: visual data, pending additional JNI work (Chromium commit).
• Not addressed by the commit: which Chrome channel or release includes this change, whether it's on by default, or what "desktop Android" means as a consumer-facing surface.

The workflow stops at "look." It never reaches "act."

None of that makes get() useless, though. A read-only method is enough to build a sidebar that lists a tab's current groups, a diagnostic panel that reports group state for troubleshooting, or a lightweight display that surfaces group metadata without touching it. Those are legitimate, narrower use cases: anything that only needs to show what already exists. What get() can't support is any extension whose value comes from creating, merging, or rearranging groups on a user's behalf, which is the kind of functionality session managers and project-based tab organizers are built around.

The clearest proof of that write-side gap shows up in the commit's own testing notes. Chromium couldn't reuse its existing test for get() because that test relies on tabs.group(), so engineers added a couple of API tests to exercise the method on its own (Chromium commit). A test suite that can't assume the write method exists suggests just how incomplete that side of the API still is.

Why inspection without action doesn't finish the job

There's a fair counterargument here, and it deserves a direct answer. Shipping the read method before the write method is a defensible sequence: build the ability to query something before building the ability to modify it. The completed JNI groundwork behind get() is real progress (Chromium commit). Nothing in this commit shows Google shelving tab-group support for Android extensions; it shows the work is partway done. For developers comparing Android's extension platform with its desktop counterpart, this reads as one conspicuous capability gap, though the supplied research doesn't include a broader feature comparison to weigh that against.

Sequencing explains why the gap exists. It doesn't change what a developer could actually build as of this commit. Until chrome.tabs.group() ships on Android, whether or not that specifically includes the "desktop Android" surface, anyone aiming at more than a static display panel has no write path to build against (Chromium commit). The supplied evidence doesn't establish whether that's changed since.

Missing Chrome for Android features: what remains unverified

The commit establishes one thing clearly: get() was added in a change tied to the surface Chromium names "desktop Android" (Chromium commit). Everything past that point is unverified in the supplied research.

The commit doesn't say which Chrome channel or release carries the change, whether it ships on by default, or what "desktop Android" actually refers to: Android's desktop-windowing mode, a distinct internal build, or something broader. None of that gets resolved in the source, so consumer availability should be treated as unverified rather than assumed, both at the time of the commit and today.

That gap matters for anyone deciding whether to build against this now rather than just read about it. A commit landing in the Chromium source tree isn't the same thing as a feature reaching a stable release on a phone someone actually owns. Before treating this as a foundation, developers should run their own verification checklist, independent of anything the commit itself states: confirm which channel the code has reached, check whether it's active there by default, and test whether "desktop Android" maps to anything available on retail hardware. The cited commit answers none of these questions, and nothing in the supplied research points toward Canary, Dev, Beta, or Stable specifically.

A useful milestone to watch for is a follow-up commit enabling chrome.tabs.group() on the same named surface. That would resolve the sequencing question raised above and mark one point, though not necessarily the only one, where this API becomes usable for actual group-management extensions. Nothing in the December 2025 commit indicates whether or when that happens.

Conclusion

This commit is a specific, documented engineering step, not proof that Google deprioritizes Android extension support broadly; the record here simply doesn't establish deprioritization one way or the other. What it does establish is a precise gap: as of December 2025, chrome.tabGroups.get() works on a surface named "desktop Android," while confirmed consumer availability, a clear answer on what that surface covers, and a working chrome.tabs.group() all remain outstanding. Developers building tab-group tools should treat that gap as the current baseline, verify it directly against whatever channel and device they're targeting, and watch for a follow-up commit on the write side before assuming this API is ready for anything beyond read-only display.