Как производить отладку кода решения написанного для мобильного устройства

Отладка мобильного приложения в 1С 8.3.7

(0) Не знаю на счет 1С, но когда-то я пытался разобраться с Андроид программированием.
И включение отладки для программ андроида делается так:

Может, тебе тоже поможет.

Глубоко ушли 🙂
Тут главное теорию знать.
Если устройство на базе Аднроид, то отладку можно через адб сделать, но в любом случае — для отладки надо установить последнюю 8.3.7 (в предыдущих был баг).
Устройство должно быть в одной сети, доступ к серверу отладки по указаному порту должен быть с устройства.
Запуск надо делать через Отладка — Запуск мобильного клиента.

Это если в двух словах.
Ну и перести сервер отладки с tcp на http.

DitriX, может ты подскажешь.

Устройство на базе Андроид.
1С 8.3.7.1759.
Протокол отладки -> "Отладка по протоколу HTTP". Переключатель "Использовать локальный сервер отладки".
Адрес локальной сетевой карты: "127.0.0.1"
Предметы отладки — Автоматическое подключение — галки стоят на всех 13 типах предметов отладки.
Запуск через "Мобильное приложение:начать отладку".

Всё работает, но не останавливается на точках останова. В какой еще бубен зашаманить?

Отладка native-кода под Android: ручное и автоматизированное тестирование

С развитием и ростом популярности ОС Android количество и разнообразие устройств под её управлением неуклонно растёт. Из-за различий в архитектуре, предназначении и оптимизации скорость и стабильность работы исполняемого кода может значительно изменяться. Поэтому, для обеспечения стабильности и оптимизации работы приложений и ОС, особенно использующих особенности конкретной архитектуры, платформы, или кода, портированного с других платформ, стоит особо внимание уделить процессу отладки кода под Андроид. В этой статье пойдёт речь о ключевых моментах и особенностях работы с native-кодом под Android. Всем, кому интересен этот мануал, прошу под кат.

В далёком 2007 году корпорация Google выпустила операционную систему нового поколения – Android.

Её появление совершило настоящую революцию на рынке мобильных устройств, подавив гегемонию Microsoft Widows Mobile, Apple iOS и Symbian OS, в последствие став самой популярной и массовой операционной системой для мобильных систем в мире. До сих пор рост популярности системы продолжается. За прошедшие шесть лет Android очень сильно разросся и развился, и спектр поддерживаемых устройств продолжает увеличиваться. Теперь это операционная система используется не только в мобильных телефонах, но также и в планшетах, телевизорах, плеерах, фотоаппаратах, ноутбуках, неттопах и прочих экзотических вещах, вплоть до военной техники. Начинки этих устройств могут весьма заметно отличаться друг от друга: за прошедшие годы перечень поддерживаемых архитектур расширился с ARM до MIPS и х86, появилась поддержка различной периферии, не говоря о непременно развивающемся Android API.

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

Тем не менее, обеспечение унификации и кроссплатформености, быстроты работы приложений – одно из приоритетных направлений сегодняшнего рынка высокопроизводительных приложений и сборок системы. Это, в первую очередь, означает повышенные требования к самой операционной системе, способной работать и делать это эффективно на различном аппаратном обеспечении, так и высокие требования к приложениям для Android.

Одним из самых эффективных решений для оптимизации и ускорения работы приложений, системы и её компонентов является оптимизация на родном, native-уровне. Другими словами, использование для приложений и системы оптимизированных, часто аппаратно-зависимых библиотек и кода, а в глобальном смысле – целого ряда библиотек, поставляющихся для каждой из целевых платформ. Такое многообразие аппаратных платформ, различных версий операционной системы, платформ API и требований к обеспечению стабильной и быстрой работы приложений требует значительных усилий на тестирование приложений, библиотек под конкретные конфигурации.

Тем не менее, одним из самых удобных инструментов для разработчика Android до сих пор является пакет Android NDK – Android Native Development Kit, включающий в себя почти всё необходимое для разработки и отладки приложений, библиотек и самой системы.

В данной статье я рассмотрю его использование для тестирования и отладки native-кода Android и автоматизацию тестирования на примере такого фреймворка, как DejaGnu.
Android развивается очень динамично, и теперь в поставку DejaGnu входит почти что всё необходимое для быстрого старта тестирования – как с Android NDK, так и без него. Главной задачей данной статьи будет рассказ о нюансах и особенностях тестирования под Android и некоторых подводных камнях, с которыми могут столкнуться инженеры.

Для начала небольшая ремарка: Android, как известно, является Unix-like операционной системой, очень схожей с обычным Linux или BSD, и большинство исходного кода Android следует лицензии, ASL2.0. Кто работал с Android, знает, что немалое количество модулей Android перешли из BSD в большей степени, чем из Linux. Тем не менее, всё, что касается native-кода и архитектуры, если не вдаваться в подробности, очень близко и известно всем тем, кто использовал Linux. Поэтому для разработки и отладки кода вполне возможно использовать точно такие же или схожие инструменты, что и для Unix-like систем. В случае компиляторов – это gcc, clang (llvm), icc и прочие. То же самое можно сказать и насчёт всего GCC toolchain и некоторых других утилит, которые либо уже портированы, либо портировать не так сложно.

Главной причиной включения в приложение native-кода или использования native-библиотек, native-исполнимых файлов является стремление увеличить производительность или переиспользовать ранее написанный код C/C++/ASM с Linux/Unix-like систем.

Преимущества использования native-кода:
• Высокая производительность
• Прямое использование CPU/HW особенностей
• Возможность переиспользования существующего Linux кода

Недостатки использования native-кода:
• Индивидуальная настройка под CPU/HW
• Недостаточная поддержка системных библиотек

Плюсы и минусы требуют тщательного тестирования, как по качеству кода, стабильности, так и по его производительности на разных платформах. Несмотря на то, что одним из постулатов Android является независимость от железа, для обеспечения работы на различных конфигурациях, в действительно приложения с native-кодом поставляются в так называемых fat binary (apk, включающие в себя native-код/библиотеки для всех возможных конфигураций оборудования, под которым будет работать приложение). Несмотря на то, что в идеале NDK компилятор должен создавать функционально равнозначный код для различных конфигураций и, следовательно, библиотеки для fat binary (или системные – для образа) должны быть равнозначными — это, к сожалению, не всегда соответствует действительности и требует проверки, особенно когда дело касается оптимизации (Neon и SSE например) и использования сторонних библиотек.

Кроме того, с развитием ОС Android и устройств под её управлением, закономерно меняются различные версии ОС, поставка этой ОС, а так же специфика устройств. В некоторых случаях для разработчика оправдано использование каких-то оптимизаций или иного компилятора для сборки native-кода. Оценка производительности, правильности и стабильности этого кода на различных конфигурациях – задача тестировщика, занимающегося Android Native тестированием.
Процесс сборки, отладки и тестирования native приложений под Android не сильно отличается от того же процесса на Linux, с единственной разницей, что мы собираем бинарные файлы (исполнимые и библиотеки) не в Android, а на хосте (Linux, MacOS, Windows) и исполняем на устройстве Android (физическом или эмуляторе). Поэтому универсальным средством коммуникации хоста с устройством под управлением Android является adb – Android Debug Bridge, входящий в состав Android SDK. Для сборки и отладки приложений целесообразно использовать тот toolchain и API, который нам нужен, а так же, при необходимости (для c++), интересующую нас версию библиотеки stdc++.

версиям используемого API:

Впрочем, с точки зрения разработчика и тестировщика, различий между получаемым кодом в зависимости от билд-хоста быть не должно, и использовать для проверки и тестирования различные конфигурации билд-хостов вовсе не обязательно.
Количество вариантов для тестирования угрожающе разрастается, и это не беря в расчёт оптимизации по CPU инструкциям: neon, core-avx2, core-i7, atom, slm; по размеру\скорости и прочие. Все это декартово произведение вариантов полученного кода (исходного и бинарного) является отправной точкой для тестирования. В случае же, когда целью тестирования является само устройство или какой-то кастомная сборка Android, то, вполне вероятно, главным весомым различием будет библиотека bionic – аналог библиотеки libc для Android.

Закончив вводную теорию, самое время перейти к практике.

Инструменты для ручной сборки и тестирования

Все необходимые инструменты входят в поставку Android NDK, которая есть для 32 и 64 бит под Linux, MacOS, Windows.

Создание и запуск приложения

В случае совпадения архитектуры host и target (обычно речь идёт о x86) и наличия root привилегий, вполне возможно использовать при желании хитрый трюк с запуском Android x86 бинарников на хосте. Для этого нужно явным образом использовать dynamic linker для Android на системе (/system/bin/linker), а так же использовать non-stripped версию bionic в путях (LD_LIBRARY_PATH). См пример Makefile: (https://android.googlesource.com/platform/bionic/+/master/tests/Android.mk: bionic-unit-tests-run-on-host).

Такой трюк, например, актуален для исполнения бинарных файлов без эмулятора (в случае отсутствия 64-битного образа или использования -mx32).

GCOV и профили

Дебаг\отладка: GDB/logcat

Автоматизация тестирования

Для автоматизации тестирования можно использовать такой фреймворк, как dejagnu. Начиная с февраля 2013 в состав DejaGnu входит борд androideabi, позволяющий производить тестирование native-кода на Android через adb.

В целом всё аналогично тому, что было описано выше, за исключением некоторых нюансов.

Для многих тестов dejagnu критичны проверки host/target триплетов. Например, как минимум для того, чтобы понять, возможен ли запуск бинарного файла на устройстве, зачастую выполняется проверка host=target=build (native). Однако, в нашем случае, вообще говоря, build_triplet не равен target_triplet, но при этом мы вполне способны и выполнять, и получать результаты на Android. Кроме того, следует учесть тот факт, что по умолчанию NDK использует флажок –fpic, что так же влияет на возможность запуска тестов и их результаты (проверка effective-target pic/nonpic). В случае же статической (static) линковки следует иметь в виду, что, возможно, так же не всё будет соответствовать ожиданиям (библиотеки static, dynamic могут разниться между собой и порождать разный код (-fpic/-fpie). Также некоторые тесты критичны к директории запуска или указанию директории для результатов; и прежде чем запускать бинарный файл, следует сменить директорию на нужную. Кроме того, во время переноса бинарного файла на устройство, права на запуск могут быть сброшены (из-за прав на папку или прав на файловую систему), поэтому так же стоит убедиться, что для исполнимого файла установлен executable bit. Кроме того, лучшим решением для организации тестирования является использование не sd-карты, а ram-диска с правильными правами, чтобы избежать быстрого износа первой.

Чтобы запустить тестирование на Android достаточно выполнить при установленной dejagnu на хосте:

Следует убедиться, что у вас явным образом указана переменная ADB_SERIAL, соответствующая серийному номеру вашего устройства.
Однако гораздо удобнее и приятнее запускать тестирование через локальный конфигурационный файл — site.exp

Например, конфигурационный файл для запуска gcc testsuite:

и для запуска того же самого gcc:

Замечание: обратите внимание, что следует убедиться, что во время запуска проверки gcc кем-то не будет перетёрта переменная GCC_EXEC_PREFIX, и то, что она unset.

• sysroot
• пути к библиотекам и заголовочным файлам
• флаги и подключаемые библиотеки (как минимум для линовки libstdc++)

Исходя из этого, лучшим решением является использование обёртки исполнимого файла из toolchain (wrapper-binaryname), примерно следующего вида:

wrapper-gcc

wrapper-g++

При необходимости, если надо получить какие-то данные из Android, то мы можем использовать функцию remote_upload (adb_upload %target_board% %source% %dest%). Эта функциональность должна предоставляться со стороны testsuite.

Профилирование, тестирование производительности

• perf
• oprofile
• sep

Тестирование производительности на Android возможно производить не только с помощью бенчмарков, работающих через Dalvik, но так же и на native-уровне, т.е. используя бенчмарки, собранные тем же самым Android NDK. В качестве примера: SPEC, EEMBC, CoreMark.

• режим работы процессора
• приложения, запущенные в фоне
• чистота запуска, и ошибки (которые можно и нужно отслеживать через logcat/dmesg)

• Отключены все второстепенные службы и приложения
• Устройство используется монопольно
• На устройстве жёстко выставлен режим работы

Например, для тестирования CPU типичная практика – это установка всех процессорных ядер и частот в равное значение и их фиксация. При необходимости отключение всех ядер, кроме того, на котором происходит тестирование.

Следует убедиться, что значение
/sys/devices/system/cpu/cpuX/cpufreq/online так же установлено правильно в зависимости от бенчмарки\профиля и\или потребностей тестирования.
Только убедившись, что всё работает в нужном режиме (cat /proc/cpuinfo) можно начинать тестирование и анализ.

Для упрощения работы и отладки native-кода, для Android существует набор утилит busybox, который не входит в поставку Android по умолчанию (т.к. поставляется по лицензии GPL 2.0).
[, [[, ar, arp, awk, base64, basename, bbconfig, beep, blkid, blockdev, bootchartd, bunzip2, bzcat, bzip2, cal, cat, catv, chat, chattr, chgrp, chmod, chown, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cttyhack, cut, dc, dd, deallocvt, depmod, devmem, diff, dirname, dmesg, dnsd, dos2unix, dpkg, dpkg-deb, du, dumpkmap, echo, ed, egrep, env, envdir, envuidgid, expand, expr, fakeidentd, false, fbset, fbsplash, fdflush, fdformat, fdisk, fgconsole, fgrep, find, findfs, flash_lock, flash_unlock, flashcp, flock, fold, free, freeramdisk, fsync, ftpd, ftpget, ftpput, fuser, getopt, grep, gunzip, gzip, halt, hd, hdparm, head, hexdump, httpd, hwclock, ifconfig, ifdown, ifup, init, inotifyd, insmod, install, iostat, ip, ipaddr, ipcalc, iplink, iproute, iprule, iptunnel, klogd, less, linuxrc, ln, loadkmap, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lsof, lspci, lsusb, lzcat, lzma, lzop, lzopcat, makedevs, makemime, man, md5sum, mdev, mesg, mkdir, mkfifo, mknod, mkswap, mktemp, modinfo, modprobe, more, mpstat, mv, nbd-client, nc, netstat, nice, nmeter, nohup, od, openvt, patch, pidof, ping, pipe_progress, pmap, popmaildir, poweroff, powertop, printenv, printf, ps, pscan, pstree, pwd, pwdx, raidautorun, rdev, readlink, readprofile, realpath, reboot, reformime, renice, reset, resize, rev, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run-parts, runsv, runsvdir, rx, script, scriptreplay, sed, sendmail, seq, setconsole, setkeycodes, setlogcons, setserial, setsid, setuidgid, sha1sum, sha256sum, sha3sum, sha512sum, showkey, sleep, smemcap, softlimit, sort, split, start-stop-daemon, strings, stty, sum, sv, svlogd, switch_root, sync, sysctl, tac, tail, tar, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, timeout, top, touch, tr, traceroute, true, ttysize, tunctl, tune2fs, udpsvd, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unlzop, unxz, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, volname, watch, wc, wget, which, whoami, whois, xargs, xz, xzcat, yes, zcat

Использование подхода, описанного в статье, позволяет быстро и легко портировать тестирование из Linux на Android, создавать с нуля и производить отладку для различных конфигураций оборудования и эмуляторов с наименьшими затратами времени.

Декомпиляция и отладка Android-приложений

В статье будет рассказано о том, как подключить отладчик к Android-приложению и пошагово пройти через вызываемые методы, используя информацию, полученную после декомпиляции приложения.

Автор: Eric Gruber

В статье будет рассказано о том, как подключить отладчик к Android-приложению и пошагово пройти через вызываемые методы, используя информацию, полученную после декомпиляции приложения. Хорошая новость в том, что для отладки не требуются привилегии суперпользователя. Описанные техники могут быть очень кстати во время пентестов мобильных приложений, поскольку мы можем «проникнуть» в код во время работы программы, получить и записать информацию, к которой обычно у нас нет доступа. Например, можно перехватить трафик перед шифрованием и на лету получить ключи, пароли и любую другую ценную информацию. Статья будет полезна пентестерам и разработчикам мобильных приложений, желающих получить более глубокие знания о возможных атаках на платформе Android.

Требования к тестовой среде:

• Операционная система: Windows / Mac OS X / Linux
• Java (рекомендуется версия 1.7)
• IDE (Eclipse, IntelliJ IDEA, Android Studio)
• Android SDK (https://developer.android.com/sdk/index.html?hl=i)
• APKTool (https://code.google.com/p/android-apktool/)/APK Studio (http://apkstudio.codeplex.com)
• Устройство / эмулятор на базе Android
• Dex2Jar (https://code.google.com/p/dex2jar/)
• JD-GUI (http://jd.benow.ca/)

В статье будет использоваться следующая конфигурация: Windows 8, Android Studio и IntelliJ IDEA. Устройство: Nexus 4 с Android версии 4.4.4. Рекомендую все утилиты добавить в переменную окружения PATH, чтобы облегчить и ускорить доступ к этим инструментам.

Android application package (APK), используемый в статье, можно скачать отсюда: com.netspi.egruber.test.apk.

Настройка устройства

Инструкция ниже поможет вам подготовить устройство для экспериментов.

Активация раздела Developer Options

Для начала на Android-устройстве должна быть разрешена отладка через USB (опция USB debugging), что позволит «общаться» с девайсом при помощи инструментов из набора Android SDK. Однако перед этим необходимо активировать раздел Developer options. На устройстве зайдите в раздел Settings > About Phone и кликните несколько раз на пункт Build Number, после чего должно появиться сообщение о том, что раздел Developer options активирован.

Рисунок 1: Для того чтобы активировать раздел Developer options, необходимо несколько раз кликнуть на Build number

Разрешение отладки через USB

Чтобы разрешить отладку через USB-порт, зайдите в раздел Settings > Developer options и отметьте флажок напротив USB debugging.

Рисунок 2: Включение опции USB debugging

Подключение устройства и запуск ADB

После подключение устройства к компьютеру через USB-порт, должно появиться сообщение «USB debugging connected on the device». Также следует проверить, можно ли подключиться к устройству при помощи приложения Android Debug Bridge (ADB), входящего в состав Android SDK (пакет Android SDK Platform-tools). В командной строке введите следующую команду:

Устройство должно отобразиться в списке.

Рисунок 3: Список подключенных устройств

Если устройство не отобразилось в списке, то наиболее вероятная причина в некорректно установленных драйверах (в Windows). В зависимости от устройства драйвер можно найти либо в Android SDK, либо на сайте производителя.

Проверка приложения на возможность отладки

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

Первый способ – запустить Android Device Monitor, входящий в состав Android SDK (в папке tools). В Windows файл называется monitor.bat. При открытии Android Device Monitor устройство отобразится в разделе Devices.

Рисунок 4: Приложение Android Device Monitor

Если какое-либо приложение на устройстве можно отлаживать, это приложение также отобразится в списке. Я создал тестовую программу, но список пуст, поскольку программу отлаживать нельзя.

Второй способ проверить приложение на возможность отладки – исследовать файл AndroidManifest.xml из пакета приложения (APK, Android application package). APK представляет собой zip-архив, содержащий всю информацию, необходимую для запуска приложения на Android-устройстве.

Всякий раз, когда приложения загружается из Google Play Store, также загружается и пакет приложения. Все загруженные APK-файлы обычно хранятся на устройстве в папке /data/app. Если у вас нет прав суперпользователя, вы не сможете получить список файлов из директории /data/app. Хотя, если вы знаете имя APK-файла, можете скопировать его при помощи утилиты adb. Чтобы узнать имя APK-файла, введите следующую команду:

Появится командная строка устройства. Затем введите следующую команду:

pm list packages -f

Отобразится список всех пакетов на устройстве.

Рисунок 5: Перечень пакетов на устройстве

Глядя на список, находим тестовое приложение.

Рисунок 6: Пакет созданного тестового приложения (выделено белым)

Теперь необходимо скопировать файл пакета. Открываем шелл и вводим следующую команду:

adb pull /data/app/[.apk file] [location]

Рисунок 7: Копируем APK-файл с устройства в систему

Теперь нужно открыть файл пакета и исследовать содержимое AndroidManifest.xml. К сожалению, мы не можем просто так распаковать архив, поскольку APK-файл закодирован в бинарном формате. Для раскодировки чаще всего используется утилита apktool, хотя я использую APK Studio, поскольку у этого приложения дружелюбный графический интерфейс. Далее в статье будет рассказываться об APK Studio.

В APK Studio кликните на маленькую зеленую иконку, задайте имя проекту и укажите путь к APK файлу. Затем укажите пусть для сохранения проекта.

Рисунок 8: Создание нового проекта в APK Studio

После открытия APK выберите файл AndroidManifest.xml и посмотрите параметры тега application. Если флаг android:debuggable отсутствует (или присутствует, но установлено значение false), значит, приложение отлаживать нельзя.

Рисунок 9: Содержимое файла AndroidManifest.xml

Модификация файла AndroidManifest.xml

При помощи утилиты apktool или APK Studio мы можем модифицировать файлы и упаковывать содержимое обратно в пакет. Сейчас мы изменим файл AndroidManifest.xml так, чтобы приложение можно было отлаживать. Добавляем внутрь тега application строчку android:debuggable="true".

Рисунок 10: Изменяем содержимое тега application

После добавления флага кликаем на иконку «молоток» и заново собираем пакет. Пересобранный пакет будет находиться в директории build/apk.

Рисунок 11: Повторная сборка пакета завершилась успешно

После пересборки пакет подписывается и его можно заново установить на устройстве (все Android-приложения должны быть подписаны). Большинство приложений не проверяет сертификат, при помощи которого происходит подпись. В противном случае необходимо изменить код, выполняющий эту проверку.

Теперь нужно установить пересобранный пакет. Вначале удаляем старое приложение при помощи следующей команды:

adb pm uninstall[package name]

Затем устанавливаем новый пакет:

adb install [.apk file]

Также можно удалить и установить пакет одной командой:

adb install -r [.apk file]

Рисунок 12: Установка пересобранного пакета

Проверьте, чтобы переустановленное приложение корректно запускалось на устройстве. Если все работает, переходим обратно в Android Device Monitor, где должно появиться тестовое приложение.

Рисунок 13: Теперь пересобранное приложение можно отлаживать

Настройка среды разработки (IDE)

Теперь к пересобранному приложению можно подцепить отладчик, но вначале нужно создать проект в среде разработки (в статье используется IntelliJ IDEA). Создаем новый проект. В поле Application name указываем произвольное имя. В поле Package name указываем имя, в точности совпадающее с иерархией папок пересобранного пакета.

Рисунок 14: Создание нового проекта в IntelliJ IDEA

Обычно имя APK-файла совпадает со структурой папок, хотя, если вы не уверены, в APK Studio проверьте иерархию директорий до папки, где находятся файлы приложений. В моем случае имя и структура папок полностью совпадают (com.netspi.egruber.test).

Рисунок 15: Иерархия директорий тестового приложения

Снимите флажок «Create Hello World Activity» и завершите создание проекта (все остальные параметры остаются по умолчанию). Новый проект должен выглядеть примерно так:

Рисунок 16: Иерархия папок и файлов нового проекта

После создания проекта нужно добавить исходный код из APK-файла для того, чтобы отладчик «знал» имена символов, методов, переменных и т. д. Хорошая новость в том, что Android-приложения можно декомпилировать практически без потери качества (исходный код будет совпадать с оригиналом). После декомпиляции исходный текст импортируется в среду разработки (IDE).

Получение исходных текстов из пакета приложения

Для начала необходимо преобразовать APK в jar-файл. Затем мы при помощи java-декомпилятора получим исходный текст приложения. Преобразование в jar будем делать при помощи утилиты dex2jar. У dex2jar есть файл d2j-dex2jar.bat, используемый для конвертирования APK в jar. Синтаксис команды довольно прост:

d2j-dex2jar.bat [.apk file]

Рисунок 17: Преобразование APK в jar

Затем открываем или перетаскиваем полученный файл в JD-GUI (это java-декомпилятор).

Рисунок 18: Структура jar-файла

Jar-файл должен отобразиться в виде иерархической структуры, внутри которой находятся java-файлы с читабельным исходным кодом. Заходим в File > Save All Sources, чтобы упаковать все исходные тексты в zip-архив.

Рисунок 19: Сохранение исходных текстов декомпилированного файла

После сохранения исходных текстов распаковываем архив в отдельную директорию.

Рисунок 20: Распакованный архив

Теперь нужно импортировать обе директории в созданный ранее проект в IDE. В IntelliJ заходим в папку src и копируем туда содержимое распакованного архива (две директории).

Рисунок 21: Обе папки скопированы в директорию src

Возвращаясь в Intellij, видим обновленный проект.

Рисунок 22: В проекте появились исходные тексты

Если мы кликнем на какой-нибудь элемент из списка, то увидим исходный текст. Как видно на скриншоте ниже (исходный текст класса LoginActivity), исходный код обфусцирован при помощи ProGuard.

Рисунок 23: Обфусцированный исходный текст класса LoginActivity

Подключение отладчика

Теперь, когда в проекте появились исходные тексты, мы можем начать устанавливать точки останова на методах и переменных. По достижению точек останова приложение будет останавливаться. В качестве примера я установил точку останова на методе (прямо в обфусцированном коде), отвечающим за обработку информации, введенной в текстовом поле.

Рисунок 24: Поставлена точка останова на обфусцированный метод

Как только появилась точка останова, подключаем отладчик к процессу на устройстве, кликнув на иконку с экраном в правом верхнем углу (на вашей IDE иконка может отличаться).

Рисунок 25: Подключаем отладчик к процессу

Далее вам будет предложено выбрать процесс, к которому нужно подключиться. Будут отображены только процессы с флагом android:debuggable="true".

Рисунок 26: Перечень процессов для подключения отладчика

После выбора процесса отладчик подсоединится к устройству.

Рисунок 27: Отладчик подключен к процессу, запущенному на устройстве

В текстовое поле я буду вводить число 42 (если помните, на соответствующем методе стоит точка останова).

Рисунок 28: В текстовое поле вводим число 42

После нажатия на кнопку «Enter Code» выполнение приложения прервется на точке останова, поскольку отладчик «осведомлен», какой метод вызывается на устройстве. Скомпилированное Android-приложение содержит отладочную информацию (например, имена переменных), доступную любому отладчику, совместимому с Java Debug Wire Protocol (JDWP). Если в приложении разрешена отладка, отладчик, совместимый с JDWP (в эту категорию попадает большинство отладчиков идущих в составе сред разработки для Java), сможет подсоединиться к виртуальной машине Android-приложения, а затем считывать и выполнять отладочные команды.

Рисунок 29: Сработала точка останова

На скриншоте ниже видно число, которое ранее мы ввели в текстовом поле.

Рисунок 30: Перечень переменных текущего экземпляра класса

Мы можем не только считывать данные в приложении, но и вставлять свои собственные. Это может быть полезно, если мы, например, захотим прервать поток выполнения кода и обойти некоторые участки алгоритма. При помощи отладчика мы можем лучше понять логику работы приложения и проанализировать то, что недоступно обычному пользователю. Например, может оказаться очень полезным просмотр используемых функций шифрования и динамические ключи. Кроме того, иногда при отладке полезно знать, как функции взаимодействуют с файловой системой или базой данных, чтобы понять какая информация сохраняется приложением. Подобные манипуляции доступны на любом Android-устройстве без привилегий суперпользователя.

Как производить отладку кода решения написанного для мобильного устройства

Отладку программы для Android можно производить несколькими способами — с помощью эмулятора, через подключение USB и через сетевое подключение TCP/IP (например по Wi-Fi).

[Отладка с помощью эмулятора]

В среду Android Studio уже встроен эмулятор устройств Android, на котором можно отлаживать свои программы. Достоинство такого метода в том, что нет необходимости покупать специально для отладки смартфон или другое устройство с установленной системой Android, и можно точно подобрать конфигурацию эмулируемого устройства. Недостаток состоит в том, что эмулятор работает очень медленно, и он очень требователен к хосту, на котором идет отладка — и к памяти, и к процессорным ресурсам.

[Отладка через USB]

Описание процесса запуска отладки под Windows XP в Android Studio, по шагам:

1. Сначала нужно разрешить режим отладки USB. Войдите в Настройки -> Параметры разработчика -> Поставьте галочку «Отладка USB». Высветится предупреждение, подтвердите положительно — «Да».

2. Нужно на компьютере установить драйвер Android ADB Driver. Это можно сделать, если скачать и запустить программу UsbDriverTool-sfx.exe [4,5]. После запуска укажите папку, куда нужно распаковать утилиту, например c:\temp, утилита распакуется в папку c:\temp\UsbDriverTool\. В папке c:\temp\UsbDriverTool\AndroidUsb\ будет находиться драйвер Android ADB Driver, который нам нужен.

3. Подключите Ваш смартфон с Android через USB к компьютеру. Внимание, это важно: на смартфоне должен определиться режим «Подключен как камера (PTP)», ни в коем случае не как USB Mass Storage устройство/флешка и не Мультимедиа-устройство MTP. Компьютер обнаружит новое устройство, запустится мастер установки драйвера. Подсуньте ему папку c:\temp\UsbDriverTool\AndroidUsb.

Установить драйвер можно также с помощью утилиты UsbDriverTool.exe, которая находится в архиве [5]. Запустите эту программу при подключенном через USB Android-устройстве. На стартовом экране будет отображено устройство SAMSUNG_Android:

Выберите строку с устройством Android и нажмите кнопку Change driver type. Появится следующий экран, где будет предложено выбрать тип драйвера.

Выберите Android ADB Driver и нажмите Install. Через несколько секунд драйвер установится и будет готов к работе.

4. Запустите Android Studio. Откройте Ваш проект программы (или создайте новый). Зайдите в меню Run -> Edit Configurations. слева в дереве настроек выберите Android Application -> MyApplication (Ваше созданное приложение) -> справа выберите в Target Device радиокнопку «USB Device», нажмите OK.

5. Запустите приложение на отладку.

Если в консоли отладки видите сообщение «Waiting for device. USB device not found», и в Android Debug Monitor Вы получаете сообщения типа «Unable to debug device: samsung-gt_n7000-0019a2fe5212ce» или «Missing forwarded port for 0019a2fe5212ce» — переподключите устройство к USB и попробуйте заново запустить отладку.

[Отладка через Wi-Fi]

ADB можно запустить по каналу связи TCP/IP, для чего можно использовать подключение Wi-Fi. Отладка через Wi-Fi является необычайно удобной. Не нужны провода, и отладка программы запускается очень быстро, так же как и при отладке через USB. Означает, что при отладке можно подключить устройство через коннектор USB к зарядке или куда-то еще. Это особенно удобно, когда отлаживаемых устройств Android у Вас больше, чем портов USB, и когда Вы хотели бы тестировать Ваши последние сборки через сеть, с помощью других людей. Подробнее про adb можно прочитать в [7]. Здесь приведено пошаговое руководство, как запустить такую отладку (подразумевается, что у Вас на компьютере уже установлены Android SDK, ADB, и Вы можете осуществлять отладку программ через USB).

1. Подключите устройство Android к Вашему компьютеру через USB в режиме разрешенной отладки через USB (как этот режим включается — см. раздел «Отладка через USB»). Перейдите в папку, где находится утилита adb.exe (на операционных системах Windows это обычно папка c:\Program Files\Android\android-studio\sdk\platform-tools), запустите интерпретатор команд cmd и введите команду:

В ответ должно быть выведено сообщение:

Если у Вас была запущена среда Android Studio, и Вы следили за консолью Devices и логом сообщений logcat, то в этот момент увидите, что подключенное устройство Android исчезло из списка, в logcat перестали появляться новые сообщения. Сейчас Вы разрешили отладку через TCP/IP соединение с использованием порта 5555 (Вы также можете использовать любой другой свободный порт), осталось подключить ADB к устройству Android.

2. Теперь нужно узнать, какой IP-адрес у устройства Android. Этот адрес он получил, когда подключился к сети Wi-Fi. Адрес можно узнать, если зайти в Настройки -> Об устройстве -> Состояние (Settings -> About -> Status).

Итак, у нашего устройства IP-адрес 192.168.0.53. Теперь введите следующую команду:

В ответ получите сообщение:

3. Если Ваш компьютер находится в той же подсети (192.168.0/24), то теперь в среде Android Studio консоль Devices покажет подключенное устройство Android, и Вы свободно можете производить отладку точно так же, как раньше это делали через USB. Состояние моста ADB можно проверить командой:

В ответ должен быть выведен список подключенных устройств:

В Вашей среде разработки теперь доступен лог Logcat, и можно запустить на отладку Ваше разрабатываемое приложение. Будут работать следующие функции (как и при отладке через USB):

• Вывод Logcat.
• Развертывание отлаживаемого приложения на устройстве (копирование его из среды разработки в устройство).
• Отладка приложения.
• Создание скриншотов через ADB.

[Отладка на виртуальном устройстве AVD]

AVD переводится как Android Virtual Device. Программа AVD Manager позволяет создавать такие виртуальные устройства, которые Вы можете использовать при отладке своих программ. Отладка на AVD имеет свои преимущества, потому что позволяет создать множество устройств Android с разными характеристиками (разное разрешение экрана, разные версии операционной системы Android, разный объем памяти и т. п.). Однако отладка на AVD работает чрезвычайно медленно, и очень требовательна к ресурсам хостового компьютера, который запускает AVD (как по памяти, так и по процессорному времени). Ускорить отладку на AVD можно, если запускать виртуальное устройство из снапшотов (это настраивается при создании виртуального устройства), или если применить специальные приемы работы с эмулятором [6], но в любом случае отладка на реальном устройстве предпочтительнее отладки на AVD.

В среде Android Studio виртуальные устройства создаются запуском программы AVD Manager через меню Tools -> Android -> AVD Manager. В Eclipse виртуальные устройства создаются и настраиваются через меню Window -> Android Virtual Device Manager. Также AVD Manager можно запустить из командной строки, если выполнить команду android.bat avd. Скрипт android.bat находится в директории sdk\tools, папка установленного SDK (пакет SDK входит в состав ADT на основе Eclipse и также входит в установку Android Studio).

[LogCat]

Система Android предоставляет мощное средство вывода отладочных сообщений LogCat. LogGat позволяет в режиме реального времени, не останавливая программу, выводить текстовые сообщения в консоль, что дает возможность разобраться — что именно сейчас происходит в программе.

В системе разработки Eclipse консоль LogCat открывается автоматически после запуска отлаживаемой программы.

LogCat поддерживает разные уровни вывода сообщений:

Благодаря наличию уровней сообщений их можно грубо отфильтровать по уровню. Например, вот так это делается в консоли LogCat в среде Eclipse:

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

Чтобы вывести что-то в лог, сначала определитесь, насколько критичным должно быть выводимое сообщение (должно ли оно быть в категории отладочной информации (d, Debug), или это должно быть просто информационное сообщение (i, Info), или это должно быть предупреждение (w, Warning) или это должно быть сообщение об ошибке (e, Error)? После этого используйте для вывода подходящий метод:

Первый параметр myApp предоставляет текстовую метку, которая позволяет дополнительно отфильтровать сообщения в логе. Это может оказаться полезным, когда сообщений слишком много, и найти нужное сообщение будет проще, если заранее знать её метку. В консоли LogCat Eclipse такой фильтр можно создать кнопкой с зеленым плюсиком «Add new logcat filter».

Примечание: после отладочного запуска приложения в Eclipse один такой фильтр создается автоматически по имени пакета приложения. В этот фильтр попадут сообщения, которые система Android сама сгенерирует в ответ на события, относящиеся к Вашему приложению.

и в файл Android.mk добавьте строку

После этого для вывода в LogCat можете использовать функции __android_log_vprintf и __android_log_printf. Однако эти функции напрямую вызывать достаточно неудобно, поэтому есть смысл создать для них специальный класс Log: