Skip to content

fix(android): log missing generated setter at debug level, not warn - #58854

Open
franruiztech wants to merge 1 commit into
react:mainfrom
franruiztech:fix/android-generated-setter-warning
Open

franruiztech wants to merge 1 commit into
react:mainfrom
franruiztech:fix/android-generated-setter-warning

Conversation

@franruiztech

@franruiztech franruiztech commented Oct 5, 2026 •

Copy link
Copy Markdown

Summary:

ViewManagerPropertyUpdater.findGeneratedSetter looks up a <class>$$PropsSetter class by reflection and, when it does not exist, logs Could not find generated setter for class ... at warn level and falls back to reflection over the @ReactProp methods (FallbackViewManagerSetter / FallbackShadowNodeSetter).

The annotation processor that generated those setters (ReactPropertyProcessor) was removed in #49811 (first released in 0.80). Since then no view manager in React Native has a generated setter, so the fallback is the normal path and the warning is printed once per view manager and shadow node class on every app run (71 lines in a typical app start on 0.85.3). It is not an error and there is nothing the app developer can do about it. Users have reported it as logcat noise several times (#29864, #31416, #45211), and it is easy to mistake for the cause of an unrelated crash.

This changes the log call from FLog.w to FLog.d. The lookup itself is kept, because a library can still ship a generated setter, and the message stays available for anyone debugging prop setup. It does not touch FLog configuration.

Changelog:

[ANDROID] [FIXED] - Do not log "Could not find generated setter" at warn level; the reflection fallback is the expected path

Test Plan:

Added ViewManagerPropertyUpdaterTest: it resolves the native props of a view manager that has no generated setter, with FLog mocked, and checks that the props are still found through the fallback and that FLog.w is not called.

Ran it with ./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest --tests com.facebook.react.uimanager.ViewManagerPropertyUpdaterTest: 1 test, passes. With the call put back to FLog.w (and nothing else changed) the same run fails with NeverWantedButInvoked for FLog.w(String, String), reporting the Could not find generated setter for class ...ViewManagerWithoutGeneratedSetter call from findGeneratedSetter. The test follows the same mockStatic(FLog) pattern as the neighbouring tests.

I also compiled the changed ViewManagerPropertyUpdater against the 0.85.3 react-android release AAR and replaced the classes in it; javap -c shows the call site now targets FLog.d and nothing else in the class changed.

On an Android 9 (API 28) x86_64 emulator, with a release build of an app on 0.85.3 (R8, Hermes, New Architecture), I ran the same scripted flow twice: login, five tabs, a list with about 20 remote logos, a company detail screen, and a cold restart. I counted the matching logcat lines.

react-android Could not find generated setter
stock 0.85.3 142 lines
0.85.3 with this patch (and the one for the Fresco rounding warning) 0 lines

Stock 0.85.3 on API 26, 31, 33 and 36 gives 141 to 142 lines for the same flow. The patched build was run on API 28 and API 34 (Android 14), with 0 lines on both, and it did not crash.

The patched react-android was built by recompiling the changed classes and replacing them in the official 0.85.3 AAR, not with a full Gradle build of ReactAndroid.

ViewManagerPropertyUpdater looks up a "<class>$$PropsSetter" class by
reflection and falls back to reflection over the @ReactProp methods when
it is not found. The annotation processor that generated those setters
(ReactPropertyProcessor) was removed in react#49811, so the fallback is now
the normal path for every view manager and shadow node.

Logging it at warn level prints one "Could not find generated setter
for class ..." line per class on every app start, for a condition that
is neither an error nor actionable. Lower it to debug. The lookup is
kept, since a library can still ship a generated setter.
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 5, 2026
@facebook-github-tools facebook-github-tools Bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 5, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant