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.
Related
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.
Android studio is getting slow in grade building process.I noticed this problem after updating to new version 3.5.Is there any ways to
speed up the building process?
1- Make sure you’re using the latest version of Gradle. Generally with every new update there is a significant improvement in performance.
Note: Java 1.8 is faster than 1.6. Make sure it’s updated too.
2- Try to minimize the use of modules. There are many cases where we need to fork the library to modify it to fit according to our needs. A module takes 4x greater time than a jar or aar dependency. This happens due to the fact that the module needs to be built from the scratch every time.
3- Enable gradle Offline Work from Preferences-> Build, Execution, Deployment-> Build Tools-> Gradle. This will not allow the gradle to access the network during build and force it to resolve the dependencies from the cache itself.
Note: This only works if all the dependencies are downloaded and
stored in the cache once. If you need to modify or add a new
dependency you’ll have to disable this option else the build would
fail.
4-Open up the gradle.properties file from the root of your project. Add the following lines of code in it.
org.gradle.daemon=true
Gradle daemon is a background process. Adding this would consume some extra memory while building.
org.gradle.parallel=true
The above line of code enables compilation of multiple modules at the same time. Besides that it also gives us other benefits such as;
Re-using the configuration for unchanged projects
Project-level is up-to-date checks
Using pre-built artifacts in the place of building dependent projects
Adding the following line of code also aids us in speeding up the build.
org.gradle.configureondemand=true
Another important property is;
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
The above line is used to allow Java compilers to have available memory up to 2 GB (2048 MB). It should only be used if you have available memory more than 2 GB.
This is how the gradle.properties file should look like:
5- Avoid dynamic dependencies such as
compile 'com.google.maps.android:android-maps-utils:0.4+'.
Dynamic Dependencies slow down your build since they keep searching for the latest builds every time. To improve the performance we need to fix the version in place.
6- Use only those dependencies that you need. For example google maps dependency, instead of importing , like :
implementation 'com.google.android.gms:play-services:17.0.0'
implementation 'com.google.android.gms:play-services-maps:17.0.0'
Gradle build speed depends on a lot of factors including the specification of your machine as well as your build type and android studio settings. You can check out this article on how to reduce your build time or go through the steps in the Android developer website.
Personal experience:
When I faced this issue, enabling offline mode drastically reduced my build time. The only problem is that I have to toggle this setting (on and off) every time I want to add a new dependency and this almost made me go berserk on several occasions. However, if properly handled, this helps a great deal.
I hope this helps. Merry coding!
you can set file->setting->search 'Gradle'-> check 'use local gradle distribution' and check 'offline work'.. in android studio. it will improve gradel building time.
Note: In newer version of Android studio, View->Tool Windows->Gradle->Toggle button of online/offline
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
I don't have much experiences with Android development and I have a doubt about the dependencies using Gradle. For example:
If I construct an Android app using Gradle dependecies and the package provider (for example picasso) remove the package from the repository, what will happens with my project? Will I lose the components? Or It makes a local copy of the binaries and my project will kept working normally?
Thanks a lot for help me to understand better how does it works.
You should keep a backup copy of the library you are installing as a dependency, but you shouldn't really worry about it ahead of the time that much.
It is quite rare, but it could get removed due to many reasons. There have been such instances in other cases where someone responsible for managing some package has just decided to remove it or alter it.
This does not just apply to Gradle but to any such dependency your application depends on, from any hosted package management solution. This same advice therefore applies to systems like NPM as well.
What you should ask yourself at some point in the development would be "Can I build this in 5 years again to fix a bug on a fresh machine with all the data I have and probably still have access to in 5 years?", because your local dependency cache might be long gone at that point anyways and the downloads for the library might be gone from the internet as well. It is a good practice to tuck them away somewhere in the same repository as the rest of the code, just in case.
Gradle downloads and caches all the dependencies when you perform Sync, you can see it at the bottom of your Android Studio.
If in the new version of library was deleted some packages, we have two options:
You update library version in your project and this package was removed for your project too
You use the old version of library and package still accessible from your project.
First, you should read that :
What is dependency management ?
The dependency cache
Short answer to your question : your project will still build unless your cache is cleared or if the dependency's version changes
But a package usually does not disappear from a repository (edit : as lu.koerfer underlined it in a comment, packages are not deleted from repository). If so, there might be a replacement package with a different name/group and you should update your dependencies to make it build properly again instead of relying on the cache.
If you will remove the dependency that you using, your project will still be able to use the library you willing to use.
until other dependency with same name / group will override your older dependency
You can read more about how gradle works, and how gradle manage his cache dependencies
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