Android studio как собрать screencap

Обзор библиотек для скриншот-тестирования Android проектов. Часть 1

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

Меня зовут Олег Осипенко и этот цикл статей является развитием моего доклада, посвященного опыту внедрения скриншот-тестирования, который я презентовал на прошедшей недавно в Екатеринбурге конференции DUMP. Отдельную часть доклада я посвятил разбору имеющихся библиотек, но, будучи ограничен временными рамками доклада, я не мог подробно остановиться на их особенностях. И сейчас я хотел бы восполнить это упущение. К тому же уже после доклада я нашел еще 2 новых библиотеки в дополнение к тем 5, что я упоминал в своем выступлении.

В этой статье я расскажу о следующих библиотеках:

Facebook* Screenshot Testing Library
Shot
Paparazzi
Dropshots

Facebook* Screenshot Testing Library

Библиотека от Facebook* появилась еще в 2015 году, когда она была представлена на конференции Droidcon NY. Благодаря этой библиотеке техника скриншот-тестирования заняла свое место в арсенале андроид-разработчиков.

Однако, на данный момент этот проект представляет интерес только с историографической точки зрения. Моя попытка интегрировать эту библиотеку на проекте завершилась неудачей как раз по той причине, что в Android слишком много всего изменилось с момента разработки — Android не стоит на месте, происходит постоянное обновление платформы, появляются новые инструменты и модели работы с данными на устройстве, разрешения и т.д. В этих условиях, любой Android-библиотеке просто для того, чтобы запускаться на новых версиях системы, требуется постоянная поддержка. Про библиотеку от Facebook этого сказать нельзя — её разработка практически остановилась, репозиторий забит открытыми issue и реквестами. К тому же для работы этой библиотеки требуются дополнительные зависимости, так как код для сравнения скриншотов написан на уже официально не поддерживаемом с 2020 года Python 2.

минусы библиотеки Facebook*

Shot

Развитием данного проекта является Shot, который использует библиотеку от Facebook* под капотом и решает все её проблемы, поскольку проект активно обновлялся вплоть до последнего времени. Интеграция в проект довольно проста: надо только подключить gradle-плагин:

// top-level build.gradle buildscript < dependencies < classpath 'com.karumi:shot:' > > // app build.gradle apply plugin: 'shot'

а также настроить тестовый раннер:

// app build.gradle android < defaultConfig < testInstrumentationRunner "com.karumi.shot.ShotTestRunner" >>

и в проекте появляется несколько новых задач по запуску и обслуживанию скриншот-тестов:

Shot tasks ---------- debugDownloadScreenshots - Retrieves the screenshots stored into the Android device where the tests were executed for the build Debug debugExecuteScreenshotTests - Checks the user interface screenshot tests . If you execute this task using -Precord param the screenshot will be regenerated for the build Debug debugRemoveScreenshotsAfter - Removes the screenshots recorded during the tests execution from the Android device where the tests were executed for the build Debug debugRemoveScreenshotsBefore - Removes the screenshots recorded during the tests execution from the Android device where the tests were executed for the build Debug executeScreenshotTests - Checks the user interface screenshot tests. If you execute this task using -Precord param the screenshot will be regenerated.

Сами тесты должны реализовать интерфейс ScreenshotTest , который предоставляет перегруженный метод compareScreenshot() . Стоит отметить, что библиотека поддерживает не только традиционные view-компоненты, но и Jetpack Compose:

class MyActivityTest: ScreenshotTest < @Test fun testActivityIsShownProperly() < val mainActivity = startMainActivity() compareScreenshot(activity) >>

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

пример отчета о тестировании Shot

Более подробно об использовании Shot для тестирования дизайн-системы приложения можно узнать из доклада Максима Теймурова на прошлом Mobius.

достоинства Shot

Однако, у Shot есть и свои недостатки. Во-первых, Shot для работы требуется доступ к adb. Для создания скриншотов нам требуется запустить тесты на устройстве, даже если мы используем эмулятор, эмулятор работает как отдельная виртуальная машина и у нас нет прямого доступа к его файловой системе. Здесь на помощь приходит adb — Android debug bridge, утилита из состава Android SDK, которая позволяет производить различные манипуляции с подключенным устройством, в том числе получать с него файлы: после прогона тестов Shot с помощью adb скачивает скриншоты и после этого запускает процесс сравнения изображений. Проблема с adb возникает в тот момент, когда над проектом работает несколько десятков человек и CI ежедневно выполняет сотни, если не тысячи проверок. В этот момент у вас может возникнуть непреодолимое желание как-то ускорить этот процесс путем различных оптимизаций, например с использованием отдельной девайс-фермы для запуска инструментальных тестов, такой как Firebase Test Lab. Но подобные фермы устройств, Firebase Test Lab, Aamazon Device Farm и другие, не дают клиентам доступа к adb, что исключает возможность использования Shot. Единственный выход из этой ситуации — это использование Shot только для верификации скриншотов:

shot

В этом случае мы можем запустить инструментальные тесты на Firebase, после этого скачать скриншоты из консоли и запустить их верификацию в Shot.

К тому же Shot требует идентичных настроек эмулятора на машинах, где предполагается выполнение скриншот-тестов, — нужно, чтобы везде использовалась одна и та же модель девайса, с одинаковой плотностью пикселей и т.п. На результат влияет даже разрядность образа эмулятора. Например, использование образа x86_64 вместо x86 приводило к получению отличающихся изображений. Причем отличались они не визуально, а на уровне байтов. Например вот так:

сравнение байтов двух изображений

И это еще одно слабое место Shot — механизм сравнения изображений. Его алгоритм предельно наивен — он просто проходил по байтам двух изображений и сравнивал их на идентичность. Shot предоставляет дополнительную настройку tolerance — допустимый процент отличающихся пикселей. Но эта настройка слишком грубая: для того, чтобы нейтрализовать эффект из примера выше, tolerance нужно было бы установить на 10-15%, что само по себе бессмысленно — как мы можем говорить о похожести двух изображений, у которых могут отличаться 15% пикселей?! При таком большом значении tolerance легко пропустить настоящую регрессию.

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

недостатки Shot

Paparazzi

Властелины open source из компании Square, библиотеками которых пользуется каждый android разработчик, не прошли мимо скриншот-тестирования, создав новый проект под названием Paparazzi. В отличие от упомянутых выше библиотек Paparazzi не требуется подключение к Android-устройству для создания скриншотов. Вместо этого визуализация компонентов выполняется с использованием LayoutLib — движка рендеринга из Android Studio. Благодаря этому достигается высокая скорость выполнения тестов так как все тесты выполняются на JVM.

Сравнение скорости выполнения тестов с использованием Shot и PaparazziПо материалам https://jobandtalent.engineering/why-go-with-paparazzi-our-journey-with-android-screenshot-testing-6afa88f41300

Для интеграции Paparazzi нам надо подключить к проекту плагин:

// top-level build.gradle buildscript < repositories < mavenCentral() google() >dependencies < classpath 'app.cash.paparazzi:paparazzi-gradle-plugin:1.2.0' >>

И применить его в модуле: apply plugin: ‘app.cash.paparazzi’ . Так как Paparazzi для выполнения тестов парсит ресурсы приложения, его использование возможно только в library-модулях — в модуле application ресурсы представлены уже в бинарном формате, работать с которым библиотека не в состоянии.

Сами тесты создаются в папке src/test и выглядят следующим образом:

class PaparazziScreenshotTest < @get:Rule val paparazzi = Paparazzi( deviceConfig = DeviceConfig.PIXEL_2, theme = "android:Theme.Material.Light.NoActionBar" ) @Test fun testXml() < val view = paparazzi.inflate(R.layout.xml_layout_sample) paparazzi.snapshot(view) > @Test fun testCompose() < paparazzi.snapshot < SampleComposeContent() >> @Test fun testGif() < val view = paparazzi.inflate(R.layout.xml_layout_sample) paparazzi.gif(view) > >

Paparazzi поддерживает тестирование как legacy-верстки в XML формате, так макетов, сверстанных с помощью Jetpack Compose и в одном тестовом классе можно комбинировать оба способа. Конфигурация рендеринга выполняется с использованием объекта Paparazzi, позволяющего настроить различные параметры отображения — модель устройства, тема приложения, отображение/скрытие клавиатуры и другие. Кроме того, у Paparazzi есть метод gif() , с помощью которого мы получим набор фреймов, что удобно для тестирования анимаций:

fun gif( view: View, name: String? = null, start: Long = 0L, end: Long = 500L, fps: Int = 30 )

К сожалению, данный метод поддерживает только макеты в XML.

После применения плагина Paparazzi в проекте появляются два новых Gradle-таска — для создания и верификации скриншотов. В случае возникновения регрессии Paparazzi создаст diff-изображение:

delta-изображение из Paparazzi достоинства Paparazzi

Однако Paparazzi при этом не лишен недостатков. Поскольку Paparazzi использует LayoutLib, его разработчикам требуется какое-то время на интеграцию новой версии LayoutLib из Android Studio в момент появления новой версии Android SDK. Таким образом всегда будет существовать определенный временной лаг между выходом новой версии Android SDK и появлением его поддержки в Paparazzi. По этой же причине Paparazzi очень легко ломается при обновлении Android Gradle Plugin, а также Jetpack Compose. Помимо этого Paparazzi закономерно наследует все баги, которые могут присутствовать в LayoutLib, а также его ограничения — например, если мы используем верстку на XML, мы не можем протестировать скриншот-тестами весь экран сборе, в том случае , если он он сверстан с применением adapter-view, таких как RecyclerView — на скриншоте мы увидим только RecyclerView, поскольку заполнение его элементами происходит уже во время выполнения приложения при подключении к нему адаптера. Также Paparazzi не поддерживает создание скриншотов из Activity и Fragment . Дополнительно стоит отметить свидетельства того, что результаты рендеринга с использованием LayoutLib могут отличаться на различных операционных системах, что будет приводить к падению скриншот-тестов.

Dropshots

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

Интеграция Dropshots в проект, наверное, самая простая. Для этого как обычно требуется подключить плагин:

// top-level build.gradle buildscript < repositories < mavenCentral() >dependencies < classpath "com.dropbox.dropshots:dropshots-gradle-plugin:0.4.0" >> // build.gradle in the module apply plugin: "com.dropbox.dropshots"

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

@RunWith(AndroidJUnit4ClassRunner::class) class DropshotsSampleTest < @gett:Rule val activityRule = ActivityScenarioRule(MainActivity::class.java) @get:Rule val dropshots = Dropshots() @Test fun testDropshots() < activityRule.scenario.onActivity < dropshots.assertSnapshot(it) >> >

После этого можно запустить тесты при помощи стандартной задачи Gradle connectedAndroidTest , либо нажатием на кнопку пуск в Android Studio. После этого на девайсе будут выполнены инструментальные тесты, во время которых будет сделан новый скриншот, запущено его сравнение с образцом и создано diff-изображение в случае возникновения каких-либо ошибок:

Diff-изображение, созданное во время прогона тестов Dropshots

Однако, данный подход наряду с неочевидными преимуществами несет и недостатки: поскольку верификация выполняется на устройстве, время выполнения тестов увеличивается прямо пропорционально размеру изображения. Хотя референсы скриншотов упаковываются в тестовый apk и поэтому уже доступны локально на том устройстве, где выполняются тесты, получение дифф-изображения с устройства происходит с использованием adb, что опять же ограничивает сценарии возможного использования. К примеру, в отличие от Shot, Dropshots возможно использовать в связке с Firebase Test Lab, но в случае возникновения регрессии скачать дифф-изображение будет невозможно, поскольку эта операция производится через adb. Алгоритм верификации, используемый в Dropshots также не отличается особой изощренностью — в наличии два встроенных алгоритма: CountValidator и ThresholdValidator . Первый позволяет указать допустимое количество отличающихся пикселей в абсолютном выражении, а второй — их процент. Тем не менее, стоит отметить, что разработчики Dropshots немного позаботились об архитектуре своей библиотеки и оставили возможность использования пользовательских валидаторов, что позволяет реализовать более продвинутый алгоритм сравнения:

@get:Rule val dropshots = Dropshots( resultValidator = MyCunnyScreenshotValidator() )

В следующей части мы рассмотрим еще три библиотеки:

Roborazzi
Testify
Kotlin Snapshot Testing

*Принадлежит meta, признанной в РФ экстремистской организацией.

Как сделать скриншот на Android-устройстве с помощью компьютера

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

Наиболее распространенный способ создания скриншотов заключается в использовании кнопки включения/блокировки и клавиши понижения громкости. Нужно одновременно зажать и удерживать кнопки на протяжении нескольких секунд. Затем прозвучит щелчок или характерный звуковой сигнал, после чего миниатюра созданного снимка отобразится в области уведомлений или в одном из углов экрана (например, на смартфонах Xiaomi, Huawei и Honor).

Сохраненный скриншот отображается в шторке уведомлений

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

Как сделать скриншот на Huawei и Honor emui Как сделать скриншот на Samsung One UI

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

Установка ADB

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

ADB входит в состав Android Studio – комплекса программных средств для разработки ПО. Загружать установочный файл Android Studio размером в несколько гигабайт не обязательно – достаточно скачать комплект инструментов Android SDK либо отдельный архив Platform-Tools с утилитами ADB и Fastboot. По этой ссылке всегда можно скачать актуальную версию Platform-Tools с официального репозитория Google. Загруженный архив следует распаковать, желательно на диске «C:».

архив Platform-Tools с утилитами ADB и Fastboot

Прежде, чем приступать к работе с ADB, нужно включить на смартфоне отладку по USB в скрытом разделе настроек «Для разработчиков». Чтобы активировать последний, следует открыть вкладку с информацией о телефоне и семь раз кликнуть по строке «Номер сборки» (при необходимости придется ввести PIN, пароль или графический ключ). После выполнения этого действия раздел «Для разработчиков» станет доступен по пути «Настройки» → «Система» → «Дополнительно». В зависимости от прошивки и версии Android, расположение раздела настроек может отличаться.

Как включить отладку по USB на Android-смартфоне usb debugging

Также рекомендуется обновить драйверы USB до последней версии и установить на компьютер комплект разработчика JDK (Java Development Kit), соответствующий разрядности операционной системы Windows. Как только с приготовлениями будет покончено, можно подключать устройство к компьютеру через USB.

ADB – это консольная утилита, управление которой осуществляется с помощью командной строки либо Windows PowerShell. Наиболее простой способ запустить консоль – перейти в папку «platform-tools», зажать клавишу «Shift» и кликнуть правой кнопкой мыши по пустой области, а затем выбрать один из двух доступных вариантов в раскрывшемся контекстном меню: «Открыть окно команд» либо «Открыть окно PowerShell здесь».

Запустить консоль ADB Открыть окно PowerShell здесь

Как сделать скриншот

Чтобы создать снимок экрана, необходимо выполнить команду:

adb shell screencap /sdcard/screenshot.png

Она содержит название файла, его расширение и расположение («sdcard» – это корневая директория внутренней памяти). Вместо приведенных в качестве примера параметров можно задать свои. Для выполнения команды достаточно нажать клавишу «Enter». В PowerShell сначала нужно добавить ./ или .\.

adb shell screencap

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

adb pull /sdcard/screenshot.png C:/Users/ Username /Downloads

Автор: Егор Плотницкий

Как собрать проект в APK файл?

Заранее хотел бы отметить, что не имею никакого опыта в этой теме, поэтому многие используемые мной термины могут быть использованы неправильно, а вопросы быть глупыми. Есть следующая задача, «собрать» готовый проект в Android Studio, весь код уже написан, есть файл build.gradle и так далее, задача лишь взять эти файлы и сделать из них APK файл для последующего запуска на телефоне, поиск не дал нужных результатов, ибо все найденное в интернете, было о написании с нуля. Извините еще раз, если задаю глупый или некорректный вопрос, заранее спасибо!

Отслеживать
задан 27 июн 2021 в 18:30
Pechenkascofe Pechenkascofe
11 1 1 серебряный знак 2 2 бронзовых знака

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

27 июн 2021 в 18:40
Если вам дан исчерпывающий ответ, отметьте его как принятый нажав на галочку слева от него
2 июл 2021 в 6:44