You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ¶ms) {
// 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.
The text was updated successfully, but these errors were encountered:
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
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 namemoka
.Changes to the Make/CMake files
Users will have to import the generate
.mk
files of the library inside theAndroid.mk
of their application (this file)Namely those changes are needed:
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: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 togetPackages
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:This is a bit trickier as
react/renderer/components/moka/ComponentDescriptors.h
might contain more than one generatedComponentDescriptors
(e.g. aCoffeeComponentDescriptors
,CappuccinoComponentDescriptors
or more).Again here we would need a
AutoLinkedComponentDescriptors
which exposes a list of discoveredComponentDescriptors
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.
The text was updated successfully, but these errors were encountered: