Fixed
Status Update
No update yet.
Comments
xa...@google.com
Update: I was able to downgrade to 32.1.10 and I can confirm it's smooth again. The issue is indeed in emulator version 33.1.1
pa...@google.com
It's happening to me too and I also confirm that reverting to 32.1.10 fixes the issue.
We should have an easier way of reverting versions. AS should allow picking the version similarly to how we already do for the other tools in SDK manager.
We should have an easier way of reverting versions. AS should allow picking the version similarly to how we already do for the other tools in SDK manager.
hu...@google.com
Hi,
would you try to turn on hardware GPU rendering (instead of auto GPU) and see if it fixes this issue?
would you try to turn on hardware GPU rendering (instead of auto GPU) and see if it fixes this issue?
hu...@google.com
Hi,
I'm currently not able to change this option, it is greyed out.
I'm currently not able to change this option, it is greyed out.
[Deleted User] <[Deleted User]>
Hi,
there are 2 ways to set it:
1. use a google_apis image (instead of google_apis_playstore). it will re-enable the option.
2. go to your avd folder (usually located in ~/.android/avd/your_avd_name.avd/), open config.ini and hardware-qemu.ini, then modify those lines:
hw.gpu.enabled=yes
hw.gpu.mode=host
there are 2 ways to set it:
1. use a google_apis image (instead of google_apis_playstore). it will re-enable the option.
2. go to your avd folder (usually located in ~/.android/avd/your_avd_name.avd/), open config.ini and hardware-qemu.ini, then modify those lines:
hw.gpu.enabled=yes
hw.gpu.mode=host
hu...@google.com
Hi,
Yes, option 2 fixes the issue (which also persists on 33.1.2 btw). Even though I get a warning when I start the emulator (see attachments).
Will this option be enabled "out of the box" in a future version?
Yes, option 2 fixes the issue (which also persists on 33.1.2 btw). Even though I get a warning when I start the emulator (see attachments).
Will this option be enabled "out of the box" in a future version?
jt...@temp.thunderhead.com
Hi,
we suspect a bug in gpu detection logic on Mac M1, and will try to address it in upcoming releases.
we suspect a bug in gpu detection logic on Mac M1, and will try to address it in upcoming releases.
ms...@gmail.com
Hi Devki,
would you help to cp aosp/2451107 to next stable and canary releases? Thank you!
would you help to cp aosp/2451107 to next stable and canary releases? Thank you!
pa...@google.com
Hi Devki,
Could we cherry-pick it to canary release as well? Thanks!
Could we cherry-pick it to canary release as well? Thanks!
hu...@google.com
@yahan it will be picked up in the next canary since we are doing snaps!
st...@gmail.com
Thanks!
im...@google.com
Was able to force the emulator to use the host GPU by opening it via the terminal with
./emulator -avd Resizable_API_33 -gpu host
st...@gmail.com
I believe this is still happening in 33.1.10
jt...@temp.thunderhead.com
Chris, would you help to send us the verbose log?
hu...@google.com
User on
ne...@gmail.com
do you still have this problem with latest 33.1.20+ ?
hu...@google.com
If that question is for me, I've tested changing the config.ini back to "hw.gpu.mode=auto" and it appears to be fine. I have 33.1.2.0.
ne...@gmail.com
with 34.1.x stable already, are there still any performance degradation ?
let us know
let us know
hu...@google.com
Can confirm the flag is correctly set for new emulators on 34.1.18
ri...@gmail.com
Any ideas about this one -
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:kaptGenerateStubsDebugKotlin'
...
Caused by: java.lang.RuntimeException: Failed to transform '/Users/user/.gradle/caches/modules-2/files-2.1/org.xerial/sqlite-jdbc/3.20.1/df3068e837e9490a9554212fcab40a2c55faf0a3/sqlite-jdbc-3.20.1.jar' using Jetifier. Reason: invalid entry size (expected 618164 but got 636977 bytes). (Run with --stacktrace for more details.) To disable Jetifier, set android.enableJetifier=false in your gradle.properties file.
at com.android.build.gradle.internal.dependency.JetifyTransform.transform(JetifyTransform.kt:204)
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:kaptGenerateStubsDebugKotlin'
...
Caused by: java.lang.RuntimeException: Failed to transform '/Users/user/.gradle/caches/modules-2/files-2.1/org.xerial/sqlite-jdbc/3.20.1/df3068e837e9490a9554212fcab40a2c55faf0a3/sqlite-jdbc-3.20.1.jar' using Jetifier. Reason: invalid entry size (expected 618164 but got 636977 bytes). (Run with --stacktrace for more details.) To disable Jetifier, set android.enableJetifier=false in your gradle.properties file.
at com.android.build.gradle.internal.dependency.JetifyTransform.transform(JetifyTransform.kt:204)
hu...@google.com
Can you please file a new bug with us and link it here so I can follow up?
ri...@gmail.com
Sure
ri...@gmail.com
Hey, deleting and cloning the repo again fixes this issue, do you still want me to file this?
hu...@google.com
No need for now (as there is too little information for it to be actionable), but we'll keep that in mind and please do file a bug if you see it again. Thanks!
em...@gmail.com
Hi,
I have this error but I cannot fix if with blacklist, is it the same issue ? Could `android.jetifier.blacklist` property fix it ?
09:08:56 > Could not resolve all files for configuration ':app:releaseUnitTestCompileClasspath'.
09:08:56 > Failed to transform artifact 'full.jar (project :api)' to match attributes {artifactType=processed-jar, com.android.build.api.attributes.BuildTypeAttr=release, com.android.build.api.attributes.VariantAttr=release, com.android.build.gradle.internal.dependency.AndroidTypeAttr=Aar, org.gradle.usage=java-api, org.jetbrains.kotlin.platform.type=androidJvm}
Thanks
I have this error but I cannot fix if with blacklist, is it the same issue ? Could `android.jetifier.blacklist` property fix it ?
09:08:56 > Could not resolve all files for configuration ':app:releaseUnitTestCompileClasspath'.
09:08:56 > Failed to transform artifact 'full.jar (project :api)' to match attributes {artifactType=processed-jar, com.android.build.api.attributes.BuildTypeAttr=release, com.android.build.api.attributes.VariantAttr=release, com.android.build.gradle.internal.dependency.AndroidTypeAttr=Aar, org.gradle.usage=java-api, org.jetbrains.kotlin.platform.type=androidJvm}
Thanks
hu...@google.com
This is a different issue. Please file a new bug and let me know the bug ID. Thanks!
me...@thomaskeller.biz
Jetifier really brings up some headaches. We upgraded AGP from 3.5.2 to 3.6.0-beta04 and found our Cucumber tests failing afterwards. The issue Cucumber reports was
cucumber.runtime.CucumberException: No backends were found. Please make sure you have a backend module on your CLASSPATH.
Cucumber reports that when an artifact like `cucumber-java` (or any other language backend) is not present. Cucumber tries to service-load this automatically when present in the classpath (seehttps://github.com/cucumber/cucumber-jvm/search?q=JavaBackendProviderService&unscoped_q=JavaBackendProviderService for references), but apparently fails.
Interestingly, the tests continued to run without issues in Android Studio, they were just failing when executed from command line. A test run with --debug showed me that the Gradle run however used jetified versions of the cucumber libraries in the application classpath. Adding `.*cucumber.*` to the jetifier blacklist solved the issue.
I'm completely unaware of the black magic that Jetifier involves, but I see that it has some very serious consequences when applied broadly on a project, things that are rather hard to track down because subtle things like service locators suddenly stop working.
cucumber.runtime.CucumberException: No backends were found. Please make sure you have a backend module on your CLASSPATH.
Cucumber reports that when an artifact like `cucumber-java` (or any other language backend) is not present. Cucumber tries to service-load this automatically when present in the classpath (see
Interestingly, the tests continued to run without issues in Android Studio, they were just failing when executed from command line. A test run with --debug showed me that the Gradle run however used jetified versions of the cucumber libraries in the application classpath. Adding `.*cucumber.*` to the jetifier blacklist solved the issue.
I'm completely unaware of the black magic that Jetifier involves, but I see that it has some very serious consequences when applied broadly on a project, things that are rather hard to track down because subtle things like service locators suddenly stop working.
hu...@google.com
Thank you for the feedback! We are looking to remove edge cases like this one, and bug reports like this help us do that.
If possible, could you attach the original version of the cucumber library and the jetified version, so that we can investigate what was actually modified by Jetifier?
If possible, could you attach the original version of the cucumber library and the jetified version, so that we can investigate what was actually modified by Jetifier?
hu...@google.com
Starting with AGP 4.0.0-alpha07 (using Jetifier 1.0.0-beta06+), Jetifier will not jetify libraries that already support AndroidX: https://android-review.googlesource.com/c/platform/frameworks/support/+/952620/ . The blacklist workaround shouldn't be needed anymore.
After updating to AGP 4.0.0-alpha07+, please remove the android.jetifier.blacklist property if you have been using it. And if you still run into issues after doing that, please file a bug with us athttp://issuetracker.google.com/issues/new?component=460323 .
To close the loop on the 3 different approaches outlined at
> We need a way to determine whether a third-party library should be jetified or not. There are a couple of approaches:
> 1. The library adds some metadata stating that it is AndroidX-ready and therefore should not be jetified.
=> Infeasible
> 2. Jetifier automatically detects the presence of AndroidX (e.g., import statements and strings containing references to AndroidX), and if AndroidX is present, assumes that the library is AndroidX-ready and skips converting it.
=> Implemented
> 3. The users need to specify a blacklist of libraries that should not be jetified.
=> Used previously as a workaround (seehttp://issuetracker.google.com/issues/new?component=460323 .
After updating to AGP 4.0.0-alpha07+, please remove the android.jetifier.blacklist property if you have been using it. And if you still run into issues after doing that, please file a bug with us at
To close the loop on the 3 different approaches outlined at
> We need a way to determine whether a third-party library should be jetified or not. There are a couple of approaches:
> 1. The library adds some metadata stating that it is AndroidX-ready and therefore should not be jetified.
=> Infeasible
> 2. Jetifier automatically detects the presence of AndroidX (e.g., import statements and strings containing references to AndroidX), and if AndroidX is present, assumes that the library is AndroidX-ready and skips converting it.
=> Implemented
> 3. The users need to specify a blacklist of libraries that should not be jetified.
=> Used previously as a workaround (see
Description
Example failures:
(1)
Execution failed for task ':app:kaptGenerateStubsDebugKotlin'.
> Could not resolve all files for configuration ':app:kapt'.
> Failed to transform file 'butterknife-compiler-9.0.0-SNAPSHOT.jar' to match attributes {artifactType=processed-jar} using transform JetifyTransform
> Failed to transform '...\.gradle\caches\modules-2\files-2.1\com.jakewharton\butterknife-compiler\9.0.0-SNAPSHOT\d5efd0795737d4523044335a7faa82b0e3d984c9\butterknife-compiler-9.0.0-SNAPSHOT.jar' using Jetifier.
Reason: The given artifact contains a string literal with a package reference 'android.support.v4.content' that cannot be safely rewritten. Libraries using reflection such as annotation processors need to be updated manually to add support for androidx.
(2)
Execution failed for task ':app:kaptGenerateStubsDebugKotlin'.
> Could not resolve all files for configuration ':app:kapt'.
> Failed to transform file 'jetifier-core-1.0.0-alpha10.jar' to match attributes {artifactType=processed-jar} using transform JetifyTransform
> Failed to transform '/Users/nkotula/.gradle/caches/modules-2/files-2.1/com.android.tools.build.jetifier/jetifier-core/1.0.0-alpha10/9eb7027c383061de12f93aae7a22cbeb97832d2a/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.
(In this example, Jetifier even tries to jetify itself!)
(3)
Execution failed for task ':app:kaptGenerateStubsDebugKotlin'.
> Could not resolve all files for configuration ':app:kapt'.
> Failed to transform file 'kotlin-compiler-embeddable-1.2.21.jar' to match attributes {artifactType=processed-jar} using transform JetifyTransform
> Failed to transform '/root/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler-embeddable/1.2.21/39456b64a42dc359e385697e2e93b5cba52e197f/kotlin-compiler-embeddable-1.2.21.jar' using Jetifier.
Reason: Malformed input or input contains unmappable characters: javaslang/?.class.
(In this example, kotlin-compiler-embeddable-1.2.21.jar does not need to be jetified but was jetified and then failed.)
We need a way to determine whether a third-party library should be jetified or not. There are a couple of approaches:
1. The library adds some metadata stating that it is AndroidX-ready and therefore should not be jetified. (The Android Gradle plugin can also help to add this information automatically for libraries that are built using the AGP.)
2. Jetifier automatically detects the presence of AndroidX (e.g., import statements and strings containing references to AndroidX), and if AndroidX is present, assumes that the library is AndroidX-ready and skips converting it.
3. The users need to specify a blacklist of libraries that should not be jetified.
We'll need to weigh the pros and cons of these approaches and select the best one (or a combination of them).