Repository navigation
fix(core): appearance APIs before app start, replaceable Android handlers, explicit systemAppearanceChanged() - #11537
Merged
Merged
Conversation
Application.systemAppearance(), orientation() and layoutDirection() threw on Android until Application.run() had initialized the module, because they read the configuration from Application.android.context, which is only set then. Code that reads the appearance while it loads, such as a theme module imported by the app's entry, could not use them. They now read the configuration from the native application when the context is not set yet. The app's code runs from the native application's onCreate, so it exists by then.
…lues Utils.android.setDarkModeHandler() kept the first handler it was given and ignored later ones, and setStatusBarColor() and setNavigationBarColor() never changed a color at all: they assigned with `??=` onto settings that always start with default colors. All three also stored the settings under the current activity rather than the one passed in, so refreshEdgeToEdge() on that activity lost them. The setters now replace the handler and the colors they are given, keep the colors they are not, and store the settings under the activity they were given.
This was referenced Oct 15, 2026
Open
|
View your CI Pipeline Execution ↗ for commit 4316bbf
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
commit: |
…e off Application.systemAppearanceChanged(rootView, appearance) did nothing while setAutoSystemAppearanceChanged(false) was in effect, so an app that turned off automatic changes to choose its own appearance had to turn them back on around each call. The flag now gates only the automatic path, where the system's appearance changes; the event still fires there. An explicit call to systemAppearanceChanged() applies the classes.
triniwiz
force-pushed
the
fix/appearance-apis
branch
from
October 15, 2026 13:27
ea689c9 to
447ce6c
Compare
NathanWalker
approved these changes
Oct 23, 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.
PR Checklist
What is the current behavior?
Application.systemAppearance(),orientation()andlayoutDirection()throw untilApplication.run()has initialized the module, because they read the configuration fromApplication.android.context. A theme module imported by the app's entry cannot read the appearance.Utils.android.setDarkModeHandler()keeps the first handler it is given and ignores later ones.setStatusBarColor()andsetNavigationBarColor()never change a color: they assign with??=onto settings that always start with default colors. All three store the settings under the current activity rather than the one passed in, sorefreshEdgeToEdge()on that activity loses them.Application.systemAppearanceChanged(rootView, appearance)does nothing whilesetAutoSystemAppearanceChanged(false)is in effect, so an app that turned automatic changes off to choose its own appearance has to turn them back on around each call.What is the new behavior?
onCreate, so it exists by then.autoSystemAppearanceChangedgates only the automatic path, where the system's appearance changes. The event still fires there. An explicitsystemAppearanceChanged()call applies the classes.Tests:
application/system-appearance.spec.ts(4) andutils/edge-to-edge.android.spec.ts(3).Verified with all of these core PRs merged together (#11527–#11537):
apps/automatedpasses on the iOS 26.4 simulator (1830 OK, 0 failed) and on an Android API 36 emulator (1692 OK; the one failure is the network-dependentIMAGE-CACHE.test_ImageCache_ValidUrltimeout, which also passes on reruns).