[BenHenning]

Explanation

Fixes #6228
Fixes part of #6233

Written by AI and edited by @BenHenning

This PR upgrades the repository's Kotlin compiler & language version from 1.6.10 (1.6) to 1.9.0 (1.9), upgrades rules_kotlin from v1.7.1 to 1.9.2, and migrates Moshi code generation from java_plugin (kapt) to kt_ksp_plugin (KSP) while keeping the build on Bazel 6.5.0.

Per #6021, migrating to Bazel 7.x+ (#6233) is required to restore Android Studio support (since the rewritten Bazel plugin required by Android Studio Otter and newer drops support for Bazel 6.x). Because each layer of the Bazel 7 upgrade carries substantial build & runtime risk, the migration is staged across a chain of PRs so each piece can land and settle independently: #6234 upgrades the core Java, proto, JVM, and initial rules_android dependencies on Bazel 6.5.0, this PR (#6235) isolates the Kotlin 1.9 & rules_kotlin toolchain migration (which is also needed by the newer AndroidX, databinding, and Robolectric dependencies in #6237 that compile against Kotlin 1.8+/1.9 metadata), #6236 migrates production shrinking from Proguard to R8, and #6237 upgrades Bazel itself to 7.7.1.

Specific toolchain, KSP, and dependency changes to note:

• build_vars.bzl updates KOTLIN_COMPILER_VERSION from "1.6.10" to "1.9.0" and KOTLIN_LANGUAGE_VERSION from "1.6" to "1.9" (with AndroidBuildSdkPropertiesTest updated accordingly), and third_party/versions.bzl & WORKSPACE upgrade rules_kotlin from v1.7.1 to 1.9.2 (updating its http_archive URL to the new release tarball format and deleting tools/kotlin/remove_processor_duplicates.patch plus its exports_files entry in tools/kotlin/BUILD.bazel, since upstream rules_kotlin 1.8+ already deduplicates annotation processor arguments via uniquify = True).
• Rather than upgrading rules_kotlin to 2.1.3 (which was explored in earlier commits on this branch), rules_kotlin is pinned to 1.9.2 (1.9.0 and 1.9.1 have a kt_android_library testonly propagation bug) with kotlinc_version explicitly pinned to 1.9.0 and ksp_version pinned to 1.9.0-1.0.12 in WORKSPACE. This is due to a three-way constraint in rules_kotlin: rules_kotlin unconditionally injects the kotlin-stdlib bundled in its compiler_release archive into target JavaInfo dependencies regardless of language_version or include_stdlibs, so pairing a 2.1.x compiler with Maven's kotlin-stdlib 1.9.0 causes split-stdlib one-definition violations during singlejar merging and //:oppia_alpha Proguard shrinking (where inner classes removed in 2.1.x remain orphaned from 1.9.0), while rules_kotlin 2.x cannot execute a 1.9.x compiler (failing both in _get_capability_template repository evaluation and at compile time with a NoSuchMethodError in BazelK2JVMCompiler due to CLICompiler.parseArguments signature changes in Kotlin 2.0). Keeping rules_kotlin, kotlinc, and Maven's kotlin-stdlib aligned on 1.9.x avoids any split-stdlib Proguard workarounds here, though I'm a bit skeptical whether rules_kotlin 1.9.2 will work all the way through the Bazel 7 upgrade in Fix #6233: Migrate to Bazel 7 [Blocked: #6236] #6237 as-is (alongside rules_kotlin_bazel7_fixes.patch) or whether Fix #6233: Migrate to Bazel 7 [Blocked: #6236] #6237 will require bumping rules_kotlin to 1.9.6 or migrating to Kotlin 2.x.
• com.squareup.moshi:moshi-kotlin and com.squareup.moshi:moshi-kotlin-codegen are upgraded from 1.13.0 to 1.15.0 so Moshi codegen can read Kotlin 1.9.0 metadata. Because Moshi 1.15.0 deprecates kapt codegen (which fails the build under warnings-as-errors), //tools:moshi_annotation_processor_plugin in tools/BUILD.bazel is converted from a java_plugin (JsonClassCodegenProcessor) to a kt_ksp_plugin (JsonClassSymbolProcessorProvider), and //third_party:moshi in third_party/BUILD.bazel is changed from java_library to kt_jvm_library. Since kt_jvm_library does not support exported_plugins for kt_ksp_plugin, targets that use @JsonClass(generateAdapter = true) now declare plugins = ["//tools:moshi_annotation_processor_plugin"] directly (e.g. //data/src/main/java/org/oppia/android/data/backends/gae/model, //scripts/src/java/org/oppia/android/scripts/maven/model, //scripts/src/java/org/oppia/android/scripts/release:google_vertex_ai_client, and several GAE test & release model targets). To support KSP plugins in data layer tests (pulled forward from Fix #6233: Migrate to Bazel 7 [Blocked: #6236] #6237 for RetrofitModuleTest), oppia_android_test.bzl threads a plugins parameter through oppia_android_test, and data/data_test.bzl attaches //tools:moshi_annotation_processor_plugin to data_test.
• To minimize upgrade scope and risk ahead of Fix ##3748, part of #6233: Migrate to using R8 [Blocked: #6235] #6236 and Fix #6233: Migrate to Bazel 7 [Blocked: #6236] #6237, all other version updates in third_party/versions.bzl use the oldest releases compatible with Kotlin 1.9.0 metadata and compiler APIs:
  • org.jetbrains.kotlin:kotlin-stdlib-jdk8 (1.6.10 -> 1.9.0), org.jetbrains.kotlin:kotlin-compiler-embeddable (1.5.0 -> 1.9.0), and org.jetbrains.kotlin:kotlin-reflect (1.3.41 -> 1.9.0) are updated to match KOTLIN_COMPILER_VERSION.
  • dagger is upgraded from 2.41 to 2.46 (the oldest release bundling kotlinx-metadata-jvm 0.6.0 for Kotlin 1.9.0 metadata support).
  • androidx.compose.compiler:compiler is upgraded from 1.1.1 to 1.5.0 (the oldest Compose compiler compatible with kotlinc 1.9.0, while keeping the Compose UI/foundation/material/runtime libraries at 1.1.1).
• Repinning third_party/maven_install.json and regenerating scripts/assets/maven_dependencies.textproto records these direct bumps along with their transitive dependency shifts and removes the obsolete conflict_resolution overrides for kotlin-reflect:1.3.41 and kotlin-stdlib-jdk8:1.6.10.

I've verified these changes locally on Bazel 6.5.0 by building //:oppia_dev and //:oppia_alpha (including Proguard 6.2.2 shrinking/obfuscation), running all static checks (bash scripts/static_checks.sh), full Android Lint (//scripts:android_lint_check), and affected unit & Robolectric tests.

Essential Checklist

• The PR title starts with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• The explanation section above starts with "Fixes #bugnum: " (If this PR fixes part of an issue, use instead: "Fixes part of #bugnum: ...".)
• Any changes to scripts/assets files have their rationale included in the PR explanation.
• The PR follows the style guide.
• The PR does not contain any unnecessary code changes from Android Studio (reference).
• The PR is made from a branch that's not called "develop" and is up-to-date with "develop".
• The PR is assigned to the appropriate reviewers (reference).

Disclosure of LLM Usage

• Did you use AI/LLMs when working on this PR? Yes
• If yes, describe the extent AI was used: Gemini CLI generated the initial Kotlin 1.9 upgrade (b844641) and KSP migration (8d4d4a3) commits through extensive back-and-forth prompting, and AntiGravity (using Gemini models) was used for the post-merge build stabilization, dependency minimization, and rules_kotlin 1.9.2 downgrade (cd1fada). Separately, this PR description was drafted with an AI agent from the branch diff and my answers to its questions, and then reviewed and edited by me.

For UI-specific PRs only

N/A -- Build & dependency infrastructure-only change that shouldn't impact the UI or UX of the app (outside of bumping the Compose compiler plugin for compatibility with Kotlin 1.9.0 but that should be a functional no-op even if it could risk introducing new bugs).

[oppiabot]

Hi @BenHenning, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue.
If you are still working on this PR, please make a follow-up commit within 3 days (and submit it for review, if applicable). Please also let us know if you are stuck so we can help you! If you're unsure how to reassign this PR to a reviewer, please make sure to review the wiki page that details the Guidance on submitting PRs.

[oppiabot]

Hi @BenHenning, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue.
If you are still working on this PR, please make a follow-up commit within 3 days (and submit it for review, if applicable). Please also let us know if you are stuck so we can help you! If you're unsure how to reassign this PR to a reviewer, please make sure to review the wiki page that details the Guidance on submitting PRs.

[oppiabot]

Hi @BenHenning, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue.
If you are still working on this PR, please make a follow-up commit within 3 days (and submit it for review, if applicable). Please also let us know if you are stuck so we can help you! If you're unsure how to reassign this PR to a reviewer, please make sure to review the wiki page that details the Guidance on submitting PRs.

[oppiabot]

Hi @BenHenning, I'm going to mark this PR as stale because it hasn't had any updates for 7 days. If no further activity occurs within 7 days, it will be automatically closed so that others can take up the issue.
If you are still working on this PR, please make a follow-up commit within 3 days (and submit it for review, if applicable). Please also let us know if you are stuck so we can help you! If you're unsure how to reassign this PR to a reviewer, please make sure to review the wiki page that details the Guidance on submitting PRs.

[BenHenning]

PTAL @adhiamboperes. I still need to self review the PR code, but I don't expect many changes. I think CI was passing locally but the actions runs seem to be running out of memory very easily. I'm not certain this is caused by my PRs or if it's just a consequence of continuing GitHub instability. If my PRs are going to make CI worse then I'll probably need to dig further into possible fixes (but maybe after they're merged so that we can prioritize getting the signals work done).

It may also be worth prioritizing getting Bazel 7 merged in and then working on optimizations (or even continuing to latest Bazel via bzlmod because I'm assuming each jump will introduce new optimization challenges, regardless, so it's probably not worth overfixing on a specific version yet).

[adhiamboperes]

Thanks @BenHenning!

I have left some comments inline.

Also re-ran the tests once and they failed, so I have retried them again. PTAL when they complete.

[adhiamboperes]

The name changed to 1.15 but reported version is still 1.13.0. Ditto ln1680 and 1691.

[adhiamboperes]

Same issue here.