📹 Gradle выложили мини курс по переиспользованию build логики между Gradle модулями (EN, 6 уроков, 30 минут)

00:00 - Папка buildSrc
02:06 - Convention Plugin
09:29 - Version Catalog
15:58 - Общие Task
19:09 - Производительность buildSrc
23:32 - included build

#gradle

🐘 Вышел Gradle 9.1.0 с поддержкой Java 25 и новыми фичами. Из интересно - "Визуалиация таска графов", но сразу грусть - не ждите картинки 😡 Насыпали везде по немного улучшений, запромоутили фичи в стабильные, поправили баги и на этом всё.

#gradle

⚠️ Работа с зависимостями в Gradle таит множество подводных камней:
- Откуда берётся зависимость?
- Какие транзитивные зависимости подтянутся вместе с ней?
- Как убедиться, что скачался именно тот артефакт, который вы ожидали?

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

1️⃣ Используйте единый источник зависимостей

В больших компаниях принято разворачивать свой Nexus / Artifactory. Он проксирует остальные репозитории (MavenCentral, Google и др.), и для проекта остаётся один источник правды.

Это ускоряет сборку (репозиторий ближе и быстрее), а также защищает от случайного скачивания библиотек «из непонятного интернета».

2️⃣ Ограничивайте содержимое репозиториев

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

Например, для Google Maven:

// settings.gradle.kts
dependencyResolutionManagement {
    repositories {
        google {
            mavenContent {
                includeGroupAndSubgroups("androidx")
                includeGroupAndSubgroups("com.android")
                includeGroupAndSubgroups("com.google")
                includeGroupAndSubgroups("org.chromium.net")
                includeGroupAndSubgroups("com.crashlytics.sdk")
            }
        }
        mavenCentral()
    }
}

Так вы избежите ненужных запросов в «левые» репозитории.

3️⃣ Проверяйте скачанные артефакты

Gradle поддерживает dependency verification. Это позволяет проверить контрольные суммы загружаемых артефактов и защититься от подмены.

📖 Документация: Dependency Verification

Пример gradle/verification-metadata.xml:

<verification-metadata>
   <configuration>
      <verify-metadata>true</verify-metadata>
      <verify-signatures>false</verify-signatures>
   </configuration>
    
   <components>
      <component group="org.apache.pdfbox" name="pdfbox" version="2.0.17">
         <artifact name="pdfbox-2.0.17.jar">
            <sha512 value="..." />
         </artifact>
      </component>
   </components>
</verification-metadata>

4️⃣ Ограничивайте транзитивные зависимости

Любая библиотека подтягивает за собой десятки других. Чтобы не получить неожиданное поведение или небезопасные версии — используйте constraints:

dependencies {
    implementation("org.apache.httpcomponents:httpclient")

    constraints {
        implementation("org.apache.httpcomponents:httpclient:4.5.3") {
            because("previous versions have a critical bug")
        }
        implementation("commons-codec:commons-codec:1.11") {
            because("version 1.9 pulled from httpclient has issues")
        }
    }
}

А если нужно зафиксировать версии жёстко:

configurations.all {
    resolutionStrategy {
        force("org.example:lib:1.2.3")
        // Есть много других возможностей
    }
}

5️⃣ Анализируйте дерево зависимостей

Чтобы понять, кто и что тянет, используйте:

./gradlew dependencies
./gradlew dependencyInsight --dependency okhttp --configuration releaseRuntimeClasspath

Это поможет отловить дубликаты и неожиданные версии.


6️⃣ Автоматизируйте обновления

Поддерживайте проект в актуальном состоянии:
🔄 используйте Gradle Versions Plugin, чтобы проверять обновления библиотек.
📝 заведите политику обновлений (например, обновлять минорные версии раз в месяц, а мажорные — отдельно и осознанно).

🔥 В итоге, хорошая стратегия работы с зависимостями — это баланс между удобством разработки и контролем. Чем больше проект и команда, тем жёстче стоит соблюдать правила.

#gradle #лучшиепрактики

🚀 Чтобы ускорить работу с Gradle рекомендую всем включить в настройках IDE параллельную работу синхронизации IDEA и Gradle проекта.

🐘 Что даёт включение «parallel fetching»

По умолчанию Gradle получает модели последовательно — по одному модулю за раз.
С включённой опцией IDE может запрашивать модели параллельно для нескольких модулей, что:
👉 ускоряет синхронизацию крупных многомодульных проектов;
👉 сокращает время обновления проекта после изменения Gradel build-файлов;
👉 лучше использует возможности CPU

#gradle #androidstudio #idea

🪙 Разрабатываю Gradle плагин для Swift кода в Android сборке (2 ч)

Не так давно разобрал как работает Swift для Android, но там совсем "на скорую руку" сделали интеграцию с Gradle билд системой.

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

Если у вас есть проблемы с Boosty - пишите @ab_manager

#AndroidBroadcast #Gradle #Swift #AndroidDev

🤖 Готовьтесь к Android Gradle Plugin 9.0 — грядут большие перемены!

Совсем скоро состоится релиз Android Gradle Plugin 9.0 (AGP), который полностью меняет подход к конфигурации Android‑проектов: удаляет устаревшие API, упрощает настройку и пересматривает организацию конфигурации.

Ключевые изменения:
👉 Переход на Gradle 9.X
👉 Поддержка Kotlin теперь встроена в AGP — подключение org.jetbrains.kotlin.android больше не требуется и даже будет рушить сборку. Из плюсов — минус один плагин.
👉 Плагин org.jetbrains.kotlin.multiplatform больше не будет работать с com.android.library и com.android.application. Используйте com.android.kotlin.multiplatform.library, а для приложения создавайте отдельный модуль.
👉 Массовые изменения в API — множество удалений без прямых альтернатив. В целом идёт отказ от старых публичных интерфейсов, ведь новые уже давно доступны, и авторы плагинов могут их использовать.
👉 Некоторые возможности конфигурации теперь будут доступны только в библиотечном плагине.

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

Подробнее обо всех изменениях — в документации

Надеюсь, Android Studio добавит ассистента по миграции. А вот авторам плагинов, похоже, прибавится работы 😅

Как вам перемены? Пойдут ли они на пользу скорости сборки и удобству использования AGP?

#Android #AndroidDev #Gradle #AGP #AndroidStudio

🤖 AGP 9.0: Fused Library Plugin — новый способ публикации нескольких модулей как один AAR

В Android Gradle Plugin (AGP) 9.0 и новее появился инструмент, которого ждали многие разработчики SDK и библиотек. Встречайте плагин Fused Library (com.android.fused-library). Пока в экспериментальном режиме.

Раньше, если вы разбивали свой код на много модулей, перед вами вставала дилемма: заставлять пользователя подключать 5 разных зависимостей или использовать неофициальные "fat-aar" скрипты. Теперь Google предлагает нативное решение.

Fused Library плагин позволяет взять несколько Android Library модулей и упаковать их в один AAR [1].

1️⃣ Для включения фичи надо будет добавить флаг в gradle.properties:

android.experimental.fusedLibrarySupport=true

2️⃣ Затем создаем модуль для публикации (например, my-sdk-fused). В его build.gradle.kts добавляем:

plugins {
    id("com.android.fused-library")
    `maven-publish`
}

androidFusedLibrary {
    namespace = "dev.androidbroadcast.mysdk"
    minSdk = 23
}

dependencies {
    // Указываем модули для "слияния"
    include(project(":core"))
    include(project(":ui-components"))
    // Можно вливать даже внешние либы!
    include("dev.androidbroadcast:cool-fonts:1.0")
}

Обратите внимание на include — это ключевая команда для упаковки.

3️⃣ Используем компонент fusedLibraryComponent при публикации артефакта:

publishing {
    publications {
        register<MavenPublication>("release") {
            groupId = "dev.androidbroadcast"
            artifactId = "fat-sdk"
            version = "1.0.0"
            from(components["fusedLibraryComponent"])
        }
    }
}

Инструмент мощный, но есть особенности:
❌ Data Binding не поддерживается.
⚠️ Ресурсы: При совпадении имен побеждает ресурс из зависимости, указанной первой.
⚠️ Build Types: Нельзя слить debug и release в один проход, нужны разные fused-модули.
🐞 Source JAR: Пока есть известные проблемы с генерацией исходников.

Подробнее читайте в [документации](https://developer.android.com/build/publish-library/fused-library)

#Android #AndroidDev #Gradle #AGP #Maven

🤯 Dagger Hilt блокирует переход на AGP 9.0

UPD. 21 января вышел Dagger 2.59 с поддержкой AGP

Android Gradle Plugin 9.0 официально зафиксировал новый стабильный конфигурационный API (вышла стабильная версия с релизом AS Otter FD 3) — это одно из самых значимых изменений в инфраструктуре Android и Kotlin Multiplatform за последние годы. Цели понятны и правильные лучше работа с кэшем и общая скорость сборок. Подробнее про все изменения я писал в отдельном посте

Google несколько релизов подряд аккуратно готовил экосистему к этому переходу, заранее добавив новый API и дав время авторам плагинов адаптироваться. Но на практике всё упирается в плагины.

Я столкнулся с тем, что Gradle-плагин Dagger Hilt до сих пор использует старую модель конфигурации и несовместим с новым DSL из AGP 9.0. В результате проект нельзя перевести на новую версию без отключения Hilt или включения режим совместимости. Иронично, что именно официальный инструмент от Google сейчас становится блокером для обновления.

Да, в AGP оставили compatibility-флаги, позволяющие продолжать сборку по старым правилам. Это спасает проекты от немедленного падения, но полностью отключает все ключевые преимущества AGP 9.0 — configuration cache, ускоренную конфигурацию и новую модель плагинов.

💬 Вы уже пробовали миграцию на AGP 9.0? Что блокирует? Делитесь в комментариях мнением.

UPD. По заявлениям подписчиков также есть проблемы в работе KAPT и KSP

#Android #AndroidDev #Gradle #Dagger #Hilt

🤖 Baseline Profile Gradle Plugin не поддерживает AGP 9.0, но есть способ поправить

Сразу после выхода Dagger с поддержкой AGP стал пробовать миграцию на AGP 9.0. Блокером послужил baselineprofile Gradle plugin. Текущая его стабильная версия 1.4.1 не поддерживает новый DSL, но зато альфа версия 1.5.0-alpha01 (вышла 17 декабря 2025) уже работает.

Учитывая, что это не влияет на код в рантайте, то я бы обновился в проде.

#Android #Gradle

🏝 Когда стоит убить Kotlin демона для ускорения сборки

Если у вас тяжёлая Android-сборка (много модулей, R8, CI с ограниченной памятью), имеет смысл принудительно завершать Kotlin Daemon после компиляции и до запуска R8 🔪

Kotlin Daemon нужен только на этапе компиляции Kotlin. После этого он спокойно живёт до конца сборки и держит память. R8 — один из самых прожорливых этапов по CPU и RAM 🔥 По итогу Daemon и R8 начинают конкурировать за ресурсы памяти

Что вы реально получаете если убивает Kotlin демона после компиляции кода:
🚀 снижение пикового потребления памяти примерно на 13–15%
🚀 ускорение R8 вплоть до ~7%
🚀 небольшое, но стабильное сокращение общего времени сборки
🚀 максимальный эффект на CI, где нет долгоживущих демонов и инкрементальности

‼️ Этот подход сработал для автора статьи, но для вас может ничем и не помочь, особенно в сборке на локальной машине.

🔗 Источник с измерениями и подробным разбором

#Android #Kotlin #R8 #Gradle

🤖 Android Gradle Plugin 9 упрощает запуск unit-тестов

По умолчанию Android Gradle Plugin создаёт Gradle-задачи для запуска unit-тестов во всех доступных build types, что на практике почти никогда не нужно. Обычно тесты запускаются только для debug-сборки.

В реальных проектах (особенно с product flavors и большим количеством модулей) это приводит к сотням лишних задач, увеличению времени конфигурации и дополнительной нагрузке на IDE и CI.

Чтобы оптимизировать работу Gradle, начиная с AGP 9.0, можно в gradle.properties добавить:

android.onlyEnableUnitTestForTheTestedBuildType=true

После этого unit-тесты будут генерироваться только для основного тестируемого build type (как правило, debug). Это:
👉 убирает лишние Gradle-задачи;
👉 сокращает время конфигурации проекта;
👉 снижает потребление памяти;
👉 ускоряет локальную разработку и CI-пайплайны.

Если вы не запускаете unit-тесты для release-сборок (а так делают почти все), то включение этого флага — бесплатная оптимизация сборочной инфраструктуры.

Это хороший пример того, как дефолтные настройки инструментов ориентированы на универсальность, а не на эффективность, и почему их стоит регулярно пересматривать в контексте реальной архитектуры проекта.

#Android #AndroidDev #Gradle

🤖 Улучшения R8 - минификатора кода в Android

В AGP 9.0 R8 получил несколько изменений, в основном направленных на оптимизацию Kotlin-кода, упрощение desugaring-пайплайна и улучшение диагностики.

Основные изменения:

👉 Новая опция -processkotlinnullchecks для обработки null-проверок, сгенерированных компилятором Kotlin. Можно задать одно из значений:
- keep - оставить проверки;
- remove_message - убрать сообщения об ошибках;
- remove - полностью удалить проверки.

Опция используется для уменьшения байткода и снижения runtime-накладных расходов в production. Я еще в 2019 писал статью про это и удалял код с помощью -assumenosideeffects

👉 Keep rules больше не применяются к companion methods
R8 перестал переносить keep-информацию на синтетические companion-методы, сгенерированные при desugaring интерфейсов.
Это ломает редкий кейс с minSdk < 24, но делает поведение более консистентным с остальными синтетическими элементами.

👉 Минимизированные имена синтетических классов в L8
L8 теперь генерирует более короткие имена для synthetic-классов ($1, $2 вместо длинных $$ExternalSynthetic...), что уменьшает размер DEX.

L8 — это утилита, стоящая за library desugaring в Android. Позволяет использовать новые API на старых версиях Android и править баги в них, делая использование API прозрачным.

AGP 9.0 прокачало R8 и L8, чтобы делать меньше лишнего байткода, более агрессивно оптимизировать Kotlin. Большинство изменений работают прозрачно, но в сумме дают более компактные сборки и более предсказуемый build-процесс.

🔗 Источник - документация по AGP 9.0

#Android #AndroiDev #Gradle #R8

🔨 Вышла Android Studio Panda 1 и там только одно существенное изменение — упрощённое управление JDK для Gradle через Gradle Daemon JVM Criteria.

Теперь в новых проектах студия по умолчанию использует критерии JVM для Gradle Daemon: Gradle сам находит совместимый JDK, установленный на машине, а если подходящего нет — включает auto-provisioning и скачивает нужный JDK. Фича стабилизирована в Gradle 9.2.0.

Что это даёт разработчику:

✅ Меньше ошибок на импорте и старте проекта. Больше не нужно вручную угадывать “правильный” JDK для конкретного проекта — меньше типичных проблем вида Unsupported class file major version и прочих сюрпризов из-за неверно выбранной Java.

✅ Консистентные сборки в IDE и в терминале. Раньше Studio могла собирать проект на одном JDK, а CLI — на другом. В итоге появлялись разные Gradle Daemon, падала предсказуемость и иногда производительность. С JVM Criteria выбор JDK становится единым — поведение сборки стабильнее.

Для существующих проектов (при совместимой версии Gradle) Android Studio покажет уведомление и предложит автоматически мигрировать текущую настройку Gradle JDK на Daemon JVM criteria, сохранив те же требования к JDK.

💡 Для работы требуется Gradle 9.2 или выше, ну и придется мигрировать на AGP 9.0

#AndroidStudio #Gradle

🐱 Выложил свои наработки для использования с AI Агентами на GitHub

Репозиторий включает магазин для Claude Code и несколько инстурметов
👉 maven-mcp умеет получать информацию о свежих версиях зависимостях, дать дифф изменений, проверь, какие обновления вам нужны
👉 sensitive-guard - добавляет хуки, чтобы проверить файлы на чувствительные данные перед тем, как агент попытается обратиться к ним. Работает на основе gitleaks.

#AI #Gradle #ClaudeCode #Безопаность #Maven

🤖 androidx.lint — это Jetpack-библиотека с набором lint-проверок специально для авторов Gradle-плагинов.

Если ты пишешь Gradle plugin для Android — она ловит ошибки, которые сложно заметить вручную:
👉 использование внутренних API Gradle и AGP (которые могут сломаться в любой момент)
👉 eager task configuration вместо lazy (withType без configureEach)
👉 вызовы, несовместимые с Gradle Project Isolation (getRootProject, findProject, getParent)
👉 Provider<String>.toString() — почти всегда баг
👉 configurations.create вместо configurations.register (проблема с Gradle 8.14+)
👉 System.getenv() напрямую вместо Provider API
👉 mustRunAfter / shouldRunAfter — дорогие операции из-за перестройки task graph

Сейчас в alpha06 (апрель 2026), стабильного релиза ещё нет, но и в прод этот код не пойдет.

#Gradle #Android

🔨 Вышел AGP 9.2.0 с одной экспериментальной фичей и набором фиксов.

Главное новшество — unified coverage and test reports. Плагин теперь умеет генерировать HTML-дашборд, который объединяет результаты unit и instrumentation тестов по всем модулям и вариантам сборки в одном месте. Пока это эксперимент: нужно включить флаг android.experimental.reportAggregationSupport=true в gradle.properties.

🛠 Из фиксов стоит выделить несколько практически значимых: починили переименование APK через новый AGP DSL, исправили падение JdkImageTransform при использовании JDK 26, починили поведение Android Lint с флагом --quiet и сломанную работу кастомных lint-правил, скомпилированных под Java 21 bytecode.

Совместимость: Gradle 9.4.1, SDK Build Tools 36.0.0, JDK 17, максимальный API level 36.1.

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

#Android #AGP #Gradle

🐘 В мире Android и тем более KMP проектов огромное количество зависимостей. Та самая ситуация, когда build зеленый, sync прошел, но приложение падает в рантайме из-за NoSuchMethodError или ClassNotFoundException, знакома многим. Причина — тихий конфликт версий. Gradle по умолчанию старается брать самую новую версию из всех найденных, но срабатывает не всегда. В разных модулях одного проекта могут спокойно жить разные версии одной библиотеки (например, okhttp 4.9.0 в модуле А и 4.11.0 в модуле Б). Gradle не считает это конфликтом, потому что модули изолированы. В рантайме при передаче объекта между модулями — ClassCastException. Особенно больно это бьет в KMP, где общая бизнес-логика связывает всё в единую цепочку.

Плагин 🐱 Dependency Conflict Analyzer переворачивает подход. Он встраивается в Gradle и каждый раз при синхронизации автоматически анализирует весь граф зависимостей по всем модулям. Не нужно ничего запускать вручную или гадать, кто что подтянул. Если есть расхождение в major-версиях — плагин сразу покажет конфликт в консоли. Причём он найдет даже скрытые расхождения между разными модулями, которые Gradle игнорирует.

# Пример работы плагина
Version conflict detected: org.slf4j:slf4j-api
 - version 2.0.17 via:
   - project :app -> ch.qos.logback:logback-classic:1.4.11 -> org.slf4j:slf4j-api:2.0.17
   ...
 - version 1.7.25 via:
   - project :app -> org.apache.logging.log4j:log4j-slf4j-impl:2.17.1 -> org.slf4j:slf4j-api:1.7.25

Такая проактивная проверка помогает фиксить конфликты еще на этапе разработки и писать более стабильный код. Попробуйте.

#Gradle

🐘 Room тихо ломает ваш build cache

Команда прогнала свой браузер (открытый проект на 160 модулей) через открытые Develocity Build Validation Scripts. Скрипты гоняют сборку в разных условиях и показывают, какие задачи зря выполняются заново вместо того, чтобы взяться из кеша.

Главная находка про Room. Пути экспорта схем были заданы абсолютными, значит на каждой машине (ноутбук разработчика, CI-агент) получался свой input и свой ключ кеша. Любая сборка на другой машине била мимо. Лечится переходом на Room Gradle Plugin, который держит относительные пути. После фикса в эксперименте с разными путями на диске выполняемых задач стало 27 вместо 440.

😁 Вторая находка про Dagger. Либа генерила классы с непредсказуемым порядком методов: один и тот же исходник на двух CI-ранах давал побайтно разный вывод и промах по кешу. Апгрейд до Dagger 2.53+ с детерминированным выводом вернул в кеш 1619 задач. Опять же важность обновления до свежих версий.

Цифрами по статье манипулируют знатно. Заголовочные 57% относятся к лучшему локальному сценарию: сборке в git worktree после CI. Сквозной выигрыш по реальному CI скромнее, 19% на полном пайплайне с тестами и 39% на сборке debug APK. Инструментальные и Firebase-тесты не кешируются в принципе, поэтому потолок там ниже. Но даже из этого уже есть простые оптимизации, которые стоит проверить.

🔗 Источник - статья на Gradle блоге

#android #gradle #room #buildcache #dagger

🐘 Два Gradle-механизма для supply chain, которые почти никто не включает

В Android-проектах зависимости обновляются тихо: transitive upgrade пришёл, сборка не сломалась, никто не заметил.

Dependency Locking фиксирует resolved версии:

// build.gradle.kts
dependencyLocking {
    lockAllConfigurations()
}

Запускаешь ./gradlew dependencies --write-locks, Gradle создаёт .lockfile в gradle/dependency-locks/. После этого любое изменение версий требует явного --update-locks.

Dependency Verification проверяет подлинность артефактов:

# gradle.properties
org.gradle.dependency.verification=strict

Инициализация: ./gradlew --write-verification-metadata sha256. Создаёт gradle/verification-metadata.xml с checksums.

Оба файла идут в git. Локинг без верификации не защитит от подмены артефакта на CDN. Верификация без локинга не предотвратит silent upgrade. Работает только в паре. В большинстве Android-проектов ни одно из этого не включено, а полезно чтобы остановиться каскадные неявные обновления

#Gradle #Android #DevSecOps