You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As part of the edge-to-edge work for #5943 and #5940, we need to draw a protection background behind the system bars (status bar and, in landscape, the navigation bar) so that toolbar and content colours stay visually continuous when the app targets Android 15 (API 35) and later.
The app currently depends on androidx.core:core:1.0.1 (resolved to 1.7.0 via Maven conflict resolution see third_party/versions.bzl and third_party/maven_install.json). This version does not include androidx.core.view.insets.ProtectionLayout, which is the canonical AndroidX primitive for drawing system-bar protections in an edge-to-edge layout. ProtectionLayout was added in androidx.core:core:1.16.0.
As a result, the current edge-to-edge implementation (behind the EnableEdgeToEdge platform parameter) uses a manual approach: a programmatically-inserted spacer View above the toolbar sized by an OnApplyWindowInsetsListener, combined with a walk-up of the view hierarchy to disable fitsSystemWindows on any AppCompat-inserted ancestor (FitWindowsLinearLayout). This works, but it reimplements functionality that ProtectionLayout now provides natively, and does not get the benefit of future AndroidX improvements.
Describe the solution you'd like
Upgrade androidx.core:core and androidx.core:core-ktx to 1.16.0 (or later stable) and swap the internals of EdgeToEdgeHelper over to use ProtectionLayout and GradientProtection.
Because the entire edge-to-edge implementation is funnelled through a single utility object (EdgeToEdgeHelper), this migration is a one-file change: no presenters need to be touched. Every screen that calls the helper will automatically pick up the ProtectionLayout-based implementation.
Pin a newer androidx.core version via maven_install overrides without a formal upgrade. This risks pulling in transitive API changes that the rest of the codebase isn't prepared for, and would still be blocked by the same Bazel/maven dependency-management constraints as a full upgrade. Not sure about this just an idea.
Additional context
This upgrade is expected to require the Bazel 7 migration (#6021 and #6233) to land first, since many newer androidx.core releases depend on Maven infrastructure that older Bazel setups struggle with. See the discussion on #6214 for context @BenHenning confirmed that a batch of version upgrades will likely be straightforward once the Bazel 7 migration lands.
The edge-to-edge work in #5940 / #5943 is being landed first behind a feature flag, with the helper architecture designed so that swapping to ProtectionLayout in a future PR is an isolated, low-risk change. Once this upgrade lands, a follow-up PR can update EdgeToEdgeHelper internals without touching any presenter or layout. Or we can completely scrape these PR's and work on a completey new one with the suggested by the docs.
Is your feature request related to a problem? Please describe.
As part of the edge-to-edge work for #5943 and #5940, we need to draw a protection background behind the system bars (status bar and, in landscape, the navigation bar) so that toolbar and content colours stay visually continuous when the app targets Android 15 (API 35) and later.
The app currently depends on
androidx.core:core:1.0.1(resolved to1.7.0via Maven conflict resolution seethird_party/versions.bzlandthird_party/maven_install.json). This version does not includeandroidx.core.view.insets.ProtectionLayout, which is the canonical AndroidX primitive for drawing system-bar protections in an edge-to-edge layout.ProtectionLayoutwas added inandroidx.core:core:1.16.0.As a result, the current edge-to-edge implementation (behind the
EnableEdgeToEdgeplatform parameter) uses a manual approach: a programmatically-inserted spacerViewabove the toolbar sized by anOnApplyWindowInsetsListener, combined with a walk-up of the view hierarchy to disablefitsSystemWindowson any AppCompat-inserted ancestor (FitWindowsLinearLayout). This works, but it reimplements functionality thatProtectionLayoutnow provides natively, and does not get the benefit of future AndroidX improvements.Describe the solution you'd like
Upgrade
androidx.core:coreandandroidx.core:core-ktxto1.16.0(or later stable) and swap the internals ofEdgeToEdgeHelperover to useProtectionLayoutandGradientProtection.Because the entire edge-to-edge implementation is funnelled through a single utility object (
EdgeToEdgeHelper), this migration is a one-file change: no presenters need to be touched. Every screen that calls the helper will automatically pick up theProtectionLayout-based implementation.Describe alternatives you've considered
EnableEdgeToEdgefeature flag. Fix part of #5940: Add edge-to-edge insets to toolbar-hosted screens #6214androidx.coreversion viamaven_installoverrides without a formal upgrade. This risks pulling in transitive API changes that the rest of the codebase isn't prepared for, and would still be blocked by the same Bazel/maven dependency-management constraints as a full upgrade. Not sure about this just an idea.Additional context
This upgrade is expected to require the Bazel 7 migration (#6021 and #6233) to land first, since many newer
androidx.corereleases depend on Maven infrastructure that older Bazel setups struggle with. See the discussion on #6214 for context @BenHenning confirmed that a batch of version upgrades will likely be straightforward once the Bazel 7 migration lands.The edge-to-edge work in #5940 / #5943 is being landed first behind a feature flag, with the helper architecture designed so that swapping to
ProtectionLayoutin a future PR is an isolated, low-risk change. Once this upgrade lands, a follow-up PR can updateEdgeToEdgeHelperinternals without touching any presenter or layout. Or we can completely scrape these PR's and work on a completey new one with the suggested by the docs.