A release-only Android crash needs evidence from the release itself. Capture the failing version, device, reproduction steps and crash trace. Then compare release configuration, optimisation and service access with the working build.
“It works from Android Studio” is a useful observation, but it is not yet a diagnosis. The application installed by a user may have been built and distributed with different settings. The first job is to make that difference specific.
Record what actually failed
Write down the app version, Android version, device and installation route. Note whether the app closes immediately, fails after a particular action or only breaks for a certain account. Keep the exact error or crash report where one is available.
A video can help explain a visible failure. A crash trace usually gives a much better starting point for investigating the code. Avoid guessing from a single screenshot if a diagnostic record is available.
Compare the release configuration
Review signing-dependent services, environment values and the resources packaged in the release. If optimisation is enabled, check whether shrinking or obfuscation affects code that is reached indirectly. These are possibilities to investigate, not a reason to disable every optimisation.
Android’s release preparation documentation describes the release configuration and testing work. The relevant checks should be applied to the actual project and its distribution route.
Change one supported cause at a time
Several unrelated changes can make a crash disappear without explaining why. Start from the evidence, make the smallest justified change and repeat the failing journey. Keep notes on the original failure and the outcome after the fix.
Check nearby workflows as well. A correction to startup configuration can affect login, ads, notifications or another service that initialises early. The regression check should follow the dependency involved.
Verify through the route that matters
Once the local release behaves correctly, repeat the agreed checks through the intended testing or distribution route where access is available. Record any part you could not verify. That is more useful than labelling the entire application “crash-free”.
If you need help with this investigation, see our Android testing and QA service. Share the affected version, the steps to reproduce the problem and the crash information you are authorised to provide.