Метаданные модуля, что это за программа для Android
Обновлено: 20.11.2024
Недавно компания Google выпустила Instant Apps для разработчиков в рамках усилий, направленных на запуск следующего крупного усовершенствования нативных приложений для Android. Мгновенные приложения призваны помочь пользователям как можно быстрее получить наилучшие возможности приложения, загружая только части приложения, когда они им нужны. Это позволяет быстро и легко привлечь пользователей к работе с мобильным приложением, даже если оно не установлено на их устройствах.
Приложения с мгновенным запуском предоставляются пользователю в виде небольших функциональных модулей, каждый из которых содержит только код и ресурсы, необходимые для выполнения определенного действия. Приложения с мгновенным запуском запускаются с помощью намерений URL, что означает, что их можно запускать из любого места, включая результаты поиска, публикации в социальных сетях, сообщения, маяки, NFC и другие приложения или даже другие приложения с мгновенным запуском.
Приложения с мгновенным запуском используют единую кодовую базу с установленными аналогами APK, а также распространяются через магазин Google Play через раздел приложений с мгновенным запуском для Android.
Разработка мгновенного приложения
Инструменты
Чтобы начать работу с Instant Apps, вам потребуется несколько новых инструментов.
- Android Studio 3.0 и Instant Apps SDK. Наряду с Instant Apps SDK компания Google также объявила о выпуске предварительной версии Android Studio 3.0, которая включает в себя множество полезных новых функций, включая поддержку Instant Apps. Вам нужно будет скачать и установить его, чтобы начать. Полный набор инструкций доступен здесь
- Gradle 4.0 (Nightly). Наряду с другими улучшениями, Gradle 4.0 поставляется с новыми конфигурациями зависимостей, которые вы можете использовать. Стоит отметить, что конфигурация компиляции устарела в Gradle 3.4 в пользу API и реализации. Эти новые конфигурации помогают вам контролировать, какие зависимости вы предоставляете как часть общедоступного API; Реализация должна использоваться для объявления зависимостей, которые доступны только внутри модуля, в то время как зависимости, объявленные с помощью API, будут экспортированы и доступны нижестоящим.
- Подключаемый модуль Android для Gradle 3.0.0-alpha1. Он поставляется с несколькими новыми подключаемыми модулями Gradle, помогающими разделить ваше приложение на модули; com.android.instantapp и com.android.feature.
- API приложений с мгновенным запуском – Google также создал удобную коллекцию утилит, которые вы можете включить в свой проект следующим образом:
Он содержит несколько полезных статических методов, которые помогают проверить, взаимодействует ли пользователь с мгновенной или установленной версией вашего приложения, а также предложить им установить полный APK в системном диалоговом окне.
Определите вариант использования
Первый и, возможно, самый важный шаг — определить, какие части вашего приложения будут лучше всего работать в качестве функций в приложении с мгновенным запуском. Мгновенные приложения управляются действиями и становятся доступными для пользователей именно тогда, когда они необходимы. Например, у пользователя на новом гараже может не быть установленного заранее подходящего приложения для парковки, но с мгновенными приложениями все, что нужно сделать пользователю, — это перейти по URL-адресу, и родное приложение может воспользоваться всеми богатыми платежными API. уже доступны, быстро и легко.
Приложения с мгновенным запуском должны в первую очередь помогать пользователям выполнять любую поставленную перед ними задачу с минимальными трудностями, а не стимулировать полные установки приложения.
Точно так же приложения с мгновенным запуском не должны выступать в качестве пробных или облегченных версий полного приложения. Это может потребовать пересмотра того, как ваши пользователи в настоящее время взаимодействуют с вашими приложениями. Как они приходят в приложение? А также каким контентом они часто делятся?
Подумайте, каким будет новый поток. В вашем приложении может быть несколько точек входа, и ни одна из них не может быть связана с панелью запуска. Кроме того, вы должны учитывать возможность того, что приложение может быть удалено из системы сразу после того, как пользователь перестанет с ним взаимодействовать.
Уменьшите размер вашего приложения
С Instant Apps иметь компактное приложение как никогда важно.
Что на самом деле не оставляет много места для больших зависимостей. Это означает, что стоит пересмотреть то, что важно для вас и ваших пользователей. Например, вы можете сэкономить на раздувании функций, если: пересмотрите свои факторы успеха, а также то, как вы их отслеживаете; удаление неиспользуемого кода; оптимизация ресурсов; а правильная защита ваших модулей действительно может помочь уменьшить ваше приложение.
Поддержка ссылок на контент и ссылок на приложения
Если вы создавали сложные приложения, поддерживающие несколько пользовательских потоков, скорее всего, вы внедрили прямые ссылки. Глубокие ссылки позволяют любому создать URL-адрес, который ведет непосредственно на определенный экран или поток в вашем приложении. Поскольку приложения с мгновенным запуском работают по URL-адресам, теперь обязательными являются ссылки на контент и ссылки на приложения. Одно из основных отличий от обычных ссылок на контент заключается в том, что не поддерживаются пользовательские схемы URI, такие как
Вы можете продолжать использовать свою собственную схему в установленном приложении, если хотите, однако есть веские основания для переключения всех глубоких ссылок на URL-адреса.
Каждая функция в вашем приложении с мгновенным запуском должна иметь хотя бы одну точку входа, определяемую как ссылка на контент. Это определяет, что увидят пользователи Activity, когда они щелкнут URL-адрес приложения с мгновенным запуском или если они перейдут к функции из другой функции в вашем приложении с мгновенным запуском. Вот пример фильтра намерений, который связывает шаблон ссылок на контент с действием.
В этом случае ItemDetailActivity будет запускаться при посещении пользователем
Ссылки на приложения
Во-вторых, вам также потребуется связать свой веб-домен с именем пакета приложения с мгновенным запуском. Эта привязка, известная как ссылки на приложения для Android, доказывает Google, что вы владеете и контролируете веб-домен, который хотите связать со своим приложением. Ранее ссылки на приложения позволяли установленным приложениям автоматически ассоциировать себя с вашим веб-доменом, поэтому, когда пользователи нажимают на URL-адреса вашего веб-сайта, они пропускают диалог устранения неоднозначности и переходят непосредственно в ваше приложение. Теперь, настроив ссылки на приложения для вашего приложения с мгновенным запуском, пользователи без установленного приложения будут беспрепятственно перенаправляться в ваше приложение с мгновенным запуском. Ссылки на приложения являются необязательными для установленных приложений, поскольку пользователи могут вручную выбирать, какие приложения они хотят обрабатывать вашими глубокими ссылками, однако ссылки на приложения являются обязательным требованием для работы мгновенных приложений. Чтобы настроить его, вам просто нужно разместить один файл JSON в корне вашего домена или поддомена по адресу /.well-known/assetlinks.json
Несмотря на то, что ваши модули приложений с мгновенным запуском должны иметь отдельные имена пакетов для целей пространства имен, ваше приложение с мгновенным запуском и устанавливаемое приложение могут иметь общий идентификатор приложения, поэтому вам нужно только зарегистрировать этот идентификатор приложения в поле "package_name". Дополнительную информацию о настройке ссылок на приложения можно найти здесь.
Модулизируйте и рефакторинг вашего приложения
Это, пожалуй, самый сложный шаг в создании приложения с мгновенным запуском, особенно для существующих приложений. Это связано с тем, что подавляющее большинство приложений сегодня представляют собой в основном сборки с одним модулем, а поддержка Instant Apps требует от разработчиков разделения своих сборок на несколько модулей, называемых функциями. Каждая функция представляет собой часть приложения, которую можно загрузить по запросу.
- Функциональные модули — это модули, которые применяют новый подключаемый модуль Gradle com.android.feature. Это просто библиотечные проекты, создающие aar при использовании другими модулями. Стоит отметить, что у них нет идентификаторов приложений, потому что это просто библиотечные проекты.
Также стоит отметить манифест функционального модуля, поскольку функционально он является лишь частью полного приложения, и его манифест будет объединен с другими при сборке проекта. Таким образом, манифесты функциональных модулей должны содержать такие вещи, как действия, содержащиеся в модуле. Каждый манифест функции также должен содержать уникальное имя пакета для модуля.
Например, вот манифест из примера функционального модуля.
- Базовый функциональный модуль. Базовый функциональный модуль можно рассматривать как основу вашего проекта. Он содержит общий код и ресурсы, которые будут использоваться другими модулями. Базовая функция отличается от других тем, что для свойства baseFeature задано значение true.
Каждый проект, в котором используются функциональные модули, должен иметь ровно один базовый модуль, и каждый функциональный модуль должен зависеть от базового модуля.
Вот пример сценария сборки базового функционального модуля.
Манифест базовой функции обычно содержит глобальные элементы, такие как тег вашего приложения. Вот пример манифеста базовой функции.
Хотя это и не является обязательным, рекомендуется, чтобы ваш базовый манифест функции содержал тег действия, который ссылается на действие, реализующее метаданные URL-адреса по умолчанию. Это сообщает Android, какое действие следует запускать в случае, если ваше приложение с мгновенным запуском открывается не по ссылке на контент, а где-то вроде средства запуска.
- APK-модуль. Это обычный модуль сборки, с которым мы все знакомы. Теперь он настроен на использование базовых и функциональных модулей для вывода apk, который будет установлен на пользовательских устройствах. Поскольку он предназначен для вывода устанавливаемого артефакта, у этого модуля есть идентификатор приложения.
Здесь манифест приложения является результатом слияния всех остальных манифестов, унаследованных от других функциональных модулей. В результате его манифест довольно разреженный.
- Модуль приложения с мгновенным запуском — реализует подключаемый модуль com.android.instant. Используйте функциональные модули и создайте разделенный zip-архив APK, содержащий все функции, которые войдут в приложение с мгновенным запуском. Это в значительной степени пустая оболочка проекта без манифеста, который реализует только другие функциональные модули проекта.
Вот пример сценария сборки модуля приложения с мгновенным запуском.
Проблемы, с которыми вы можете столкнуться
Теперь, когда мы рассмотрели структуру приложений с мгновенным запуском, важно рассмотреть некоторые проблемы, с которыми мы столкнулись при создании приложения с мгновенным запуском. Некоторые плагины Gradle, на которые вы полагаетесь, могут не работать. Многие плагины Gradle для проектов Android проверяют наличие модулей с помощью плагинов com.android.application или com.android.library. Хотя новый подключаемый модуль com.android.feature работает аналогично проекту библиотеки, у него нет имени образца пакета, поэтому ваши любимые подключаемые модули Gradle могут нуждаться в обновлении.
Вы можете получить имя пакета вашего приложения из контекста и заставить VIEW Intent рассматривать только действия под вашим именем пакета.
Развертывание
Тестирование при разработке
Чтобы протестировать приложение с мгновенным запуском локально во время разработки, вы можете просто использовать Android Studio для запуска своего приложения с мгновенным запуском. Но вот как это работает за кулисами.
Предположим, что ваш модуль приложения с мгновенным запуском называется InstantApp. Сначала запустите задачу gradle gradle :instantapp:assembleDebug Это создаст артефакт zip-архива в папке ваших сборок. Затем разархивируйте этот архив, и вы найдете несколько APK, по одному для каждого функционального модуля. Наконец, запустите эту команду adb, чтобы одновременно установить все эти APK. adb install-multiple -r -t --ephemeral base.apk feature1.apk feature2.apk, где base.apk, feature1.apk и feature2.apk — это APK ваших функций. Предупреждение: мы заметили, что эта команда adb может периодически завершаться ошибкой.
Развертывание в рабочей среде
Чтобы развернуть приложение с мгновенным запуском в Google Play Store, вам просто нужно запустить ту же задачу gradle, что и выше, но с использованием варианта выпуска: gradle :instantapp:assembleRelease. Затем загрузите zip-архив в консоль Play Store. Вам не нужно распаковывать архив. Но прежде чем Google примет ваше приложение с мгновенным запуском, вам необходимо убедиться, что некоторые параметры настроены правильно.
Подписание кода
Приложения с мгновенным запуском — это, по сути, набор APK-файлов, по одному для каждого функционального модуля. Поэтому вам нужно будет подписать каждый из этих APK так же, как вы подписываете устанавливаемый APK. Это означает, что вам нужно будет добавить конфигурацию подписи в файл build.gradle каждого функционального модуля (включая базовый функциональный модуль).
Фильтры намерений
Чтобы развернуть приложение с мгновенным запуском, вам также необходимо убедиться, что фильтры намерений в ваших манифестах имеют определенный формат. Пример рабочей настройки см. в объявлении для ItemDetailActivity выше. Вот ключевые моменты:
Убедитесь, что вы указали android:autoVerify="true". Этот атрибут указывает Android автоматически проверять ваши ссылки на приложения. Поскольку приложения с мгновенным запуском работают на основе ссылок на приложения, этот атрибут является обязательным. Убедитесь, что вы используете несколько тегов только с одним атрибутом каждый. Поэтому вместо
Пример приложения: Шмель
Мы создали образец приложения под названием Bumblebee, чтобы понять, что возможно с Instant Apps. Bumblebee — это вымышленный магазин с простым каталогом и общими тележками для покупок. Он использует Firebase для данных каталога, пользовательских данных и размещения ресурсов. Мы также разработали приложение с использованием новых компонентов архитектуры Google, которые оказались чрезвычайно полезными и простыми в использовании. Более подробную информацию об этих новых архитектурных библиотеках можно найти здесь. Мы рекомендуем ознакомиться с замечательными сообщениями Эрика Ричардсона в блоге.
Bumblebee – это приложение с мгновенным запуском, состоящее из трех функциональных модулей, каждый из которых содержит собственный экран. Корневая точка входа — это функция «Обзор», которая демонстрирует сетку продуктов, доступных для покупки (на самом деле это просто фотографии предметов, которые мы нашли в офисе). Нажав на один из них, вы перейдете к функции «Детали товара», в которой указана цена и полное описание. Отсюда вы можете добавить товар в корзину. Если у вас есть корзина, вы можете просмотреть ее с помощью функции «Корзина покупок» и легко поделиться ссылкой на мгновенное приложение в свою корзину. Помните, что ссылки на мгновенные приложения — это просто URL-адреса. Любой, с кем вы поделитесь ссылкой, может сразу же получить доступ к вашей корзине напрямую как к приложению с мгновенным запуском без необходимости загружать функции каталога.
Вот несколько ссылок, которые вы можете открыть на своем телефоне Android, чтобы попробовать Bumblebee:
Злоупотребление метаданными многоплатформенных модулей Compose и Gradle
04 ноября 2021 г.
Большую часть года мой основной рабочий проект (под названием Redwood) построен на основе Compose 1 и работает на всех платформах, которые поддерживает Kotlin. Это, конечно, означает Android, но у нас также есть Compose, работающий на iOS, в Интернете, JVM и всех других нативных целях. Это действительно мультиплатформенный проект Compose 2 .
Заставить Compose работать на всех этих платформах не так сложно, как вы думаете. Среда выполнения Compose написана как мультиплатформенный код Kotlin, но Google поставляет его только для Android. JetBrains идет еще дальше, поставляя версии, скомпилированные для Интернета и для JVM. Мы просто делаем все возможное и компилируем его для каждой цели Kotlin, а также поставляем как единый мультиплатформенный артефакт Kotlin.
В течение года это работало нормально. Однако недавно пользовательский интерфейс Compose стал стабильным, а это означало, что наши инженеры Android стремились начать использовать его в основном приложении (а не только в примерах). После введения Compose UI D8 завершается с ошибкой повторяющегося класса:
Компания Redwood уже собирала Compose на основе тех же git SHA, что и релизные сборки Google. В идеале мы могли бы использовать наши собственные сборки для каждой платформы, кроме Android, а затем указать артефакт Google исключительно для Android. Это позволит Gradle увидеть два проекта как имеющие общую зависимость, тем самым устраняя дублирование классов среды выполнения Compose.
Метаданные модуля Gradle
Механизм, с помощью которого многоплатформенные артефакты Kotlin разрешают правильную зависимость, основан на формате метаданных модуля Gradle.
Метаданные модуля Gradle – это уникальный формат, направленный на улучшение разрешения зависимостей за счет обеспечения многоплатформенности и поддержки вариантов.
Метаданные модуля — это документ JSON, в котором описаны поддерживаемые платформы с помощью атрибутов "ключ-значение". Для среды выполнения Redwood Compose метаданные модуля выглядят примерно так:
Для пользователя Android перенаправление артефакта разрешается в app.cash.redwood:compose-runtime-android, что является одной из координат неправильного артефакта, видимых в ошибке дублирования класса из D8. Как я упоминал выше, мы хотим, чтобы этот вариант перенаправлял на сборку Google среды выполнения Compose, а не на нашу собственную.
Мы могли бы попытаться изменить значения в объекте available-at, чтобы они указывали на артефакт Google, но в соответствии со спецификацией метаданных модуля Gradle ключ URL также должен указывать на файл метаданных, который Google не поставляет. р>
К счастью, массив зависимостей чуть ниже available-at в спецификации позволяет указывать произвольные координаты Maven. Это позволило бы нам определить вариант без доступного атрибута, но с одним элементом зависимости от связанного с ним артефакта среды выполнения Google Compose.
Но файл метаданных модуля полностью создается Gradle на основе информации о проекте. Как мы можем изменить его, чтобы изменить вывод только одного варианта?
Изменение метаданных модуля Gradle
Спойлер: вы не можете. По крайней мере, не использовать какие-либо стабильные API, предоставляемые Gradle 4 .
Лучший (единственный?) механизм, который я нашел, — это подключиться к задаче создания файла метаданных модуля и выполнить текстовую модификацию JSON сразу после его создания.
Сначала мы определяем текстовый файл, содержащий ожидаемое содержимое JSON, которое необходимо заменить 5 .
Обратите внимание, как заполнитель используется для минимизации изменений в этом файле с течением времени.
Далее определите замену JSON в другом файле.
И снова мы используем специальную строку, чтобы свести к минимуму необходимость изменения этого файла при обновлении до новых версий Compose.
Наконец, выполните эту текстовую замену сразу после создания файла. Здесь заполнители и заменены их реальными значениями.
Это очень хитрый код, но любые неожиданные изменения в формате метаданных модуля приведут к сбою сборки, что позволит вам переоценить подход. Возможно, в будущем Gradle будет поддерживать этот тип преобразования с помощью стабильного общедоступного API.
Эта простая замена текста сегодня решает исходную проблему дублирования классов. И это делается таким образом, что потребителю не требуется разбираться в нюансах построения среды выполнения Compose.
Несмотря на решение проблемы для сборок Android, у нас все еще есть проблема дублирования классов для других платформ, на которых можно использовать несколько проектов на основе Compose. Если бы вы использовали Redwood на JVM с Compose for Desktop от JetBrains, у вас было бы две копии среды выполнения Compose (возможно, созданные из разных версий). То же самое верно для ориентации в Интернете и использования JetBrains Compose for Web.
Чтобы исправить эту ситуацию, Google действительно должен поставлять среду выполнения Compose в качестве надлежащего мультиплатформенного артефакта для всех целей Kotlin. К сожалению, их мультиплатформенная история на Kotlin отстает от потребностей сообщества на несколько лет, и вероятность того, что это произойдет в ближайшее время, очень маловероятна. Лучшее, на что мы можем надеяться сейчас, это то, что JetBrains выпустит надлежащий мультиплатформенный артефакт среды выполнения Compose с той же версией, что и у Google, и использует этот хак, чтобы указать вариант Android на двоичный файл Google. Тогда каждый в многоплатформенном пространстве Compose сможет стандартизировать свои артефакты.
Однако до тех пор мы продолжим несовершенную практику создания собственной среды выполнения Compose для Redwood и указания на артефакт Google для Android 6 .
В продолжение плохого названия, связанного с Compose, JetBrains имеет проект под названием Compose Multiplatform, который не является полностью мультиплатформенным и не полностью переносит пользовательский интерфейс Compose на каждую поддерживаемую платформу. Наш проект — это «просто» среда выполнения Compose (не Compose UI), но работающая полностью на нескольких платформах. ↩
В отличие от JVM, путь к классам которой представляет собой набор jar-файлов, каждый из которых содержит классы, в которых побеждает первый, путь к классам в Android представляет собой единый набор классов, в котором дубликаты не поддерживаются (из-за формата файла dex). ↩
Начиная с Gradle 7.2. ↩
Опущено в предыдущем примере, некоторые варианты имеют запись "API" и "среда выполнения". ↩
Мы также должны создать подключаемый модуль компилятора Compose Kotlin для нативного кода из-за того, как работает компилятор Kotlin/Native. Google может отправить его, или JetBrains может заставить существующие плагины работать как нативные. ↩
Я новичок в Android и раньше не видел и не слышал о метаданных. Однако я гуглю это и ищу об этом на YouTube, что это в основном информация о вашем объекте. Поправьте меня, если я ошибаюсь. Может ли кто-нибудь помочь мне понять это лучше.
1) Что такое метаданные?
2) Почему он используется в Android?
Было бы хорошо, если бы на примере было дано объяснение, почему метаданные используются в Android. Я видел их внутри тега метаданных активности манифеста.
они просто используются для хранения данных в паре ключ-значение, которую можно вызвать из родительского компонента. Этого знания достаточно для отдыха, исследованиям нет конца.
3 ответа 3
В Android вы можете определить метаданные в файле AndroidManifest.xml
Очень простое использование
По сути, это дополнительная возможность хранения информации, к которой можно получить доступ через весь проект. В этом случае определяется внешний тег и внутренний тег.
Вы можете сохранить boolean , int , String или float.
Это полезно для библиотеки или API
Допустим, вы создали API/LIB, который могут использовать все. Однако для конкретной процедуры вам нужен КЛЮЧ, и этот КЛЮЧ должен быть определен разработчиком, который будет использовать ваш API. Таким образом, вы не можете предсказать, каким ключом поделится разработчик.
Используя , разработчик, который хочет использовать ваш API/LIB, может поделиться с вами КЛЮЧОМ. Таким образом, вы оставляете свой API настроенным на чтение этого КЛЮЧА и создаете исключение, если пользователь не определил его.
Одним из классических примеров является Google Реклама (Admob).
Вы должны добавить следующую строку в свой AndroidManifest:
Это загрузит com.google.android.gms.version со значением, представленным @integer/google_play_services_version . Затем, вероятно, службы Google Play (Admob) прочитают эти метаданные и смогут определить версию службы Google Play, которую вы использовали при создании своего приложения.
Еще один пример
Еще одно применение для — когда их нужно использовать для настройки действия. Таким образом, вы можете передать Android ценную информацию о своей активности, и тогда Android сможет правильно обрабатывать вашу активность. В этом случае тег добавляется внутри тега.
Метаданные модуля Gradle достигают 1.0 в Gradle 5.3, и здесь мы объясняем, почему вы должны быть так же взволнованы, как и мы!
Метаданные модуля Gradle были созданы для решения многих проблем, которые годами мешали управлению зависимостями, в частности, но не исключительно, в экосистеме Java. Это особенно важно, потому что файлы POM (или файлы Ivy) просто недостаточно богаты, чтобы описать реальность современного программного обеспечения, когда вам может потребоваться различать двоичные файлы для разных платформ или выбирать одну конкретную реализацию API, когда доступно несколько.
Мы опишем другие примеры позже в этом посте. Некоторые проблемы могут иметь обходные пути, но там, где эти обходные пути являются хакерскими или даже подверженными ошибкам. Например, вы понимали, что это проблематично: использование классификаторов для разных версий Java, исключения, чтобы избежать привязки определенного регистратора, или добавление зависимостей первого уровня только потому, что вам нужно переопределить определенную версию?
Метаданные модуля Gradle 1.0 — это ответ на эти проблемы и первый шаг к лучшему управлению зависимостями в нашей отрасли.
Что это позволяет на практике?
Вы когда-нибудь ругались, когда у вас были и guava-jdk5, и guava-jdk8 в пути к классам, и ваше приложение работало только из-за удачного порядка записей? Вы когда-нибудь сталкивались с проблемой наличия разных привязок SLF4J и замечали это только во время выполнения? Это связано с тем, что эти библиотеки имеют разные варианты, которые не могут быть правильно описаны существующими форматами метаданных. Как инструмент сборки вообще должен понимать разницу между JAR jdk8, исходным кодом или даже всем? Метаданные модуля Gradle предназначены для объяснения разницы таким образом, чтобы потребители могли выразить более точные требования. Например, потребитель может специально запросить что-то, что он может использовать с JDK 8. А в случае SLF4J инструмент сборки распознает, что привязка Log4J является взаимоисключающей с привязкой java.util.logging.
Идея заключается в поддержке управления зависимостями с учетом вариантов, которое основано на описании вариантов компонента, таких как основные двоичные файлы, пакеты с исходным кодом, двоичные файлы для конкретных платформ и т. д., а также их соответствующих зависимостей. .
Некоторые из наших партнеров используют метаданные Gradle уже несколько месяцев. Нативный Kotlin, например, использует метаданные модуля Gradle для представления различных двоичных файлов, которые вы можете получить при компиляции проекта Kotlin для разных архитектур. Google использует управление зависимостями с учетом вариантов, но ему не хватает «внешней модели». Метаданные модуля Gradle — это внешняя модель, которая позволит правильно публиковать архивы Android (AAR).
Это всего лишь примеры, но эти и многие другие проблемы можно решить, используя метаданные Gradle. По мере того, как все больше авторов библиотек будут использовать метаданные модуля Gradle, наша отрасль в целом будет решать больше проблем.
Как метаданные модуля Gradle влияют на вас
Метаданные модуля Gradle 1.0 обеспечивают детальное разрешение зависимостей для всех пользователей Gradle. Начиная с Gradle 5.3, если вы являетесь потребителем и в используемой вами библиотеке опубликованы метаданные Gradle, Gradle автоматически использует любые метаданные Gradle, опубликованные в репозиториях Maven или Ivy.
Однако Gradle 5.3 не будет опубликовать его автоматически по умолчанию — это произойдет в версии 6.0. Вы можете опубликовать метаданные модуля Gradle уже сегодня, но вы должны согласиться на его публикацию, используя плагины Maven Publish или Ivy Publish и включив функцию экспериментальной публикации, добавив следующую строку в сценарий настроек:
settings.gradle(.kts)
Как метаданные модуля Gradle влияют на сборки Maven или Ant+Ivy?
Ничего не меняется для потребителей Maven и Ivy: если вы выбрали публикацию метаданных модуля Gradle, соответствующий файл публикуется вместе с файлом POM (если вы публикуете в репозиторий Maven) или файлом Ivy (если вы публикуете в репозиторий Ivy). Имейте в виду, что сопоставление компонента сборки с метаданными Maven и Ivy с потерями: например, вы не знаете, какая версия Java использовалась для сборки чего-либо, поэтому потребители не могут узнать, они совместимы или нет заранее. Другой пример — когда вы используете определенные функции Gradle, такие как расширенные версии. Мы делаем все возможное, чтобы сопоставить их с концепциями в Maven или Ivy, но информация все равно будет потеряна в процессе из-за ограничений их форматов метаданных.
Обратите внимание, что в Gradle 5.2 добавлены предупреждения, выдаваемые подключаемыми модулями публикации, когда он знает, что сопоставление связано с потерями или проблематично для других инструментов сборки.
Ссылки и отсылки
Метаданные модуля Gradle – это файл JSON с расширением .module . Каждый файл описывает один программный компонент с нулем или более вариантами. Вот содержимое примера файла метаданных для компонента «com.acme:client:1.0-SNAPSHOT» в нескольких вариантах:
В этом файле объявлено 4 варианта, а атрибуты сообщают средству сборки, для чего они используются. В частности, здесь вы увидите, что есть 2 варианта для «API» и 2 варианта для «среды выполнения», тогда как обычно вы видите только по одному для каждого. Причина в том, что этот конкретный компонент объявляет дополнительный вариант, в котором зависимости затенены (толстая банка). Это дает потребителю возможность решить, нужны ли ему зависимости в виде отдельных jar-файлов или просто вариант библиотеки fatjar.
Если вас интересуют дополнительные технические подробности, обратитесь к спецификации метаданных модуля Gradle 1.0
Читайте также: