- Gradle
- Задаём имя APK при компиляции
- Оптимизатор кода R8
- Сжимаем итоговый APK
- Класс BuildConfig
- Разделяем отладочную и финальную версию
- Прячем секретную информацию
- Автогенерация версии кода
- settings.gradle
- gradle.properties (Project Properties)
- Режим параллельного выполнения
- Gradle-демон
- Режим конфигурации при необходимости
- Меняем номер версии библиотек в одном месте
- Настройки в Android Studio
- Gradle Task
- Узнать debug.keystore: MD5 и SHA1
- Gradle Console
- Terminal
- Добавление зависимостей через интерфейс студии
- Дополнительное чтение
- Building Your Project with Gradle
- In this document
- See also
- Video
- Overview of the Build System
- Build configuration
- Build by convention
- Projects and modules
- Dependencies
- Build tasks
- The Gradle wrapper
- Create and Build an Android Studio Project
- Create a project in Android Studio
- Add a library module
- Create a new library module
- Open an activity from a library module
- Add a dependency on a library module
- Build the project in Android Studio
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 подключить их к проекту.
В этом примере мы указали, что существуют новая папка presentations в папке /src/main/ наряду с существующими папками java и res. Внутри созданной папки есть ещё две папки layout и animations, которые содержат файлы ресурсов.
Только помните, что вам нужно избегать конфликта имён при слиянии всех файлов при сборке.
Значение sourceSets указывает Gradle, какие папки следует использовать. Этим приёмом пользуются продвинутые программисты. Мы пока не будем использовать такую технику.
Другая полезная возможность — создавать разные версии приложений, например, демо-версию и платную версию. Немного об этом рассказано здесь.
Номер версии приложения и требования к версии Android прописаны в секции defaultConfig. Если у вас сохранились старые версии приложений, то в манифесте можете удалить данные записи. По-моему, там даже выводится соответствующая подсказка. Даже если вы эти данные в манифесте не удалите, то значения из gradle.build имеют больший приоритет и перепишут значения в манифесте при не совпадении.
Подключение библиотеки происходит одной строчкой. Например, нужно добавить библиотеку Picasso:
В Android Studio 3.0 используется новая версия Gradle, в которой compile считается устаревшей. Вместо него следует использовать новое слово implementation.
Есть похожая команда, которая подключает библиотеку, которая будет использоваться только для отладки приложения и в релизной версии она не нужна.
Далее включаете синхронизацию и через несколько секунд в папке появляется нужная библиотека, готовая к использованию. Сама библиотека скачивается с специального хранилища-репозитория JCenter. Данный репозиторий используется по умолчанию и прописан в buil.gradle проекта.
Можно указать другой репозиторий, например, Maven Central.
Для поиска через Maven-репозиторий используйте The Central Repository Search Engine.
Библиотеку можно подключать и старым способом, используя jar-файл, но такой способ уходит в прошлое.
Сам файл нужно скопировать в папку /libs.
При любом изменении файла недостаточно его сохранить. Нужно также произвести синхронизацию. Наверху обычно появляется жёлтая полоска с ссылкой Sync Now.
Задаём имя APK при компиляции
Можно задать собственное имя при компиляции проекта. Например, так.
Получим имя MyName-1.0.12-release.apk
Оптимизатор кода R8
Оптимизатор кода R8 имеет следующие возможности: урезание байт-кода, сжатие, обфускация, оптимизация, удаление «синтаксического сахара», преобразование в DEX. Оптимизатор может производить все операции за один шаг, что даёт сильное улучшение производительности. R8 был введён в Android Gradle plugin 3.3.0. Вам нужно только включить его.
R8 разработан для работы с существующими ProGuard-правилами, хотя возможны ситуации, когда нужно переработать правила.
Сжимаем итоговый APK
В Gradle 1.4 появилась возможность сжать итоговый файл, убрав неиспользуемые ресурсы, в том числе из библиотек, например, Google Play Services.
Во время сборки приложения вы можете увидеть строку:
Другой способ убрать неиспользуемые ресурсы конфигурации. Например, вам не нужные локализованные ресурсы для всех языков, которые входят в библиотеку Google Play Services или Android Support Library и др. Оставим только нужные языки. Возможно, вы также не хотите поддерживать mdpi или tvdpi-разрешения в своём приложении. Мы можем установить языки и разрешения, которые используются в приложении, остальные будут исключены, что позволит уменьшить вес приложения.
Можно перенести ключи из манифеста.
Чтобы их не светить, например, если выкладывать код на Гитхабе, то сделаем так.
И в манифесте переделаем код.
В большинстве случаев это сработает, но иногда ключ требуется при компиляции и указанный пример может не сработать. В таком случае применяют другой вариант через manifestPlaceholders.
В манифесте пишем.
Класс BuildConfig
В статье LogCat упоминался способ быстрого отключения журналирования.
Суть в следующем. Когда вы создаёте новые переменные в блоках defaultConfig или buildTypes (ветки debug и release), то Gradle создаёт специальный класс BuildConfig, и вы можете получить доступ к этим переменным.
Например, добавим переменную в defaultConfig
На языке Java это равносильно String YOUR_TOKEN = «ABRAKADABRA»;
Теперь мы можем обратиться к созданной строке.
С секцией buildType ситуация интереснее. У секции есть два блока debug и release. Можно создать переменные с разными значениями, которые будут использоваться в зависимости от ситуации. Например, у вас есть собственное API для сервера. Для тестирования вы используете один адрес, а для финальной версии — другой адрес. Тогда вы просто указываете разные адреса в разных ветках. Переменные могут быть не только строковыми.
Создаём код для перехода на веб-страницу.
Теперь вам не нужно переписывать каждый раз код. Загружаться будет страница по нужному адресу автоматически.
Разделяем отладочную и финальную версию
По такому же принципу можно организовать запуск новой версии программы, не затрагивая программу, которую вы установили с Google Play. Допустим вы на своём телефоне установили своё собственное приложение через Google Play. Теперь вам нужно написать новую версию и проверить на своём телефоне. Из-за конфликта имён новое тестируемое приложение перепишет финальную версию или вообще не установится. Поможет следующий трюк.
В специальных переменных applicationIdSuffix и versionNameSuffix мы задаём суффиксы, чтобы избежать конфликта. А в переменной resValue указываем название программы для отладочной и финальных версий, чтобы на устройстве можно было их найти. Не забудьте при этом удалить строковый ресурс app_name в res/values/strings.xml, иначе получите ошибку при компиляции. Теперь можете спокойно запускать приложение с новым кодом, не боясь повредить своё любимое приложение.
Прячем секретную информацию
Следующий совет больше подходит для компаний. Когда подписывается приложение, то нужно указывать пароль, хранилище и т.д. Чтобы их не светить в студии, можно прописать их в переменных и поместить в секцию signingConfigs. Сервер сам найдёт нужные ключи и воспользуется ими в своих сценариях.
Автогенерация версии кода
Нашёл совет, сам не применял. Не обязательно вручную менять версию приложения в атрибутах versionCode и versionName, можно сделать через переменные, а они сами подставятся в нужное место. На любителя.
settings.gradle
Файл settings.gradle обычно состоит из одной строчки.
Это означает, что у вас используется один проект для работы. Если вы будете подключать другие проекты, то здесь появятся новые строки.
gradle.properties (Project Properties)
Несколько советов по настройке файла gradle.properties.
Режим параллельного выполнения
В этом файле можно найти закомментированную строку # org.gradle.parallel=true. Если модули вашего проекта не используют друг друга как зависимости, создавая перекрёстные ссылки, можно включать режим параллельного выполнения, что ускорит скорость сборки до
Gradle-демон
Включение на компьютере демона Gradle даст значительный прирост в скорости сборки.
Режим конфигурации при необходимости
Если в проекте используется много модулей, то можно включить режим конфигурации при необходимости. Ускорение будет заметно при большом количестве используемых модулей:
Меняем номер версии библиотек в одном месте
Очень часто в проекте используются взаимосвязанные библиотеки с одинаковыми номерами.
Можно быстро поменять у всех номера через переменную. Для этого используется секция ext, в которой указывается переменная и номер версии. Затем в секции 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 увидите нужную информацию.
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.
Дополнительное чтение
В примере работы с PDF-файлами в папке assets использована операция запрета на сжатие файлов, которое происходит по умолчанию.
Задачи Gradle — теория для общего развития.
Источник
Building Your Project with Gradle
In this document
See also
Video
What’s New in Android Developer Tools
The Android Studio build system is the toolkit you use to build, test, run and package your apps. The build system is independent from Android Studio, so you can invoke it from Android Studio or from the command line. After you write your application, you can use the features of the build system to:
- Customize, configure, and extend the build process.
- Create multiple APKs for your app with different features using the same project.
- Reuse code and resources.
The flexibility of the Android Studio build system enables you to achieve all of this without modifying your app’s core project files.
Overview of the Build System
The Android Studio build system consists of an Android plugin for Gradle. Gradle is an advanced build toolkit that manages dependencies and allows you to define custom build logic. Many software projects use Gradle to manage their builds. The Android plugin for Gradle does not depend on Android Studio, although Android Studio is fully integrated with it. This means that:
- You can build your Android apps from the command line on your machine or on machines where Android Studio is not installed (such as continuous integration servers).
- You can build your Android apps from Android Studio with the same custom build configuration and logic as when you build from the command line.
The output of the build is the same whether you are building a project from the command line, on a remote machine, or using Android Studio.
Build configuration
The build configuration for your project is defined inside Gradle build files, which are plain text files that use the syntax and options from Gradle and the Android plugin to configure the following aspects of your build:
- Build variants. The build system can generate multiple APKs with different configurations for the same project. This is useful when you want to build different versions of your application without having to create a separate project for each of them.
- Dependencies. The build system manages project dependencies and supports dependencies from your local filesystem and from remote repositories. This prevents you from having to search, download, and copy binary packages for your dependencies into your project directory.
- Manifest entries. The build system enables you to specify values for some elements of the manifest file in the build configuration. These new values override the existing values in the manifest file. This is useful if you want to generate multiple APKs for your project where each of them has a different package name, minimum SDK version, or target SDK version.
- Signing. The build system enables you to specify signing settings in the build configuration, and it can sign your APKs during the build process.
- ProGuard. The build system enables you to specify a different ProGuard rules file for each build variant. The build system can run ProGuard to obfuscate your classes during the build process.
- Testing. The build system generates a test APK from the test sources in your project, so you do not have to create a separate test project. The build system can run your tests during the build process.
Gradle build files use Groovy syntax. Groovy is a dynamic language that you can use to define custom build logic and to interact with the Android-specific elements provided by the Android plugin for Gradle.
Build by convention
The Android Studio build system assumes sensible defaults for the project structure and other build options. If your project adheres to these conventions, your Gradle build files are very simple. When some these conventions do not apply to your project, the flexibility of the build system allows you to configure almost every aspect of the build process. For example, if the sources for your project are located in a different directory than the default, you can specify this location in the build file.
Projects and modules
A project in Android Studio represents a complete Android app. Android Studio projects consist of one or more modules. A module is a component of your app that you can build, test, or debug independently. Modules contain the source code and resources for your app. Android Studio projects contain three kinds of modules:
- Java library modules contain reusable code. The build system generates a JAR package for Java library modules.
- Android library modules contain reu sable Android-specific code and resources. The build system generates an AAR (Android ARchive) package for library modules.
- Android application modules contain application code and may depend on library modules, although many Android apps consists of only one application module. The build system generates an APK package for application modules.
Android Studio projects contain a top-level Gradle build file that lists all the modules in the project, and each module contains its own Gradle build file.
Dependencies
The Android Studio build system manages project dependencies and supports module dependencies, local binary dependencies, and remote binary dependencies.
A project module can include in its build file a list of other modules it depends on. When you build this module, the build system assembles and includes the required modules.
If you have binary archives in your local filesystem that a module depends on, such as JAR files, you can declare these dependencies in the build file for that module.
When some of your dependencies are available in a remote repository, you do not have to download them and copy them into your project. The Android Studio build system supports remote Maven dependencies. Maven is a popular software project management tool that helps organize project dependencies using repositories.
Many popular software libraries and tools are available in public Maven repositories. For these dependencies you only have to specify their Maven coordinates, which uniquely identify each element in a remote repository. The format for Maven coordinates used in the build system is group:name:version . For example, the Maven coordinates for version 16.0.1 of the Google Guava libraries are com.google.guava:guava:16.0.1 .
The Maven Central Repository is widely used to distribute many libraries and tools.
Build tasks
The Android Studio build system defines a hierarchical set of build tasks: the top-level tasks invoke the tasks they depend on to produce the necessary outcomes. The build system provides project tasks to build your app and module tasks to build modules independently.
You can view the list of available tasks and invoke any task from Android Studio and from the command line, as described in Build the project in Android Studio and and Build the project from the command line.
The Gradle wrapper
Android Studio projects contain the Gradle wrapper, which consists of:
- A JAR file
- A properties file
- A shell script for Windows platforms
- A shell script for Mac and Linux platforms
Note: You should submit all of these files to your source control system.
Using the Gradle wrapper (instead of the local Gradle installation) ensures that you always run the version of Gradle defined in the properties file. To configure your project to use a newer version of Gradle, edit the properties file and specify the new version there.
Android Studio reads the properties file from the Gradle wrapper directory inside your project and runs the wrapper from this directory, so you can seamlessly work with multiple projects that require different versions of Gradle.
Note: Android Studio does not use the shell scripts, so any changes you make to them won’t work when building from the IDE. You should define your custom logic inside Gradle build files instead.
You can run the shell scripts to build your project from the command line on your development machine and on other machines where Android Studio is not installed.
Create and Build an Android Studio Project
This section builds on the concepts presented above and shows you how to:
- Create projects and modules.
- Work with the project structure.
- Edit build files to configure the build process.
- Build and run your app.
Create a project in Android Studio
To create a new project in Android Studio:
- Click File and select New Project.
- In the window that appears, enter «BuildSystemExample» in the Application name field.
- Leave the rest of the values unchanged and click Next.
- Leave the default icon settings unchanged and click Next.
- Select Blank Activity and click Next.
- Leave the default activity and layout names unchanged and click Finish.
Figure 1 shows how the Android Studio window looks like after creating the project.
Component
/
When you add additional modules to your project, the directory structure for each module is similar to the one shown in table 1, replacing app by the name of the module.
Add a library module
This section shows you how to add a library module to your project and how to add this library as a dependency of an application module.
Create a new library module
It is good development practice to group functionality that you may reuse in other apps inside a library module. To create a library module inside the BuildSystemExample project:
- Click File and select New Module.
- On the window that appears, select Android Library and click Next.
- Leave the default module name ( lib ) unchanged and click Next.
- Select Blank Activity and click Next.
- Type «LibActivity1» on the Activity Name field and click Finish.
The project now contains two modules, app and lib , with one activity in each module.
Open an activity from a library module
Library modules contain activities and other logic that one or more application modules reuse. In this example, MainActivity in the app module opens LibActivity1 from the lib module. To open LibActivity1 from MainActivity :
Edit the layout file for MainActivity in the app module. This file is located in app/src/main/res/layout/activity_main.xml . Replace the contents of this file with the following:
Copy the following code inside the onButton1Clicked method in MainActivity :
When the user taps the Open LibActivity1 button on MainActivity (from the app module), LibActivity1 (from the lib module) starts.
Add a dependency on a library module
The app module now depends on the lib module, but the build system does not know about this yet. Edit the build file for the app module ( app/build.gradle ) and add a dependency on the lib module:
The lib module can still be built and tested independently, and the build system creates an AAR package for it that you could reuse in other projects.
Build the project in Android Studio
To build the project on Android Studio, click Build and select Make Project. The status bar at the bottom of the window shows the current progress of the build:
Gradle: Executing tasks: [:app:assembleDebug, :lib:bundleDebug]
If your project uses product flavors, Android Studio invokes the task for the selected build variant. For more information, see Work with build variants.
Click The Gradle Console shows the build tasks and subtasks that the build system runs for Android Studio. If the build fails, you can find more details on the console. To hide the Gradle Console, click
Источник