Fixed
Status Update
Comments
to...@gmail.com <to...@gmail.com> #2
I don't think #1 makes a lot of sense. There are already potentially libraries out there without that metadata.
#2 makes the most sense to me, but in case we cannot be 100% reliable we should allow blacklisting libraries as described in #3. This should probably be handled globally for a project (in gradle.properpies rather than in the DSL)
#2 makes the most sense to me, but in case we cannot be 100% reliable we should allow blacklisting libraries as described in #3. This should probably be handled globally for a project (in gradle.properpies rather than in the DSL)
to...@gmail.com <to...@gmail.com> #3
As I have mentioned I don't think there is a silver bullet. #2 does not work on 100% and #1 will take time before devs will provide the metadata. #3 is in my opinion very important to introduce asap, as the developers have no way how to workaround it at this stage. Also in the future there can be any other issue and there is nothing wrong in doing #3 until we figure out something robust (or for instance finally migrate work manager and navigation to androidx that would make #2 a feasible solution).
ti...@google.com <ti...@google.com>
to...@gmail.com <to...@gmail.com> #4
Yes, I'm working on #3 right now to unblock users. We can continue thinking about #2.
to...@gmail.com <to...@gmail.com> #5
Starting with AGP 3.3.0-rc01 and 3.4.0-alpha04, to blacklist libraries that should not be jetified, users can add a comma-separated list of regular expressions to the following property in the gradle.properties file:
android.jetifier.blacklist = ...
If a library's absolute path contains a substring that matches one of the regular expressions, the library won't be jetified.
For example, if the property is
android.jetifier.blacklist = doNot.*\\.jar, foo
then "/path/to/doNotJetify.jar" won't be jetified.
Change-Id: I6531fe0faafa45dc2811c5223ba199ccce5fee53
Note that this is only a temporary workaround while we work on a proper solution.
android.jetifier.blacklist = ...
If a library's absolute path contains a substring that matches one of the regular expressions, the library won't be jetified.
For example, if the property is
android.jetifier.blacklist = doNot.*\\.jar, foo
then "/path/to/doNotJetify.jar" won't be jetified.
Change-Id: I6531fe0faafa45dc2811c5223ba199ccce5fee53
Note that this is only a temporary workaround while we work on a proper solution.
to...@gmail.com <to...@gmail.com> #6
Hi. I'm trying to use the `android.jetifier.blacklist` workaround to prevent jetify from processing lombok (which generates a DuplicateEntry exception when trying to transform). I can't see to get it working though. Here are the relevant files:
gradle.properties:
```
android.enableJetifier=true
android.jetifier.blacklist = .*lombok.*
android.useAndroidX=true
```
build.gradle:
```
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build.jetifier:jetifier-processor:1.0.0-beta02'
classpath 'com.android.tools.build:gradle:3.3.0-beta03'
}
}
plugins {
id 'com.android.application' //version '3.3.0-beta03'
id 'jacoco'
}
```
gradle.properties:
```
android.enableJetifier=true
android.jetifier.blacklist = .*lombok.*
android.useAndroidX=true
```
build.gradle:
```
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build.jetifier:jetifier-processor:1.0.0-beta02'
classpath 'com.android.tools.build:gradle:3.3.0-beta03'
}
}
plugins {
id 'com.android.application' //version '3.3.0-beta03'
id 'jacoco'
}
```
to...@gmail.com <to...@gmail.com> #7
As mentioned at comment #5 , you will need to use AGP 3.3.0-rc01+ or 3.4.0-alpha04+ for the workaround to take effect.
ti...@google.com <ti...@google.com> #8
I am interested in the ability to blacklist dependencies from being jettified as well. The binary rewrite messes with AspectJ aspect classes. It re-introduces this problem: https://issuetracker.google.com/issues/119153999
ap...@google.com <ap...@google.com> #9
I've succesfully tested the blacklist config with:
* AGP 3.3.0-rc01
* Gradle 5.1-rc-1
I just wanted to add a comment about what I had to blacklist, so that perhaps jetifier can handle this automatically without a rule.
TL;DR: jetifier should probably not even try to open *.so files.
Details:
My project depends (transitively) on a jar which contains only native *.so files.
On one particular machine (docker container) with apparently not enough memory, I was getting this error:
Execution failed for task ':libon-lite-client:checkDebugClasspath'.
> Could not resolve all files for configuration ':libon-lite-client:debugCompileClasspath'.
> Failed to transform artifact 'liblinphone-debug-symbols.jar (org.liblinphone:liblinphone:4.0.1)' to match attributes {artifactType=android-classes, org.gradle.usage=java-runtime-jars}
> Execution failed for JetifyTransform: /root/.gradle/caches/modules-2/files-2.1/org.liblinphone/liblinphone/4.0.1/871c6e76e93a7fa1bbafb5eb450e45c2330e866/liblinphone-4.0.1-debug-symbols.jar.
> Java heap space
(Note that with gradle 4.10.2/AGP 3.2.1, I didn't have this detailed info, but just simply "Transformation hasn’t been executed yet" (https://issuetracker.google.com/issues/119951660 ). I got this additional error message with gradle 5.1-rc-1/AGP 3.2.1.)
Now with gradle 5.1-rc1/AGP-3.3.0-rc01, I have this rule:
android.jetifier.blacklist=liblinphone-4.0.1-debug-symbols.jar
And I no longer get the error.
I suppose jetifier shouldn't even try to look into binary *.so files.
* AGP 3.3.0-rc01
* Gradle 5.1-rc-1
I just wanted to add a comment about what I had to blacklist, so that perhaps jetifier can handle this automatically without a rule.
TL;DR: jetifier should probably not even try to open *.so files.
Details:
My project depends (transitively) on a jar which contains only native *.so files.
On one particular machine (docker container) with apparently not enough memory, I was getting this error:
Execution failed for task ':libon-lite-client:checkDebugClasspath'.
> Could not resolve all files for configuration ':libon-lite-client:debugCompileClasspath'.
> Failed to transform artifact 'liblinphone-debug-symbols.jar (org.liblinphone:liblinphone:4.0.1)' to match attributes {artifactType=android-classes, org.gradle.usage=java-runtime-jars}
> Execution failed for JetifyTransform: /root/.gradle/caches/modules-2/files-2.1/org.liblinphone/liblinphone/4.0.1/871c6e76e93a7fa1bbafb5eb450e45c2330e866/liblinphone-4.0.1-debug-symbols.jar.
> Java heap space
(Note that with gradle 4.10.2/AGP 3.2.1, I didn't have this detailed info, but just simply "Transformation hasn’t been executed yet" (
Now with gradle 5.1-rc1/AGP-3.3.0-rc01, I have this rule:
android.jetifier.blacklist=liblinphone-4.0.1-debug-symbols.jar
And I no longer get the error.
I suppose jetifier shouldn't even try to look into binary *.so files.
ti...@google.com <ti...@google.com> #10
Re #comment9 :
Jetifier ignores *.so files. However it has to extract each archive to the memory and check each file and recreate a new zip file to the filesystem. So loading the archive to the memory has to be done no matter if there are .so files or not.
Jetifier ignores *.so files. However it has to extract each archive to the memory and check each file and recreate a new zip file to the filesystem. So loading the archive to the memory has to be done no matter if there are .so files or not.
to...@gmail.com <to...@gmail.com> #11
@Filip: I wonder if Jetifier should check the zip entries' meta data first (without loading their contents) and return immediately if there are no entries that need jetifying. (Returning is good enough, Jetifier doesn't need to copy the file to somewhere else. And even when it needs to copy some large entries from one zip file to another, we can probably use streams/Zip64 so that it doesn't load the entire zip file/zip entry into memory---see Issue 113559507 .)
pr...@google.com <pr...@google.com> #12
Is anyone else having issues with AGP 3.3.0-rc01+ or 3.4.0-alpha04+ where the project compiles and runs fine, but cannot resolve the R file? I tried invalidating android studio caches, cleaning, deleting .idea, deleting .gradle, and nothing works except reverting to android plugin 3.2.1...which I can't do because I need the jetifier blacklist workaround.
Description
Jetpack Compose version: 1.8 snapshots starting with 12408595 (So included in alpha03)
I unfortunately have some trouble to build a small repro but that commit broke transitions handled by
AnimatedContent
in my app.See attached video.
There's also some details in slack in a thread with Doris.
To resume, there's some size resolution issues when removing and adding back screens that makes the
AnimatedContent
wrongly detect a size change and doing wrong size animations.You can see in the video that the fade transition does work, then when switching screen then going back it no more work correctly and animate the size for no reasons.
Forcing
.using(null)
does workaround the issue.When reaching the broken state, if both contents of
AnimatedContent
are boxes with.fillMaxSize()
then it just shows a black screen as is it was animating from 0 to 0 size. If one of the content does not have the.fillMaxSize()
then it leads to the size animations you can see in the video.