Gradle wrapper что это
Рекомендуется выполнять сборку Gradle с помощью утилиты Gradle Wrapper (далее коротко просто «Wrapper»). Wrapper это скрипт, который берет декларируемую версию Gradle и перед сборкой загрузит её при необходимости. В результате разработчики могут быстро получить рабочий компилируемый проект Gradle без исследования руководства по инсталляции, что экономит время и деньги вашей компании.
Рис. 1. Рабочий процесс Wrapper.
В двух словах вы получаете следующие преимущества:
· Стандартизирует проект на данной версии Gradle, что позволяет создавать более надежные и устойчивые сборки.
· Предоставление новой версии Gradle различным пользователям и средам разработки (например, IDE или серверам непрерывной интеграции) осуществляется так же просто, как и изменение определения Wrapper.
Так как же это работает? Для пользователя обычно существует три различных рабочих процесса:
· Вы настраиваете новый проект Gradle, и хотите добавить к нему Wrapper.
· Вы хотите запустить проект с помощью Wrapper, который уже предоставлен для проекта.
· Вы хотите обновить Wrapper для новой версии Gradle.
В последующих секциях описывается более подробно каждый из этих случаев.
[Добавление Gradle Wrapper]
Генерация файлов Wrapper требует установленную на вашем компьютере Gradle runtime, как это описано в разделе установки Gradle [2]. К счастью, создание начальных файлов Wrapper является однократным процессом.
Каждая сборка Gradle поставляется со встроенной задачей (task), которая называется wrapper. При перечислении задач можно найти задачу, указанную в группе «Задачи установки построения». Выполнение задачи обертки создает необходимые файлы обертки в каталоге проекта. Эту задачу можно найти в группе «Build Setup tasks», если вывести список задач. Выполнение задачи wrapper генерирует необходимые файлы Wrapper в каталоге проекта.
Запуск команды gradle tasks выдаст список основных задач выбранного проекта. Этот отчет покажет задачи по умолчанию (default tasks) для проекта, если они существуют, и описание для каждой задачи.
$ gradle tasks
По умолчанию отчет этой команды покажет только те задачи, которые были назначены группе задач. Вы можете получить больше информации в списке задач, используя опцию —all.
$ gradle tasks --all
Если нужна более конкретная информация, то можно отобразить только задачи из определенной группы, используя опцию —group.
$ gradle tasks --group="build setup"
Подробное описание интерфейса командной строки Gradle см. в [3].
Запуск задачи Wrapper:
$ gradle wrapper > Task :wrapper
BUILD SUCCESSFUL in 0s 1 actionable task: 1 executed
Замечание: чтобы сделать файлы Wrapper доступными для других разработчиков и сред выполнения, необходимо добавить их в репозиторий системы управления версиями. Размер всех файлов Wrapper, включая JAR-файл, очень мал. Подразумевается добавление также и JAR-файла в систему управления версиями. Некоторые организации не разрешают проектам передавать двоичные файлы в систему управления версиями. Однако на данный момент альтернативных вариантов нет.
Информация о дистрибутиве Gradle сохраняется в файле свойств Wrapper: gradle/wrapper/gradle-wrapper.properties.
· На сервере организуется хостинг дистрибутива Gradle.
· Устанавливается тип дистрибутива Gradle. По умолчанию это дистрибутив bin, который содержит только runtime-код, но не образец кода и документацию.
· Версия Gradle используется для выполнения сборки. По умолчанию задача wrapper берет точно ту же версию Gradle, которая использовалась для генерации файлов Wrapper.
Опционально устанавливается таймаут в миллисекундах, когда загружается дистрибутив gradle.
gradle/wrapper/gradle-wrapper.properties distributionUrl=https\://services.gradle.org/distributions/gradle-8.1.1-bin.zip
Все эти аспекты конфигурируются в момент генерации файлов Wrapper с помощью следующих опций командной строки.
Версия Gradle используется для загрузки и выполнения Wrapper. Разрешены следующие метки (labels):
· latest
· release-candidate
· nightly
· release-nightly
Тип дистрибутива Gradle, используемый для Wrapper. Доступные опции bin и all. ПО умолчанию используется bin.
Полный URL, указывающий на ZIP-файл дистрибутива Gradle. Использование этой опции делает опции —gradle-version и —distribution-type устаревшими, поскольку URL уже содержит эту информацию. Опция —gradle-distribution-url очень важна, если вы хотите реализовать хостинг дистрибутива Gradle в внутри сетевой инфраструктуры компании.
Хэш-сумма SHA256, используемая для верификации загруженного дистрибутива Gradle.
Таймаут сети, используемый при загрузке дистрибутива gradle, в мс. Значение по умолчанию 10000.
Пример установки опций для задачи Wrapper. Для иллюстрации использования опций командной строки предположим следующий случай. Вы хотите генерировать Wrapper версии 8.1.1 , и используете дистрибутив all, чтобы позволить вашей IDE функцию code-completion для навигации по исходному коду Gradle. Эти требования реализуются следующей командной строкой:
$ gradle wrapper --gradle-version 8.1.1 --distribution-type all > Task :wrapper
BUILD SUCCESSFUL in 0s 1 actionable task: 1 executed
Результат этой команды вы найдете в файле свойств Wrapper.
Пример генерации URL дистрибутива:
distributionUrl=https\://services.gradle.org/distributions/gradle-8.1.1-all.zip
Давайте взглянем на следующую структуру проекта для иллюстрации ожидаемых файлов Wrapper. На Kotlin она будет выглядеть так (на Groovy будет то же самое, просто у файлы build.gradle.kts и settings.gradle.kts будут без суффикса .kts):
.
├── a-subproject
│ └── build.gradle.kts
├── settings.gradle.kts
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat
Проект Gradle обычно предоставляет файл settings.gradle(.kts) и по одному файлу build.gradle(.kts) для каждого субпроекта. Файлы Wrapper находятся рядом в каталоге gradle и корневом каталоге проекта. В следующем списке объясняется их назначение.
gradle-wrapper.jar JAR-файл Wrapper, содержащий код для загрузки дистрибутива Gradle.
gradle-wrapper.properties Файл свойств, отвечающий за конфигурирование runtime-поведение Wrapper, например определение версии Gradle, совместимой с этой версией Wrapper. Обратите внимание, что более общие настройки, такие как конфигурирование Wrapper для использования прокси, должны переходить в другой файл настроек.
gradlew , gradlew.bat Шелл-скрипт и командный файл Windows для выполнения сборки с помощью Wrapper.
Можно выполнить построение с помощью обертки без установки среды выполнения Gradle. Если проект, с которым вы работаете, не содержит эти файлы Wrapper, их необходимо сгенерировать.
[Использование Gradle Wrapper]
Рекомендуется всегда выполнять сборку с помощью Wrapper, чтобы гарантировать управляемое и стандартизированное выполнение сборки. Использование Wrapper выглядит почти как сборка с инсталляцией Gradle. В зависимости от операционной системы вы можете запустить либо gradlew, либо gradlew.bat вместо команды gradle. Следующий вывод консоли демонстрирует использование Wrapper на Windows для проекта, основанного на Java.
$ gradlew.bat build Downloading https://services.gradle.org/distributions/gradle-5.0-all.zip . Unzipping C:\Documents and Settings\имяпользователя\.gradle\wrapper\dists\gradle-5.0-all\ ac27o8rbd0ic8ih41or9l32mv\gradle-5.0-all.zip to C:\Documents and Settings\имяпользователя\ .gradle\wrapper\dists\gradle-5.0-al\ac27o8rbd0ic8ih41or9l32mv Set executable permissions for: C:\Documents and Settings\имяпользователя\.gradle\wrapper\ dists\gradle-5.0-all\ac27o8rbd0ic8ih41or9l32mv\gradle-5.0\bin\gradle
BUILD SUCCESSFUL in 12s 1 actionable task: 1 executed
В случае, когда на машине нет дистрибутива Gradle, скрипт Wrapper загрузит его и сохранит в локальной файловой системе. Любые последующие сборки будут выполняться с использованием локального дистрибутива, пока не поменяется URL дистрибутива в свойствах Gradle.
Замечание: шелл-скрипт Wrapper и командный файл Windows находится в корневой директории сборки Gradle для одиночного проекта или проекта со множеством субпроектов (multi-project). Вам понадобится обращаться к правильному пути к этим файлам в случае, если хотите их выполнить сборку из подкаталога, где находится субпроект, например gradlew tasks.
[Обновление Gradle Wrapper]
Обычно проекты стараются держать свежими, чтобы обновлять версию Gradle и пользоваться добавленными нововведениями и улучшениями. Один из способов обновить версию Gradle — вручную поменять свойство distributionUrl в файле gradle-wrapper.properties, где находятся свойства Wrapper. Лучшая и рекомендуемая опция — запустить задачу Wrapper (wrapper task) и предоставить целевую версию Gradle, как это было описано выше в разделе «Добавление Gradle Wrapper». Использование wrapper task гарантирует, что для проекта применятся любые оптимизации, сделанные для шелл-скрипта Wrapper или командного файла, вместе со специальной, соответствующей версией Gradle. Как обычно, следует сделать фиксацию (commit) изменений в файлах обертки системы управления версиями.
Обратите внимание, что однократный запуск wrapper task обновит только gradle-wrapper.properties only, но оставит не измененным сам Wrapper в файле gradle-wrapper.jar. Это обычно нормально, поскольку новые версии Gradle могут быть запущены даже со старыми файлами Wrapper. Если вы все же хотите, чтобы все файлы Wrapper были полностью обновлены, вам потребуется запустить wrapper task второй раз.
Используйте Gradle wrapper task для генерации Wrapper, указав версию. По умолчанию используется текущая версия. Когда обновили wrapper, можете проверить, та ли версия была установлена, что вы ожидали, с помощью запуска команды ./gradlew —version.
Пример обновления Wrapper на последнюю версию:
$ ./gradlew wrapper --gradle-version lates
BUILD SUCCESSFUL in 4s 1 actionable task: 1 executed
Пример обновления Wrapper на определенную версию:
Gradle Wrapper
Gradle Wrapper (или короче говоря, просто «Wrapper») — это специальный скрипт (а также несколько дополнительных файлов), который вызывает объявленную версию Gradle, при необходимости загружая ее заранее.
Рекомендуемый способ выполнения любой сборки Gradle — это с помощью Gradle Wrapper’а.
Содержимое
К его файлам относятся:
- gradlew и gradlew.bat — сами скрипты для запуска gradle через wrapper;
- gradle/wrapper/gradle-wrapper.jar — сам wrapper, небольшая java программа;
- gradle/wrapper/gradle-wrapper.properties — настройки gradle wrapper’а, в которых указывается версия gradle для всего проекта.
Запуск
Взаимодействие с Gradle Wrapper происходит при любой сборке gradle проекта. При запуске gradle задач через IDE автоматически происходит обращение к Gradle Wrapper, а когда работа идет через терминал — нужно вызывать gradlew / gradlew.bat (в зависимости от ОС).
gradlew.bat props> ./gradlew props> Вся логика работы Gradle Wrapper’а заключается в следующем:
- Скрипт проверяет наличие JDK, если ее нет — выводит соответствующее понятное сообщение.
- Считывается конфигурация из gradle-wrapper.properties , а именно — distributionUrl , в котором определено, какую версию gradle нам нужно скачать.
- Если данная версия gradle уже скачивалась, то она доступна в кешах в директории ~/.gradle и будет использоваться. Иначе же Gradle Wrapper скачает gradle нужной версии и сохранит в указанную выше кеш директорию.
- Запускает gradle нужной версии, передавая ему все опции запуска, которые были переданы в Gradle Wrapper.
Таким образом, несколько небольших файлов, лежащих в git репозитории, позволяют разработчику не вспоминать о необходимости скачать нужную для проекта версию gradle и использовать ее — автоматика все сделает сама.
Gradle Wrapper автоматически сохраняет скачиваемые версии gradle в кеш в GRADLE_HOME — ~/.gradle . Поэтому данная директория со временем начинает раздуваться в размерах, так как на разных проектах может требоваться разная версия gradle, а также на проектах периодически производят обновление версии gradle.
Удалять содержимое директории ~/.gradle , при раздувшихся размерах, можно, но нужно понимать, что следующая сборка gradle потребует значительно больше времени, так как будет скачиваться нужная версия gradle, а также все зависимости, которые нужны проекту (кеш зависимостей также лежит в GRADLE_HOME ).
Параметры
# PROJECT_DIR/gradle/gradle-wrapper.properties # определяет, следует ли хранить распакованный дистрибутив-оболочку в проекте # или в домашнем каталоге пользователя gradle. distributionBase=GRADLE_USER_HOME # путь, по которому распаковываются дистрибутивы gradle, необходимые для оболочки # он указан относительно каталога distributionBase distributionPath=wrapper/dists # URL-адрес для загрузки дистрибутива gradle distributionUrl=https\://services.gradle.org/distributions/gradle-7.2-bin.zip # указание путей для распаковки zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists Про обновление версий Gradle вы можете прочитать тут.
Материалы
- Документация — Gradle Wrapper
- Документация — Wrapper API
Gradle
Gradle — система автоматической сборки, построенная на принципах Apache Ant и Apache Maven. В Eclipse использовалась система Ant, но большинство разработчиков даже не замечало её работы. В основном возможности системы использовались в конторах для автоматизации различных задач. В Android Studio такой номер не пройдёт. Gradle сопровождает вас во время разработки постоянно. Поначалу, если вы перешли с Eclipse, Gradle сильно раздражает своими действиями. Но позже вы оцените её удобство и может даже полюбите её.
Gradle не является изобретением для Android Studio, система была разработана раньше и использовалась в приложениях для Java, Scala и других языках.
Система сборки Gradle очень мощная и сложная, чтобы о ней рассказать в двух словах. Есть целые книги о ней. Сами команды в Gradle представляют собой обычный текст с использованием синтаксиса Groove для конфигурации. Но нам не нужно знать всё. Познакомимся поближе с системой и научимся пользоваться ей.
Создайте новый проект или откройте любой существующий проект из Android Studio и посмотрите на структуру проекта.
В последних версиях студии файлы Gradle выделили в отдельную папку Gradle Script. Раскройте её. В основном вас должен интересовать файл build.gradle, который относится к модулю. Рядом с этим файлом в скобках будет написано Module: app. Двойным щелчком откройте его, вы увидите, что файл является текстовым.
Также есть файл build.gradle, который относится к проекту. Но с ним работают реже. Так находятся настройки для репозиториев и самого Gradle.
Вернёмся к файлу модуля, вы увидите много интересной информации. Например, вы там можете увидеть настройки, которые раньше вы могли видеть в манифесте — номера версий, номера SDK и так далее. Забегая вперёд, скажу, что здесь можно добавить всего одну волшебную строчку и нужная библиотека сама скачается из интернета и установится в проекте. Красота!
Однако вернёмся в корневую папку. Кроме файлов build.gradle мы можем заметить файлы gradle.properties, settings.gradle и другие. Трогать их не нужно.
В корневой папке также есть файлы gradlew и gradlew.bat для работы с Gradle Wrapper. В принципе вам не нужно знать о них ничего. Но для параноиков есть информация — если вы часто импортируете проекты из неизвестных источников, то они содержат файл gradle/wrapper/gradle-wrapper.properties. Откройте его текстовым редактором и посмотрите на адрес у distributionUrl. Путь должен вести на официальный сай //services.gradle.org или на внутренний корпоративный сервер. Другие адреса должны вызвать тревогу.
Вы могли заметить, что по сравнению с Eclipse изменилась структура файлов. В папке app находится папка src, а ней папка main, в которых папки java, res и файл манифеста. Новая структура лучше отвечает требованиям Gradle для управления файлами.
Вы, например, можете создавать альтернативные папки с ресурсами и с помощью build.gradle подключить их к проекту.
android < compileSdkVersion 20 buildToolsVersion "20.0.0" defaultConfig < applicationId "ru.alexanderklimov.hellokitty" minSdkVersion 16 targetSdkVersion 20 versionCode 1 versionName "1.0" >sourceSets < main < res < srcDirs = [ 'src/main/res', 'src/main/presentations/animations', 'src/main/presentations/layouts'] >> > >
В этом примере мы указали, что существуют новая папка presentations в папке /src/main/ наряду с существующими папками java и res. Внутри созданной папки есть ещё две папки layout и animations, которые содержат файлы ресурсов.
Только помните, что вам нужно избегать конфликта имён при слиянии всех файлов при сборке.
Значение sourceSets указывает Gradle, какие папки следует использовать. Этим приёмом пользуются продвинутые программисты. Мы пока не будем использовать такую технику.
Другая полезная возможность — создавать разные версии приложений, например, демо-версию и платную версию. Немного об этом рассказано здесь.
Номер версии приложения и требования к версии Android прописаны в секции defaultConfig. Если у вас сохранились старые версии приложений, то в манифесте можете удалить данные записи. По-моему, там даже выводится соответствующая подсказка. Даже если вы эти данные в манифесте не удалите, то значения из gradle.build имеют больший приоритет и перепишут значения в манифесте при не совпадении.
defaultConfig
Подключение библиотеки происходит одной строчкой. Например, нужно добавить библиотеку Picasso:
dependencies
В Android Studio 3.0 используется новая версия Gradle, в которой compile считается устаревшей. Вместо него следует использовать новое слово implementation.
implementation 'com.android.support:recyclerview-v7:27.0.0'
Есть похожая команда, которая подключает библиотеку, которая будет использоваться только для отладки приложения и в релизной версии она не нужна.
debugCompile 'junit:junit:4.12' // старый вариант testImplementation 'junit:junit:4.12' // новый вариант для Android Studio 3.0
Далее включаете синхронизацию и через несколько секунд в папке появляется нужная библиотека, готовая к использованию. Сама библиотека скачивается с специального хранилища-репозитория JCenter. Данный репозиторий используется по умолчанию и прописан в buil.gradle проекта.
repositories
Можно указать другой репозиторий, например, Maven Central.
repositories
Для поиска через Maven-репозиторий используйте The Central Repository Search Engine.
Библиотеку можно подключать и старым способом, используя jar-файл, но такой способ уходит в прошлое.
dependencies < compile files("libs/library1.jar", "libs/library2.jar") >
Сам файл нужно скопировать в папку /libs.
При любом изменении файла недостаточно его сохранить. Нужно также произвести синхронизацию. Наверху обычно появляется жёлтая полоска с ссылкой Sync Now.
Задаём имя APK при компиляции
Можно задать собственное имя при компиляции проекта. Например, так.
defaultConfig
Получим имя MyName-1.0.12-release.apk
Оптимизатор кода R8
Оптимизатор кода R8 имеет следующие возможности: урезание байт-кода, сжатие, обфускация, оптимизация, удаление «синтаксического сахара», преобразование в DEX. Оптимизатор может производить все операции за один шаг, что даёт сильное улучшение производительности. R8 был введён в Android Gradle plugin 3.3.0. Вам нужно только включить его.
android < buildTypes < release < minifyEnabled true > > >
R8 разработан для работы с существующими ProGuard-правилами, хотя возможны ситуации, когда нужно переработать правила.
#отключение R8 только для Android Library модулей android.enableR8.libraries = false
#отключение R8 для всех модулей android.enableR8 = false
Сжимаем итоговый APK
В Gradle 1.4 появилась возможность сжать итоговый файл, убрав неиспользуемые ресурсы, в том числе из библиотек, например, Google Play Services.
buildTypes
Во время сборки приложения вы можете увидеть строку:
:android:shrinkDebugResources Removed unused resources: Binary resource data reduced from 2570KB to 1711KB: Removed 33% .
Другой способ убрать неиспользуемые ресурсы конфигурации. Например, вам не нужные локализованные ресурсы для всех языков, которые входят в библиотеку Google Play Services или Android Support Library и др. Оставим только нужные языки. Возможно, вы также не хотите поддерживать mdpi или tvdpi-разрешения в своём приложении. Мы можем установить языки и разрешения, которые используются в приложении, остальные будут исключены, что позволит уменьшить вес приложения.
// build.gradle android < defaultConfig < resConfigs "en", "ru" resConfigs "nodpi", "hdpi", "xhdpi", "xxhdpi", "xxxhdpi" >>
Можно перенести ключи из манифеста.
Чтобы их не светить, например, если выкладывать код на Гитхабе, то сделаем так.
defaultConfig
И в манифесте переделаем код.
В большинстве случаев это сработает, но иногда ключ требуется при компиляции и указанный пример может не сработать. В таком случае применяют другой вариант через manifestPlaceholders.
defaultConfig
В манифесте пишем.
Класс BuildConfig
В статье LogCat упоминался способ быстрого отключения журналирования.
Суть в следующем. Когда вы создаёте новые переменные в блоках defaultConfig или buildTypes (ветки debug и release), то Gradle создаёт специальный класс BuildConfig, и вы можете получить доступ к этим переменным.
Например, добавим переменную в defaultConfig
defaultConfig
На языке Java это равносильно String YOUR_TOKEN = «ABRAKADABRA»;
Теперь мы можем обратиться к созданной строке.
String token = BuildConfig.YOUR_TOKEN; // Что-то делаем со своей строкой
С секцией buildType ситуация интереснее. У секции есть два блока debug и release. Можно создать переменные с разными значениями, которые будут использоваться в зависимости от ситуации. Например, у вас есть собственное API для сервера. Для тестирования вы используете один адрес, а для финальной версии — другой адрес. Тогда вы просто указываете разные адреса в разных ветках. Переменные могут быть не только строковыми.
buildTypes < debug < buildConfigField "String", "API_URL", '"http://developer.alexanderklimov.ru/api/debug/"' buildConfigField "boolean", "REPORT_CRASHES", "true" >release < . тут какие-то другие записи buildConfigField "String", "API_URL", '"http://developer.alexanderklimov.ru/api/release/"' buildConfigField "boolean", "REPORT_CRASHES", "false" >>
Создаём код для перехода на веб-страницу.
Uri addressUri = Uri.parse(BuildConfig.API_URL); Intent openLinkIntent = new Intent(Intent.ACTION_VIEW, addressUri); startActivity(openLinkIntent);
Теперь вам не нужно переписывать каждый раз код. Загружаться будет страница по нужному адресу автоматически.
Разделяем отладочную и финальную версию
По такому же принципу можно организовать запуск новой версии программы, не затрагивая программу, которую вы установили с Google Play. Допустим вы на своём телефоне установили своё собственное приложение через Google Play. Теперь вам нужно написать новую версию и проверить на своём телефоне. Из-за конфликта имён новое тестируемое приложение перепишет финальную версию или вообще не установится. Поможет следующий трюк.
buildTypes < debug < applicationIdSuffix ".debug" versionNameSuffix "-debug" resValue "string", "app_name", "AboutCat (debug)" >release < minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' resValue "string", "app_name", "AboutCat" >>
В специальных переменных applicationIdSuffix и versionNameSuffix мы задаём суффиксы, чтобы избежать конфликта. А в переменной resValue указываем название программы для отладочной и финальных версий, чтобы на устройстве можно было их найти. Не забудьте при этом удалить строковый ресурс app_name в res/values/strings.xml, иначе получите ошибку при компиляции. Теперь можете спокойно запускать приложение с новым кодом, не боясь повредить своё любимое приложение.
Прячем секретную информацию
Следующий совет больше подходит для компаний. Когда подписывается приложение, то нужно указывать пароль, хранилище и т.д. Чтобы их не светить в студии, можно прописать их в переменных и поместить в секцию signingConfigs. Сервер сам найдёт нужные ключи и воспользуется ими в своих сценариях.
signingConfigs < release < storeFile "$" keyAlias "$" storePassword "$" keyPassword "$" > >
Автогенерация версии кода
Нашёл совет, сам не применял. Не обязательно вручную менять версию приложения в атрибутах versionCode и versionName, можно сделать через переменные, а они сами подставятся в нужное место. На любителя.
def versionMajor = 1 def versionMinor = 0 def versionPatch = 0 android < defaultConfig < versionCode versionMajor * 10000 + versionMinor * 100 + versionPatch versionName "$.$.$" > >
settings.gradle
Файл settings.gradle обычно состоит из одной строчки.
include ':app'
Это означает, что у вас используется один проект для работы. Если вы будете подключать другие проекты, то здесь появятся новые строки.
gradle.properties (Project Properties)
Несколько советов по настройке файла gradle.properties.
Режим параллельного выполнения
В этом файле можно найти закомментированную строку # org.gradle.parallel=true. Если модули вашего проекта не используют друг друга как зависимости, создавая перекрёстные ссылки, можно включать режим параллельного выполнения, что ускорит скорость сборки до ~30%.
org.gradle.parallel=true # включаем режим параллельного выполнения
Gradle-демон
Включение на компьютере демона Gradle даст значительный прирост в скорости сборки.
org.gradle.daemon=true # включаем демон
Режим конфигурации при необходимости
Если в проекте используется много модулей, то можно включить режим конфигурации при необходимости. Ускорение будет заметно при большом количестве используемых модулей:
org.gradle.configureondemand=true
Меняем номер версии библиотек в одном месте
Очень часто в проекте используются взаимосвязанные библиотеки с одинаковыми номерами.
dependencies < compile 'com.android.support:appcompat-v7:23.4.0' compile 'com.android.support:design:23.4.0' compile 'com.android.support:percent:23.4.0' compile 'com.android.support:cardview-v7:23.4.0' compile 'com.android.support:gridlayout-v7:23.4.0' //play services compile 'com.google.android.gms:play-services-location:9.2.1' compile 'com.google.android.gms:play-services-gcm:9.2.1' >
Можно быстро поменять у всех номера через переменную. Для этого используется секция ext, в которой указывается переменная и номер версии. Затем в секции dependencies номер версии заменяется на имя переменной
ext < supportLibraryVersion = '24.0.0'; playServicesVersion = '9.2.1' >dependencies < compile "com.android.support:appcompat-v7:$supportLibraryVersion" compile "com.android.support:design:$supportLibraryVersion" compile "com.android.support:percent:$supportLibraryVersion" compile "com.android.support:cardview-v7:$supportLibraryVersion" compile "com.android.support:gridlayout-v7:$supportLibraryVersion" //play services compile "com.google.android.gms:play-services-location:$playServicesVersion" compile "com.google.android.gms:play-services-gcm:$playServicesVersion" >
Обратите внимание, что одинарные кавычки заменяются на двойные, а символ $ указывает на строковый тип.
Расширенная версия с разными переменными в другом виде.
ext.compileSdkProjectVersion= 24 ext.buildToolsProjectVersion= '24.0.0' ext.supportLibraryVersion = '24.0.0' ext.googlePlayVersion = '8.4.0’ android < compileSdkVersion compileSdkProjectVersion buildToolsVersion buildToolsProjectVersion //… >dependencies
Если в проекте используются несколько модулей с одинаковыми зависимостями, то эти записи можно перенести в корневой build.gradle, чтобы не менять номера версий в каждом модуле.
Настройки в Android Studio
Рассмотрим настройки, доступные в Android Studio. Закройте текущий проект, чтобы увидеть стартовое окно студии. В правой части нажмите на пункт Configure. В следующем окне выберите пункт Settings, чтобы оказаться в окне настроек студии. В левой части найдите пункт Build, Execution, Deployment, затем подпункт Build Tools, далее подпункт Gradle. По умолчанию, там всё чисто, только указан путь у Service directory path. Это были общие настройки.
Теперь рассмотрим настройки, относящиеся к проекту. Запустите любой проект в Android Studio. Выберите меню File | Settings. . Снова пройдитесь по пунктам Build, Execution, Deployment | Build Tools | Gradle. Вы увидите практически такое же окно с небольшими изменениями. Теперь поле Linked Gradle Projects не будет пустым, а также появятся дополнительные настройки. По умолчанию рекомендуют использовать Use default gradle wrapper.
Gradle Task
На правой стороне Android Studio имеется вертикальная вкладка Gradle, которую можно развернуть. Она содержит список задач (task), которая выполняет Gradle при работе с текущим проектом. Вы можете выделить любую из этих задач и запустить её двойным щелчком. Можно выделить несколько задач.
Узнать debug.keystore: MD5 и SHA1
Иногда требуется узнать значения debug.keystore: MD5 и SHA1. Обычно их получают через командную строку. Но это долго и неудобно, так как нужно помнить все аргументы. Есть способ проще. Открываем вкладку Gradle, нажимаем на кнопку со стрелками Refresh all Gradle Projects. Затем последовательно открываем элементы Tasks | android и запускаем команду signingReport. В нижнем окне Run увидите нужную информацию.
Variant: debug Config: debug Store: C:\Users\klimo_000\.android\debug.keystore Alias: AndroidDebugKey MD5: BA:6F:23:49:2D:9A:9C:0C:44:75:E0:94:59:07:E0:22 SHA1: 9D:51:F4:B8:4B:15:57:4B:EC:79:67:DC:F4:7C:5B:FB:02:C6:A2:F7 Valid until: Thursday, 1 December 2044
Gradle Console
Когда выполняется какая-то задача Gradle, то ход её выполнения можно увидеть в окне Gradle Console. Открыть её можно через вкладку Gradle Console в нижней правой части студии.
Terminal
Запускать задачи Gradle можно и в окне Terminal.
На панели инструментов имеется значок Sync Project with Gradle Files, которую следует использовать при редактировании файлов Gradle. Как правило, студия также выводит предупреждающее сообщение с ссылкой при изменении файла, которая делает ту же работу.
Добавление зависимостей через интерфейс студии
В статье описывался способ включения библиотеки в проект через редактирование файла build.gradle. Существует альтернативный вариант через настройки студии. Щёлкните правой кнопкой мыши на имени модуля (app) и выберите пункт Open Module Settings (быстрая клавиша F4). В правой части окна находятся вкладки, которые оказывают влияние на файл build.gradle. Например, вкладка Dependencies содержит подключаемые библиотеки.
Чтобы добавить новую зависимость, нажмите на значок с плюсом и выберите нужный вариант, например, Library dependency. Откроется список доступных библиотек из репозитория Maven.
Конфигурация в Android Studio Flamingo
Иногда студия начинает дурить, ругается на несовместимость каких версий библиотек, компиляторов и прочее. Вот и в версии Flamingo проект перестал собираться после какого-то обновления.
Мои настройки, после которого студия собрала проект.
// Project plugins < id 'com.android.application' version '8.0.1' apply false id 'com.android.library' version '8.0.1' apply false id 'org.jetbrains.kotlin.android' version '1.8.0' apply false >// Module compileOptions < sourceCompatibility JavaVersion.VERSION_17 targetCompatibility JavaVersion.VERSION_17 >kotlinOptions
Дополнительное чтение
В примере работы с PDF-файлами в папке assets использована операция запрета на сжатие файлов, которое происходит по умолчанию.
Задачи Gradle — теория для общего развития.
Руководство по обертке Gradle
Gradle обычно используется разработчиками для управления жизненным циклом сборки проекта. Это инструмент сборки по умолчанию для всех новых проектов Android.
В этом руководстве мы узнаем о Gradle Wrapper, сопутствующей утилите, упрощающей распространение проектов.
2. Gradle-обертка
Чтобы создать проект на основе Gradle, нам нужно установить Gradle на нашу машину. Однако, если наша установленная версия не совпадает с версией проекта, мы, вероятно, столкнемся со многими проблемами несовместимости.
Gradle Wrapper, также называемый сокращенно Wrapper , решает эту проблему. Это скрипт, который запускает задачи Gradle с объявленной версией . Если заявленная версия не установлена, Wrapper устанавливает требуемую.
Основные преимущества Wrapper заключаются в том, что мы можем:
- Создайте проект с помощью Wrapper на любой машине без предварительной установки Gradle.
- Иметь фиксированную версию Gradle. Это дает многоразовые и более надежные сборки на конвейерах CI.
- Легко обновитесь до новой версии Gradle, изменив определение Wrapper.
В следующих разделах мы будем запускать задачи Gradle, требующие локальной установки Gradle .
2.1. Генерация файлов-оболочек
Чтобы использовать Wrapper, нам нужно сгенерировать определенные файлы. Мы создадим эти файлы, используя встроенную задачу Gradle, называемую оболочкой. Обратите внимание, что нам нужно сгенерировать эти файлы только один раз.
Теперь давайте запустим задачу- оболочку в каталоге нашего проекта:
$ gradle wrapper Давайте посмотрим на вывод этой команды:
Давайте посмотрим, что это за файлы:
- gradle-wrapper.jar содержит код для загрузки дистрибутива Gradle, указанного в файле gradle-wrapper.properties
- gradle-wrapper.properties содержит свойства среды выполнения Wrapper — самое главное, версию дистрибутива Gradle, совместимую с текущим проектом.
- gradlew — это скрипт, который выполняет задачи Gradle с помощью Wrapper.
- gradlew.bat — пакетный скрипт, эквивалентный gradlew , для машин Windows .
По умолчанию задача оболочки создает файлы оболочки с версией Gradle, установленной в данный момент на компьютере. При необходимости мы можем указать другую версию:
$ gradle wrapper --gradle-version 6.3 Мы рекомендуем проверять файлы Wrapper в системе управления версиями, такой как GitHub. Таким образом мы гарантируем, что другие разработчики смогут запустить проект без необходимости установки Gradle.
2.2. Запуск команд Gradle с помощью Wrapper
Мы можем запустить любую задачу Gradle с помощью Wrapper, заменив gradle на gradlew .
Чтобы вывести список доступных задач, мы можем использовать команду gradlew tasks :
$ gradlew tasks Давайте посмотрим на вывод:
Help tasks ---------- buildEnvironment - Displays all buildscript dependencies declared in root project 'gradle-wrapper'. components - Displays the components produced by root project 'gradle-wrapper'. [incubating] dependencies - Displays all dependencies declared in root project 'gradle-wrapper'. dependencyInsight - Displays the insight into a specific dependency in root project 'gradle-wrapper'. dependentComponents - Displays the dependent components of components in root project 'gradle-wrapper'. [incubating] help - Displays a help message. model - Displays the configuration model of root project 'gradle-wrapper'. [incubating] outgoingVariants - Displays the outgoing variants of root project 'gradle-wrapper'. projects - Displays the sub-projects of root project 'gradle-wrapper'. properties - Displays the properties of root project 'gradle-wrapper'. tasks - Displays the tasks runnable from root project 'gradle-wrapper'. Как мы видим, результат такой же, как и при запуске этой задачи с помощью команды gradle .
3. Общие проблемы
Теперь давайте рассмотрим некоторые распространенные проблемы, с которыми мы можем столкнуться при работе с Wrapper.
3.1. Глобальный .gitignore, который игнорирует все файлы JAR
Некоторые организации не разрешают разработчикам регистрировать JAR-файлы в своей системе управления версиями. Обычно в таких проектах в глобальном файле .gitignore есть правило игнорировать все jar-файлы. Поэтому файл gradle-wrapper.jar не регистрируется в репозитории git. По этой причине задачи Wrapper не запускаются на других машинах. В таких случаях нам нужно принудительно добавить файл gradle-wrapper.jar в git :
git add -f gradle/wrapper/gradle-wrapper.jar Точно так же у нас может быть файл .gitignore для конкретного проекта , который игнорирует файлы jar. Мы можем исправить это, либо ослабив правило .gitignore , либо принудительно добавив файл jar-оболочки, как показано выше.
3.2. Отсутствует папка-оболочка
При проверке проекта на основе оболочки мы можем забыть включить папку оболочки , которая существует внутри папки gradle . Но, как мы видели выше, папка оболочки содержит два важных файла: gradle-wrapper.jar и gradle-wrapper.properties.
Без этих файлов мы получим ошибки при выполнении задач Gradle с Wrapper. Поэтому мы должны проверить папку- оболочку в системе контроля версий .
3.3. Удаленные файлы-оболочки
Проекты на основе Gradle содержат папку .gradle , в которой хранится кеш для ускорения выполнения задач Gradle. Иногда нам нужно очистить кеш , чтобы устранить проблемы со сборкой Gradle. Обычно мы удаляем всю папку .gradle . Но мы можем перепутать папку Gradle Wrapper с папкой .gradle и тоже удалить ее. После этого мы обязательно столкнемся с проблемами при попытке запуска задач Gradle с помощью Wrapper. «
Мы можем решить эту проблему, вытащив последние изменения из источника . Кроме того, мы можем восстановить файлы Wrapper.
4. Вывод
В этом уроке мы узнали о Gradle Wrapper и его основном использовании. Мы также узнали о некоторых распространенных проблемах, с которыми мы можем столкнуться при работе с Gradle Wrapper.
Как обычно, мы можем проверить проект со сгенерированными файлами Gradle Wrapper на GitHub .