Status Update
Comments
xo...@google.com <xo...@google.com> #2
Thank you for posting an issue. It is not obvious to me what the error is, please give some more information, ideally a
If you cannot provide a dump, please share the full stack trace and potentially the classes that are failing if that is available from the information you have. You can probably obtain it by running the release process from the command line.
The Expected stack map table for method with non-linear control flow.
is because you have invalid class file input. It is an error to not provide frame information in jumps and has been so from class file version 50.
xa...@google.com <xa...@google.com> #3
xo...@google.com <xo...@google.com> #4
If the issue re-appears feel free to re-open the bug.
xa...@google.com <xa...@google.com> #5
The application I'm working on is getting the same error after upgrading Gradle and the Gradle Plugin (7.4.1). Very little info online about this. Let me know what info I can provide; it seems like a legitimate issue given that multiple people are reporting it.
The application I'm working on is not using androidx.multidex:multidex like the other user.
> Task :app:dexBuilderDebug FAILED
AGPBI: {"kind":"error","text":"com.android.tools.r8.internal.Fq: No VersionRequirement with the given id in the table","sources":[{}],"tool":"D8"}
AGPBI: {"kind":"error","text":"com.android.tools.r8.internal.Fq: No VersionRequirement with the given id in the table","sources":[{}],"tool":"D8"}
com.android.tools.r8.internal.Fq: No VersionRequirement with the given id in the table
Execution failed for task ':app:dexBuilderDebug'.
> Could not resolve all files for configuration ':app:detachedConfiguration3'.
> Failed to transform jetified-anko-sdk25-coroutines-0.10.3.jar to match attributes {artifactType=ext-dex-dexBuilderDebug, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
> Execution failed for DexingExternalLibArtifactTransform: /Users/.../.gradle/caches/transforms-3/17e3e87543b7bc6c15b2729175c4f93a/transformed/jetified-anko-sdk25-coroutines-0.10.3.jar.
> Error while dexing.
> Failed to transform jetified-anko-appcompat-v7-coroutines-0.10.3.jar to match attributes {artifactType=ext-dex-dexBuilderDebug, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
> Execution failed for DexingExternalLibArtifactTransform: /Users/.../.gradle/caches/transforms-3/192f3b6aa3588ba73225fa6268e99efa/transformed/jetified-anko-appcompat-v7-coroutines-0.10.3.jar.
> Error while dexing.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
com.android.tools.r8.internal.Fq: No VersionRequirement with the given id in the table
I've tried invalidating caches as well as rebuilding the project.
Please let me know if I should open a separate ticket!
so...@google.com <so...@google.com> #6
Would it be possible to provide a
Potentially I only need /Users/.../.gradle/caches/transforms-3/17e3e87543b7bc6c15b2729175c4f93a/transformed/jetified-anko-sdk25-coroutines-0.10.3.jar
to reproduce the problem.
Are you using desugared library? Is this R8 or D8 (minifyEnabled = true
)?
xo...@google.com <xo...@google.com> #8
I tried to look for the library for which the issue is reported adding the dependency implementation 'org.jetbrains.anko:anko-sdk25-coroutines:0.10.3'
to a project. However that artifact is not found on the usual Maven repos, and jetified-anko-sdk25-coroutines-0.10.3.jar
will be needed to make progress.
xo...@google.com <xo...@google.com> #9
Branch: main
commit f631bcf3e4e0a2bb02323de96ba26acdba5e8014
Author: Morten Krogh-Jespersen <mkroghj@google.com>
Date: Mon Mar 20 14:00:12 2023
Clean-up parsing kotlin metadata to not throw exception in thread
Bug:
Change-Id: I42c5e986d3b0ea9448bc7a6512934283f88f92c9
M src/main/java/com/android/tools/r8/kotlin/KotlinClassMetadataReader.java
M src/main/java/com/android/tools/r8/kotlin/KotlinMetadataEnqueuerExtension.java
M src/main/java/com/android/tools/r8/kotlin/KotlinMetadataRewriter.java
M src/main/java/com/android/tools/r8/utils/BooleanBox.java
sp...@google.com <sp...@google.com> #10
The error is that old kotlin compilers would generate synthetic lambdas with version requirement: 0
as default but it actually should just be empty. An issue was reported on kotlin here:
This is fixed from 1.3.40-dev and forward. The synthetic lambda that fails has metadata version 1.1.15 and therefore compiled by a compiler that generated the invalid entry in version requirement.
We should not throw an error that fails compilation in D8. This is fixed ToT and I will cherry-pick to our release branches.
am...@google.com <am...@google.com> #11
Branch: 8.0
commit 6bd39cff22a1ebcd7593622b25fc8cbad2a6d655
Author: Morten Krogh-Jespersen <mkroghj@google.com>
Date: Mon Mar 20 15:34:12 2023
Clean-up parsing kotlin metadata to not throw exception in thread
Bug:
Change-Id: I42c5e986d3b0ea9448bc7a6512934283f88f92c9
M src/main/java/com/android/tools/r8/kotlin/KotlinClassMetadataReader.java
M src/main/java/com/android/tools/r8/kotlin/KotlinMetadataEnqueuerExtension.java
M src/main/java/com/android/tools/r8/kotlin/KotlinMetadataRewriter.java
M src/main/java/com/android/tools/r8/utils/BooleanBox.java
sp...@google.com <sp...@google.com> #12
Branch: 8.0
commit f8b4d858b23c7b59eb4c8357772ed6ad4406a7d7
Author: Morten Krogh-Jespersen <mkroghj@google.com>
Date: Mon Mar 20 15:34:26 2023
Version 8.0.36
Bug:
Change-Id: I155be22a9466968f82f4d450861670332754f91a
M src/main/java/com/android/tools/r8/Version.java
am...@google.com <am...@google.com> #13
I will add in manually for now. I can also confirm that the fix works when added manually like:
buildscript {
repositories {
maven {
url '
}
}
}
dependencies {
classpath 'com.android.tools:r8:8.0.36'
}
sp...@google.com <sp...@google.com> #14
Our 8.0 branch corresponds to Android Studio Flamingo, and it should be in for the final release.
am...@google.com <am...@google.com> #15
เรียนรู้แอนดรอยด์
sp...@google.com <sp...@google.com> #16
xa...@google.com <xa...@google.com> #17
This is fixed from AGP 8.0, so please ensure that version or higher is used.
sp...@google.com <sp...@google.com> #18
I filed
sp...@google.com <sp...@google.com> #19
I've attached a project which demonstrates when a build will break in case (3) from #16.
In this project, the app gets its namespace ("com.example.namespace"
) from the package
attribute of the AndroidManifest.xml
.
The AndroidTest component gets its namespace from the testApplicationId
, and it's the same namespace as the app's.
The AndroidTest component calls com.example.namespace.R.string.app_android_test_string
in ExampleInstrumentedTest
, which compiles as-is (./gradlew :app:assembleAndroidTest
), but if we add namespace "com.example.namespace"
to the DSL, then it doesn't compile anymore because the AndroidTest component's namespace becomes "com.example.namespace.test".
xo...@google.com <xo...@google.com> #20
Thanks for the test project.
What are the downsides of preserving the workingness of the project by adding testNamespace "com.example.namespace"
in the case that there is a collision, like in this test project? It builds successfully for me, but maybe there are subsequent problems?
xo...@google.com <xo...@google.com> #22
Thanks. (But not in the test project from -alpha09
).
sp...@google.com <sp...@google.com> #23
Ah, yes, looks like that change was merged in -alpha10
.
xo...@google.com <xo...@google.com> #24
OK. I've implemented the behaviour in main
and androidTest
packages we block the upgrade rather than upgrade to something that doesn't work: largely because there's no real way at the moment to conditionally hook the post-upgrade display (given that the post-upgrade display absolutely must display sync status and rollback recommendations/suggestions if appropriate). I think this is probably best (and consistent with other upgrade processors).
I think that's it for Upgrade Assistant support on this, apart from the precise canary when the new behaviour is activated: over to you, Scott.
sp...@google.com <sp...@google.com> #25
Thanks! Closing this bug as I still have
al...@booking.com <al...@booking.com> #26
After upgrading to Android Gradle Plugin 8.0.1 and moving all namespaces from Manifests to build scripts, my android tests started failing, giving me the following error:
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.myapp.android.test.TestApplication"
The problem seems to be related to the namespace: the namespace for android tests is %namespace% + ".test". When the OS tries to load a component that is declared in Manifest with a relative path like android:name=".TestApplication" it uses the test namespace and eventually cannot find it on the classpath.
Is there a way to fix this?
sp...@google.com <sp...@google.com> #27
Is there a way to fix this?
Can you use the fully qualified name instead of ".TestApplication"?
If that doesn't work for you, can you give more details so I can reproduce the issue? IIUC, the actual fully qualified class name is com.myapp.android.TestApplication
, and android:name=".TestApplication
is located in the androidTest
AndroidManifest.xml
... is that correct?
al...@booking.com <al...@booking.com> #28
Using fully qualified name fixes the problem, but it is not an elegant solution for a huge project with hundred of modules with android tests where it all needs to be fixed manually.
It worked well with "package" in Manifest.
Just wonder, is this the only solution?
sp...@google.com <sp...@google.com> #29
Using fully qualified name fixes the problem, but it is not an elegant solution for a huge project with hundred of modules with android tests where it all needs to be fixed manually.
Unfortunately, I can't think of another way to fix the problem.
It worked well with "package" in Manifest.
Yes, but we've opted to (1) disallow setting a value for package that is different than the (test) namespace and (2) disallow having namespace match testNamespace. (1) - because it is confusing, and (2) - because there can be unintended collisions of production vs test android resources.
Very sorry for the breaking change.
al...@booking.com <al...@booking.com> #30
xa...@google.com <xa...@google.com> #31
Isn't this issue more related to the change we made to the test applicationID
as part of this change? It used to be that the test appID was computed badly based on the test package, but we change the computation (I don't remember exactly the change).
The relative path in the manifest is expanded based on testApplicationId
, not the testNamespace
(computed or explicit).
You should configure this to be what you expect it to be.
sp...@google.com <sp...@google.com> #32
The relative path in the manifest is expanded based on testApplicationId, not the testNamespace (computed or explicit).
That was the old behavior, but AGP uses the namespace now, not the application ID. See
Description
See Issue 176931684 for reference.
Basically AndroidTest variants do not the correct value for the package name for their
R
classes. We need to fix this.This would be a source level breaking change for project and we would need support in the Upgrade Assistant to fix it.
We need to discuss timing but in all likelihood that would be done in AGP 8.0