IssueTracker

Having a recurrence of the issue with none of the databinding abstract base classes being found. It's again consistent across several consecutive clean + rebuild cycles. I've dumped a complete file listing from the app/build folder to look at and after filtering down to files matching a specific binding name here's what exists:

app/build/generated/data_binding_base_class_source_out/debug/out/com/example/myapp/databinding/MyBinding.java
app/build/generated/source/kapt/debug/com/example/myapp/databinding/MyBindingImpl.java
app/build/intermediates/javac/debug/classes/com/example/myapp/databinding/MyBinding.class
app/build/intermediates/javac/debug/classes/com/example/myapp/databinding/MyBindingImpl.class
app/build/intermediates/project_dex_archive/debug/out/com/example/myapp/databinding/MyBinding.dex
app/build/intermediates/project_dex_archive/debug/out/com/example/myapp/databinding/MyBindingImpl.dex

It looks like the base Binding.java files are actually getting generated but in a completely separate directory from the implementations. It seems Android Studio is not currently including the data_binding_base_class_source_out directory as a generated source location (nothing in there shows up under java (generated) in the Android Studio project view).

Without removing any of the generated files or changing any code I've now forced a gradle sync with an editor window open on the source for a fragment with references to a binding class. The fragment source immediately went from full of errors about the missing binding class back to completely normal. None of the generated files listed above have moved. The bases still don't appear listed under java (generated) in the android studio project view. Opening one of the generated binding implementations in an editor window marks several errors stemming from Cannot inherit from final 'com.example.myapp.databinding.MyBinding'.

Still not sure how to actually reproduce this state in the first place. Manually forcing gradle sync seems like a quick and easy workaround at least. Is this a bug or misconfiguration somewhere on my end?

Can you attach your IDEA.log? I've exceptions get thrown that screw up the timing and cause this to happen. Thanks!

I've attached the last third or so of the IDEA.log that covers everything from the 16th onward. I think it should fully cover the occurence from my previous comment (and I think at least one more after). I'm guessing the gradle sync that resolved it then is the one starting 2020-02-16 03:12:08. The actual issue probably started within the preceding 30 mins and I'm not seeing any exceptions in that window though are many repetitions of

INFO - abinding.index.BindingXmlIndex - BindingXmlIndex queried outside of smart mode.

both in that window and throughout. Related?

Yeah, the exception I was hoping to see isn't there. Thanks for attaching the log.

It's been very very hard to track this issue down. It's been nearly impossible to reproduce on command so far. We did some major rewriting of how caching worked, hoping it would resolve the issue once and for all, but if you're using 3.6RC3, then you already have the latest there :/.

The "BindingXmlIndex" log on its own should be harmless, although it could be pointing to some underlying issue? In IntelliJ, "smart mode" is the mode the IDE gets into when it's done indexing, because after that, it has enough information to be "smart" about things like navigation, refactoring, analysis, etc. If you're outside of smart mode, maybe that means your IDE got stuck in an indexed state or something? If you're still indexing, then definitely things like Binding classes (and many other things) aren't ready to auto-complete / resolve.

Maybe for now, could you check to see if you keep seeing that every time this issue happens? It would be nice to know if that's a real hint or a red herring.

Thank you!

Thanks for the explanation. I'll keep an eye on that log for future occurrences.

I'm attaching two brief logs of a couple restarts for comparison. Sequence of events:

1. Issue occurs again and persists after a clean & rebuild
2. Exit Android Studio
3. Launch Android Studio
4. Issue still present and persists after another clean & rebuild
5. Exit Android Studio
6. Launch Android Studio
7. Issue has resolved itself...

The first log covers 3,4,5 including the clean & rebuild @ 2020-02-18 16:31:59. The second covers 6,7. Scrolling through side-by-side beyond some slight reordering and timing variations they seem virtually identical to me.

I'm also seeing this in our project - all databinding references are not resolved after restarting the IDE or closing and opening the project. The only reliable way I've found to fix a particular Binding is to making a structural change to the layout xml, and from then it's ok for that one layout file I think.

This definitely has become a lot worse in RC3 - in earlier releases light class generation would occasionally break, but that usually coincided with the generated R class and lint also breaking for a new or modified layout file (and a restart would sort that out)

At one point I thought I'd reproduced it in a sample project, but then the behaviour disappeared and I haven't been able to reproduce it again in that project

I've attached my idea.log from a restart and opening a file referencing a generated binding. Again there doesn't seem to be much in there other than lots of

INFO - abinding.index.BindingXmlIndex - BindingXmlIndex queried outside of smart mode.

comment #8, that log is worrying. You don't have a project you can share, do you? We're having trouble reproing locally.

In RC3, we added a guard against indexing in dumb mode, since before that we had a bunch of internal reports of projects crashing with stacks like the following:

com.intellij.openapi.project.IndexNotReadyException: <elided>
	at com.intellij.openapi.project.IndexNotReadyException.create(IndexNotReadyException.java:81)
	at com.intellij.util.indexing.FileBasedIndexImpl.handleDumbMode(FileBasedIndexImpl.java:788)
	at com.intellij.util.indexing.FileBasedIndexImpl.ensureUpToDate(FileBasedIndexImpl.java:746)
	at com.intellij.util.indexing.FileBasedIndexImpl.processExceptions(FileBasedIndexImpl.java:908)
	at com.intellij.util.indexing.FileBasedIndexImpl.processValueIterator(FileBasedIndexImpl.java:984)
	at com.intellij.util.indexing.FileBasedIndexImpl.processValuesInOneFile(FileBasedIndexImpl.java:934)
	at com.intellij.util.indexing.FileBasedIndexImpl.getValues(FileBasedIndexImpl.java:815)
	at com.android.tools.idea.databinding.index.BindingXmlIndex$Companion.getDataForFile(BindingXmlIndex.kt:69)
	at com.android.tools.idea.databinding.index.BindingXmlIndex$Companion.getDataForFile(BindingXmlIndex.kt:72)

I'm not sure by aborting earlier if we ended up breaking some cases at the expensive of preventing crashes elsewhere. Until we can repro locally, I can't be sure yet what the right course of action is.

I'm afraid I can't share this project, and I still can repro in a smaller one. The issue still persists on 3.6 final and 4.0 beta 1.

One thing I noticed is that after editing the xml file, it actually seems to fix all binding classes for that gradle module, not just that one binding.

Yeah, it's definitely broken for some users, but it's hard to tell how widespread the issue is. Fundamentally, while IntelliJ is not in smart mode, it can't access the index, and when it can't access the index, it can't access all the data we need to generate data binding / view binding classes. The thing is, if IntelliJ is not in smart mode, everything else should be in a similar state (that is, IntelliJ should just act like a simple text editor). But it doesn't sound like you're seeing that behavior?