Что бы вы сделали, если бы релизная сборка приложения падала в месте, отличном от дебажной сборки?

Проверил бы различия в конфигурации: Проанализировал бы файлы build.gradle (module и app) и настройки ProGuard/R8 или других обфускаторов. Часто проблема кроется в исключении классов, полей или методов, которые используются в продакшене, но не в дебаге. Проверил бы различные buildTypes и productFlavors.

Использовал бы логи: Внедрил бы обширное логирование в проблемном месте кода и вокруг него, а также собирал бы логи с релизной сборки (через средства мониторинга, если есть, или попросил бы воспроизвести и предоставить логи).

Анализировал бы стектрейс: Внимательно изучил бы стектрейс ошибки релизной сборки. Сравнил бы его со стектрейсом дебажной сборки, если она тоже падала в аналогичном месте (или если удалось воспроизвести падение в дебаге). Уделял бы внимание номерам строк и именам классов/методов после обфускации (используя mappings.txt).

Попробовал бы воспроизвести проблему в максимально приближенном к релизу окружении:

• Создал бы локальную сборку с теми же настройками buildType и productFlavor, что и релиз.
• Отключил бы дебагер.
• Использовал бы обфускацию.
• Если возможно, тестировал бы на устройстве, приближенном к тем, на которых воспроизводится ошибка.

Использовал бы инструменты мониторинга производительности и ошибок: Если интегрированы Crashlytics, Sentry или аналогичные, проанализировал бы отчеты об ошибках с продакшена. Они предоставляют информацию о типе устройства, версии ОС, версии приложения и самом стектрейсе.

Изучил бы изменения между успешной и падающей сборками: Определил бы, какие именно изменения в коде, библиотеках или конфигурации были внесены между пос