Even if you tried the reflection glue (and I did on a side project last week), you will have issues if you change any code that should cause dagger code to generate different output (but not the component itself). It would be great to get someone that's familiar with the incremental compilation step, but as you said, I don't know (at least with my current set of knowledge about this) what we can do, and ideally this is something that could be solved at the build level so that every annotation processor would get this support.

The best way would definitely be scanning the whole project again on incremental builds. As far as I know annotation processing can also scan .class files (RetentionPolicy.RUNTIME), but you have to add them manually to javac when compiling. I have never done that, but it should work. So I think gradle incremental build have to add all other already compiled .class files to javac when compiling the incremental build ...

For me, Hannes' suggestion to disable incremental dex didn't resolve the issue, which is why I had to disable incremental builds a little higher up the compilation chain, as suggested by this guy.

Running Gradle with the following command line option caused Dagger's annotation processor to work properly again:

-Pandroid.incrementalJavaCompile=false

@aurae that's what Tor Norbye suggested to me as well and has worked for me. He said they're considering controlling the incremental flag for recognized processors in the future.

I just talked with Tor and the next beta is going to make sure that incremental compilation is turned off for project that use Dagger, so it should at least be better in Android Studio. We're also going to raise the issue with the Gradle folks and see what they have to say.

@gk5885 Shouldn't the solution apply to all projects using annotation processing? Or is this only a dagger-specific problem?

It's not specific to Dagger, but many annotation processors are much simpler, and I think it could work with 1:1 mappings between input and output classes.
Anyway, @gk5885, if you have a link to a Gradle issue please add it here. I believe this problem has been solved in Pants where they (try to) map inputs to outputs and persist this mapping for next rounds.

@arriolac, I believe that they selected some list of annotation processors that they knew to have problems. I don't have any details, but I know that it was addressed for Dagger and some others.

@tbroyer Some people from the Android tools side of things are going to discuss it in their regular sync with the Gradle people. I don't have any details, but they're going to report back when they talk it over.

This is not a dagger-specific problem, it affects all annotation processors that uses getElementsAnnotatedWith(), some are fixable and some are not, for example, I had to do the following for an example project that I maintain:

1. Fixable without interface changes: edisonw/PennStation@c32b43c
2. Needs Refactoring: edisonw/PennStation@c1fd069

@gk5885 So this is fixable on the annotation processor side but may have to rethink some use cases.

I think turning it off for all annotation processors is not the right solution, maybe there needs a way for the annotation processors to declare themselves to require the knowledge of all existing files. apt plugin does support variables.

Any updates on this? It doesn't look like Android Studio or Gradle are modifying their behavior when dagger is used. I am disabling incremental compilation explicitly in projects that use Dagger, but it would be nice if this would happen automatically.

I would file those issues with the tools issue trackers, not with dagger. Not much we can do on that end.

Sure - I asked because of @gk5885's comment from February 4th that mentioned that Android Studio would fix in an upcoming beta. Recent changes to gradle seem to have make it worse, but I only have anecdotal evidence.

The sense that I get is that http://tools.android.com/tech-docs/new-build-system/2-5-alpha-gradle-plugin will be addressing this. Either way, there is little that Dagger can do here