fix(android): no camera devices on app start

[hannojg]

What

I was looking at a bug where no camera devices were returned, however, getting them later I was getting values:

This resulted in the camera never displaying

Changes

Problem:

• Before we init the cameraProvider in onInitialize()
• In our app code however we request the camera devices through the native module's constants
• getConstants() will be called before onInitialize() so we just return an empty camera list
• As the camera devices never changed no new event would be emitted that would refresh the devices list

Solution:

• Move the cameraProvider + manager to the init which will be called earlier, react context should be present at this point as its a constructor arg
• This way when getConstants gets called we can get the devices, which fixes the. problem
• I kept cameraManager.registerAvailabilityCallback in onInitialize() as this needs to the looper, which we don't have available in init (at least on new arch as its init from a bg thread)

Note: I am wondering if this is a performance improvement as well, as before I assume something as:

• getCameraDevices: []
• event emitted which camera devices changed emitted
• getCameraDevices: [...]

So first frame time might be faster? 🤷

Tested on

• Samsung S23

Related issues

Not sure, haven't checked

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-native-vision-camera	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 14, 2025 10:19am

[mrousavy]

ah dope!

[n-kulic]

@hannojg @mrousavy Just noting that in this PR, sendAvailableDevicesChangedEvent() was indirectly moved into init, which is causing crashes on hot restart because js bridge isn't ready yet. We opened a follow-up PR to fix this by moving event back to initialize():

• fix(android): avoid calling getJSModule in init #3623

[mrousavy]

uhm - does that not effectively just revert our changes? @hannojg can you review/confirm?

[n-kulic]

@mrousavy Not a full revert, early init of native part (cameraProvider/extensionsManager) is still kept in init.

The only change is moving sendAvailableDevicesChangedEvent() back into initialize(), because that's where it's safe to call getJSModule.

The problem with previous approach is that getJSModule was being called from init (by sendAvailableDevicesChangedEvent) before JS bridge was ready. You can see that here:

• ReactInstanceManager.java:1458

  private ReactApplicationContext createReactContext(...) {
    ...
    // CameraDevicesManager.init triggers here
    NativeModuleRegistry nativeModuleRegistry = processPackages(reactContext, mPackages);

   // JS bridge initialization starts here
    CatalystInstanceImpl.Builder catalystInstanceBuilder = new CatalystInstanceImpl.Builder()
    ...
    
    // Key point: calling getJSModule before this will throw IllegalStateException,
    // which is what currently happens in CameraDevicesManager.init.sendAvailableDevicesChangedEvent.getJSModule
    reactContext.initializeWithInstance(catalystInstance);

So why it works on cold start?

Short answer: timing/race condition.

Long answer: cameraProvider and extensionsManger initialize asynchronously by coroutine. On cold start coroutine usually schedules slightly later, so JS bridge is ready by the time sendAvailableDevicesChangedEvent() runs. Hot restart exposes this timing issue.

[mrousavy]

Got it thanks!