Fixed
Status Update
No update yet.
Comments
ra...@google.com
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)
st...@baramundi.de
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).
ra...@google.com
Yes, I'm working on #3 right now to unblock users. We can continue thinking about #2.
ra...@google.com
ra...@google.com
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.
ap...@google.com
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'
}
```
st...@baramundi.de
As mentioned at
ra...@google.com
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
Description
Version used: 1.0.0-alpha08
Devices/Android versions reproduced on: Moto G5s Plus, Android 7.1.1 / Huawai P20 lite, Android 8.0.0
We can reproduce a crash of the workmanager on some devices.
In our code we enqueue a UniqueWork with ExistingWorkPolicy.REPLACE, as soon as it finishes with State.SUCEEDED we enqueue it again. There is always only one job at the time.
After about 100 jobs the workmanager crashes with: java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs.
It looks like the workmanager does not prune the finished jobs fast enough, and they count as 'sheduled' job, even if they are finished?
The crash is reproducible on the Moto G5s Plus and Huawai P20 lite. But it behaves very inconsistent, sometimes it occurs on the first run, sometimes only after a few restarts of the app. But we cannot reproduce it on the Pixel 2 XL or the emulator.
Calling pruneWork() before enqueue() doesn't fix the problem.
Reducing the result lifetime by calling keepResultsForAtLeast(..) doesn't work as well.
We provided a sample app which triggers the issue.