Repository navigation
android: make the overlay bar actually overlay something (#1836) - #1838
Merged
Merged
Conversation
#1837 shipped a toggle that changed nothing on screen, and the reason was a logic error I described as a follow-up instead of recognising as the mechanism. Moving the bar out of the Scaffold slot is not enough on its own. A screen's backdrop is painted INSIDE the screen, and the overlay path still inset the NavHost by the bar height — so the screen, and its backdrop with it, still stopped exactly where it did before. The bar floated over a strip of the shell's container colour rather than over anything, which is why enabling the setting looked identical and left a black band around the bar. The screen now reaches the bottom edge (NavHost bottom inset is zero in the overlay path) so its full-bleed backdrop paints behind AND around the glass, and ScreenScaffold adds the bar's height to the scrolling CONTENT's bottom padding instead. Because that padding sits inside the scroll viewport, content passes under the bar as you scroll and the last row still comes to rest clear of it. Doing it in ScreenScaffold is what makes this one change rather than four: every top-level screen routes through it — Today, Trends, Sleep, Coupled and More — so none needed touching. Today's other verticalScroll is a bounded editor list, not the page. The measured height rides on BottomBarStyleStore, mirroring BackgroundImageStore, and barHeightForContent() returns zero unless the overlay is on, so a caller cannot inset content in the slot layout where the Scaffold has already reserved that space. Kotlin: full suite 5089/0; compile and doc-comment gate clean. Still needs a device — but unlike the first version there is now something to look at.
Re-review catch. Routing the inset through ScreenScaffold covers every top-level screen, which is why it is one change rather than four — but it only covers screens that USE it. Auditing every screen that scrolls without it turned up eight files. Seven are not NavHost destinations, or are sheets: UpdatesInboxScreen renders inside a ModalBottomSheet, which is its own window above the bar. StepsCalibrationScreen is the exception - a real destination, scrolling on its own Column. In the overlay layout that screen reaches the bottom edge like any other, so without clearance its last rows sit behind the bar. Zero when the overlay is off, so the slot layout is untouched. The comment there names the general rule, since the next screen added outside ScreenScaffold will need the same and nothing enforces it. Kotlin: full suite 5089/0; compile and doc-comment gate clean.
ryanbr
added a commit
that referenced
this pull request
Sep 3, 2026
versionCode 420 -> 421, CURRENT_PROJECT_VERSION 301 -> 302. Version stays 11.1.1. 421 is the first build where the overlay bottom bar does anything. In 420 the toggle was inert - the bar moved out of the Scaffold slot but the screen was still inset above it, so the backdrop stopped where it always had. #1838 lets the screen reach the bottom edge and clears the bar from the scrolling content instead. Settings > Appearance > Bottom bar overlay, still default OFF. With it on, the background should continue around and behind the bar and content should pass beneath the glass while scrolling.
This was referenced Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1837, which shipped a toggle that changed nothing on screen. Reported straight away:
"I don't see a difference when I enabled bottom bar overlay." Correct, and the reason is a logic error of
mine.
Why the first version was inert
Moving the bar out of the
Scaffoldslot is not enough on its own. A screen's backdrop(
LiquidScreenSky/BackgroundImageBackdrop) is painted inside the screen, and the overlay pathstill inset the
NavHostby the bar height — so the screen, and its backdrop with it, stopped exactlywhere it did before.
The bar floated over a strip of the shell's
containerColor, not over anything. Hence: identical layout,and a black band around the bar where the mosaic background should have continued.
I wrote the missing half in #1837's own description as a nice-to-have follow-up:
That was not a follow-up. It was the mechanism, and calling it optional is what let an inert change ship
behind a switch that promised something.
What this does
NavHost's bottom inset is zero in the overlay path, so ascreen's full-bleed backdrop paints behind and around the glass.
ScreenScaffoldclears the bar from the CONTENT. The bar's height is added to the scrolling column'sbottom padding. Because that padding sits inside the scroll viewport, content passes under the bar as
you scroll and the last row still comes to rest clear of it.
That distinction — layout reaches the edge, content clears the bar — is the whole overlay.
One change, not four
Every top-level screen routes through
ScreenScaffold: Today, Trends, Sleep, Coupled and More. So none ofthem needed touching, and a screen added later inherits it. Checked rather than assumed — Today's other
verticalScrollis a bounded editor list, not the page scroll.The measured height rides on
BottomBarStyleStore, mirroringBackgroundImageStore, andbarHeightForContent()returns zero unless the overlay is on — so a caller cannot inset content in theslot layout, where the Scaffold has already reserved that space.
Unchanged
Still behind Settings → Appearance → Bottom bar overlay, default off. The off-path remains the shipped
slot layout.
Verification
compileFullDebugKotlinclean, full Android suite 5089 tests, 0 failures, doc-comment gate clean.Still needs a device — but unlike the first version there is now something to look at: the background
should continue around and behind the bar, and content should pass beneath the glass while scrolling.