There is no single replacement for the Transform API - android? - android

I recently updated my android studio to version -2021.2.1 Patch 2
My gradle distribution version is 7.3.3
When I build my project I get the following error
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.
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.
Affected Modules: core

For anyone stuck in this issue
Add this android.debug.obsoleteApi=true to your gradle.properties
This will help you identify which library is causing the issue.
In my case it was 3rd party library which caused this.

Related

How can I see dependency updates in build.gradle when using variables?

Android studio will show you if there is a newer version of a library when the version number is hard coded. But if you use variables, this seems to short circuit that functionality. Is there any way to get it back? I want to see available updates in build.gradle without having to Inspect the project.
Gradle 6 offers a new way to recommend and share versions between projects called platforms. This allows you to specify a set of dependency versions to share across projects without using variables.
You can use the Java Platform Plug-in to create a platform; a special kind of project that only contains a list of dependencies that work together. I haven't tried this, but hopefully Android studio will alert you if any of these versions are out of date since you'll be using hard coded version numbers.
You can then reference your platform in your other projects using the platform keyword and load all the other dependencies without versions
dependencies {
// get recommended versions from the platform project
api(platform(project(":platform")))
// no version required
api("commons-httpclient:commons-httpclient")
}

How to get library dependency version used in Gradle file from android Programmatically?

I'm currently stuck at one Problem regarding Gradle dependancy. I'm implementing application where I need to use various Third-party libraries to get work done & they are working great but currently situation is that I need their version numbers used in Gradle file.
I've found this question most closely related to my problem Is there a way to list all gradle dependencies programmatically?
But its printing dependency tree using Gradle task using Gradle console so, is there anyway we can get this using Android code?
Also I would like to explain my question in simpler terms , How can I get retrofit2 library version Programmatically ?

How do I use the standalone Jetifier to migrate to AndroidX?

The Jetifier tool is used as part of the AndroidX migration tool bundled with Android Studio. There is an issue with the tool, however, that is outlined here: https://issuetracker.google.com/issues/113224601.
The error message looks like this when running the Jetifier on certain libraries (one particular library keeps popping up for multiple users: org.eclipse.jdt.core):
Failed to transform '/path/to/library/org.eclipse.jdt.core-3.10.0.jar' using Jetifier.
Reason: The type does not support '.' as package separator!
This issue has been fixed for a while in the Jetifier tool itself, but the fixed version has not been included in any Android Studio updates yet (even the latest canary build).
I can confirm that running the standalone Jetifier works in transforming the problematic libraries, but I have no idea how to get these transformed libraries into our project. Off the top of my head, I can think of two different ways to get this migration to AndroidX to work:
Run the standalone tool on each library and instruct Gradle to use those versions (I might need to tell the Gradle tasks not to run the Jetifier on them)
Instruct the Gradle tasks to use the standalone tool in place of the one shipped with Android Studio.
Any help getting either of the above suggested fixes to work would be greatly appreciated (or if there is another way, I'd love to know about it). The internals of the Android Gradle build system are incredibly complicated, and I really need some gurus' assistance to get past this roadblock.
This is a serious road block for us since we want to begin the process of migrating our app in parallel with our development. There are a lot of things we need to iron out with this migration, and being ready to "flip the switch" when the tool is finally updated would help keep our releases on track.
Thanks!
Actually, from that same thread that I linked, there's a workaround:
Sorry jetifier beta01 was not binary compatible with alpha10.
Please try:
buildscript {
dependencies {
classpath 'com.android.tools.build.jetifier:jetifier-processor:1.0.0-beta02'
}
}
So, I guess now you can specify the newest version of the Jetifier in your buildscript.
I really should have scrolled all the way to the bottom of that thread before posting this, but now hopefully this workaround is more visible to people.
UPDATE
It seems this workaround does not work with DataBinding enabled. It looks like the new Jetifier tool is trying to run on the old version:
Failed to transform '/path/to/library/jetifier-core-1.0.0-alpha10.jar'
using Jetifier. Reason: The given artifact contains a string literal
with a package reference 'android/support/v4' that cannot be safely
rewritten. Libraries using reflection such as annotation processors
need to be updated manually to add support for androidx.
UPDATE 2 (20 Nov 2018):
There is a workaround to the issue of Jetifier trying to Jetify itself being released in AGP 3.3.0-rc01 and 3.4.0-alpha04. The devs are adding the ability to blacklist libraries from being Jetified. In your gradle.properties file, add a comma-separated list of Regular Expressions to match what files you don't want the Jetifier to touch. For example:
android.jetifier.blacklist = doNot.*\\.jar
Would exclude /path/to/doNotJetify.jar
I´m a bite late to the party, but I think there is only one fast option to solve that issue:
Go to Google Archives, Agree save and terms and download Android Studio 3.3 Beta 2 - this is the latest version before the problem occurs. You also have to downgrade your build.gradle to
classpath 'com.android.tools.build:gradle:3.3.0-beta02'
using gradle-4.10.2-all should be no problem.
Perhaps the problem will be fixed with the next beta or canary release, but for now this was the only option that worked out for me.

Whorlwind and RxJava2

I have a question regrading RxJava2 support in WhorlWind.
I am converting a project which uses Whorlwind from Rx1 -> Rx2. My current Whorlwind version in my root project gradle is 1.0.1, which according to their github CHANGELOG.MD is the only version.
https://github.com/square/whorlwind/commit/769ad313154df46ce07638dc79bd46ae14e5fbfb
As you can see, the commit above has made the changes to support rxjava2 however I am not able to find a version number to update in my gradle. There must be some key concept I'm missing because how I understand it, the Whorlwind library on my machine will remain at the RxJava1 build until I update the gradle to bring in some new Whorlwind library.
Thanks
I ran into the same issue with that library, what I did to move forward was to use the library the same way that the sample app that they have uses it. By adding the library to your project and referencing the library from there.
See their build.gradle here:
https://github.com/square/whorlwind/blob/master/whorlwind-sample/build.gradle
https://github.com/square/whorlwind/commit/47961437c611abc4ec88c900cdb6621ef6662b1c
In the gradle.properties, Square lists a snapshot of a newer version that supports Rx2. I'm not sure why they don't list it in the ChangeLog or ReadMe

Kotlin library 'classes.jar' has an unsupported format. Please update the library or the plugin

This message appears on project sync.
I've tried to clean and rebuild the project, but no success.
I'm using latest plugin version 0.12.275, "org.jetbrains.kotlin:kotlin-gradle-plugin:0.12.213" and "org.jetbrains.kotlin:kotlin-stdlib:0.12.213"
I've tried with the stable version 0.12.200 for both plugin and library, but I get the same error.
I'm using Android Studio AI-141.1972460 (canary channel).
Looks like the problem was in my *.aar lib, that was included in the project - it was compiled with an old version of Kotlin. I've upgraded the libary to the latest Kotlin version and it works now.
This issue was resolved with the updated library as mentioned by #ookami.kb
About the error message...
The "unsupported format" error comes when the ABI version number of the class files created by Kotlin does not match the expected used by the Kotlin compiler. This is no longer an issue with Kotlin 1.0 Betas since the ABI number will not change again for 1.0. But, there will be one forced recompile at 1.0 release candidate to ensure no old compiler bugs affect libraries or code and everything is rebuilt clean. Afterwards no issues such as this will exist.
Therefore if a library is not up to date with the same ABI, or hits this last "1.0 recompile" you may run into a similar error. The solution is always to find the updated library.
More about this in the Kotlin 1.0 Beta 4 announcement "What's Next" section:
After the Beta period is over, there will an RC and then 1.0.
We would really like to make sure that no code compiled with
pre-release versions of Kotlin are kept around after 1.0, so the RC
compiler will force recompilation of all the old code. We will
coordinate with library maintainers outside JetBrains to make sure
that all the widely-used libraries will be recompiled in time.
We’ll also take the opportunity to remove some legacy at this point:
remove all the deprecations that we have accumulated in the process of evolving our libraries,
remove all the deprecations from the generated code (you might not have heard of those, but they exist!),
get rid of some legacy bytecode peculiarities that were found during the beta,
move some of the stdlib code around so that the packages there have
more structure.
After that point, the only compatible changes to the
standard library are deprecations and additions (this does not include
reflection APIs). We are running an open review for the library API to
make sure we haven’t missed anything important.
This is Kotlin bug with new plugin version

Categories

Resources