Feature request: Support KSP

For Kotlin projects, Dagger currently makes use of KAPT. This is generally quite slow since it requires generating Java stubs before the annotation processing step.

KSP offers an alternative to this by making it easier for annotation processors like Dagger to more directly use Kotlin's compiler plugin infrastructure. Based on initial benchmarks, using KSP can speed up build times by as much as 2x.

Just updating this to give a sense of where we are at. This is a priority for us that we are looking into. There are some complications though mostly due to the SPI plugins which expose the JSR-269 APIs through our public interface. There’s also the fact that our annotation processor code base is huge.

Because we still need to support our javac users, we cannot switch entirely to the KSP APIs which leaves us in a bit of a pickle since the places these are exposed are deep in our core model classes. I don’t think there is a possible way to get around this being a breaking API change, but we’ll need to figure out the right API to switch to that can support both KSP and javac SPI users.

Anyway, all this is to say, this is a high priority and we are working on this, but it is also a complicated thing to rollout for a codebase our size.

Can you use compiler-processing from Room to simultaneously support both? SPI users can, for now at least, be told they're unsupported in KSP (which seems fair considering the SPI API is javac-based anyway).

Thanks for the pointer, we are already in discussion with that team about that as a possibility =)

Hi any update on this? Thanks!

Still working on it. We're preparing a new model that will wrap both javac and KSP types like in this recent change: 30fa0f3

SPI users can, for now at least, be told they're unsupported in KSP

I've opened a separate issue #2802 for that to track status and discuss possible solutions as my team is concerned about KSP support in SPI.

@Jeffset

@Jeffset, once we're ready to support KSP in Dagger, we will likewise support KSP in the SPI plugins as well. I think we can probably close #2802 , as this issue should track both.

Just to give you more details on our plans for the SPI plugin:

The new SPI model currently exists, and we are beginning to use it internally in Dagger. However, it is not yet available for users to write their own plugins.

The new model will be a thin wrapper around the javac/ksp types. For example, DaggerElement is a wrapper around Element in javac and KSDeclaration in KSP. If you need access to the javac or KSP types directly in your plugin, you will be able to call .compiler() to get which environment you're currently in (i.e. javac or KSP), and then call .javac() or .ksp() respectively to get access to the types.

Feel free to let us know if you have any concerns.

KSP is officially 1.0!
https://android-developers.googleblog.com/2021/09/accelerated-kotlin-build-times-with.html

My last dep that uses kapt is dagger + hilt! Do we have any estimated timeline? Just curious if this is a "likely by the end of 2021" type of feature request, or a "likely by the end of 2022" type of feature request. 😅

Dagger maintainers are pretty good about posting updates, let's trust a push system rather than nagging about something they are obviously aware of and working on.

Updating here since it has been some time. We've been making progress on the KSP migration, which includes making changes to Room's xprocessing libraries which we are using. Things were recently delayed for a while as the migration uncovered and exacerbated an existing issue which is the main change of the 2.41 release we just did. This issue caused a large delay not only in pulling people off the migration but also because we were afraid of making the problem worse by continuing the migration.

For that reason, it is still hard to give any sort of estimate as it is really the unknowns that we're going to hit that will take the bulk of the time. Just that one issue discovered set us back a couple months. With that said, now that the 2.41 release is finally out, we are now unblocked to continue the migration work.

any news here?

Dagger's KSP support has been documented as alpha since Dagger 2.48 (released 2023-08-30) — three years as of 2026-09-01. It is still labelled alpha in the current docs, including as of Dagger 2.60.1 (2026-07-06).

Meanwhile AGP has moved decisively against kapt. AGP 9.0 enables built-in Kotlin by default, which is incompatible with kotlin-kapt; the sanctioned fallback is com.android.legacy-kapt, and the android.builtInKotlin=false opt-out is scheduled for removal in AGP 10.

Staying on the older toolchain is not a realistic option for us: a growing number of core Android libraries now require recent AGP and Kotlin releases, so we cannot remain indefinitely in the configuration where kapt was still a supported choice.

This leaves Dagger users with no non-alpha, forward-compatible path. We are requesting an official statement on the KSP stability roadmap.

Questions

Is there a target release or timeframe for Dagger KSP to reach beta, and subsequently stable?
What specific criteria or known blockers remain before beta? Is there a checklist? We would also like to understand the concrete risk of adopting KSP now.
Given AGP 9 already classifies kapt as legacy and AGP 10 removes the built-in-Kotlin opt-out, is Dagger KSP expected to reach stable before AGP 10 ships?
Is com.android.legacy-kapt + Dagger-on-kapt a configuration that will remain supported through AGP 10, or should production applications plan on adopting alpha-stage KSP support instead?

A published roadmap — even an approximate one — would let teams decide between adopting alpha KSP, remaining on legacy-kapt, or migrating away from Dagger before AGP 10.

Thanks in advance for any clarity you can share.

KSP is officially 1.0! https://android-developers.googleblog.com/2021/09/accelerated-kotlin-build-times-with.html

My last dep that uses kapt is dagger + hilt! Do we have any estimated timeline? Just curious if this is a "likely by the end of 2021" type of feature request, or a "likely by the end of 2022" type of feature request. 😅

It is "Not finished by September 2026 kind of feature request". 😅

@dk-3cx

@dk-3cx, sorry for the delayed response (I was OOO)!

We dropped the ball on making an official announcement, but the good news is that Dagger KSP is considered stable as of version 2.60+ and KSP 2.3.9+. In particular, we hit our Beta criteria back in December 2025 and our Stable criteria in July 2026. You can see more details on these decisions below, and we will update the documentation to reflect this.

To explicitly answer your questions:

Target for beta/stable: Dagger KSP is officially considered stable as of version 2.60.
Criteria/blockers before beta: There are no remaining blockers. The risk of adopting KSP now is very low.
Stable before AGP 10: Yes, it is stable now.
Legacy-kapt vs KSP: As for whether legacy-kapt will remain supported in AGP 10, that’s something that you’ll need to ask the AGP team. Dagger will continue to support both Javac/KAPT and KSP annotation processing, and you are free to choose whichever one works best for your application.

For the long answer, you can check out the timeline below. This has been a very long, messy road and admittedly we haven’t done a great job of communicating. In addition, the goal posts were fuzzy and kept shifting. I’ve tried to clarify as much as possible below to give an idea of why this has taken so long, and to justify the Alpha, Beta, and Stable dates I mentioned above. (Also keep in mind that while KSP was one of our top priorities, there were occasionally higher priority issues -- not mentioned in this timeline -- that put this work on hold for various amounts of time):

Early 2022 (Feature request: Support KSP #2349 (comment)), work started on Dagger’s migration to KSP1 using XProcessing (a wrapper around the annotation processor layer that supports both Javac/KAPT and KSP).
May 2022 (Feature request: Support KSP #2349 (comment)), wrapped up our initial migration to XProcessing, though in the process we found many APIs that were still missing. We began working with the XProcessing team to design and implement these new APIs.
Nov 2022 (Feature request: Support KSP #2349 (comment)), Dagger KSP was officially enabled and working in all of Dagger’s existing Java source tests. We began work to add Kotlin source tests and rollout Dagger KSP to real projects in Google to test correctness.
May 2023 (Feature request: Support KSP #2349 (comment)), the rollout to real apps in Google uncovered a number of issues -- the largest being translating Kotlin types to their Java equivalent with the correct variance. In particular, Dagger relies heavily on matching the exact type of a request (e..g Foo<Bar> != Foo<? extends Bar>) and for backwards compatibility, this process had to be reverse engineered to exactly match the types produced by KAPT (see KSTypeVarianceResolver). We spent the next few months tracking down and fixing all of these issues.
Aug 2023 (Feature request: Support KSP #2349 (comment)), Dagger KSP was released as Alpha (for KSP1). At this point the main remaining issue was performance. The plan was to give a short time in Alpha for external developers to try it out and then quickly move to Beta/Stable while investigating performance.
Dec 2023 (https://android-developers.googleblog.com/2023/12/ksp2-preview-kotlin-k2-standalone.html), KSP2 was announced. This essentially halted our plans to move KSP1 to Beta/Stable, and we shifted our priority to supporting KSP2.
Sep 2024 (Feature request: Support KSP #2349 (comment)), at this point we were mostly just filing issues to the KSP team trying to get KSP2 working with Dagger’s and XProcessing’s existing test suites (which were previously working with KSP1). Unfortunately, this process just took a long time. The KSP team was essentially building the KSP2 architecture from scratch, which was a massive undertaking that constrained their bandwidth to fix all of these edge cases.
March 2025 (Feature request: Support KSP #2349 (comment)), all of the known KSP2 correctness issues were fixed, and we were essentially back at the Alpha stage for KSP2 and ready for external users to try it out. Similar to before, the plan was to give a short time in Alpha for external developers to try it out and then quickly move to Beta/Stable while investigating performance.
Dec 2025, we had rolled out KSP2 to ~40% of apps in Google, and received very few reports of issues from external users, so we were pretty confident in the correctness of KSP2. We should have officially moved Dagger KSP to Beta at this time. The main issues remaining were just related to performance, especially cases where Dagger KSP2 was actually slower than Dagger KAPT. We decided to dedicate resources from the Dagger team to investigate performance across the various layers in the stack, including Dagger, XProcessing, KSP, and Kotlinc.
July 2026, we wrapped up a number of performance improvements and validated that Dagger KSP2 was faster than KSP1/KAPT. We should have officially moved Dagger KSP to Stable at this time.

I hope this helps clarify things, and feel free to let me know if there’s anything I haven’t answered or remains unclear.

@bcorso

@bcorso Yes, this does clarify things and, although I can't speak for everyone, any concerns I may have had about timelines and the messy communication have completely melted away. So, thank you for taking the time to explain everything in such great detail! 😄👍

Also, well done to the team for taking on such a huge, thankless and meandering task, your efforts have not gone unnoticed. 🎉

Update Dagger KSP documentation and CI workflow for stable KSP support.

Navigation Menu

Repository navigation

Feature request: Support KSP #2349

69 remaining items

Questions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: Support KSP #2349

Description

Activity

Chang-Eric commented on Apr 22, 2021

ZacSweers commented on Apr 23, 2021

Chang-Eric commented on Apr 23, 2021

CoreFloDev commented on Jul 9, 2021

Chang-Eric commented on Jul 9, 2021

Jeffset commented on Aug 5, 2021

bcorso commented on Aug 5, 2021

ColtonIdle commented on Sep 8, 2021

ZacSweers commented on Sep 8, 2021

Chang-Eric commented on Feb 16, 2022

johnnycrq commented on Apr 22, 2022

69 remaining items

dk-3cx commented on Sep 1, 2026

Questions

lukas1 commented on Sep 3, 2026

bcorso commented on Sep 9, 2026

jbduncan commented on Sep 9, 2026

jbduncan commented on Sep 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions