Title
[Android] Add integration tests for SystemUiMode transitions
Body
Use case
The PlatformPluginTest unit tests are Mockito-based — they verify which APIs are called on a mocked Window/View, but they cannot observe residual decorView state that bleeds across mode switches. This is exactly the gap that allowed #186723 to ship: switching immersiveSticky → edgeToEdge left FLAG_FULLSCREEN/FLAG_HIDE_NAVIGATION set on the decor view from the prior mode, but no unit test could see that because each test instantiated a fresh mock.
We should add Android instrumentation/integration tests that exercise the full transition matrix between SystemUiMode values and assert the resulting window insets / system-bar visibility on a real (or emulated) device.
Proposal
Add a new entrypoint under dev/integration_tests/android_engine_test/ (which already uses SystemChrome.setEnabledSystemUIMode) that drives the following matrix:
|
→ leanBack |
→ immersive |
→ immersiveSticky |
→ edgeToEdge |
→ manual |
| leanBack |
✓ |
✓ |
✓ |
✓ |
✓ |
| immersive |
✓ |
✓ |
✓ |
✓ |
✓ |
| immersiveSticky |
✓ |
✓ |
✓ |
✓ |
✓ |
| edgeToEdge |
✓ |
✓ |
✓ |
✓ |
✓ |
| manual |
✓ |
✓ |
✓ |
✓ |
✓ |
For each cell, after applying mode A then mode B, assert the expected post-state on the host side, e.g.:
edgeToEdge: WindowInsetsCompat.Type.systemBars() is visible; window does not fit system windows.immersive/immersiveSticky/leanBack: status + nav bars hidden.manual: only the requested overlays are visible.
These checks can be implemented on the Android side via an instrumentation test that reads WindowInsetsCompat and View.getSystemUiVisibility() after each transition completes.
Coverage targets
- API 29 (lowest e2e-supported SDK; uses the older
setSystemUiVisibility(0) clear path)
- API 30+ (would use the modern
WindowInsetsControllerCompat.show() path if PR #187207 adopts it)
- API 35/36 with
targetSdk at 35/36 (default e2e enforcement; legacy modes are ignored by the OS)
Why now
Two e2e-related changes in quick succession (#183072, #187207) and one P1 regression (#186723) indicate this code path is both fragile and under-tested at the integration level. Per #133074, the remaining modes (leanBack/immersive/immersiveSticky) will also eventually be migrated off deprecated View flags — having a transition-matrix test in place beforehand would catch the same class of bug for those migrations too.
Related
Labels (suggested)
platform-android, team-android, engine, c: tests, P2
Title
[Android] Add integration tests for
SystemUiModetransitionsBody
Use case
The
PlatformPluginTestunit tests are Mockito-based — they verify which APIs are called on a mockedWindow/View, but they cannot observe residualdecorViewstate that bleeds across mode switches. This is exactly the gap that allowed #186723 to ship: switchingimmersiveSticky → edgeToEdgeleftFLAG_FULLSCREEN/FLAG_HIDE_NAVIGATIONset on the decor view from the prior mode, but no unit test could see that because each test instantiated a fresh mock.We should add Android instrumentation/integration tests that exercise the full transition matrix between
SystemUiModevalues and assert the resulting window insets / system-bar visibility on a real (or emulated) device.Proposal
Add a new entrypoint under
dev/integration_tests/android_engine_test/(which already usesSystemChrome.setEnabledSystemUIMode) that drives the following matrix:For each cell, after applying mode A then mode B, assert the expected post-state on the host side, e.g.:
edgeToEdge:WindowInsetsCompat.Type.systemBars()is visible; window does not fit system windows.immersive/immersiveSticky/leanBack: status + nav bars hidden.manual: only the requested overlays are visible.These checks can be implemented on the Android side via an instrumentation test that reads
WindowInsetsCompatandView.getSystemUiVisibility()after each transition completes.Coverage targets
setSystemUiVisibility(0)clear path)WindowInsetsControllerCompat.show()path if PR #187207 adopts it)targetSdkat 35/36 (default e2e enforcement; legacy modes are ignored by the OS)Why now
Two e2e-related changes in quick succession (#183072, #187207) and one P1 regression (#186723) indicate this code path is both fragile and under-tested at the integration level. Per #133074, the remaining modes (
leanBack/immersive/immersiveSticky) will also eventually be migrated off deprecatedViewflags — having a transition-matrix test in place beforehand would catch the same class of bug for those migrations too.Related
immersiveStickytoedgeToEdgein Flutter 3.44.0 #186723Viewflag migration: Change inset handling from deprecatedSYSTEM_UI...flags toWindowInsetsController#133074, Fix Android Engine Deprecations #98602Labels (suggested)
platform-android,team-android,engine,c: tests,P2