AGP7.0 depends on the use of version management version catalogs

 

Table of contents

What are version catalogs?

Comparison of dependency management methods

specific usage

 Precautions

summary

---

• What are version catalogs?

        Version catalogs is a dependency version management method launched after AGP7.0.
        At this time, some friends will ask: Didn’t there be other ways of version management before, and they are also very easy to use, why use this?
        Ok, with this question in mind, let's make a comparison of the previously commonly used dependency management methods

• Comparison of dependency management methods

	ext	version catalogs
declaration domain	*.gradle	*.toml / stting.gradle
Is it modifiable	yes	no
wording	bells and whistles	Fixed wording xxx.xxx.xxx
check	none	Sync check

ext：

That is, it can be declared in each .gradle file. This declaration method will be fragmented, and if the same variable is defined later when defining the variable, the original variable will be overwritten (this problem is prone to occur during team development). It is also relatively casual, and each developer's writing style may be different, which will cause more confusion than dependency management, and there is no verification process at compile time or synchronization

version catalogs:
The declarations in this way are all written in the fixed file *.toml or sting.gradle, and there will be no duplication of variable names in ext that will cause the variables declared later to replace the variables defined earlier, and during synchronization Can do verification, which is conducive to the development of the team, and it is not easy to have dependency version conflicts under each module

• specific usage

version management type	type description	Definition example	Usage example app/build.gradle
library	arr, jar version management	library( 'core-ktx', 'androidx.core', 'core-ktx') .version('1.7.0')	api group name.core.ktx
bundle	Dependency aggregation management	bundle('androidx', ['core-ktx', 'constraintlayout', 'appcompat'] )	api group name.androidx
version	Version number constant management	version('compileSdk','33')	api group name.versions .compileSdk .get() .toInteger()
plugin	gradle plugin version management	plugin('hilt-android', 'com.google.dagger.hilt.android' ).version('2.41')	group name.plugins.hilt.android

Example in sting.gradle:

pluginManagement {
    ...
}
//1.启用Version Catalogs
enableFeaturePreview('VERSION_CATALOGS')
dependencyResolutionManagement {
    ...
    //2.在这里添加versionCatalogs
    versionCatalogs{
        //3.创建一个分组名称 这里起名androidxLibs
        create('androidxLibs'){
            //4.依赖管理分组定义
            //如：api'androidx.core:core-ktx:1.7.0' 
            //参数:(别名(自己看着取),group,artifact,version)    
            library('core-ktx','androidx.core','core-ktx').version('1.7.0')
            library('appcompat','androidx.appcompat','appcompat').version('1.6.1')
            //5.依赖聚合管理 即：将多个依赖进行合并，引用时只需要调用聚合管理分组即可
            //参数:(引用时的别名,[需要聚合的别名,需要聚合的别名])
            bundle('androidx',['core-ktx','appcompat'])
        }
        //可以创建多个分组
        create('googleLibs'){
            library('material','com.google.android.material','material').version('1.9.0')
        }

        /**
         * 6.版本号常量管理
         * 在app/build.gradle中
         * compileSdk buildsdk.versions.compileSdk.get().toInteger()
         */
        create('buildsdk'){
            version('compileSdk','33')
            version('minSdk','24')
            version('targetSdk','33')
        }
        
      /* 7.插件管理
       * 只需在app/build.gradle中alias(pluginLibs.plugins.hilt.android)即可
       * 对于没有发布到gradlePluginPortal的插件，暂时沿用老的模式，即buildScript { dependencies{  classpath 'xxx.xxx.xxx:1.0.0'}}
       */
       create('pluginLibs'){
          plugin('application','com.android.application').version('7.4.1')
       }
        //8.引用文件(在根目录当中创建libs.version.toml文件，示例代码在下面)
        //直接将四种类型的管理放到文件当中
        create("libs"){
            from(files("libs.version.toml"))
        }
    }
}

Create libs.version.toml in the root directory

ps: The writing method is basically fixed
. Example:
 

#版本管理
[versions]
compileSdk = '33'
minSdk = '24'
targetSdk = '33'

#插件管理
[plugins]
android-application = { id = "com.android.application", version = "7.4.1" }
android-library = { id = "com.android.library", version = "7.4.1" }

#依赖管理
[libraries]
core-ktx = { module = "androidx.core:core-ktx", version = "1.7.0" }
appcompat = { module = "androidx.appcompat:appcompat", version = "1.6.1" }
constraintlayout = { module = "androidx.constraintlayout:constraintlayout", version = "2.1.4" }

#依赖聚合
[bundles]
androidx = ["core-ktx", "appcompat", "constraintlayout"]

 example app/bundile.gradles:

plugins {
    //1.引用插件示例
    alias(pluginLibs.plugins.application)
}

android {
    namespace 'com.techme.jetpack_android_online'
    //2.版本管理引用示例:
    compileSdk buildsdk.versions.compileSdk.get().toInteger()
    defaultConfig {
        applicationId "com.techme.jetpack_android_online"
        minSdk buildsdk.versions.minSdk.get().toInteger()
        targetSdk buildsdk.versions.targetSdk.get().toInteger()
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

dependencies {
    //3.依赖管理引用示例
    implementation googleLibs.material
    //4.聚合依赖管理示例
    implementation androidxLibs.bundles.androidx
    //5.引用libs.version.toml文件示例
    implementation libs.constraintlayout
}

•  Precautions

After testing, if you use the form of *.toml file to quote time dependencies, it is not the same as others

Compare →

ps: libs is the group name

Dependency reference:

libs.constraintlayout
is: group name. alias

Other (aggregation, plugin, version):

Aggregation: group name.bundles.alias

Plugins: group name.plugins.alias

Version: group name.versions.alias

• Remark

This article is basically an explanation in vernacular, and it can also be said to be a personal study note. There are not so many technical terms. If there is something wrong, please correct me