Установка SDK, знакомство с SDK, инструменты SDK.

В этой части пробежимся по верхушкам Android Software Development Kit (SDK), посмотрим, как он устроен, какие инструменты в него входят и как с этими инструментами работать. Особо углубляться в детали не будем, лишь поиграемся с отдельными программами, чтобы понять, как там всё работает.

Текст статьи (ссылки, описания, инструкции) актуален на март 2013 года.

Подготовка и установка SDK¶

Итак, приступим. Прежде всего вам необходимо установить java sdk, одного только java runtime для полноценной работы Android SDK недостаточно.

Напомню, что у меня везде речь идёт только о линуксе. Для начала создаём на компьютере каталог ~/android, там у нас будет лежать всё нужное для работы. Я это делаю специально, чтобы все инструменты находились в одном месте и во всех последующих статьях подразумевается, что SDK установлен ровно так, как сейчас будет описано.

% mkdir ~/android
% cd ~/android

Дальше скачиваем в этот каталог архив SDK (ссылку берём с официального сайта) и распаковываем (скачанный файл обычно называется как-то типа adt-bundle-linux-x86-20130219.zip, он достаточно большой):

% unzip adt-bundle-linux-x86-20130219.zip

В этом архиве находится базовая часть SDK, она распаковалась в каталог с именем типа adt-bundle-linux-x86-20130219, можете туда зайти и посмотреть, что там вообще есть, запускать пока ничего не надо. А лежит там собственно SDK и предварительно настроенная среда разработки Eclipse со всеми необходимыми плагинами. Не переименовывайте и не перемещайте никакие файлы или каталоги внутри каталога SDK, этим вы можете сломать работу Eclipse. Более подробно о файлах в SDK можно почитать на офсайте.

Начнём с Eclipse ADT, он запускается такой командой (вместо adt-bundle-linux-x86-20130219 может быть другой путь, зависит от версии скачанного SDK, дальше во всех именах файлов я его буду обозначать как adt-bundle-<OS-PLATFORM>):

% ~/android/adt-bundle-<OS-PLATFORM>/eclipse/eclipse

Можете создать симлинку или ещё как-нибудь запомнить эту команду. При первом запуске вам предложат выбрать каталог для проектов, вариант по умолчанию вполне годится, можно ничего не менять. Сразу после запуска вы увидите приветсвенный экран с короткой информацией по ADT и SDK. Всё на английском, конечно, привыкайте.

Информация Дальше в этой статье и во всех последующих последующих я буду Eclipse ADT называть просто ADT (сокращение от Android Development Toold).

Из окна ADT запускаем менеджер SDK, через меню Window → Android SDK Manager. Выглядит он примерно так:

SDK устроен по модульному принципу, модули можно устанавливать и удалять по мере необходимости. Некоторые инструменты из SDK можно запускать как в диалоговом режиме с гуёвыми окошками, так и в режиме командной строки; второй режим иногда удобнее, так как позволяет очень гибко настраивать программное окружение.

По умолчанию менеджер SDK предлагает поставить модули для самых последних версий андроида. Но нам пока этого не надо, поэтому снимем все галочки (для этого можно кликнуть по ссылке Deselect all в этом окне), но выберем модуль Android SDK Platform-tools и установим его (для этого нажмём кнопку внизу справа, на ней ещё написано что-то типа Install 1 package..., соглашаемся с условиями лицензии, ну разберётесь, короче, не в первый раз ставить программы; впрочем, этот модуль может быть уже установлен, если вы только что скачали последнюю версию SDK). В этом модуле Platform tools содержатся всякие важные программы, с ними мы чуть позднее поработаем.

Менеджер SDK весьма глючен, поэтому настоятельно советую его перезагружать после каждой установки модулей.

Архитектура SDK¶

В своём составе SDK содержит эмулятор андроидных платформ, он построен на базе qemu и весьма нетороплив (мягко говоря). Эмулятор позволяет создавать виртуальные устройства (Android Virtual Device или AVD в терминологии SDK), на которых можно запускать и тестировать создаваемые приложения. Советую аббревиатуру AVD запомнить, она дальше будет неоднократно всплывать.

Модули SDK можно разделить на две группы: в первую входят модули с данными для разработки приложений под конкретную версию андроидной платформы, они в списке обычно обозначены как SDK Platform внутри «папки» с названием версии платформы, также в неё входят дополнительные компоненты для конкретных девайсов, например, для планшета Samsung Galaxy Tab есть отдельный модуль Android 2.2/GALAXY Tab by Samsung Electronics.; во вторую группу входят все остальные модули (примеры кода, например, или модули для поддержки гугловых сервисов, или документация по API).

Модуль SDK Platform обычно распаковывается в каталог ~/android/adt-bundle-<OS-PLATFORM>/platforms/platform-NNN, где NNN — номер версии API платформы (число). Для каждого мажорного релиза платформы выпускается новая версия API, к примеру, для Android 2.2 номер версии API — 8, для Android 2.3.1 — 9, для Android 2.3.3 — 10, для Android 4.2.2 — 17 и так далее. В модуле содержатся файлы, необходимые для запуска данной платформы в эмуляторе андроидных платформ. Сразу же скажу, что в этом модуле не установлены гугловые сервисы для работы Google Maps, к примеру. Модули с поддержкой Google API выделены отдельно и обычно называются Google APIs by Google Inc.¹ В принципе, все модули, разворачивающиеся в каталоге ~/android/adt-bundle-<OS-PLATFORM>/platforms по структуре примерно одинаковы — там содержатся файлы, из которых создаётся образ виртуального девайса AVD.

Работа с виртуальными девайсами¶

Чтобы создать виртуальный девайс, нужно сначала установить модуль с образами для него, например, модуль с образом «голого» андроида (модуль с именем SDK Platform любой версии API); или образ какого-нибудь девайса, например, Galaxy Tab (модуль называется Android 2.2 (API 8)/GALAXY Tab by Samsung Electronics).

Менеджер виртуальных девайсов можно запустить либо из окна Eclipse ADT (меню Window → Android Virtual Device Manager), либо из окна менеджера SDK (меню Tools → Manage AVDS...) Выглядит этот менеджер вот так:

Чтобы создать новый девайс, жмём New..., открывается примерно такой диалог (здесь поля уже заполнены, об их значении —после скриншота):

В поле AVD Name вводим название девайса, для начала сойдёт что-нибудь типа test-111, из списка Device выбираем «реальный» аппарат, который мы хотим эмулировать (или просто разрешение экрана), из списка Target выбираем образ на основе которого будет создан девайс. В группе Memory options указываем параметры оперативной памяти устройства. В поле Internal storage вводим размер «встроенной флешки», также можно задать размер «внешней» флешки. Когда всё сделано, жмём OK. На остальные поля в диалоге можете пока забить, значения по умолчанию сгодятся. После некоторой паузы показывается диалог со списком фич виртуального девайса и в списке должна появиться новая строчка, выделяем её и кликаем по кнопке Start..., далее на Launch. Загрузка девайса может занять немало времени, но в итоге всё загрузится как надо: на экране появляется новое окно с изображением экрана устройства, можно по экрану кликать мышкой (это аналог тыка пальцем по экрану), можно тыкать на «хардварные» кнопки сбоку.

Информация Виртуальные девайсы физически создаются в каталоге ~/.android/avd, для каждого девайса с именем NNNN там создаётся каталог NNN.avd с образами дисков и памяти, а также конфиг NNN.ini. Запускать нужный образ в эмуляторе можно такой командой (в аргументе -avd указываем имя нашего девайса, в данном случае это test-111): % ~/android/adt-bundle-/tools/emulator -avd test-111

У команды emulator есть куча разнообразных полезных параметров, полный список можно посмотреть командой:

% emulator -help

Совет Очень рекомендую добавить каталоги ~/android/adt-bundle-<OS-PLATFORM>/tools и ~/android/adt-bundle-<OS-PLATFORM>/platform-tools в переменную окружения PATH, чтобы программы из этих каталогов можно было вызывать откуда угодно без указания полного пути. Дальше я предполагаю, что вы это сделали, поэтому имена программ буду указывать без пути к каталогу, где они лежат.

Android Debug Bridge (ADB)¶

В SDK есть средства подключения к девайсу с андроидом, причём они работают совершенно одинаково как с реальными, так и с виртуальными железками. На прошлом шаге мы запустили виртуальный девайс в эмуляторе, давайте теперь прицепимся к нему при помощи инструментов SDK.

Первый из них называется Android Debug Bridge — это утилита командной строки, называется adb, лежит в каталоге ~/android/adt-bundle-<OS-PLATFORM>/platform-tools и позволяет выполнять отладочные работы на подключенном устройстве.

К этому моменту у нас где-то должно болтаться окно с запущенным виртуальным девайсом, вот к нему и будем подключаться. Сначала посмотрим, какие вообще девайсы нам доступны для отладки:

% adb devices
List of devices attached 
emulator-5554   device

Итак, видим девайс с названием emulator-5554, с ним и будем работать. Все доступные опции программы adb можно посмотреть командой adb help, она покажет длинный список всевозможных опций с достаточно подробным описанием каждой.

Давайте посмотрим системный лог нашего виртуального девайса, это делается так (выйти из него можно через стандартный хоткей Ctrl+C):

% adb logcat

Анализ системного лога — это один из важнейших инструментов отладки, в лог сыплются записи о любом действии, произошедшем на устройстве, туда же пишутся детальные сообщения об ошибках выполнения программ, отладочная информация. Команда adb logcat выводит на экран все записи из лога, которые хранятся на девайсе на момент вызова, после чего продолжает работать, выводя новые сообщения по мере их генерации. У команды logcat есть опции фильтрации, в которых указывается, что именно мы хотим видеть. Полное и детальное описание этой программы можно найти на девелоперском офсайте андроида.

Ещё немного поиграемся с logcat, сначала немного про формат вывода. Вот небольшой кусок лога:

D/dalvikvm(  119): GC_EXTERNAL_ALLOC freed 4667 objects / 256808 bytes in 324ms
V/MediaScanner(  230): pruneDeadThumbnailFiles... android.database.sqlite.SQLiteCursor@44f17b18
V/MediaScanner(  230): /pruneDeadThumbnailFiles... android.database.sqlite.SQLiteCursor@44f17b18
D/MediaScanner(  230):  prescan time: 987ms
D/MediaScanner(  230):     scan time: 28ms
D/MediaScanner(  230): postscan time: 129ms
D/MediaScanner(  230):    total time: 1144ms
D/MediaScannerService(  230): done scanning volume external
I/Launcher.Model(  119): not binding apps: no Launcher activity

У каждой записи есть приоритет, он обозначается буквой в начале сообщения, например, D означает Debug, то есть отладку; V — это наименьший возможный приоритет, от слова Verbose. Приоритет сообщения указывается программой, которая его сгенерила, всего возможно семь приоритетов (по возрастанию значимости): Verbose, Debug, Info, Warning, Error, Fatal, Silent.

Сразу за приоритетом, после символа / указывается тег сообщения, обычно это название сервиса или программы, сгенерившей сообщение. Далее в скобках указывается PID процесса, а после двоеточия собственно текст сообщения, который программа отправила в лог.

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

% adb logcat -v time

Эта команда печатает перед каждой записью из лога время этого события с точностью до миллисекунд. Другие опции форматирования вы найдёте на странице документации adb.

Информация Если adb видит несколько девайсов, вам придётся указать, какой именно вы хотите использовать. В местных примерах я этого не делаю, так как adb достаточно умная команда и в случае всего одного девайса подцепляется к нему автоматически, однако если девайсов несколько, придётся указать, какой именно нужно использовать при помощи опции -s: adb -s emulator-5554 logcat. Также есть две полезных опции: -d позволяет подключиться к реальному подключенному девайсу, -e — к виртуальному; то есть если у вас подключено два девайса (один виртуальный, другой реальный), то командой adb -e можно подключиться к виртуальному, а командой adb -d — к реальному без ввода идентификатора.

С логом поигрались, теперь вспомним, что на девайсе работает практически полноценный линукс, а у линукса есть терминал, в который можно зайти, выполнив команду adb shell:

% adb shell
root@android:/ # pwd
/
root@android:/ # ls
acct
cache
config
d
data
default.prop
dev
etc
init
init.goldfish.rc
init.rc
init.trace.rc
init.usb.rc
mnt
proc
root
sbin
sdcard
sys
system
ueventd.goldfish.rc
ueventd.rc
vendor

В этом терминале обычно доступны самые базовые линуксовые команды типа ls, pwd, mount, однако опции этих команд могут сильно отличаться от тех, к которым вы привыкли на обычной линукс-машине. Возможности терминала там также довольно скромны, многих привычных фич bash/zsh там точно не будет. Кроме того, полноценный суперюзерский доступ по умолчанию есть только на виртуальных девайсах, производители железок предпочитают давать лишь весьма ограниченный доступ (который, однако, иногда можно расширить до полноценного суперюзерского, эта процедура называется в русском андроид-сообществе рутованием девайса или получением root-доступа).

Можете полазить по файловой системе девайса, посмотреть, что и где там лежит. Вы, несомненно, обнаружите, что от привычной линуксовой машины структура файловой системы довольно сильно отличается. К примеру, нет каталога /usr, однако есть /system, причём этот каталог примонтирован с правами только для чтения, так что даже с суперюзерским доступом туда слазить не получится.

Ещё одна полезная опция прогаммы adb называется bugreport, она собирает и выводит на экран с девайса максимум информации о конфигурации (как программной, так и аппаратной):

% adb bugreport

Dalvik Debug Monitor Server (DDMS)¶

Ещё один крайне полезный инструмент называется Dalvik Debug Monitor Server (DDMS), эта программа находится в каталоге ~/android/adt-bundle-<OS-PLATFORM>/tools и позволяет лазить в недра работающего девайса подобно adb, тоже работает как с виртуальными, так и с реальными железками. Однако в отличие от adb, эта программа не с интерфейсом командной строки, а с полноценным графическим интерфейсом.

Однако обычно нет необходимости запускать DDMS вручную, поскольку программа встроена в Eclipse ADT и оттуда её можно открыть через меню Window → Open Perspective → DDMS.

Если же вы решите запустить ddms вручную, то увидите такое окно:

Через DDMS можно смотреть системный лог девайса, изучать работающие процессы, ходить по файловой системе. Одна из самых полезных фич программы — снятие скриншотов с девайса, делается это через меню Device → Screen Capture или хоткеем Ctrl+S.

Вводный обзор средств SDK на этом и закончим.

Ссылки¶

• Developer Guide/Tools/adb — полная документация по программе adb
• Using DDMS — подробное описание DDMS на девелоперском офсайте андроида.

Читайте в следующей части: установка и настройка eclipse для нашего программного окружения

← предыдущая часть | следующая часть →