Fix nullable float props crashing ViewManagers on Android

[dennytosp]

Summary:

Fixes#55350.

A codegen'd Fabric component that declares an optional float prop:

typeNativeProps=Readonly<{
...ViewProps,testFloatNullable?: WithDefault<CodegenTypes.Float,null>,}>;

crashes the app at startup as soon as the ViewManager implements it with a @ReactProp annotation:

java.lang.RuntimeException: Unrecognized type: class java.lang.Float
for method: MyNativeViewManager#setTestFloatNullable
at ViewManagersPropertyCache.createPropSetter(...)
at ViewManagerPropertyUpdater$FallbackViewManagerSetter.<init>(...)
at ViewManager.getNativeProps(...)

WithDefault<Float, null> is the only way to express a genuinely nullable float in a codegen spec — a plain optional CodegenTypes.Float is emitted as a primitive float defaulting to 0f. So codegen generates a @Nullable Float setter in the ViewManager interface, and then the runtime refuses to bind it.

Root cause

GeneratePropsJavaInterface emits exactly four boxed (nullable) prop types:

Codegen type annotation	Emitted Java type	Handled by ViewManagersPropertyCache
BooleanTypeAnnotation with default: null	@Nullable Boolean	BoxedBooleanPropSetter
ReservedPropTypeAnnotation / ColorPrimitive	@Nullable Integer	BoxedColorPropSetter
Int32EnumTypeAnnotation	@Nullable Integer	BoxedIntPropSetter
FloatTypeAnnotation with default: null	@Nullable Float	nothing — falls through to else

createPropSetter maps java.lang.Boolean and java.lang.Integer, but has no branch for java.lang.Float, so it hits the else and throws. This adds the missing BoxedFloatPropSetter, mirroring BoxedIntPropSetter: unbox Double (all JS numbers arrive as Double) to Float, and pass null straight through so the setter actually receives the absent value.

DoubleTypeAnnotation is deliberately not covered — codegen always emits it as a primitive double, never boxed, so there is no nullable-double setter to bind.

Note this only affects ViewManagers that use @ReactProp. A codegen'd ViewManager that routes props through its generated delegate never reaches ViewManagersPropertyCache, which is why the crash looks intermittent — the annotation is what pulls in FallbackViewManagerSetter.

Changelog:

[ANDROID] [FIXED] - Fix RuntimeException: Unrecognized type: class java.lang.Float when a ViewManager implements a nullable float prop (WithDefault<Float, null>) with @ReactProp

Test Plan:

Added testBoxedFloatSetter to ReactPropAnnotationSetterTest, alongside the existing testBoxedBooleanSetter / testBoxedIntSetter, plus a boxedFloatProp on the ViewManager under test. It drives viewManager.updateProperties(...), which is the same FallbackViewManagerSetter → getNativePropSettersForViewManagerClass → createPropSetter path as the crash stack trace, and asserts the setter receives 3.5f, -7.0f and null.

$ ./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest \
--tests "com.facebook.react.uimanager.ReactPropAnnotationSetterTest"
BUILD SUCCESSFUL in 3m 16s
tests=18 failures=0 errors=0 skipped=0
ok testBoxedBooleanSetter
ok testBoxedFloatSetter <- new
ok testBoxedIntSetter
ok testFloatSetter
... (18/18)

Reverting only ViewManagersPropertyCache.kt and keeping the new test reproduces the reported crash verbatim:

tests=18 failures=18 errors=0
java.lang.RuntimeException: Unrecognized type: class java.lang.Float
for method: ReactPropAnnotationSetterTest$ViewManagerUnderTest#setBoxedFloatProp

All 18 fail rather than just the new one, and that is the bug's real shape:
getNativePropSettersForViewManagerClass builds the setter map for the entire
ViewManager class in one pass and caches it, so a single unbindable prop takes
down every other prop on that manager. That is why the reported crash happens at
startup, while getNativeProps() is collecting view manager constants, rather
than when the offending prop is first set.

Kotlin formatting:

$ ./gradlew ktfmtCheck
BUILD SUCCESSFUL

ViewManagersPropertyCache is an internal object and BoxedFloatPropSetter is
a private class, so ReactAndroid.api is unchanged.

[meta-codesync]

@javache has imported this pull request. If you are a Meta employee, you can view this in D116928062.

[meta-codesync]

@javache merged this pull request in 8d23b14.