Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autolinking: Support for Android on New Architecture #1596

Closed
cortinico opened this issue Apr 21, 2022 · 1 comment · Fixed by #1603
Closed

autolinking: Support for Android on New Architecture #1596

cortinico opened this issue Apr 21, 2022 · 1 comment · Fixed by #1603

Comments

@cortinico
Copy link
Member

Describe the Feature

Hey all,
I'm opening this issue to keep track of the status of the Autolinking support for Android on New Architecture.

As we all know, Autolinking is such a crucial part of our infrastructure, as it allows to easily depend on external libraries without having to manually import gradle dependencies.

For Android, the Autolinking support inside the CLI will need to be expanded to handle a couple more scenarios. I'm describing them below.

Overview of the necessary changes

First, autolinking will have to rely on the library name specified in the build.gradle file. For the sake of the examples below, let's call this library name moka.

Changes to the Make/CMake files

Users will have to import the generate .mk files of the library inside the Android.mk of their application (this file)

Namely those changes are needed:

 include $(REACT_ANDROID_DIR)/Android-prebuilt.mk
 
 # If you wish to add a custom TurboModule or Fabric component in your app you
 # will have to include the following autogenerated makefile.
 # include $(GENERATED_SRC_DIR)/codegen/jni/Android.mk

+# Includes the .mk file for library moka
+include $(NODE_MODULES_DIR)/moka/android/app/build/generated/source/codegen/jni/Android.mk

 [...]

 LOCAL_SHARED_LIBRARIES := \
   libfabricjni \
   libfbjni \
   libfolly_runtime \
   libglog \
   libjsi \
   libreact_codegen_rncore \
+  libreact_codegen_moka \
   libreact_debug \
   libreact_nativemodule_core \
   libreact_render_componentregistry \
   libreact_render_core \
   libreact_render_debug \
   libreact_render_graphics \
   librrc_view \
   libruntimeexecutor \
   libturbomodulejsijni \
   libyoga

Agree that the include is not great. We could potentially have a $(call import-codegen-module,moka) which will make for a easier and more maintainable syntax.

Moreover, we're currently updating the .mk files to CMake files, which will make the setup easier.

We would have to adapt autolinking to generate a Android.mk/CMakeLists.txt file which contains all the imports of the discovered library. This file can then be imported inside the template.

Changes to the Application Module Provider

The MainApplicationModuleProvider.cpp file (this one) needs to be updated to include all the autolinked modules. This is necessary in order for TMs to be discovered.

Namely a user would have to do this change to include the moka library:

 #include "MainApplicationModuleProvider.h"

 #include <rncore.h>
+#include <moka.h>

 namespace facebook {
 namespace react {

 std::shared_ptr<TurboModule> MainApplicationModuleProvider(
     const std::string moduleName,
     const JavaTurboModule::InitParams &params) {
   // Here you can provide your own module provider for TurboModules coming from
   // either your application or from external libraries. The approach to follow
   // is similar to the following (for a library called `samplelibrary`:
   //
   // auto module = samplelibrary_ModuleProvider(moduleName, params);
   // if (module != nullptr) {
   //    return module;
   // }
   // return rncore_ModuleProvider(moduleName, params);
+  auto module = moka_ModuleProvider(moduleName, params);
+  if(module != nullptr) {
+      return module;
+  }
   return rncore_ModuleProvider(moduleName, params);
 }

Therefore we probably need a autolinked_ModuleProvider that checks for all the autolinked modules. Those files are going to be a .h/.cpp file can be codegenned and in this if-then-else statement in a cascading style (similary to getPackages on the main application class).

Changes to the Main Components Registry

The MainComponentsRegistry.cpp file (this one) needs to be updated to include all the autolinked components. This is necessary in order for external Fabric componetns to be discovered.

Namely a user would have to do this change to include the moka library:

 #include "MainComponentsRegistry.h"

 #include <CoreComponentsRegistry.h>
 #include <fbjni/fbjni.h>
 #include <react/renderer/componentregistry/ComponentDescriptorProviderRegistry.h>
+#include <react/renderer/components/moka/ComponentDescriptors.h>
 #include <react/renderer/components/rncore/ComponentDescriptors.h>

 namespace facebook {
 namespace react {

 MainComponentsRegistry::MainComponentsRegistry(ComponentFactory *delegate) {}

 std::shared_ptr<ComponentDescriptorProviderRegistry const>
 MainComponentsRegistry::sharedProviderRegistry() {
   auto providerRegistry = CoreComponentsRegistry::sharedProviderRegistry();

   // Custom Fabric Components go here. You can register custom
   // components coming from your App or from 3rd party libraries here.
   //
   // providerRegistry->add(concreteComponentDescriptorProvider<
   //        AocViewerComponentDescriptor>());
+  providerRegistry->add(concreteComponentDescriptorProvider<
+          MokaComponentDescriptor>());
   return providerRegistry;
 }

This is a bit trickier as react/renderer/components/moka/ComponentDescriptors.h might contain more than one generated ComponentDescriptors (e.g. a CoffeeComponentDescriptors, CappuccinoComponentDescriptors or more).

Again here we would need a AutoLinkedComponentDescriptors which exposes a list of discovered ComponentDescriptors that can be all added in this function here.

Possible Implementations

I'm opening this issue to understand if there is someone that is willing to look into those changes and develop them. I'm happy to support them/review them to make sure everything works correctly with the New Architecture on Android.

@thymikee
Copy link
Member

Thanks for creating that! I've asked @kbieganowski to take a look at this space but he ran out of time. Would appreciate any help. This PR originally introducing autolinking to Android should be a good resource to start with: #258

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

Successfully merging a pull request may close this issue.

2 participants