fix(native): seed a concrete scheme-aware Android __rn-css-color

[YevheniiKotyrlo]

Summary

On Android, every color that resolves through the root __rn-css-color fallback renders nothing — default ring-* / inset-ring-* (Tailwind v4's default ring color is currentcolor), text-current, and bg-current are all invisible. iOS is fine.

The root seed in src/native-internal/root.ts:

rootVariables("__rn-css-color").set([[
  Platform.OS === "ios"
    ? PlatformColor("label", "labelColor")
    : PlatformColor("?attr/textColorPrimary", "SystemBaseHighColor"),
]] as any);

On Android PlatformColor('?attr/textColorPrimary') resolves through React Native's ColorPropConverter.resolveThemeAttribute, which returns outValue.data without inspecting outValue.type:

if (theme.resolveAttribute(resourceId, outValue, true)) {
  return outValue.data
}

?attr/textColorPrimary is a ColorStateList on AppCompat / Material themes, so Theme.resolveAttribute fills outValue with a resource reference (TYPE_REFERENCE), not a packed color — and outValue.data is then that reference id, used as if it were an ARGB int. The paint is a garbage, effectively-invisible color. The fallback 'SystemBaseHighColor' has no @ / ? prefix, so it isn't a valid resource path and is silently skipped. Net effect on device: no exception, no paint — verified on an Android emulator, where re-seeding __rn-css-color with #FF00FF made the rings and text-current render magenta, proving the resolution machinery is correct and only the seed value was wrong.

Fix

Seed a concrete color on Android, made scheme-aware through the root observable's existing prefers-color-scheme evaluation — no new Appearance listener, and it drops the as any + two eslint suppressions:

if (Platform.OS === "ios") {
  rootVariables("__rn-css-color").set([
    [PlatformColor("label", "labelColor") as unknown as StyleDescriptor],
  ]);
} else {
  rootVariables("__rn-css-color").set([
    ["#FFFFFF", [["=", "prefers-color-scheme", "dark"]]],
    ["#000000"],
  ]);
}

The root variable is only the ultimate fallback (any ancestor-published or themed --__rn-css-color overrides it), so a binary black/white default is spec-faithful — CSS's initial color is effectively canvastext. iOS keeps PlatformColor('label'), a first-class dynamic color that already tracks the system appearance.

Why the media-query form: the root observable already evaluates each seeded value's media query against the reactive colorScheme observable (native/conditions/media-query.ts), so [["#FFFFFF", darkMQ], ["#000000"]] is scheme-reactive for free — the same mechanism light-dark() and prefers-color-scheme rules use — rather than a second imperative Appearance subscription.

Test plan

src/__tests__/native/root-color-seed-android.test.tsx (Platform.OS mocked to android — the seed is a module-load side effect and jest-expo defaults to ios):

• currentcolor with no ancestor → #000000 (light) / #FFFFFF (dark).
• Live reactivity: act(() => colorScheme.set("dark")) re-resolves the same element.
• A default ring and inset-ring (box-shadow currentcolor) paint with the seed color — the reported symptom.
• No color-scheme preference (null) falls back to the light default.
• An ancestor-published color still overrides the seed (it is only the ultimate fallback).

src/__tests__/native/root-color-seed.test.ios.tsx:

• iOS keeps PlatformColor('label'); ancestor override still works.

src/__tests__/native/root-color-seed-override.test.tsx:

• A stylesheet :root { color } replaces the seed outright, and a scheme-conditioned one overrides it per scheme. This is what makes a hardcoded black/white defensible, and the other files only ever tested an ancestor element. Its own file because inject replaces a root variable outright and nothing puts it back between tests, so a :root { color } leaks into every later test in the same file.

src/__tests__/vendor/tailwind/ring-color-seed.test.tsx (real Tailwind → the runtime, android):

• ring-2 / ring — whose default color is currentcolor — paint the concrete seed (#000000 light, #FFFFFF dark); an explicit ring-red-500 still wins. This exercises the reported symptom through actual Tailwind output, not a hand-written box-shadow.

Verified red→green: pre-fix, the Android tests resolve to { semantic: ["?attr/textColorPrimary", "SystemBaseHighColor"] }; post-fix, concrete colors.

To be precise about what that proves and what it does not: jest-expo's haste defaultPlatform is ios, so PlatformColorValueTypes always resolves its .ios.js variant even with Platform.OS mocked to android. The tests therefore observe the unresolved descriptor rather than Android's {resource_paths: […]} shape, and they are guards on the seed value rather than on the native resolution. The native side is what the emulator run above covers.

Why black and white, rather than another theme attribute

The failure is specific to the ?attr/ path returning outValue.data unchecked. @-prefixed resources go through ResourcesCompat.getColor, which flattens a ColorStateList correctly, and a theme attribute whose value is a plain <color> resolves to TYPE_INT_COLOR_* where data really is ARGB. So ?attr/colorForeground — which points at foreground_material_light|dark in AppCompat and Material — would plausibly work and would keep the platform's real foreground across DayNight and custom brand themes, instead of collapsing every theme to pure black or white.

I chose the concrete pair because it is what CSS Color 4 specifies for the initial color (CanvasText), because prefers-color-scheme is the only signal the runtime has, and because it matches how light-dark() already compiles in this repo. But if you would rather keep a platform attribute here, colorForeground is the candidate and I am happy to switch — it needs a device check I have not run.

yarn test, yarn typecheck, yarn eslint, and prettier --check all pass. (Two babel/ import-plugin suites fail only on Windows — a pre-existing path-separator bug in the plugin, unrelated to this change; they are green on CI.)

Follow-up (separate, facebook/react-native)

The deeper RN-layer bug — ColorPropConverter.resolveThemeAttribute returning outValue.data unchecked for ColorStateList attributes (a reference, not a color) — affects any PlatformColor('?attr/<ColorStateList>') usage and is worth a separate issue in react-native itself.

References

• React Native — ColorPropConverter.resolveThemeAttribute returns outValue.data without checking outValue.type (Kotlin source, commit-pinned) · PlatformColor
• Android — ?attr/textColorPrimary is a themed ColorStateList in AppCompat / Material components, which is why the returned outValue.data is a reference, not a color.
• react-native-css — the reactive mechanism reused: the root observable evaluates each seeded value's media query against the colorScheme observable (native/conditions/media-query.ts — prefers-color-scheme → get(colorScheme)), so a media-query-conditioned seed is scheme-reactive with no extra listener.

Overlaps with #410

Both edit the same twelve lines of src/native-internal/root.ts — this one changes the seed, #410 puts the registries behind one globalThis key. They are independent defects with different blast radii, so I have kept them apart; whichever lands first, I will rebase the other onto the composed body.

One thing worth knowing before both land, because neither branch's tests can see it. observable.set() evaluates its read function immediately, so a media-conditioned seed calls testMediaQuery → get(colorScheme) during root.ts's module body. On main that never happens, because the seed carries no media query. Under #410 the registry becomes process-global while colorScheme in src/native/reactivity.ts does not, so the shared seed binds to whichever module copy evaluated first. Measured with jest.resetModules(): the composed pair answers #000000 after a second copy sets dark, where this branch alone answers #FFFFFF.

That is #410's class of bug rather than this one's — any @media (prefers-color-scheme: dark) { :root { --x } } in user CSS already hits it under #410 — but this change makes it reachable in every Android app rather than only in stylesheets that happen to use a conditioned root variable. The real fix is to guard reactivity.ts's process-global observables the way style-collection.ts and variables.tsx already are. Happy to send that first if you would prefer it ahead of either.