How We Solved a Random React Native Camera Crash That Only Happened on Some Android Devices

For several days, our team was investigating one of the most frustrating production issues I’ve encountered in a React Native application.

The issue seemed completely random.

Some users could capture all six required images without any problem. Others experienced a crash after the second, fourth, or sixth image. The application didn’t completely crash — instead, it unexpectedly exited the camera flow and navigated back to the previous screen.

Even more confusing, the issue only occurred on certain Android devices.

iOS worked perfectly.

Selecting images from the gallery worked perfectly.

Only the camera flow was affected.

At first glance, everything pointed toward React Native Image Picker or the device camera.

It turned out that neither of them was responsible.

The Production Environment

The application allows users to capture multiple images as part of a warranty and claim submission process.

Each captured image goes through several stages before being uploaded to Salesforce:

• Capture image
• Compress image
• Display preview
• Convert image to Base64
• Upload to Salesforce
• Delete temporary files

The workflow sounds straightforward.

However, the problem appeared only when users captured multiple images quickly.

The Symptoms

The production behavior was inconsistent.

• First image usually worked.
• Sometimes the second image failed.
• Sometimes the fourth image failed.
• Sometimes the sixth image failed.

The randomness made the issue extremely difficult to reproduce.

Even more challenging:

• No JavaScript exception
• No OutOfMemory exception
• No native crash stack trace
• Crashlytics showed no meaningful crash

Everything looked normal.

The Investigation

Our first assumption was that the camera library had a bug.

We tested multiple Android devices.

We investigated:

• React Native Image Picker
• Camera permissions
• Android 16 changes
• Image preview rendering
• React Native state updates
• Salesforce upload logic
• Image cache

Nothing explained the behavior.

Eventually, we added detailed logging around every step of the image pipeline.

Then something interesting appeared.

The Breakthrough

As an experiment, we added a 10-second delay before allowing users to capture the next image.

Surprisingly…

Get Vinod Vishwakarma’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The issue completely disappeared.

That immediately ruled out the camera itself.

The camera was functioning correctly.

Something else was still running in the background.

The Real Root Cause

The actual problem was image compression.

Every captured image immediately started an asynchronous compression process.

If the user quickly captured another image, another compression started.

Then another.

Then another.

Multiple compression operations were running simultaneously.

Each compression created temporary files, consumed CPU, allocated memory, and competed for storage resources.

On some Android devices, this resource contention eventually caused the camera activity to exit unexpectedly.

The crash was never inside the camera.

The crash was caused by heavy background work competing with the camera lifecycle.

The Solution

Instead of allowing unlimited compression tasks, we redesigned the pipeline.

The improvements included:

• A compression queue that processes one image at a time
• Preventing concurrent image compression
• Reducing unnecessary temporary image generation
• Better cache management
• Cleaning temporary files after successful Salesforce uploads
• Keeping the implementation compatible with both Android and iOS

The new workflow became much simpler:

Capture Image
        ↓
Compression Queue
        ↓
Compressed Image
        ↓
Preview
        ↓
Upload to Salesforce
        ↓
Delete Temporary Files

Only one compression job is active at any given time.

The Result

After deploying the optimized implementation:

• Random camera exits disappeared
• Image processing became significantly more stable
• Cache usage dropped considerably
• Upload reliability improved
• Overall image capture became noticeably faster

Most importantly, users could complete the entire claim process without interruption.

Lessons Learned

This issue reinforced several important engineering lessons.

1. The crash location is not always the root cause.

Applications often fail where the symptoms appear, not where the problem originates.

2. Background operations deserve as much attention as foreground UI.

A perfectly functioning camera can still fail if intensive background work competes for resources.

3. Production logs are invaluable.

Without detailed instrumentation, this issue would have been almost impossible to diagnose.

4. Serialization can outperform parallelism.

While running multiple tasks concurrently sounds efficient, serial execution through a queue often provides better stability for resource-intensive operations like image processing.

Final Thoughts

This bug reminded me that software engineering isn’t just about writing code — it’s about understanding how every component interacts under real-world conditions.

Sometimes the most difficult production issues aren’t caused by a broken API or a faulty library.

They’re caused by small background operations quietly competing for resources until the system reaches its limit.

Finding the true root cause required patience, experimentation, and careful observation.

And that’s often where the best engineering lessons come from.

Have you ever encountered a production issue where the actual root cause was completely different from where the application appeared to fail? I’d love to hear your experience in the comments.