Hi all,
Hoping someone’s hit this before. We’re integrating DeepAR into a React Native (Expo) app on Android and switchEffect()/switchEffectWithPath() reaches the native SDK on a live, correctly-initialized DeepAR instance and returns without throwing — but effectSwitched()/error() never fires. No exception, no native log output, no crash. Just stuck forever.
Environment:
- DeepAR Android SDK v5.6.22 (current latest)
- react-native-deepar v0.11.0
- Reproduces identically on Samsung SM-A346E (Android 16, API 36) and Samsung SM-N960F (Android 10, API 29) — so it doesn’t look device- or OS-version-specific.
What we’ve ruled out:
- Camera permissions/binding — bindToLifecycle() succeeds every time on both devices.
- JS↔native dispatch on our end — confirmed via logging that switchEffectWithPath() is called exactly once per attempt, on the correct live instance.
- The effect file’s content — rebuilt a minimal effect in DeepAR Studio with just a Lips node, removed the Beauty/skin-smoothing node in case it depended on the Web-only Beauty plugin your docs mention. Identical hang.
- Missing Android 12+ manifest entries — added the libOpenCL.so/libOpenCL-pixel.so declarations from the Android getting-started guide. Identical hang.
- Stale build artifacts — confirmed via a completely fresh build.
- Device/OS-specific behavior — reproduces across two very different devices/Android versions.
One thing we chased and had to walk back: on the first device, logcat showed a new CameraX graph created right at switchEffect() time that reported CameraUnavailable and never recovered, which looked like it might be a CameraX-implementation conflict (our app also uses react-native-vision-camera elsewhere, which pulls in camera-camera2-pipe — not present in DeepAR’s own quickstart-android-java repo or in react-native-deepar’s own build.gradle). But on the second device, the camera bound and reached CAMERA_STATE_ACTIVE cleanly with no such conflict at all — yet switchEffect() still hung the same way. So that doesn’t seem to be the actual cause.
One thing that caught our eye: the Web SDK changelog documents a fixed bug where switchEffect() never resolves if setPaused(true) was called beforehand and tracking wasn’t initialized. We don’t see an equivalent fix noted in the Android changelog. We aren’t calling setPaused() ourselves, but if there’s a similar tracking-initialization precondition internally on Android, that would match a hang with zero error signaling pretty well.
Also found a couple of other threads here with a similar flavor (custom Studio effect works in Live Preview, breaks specifically on Android) but they look unresolved too.
Has anyone gotten switchEffect() to reliably resolve/fail (rather than hang silently) on Android? Any known gotchas around tracking initialization, camera state, or engine readiness before calling switchEffect() that aren’t in the docs? Happy to share logcat excerpts or more detail if useful.
Thanks!