Skip to content

fix(android): compile native code into merged SO#3871

Open
alpha0010 wants to merge 1 commit intosoftware-mansion:mainfrom
alpha0010:patch-2
Open

fix(android): compile native code into merged SO#3871
alpha0010 wants to merge 1 commit intosoftware-mansion:mainfrom
alpha0010:patch-2

Conversation

@alpha0010
Copy link
Copy Markdown

Description

Take advantage of the merged library structure introduced in RN 0.76 to reduce footprint on Android.

Changes

Modifies the custom CMakeLists.txt to more closely match the autogenerated android/build/generated/source/codegen/jni/CMakeLists.txt it is replacing.

Before & after - visual documentation

Before After
Screenshot 2026-04-10 at 3 56 19 PM Screenshot 2026-04-10 at 3 56 33 PM

Note that libreact_codegen_rnscreens.so is now merged into libappmodules.so.

(librnscreens.so is untouched, as I am not familiar enough with the structure to know if that is possible to merge as well.)

Test plan

Build and run Android. Analyze the APK to confirm library merging. There should be no functional change.

Checklist

  • Included code example that can be used to test this change.
  • For visual changes, included screenshots / GIFs / recordings documenting the change.
  • For API changes, updated relevant public types.
  • Ensured that CI passes

Copy link
Copy Markdown
Member

@kkafar kkafar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, thanks for the contribution!

I get the change & why it uses a bit less memory, but I'm not confident about its consequences. I don't recall exactly why it has been a shared lib in the first place.

You mention that you want to align a bit more with the autogenerated CMakeLists (including only the codegened srcs, w/o our custom code) - do you happen to have context how that generated CMakeLists changed? Is it something RN Codegen introduced recently or has it been like that for a long time now?

Also, do you happen to open similar PRs to other libraries?

@kkafar kkafar self-assigned this Apr 13, 2026
@alpha0010
Copy link
Copy Markdown
Author

I get the change & why it uses a bit less memory, but I'm not confident about its consequences. I don't recall exactly why it has been a shared lib in the first place.

I suspect the origin of this for many libraries is https://swmansion.com/blog/react-natives-new-architecture-the-tricky-parts-1-2-bb0c16950f2d/ , which is the most complete description I have been able to find, regarding new architecture shadow nodes. It mentions copying and modifying the generated CMakeLists.txt, but uses SHARED in the displayed snippet (which would have been correct at the time, since RN 0.76 was released two days after that blog post).

You mention that you want to align a bit more with the autogenerated CMakeLists (including only the codegened srcs, w/o our custom code) - do you happen to have context how that generated CMakeLists changed? Is it something RN Codegen introduced recently or has it been like that for a long time now?

To my knowledge, this changed in RN 0.76 react-native-community/discussions-and-proposals#816 , with the introduction libappmodules.so. I am not familiar enough with RN's codebase trace down a specific commit though.

Also, do you happen to open similar PRs to other libraries?

I did open one other currently: AppAndFlow/react-native-safe-area-context#715 (and probably will open more with other libraries in the near future).

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants