Hi all! Just wanted to share some things I had run...

# kotlin-toolchain

[Zachary Sistrunk]

Hi all! Just wanted to share some things I had run into while setting up a project:

First off, there was some kind of issue in the BOM handling. Following OpenTelemetry's instructions for the android-agent import, they said to import the android agent BOM alongside the agent itself, as the versions of dependencies in the agent were unversioned and needed the BOM to be resolved. Gradle handled it fine, but Kotlin Toolchain wasn't able to resolve the versions. It may have something to do with how the BOM was built, it imported other BOMs itself.

Second, without being able to use dependency exclusions, I ran into a conflict between tink and tink-android. They both contain the same classes, so you can't have them both on the classpath of an Android build or it will fail to build due to duplicate class definitions. In my case, I had two dependencies that each imported one: androidx.security:security-crypto imports tink-android, while org.unifiedpush.android:connector imports tink.

[alexey.barsov]

Hi, @Zachary Sistrunk , thanks for your detailed feedback!
• Regarding BOM, it looks like a bug since resolution of external dependencies with unspecified versions was supported some time ago. That would be great if you file an issue with some trivial reproducing project config or some partial dependencies declaration that causes the issue.
• Supporting ways to adjust a dependency graph (and particularly, exclusions AMPER-923) are in our plans. And, though the issue is clear, to understand the case better, it would be great if you could share a sample module configuration leading to the issue with mixing tink and tink-android on classpath. Thanks in advance

[Zachary Sistrunk]

@alexey.barsov Sure, here you go! This minimal reproducer recreates both issues at once. The dependencies will fail to load due to the OTel failure, but if you comment out those two dependencies and try to build, you'll hit the Android failure.

[alexey.barsov]

hi, @Zachary Sistrunk
I am sorry for the delay, I have tried the repro project and found out that you were right the first issue is caused by the nesting of BOMs.
I have filed a bug AMPER-5449 , fixed it locally, and it will take some time (till the end of the day I guess) to get it into the dev build.

The issue with lacking exclusions support (or some other ways to tune the graph) is still there and will be addressed (it is in our short-term road map).

Meanwhile, there are work-arounds for both issues:
• BOM issue might be worked around by specifying direct dependencies on transitive BOMs (as you already mentioned in the module.yaml of the repro project)
• duplicated class declaration might be resolved by adding tink into the module-wide list of excluded libraries.

product: android/app

dependencies:
  - org.unifiedpush.android:connector:3.3.3
  - androidx.security:security-crypto:1.1.0-alpha06
  # Dependency resolution will fail due to issue 1. Comment the below two lines to test issue 2.
  - bom: io.opentelemetry.android:opentelemetry-android-bom:1.4.0-alpha
  - bom: io.opentelemetry:opentelemetry-bom:1.62.0
  - bom: io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom:2.28.0
  - io.opentelemetry.android:android-agent:1.4.0

settings:
  android:
    namespace: dev.sistrunk.reproducer
    compileSdk: 36
    minSdk: 26
    targetSdk: 36
    applicationId: dev.sistrunk.reproducer
  internal:
    excludeDependencies:
      - com.google.crypto.tink:tink

[Zachary Sistrunk]

Thank you! I didn't see anything in the docs about the module-wide exclusions, but I think that would work perfect and will let me get rid of the convoluted workaround I did with a locally published Gradle build.

@alexey.barsov I did run into one more issue after that, however, still in the Android build. AGP ran a task MergeJavaResWorkAction, which combined together the resource folders of all dependencies. The issue was that two dependencies brought in conflicting resources with the same name: META-INF/versions/9/OSGI-INF/MANIFEST.MF
I don't have a repro for this at the moment, but these were the two dependencies that the build called out as conflicting.
◦ org.jspecifyjspecify1.0.0
◦ io.opentelemetryopentelemetry exporter common1.63.0
Right now my workaround for this one is a plugin that takes the Classpath as an input and modifies the dependency JARs to strip that file out. It works, but the modification of the classpath in that manner breaks execution avoidance, so now my Android build runs every time.

[alexey.barsov]

Do I get it right that those two dependencies are legit and expected at the end of resolution phase and the issue is that both of them have the same resource with is incorrectly processed by the build logic? Or one of dependencies is unexpected and is somehow filtered out if you build the same project by Gradle?

[Zachary Sistrunk]

The dependencies are legit and expected. The same problem would occur in Gradle, but Gradle has a way to configure that resource task to handle conflicts in resource files. I’ll be able to build a repro later today to show it in more detail.

[alexey.barsov]

Cc @Anton Prokhorov, could you please have a look at the issue with duplicated resources?

[Anton Prokhorov]

youtrack.jetbrains.com/issue/AMPER-5488 created an issue

[Zachary Sistrunk]

Oh, thanks! I'm sorry, this past couple of weeks ended up being super busy at work, so I wasn't able to make the repro like I said. Do you still need it, or were you are to make it internally already?

[Anton Prokhorov]

Do you still need it

Yes, it would be delightful if you made it

[Anton Prokhorov]

oh, it turned out, there is a way to configure that

try this:

settings:
  android:
    resourcePackaging:
      excludes:
        - META-INF/versions/9/OSGI-INF/MANIFEST.MF

[Anton Prokhorov]

Lacking of the documentation, I guess, is a problem here, I'll update the docs