Android build fails with duplicate com.facebook.* classes when using mwdat-core in Expo / React Native

[QuentinGrange]

Android build fails with duplicate com.facebook.* classes when using mwdat-core in Expo / React Native

Description

I’m trying to build an Expo module to integrate mwdat into a React Native / Expo app.

• ✅ iOS build works correctly
• ❌ Android build fails during the build phase

---

Environment

• Expo (React Native) project
• Android (standard Expo / React Native setup)
• com.meta.wearable:mwdat-core:0.3.0

---

Build error

During the Android build, Gradle fails with duplicate class errors:

Execution failed for task ':app:checkDebugDuplicateClasses'.

Duplicate class com.facebook.common.logging.FLog found in modules
fbcore-3.6.0.aar (com.facebook.fresco:fbcore:3.6.0)
and
mwdat-core-0.3.0.aar (com.meta.wearable:mwdat-core:0.3.0)

Similar duplicate errors occur for many classes under:

• com.facebook.common.*
• com.facebook.jni.*
• com.facebook.proguard.annotations.*

(See full stack trace above.)

---

Analysis

After investigation, it appears that mwdat-core-0.3.0.aar bundles Facebook libraries directly inside its AAR, including:

• Fresco (com.facebook.common.*)
• fbjni (com.facebook.jni.*)
• Facebook proguard annotations

These same libraries are already present in React Native / Expo, which causes duplicate classes at build time.

Because these classes are physically embedded in the mwdat-core AAR (not declared as Gradle dependencies), standard Gradle solutions such as:

• exclude
• resolutionStrategy.force

do not resolve the issue.

---

Expected behavior

Ideally, mwdat-core should:

• Not bundle Facebook / Fresco / fbjni classes directly, or
• Provide a variant without these dependencies, or
• Declare them as proper Gradle dependencies so they can be resolved normally

This would allow mwdat to be used in React Native / Expo Android projects without conflicts.

---

Questions

• Is there a recommended Android configuration for React Native / Expo?
• Is there a variant of the SDK without bundled Facebook dependencies?
• Is a fix planned for this packaging issue?

Thanks in advance 🙏

[rohanbhagwat7]

Patch mwdat-core AAR to remove bundled Facebook classes (Repackage the AAR)

I ran into the same issue integrating mwdat-core into an Expo/React Native app. Since the Facebook classes are physically bundled inside the AAR (not declared as Gradle dependencies), the only solution is to manually strip them out.

+1 to the request for Meta to either:

• Declare these as proper Gradle dependencies instead of bundling them
• Provide a -nofacebook variant for React Native projects

[hectorjdgdev]

The same for me

[simonweill]

Just managed to sort it out :) Thanks!

[QuentinGrange]

Finally the script is not a good solution this is what i did so the app doesnt crash:

Android – Fix build error by using local AAR dependencies

You can avoid this issue by downloading the required AARs via Gradle and adding them directly to your Expo module.

1. Add the AAR files

Download the .aar files and place them in the following directory of your Expo module:
android/libs/

Example:

• mwdat-core-0.3.0.aar
• mwdat-camera-0.3.0.aar
• mwdat-mockdevice-0.3.0.aar

---

2. Configure expo-module.config.json

Update your expo-module.config.json to declare the local AAR projects:

{
  "android": {
    "gradleAarProjects": [
      {
        "name": "mwdat-core",
        "aarFilePath": "android/libs/mwdat-core-0.3.0.aar"
      },
      {
        "name": "mwdat-camera",
        "aarFilePath": "android/libs/mwdat-camera-0.3.0.aar"
      },
      {
        "name": "mwdat-mockdevice",
        "aarFilePath": "android/libs/mwdat-mockdevice-0.3.0.aar"
      }
    ],
    "modules": ["expo.modules.metawearables.ExpoMetaWearablesModule"]
  }
}

3. Update build.gradle

Add the following dependencies to your module’s build.gradle file:

dependencies {
  implementation project(":${project.name}$mwdat-camera")
  implementation project(":${project.name}$mwdat-core")
  implementation project(":${project.name}$mwdat-mockdevice")
}

4. Build the project

[QuentinGrange]

According to this issue the problem will be fixed soon: #24

[hectorjdgdev]

how did you solve it @simonweill