Нативные отладочные символы android studio

Использование отладчика Android Studio по максимуму

Это хитрость, о которой я узнал совсем недавно у Senior Android разработчика в моей компании, и теперь я чувствую себя несчастным, сожалея о времени, которое я провел в ожидании сборки Gradle, чтобы проверить свои изменения при написании Android приложений.

Вот типичный сценарий, который каждый Android разработчик мог бы встретить, по крайней мере, один раз в течение своего жизненного цикла разработки. У вас есть список элементов, которые вы хотите показать в ListView или RecyclerView.

Ниже приведен наш возлюбленный метод onBindViewHolder , который связывает вашу модель с вашими view-компонентами RecyclerView.

Теперь, допустим, вы захотели изменить цвет текста для каждого третьего элемента в списке. Таким образом, код будет выглядеть примерно так:

Затем вы нажмёте Run и дождётесь завершения сборки и увидите ваши изменения, так?

Теперь вы бы подумали, существует ли другой путь для достижения этой же цели?

Твой выход, Android Studio! Да, нам не нужен внешний плагин или инструмент для достижения вышеупомянутой задачи и более того, нам даже не придется заново собирать проект. Вы не ослышались, мы обойдёмся без Gradle 🙂 Вот как!

Шаг 1 — Необходимо определить конфигурацию запуска

Такая конфигурация запуска позволит нам запускать наше приложение и присоединять к нему отладчик из Android Studio, а также вы сможете присоединить его к уже запущенному процессу.

Нажмите Run → Edit Configurations.

Edit Configurations» data-src=»https://habrastorage.org/getpro/habr/post_images/925/25e/e1a/92525ee1a0fa26e7cca96d237563c9fa.png»/>

В верхнем левом углу диалогового окна щелкните значок «+» и выберите Android App.

Теперь дайте ему имя, мне нравится называть его Run-Only, но вы можете называть его как угодно.

Выберите модуль, который содержит код вашего приложения, в приведенном ниже скриншоте он называется app.

Важный шаг:

В разделе Installation Options выберите Nothing;
В Launch Options выберите Default Activity;
В разделе Before Launch удалите Gradle-aware Make.

Таким образом, конфигурация должна выглядеть следующим образом:

Теперь вы можете применить и сохранить эту конфигурацию. Сейчас она должна быть выбрана автоматически. Если нет, то просто выберите её из списка.

Теперь поставьте breakpoint поближе к строке, которую вы хотите проверить. В нашем случае мы разместим ее там, где мы устанавливаем текст.

Щелкните правой кнопкой мыши на breakpoint и снимите флажок Suspend (рус. приостановить).

Как только вы снимете флажок, диалог расширится и покажет больше опций.

Нам интересен раздел Evaluate and log. Мы напишем там выражение, чтобы проверить изменения в нашем элементе RecyclerView. Нажмите на маленький значок голубого цвета справа от окна ввода Evaluate and log, чтобы развернуть его до более крупного редактора, и добавьте выражение для тестирования, и нажмите Ok, а затем Done.

Теперь нажмите на иконку Debug с выбранной конфигурацией Run-Only и посмотрите на эту магию.

Приложение должно запуститься с вашей Activity по умолчанию, и вы должны увидеть внесенные там изменения. Также, если вы уделяете пристальное внимание IDE, в самом низу вы увидите только одну запускаемую задачу: Launching Activity.

Хотелось бы услышать ваши впечатления, когда вы опробуете эту хитрость!

Источник

Отладка Android CMake проекта по-взрослому

После перевода наших проектов на CMake, встал вопрос об отладке нативной части Android. Так как инструменты NDK стали неактуальны, пришлось залезть в дебри и научить Eclipse запускать удалённую отладку CDT-проекта, что называется, вручную. В идеале, чтобы это выполнялось в один клик.

Если вам не чужда разработка с использованием Android NDK, и вы хотите познать некоторые тонкости отладки, велкам под кат.

В одной из наших студий было принято решение о переводе кроссплатформенных проектов на CMake, что позволило ускорить их разработку, но также внесло свои коррективы в некоторые этапы. CMake полностью заменил систему сборки ndk-build, и «инструменты отладки» ndk-stack, ndk-gdb стали недоступны. Помедитировав над Eclipse и CDT в частности, появилась мысль о том, что отладку нативного кода CMake Android-проекта можно сделать удобной, быстрой и доступной.

CMake Android-проект

В этой статье мы рассмотрим нашу задачу в слегка уменьшенном масштабе — на примере Teapot из состава Android NDK. Его сборка была переведена с ndk-build скриптов на CMake. Надо пояснить, что CMake не заточен полностью под Android, как и под любую другую платформу. Дополнительный функционал нужно писать самому, что и было сделано в данном случае, поэтому не удивляйтесь, если видите какую-то переменную или функцию, о которых в документации CMake ни слова. Бóльшую часть я попытаюсь описать, но кое-что могу упустить, поэтому если вы решите перенять опыт, то вам придётся вникнуть в используемые скрипты и хотя бы примерно понимать их работу, дабы при выходе новой версии NDK не сесть в лужу.

Для успешной сборки и настройки отладчика, вам понадобятся:

• Android SDK
• Android NDK r8+
• CMake 2.8.11+
• MinGW (если вы на Windows)
• Переменная окружения ANDROID_NDK, указывающая на распакованный NDK

После загрузки демо-проекта, запустите cmake.cmd/sh , после чего в Eclipse импортируйте проекты из папок build/android_debug и sources/Teapot .
Для проекта TeapotNativeActivity можно добавить референс на TeapotNativeActivity-Debug@android_debug , чтобы пересборка происходила автоматически.

В итоге у вас должен получиться такой workspace:

Немного теории

Отладка native кода Android-приложения включает в себя несколько этапов:

1. Сборка нативных библиотек с отладочными символами (чтобы отладчик мог связать код в исходниках и скомпилированный код).
2. Создание урезанных версий библиотек без отладочных символов, но со ссылкой на них.
3. Сборка и установка APK на устройство с урезанными версиями библиотек.
4. Запуск APK.
5. Поиск идентификатора процесса (PID) запущенного APK.
6. Запуск удалённого отладчика на устройстве с указанием PID. Отладчик открывает TCP порт на устройстве, куда можно слать команды gdb.
7. Пробрасывание TCP порта с устройства на локальный компьютер.
8. Загрузка с устройства системных файлов, необходимых для корректной работы отладчика (установки правильных адресов и смещений).
9. Запуск отладчика на локальном компьютере с указанием локального TCP порта и конфигурацией путей поиска библиотек и исходников.

В Eclipse всё это разделяется на несколько основных этапов:

1. Сборка нативного кода.
2. Сборка APK.
3. Запуск APK.
4. Выполнение скрипта-хелпера для настройки отладчика локально и удалённо.
5. Запуск отладчика нативного кода.

Наша задача — объединить это всё в один клик.

Challenge accepted

Сборка .so

Сборка отладочных версий библиотек не представляет сложностей (CMake всё делает за нас), однако нюанс поджидает в совместимости форматов отладочной информации. Мы используем для сборки своих проектов arm тулчейн gcc-4.8, в котором почему-то используется gdb, не совместимый из коробки с генерируемым форматом dwarf. Для нахождения общего языка, компилятору нужно указать конкретный формат dwarf.

Для этого прописываем флаги в CMake:

Помещение отладочной информации в отдельный файл

Размер библиотеки с отладочными данными может достигать нескольких сотен мегабайт, что негативно влияет на размер APK и, как следствие, скорость загрузки на устройство. Для решения этой проблемы выполняем strip отладочной информации в отдельный файл:

После сборки, полная версия .so переименовывается в .so.debug , и на её основе создаётся .so с убранной информацией об отладке и ссылкой на .so.debug файл.
Этот код находится в функции set_ndk_gdbserver_compatible(target) в файле CMake/auto_included/android_helpers.cmake . Помимо выполнения стрипа после сборки, он также выполняет другие важные шаги, о которых ниже.

Удаленный отладчик a.k.a. gdbserver

При сборке не отладочной конфигурации файл gdbserver будет удаляться.

Скрипт ndk-gdb.py

Для настройки устройства и локальной машины используется переработанная версия скрипта ndk-gdb.py из Android NDK.

В его задачи входит:

1. Проверка наличия флага android:debuggable=»true» в AndroidManifest.xml .
2. Получение идентификатора package из AndroidManifest.xml .
3. Подключение к девайсу и поиск PID запущенного инстанса по идентификатору package.
4. Запуск gdbserver , пробрасывание порта.
5. Копирование дополнительных файлов для отладчика на локальную машину.
6. Создание файла gdb.setup для отладчика на локальной машине.

Этот скрипт создаётся на основе шаблона CMake/auto_included/stuff/ndk-gdb.py.in в момент вызова set_ndk_gdbserver_compatible(target) . В процессе запуска отладки скрипт должен запускаться после старта APK.

Настройка Eclipse для запуска ndk-gdb.py

Здесь и далее, параллельно описанию, будет идти мануал по настройке демо-проекта.

Добавляем External Tool с такой конфигурацией:

Так как это промежуточный шаг для запуска отладчика, то привязка к билду нам не нужна:

Настройка отладчика C++ Remote Application

Eclipse CDT предлагает несколько вариантов работы отладчика, но нас интересует единственно верный в данном случае: C++ Remote Application .

В настройки отладчика прописываются пути:

• приложения для отладки
• отладчика
• конфигурации отладчика

Приложение для отладки — это файл app_process , который загружается с устройства на локальный компьютер. app_process — это нативный исполняемый файл для платформы Android, через который стартуют все Java-процессы.

Конфигурация отладчика — это файл gdb.setup , в котором указаны пути для поиска библиотек.

После генерации CMake-проекта, в папке build/android_debug/ndk-gdb создаются пустышки app_process и gdb.setup , чтобы на них можно было натравить Eclipse. В момент запуска отладки, скрипт ndk-gdb.py подгружает с девайса настоящий файл app_process и конфигурирует gdb.setup .

Настройка отладчика в Eclipse

Что отлаживаем:

Чем отлаживаем:

Как удобно-то!

В результате этих действий мы получили несколько разных задач в Eclipse, которые уже позволяют запустить отладку, но для этого нужно:

1. Запустить APK
2. Запустить скрипт ndk-gdb.py
3. Запустить отладчик

Мы же рассчитываем отлаживать наше приложение в один клик, так?

Launch Group to the rescue!

На наше счастье, Eclipse CDT предлагает механизм по автоматизации нескольких разных действий в Eclipse, и имя ему Launch Group.

Создайте конфигурацию с последовательносью:

1. Запуск отладки APK, задержка 2 секунды. Задержка нужна для стабильного запуска APK, т.к. следующий шаг требует запущенный APK, иначе скрипт не найдёт нужный процесс.
2. Запуск скрипта ndk-gdb.py, задержка 2 секунды. Задержка нужна для стабильного пробрасывания порта с устройства.
3. Запуск отладчика C++ Remote Application.

Для удобства на вкладке Common активируйте отображение этого шага на кнопке отладки в Eclipse:

Debug me

Если всё сделано правильно и у вас хорошая карма, то при запуске этого действия вы сможете наслаждаться отладкой вашего проекта:

Что-то пошло не так?

Проблемы бывают, и мы их периодически ловим. Разные девайсы имеют разную производительность, прошивки, версии Android.
Чаще всего сложности возникают из-за медленного запуска APK, что приводит к подключению отладчика ещё на фазе загрузки .so, что негативно сказывается на запуске, и порой вообще невозможно продолжить работу. Для решения этой проблемы нужно увеличить задержку между первым и вторым шагом в Launch Group.
Ещё возможна проблема с зависанием отладчика на девайсе, ребут устройства обычно спасает.

Также в предложенном примере используется ndk-gdb.py скрипт, рассчитанный на то, что его будут запускать только на Linux x86, Mac OS X x64 или Windows x64. Если ваша конфигурация отличается, то вам придётся его подкрутить.

Заключение

Всё это позволило значительно упростить отладку любого Android CMake-проекта, и мы этому несказанно рады. Конечно, есть простор для улучшений и оптимизаций: в идеале хочется сделать нечто, что могло бы настроить все эти шаги в Eclipse автоматически, потому как каждый новый проект/ветка требует такой настройки.

Если у вас появились вопросы или предложения по улучшению/упрощению схемы, я буду рад их услышать!

Источник