Symptoms (found on-device: Huawei Mate 10 Pro, API 29)
On the main screen, the bottom section (View Battery Insights button + developer signature) takes up
almost a third of the screen with a large empty margin below it, and it overlaps/pushes the
battery details table so that the table's lower rows are hidden and cannot be scrolled into view.
Root cause
- The details table isn't scrollable.
fragment_battery_details.xml is a bare TableLayout inside a FrameLayout — no ScrollView. In activity_main.xml it sits in a weighted (height=0dp, weight=1) slot, so when the gauge + footer are tall the remaining rows are simply clipped with no way to scroll.
- The footer has a hardcoded 64dp bottom padding.
content_navigation_bar_padding is 64dp (dimens.xml); on a non-edge-to-edge device (API < 35) the system already insets content above the navigation bar, so this 64dp is pure extra empty space — the "large margin below".
Proposed fix
- Wrap the
TableLayout in a ScrollView so the details always scroll instead of clipping.
- Reduce
content_navigation_bar_padding from 64dp to a sensible content margin (~16dp). (Also used by activity_battery_insights.xml, which is already a scroll container.)
Acceptance criteria
Follow-up (not in scope)
Proper edge-to-edge bottom-inset handling on the main/insights screens (via
BaseActivity.applyBottomSystemBarInset, as Settings already does) so API 35+ devices clear the
navigation bar dynamically rather than relying on a fixed dimension.
Found during on-device testing of #68.
Symptoms (found on-device: Huawei Mate 10 Pro, API 29)
On the main screen, the bottom section (View Battery Insights button + developer signature) takes up
almost a third of the screen with a large empty margin below it, and it overlaps/pushes the
battery details table so that the table's lower rows are hidden and cannot be scrolled into view.
Root cause
fragment_battery_details.xmlis a bareTableLayoutinside aFrameLayout— noScrollView. Inactivity_main.xmlit sits in a weighted (height=0dp, weight=1) slot, so when the gauge + footer are tall the remaining rows are simply clipped with no way to scroll.content_navigation_bar_paddingis64dp(dimens.xml); on a non-edge-to-edge device (API < 35) the system already insets content above the navigation bar, so this 64dp is pure extra empty space — the "large margin below".Proposed fix
TableLayoutin aScrollViewso the details always scroll instead of clipping.content_navigation_bar_paddingfrom64dpto a sensible content margin (~16dp). (Also used byactivity_battery_insights.xml, which is already a scroll container.)Acceptance criteria
Follow-up (not in scope)
Proper edge-to-edge bottom-inset handling on the main/insights screens (via
BaseActivity.applyBottomSystemBarInset, as Settings already does) so API 35+ devices clear thenavigation bar dynamically rather than relying on a fixed dimension.
Found during on-device testing of #68.