fix(deps): update dependency androidx.core:core-ktx to v1.13.1 - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
androidx.core:core-ktx (source)	1.13.0 -> 1.13.1

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[LikeTheSalad]

I see, it seems like Compose is so special that it has its own compiler, which is very strict with what Kotlin versions it should run on, to the point that it will refuse to compile if the Kotlin version is newer than the latest compatible version tested with the Compose compiler..... Android ☕

It seems like the CI takes the sample app into account to run the PR checks, which is why it needs to run the compose compiler, which gives us a couple of options:

• Ignoring the Compose compiler warnings (I guess it should be possible, though I've never tried to do so).
• Downgrading Kotlin (I wouldn't like to do this one).
• Making the sample app a standalone Gradle project which would use the Android agent via composite builds config. This would make the Android agent compile when compiling the sample app, but not vice-versa, as the Android agent project wouldn't be aware of the sample app module.

WDYT @breedx-splk ?

[breedx-splk]

WDYT @breedx-splk ?

Ugh. Having the demo-app as a separate project I think will work around this problem, but I dislike it for a few reasons:

1. It makes the already complicated gradle plumbing more complicated.
2. It then becomes difficult to pick/choose which things to build for a given PR change.
3. It's much slower and more difficult to see how a given change impacts the user-facing APIs. By having the demo app in scope, seeing changes is more immediate.
4. Which project do I choose have open in IDEA? Both?

This is also an interesting read: renovatebot/renovate#18354

Would it really be a big deal to hold out on the version of kotlin (minor version) until compose can handle it? I wonder how much it lags in reality....

Also, I wonder if it would be possible to build the demo app with the older version of the kotlin complier. It might complicate the conventions or make us have to break the conventions in the demo app, but that might be a nicer approach?

[breedx-splk]

I did a prototype of what it looks like to break the conventions for the demo app in order to get the build working again. Please take a look: #352
I can convert out of draft if we like that approach.

[LikeTheSalad]

I did a prototype of what it looks like to break the conventions for the demo app in order to get the build working again. Please take a look: #352
I can convert out of draft if we like that approach.

Thanks, I've left a comment there with my thoughts on it!

[breedx-splk]

Ok so yeah I closed that other draft PR because I couldn't get the build to work with two versions of the gradle kotlin plugin on the classpath. It seems like it's expressly forbidden or blocked or just a plain ol' classpath limitation. In any case, seems not to work.

I also spent some time trying to get a composite build working to no avail. If you care to look at what I started I pushed it here: https://github.com/breedx-splk/opentelemetry-android/tree/demo_break_conventions_composite