getsentry / getsentry/sentry-java
Investigate AGP built-in Kotlin and remove android.builtInKotlin=false opt-out
- Dominant language
- Kotlin
- Stars
- 1.4k
- Forks
- 478
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 67
Description
Follow-up to the AGP 8.13.1 → 9.2.1 bump (getsentry/sentry-java#5777). AGP 9 bundles its own ("built-in") Kotlin. To land the bump without a large refactor, we added a temporary opt-out in `gradle.properties`:
```
# AGP 9+ migration opt-outs until we remove kotlin-android plugin and adopt built-in Kotlin.
android.builtInKotlin=false
```
**Why this matters:** `android.builtInKotlin=false` keeps us on the standalone `org.jetbrains.kotlin.android` plugin (Kotlin 2.3.21). If Google removes this opt-out in a future AGP release, we would be forced onto built-in Kotlin — and given our current project structure, that may block us from upgrading at all.
**What to investigate:**
* Whether AGP's built-in Kotlin version can be controlled/pinned, and whether it is compatible with our multi-module setup.
* What breaks if we remove `android.builtInKotlin=false` today.
**What's involved:**
* `org.jetbrains.kotlin.android` is applied in ~15 modules (sentry-android, sentry-android-core, sentry-android-replay, sentry-compose, etc.). Adopting built-in Kotlin means removing that plugin from all of them.
* Interacts with `kotlin.stdlib.default.dependency=false` (stdlib management) and the pinned `kotlinStdLibVersionAndroid = "1.9.24"` (`buildSrc/src/main/java/Config.kt:5`).
**Done when:** we understand the constraints, have a documented path forward, and (ideally) can remove `android.builtInKotlin=false`.
Should be picked up after the AGP bump PRs merge.
Contributor guide
Research direction
Start with gradle.properties and buildSrc/src/main/java/Config.kt:5, then inspect the roughly 15 modules applying org.jetbrains.kotlin.android, including sentry-android and sentry-android-core. Remove android.builtInKotlin=false in a trial configuration and record compatibility, Kotlin version control, stdlib behavior, and multi-module breakage. Done means the constraints and a documented migration path are clear, ideally with the opt-out removed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- build-system, mobile
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100