Conversation
ApprovabilityVerdict: Not approved Macroscope's review found this PR not approvable — This PR changes production Android framing and pane geometry across the workspace and many settings-related routes, including a new shared header/content abstraction. Its behavior is limited to the existing opt-in Material You Layout mode, but the cross-cutting runtime impact is broader than a small isolated UI fix. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (19)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughChangesMaterial You mobile layout
Priority: ➖ Normal Estimated code review effort: 4 (Complex) | ~45 minutes Change: Bug fix Sequence Diagram(s)sequenceDiagram
participant SettingsRouteScreen
participant SettingsScreen
participant AndroidScreenHeader
participant SettingsScreenContent
SettingsRouteScreen->>SettingsScreen: render settings content and header props
SettingsScreen->>AndroidScreenHeader: render shared Android header
SettingsScreen->>SettingsScreenContent: render Material You framed content
Possibly related PRs
Suggested reviewers: Merge Risk: ⚪ Minimal · up to No merge-blocking behavior regression was identified in the Material You framing changes. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Ah yeah the highlight doesn't quite look right. I'll try to iterate on that @juliusmarminge As for the option--I also prefer it, but I originally kept it as a toggle for a couple reasons:
I'm totally for switching over or at least setting it as default for new users? Gather bug reports? |
Yea sounds like a good first step |
|
I'm actually looking closer at some of the apps I used for comparison and it turns out I was entirely wrong on the sidebar and detail using the same header surface color across a handful of system and Google apps However, no, those are all different colors in most apps. I'll have my agent reply with some examples of other apps. |
|
@juliusmarminge Following up with current Android 17 references. The apps don't use one uniform surface or selection rule:
So distinct pane colors aren't inherently wrong, but these references don't justify accidental seams or inconsistent spacing. The selected-thread shape is a separate choice from the pane surfaces. These are original, unedited emulator captures at 2076 × 2152, 390 dpi, with updated Google apps. Both palettes were applied through Settings → Wallpaper & style → Home screen → Colors: blue wallpaper colors, then pink from Other colors. Each app was captured with Android's light and dark modes. The fixture set contains 8 fictional local contacts, 17 SMS messages, and 6 call-history entries. Nothing was sent or dialed. These are SMS, not RCS; they don't establish an RCS color-token mapping. Messages — populated SMS; first row selected — blue and pink, light and darkMessages uses an inset, fully rounded selection, including the first conversation. The list and conversation canvas use different surfaces.
Phone — selected call history — blue and pink, light and darkPhone uses a navigation rail, call list, and detail pane with distinct surfaces. Its selected first call follows the grouped cell shape: rounded top corners, much squarer bottom corners.
Settings — two-pane network page — blue and pink, light and darkSettings uses different pane surfaces, an outlined pill-shaped search field, and grouped list cells.
Messages — before population — blue and pink, light and darkThe empty state was captured before adding the fictional SMS conversations.
Contacts — populated list — blue and pink, light and darkContacts uses a navigation rail and a full-width grouped list here. Opening a contact replaces the list rather than keeping a persistent list/detail split.
Clock — world cities — blue and pink, light and darkClock uses a wide two-column card layout, not master-detail. It stays dark in both system modes in this build.
Extra checks — second Messages row selected; Contacts detailThe second Messages row gets the same fully rounded inset selection as the first. Contacts detail opens full-width at this configuration.
Versions and emulator caveats
Reference capture and verification by the Codex agent in T3 Code. No application-code changes in this reference pass. |
|
Of course why would android be consistent 🙃🙃🙃 For real trusting your judgement here more than mine on how we should have our layout... I'll need to think about the iPhone Duo layout as well in the coming weeks so if i don't have to think about android design systems thats just a bonus :) |
|
Thinking about hiding the search bar into a secondary FAB or moving the filter to the secondary FAB so the search can be part of the main toolbar row especially on foldable. I think I need a variant comparison skill :) Having the search bar hidden on the two column layout would help clean up the layout and align the baselines of each pane. I think the offset of the search bar width will make more sense if it's replacing the toolbar rather than making it larger |
|
Leaving this in case the iPad layout is of interest: https://github.com/user-attachments/assets/40fa18b6-03c3-4a33-9b24-f8e791ab9b63 |
|
I actually use the iPad app a decent amount and have a couple PRs open addressing some multi window bugs The idea I'm having would diverge slightly from the IOS layout |
|
Five local app variants, captured on Android 17 with disposable data. No code pushed.
All FABs are rounded squares. A–D use an 80dp Compose button and 56dp secondary buttons where present. E uses 56dp for both buttons, with an extended New thread label. Stacked buttons share a right edge and an 8dp gap. Material You Layout is on throughout. Typecheck and changed-file lint passed in all five worktrees. Implementation and captures: Codex in T3 Code. |
|
I don't really use search that much, the reason i have it always available on iOS is cause the toolbar is something a lot of Apple apps use, so I'm fine collapsing it to a button on android |











































































What Changed
Why
Material You Layout already styles the folded thread list and chat, but the unfolded sidebar still uses different header spacing and surfaces. Settings also bypasses the rounded detail frame. This is a focused parity fix on top of the merged theme work in #10691 and #10692, not a revival of the broader redesign in #6081. The header/action behavior from #5385 stays intact.
The header token is made opaque only while Material You Layout is enabled; wallpaper colors still supply their own header surface. iOS and non-Material layout paths retain their existing framing. No palette inspector, screenshot assets, server changes, or new settings are included.
UI Changes
Same Pixel 9 Pro Fold emulator, disposable Showcase Studio data, Material You Layout enabled, and matching theme/mode for each pair. Left is before; right is after. Before captures use
6dbea7ed09, whose mobile sources are identical to the pinned main baseb5b29e7b8b; after captures use8af949faf1.Default T3 Code — light
Default T3 Code — dark
Iris — light
Iris — dark
System wallpaper colors — light
System wallpaper colors — dark
Folded list — default light (preserved layout)
Verification
mobileThemeVariables,materialYouTheme,mobileTheme,mobileThemeRuntime, andappearancePreferencesChecklist
Model: GPT-6 Astra & Fable 5.1 | Harness: Codex & Claude Code in T3 Code
Summary by CodeRabbit
New Features
Bug Fixes
Tests