API 'android.registerTransform' is obsolete.

[po1xiao]

API 'android.registerTransform' is obsolete.
It will be removed in version 8.0 of the Android Gradle plugin.
The Transform API is removed to improve build performance. Projects that use the
Transform API force the Android Gradle plugin to use a less optimized flow for the
build that can result in large regressions in build times. It’s also difficult to
use the Transform API and combine it with other Gradle features; the replacement
APIs aim to make it easier to extend the build without introducing performance or
correctness issues.

There is no single replacement for the Transform API—there are new, targeted
APIs for each use case. All the replacement APIs are in the
androidComponents {} block.

The Transform API uses incremental APIs deprecated since Gradle 7.5. Please add
android.experimental.legacyTransform.forceNonIncremental=true to
gradle.properties to fix this issue. Note that this will run transforms
non-incrementally and may have a build performance impact.
For more information, see https://developer.android.com/studio/releases/gradle-plugin-api-updates#transform-api.
To determine what is calling android.registerTransform, use -Pandroid.debug.obsoleteApi=true on the command line to display more information.

编译的的时候总会报一个警告，昨天androidStudio升级了Electric Eel | 2022.1.1，AGP已经7.4了，看了一下官方的计划，感觉离8.0不远了，而且就像提示说的，Transform的确对编译速度会有影响，请问针对AGP8.0有什么适配计划吗？
不升级AGP版本是一个选项，说如要升级AGP到8.0还能继续使用aspectjx吗？

[wurensen]

@po1xiao 估计废弃掉transform之后，新机制没法用aspectj了。

[po1xiao]

@po1xiao 估计废弃掉transform之后，新机制没法用aspectj了。

那就太可惜了

[jiqianwen]

还有替代方案吗。。。。

[wurensen]

@jiqianwen 可以直接基于AGP自带依赖的ASM字节码操作框架。

[Heart-Beats]

AGP8.0 目前已经发布了，大佬有时间可以考虑适配一下

[wurensen]

大家可以看下有什么新的替代api方式，我空了的时候去看看。

[jiqianwen]

大家可以看下有什么新的替代api方式，我空了的时候去看看。

jadepeakpoet/ARouter#7
阿里路由这个也因为AGP8.0 Transform被干掉了不能用了，看issue说是在做迁移，不知道怎么个迁移法

[wurensen]

@jiqianwen 主要是aspectj的机制会产生新的类，导致不好迁移；如果类似于只用ASM这样的工具，只修改当前类的字节码，那很好修改。AGP直接内嵌了ASM，提供了接口，可以很方便的处理。

[jadepeakpoet]

使用TransformAction应该可以解决这个问题(可以向outputs目标内写入新文件)
https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.transform.TransformAction.html

或者可以看看另一个路由库适配agp8.0的办法(自定义了一个Task来代替原先的Transform,核心还是处理输入与数据jar)
https://github.com/HuolalaTech/hll-wp-therouter-android/blob/feature/apg8/plugin-agp8/src/main/groovy/com/therouter/plugin/TheRouterPlugin.groovy

https://github.com/HuolalaTech/hll-wp-therouter-android/blob/feature/apg8/plugin-agp8/src/main/groovy/com/therouter/plugin/agp8/TheRouterGetAllClassesTask.groovy

[wurensen]

@jadepeakpoet 之前有草查了一下，也是看到这两种方式，等空了我仔细看看。

[KnightAndroid]

可以尽快适配Gradle8.0版本么，Transform已经被标记为废弃了，在AGP8.0中移除了，取而代之就是TransformAction

[gnmmdk]

可以尽快适配Gradle8.0版本么,目前应用市场（小米/VIVO）要求适配Android14，而14又必须使用Gradle8.0

[gnmmdk]

是否可以用javassist替换aspectj

[wurensen]

初步估计得9月底才有空。

[gnmmdk]

大兄弟有开始准备适配了吗？🌹

[wangpei72]

10月中啦！！！！！！求最新适配版本！！

[wurensen]

最近公司业务比较忙，都在加班搞，有没有兄弟有空，可以主导一下这个适配。

[gnmmdk]

有没有其他替代的这个库的方案？

[KnightAndroid]

最近公司业务比较忙，都在加班搞，有没有兄弟有空，可以主导一下这个适配。

主要是首先要熟悉库的逻辑，才好改，其次改完之后要全面测试，都需要花费大量时间

[gamedragon]

学习了一下ASM和aspectj的流程，这两个虽然最终原理都是一样，但是不是一个路数，感觉不是简单改动就能适配的了的

[FlyJingFish]

本人开发了一个不用AspectJ的aop框架，当然也同样支持AGP8AndroidAOP，一般来说相对 Android 的使用还是不错的，相对 AspectJ 更轻量

[wurensen]

本人开发了一个不用AspectJ的aop框架，当然也同样支持AGP8AndroidAOP，一般来说相对 Android 的使用还是不错的，相对 AspectJ 更轻量

@FlyJingFish 大概看了一下，你这边应该是用了apt的方式。apt不一定适用于大部分人的场景，因为要使用aop就是很多时候想织入的代码是字节码文件，而apt是编译期的方案，没法修改第三方代码。

[FlyJingFish]

本人开发了一个不用AspectJ的aop框架，当然也同样支持AGP8 AndroidAOP，一般来说相对Android的使用还是不错的，相对AspectJ更轻量

@FlyJingFish大概看一下这篇文章，你的文章应该是用了 apt 的方式。apt 不一定适用于大多数人的场景，因为要使用 aop 就是很多时候想织入的代码是字节码文件，而 apt 是编译期的方案，修改不了第三方代码。

你看错了，就是基于修改字节码实现的，apt只是自定义Aop会用到，已有的Aop包括自定义Aop最后都会通过修改字节码文件织入代码

[Cazaea]

已经年底了，大佬有考虑适配8.0吗？

[KnightAndroid]

大佬，是否有考虑进行8.0的适配计划？