Для QA-инженеров: как использовать Android Debug Bridge в тестировании мобильных приложений

Привет, Хакернун! Меня зовут Александр Карпенко, и я работаю QA Engineer в ==inDrive==. Я подготовил эту статью для начинающих QA-специалистов. Ниже я расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и зачем он нужен в первую очередь. место.

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

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

Для начала давайте коснемся самых основных команд, чтобы убедиться, что последующие пункты представлены в логической последовательности.

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

Обычно мы работаем с одним устройством, но иногда подключаются несколько устройств, например, по TCP/IP. В этом случае нам нужно вручную указать устройство, на котором мы хотим запустить команду.

Отобразить список всех подключенных устройств для получения идентификатора

adb devices — отображает список подключенных устройств (при использовании переключателя -l открывается расширенный список свойств). Это полезно, если подключено несколько устройств и сразу не понятно, какое из них нам нужно.

Чтобы сообщить ADB, на какое устройство нацеливаться, серийный номер устройства должен быть указан после ключа -s:

adb -s <serial_number> <command>, где <serial_number> – серийный номер устройства из списка, а <command> – команда, которую нужно выполнить на устройство.

Например, установка приложения на конкретное устройство из списка:

adb -s 32312b96 install user/download/app.apk

Другой частый сценарий — когда в операции одновременно участвует реальное устройство и эмулятор, например, для разных ролей исполнителя/оригинатора. В этом случае устройства легко отличить не по серийному номеру, а по переключателям —d —e после команды adb. Пример:

adb —d install user/download/app.apk — команда будет выполнена на реальном устройстве, с переключателем —е на эмуляторе.

Мы также можем подключиться к устройству через TCP/IP, если оно использует ту же сеть Wi-Fi. Для этого подключите устройство к ПК кабелем и измените режим работы на устройстве с USB на TCP/IP с помощью команды:

adb TCPIP 5555

Определить IP-адрес устройства любым доступным способом

Например, через настройки телефона в разделе Общие сведения или с помощью команды:

оболочка adb ifconfig wlan0

Если в этот момент ваше устройство уже отключено от ПК, обязательно дополнительно укажите S/N устройства. Далее подключаемся к нему:

adb connect ip_address:5555

Устройство можно отключить командой:

adb отключить ip_address:5555

adb disconnect — чтобы отключить все наши устройства TCP/IP.

Чтобы вернуться в режим USB, используйте команду:

adb usb (строчные буквы важны).

Установка и удаление приложения, а также поиск пакета на устройстве

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

adb install <apk_path>, где <apk_path> – это абсолютный путь к нашему файлу приложения APK.

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

—d — переустанавливает с пониженной версией. В противном случае произойдет сбой (ошибка) [INSTALL_FAILED_VERSION_DOWNGRADE]).

—r — переустанавливает приложение с сохраненными данными.

—g — предоставляет все разрешения, указанные в манифесте приложения в процессе установки.

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

Приложение удаляется на основе имени пакета. Для этого нужно знать, как приложение регистрируется в системе. Используйте командную консоль и диспетчер пакетов (pm).

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

список пакетов adb shell pm

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

adb shell pm список пакетов | grep com.myApp

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

список пакетов adb shell pm > /Пользователи/имя пользователя/packages.txt

Теперь, когда мы знаем, как узнать имя пакета приложения, вернемся к тому, как удалить его с устройства. Это можно сделать с помощью команды:

adb удалить com.myApp

adb uninstall -k com.myApp — удаляет приложение, но сохраняет данные и файлы кеша.

Отдельно представлю команду, которая часто может оказаться полезной:

adb shell pm clear com.myApp — очищает кеш и данные приложения.

Загрузка APK-файла с устройства

Я думаю, что это редкая ситуация. Но кому-то это может пригодиться, как когда-то и мне. Все установленные приложения хранят свои APK-файлы в папке /data/appfolder. Поскольку вы знаете название пакета, вы можете найти место, где установлено приложение, и скачать оттуда его APK. Для этого выполните следующую команду:

adb shell pm path com.myApp — отображает каталог установки приложения.

Это может выглядеть не очень презентабельно:

package:/data/app/~~YcTsnr19yQR6ENa0q2EMag==/com.myApp—IHasf91SDB0erQLagc8j0Q==/base.apk

Но именно так нам и нужно, чтобы этот путь выглядел. Давайте немного пропустим вперед и посмотрим, как мы можем скопировать нужный нам файл на ПК с телефона. Это можно сделать с помощью команды:

adb pull <crazyPath> /Users/username/, где <crazyPath> — это результат нашей предыдущей команды, /Users/username/ — это путь на ПК, где вы хотите скопировать наш файл в.

Текстовые поля

Давайте кратко поговорим о проверке текстовых полей. Например, вам нужно проверить ограничение на максимальное количество символов, которые можно ввести в текстовое поле. Если вы используете одно устройство, разные наборы передаваемых данных могут храниться на телефоне или в облаке. Однако, если тестирование необходимо проводить на разных устройствах, данные тестирования можно сохранить на ПК и передать на устройства с помощью следующих команд:

текст ввода оболочки adb <text>

Пример:

adb shell input text test%stest — будет введена строка «test test». Замените пробелы специальными символами %s, иначе на устройство будет отправлена ​​только часть, предшествующая пробелу. Если мы используем специальные символы, такие как !@# в передаваемом тексте, они должны быть отмечены обратной косой чертой ( ) перед ними.

Например, команда:

тест ввода текста оболочки adb!@#$%stest будет отображать "test!@#$ test" на экране

(ADB не работает с кириллическими символами и генерирует ошибку NullPointerException).

Содержимое буфера обмена можно передать следующим образом:

текст ввода оболочки adb $(pbpaste)

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

текст ввода оболочки adb $(pbpaste | sed -e 's/ /%s/g')

pbpaste — это текст, который содержится в буфере.

Переключатель ”—e” позволяет выполнять команды, необходимые для редактирования текста.

«s/take this/change_it_to/option» — это шаблон (шаблон), который следует использовать.

/g — это флаг для замены всех совпадений для определенного шаблона без исключения.

Глубинные ссылки

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

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

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

В Shell ADB мы можем использовать диспетчер действий (AM) для выполнения команд.

Мы начинаем нашу активность и отправляем ссылку на контент, которую хотим проверить. Глубокая ссылка обычно содержит символ «&», разделяющий экраны. Поэтому при открытии через терминал перед ним должна быть вставлена ​​обратная косая черта ().

adb shell am start -W -a android.intent.action.VIEW -d «myApp://open/client/trip&last_trip=test» com.myApp

am — вызывает диспетчер активности.

W — ожидание загрузки перед выполнением команды.

a — определяет, какое действие должно быть выполнено. В данном случае это action.View.

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

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

Создание скриншотов и запись видео с экрана устройства

Используйте эту команду, чтобы сделать снимок экрана:

скриншот adb shell -p <device_path/screenshot_name.png>

Пример:

adb shell screencap -p /sdcard/screencap.png — делает снимок экрана и сохраняет файл с именем screencap.png на устройстве в папку /sdcard/screencap. папка png.

Вы можете сохранить скриншот на свой компьютер следующим образом:

adb pull /sdcard/screencap.png — по умолчанию файл копируется в каталог текущего пользователя, т. е. /Users/username/screencap.png.< /p>

Или вы можете запустить всю команду сразу:

скриншот adb shell -p /sdcard/screencap.png && adb pull /sdcard/screencap.png

В последних версиях ADB для получения снимка экрана можно использовать следующую команду:

adb exec—out screencap —p > screen.png — файл скриншота также появится в каталоге текущего пользователя на ПК.

Путь по умолчанию можно изменить вручную, добавив в конце команды:

adb exec—out screencap -p > downloads/test/screen.png — и скриншот появится в папке /Users/username/downloads/test/screen.png.

Если интересно, вы также можете немного автоматизировать этот процесс, добавив псевдоним в bash_profile. В macOS вы можете использовать службу Automator для создания и настройки горячих клавиш.

Используйте эту команду для записи видео:

adb shell screenrecord device_path.

Пример:

adb shell screenrecord /sdcard/screenrecord.mp4 — используйте эту команду, чтобы начать запись экрана устройства с настройками по умолчанию в течение трех минут и сохранить результат в файл /sdcard/screenrecord. mp4 на устройстве.

Вы можете вручную указать время записи с помощью переключателя —time—limit time (в секундах, но продолжительность записи по-прежнему ограничена 180 секундами).

Запись можно остановить досрочно, нажав CTRL + C

Файл также можно скопировать с помощью команды pull аналогично процедуре со снимком экрана.

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

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

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

Мы открыли его на своем ПК, настроили формат и содержимое, загрузили на телефон и проверили, правильно ли приложение реагирует на неизвестные форматы и ограничения на размер. Чтобы загрузить файл на телефон с ПК, вы можете использовать эту команду:

adb push /Users/username/file <device_path>

Запустим команду:

adb push /Users/username/screen.png sdcard — это скопирует наш файл screen.png на SD-карту телефона.

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

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

оболочка adb для уничтожения com.myApp

Запустите его еще раз и проверьте, все ли работает нормально.

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

Журналы

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

adb logcat — отображает журналы в режиме реального времени.

adb logcat —d — отображает информацию журнала в момент запуска команды, без добавления реальных событий на устройстве. Также можно вывести журнал в отдельный файл с помощью команды: adb logcat —d > file.log (файл создается в каталоге текущего пользователя).

И команда adb logcat >> file.log будет записывать журнал прямо в файл, добавляя все реальные события на устройстве.

Существует несколько уровней в порядке возрастания приоритета: V — Подробно, D — Отладка, I — Информация, W — Предупреждение, E — Ошибка, F — Фатальная, S — Без звука, например:

adb logcat '*:E' — выведет логи с ошибками и уровнем выше.

Теперь кратко остановимся на форматировании вывода и фильтрах. Вы можете изменить формат вывода на консоль с помощью ключа -v, например:

adb logcat -v time — выводит журналы последовательно, записывая моменты времени.

adb logcat -v color — отображает каждый уровень журналов разным цветом (что полезно при чтении).

adb logcat -v Brief — отображает приоритет процесса, тег и PID.

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

adb logcat SwrveSDK:I '*:S' — будет отображать события аналитики, которые мы отправляем через службу swrve. Параметр *:S (-s) указывает, что вывод журнала ограничен выражением фильтра, которое мы указали явно.

И, как всегда, вы можете использовать утилиту grep для фильтрации вывода:

adb logcat '*:E' —v color | grep com.myApp

Традиционно за дополнительной информацией вы всегда можете обратиться к своему помощнику adb logcat --help

Теперь давайте посмотрим, как его использовать

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

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

adb logcat —c, затем мы воспроизводим ошибку и запускаем adb logcat —d

Для тех, кто любит копаться в кучах журналов, есть еще один инструмент для рассмотрения — отчет об ошибках ADB. Этот инструмент позволяет создавать zip-архивы с полной отладочной информацией в текстовом формате (.txt).

adb bugreport /Users/username — создает zip-архив в указанном каталоге.

Копирует всю информацию об устройстве, такую ​​как данные о состоянии дампа, dumpsys и logcat, в указанную папку. По умолчанию отчеты об ошибках хранятся в /bugreports и могут быть просмотрены через:

оболочка adb ls /bugreports/

Самая важная для нас информация хранится в файле bugreport-BUILD_ID-DATE.txt

Отслеживание сбоев и ANR (приложение не отвечает) — еще один интересный инструмент для работы со сбоями. Запустите его с помощью этой команды:

n adb shell am monitor, а затем мы воспроизводим наш сбой. Консоль отобразит информацию о сбое без каких-либо лишних деталей и три варианта продолжения наших усилий по мониторингу: (c)continue: показать диалоговое окно сбоя, (k)ill: немедленно убить приложение, (q)uit: завершить мониторинг< /код>.

Эмуляторы

Отображение списка настроенных эмуляторов:

эмулятор -list-avds

Запускаем нужный нам эмулятор:

эмулятор @avdname

При работе с эмуляторами иногда необходимо перезапустить сервисы, а также перезагрузить сервер после запуска эмулятора, но довольно часто достаточно даже одной команды: adb kill-server. Если это не поможет, то запустите весь скрипт:

emulator -list-avds — отображает список настроенных эмуляторов.

adb kill-server — останавливает сервер.

emulator -avd avdname (или emulator @avdname) — где avdname — имя эмулятора.

adb start—server — перезапускает сервер.

adb devices — отображает список подключенных устройств, на которых должен появиться наш потерянный эмулятор.

Для самых ленивых из вас эмулятор можно создать из командной строки. Например, следующая команда создает эмулятор с именем «test», используя образ системы x86 с API 25:):

avdmanager create avd —n test —k "system—images;android—25;google_apis;x86"

Если нужный образ недоступен, его можно предварительно установить командой: n

sdkmanager --install «система — изображения; android — 25; google_apis; x86»

sdkmanager --list | система grep—images — отображает список изображений, доступных для скачивания

С эмуляторами также иногда возникают «фантомные» проблемы во время работы, и одна часто используемая команда, которая здесь помогает, — «холодная загрузка» эмулятора без подтягивания автоматического моментального снимка. Снимок, сделанный на выходе, будет таким:

emulator @avdname —no—snapshot—load

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

-no-snapshot-save — автоматический снимок не будет сохранен

-no-snapshot — снимок не будет загружен или сохранен

Если эмулятор по-прежнему не работает должным образом, его можно очистить с помощью переключателя, возвращающего эмулятор в исходное состояние: -wipe-data

Создание моментальных снимков — очень полезная функция для сохранения различных состояний устройства. Вручную это можно сделать через настройки эмулятора или выполнив эту команду:

adb emu avd snapshot save test — сохраняет состояние эмулятора, где test — это имя снимка, который будет сохранен на устройстве

emulator @avdname —snapshot—list — запускает наш эмулятор с именем @avd и отображает список снимков в консоли

Затем вы можете загрузить ранее сохраненный снимок с помощью этой команды:

adb emu avd snapshot load test — где test — имя ранее сохраненного снимка

adb emu avd snapshot delete test — удаляет снимок с именем test

Также есть возможность сразу запустить эмулятор с нужным нам снапшотом:

эмулятор @avdname - тестовый снимок

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

adb emu avd snapshot pull test /Users/username/

Нашим эмулятором можно управлять через консоль telnet. Но сначала вы должны установить его. Проще всего это сделать с помощью менеджера пакетов brew, если он у вас есть. Если нет, то самое время узнать, что это такое и как его использовать. Итак, установите telnet с помощью команды: brew install telnet.

Далее запускаем наш эмулятор, и в другой вкладке терминала подключаемся к нему командой: telnet localhost port, Пример:

telnet localhost 5554 — подключается к нашему эмулятору, который использует порт 5554

После выполнения команды мы можем делать с нашим эмулятором всякие полезные штуки, в том числе работать с гео (например, команда geo fix 40.748840 -73.984279 установит желаемое местоположение по указанным координатам), сеть или аккумулятор, а полный список команд как всегда можно найти в справке.

Например, та же процедура со снимками несколько упрощается, а команды, описанные в предыдущем разделе, сводятся к avd snapshot <command>.

Изменение разрешения на устройстве

Диспетчер окон (wm) имеет несколько полезных команд для обеспечения правильного отображения элементов на экране устройства. Они позволяют вам настроить разрешение плотности пикселей, чтобы вы могли просмотреть все необходимые параметры размеров экрана и посмотреть, как наше приложение будет адаптироваться к ним, не имея под рукой соответствующего количества устройств:

adb shell wm size 1080x1920 — задает пользовательское разрешение экрана с шириной 1080 и высотой 1920.

adb shell wm size reset — сбрасывает все наши измененные настройки.

adb shell wmdensity X — изменяет плотность пикселей, где минимальное значение равно 72. Чем больше значение, тем больше элементы на экране.

adb shell wmdensity reset — сбрасывает все наши измененные настройки.

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

Обезьяна

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

adb shell monkey — отображает все параметры Monkey.

Пример полного сценария:

adb shell monkey ——throttle 100 ——pct—syskeys 0 —p com.myApp —v 10

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

Ключ --pct-syskeys — определяет процент системных кнопок, которые будут нажаты во время сценария. В этом примере установлено значение 0, что означает, что ни одна системная кнопка не будет нажата.

Переключатель -p — имя передаваемого пакета

Переключатель -v — количество выполняемых действий

Разрешения приложения

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

dumpsys-пакет оболочки adb com.MyApp | разрешение grep — отображает список доступных разрешений для приложения, например, разрешения на установку — обязательные разрешения, которые предоставляются при установке приложения, разрешения во время выполнения — разрешения, которые запрашивается в определенный момент, например, при доступе к файловому хранилищу. Обратите внимание: если разрешение отсутствует в запрошенном списке разрешений, вы не сможете предоставить к нему доступ.

Итак, для отзыва разрешения нашего приложения необходимо выполнить следующую команду:

adb shell pm revoke имя_пакета имя_права, пример:

adb shell pm revoke com.MyApp android.permission.CAMERA — отзывает доступ com.myApp к камере. Как только мы вернемся в приложение и попытаемся использовать камеру через него, мы увидим новый запрос на разрешение.

Команда гранта дает разрешение приложению, например:

adb shell pm grant com.myApp android.permission.CAMERA — предоставляет доступ к камере телефона для нашего приложения.

Аккумулятор

Давайте кратко рассмотрим аккумулятор и режим ожидания.

adb shell dumpsys battery — отображает информацию о батарее.

adb shell dumpsys battery set level X — устанавливает уровень заряда батареи, где X — процент заряда.

adb shell dumpsys battery unplug — имитирует отключение батареи.

adb shell dumpsys battery reset — сбрасывает все наши измененные настройки.

Теперь давайте посмотрим на режимы ожидания. Начиная с Android 6, существует функция, известная как режим Doze Mode, для экономии заряда аккумулятора и продления срока службы аккумулятора за счет ограничения активности приложений после того, как пользователь не взаимодействует с устройством в течение некоторого времени и когда устройство не заряжается.

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

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

adb shell dumpsys battery unplug — отключает аккумулятор.

adb shell dumpsys deviceidle step — возможно, команду придется выполнить несколько раз, пока не отобразится: Stepped to deep: IDLE.

После всех проделанных нами процедур с батареей лучше всего выполнить команду:

сброс батареи в оболочке adb dumpsys — возвращает ее в исходное состояние.

Эту команду также можно использовать для перевода устройства в режим ожидания:

adb shell dumpsys deviceidle force—idle — иногда перед этим нужно выполнить команду: adb shell dumpsys deviceidle enable.

Вы можете снова активировать его из режима Doze с помощью команды:

adb shell dumpsys deviceidle unforce — и не забудьте сбросить состояние батареи:

сброс батареи dumpsys оболочки adb.

Теперь немного о App Standby. Для развертывания приложения в этом режиме необходимо выполнить следующие команды:

adb shell dumpsys battery unplug — отключает батарею, как и в предыдущем случае.

adb shell am set—inactive com.myApp true — развертывает приложение в режиме ожидания приложения.

Затем переключите наше приложение из режима ожидания приложения с помощью этой команды:

Установлена ​​оболочка adb — inactive com.myApp false.

Вы можете проверить статус приложения, выполнив эту команду:

adb shell am get — неактивный com.myApp

Еще несколько полезных команд для рассмотрения

adb reboot — перезагружает устройство (актуально и для реального устройства).

adb shell dumpsys package com.myApp — отображает полную информацию о конкретном приложении.

adb shell dumpsys meminfo com.myApp — для проверки использования памяти приложением на устройстве, начиная от занимаемого места и заканчивая отображением баз данных, используемых этим приложением, а также пути к ним. .

adb shell getprop — показывает список доступных свойств устройства (производитель, модель устройства, характеристики оборудования и т. д.)

Отобразить список действий, доступных приложению:

Пакет dumpsys оболочки adb com.myApp | grep — активность.

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

окно дампа оболочки adb | grep сфокусирован.

Запустите выбранное действие приложения:

adb shell am start —n com.myApp/.ActivityClass — так вы сможете запускать любые установленные приложения, включая системные. Пример: adb shell am start -n com.android.settings/.Settings отображает настройки нашего телефона.

Позвоните на указанный номер телефона:

оболочка adb при запуске — android.intent.action.CALL tel:+790900000XX.

Откройте страницу в веб-браузере:

оболочка adb при запуске — android.intent.action.VIEW 'https://indriver.com'

Заключительные мысли

Хочу отметить, что невозможно втиснуть все возможности Android Debug Bridge в одну статью или провести их тщательное изучение. Изменения происходят постоянно: то, что работает сегодня, может вдруг перестать работать завтра, а потребность в знании тех или иных инструментов будет возникать по мере поиска решений конкретных вопросов. Но я могу с уверенностью сказать, что материала, который мы рассмотрели сегодня, достаточно, чтобы вы начали, а затем продолжили какое-то время.

Удачи в ваших начинаниях, и я надеюсь, вам понравится погружаться в захватывающий мир тестирования программного обеспечения!