Инструменты тестирования Android приложений. Часть 4
Содержание:
ReTrace
В теме про Logcat я говорил, что у Android приложений есть несколько видов сборки. Два стандартных и обязательных из них — это “debug” и “release” (на некоторых проектах их может быть больше).
Вот два основных отличия этих сборок:
- “release” сборка обфусцируется
Обфускация — это переименование исходного кода, которое усложняет читаемость исходного когда и сокращает размер файлов. Так, например, если класс на Java был назван “com.example.MyClazz”, то после обфускации он превратится в что-то вроде “a.b.cсс”.
Когда разработчик запускает “release” сборку, система сборки создает apk файл с исходным кодом и файл mapping.txt. Последний файл содержит “перевод” файлов до и после обфускации, если брать наш пример, то в нем будет следующая строка:
com.example.MyClazz <-> a.b.ccc
Учитывайте, что обфускация происходит на этапе сборки релизной версии apk, и это полностью автоматизированный процесс. Результат будет таким же сюрпризом для разработчиков, как и для тестировщиков.
Хорошо и удобно хранить все сборки проекта на удаленном хранилище, к которому QA специалисты имеют доступ. И туда же загружать вместе с релизным APK его маппинг, чтобы все могли найти файл, который может развернуть обфускацию и сделать код снова читаемым.
2. на “release” отключен Logcat
Я уже упоминал выше, что мы не имеем возможности посмотреть логи пользователя из Logcat напрямую, так как Logcat не ведет журнал на “release” версии. Но на многих проектах обходят это условие и немного переписывают внутренний логгер так, чтобы он собирал эти данные локально и хранил их в защищенном месте внутри приложения. В этом случае, если пользователь захочет отправить отчет об ошибке разработчикам, на девайсе создастся файл, где будут собраны все логи на момент ошибки и, например, все логи за пять минут до ошибки. Пользователь может отправить этот файл в службу поддержки.
Но есть одна сложность: из-за той самой обфускации логи превращаются в абракадабру и прочитать их становится невозможным. Если к вам попали логи с обфусцированной ошибкой, вероятнось того, что вы сможете понять что именно произошло, крайне мала.
И тут на сцену выходит еще один инструмент, который поможет в переводе абракадабры — ReTrace. Это утилита, которая принимает на вход обфусцированные логи с ошибкой и mapping.txt файл и “переводит” их в читаемый вид.
Найти деобфускатор можно в папке “Preferences → Android SDK → Android SDK location:” дальше перейти в tools/proguard/lib и запустить proguardui.jar.
У proguard приятный GUI, что бывает редко. В запущенной программе надо открыть вкладку ReTrace, загрузить туда mapping.txt и скопипастить обфусцированный стэк вызовов функций ошибки (или любых логов). После деобфускации вы получите красивые логи, какими вы можете увидеть их в “debug” версии приложения.
Понимание принципа работы обфускации и метода возвращения ее в первоначальный вид очень расширяет кругозор. Разумеется, это не ежедневный кейс, с которым вам придется столкнуться. Но, если из саппорта придет странная ошибка, у вас будет знание о том, как с ней разобраться: с помощью каких инструментов все это привести в человеческий вид и как понять, что произошло на момент ошибки. Что, в свою очередь, поможет быстрее ее воспроизвести и грамотнее оформить отчет.
В следующей части мы разберемся с тем, что такое ANR и как находить и локализировать проблему “лагов” в приложениях.
