Где лежит android sdk

Настройка Android SDK

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

1. Скачать Android SDK

Зайдите на страницу Android Developer SDK. Скачайте архив с последней версией Android SDK и распакуйте его.

2. Установить Android SDK

Следуйте инструкциям на странице Installing the SDK (причём, вы можете свободно пропустить опциональные части, относящиеся к Eclipse). В шаге 4 руководства Installing the SDK убедитесь, что добавили как минимум одну Android platform (Android платформу) с уровнем API равным или выше 9 (платформа 2.3 или выше), Platform Tools и USB drivers (USB драйверы), если вы используете Windows.

3. Удостовериться, что система определяет ваше устройство

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

Для Windows: если Andoid устройство автоматически определяется системой, вам все равно придётся обновить драйверы на те, который поставляются с Android SDK. Это делается через диспетчер устройств Windows. —>Если устройство не определяется автоматически, используйте драйверы из Android SDK или особые драйверы, предоставленные производителем. —>Дополнительную информацию можно найти здесь: USB Drivers for Windows

Для Mac: если вы разрабатываете на OSX, тогда обычно не требуется никаких дополнительных драйверов.

Важно: Не забудьте включить “Отладку по USB” на вашем устройстве. Перейдите в Настройки -> Параметры разработчика , для включения отладки по USB. Начиная с Android Jelly Bean 4.2, параметры разработчика по умолчанию скрыты. Для их включения, понажимайте несколько раз пальцем на строку в меню Настройки -> Об устройстве -> Номер сборки . После этого вам станет доступен пункт Настройки -> Параметры разработчика .

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

4. Добавить путь до Android SDK в Unity

При первой сборке проекта под Android (или если Unity не сможет обнаружить SDK), вас попросят указать местоположение папки, в которую вы установили Android SDK (вы должны выделить корневую папку установленного SDK). Путь до Android SDK также можно изменить в редакторе, выбрав в меню Unity > Preferences и перейдя в раздел External Tools окна настроек.

Добавление пакетов Android SDK Manager

По умолчанию, в Android SDK не установлено все необходимое для начала разработки. Пакет SDK содержит инструменты, платформы и другие компоненты, которые можно загрузить по мере необходимости, используя Android SDK Manager. Поэтому, прежде чем начать, вы должны добавить несколько пакетов в Android SDK.

Чтобы начать добавлять пакеты, запустите Android SDK Manager одним из следующих способов:

• В Android Studio при первом запуске в окне приветствия выберите пункт Configure> SDK Manager
• Если Android Studio уже запущена, выберите пункт меню Tools> Android> SDK Manager.

1. Откроется окно настроек Android SDK:
2. Обязательно выберите такие компоненты:
3. Следующий курс: Создание вашего первого приложения

Откроется окно настроек Android SDK:

На вкладке SDK Platforms отметьте для загрузки все наиболее популярные на текущий момент версии Android. Их список постоянно обновляется на официальном сайте.

Перейдите на вкладку SDK Tools и отметьте для загрузки минимально необходимый набор компонентов, как показано на скриншоте:

Обязательно выберите такие компоненты:

• Android SDK Build-tools
• Android SDK Platform-tools (последняя версия)
• Android SDK Tools (последняя версия)
• Android Support Repository

После выбора нажмите кнопку Apply и дождитесь загрузки всех компонентов.

По окончании загрузки нажмите Finish. Среда разработки готова к работе.

Следующий курс: Создание вашего первого приложения

Вам також може сподобатися

Уроки по android разработке на Java 4 15 225

В этом уроке начинаем обзор способов сохранения данных в android приложениях. Начнем с SharedPreferences.

Уроки создания андроид-приложений на Kotlin 0 102 956

В первом уроке курса по разработке андроид-приложений на языке Kotlin мы установим необходимые средства

Инструменты android разработчика 0 278

Команда опытных android разработчиков делится опытом на бесплатных вебинарах по андроид-программированию и разработке. В

Дизайн android приложений 3 7 475

Как использовать векторную анимацию (Animated Vector Drawable) в андроид-приложениях. Как загрузть в приложение android свою

Уроки по android разработке на Java 0 1 444

Видеоверсия известных уроков Дмитрия Виноградова (startandroid.ru) по программированию и разработке android приложений для смартфонов

Инструменты android разработчика 1 323

Решение часто возникающих вопросов и проблем, с которыми сталкиваются начинающие android разработчики

Коментарі: 8

Прошу помощи. Только начал изучать разработку под андроид и возникла следующая проблема. Есть планшет Nexus 7 2012 WiFi, прошивка CyanogenMOD Android KitKat (4.4.4). Создаю новый пустой (Empty Activity) проект в Android Studio v 3.0.1, вообще ничего не меняю и пытаюсь запустить проект на устройстве – оно устанавливается и планшет переходит в ребут. Далее запускается очень много раз вылетает ошибка, что Trebuchet (это лаунчер) остановлен. Вообщем еле-еле удаляю приложение и всё становиться нормально. SDK установлены с версии 19 (4.4.4) по 26. Минимальный sdk установлен как 19. Такой же проект на Samsung (android 6.0) запускается без проблем. В чём может быть проблема ума не приложу. Мне кажется, что это возможно как-то связано с движком тем Cyanogen а может и нет, так как пробовал прошивку ParanoidAndroid – та же беда. Прошу поставьте меня на путь истинный

admin (автор)

Любые сторонние прошивки вы устанавливаете на свой страх и риск. Нормальная работа системы при этом не гарантируется. Об этом все авторы прошивок пишут.

Это я прекрасно понимаю, и претензий не имею. Дело в том, что система работает стабильно. Остальные приложения которые были изначально написаны для 4.4.4 работают хорошо. И даже современные приложения устанавливаются и работаю -> а это значит, что авторы как то включили поддержку 4.4.4. Возможно ещё где-нибудь нужно нажать “галочку ” для поддержки 4.4.4?

Объясните пожалуйста, зачем нужны эти пакеты? Google APIs ARM EABI v7a System Image
Google APIs
И все пакеты в Extras. Спасибо.

admin (автор)

Google APIs – ARM EABI v7a System Image – это образ эмулятора
Google APIs – API сервисов Google, например Maps или YouTube
в Extras самое необходимое – Android Support repository, android support library, google play services, google usb driver – названия как-бы не нуждаются в объяснении.

Что за WTF?! пишет отказано в доступе и доне нотхинг вас инсталед в конце чё делать

Здравствуйте
У меня установлена AS 2.1
Android SDK Build-tools не установлены (стоит прочерк)
Нужно ли устанавливать Android SDK Build-tools ? Все? И почему по умолчанию они не установлены вообще?

Додати коментар Скасувати відповідь

Щоб відправити коментар вам необхідно авторизуватись.

Внимание, Акция!

Продвинутый курс в подарок!

Новые записи на сайте

• Как создать мобильное приложение на Kotlin с Jetpack Compose и Clean Architecture. Часть 3. Панель поиска Compose 14.04.2023
• Как создать мобильное приложение на Kotlin с Jetpack Compose и Clean Architecture. Часть 2. Слой UI 04.04.2023
• Как создать мобильное приложение на Kotlin с Jetpack Compose, REST API и Clean Architecture. Часть 1. 30.03.2023
• Jetpack Compose – настав час навчитися новому підходу у розробці Android додатків 01.03.2023
• Продвинутый курс по созданию android-приложения Radio App на языке Kotlin с Jetpack Compose 03.02.2022

• Архитектура андроид-приложений
• Дизайн android приложений
• Документация по android
• Изменения версий Android
• Инструменты android разработчика
• Новости
• Новости Андроид
• Продвинутые курсы по разработке мобильных приложений на Android
• Разработка игр для android
• Создаем android-приложения
• Уроки по android разработке на Java
• Уроки по основам Java
• Уроки создания андроид-приложений на Kotlin

Где лежит android sdk

Установка 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- ):

% ~/android/adt-bundle-/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-/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. 1 В принципе, все модули, разворачивающиеся в каталоге ~/android/adt-bundle-/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-/tools и ~/android/adt-bundle-/platform-tools в переменную окружения PATH, чтобы программы из этих каталогов можно было вызывать откуда угодно без указания полного пути. Дальше я предполагаю, что вы это сделали, поэтому имена программ буду указывать без пути к каталогу, где они лежат.

Android Debug Bridge (ADB)¶

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

Первый из них называется Android Debug Bridge — это утилита командной строки, называется adb , лежит в каталоге ~/android/adt-bundle-/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-/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 для нашего программного окружения

1. Содержимое модуля Android 2.2 (API 8)/Google APIs by Google Inc. разворачивается не в каталоге platforms , а в каталоге ~/android/android-sdk-linux/add-ons/addon-google_apis-google_inc_-8 . С другими аддонами — для эмуляторов реальных устройств, например — аналогично. ↩

Комментарии

Гость: Alex | 2012-10-20 в 16:21

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

Я не смог найти у себя дополнительные компоненты для конкретных девайсов, подскажите, пожалуйста, откуда и как их установить

Sergey Stolyarov | 2012-10-20 в 17:30

Они там же в списке показываются, нужно просто поискать. Ну, и не для всех девайсов там есть компоненты, конечно.

Гость: Павел | 2013-09-04 в 20:04

у меня на команду % adb devices пишет adb не является командой

Sergey Stolyarov | 2013-09-04 в 20:13

Значит, программа из текущего каталога не видна. Можно по полному пути вызывать команду, например, типа ~/android/adt-bundle-/platform-tools/adb , вместо подставить нужное значение.

Скучный бложик тестировщика

Об Android, о тестировании, мысли, рекомендации, инструкции.

9 мая 2016 г.

Android SDK. Тестируем по-настоящему!

Эта запись — предпоследняя из всего цикла. Пожалуй, она самая скучная, однако она ближе всего к тому, что называется тестированием. И, мне кажется, она ещё и самая длинная. Я попытался разбавить всю эту скукоту наглядными примерами, скриншотами. Книги с картинками читают охотнее? По крайней мере популярные «блоггеры» (а я — популярный, у меня есть минимум 8 читателей, скоро продамся кому-нибудь и работать перестану!) часто ставят всякие картинки, возможно это и работает.

Как бы то ни было, здесь можно получить минимальное понимание того, что есть в Android SDK и что из этого нужно тестировщику. А главное — зачем. Ещё тут есть море грамматических ошибок, наверное, так как писать большую часть текста приходилось ночью, а я по ночам люблю спать и после 22 часов, как правило, уже сплю.

Уверен, вам было интересно узнать, во сколько я засыпаю. Читайте дальше, там ещё интереснее!

Android SDK

Мы подбираемся всё ближе и ближе к инструментам и методам тестирования. Инструменты для тестирования, а также всякий вспомогательный инструментарий, входит в состави Android SDK. Самые нужные компоненты из состава SDK, конкретно для тестировщиков, это инструменты SDK, они же SDK tools, инструменты сборки, они же Build tools (внезапно, да?) и инструменты платформы, они же Platform tools. Нет никакого смысла запоминать это. Я просто сказал названия папок из установленного пакета Android SDK:

Рис. 1. Содержание папки Android SDK

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

SDK Tools

Здесь лежит набор инструментов, без которых нет смысла и начинать тестирование. Без этих инструментов у вас будет не тестирование, а ловля рыбы в мутной воде. Ключевыми инструментами здесь являются следующие: emulator, monitor, monkeyrunner и, для автоматизваторов, uiautomatorviewer.

Эмулятор

Вообще называется он «Android Virtual Device» (AVD). Он позволяет создавать виртуальные устройства как из шаблонов, типа Nexus 6, Nexus 4, просто «Устройство с экраном на 7 дюймов», так и совсем кастомные, а также и создавать свои шаблоны. Достоинство и недостаток виртуальных устройств именно в их эмуляции. В отличие от виртуальных машин, где, очень грубо и просто говоря, аппаратные возможности и сами устройства хостовой ОС пробрасываются в гостевую ОС, эмулятор вынужден предоставлять совершенно другую архитектуру — ARM. И от того эмулятор ужасно тормозит. За этого его не любят.
Впрочем на Intel процессорах хостовой ОС можно установить HAXM (Intel Hardware Accelerated Execution), который также можно найти в SDK (в extras), и получить отличный прирост производительсности эмулятора Intel процессора. Однако это доступно только для владельцев Intel и на процессорах от AMD HAXM не работает. Но в любом случае, x86 эмуляторы побыстрее ARM’овских.

Вторая, но гораздо более важная проблема, заключается в том, что периодически эмулятор просто отваливается. Вы можете взаимодействовать с ним мышкой и горячими клавишами, но не можете подцепиться через adb (про который я расскажу дальше). Без доступа по adb эмулятор становится просто не нужен. Здесь, кстати, может спасти альтернативный эмулятор — Genymotion, который сделан для исправления типичных проблем штатного эмулятора (и очень популярен!).

Почему же эмулятор ещё жив, если есть реальные устройства, есть альтернативы? Благодаря эмулятору вы можете, например, посмотреть, как будет выглядеть интерфейс приложения на устройстве, которого у вас нет: вы можете в несколько кликов создать вируальное устройство, задав нужное разрешение, плотность точек, соотношение сторон, и поглядеть на интерфейс. Можно и быстро посмотреть реакцию на типовые ситуации — изменение громкости, поворот экрана, изменение скорости подключения к сети и подобное. К тому же образы Android (кстати, образы Android для эмулятора — практически оригинальный AOSP!) обновляются очень оперативно. У вас может не быть образа для Nexus устройства, но для эмулятора он всегда есть. Эмулятор всегда под рукой.

Monitor

Или, как его звали в молодости, DDMS. DDMS теперь (на самом деле давно) деприкейтед, то есть объявлен устаревшим, и эту аббревиатуру можно не запоминать. Расшифровывается она, кстати, Dalvik Debug Monitor Service. Dalvik — это и есть та виртуальная машина, в которой работают Android приложения. Dalvik жил до Android 4.4 включительно, а в Android 5.0 он был заменён на виртуальную машину ART — Android Runtime.
Одно из ключевых отличий ART от Dalvik, в глазах пользователя, это то, что Dalvik компилировал приложения при первом запуске («кэш Далвика» — это вот они), обеспечивая значительное ускорение при повторных вызовах, а ART — при установке. Впрочем, даже эта JIT, Just In Time, то есть «на лету», компиляция байт-кода в машинный появилась лишь в Android 2.2, а до того всё было на одном интерпретаторе. То есть при Dalvik приложения быстрее устанавливаются, но задают жару системе при первом старте. При ART приложения заметно, прям сильно заметно, дольше устанавливаются, зато запускаются шустрее и не создают таких нагрузок при первом старте. На самом деле различий больше, но нас они особо не касаются. Лично мне знание всех этих различий ни разу не пригодилось в работе.

Так вот, monitor, который запускается файлом monitor.bat, представляет собой, кроме всего прочего, графическую оболочку для logcat. Что это такое, я расскажу позже. Здесь нам важно, что в этой оболочке мы можем искать нужные строки, фильтровать их, отслеживать поведение продукта, да ещё пусть и с примитивной, но всё-таки подсветкой. Возможностей у monitor больше, но они либо практически бесполезны, если у вас есть более одного устройства, либо слишком хардкорны для ознакомительной лекции.

Monkeyrunner

Это инструмент, предоставляющий API для взаимодействия с приложениями на устройстве путём отправки на это устройство разных событий. Средствами monkeyrunner можно очень быстро написать скрипт, который будет запускать нужные активити, тыкать в нужные места, вызывать меню, стучать по клавиатуре (включая набор заданных текстов), менять громкость устройства, гасить экран и всё такое прочее. К сожалению, гибко писать тестовые приложения на нём очень трудно, всё же он ориентирован на простоту. Зато с его помощью можно достаточно быстро написать тестовый сценарий, которые будут помогать находить регрессионные ошибки в, скажем, интерфейсе.
Этот инструмент имеет встроенные методы для снятия скриншотов и даже сравнения их между собой! Не следует путать monkeyrunner и monkey, о котором я расскажу позже.

Uiautomatorviewer

Это полезный инструмент, облегчающий написание грей бокс автотестов. Что такое White box, Black box и Gray box тестирование?

• White box — мы знаем о приложении всё, при желании даже в код можем заглянуть. Более того, наше тестовое приложение может обращаться напрямую к тестируемому приложению, топая грязными ногами в его песочнице
• Black box — мы не знаем о приложении ничего. Мы люди простые — мы видим поле ввода, мы вводим туда данные. Ноль, единицу, огромное число, отрицательное число, число с десятичной точкой, число с десятичной запятой, текст, символы юникода, null’ы, скриптовые сценарии, вставляем из буфера обмена сочинения Льва Толстого, картинки, музыкальные файлы, ставим символ юникода, чтобы текст вводился справа налево… В общем — любимое развлечение при типичном исследовательском тестировании
• Gray box — мы кое-что знаем о приложении, но особо с этим сделать ничего не можем. К примеру, мы знаем, как и почему текст меняется при нажатии на кнопку, но программно именно на эту кнопку нажать не можем. «Именно на эту» — это обращение уровня findViewById(R.id.btnPressMeButton), а не уровня «кнопка, которая лежит вот на этом экране, но не первая, а вторая». Когда вы пытаетесь своей маме по телефон объяснить, как сделать скриншот, это вот оно. Вы знаете, как это происходит, вы точно знаете, что должно получиться на каждом из шагов, но сами этого сделать не можете

Так вот когда нужно автоматизировать ввод данных в поле и нажатие на кнопку, то нужно узнать, а что это за ресурсы такие, чтобы обращаться напрямую к ним. Можно, конечно, по координатам тыкать, но это просто смешно — даже одно и тоже устройство может быть в двух положениях, а устройств с разными экранами и разрешениями экранов миллиарды. Здесь на помощь и приходит инструмент uiautomatorviewer.

• Мы подключаем устройство к компьютеру или же запускаем эмулятор
• Запускаем приложение и просим этот инструмент собрать данные обо всём, что он «видит»

Инструмент очень подробно разбирает всё приложение на элементарные элементы и показывает все доступные их свойства. В итоге мы можем своим автотестам обращаться чётко к нужным ресурсам вне зависимости от того, на каком устройстве это приложение было запущено. Что ещё ценно, этот инструмент позволяет сохранить данные о разобранных экранах. Мы можем взять устройство на время, быстро сохранить нужные экраны нужных приложений и вернуть его. А дальше писать сценарий автотеста, посматривая в сохранённые данные.
Чем же это хуже тестирования белого ящика? Тем, что это всё так сладко только в теории. На практике же графический интерфейс приложения может быть построен таким образом, что на нём будет множество «одинаковых» элементов.

Рис. 2. Так uiautomatorviewer «видит» экран настроек режима разработчика (правая верхняя треть) и данные конкретного переключателя, по которым его можно попытаться найти программно (правая нижняя треть)

На скриншоте типичный пример, когда обратиться к конкретному элементу можно, но это уже выходит за рамки «охохо, сейчас мы тут всё быстренько автоматизируем». У переключателя тот же айди ресурса, что и у всех других переключателей. Нет, в R.java (в этом файле перечислены вообще все ресурсы, какие они есть в приложении) у них разные айди, но снаружи этого не видно.
Теперь, чтобы переключить конкретно этот переключатель, нужно рекурсивно перебирать лайауты (это, грубо говоря, форма с пазами, в которые все элементы интерфейса вставляются, а форма уже «следит», чтобы из пазов ничего не уезжало) и по косвенным признакам находить нужный, чтобы уже в нём забраться внутрь и щёлкнуть тумблером. Либо же сразу обратиться к нужному лайауту по его индексу (здесь он имеет индекс 6), внутри которого выбрать дочерний с индексом 1, внутри которого щёлкнуть тумблером.

В первом случае кода будет намного больше, зато небольшие перетасовки интерфейса не сломают автотест, потому что ориентируется он по косвенным признакам (скажем, читает текст и сравнивает с эталонным), однако это уже слабо подходит для тестирования локализаций (потому что в локализациях тексты, понятное дело, меняются). Во втором случае кода совсем мало, можно даже в пару строк уложиться, зато просто перестановка двух вьюх (View здесь — это каждый из элементов интерфейса: каждая кнопка, каждая надпись, каждый переключатель — всё это самостоятельные вьюхи) относительно друг друга полностью сломает автотест. Зато этот метод идеален для тестирования локализаций, потому что для локализаций интерфейс меняют очень редко и нужно, как правило, проверять именно влезание надписей и что эти надписи вообще правильные. А это, между прочим, uiautomatorviewer умеет! Просто потому что он получает ровно те строки, которые видны. То есть если строка вылезает за пределы экрана, вылезшую часть он не «прочтёт».

Build Tools

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

• assets. Здесь, обычно, лежат различные ресурсы, которые используются не для правильного отображения интерфейса на правильных языках, а просто вспомогательные, нужные для нормальной работы. Например, ini файлы, собственные шрифты, открытые криптографические ключи и всякое такое
• lib. Здесь у людей, которые ещё не лишились остатков разума, хранятся библиотеки функций
• META-INF. Место хранения подписи. Все apk файлы подписаны электронной цифровой подписью, подтверждающей целостность файла и принадлежность приложения владельцу. Любое изменение внутри apk файла делает подпись не валидной. Android откажется установить такое приложение, выбросив соответствующее исключение. Также Android откажется установить одно приложение поверх другого, если у них одинаковое внутреннее имя, но разные подписи. Если же внутренние имена пакетов (их, кстати, можно найти в AndroidManifest.xml) и подписи совпадают, то только тогда возможен апгрейд. Это позволяет избежать ситуации, когда поддельное приложение пытается подменить собою настоящее. Так как модифицировать приложение в тестовых целях приходится десятки раз в день, то приходится постоянно переподписывать итоговые apk. В тестовых целях «боевые» подписи использовать строго не рекомендуется!
• res. Здесь хранятся все ресурсы приложения — картинки, звуки, тексты, оффлайн справки. Текстовые ресурсы сгруппированы по языкам, графические — по видам экранов
• AndroidManifest.xml. Об этом файле рассказывалось раньше. Сейчас нам нужно узнать другое. Этот файл представляет собой бинарный XML. То есть его нельзя просто взять и открыть в Notepad++ и с удобством читать на ночь
• classes*.dex. Здесь находится весь программный код продукта. Под декомпиляцией apk файла подразумевается декомпиляция именно этого файла. Обычно файл classes.dex всего один. Но в Android есть некоторые ограничения на количество используемых методов — максимум шестьдесят пять тысяч пятьсот… Кто догадается про последние две цифры? В общем, максимум 65536 методов на один dex файл. Что важно. Речь не об определённых вами методах, а о тех, на которые вы можете сослаться. То есть вы можете подключить библиотеку ради одного метода «сделать хорошо», а она с собой тянет ещё 50 тысяч, которые вы никогда не используете и вообще вам не нужны. Однако счётчик они накрутят! Бест практикс говорит, что нечего подключать библиотеки почём зря. Но кто же их слушает, правда? Кто такие Google с их бест практикс? Вместо этого можно использовать больше файлов classes.dex, нумеруя их. Android обрабатывает эту ситуацию и не спотыкается. Ещё есть обфускаторы, которые для своих целей дробят classes.dex на кучу файлов по своим причинам. Dex, кстати, это привет из прошлого и означает «Dalvik executable», то есть формат, исполняемый виртуальной машиной Dalvik. С переходом на ART никто ничего не переименовывал во имя обратной совместимости
• resources.arsc. Здесь можно найти ссылки на все ресурсы приложения, которые живут в res. Здесь же можно найти все текстовые строки, надписи с кнопок и подобное. Не особо то это нужно в повседневности, но пусть будет. Этот файл также нельзя прочесть как текст, но получить из него и из AndroidManifest.xml данные можно похожим образом, одним и тем же инструментом — aapt.

AAPT

Aapt.exe — утилита, которая используется для выковыривания некоторых данных из приложения. То есть это тестировщики используют её для разбора, а вообще это Android Asset Packing Tool и с её помощью код и ресурсы собираются в единый apk файл. Но у этой утилиты есть параметры запуска, которыми можно и модифицировать apk файлы без привлечения внешних архиваторов и, что важно, получать некоторую информацию. Узнать, какие пермишены использует приложение, проверить, что строка «Папа у Васи силён в математике» была удалена, узнать минимальную версию API, посмотреть внутреннее имя пакета и его версию и всё такое прочее можно сделать одной командой, прочитав нужный файл AndroidManifest.xml или resources.arsc (и не только их можно читать, понятное дело). На выходе вы получите не зашифрованный текст, с которым можете работать.

• Вам нужно убедиться, что новая версия приложения не может быть затёрта более старой версией при установке поверх. Этим занимается сам Android, отслеживая внутренний номер версии, который вообще никакого отношения к версии продукта, к его билду, не имеет. Значение параметра version code отслеживается инсталлятором приложений Android. Если между файлами A.apk и B.apk этот параметр имеет одно и тоже значение, то версии могут быть установлены друг поверх друга в любом порядке. Если у B.apk значение числа в этом параметре будет больше, то B можно будет установить поверх A, а наоборот — нет. Если параметра вообще не будет, то в Маркет приложение залить будет нельзя. Впрочем, Market вообще хорошо следит за этим параметром и не даст залить ту же самую версию или версию ниже, только на повышение
• Вы получили на тестирование чёрный ящик. Так как это Android, то довольно много всего полезного вы всё равно можете получить, сделав из чёрного ящика такой, мутно-серый. Много чего полезного с приложением можно сделать из командной строки через adb. Но почти всегда для этого нужно знать внутреннее имя приложения, оно же package name (это имя уникально для Play Store и самого устройства) и названия операций (активити) этого приложения. Например, зная имя пакета и названия операций, вы можете сделать прямой вызов любого из них (ну, не любого, а тех, у которых установлен флаг exported, который по умолчанию всё-таки установлен) и посмотреть, что же получится. Если это, скажем, приложение программы лояльности KFC, то его падение тут не является какой-то проблемой. Если это защитное приложение (антивирус, антивор, родительский контроль и всё в таком духе), то ни о каких падениях говорить недопустимо, потому что стороннее приложение точно также сможет обратиться к «больному» месту (использовать эту точку входа) и уронить продукт
• Вам нужно убедиться, что для приложения убрали некий пермишен. Можно посмотреть информацию об установленном приложении, а можно отфильтровать вывод команды утилиты aapt в поисках того, что нужно.
• Вам нужно убедиться, что некая строка заменена на другую. Безусловно, нужно её вызвать в продукте по сценарию. Но если весь продукт не менялся и изменение было строго в ресурсах и заключалось в исправлении опечатки, можно отфильтровать вывод этой утилиты, запущенной с нужными параметрами, и посмотреть, что вернёт фильтрация.

zipalign

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

Platform Tools

И, это случилось. Мы дошли до тестирования, наконец! Здесь я расскажу, что такое и для чего используется adb — лучший друг Android тестировщика.

Что такое ADB

Adb — Android Debug Bridge — это консольная многофункциональная утилита, которая позволяет подключаться к запущенному эмулятору или подключенному в режиме отладки устройству и взаимодействовать с ним. Состоит adb из трёх компонентов:

• Клиент. Это сам exe файл, если речь о Windows, который мы запускаем с нужными командами и ключами команд, получая в ответ некоторый результат. То есть клиент выполняет операцию разово
• Сервер. Сервер также работает на вашей машине. Клиент взаимодействует с устройством или эмулятором через сервер. Чтобы каждый раз не поднимать сервер и не тушить его на каждую команду, первый запуск клиента автоматически запускает сервер, который будет работать, пока вы руками его не остановите. Остановить можно как штатной командой adb kill-server так и просто отстрелив его системным диспетчером задач или командой taskkill. Если сервер остановлен и вы хотите, чтобы команды исполнялись сразу в вашем тестовом сценарии, то сделайте предварительный запуск сервиса командой adb start-server. Запуск monitor также поднимает сервер. Потому что получение системных логов с устройства идёт в реальном времени и тут стартом-стопом приложения просто не обойтись
• Демон, который работает на устройстве или эмуляторе. Вы сами не имеете к нему никакого отношения, он является частью прошивки

Одна из прелестей сервера в том, что он может одновременно работать с несколькими устройствами. Вообще сервер ожидает устройства в диапазоне портов 5555-5585. Запоминать эти цифры бессмысленно, во-первых потому что всё несколько сложнее (например, сервер сканирует только нечётные номера из диапазона), во-вторых вы всё равно не будете использовать больше десяти устройств одновременно в худшие из времён. Мой максимум — тестирование на восьми устройствах одновременно:

Рис. 3. Приёмочное тестирование Kaspersky Phound! одновременно на восьми устройствах

Это не значит, что больше десятка устройств одновременно у вас никогда не будет. Это я про тестирование из консоли сказал. А вообще, одновременная проверка какой-то проблемы на нескольких десятках устройств — это не что-то невероятное, такое случается:

Рис. 4. Воспроизведение проблемы с быстрым разрядом батареи. К счастью, этим занимался не я

К слову, если у вас подключено одновременно более одного устройства, то выполнение «adb command» вернёт ожидаемую ошибку о том, что не понятно, к какому из устройств обращаются. Потому, кроме прочего, у adb есть команда devices, которая возвращает список устройств по их серийникам (что берётся в качестве SerialId нам не важно, пусть хоть случайно генерируется от солнечных вспышек), указывая для каждого из них, доступно ли оно, реальное ли это устройство или эмулятор. Но о командах ниже.

Включение отладки через adb

Возможности управления устройством через adb очень широки и многие из них опасны. К примеру, ни одно приложение в AOSP и в тех кастомах, которые не сильно испорчены производителями, не имеет привилегий из своей песочницы взять и перезагрузить устройство. А команда adb reboot мгновенно отправит устройство на перезагрузку, не запрашивая никаких подтверждений. Через adb можно останавливать приложения, а не только прибивать их. В AOSP и не сломанных кастомах остановка приложений дозволена только пользователю через графический интерфейс. Возможностей, которые даёт adb, очень много. И так как с точки зрения безопасности это большая дырка, то Google делает некоторые усложнения для бездумного включения режима отладки.

Android 2.1-2.3

Эти версии Android уже практически никто не поддерживает, так что просто историческая справка. Нужно было зайти в настройки, пункт «Приложения» и там поставить галку разрешения отладки через USB. Что это такое — нигде особо не пояснялось.

Android 3.0-4.1

Включение режима отладки по USB вынесли в отдельный пункт в настройках, который называется «Developer options» или «Инструменты разработчика». Именно во множественном числе, так как появилась возможность не только разрешать отладку через USB (и, кстати, по Wi-Fi), но и включать специальные режимы работы Android, которые по умолчанию выключены, но сюда были вынесены для тех разработчиков, которые понимают, что пункты эти появились не просто так, что в будущем они станут настройками по умолчанию, а сейчас есть возможность протестировать поведение продукта. К примеру, появилась возможность использовать графичекий ускоритель для отрисовки интерфейса. А в Android 4.4 здесь появился пункт, позволяющий перейти на конкретном устройстве с Dalvik на ART, за несколько месяцев до появления Android 5.

Android 4.2-4.2.1

Первое из двух серьёзных улучшений для безопасности. Если ранее Developer options был виден любому человеку и любой мог его включить, открыв таким образом дырку в безопасности (шутка про «хоть что-то у нас в безопасности»), то в 4.2 пункт «Инструменты разработчика» исчез. Его не было в интерфейсе. Чтобы он появился, нужно зайти в настройки системы, выбрать пункт «Об устройстве», найти там строку «Версия сборки» и несколько раз тапнуть по ней. На тапы будут появляться сообщения, что осталось столько то раз, а потом «Вы уже разработчик». Только после этого пункт «Инструменты разработчика» появлялся на старом месте и можно было разрешить отладку по USB. Прямого метода скрытия пункта нет. Предполагается, что раз уж человек сделал такой путь, то он понимает, что делает.

Android 4.2.2

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

Рис. 5. Запрос доверия компьютеру

Если устройство имеет пароль блокировки, то этот запрос системы возникнет под экраном блокировки. То есть если в Android 4.2.1 и ниже пользователь включил режим отладки, то любой злоумышленник, получив физический доступ к устройству, мог работать с ним через adb, минуя блокировку. Начиная с Android 4.2.2 это стало невозможно сделать.

Android 6

Если устройство заблокировано, то по умолчанию к нему нельзя подключиться, так как демон просто не будет отвечать на запросы, потому что все подключения по USB считаются зарядным устройством и adb сервер снаружи никто не ждёт. Нужно перевести устройство в режим MTP для начала.

Ключи, команды и параметры запуска adb

И вот оно, самое-самое. Я расскажу о некоторых, самых популярных командах и ключах команд для adb. Они используются с частотой от несколько раз в месяц до несколько раз в час.

Ключи adb

• Ключ -d означает «device» и сообщает adb, что команда, которая идёт далее, должна быть выполнена на реальном устройстве, а не на эмуляторе. То есть если у вас подключено одно реальное устройство и сколько угодно эмуляторов, то adb -d command отправит command на реальное устройство
• Ключ -e, наоборот, говорит, что между устройством и эмулятором нужно выбрать эмулятор
• Ключом -s можно указать конкретное устройство. Если у вас их подключено одновременно 10 штук и вам нужно перезагрузить конкретный LG, у которого его id, скажем, 12345, то выполните команду adb -s 12345 reboot. У эмуляторов коды тоже есть и они выглядят как emulator-55XX, где 55XX — это порт подключения эмулятора для adb. Как узнать id? Читайте ниже

Команды adb

Основные

Основных команд три: devices, help и version. Вам частно нужна будет команда devices. Команда adb devices возвращает список устройство по id и их состояние.

Рис. 6. Результат выполнения adb devices

На скриншоте выше 036969c40935bf1a device означает, что это реальное устройство (device) и его id — 036969c40935bf1a. Состояние emulator означало бы, что это эмулятор. Состояние offline обычно означает, что устройство подключено, но подключение этого компьютера не разрешено ещё на самом устройстве, см. рис. 5. Хотя иногда это означает, что подключение зависло — adb сервер на компьютере и демон на устройстве не могут установить связь между собой. Зная id вы можете использовать ключ -s для запуска adb: adb -s 036969c40935bf1a reboot
Что значат help и version я понятия не имею. Думаю, вы можете посмотреть это в справке, но я не знаю, как её вызвать. Также в новых версиях могут добавляться новые команды, но как посмотреть версию adb я тоже не знаю. Парам-парам-пам, фью!

Отладочные

• adb logcat . Выводит системный лог в реальном времени в stdout. Прям бери и перенаправляй вывод в файл, чтобы предоставить лог разработчику (ниже покажу, как правильно это сделать), или парси сам в поисках ключевых строк. Утилита monitor показывает именно вывод logcat. Практически всё тестирование завязано на чтение логов, если это не тестирование графического интерфейса. Хотя и тут тоже лог часто нужен

adb logcat -v threadtime *V > file.txt adb logcat -f /sdcard/file.txt -v threadtime *V

• adb bugreport в ыводит сборную информацию от команд dumpsys, dumpstate и logcat. Полезно, если устройство не ваше, вам его принесли со словами «вот, только что опять». Вы собираете эту информацию и возвращаете устройство владельцу

Работа с данными

• adb install file.apk. Команда install устанавливает apk на устройство и возвращает Success, если всё нормально и текст ошибки, если что-то не так. Чаще всего «не так» бывают «приложение уже установлено» и значит нужно либо его удалить, либо использовать ключ -r (install -r), чтобы сделать upgrade (или даже -d, чтобы сделать даунгрейд; но такое не нужно почти никогда), «не валидная цифровая подпись» и значит приложение нужно переподписать, «цифровые подписи не совпадают», когда вы пытаетесь сделать install -r, но у уже установленного приложения и этой apk разные подписи, или, уже очень редко на современных устройствах, «нет места»
• adb uninstall packagename. Чтобы деинсталлировать установленное приложение, нужно знать его внутреннее имя, packagename (которое легко узнасть, имея в руках утилиту aapt)
• adb push local_file remote_file. Команда push отправляет local_file с вашего компьютера на устройство. Скажем, adb push d:\test\qqq.tmp /sdcard/demo.app скопирует файл qqq.tmp в корень карты памяти устройства под именем demo.app. Управлять файлами внутри устройства таким образом нельзя, это делается иначе, через шелл, о чём я расскажу дальше
• adb pull remote_file local. Команда pull, напротив, копирует файл с устройства вам на компьютер

Скриптовые

Для упрощения написания сценариев автоматизации есть три команды:

• adb get-serialno. Если к компьютеру подключено одно устройство, то команда вернёт его id. В любой другой ситуации будет возвращена ошибка. Это то, что написано в первом столбце для команды adb devices, но только для одного устройства
• adb get-state возвращает состояние устройства, если оно одно подключено и ошибку в иных случаях. Это то, что написано во втором столбце для команды adb devices. Можно их обе и не использовать, а парсить только вывод adb devices, но ситуации бывают разные.

Рис. 7. Результаты выполнения команд devices , get-serialno и get-state

• adb-wait-for-device other_command ожидает, пока adb серверу не ответит хотя бы один демон и тут же выполнит other_command. Скажем, вам нужно установить приложение на все подключаемые устройства. Вы пишите бесконечный цикл, который содержит только одну важную строку: adb wait-for-device install application.apk

Управление сервером

Здесь всего две команды и я говорил про них выше. Они нужны, потому что подключение между сервером и демоном нет-нет, а зависает, особенно на не очень качественных прошивках. adb kill-server останавливает adb сервер, а adb start-server запускает его.

Рис. 8. Реакция на команды остановки и запуска сервера, когда сервер работает или не работает

Главная сложность в том, что остановка сервера означает отвал всех устройств и прерывание записи лога, если у вас выполнялась всё это время adb logcat. И никакой adb -s не поможет, так как перезапускается весь сервис, так что помните это.

Впервые мне пришлось использовать перезапуск сервиса на каждой итерации автотеста, когда устройство One Plus One стало мгновенно проходить автотест, причём проваливая его. При отладке своего скрипта, суть которого сводилась к парсингу вывода adb logcat, выяснилось, что команда logcat вываливала содержимое буфера за последние несколько часов, а не с момента старта. Вообще, чтобы затирать старые записи и писать лог строго с текущего момента, у команды logcat есть ключ -c, от clear. Проверил руками — и действительно, adb logcat -c просто не отрабатывала, не возвращая никаких ошибок. После перезапуска сервиса всё заработало, поработало и сломалось точно также на очередной итерации. Пришлось вносить изменения в автотест, добавив перезапуск сервиса.

Shell

Команды, которые должны быть выполнены внутри самого Android, выполняются из шелла. Этих команд довольно много и без них жить трудно. Скажем, напечатать текст в поле ввода, если там стоит курсор, можно командой input text, выполненной в шелле. А скопировать файл из места А в место Б можно средствами cp.

Строго говоря, сама команда shell — это команда adb. Таким образом можно работать в шелле, будто бы подключившись по ssh или telnet, выполнив adb shell и нажав Enter, а можно выполнять по одной команде shell’а, делая это из adb. В первом случае вам доступны инструменты и возможности Linux и Android, во втором — инструменты и возможности консоли, в которой вы работаете. В Windows это cmd или, скажем, PowerShell.

Я приведу в пример несколько команд, доступных из shell, но их гораздо больше. Нужно просто понимать, что примерно можно делать в шелле.

Monkey

Манки — это утилита, которая генерирует заданное количество псевдослучайных событий для вашего приложения. Она не используется для реального тестирования пользовательских сценариев. Безусловно, с её помощью будут обнаруживаться падения, но подавляющее большинство этих падений никогда не будет обнаружено пользователями из-за, например, совершенно неожиданного или даже невозможного сценария.

Для чего очень полезен манки — так это обнаруживать утечки памяти. Просишь её сгенерировать несколько десятков тысяч событий и смотришь на потребление памяти. По завершению работы манки должен запуститься джавовский сборщик мусора и освободить память. Конечное, значение используемой памяти не должно сильно отличаться от начального значения.

Activity Manager

• Можно запустить активити или сервис вашего приложения, послав нужный Intent
• Можно остановить, то есть сделать Force Stop, приложение. Это очень полезно, когда вы работаете с реальными вредоносами, к примеру. Можно остановить так выполнение любой заразы, если антивирус провалил тест. Конечно, из шелла можно и kill сделать, но это обычно бесполезно
• Можно послать бродкаст

Package Manager

• Можно получить список всех установленных приложений. Самое простое — я фильтрую выдачу по тем, которые принадлежат нам, чтобы проверить, нужно ли их удалять
• Можно получить путь к установленному приложению, зная его имя пакета. И затем, например, скопировать командой обычным cp -r. Я использую эту возможность именно чтобы получить нужное приложение с целевого устройства. Скажем, человек подозревает, что у него установлено вредоносное приложение. Я даю ему скрипт, который собирает приложения с телефона и он отдаёт мне их
• Установить и деинсталлировать приложение. Так как в целом писать adb shell pm install и adb shell pm uninstall дольше, чем просто adb install и adb uninstall, то эта возможность почти не используется. С другое стороны, если вы уже в шелле, то можно не запускать другой сеанс cmd. Также через pm install можно немного рулить пермишенами для Android 6
• Можно чистить данные приложения. Очень полезная операция, недоступная без root привилегий на самом устройстве. Если вы тестируете приложение, которое защищается от удаления правами Администратора устройства, то это уже само по себе создаёт неудобства, так как деинсталлировать через adb его нельзя. А если оно ещё и блокирует устройство паролем, при попытке забрать права, то это вообще нудно. Когда-то я тестировал такое приложение (это оно на рис. 3 и есть). Причём код блокировки был случайным и генерировался на каждой инсталляции. Тогда я написал скрипт из пары строк, который останавливал приложение и чистил его данные. Дальше руками снимал права Администратора устройства и никаких блокировок не происходило, так как с точки зрения приложения его только что установили и оно не было настроено. Полезно это ещё для длинных автотестов, где требуется, чтобы приложение запускалось будто только после инсталляции. У меня есть скрипт для тестирования производительности, который, конкретно в этом случае, в цикле запускает приложение, считает время, за которое оно запустилось, останавливает его, чистит ему данные и запускает снова. Ещё это очень полезно, если есть активное заражение системы и нужно приструнить вредонос. В статье «Спасаемся от Androidлокеров (Trojan-Ransom)» часть работы приходится на am и pm
• Сделать скриншот, сохранив файл под желаемым именем на устройстве. Забрать с устройства его можно командой adb pull. Можно заскриптовать это дело и сделать скринкаст
• Сделать захват видео с экрана

Завершить эту запись я решил демонстрацией того, что подразумевалось под словами « В первом случае вам доступны инструменты и возможности Linux и Android, во втором — инструменты и возможности консоли, в которой вы работаете.» Вы читали эти слова буквально несколько минут назад, должны вспомнить. На скриншоте ниже я проделаю одно и тоже — получу список установленных приложений через пакетный менеджер и отфильтрую вывод по названиям, в которых есть явное упоминание LG. В cmd у меня есть findstr, а в shell — grep.

Рис. 9. Поиск строки с заданным вхождением в cmd и в shell

З.Ы.: (лол, как в старые добрые, когда мы писали «ЗЫ» и «йа креведко» и это было ещё смешным!) Просыпаюсь я где-то в 7 утра.