Android Broadcast
14.5K subscribers
3.83K photos
397 videos
11 files
6.3K links
Подборка новостей и статей для Android разработчиков.

Реклама и связь с автором @ab_manager

РКН https://abdev.by/rkn_tg_ab #MQRZR
Download Telegram
🤖 Готовьтесь к 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🤖 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Android Broadcast
🔥 В Dagger 2.59 добавили поддержку AGP 9.0. Одним блокером для миграции на AGP 9.0 стало меньше #Android #Gradle
🤖 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🏝 Когда стоит убить 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🤖 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🤖 Улучшения 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔨 Вышла 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🐱 Выложил свои наработки для использования с AI Агентами на GitHub

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

#AI #Gradle #ClaudeCode #Безопаность #Maven
Please open Telegram to view this post
VIEW IN TELEGRAM
🤖 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
🔨 Вышел 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🐘 В мире 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🐘 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🐘 Два 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
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
🐘 Вышел Gradle 9.7. Ключевое изменение новое релиза Gradle - Isolated Project перешли из экспериментального статуса в incubating. Это значит что фича уже готова к тестированию и следующий этап - релиз.

Isolated Project - большой шаг в том чтобы повысить параллельность сборки, лучшую работу с конфиг кэшем и ускорение сборки проекта!

Фича выключена по умолчанию, для включения надо добавить флаг:
# Файл gradle.properties в корне проекта
org.gradle.isolated-projects=true

⚠️ Ваш сборка и плагины, подключенные в проект, должны поддерживать Isolated Project

🔗 Подробнее про Isolated Project

#Gradle
Please open Telegram to view this post
VIEW IN TELEGRAM
В Gradle 9.7.0 официально вывели Isolated Projects из экспериментального статуса в incubating. Для Android-разработчиков, особенно тех, кто живёт в больших мультимодульных проектах или монорепах, это одна из самых заметных новостей последних релизов.

Суть простая и одновременно радикальная. Раньше конфигурация проектов в Gradle шла последовательно: один модуль за другим, и каждый мог свободно лезть в состояние соседей. В больших сборках (тысячи модулей) это превращалось в минуты ожидания просто на этапе конфигурации — и при синхронизации Android Studio, и при обычном ./gradlew. Isolated Projects вводит жёсткие границы: во время конфигурации проект больше не может трогать изменяемое состояние другого проекта, например добавить зависимость или сделать конфигурацию плагина. Благодаря этому Gradle наконец-то может конфигурировать модули параллельно, используя все доступные ресурсы компьютера.

Цифры из блога Gradle довольно красноречивые. На собственном 300-модульном билде Gradle медианный IDE-sync ускорился с 84 до 47 секунд. На Android-монорепе больше чем с 5000 проектов синхронизация Android Studio упала с 5 минут 9 секунд до 2 минут 44 секунд (почти в два раза). Репозиторий AndroidX тоже показал ощутимый выигрыш. Причём это только начало: изоляция открывает дорогу к выборочной конфигурации (конфигурировать только те проекты, которые реально нужны для текущей задачи) и к более тонкому кэшированию результатов конфигурации.

Интересно, что такой подход уже давно является нормой в других системах сборки. Bazel и Buck изначально проектировались вокруг изоляции: пакеты/таргеты максимально независимы, конфигурация декларативная, параллелизм — естественное следствие. Gradle исторически шёл другим путём — максимальная гибкость и возможность писать почти любой императивный код в build-скриптах, что в итоге сыграло против него. Isolated Projects — это попытка взять лучшее из обоих миров: сохранить привычную модель Gradle, но добавить те самые границы, которые позволяют масштабироваться.

Адаптация проекта для Isolated Project

Чтобы адаптировать свой проект сначала нужно, чтобы сборка уже нормально работала с Configuration Cache, Isolated Projects строится поверх него строится. Дальше в gradle.properties добавляете:

org.gradle.isolated-projects=true


После включения Gradle начнёт падать на любом нарушении изоляции (если не станет - вы мастер конфигурации). Чаще всего это:
- доступ к изменяемому состоянию другого проекта (rootProject.version, project(":other").tasks и т.п.);
- использование allprojects / subprojects с мутациями;
- плагины, которые регистрируют задачи или расширения «через границу» проекта.

Исправляется это в основном переносом общей логики в convention плагины, использованием project.isolated для безопасного чтения данных и lifecycle-колбэками из settings. Есть diagnostics-режим, который помогает найти все нарушения, и даже «dangerously ignore problems», если хочется сначала просто замерить прирост производительности.

Команда Gradle плотно работала с Google и JetBrains, поэтому Android Gradle Plugin и Kotlin Gradle Plugin уже поддерживают изоляцию (на свежих версиях). KSP тоже умеет — нужно только включить ksp.project.isolation.enabled=true. Официальный пример Now in Android уже приведён в совместимое состояние.

С комьюнити-плагинами ситуация разношёрстная. Многие уже адаптированы (Apollo, Wire, Firebase Crashlytics/Perf, Dependency Analysis и другие). Некоторые всё ещё ломаются или требуют костылей: Spotless часто приходится условно отключать, Gradle Doctor, SKIE и часть Kotlin Multiplatform (особенно WASM/JS) пока в красной зоне. Если ваш плагин падает, то лучшее, что можно сделать, это создать issues или найти уже открытое. Актуальный статус поддержки Isolated Project в Gradle плагинами есть на сайте (спасибо Никите К. за ссылку)?

Станет ли это обязательным? В ближайшее время нет. Фича incubating, по умолчанию выключена и официально не рекомендуется для продакшен-артефактов. Gradle явно говорит, что собирается стабилизировать Isolated Projects и в конечном итоге сделать их режимом по умолчанию, но конкретных сроков нет. На мой взгляд, раньше выхода Gradle 11 это не состоится, потому что очень много правок надо сделать по всей экосистеме Gradle. Пока это инструмент для тех, кто готов инвестировать время в миграцию ради заметно более быстрой синхронизации и конфигурации.

Если у вас большой Android-проект и синхронизация уже начала раздражать — имеет смысл попробовать. Даже если прямо сейчас не всё идеально, направление понятно: Gradle медленно, но верно уходит от «всё можно менять отовсюду» к модели, в которой проекты действительно изолированы. А это именно то, что нужно монорепам и большим мультимодульным сборкам.

#Gradle
🤯 И ты, Gradle, ударился в AI

Gradle запустил инициативу Agentic Gradle. Цель — сделать сборку понятной не только человеку, но и кодинг агентам.

Что внутри:
👉 официальные skills (инструкции в духе Claude Skills) — как читать ошибки, запускать таски, разбирать Build Scan. Skills обещают в ближайшие недели (после бенчмарков).
👉 бенчмарки, которые измеряют реальный эффект skills;
👉 убирание лишнего текста, чтобы не жечь токены зря.

Ценой стал сдвиг Configuration Cache с Gradle 10 на 11.

Сам кэш уже стабильный — включай руками:
org.gradle.configuration-cache=true


Самое показательное даже не skills. Билд-система — штука, которая вроде бы должна стоять чуть в стороне от хайпа. И вот Gradle тоже идёт в agentic. Потому что пользователи уже этого хотят, потому что открываются новые способы продвижения, потому что инвесторам это нужно показывать. Даже серьёзные инструменты сейчас вынуждены "кланяться".

🔗 Источник - блог Gradle

#Gradle #AI
// Пример форсирования структуры проекта через Aalekh
// build.gradle.kts (root project)
aalekh {
layers {
layer("domain") { modules(":core:domain", ":feature:*:domain") }
layer("data") {
modules(":core:data", ":feature:*:data")
canOnlyDependOn("domain")
}
layer("presentation") {
modules(":feature:*:ui", ":app")
canOnlyDependOn("domain", "data")
}
}
}


#Gradle
Media is too big
VIEW IN TELEGRAM
🐱 Визуализация многомодульного Gradle проекта и форсирование правил - Aalekh. Подключается как Gradle плагин.

#Gradle
Please open Telegram to view this post
VIEW IN TELEGRAM