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?

I'd be very careful about that workaround (comment #13). First of all, I think that setting is lost when you sync Gradle, and second, in the cases where data binding / view binding works (it seems it might be timing sensitive?), you'll get spurious errors about multiple classes defined with the same name.

I added a demo of the bug here: https://github.com/cckroets/AS_3_6_DataBinding_Bug/tree/master

It seems to happen when you define custom resource directories like so:

android {
    defaultConfig {
        sourceSets {
            main.res.srcDirs = [
                    'src/main/res/one',
                    'src/main/res/two'
            ]
        }
    }
}

This is most likely a duplicate of https://issuetracker.google.com/issues/147609508 (at least the issue I was seeing was, that manifested the same way.) And has been fixed in Android Studio 4.0 beta 1. Try giving that a shot, it worked for me.

Regarding the smart mode question in #11 I still get functional ide editor behavior in the state when the databindings aren't registering. There's no indication to me that indexing is ongoing. Highlighting (including marking references to the binding classes in red for class not found), go to definition, etc. all work.

Also still encountering this in 3.6 final. Haven't tried the 4.0 beta. Doing a grade sync via file menu still seems mostly reliable as remedy.

That bug will still likely be broken in 4.0+, I have no idea what's going on. We're still hoping to find a repro project... :/

Hey Ben / comment #8,

My team thinks we found the bug, but it's only a guess since we still haven't been able to reproduce.

If you could do me a favor -- the next time you see the issue, make sure that the IDE stops indexing / that autocompletions work, etc., and then go to a random layout XML file, modify it (e.g. change an android:id by adding a letter to it and then deleting the letter or something), and let me know if that kickstarts your bindings working again.

Depending on your answer, I'll be more or less confident that our fix is the fix.

Thank you!! (Of course, if anyone else is seeing the BindingXmlIndex queried outside of smart mode. message in your log file, this plea is for you as well :)

Just had the issue again and the procedure described in #19 (temporarily modify a random view id in an xml) got bindings back up and running immediately.

Edit: and a second success minutes later.

Thank you! That makes me more confident in the fix.

For the curious, it seems like what's happening is...

1. Some code is trying to query our system for which Binding classes are generated
2. Due to a case that we haven't ever seen locally, this seems to be happening to some people while their IDE is in dumb mode (think, text mode; no special IDE smarts enabled)
3. When in dumb mode, because our indexes aren't ready yet, we say "There are no Binding classes right now, come back later"
4. Due to a bug (/me raises hand and points at myself), we don't realize this happened in dumb mode and cache this intermediate result
5. IDE gets out of dumb mode, but when code queries our system for Binding classes again, we tell them: "Checks the cache Sorry we have nothing"
6. When you modify an XML file, that flushes the cache out. Next time you try to interact with Bindings, we search again fresh and find everything as expected.

I have a fix for this case, and now that I know it might be the likely fix for this bug, I'm going to push as hard as I can to get it into a patch release. The biggest risk is I am not currently able to repro this problem yet on my own (outside of faking things in test code), so I can't 100% guarantee this will solve this bug once and for all. But I'll stay in touch with this bug once the fix goes out so we can confirm things one way or another.

Great news! I can also confirm that modifying a resource ID makes binding classes appear in the IDE

I've got an extra stubborn one here where one specific binding wasn't being recognized. I was clearing out old layout resources and ended up deleting a layout.xml that was actually still required. Next:

1. Following build fails and I learn the binding for that layout was still being used
2. I restore the layout.xml via git
3. The build now succeeds
4. Android Studio no longer recognizes the existence of the binding class

Android Studio is settled in smart mode, no ongoing indexing that I can determine. This one survives across:

• modifying layout resource ids
• major modifications to other unrelated layout resources
• full project clean & rebuild
• file > sync project with gradle files
• file > sync with file system
• file > invalidate cache

A subsequent Invalidate Caches and Restart has finally fixed it.

I tried to reproduce in a minimal template project by deleting and restoring a required layout.xml but no luck, the binding is recognized there immediately on file restore. Leaving that minimal template project open for an hour or two completely untouched has still eventually landed it in the "no bindings exist" state though. The modify-resource-ID solution worked immediately in this case. Is there an easy way to launch a separate instance of Android Studio with its own dedicated idea.log? I could leave the template project open and idle in the background to maybe capture a minimal log of the transition into this state...

TL;DR: the modify-resource-ID strategy isn't 100% reliable for me it seems.

ps. "Find Usages" on a layout.xml says "No usages found in All Places" when it is actually used indirectly via the binding class. "Safe delete" doesn't care either. I assume that's similarly because Android Studio doesn't consider the contents of the generated binding sources in those searches?

Comment #23 thanks for the detailed steps. I'll give it a shot momentarily and see if I can repro locally.

Comment #23, good news (probably). I was not able to repro the issue with my latest build, which hopefully means the fixes we made for other issues will fix your case too.

As for "Find Usages", actually we don't cover that case. I'll add a bug for the feature request.

Comment #26 and Comment #27, it's possible there are several different edge cases all getting lumped here, but the problem fundamentally is that caching logic in data binding changed due to a refactor in 3.6 and isn't getting reset when it should.

This is why, for those users, we recommend going into a layout XML file, modifying it and unmodifying it (find an android:id for example, then delete a letter and add it back).

We have a patch coming in the future which should alleviate many (or, with wishful thinking, all!) issues reported here. I'll ping this bug when that patch lands.

Comment #29, were you using custom res/ dirs? See also https://issuetracker.google.com/147609508 for more info.

If not, a sample project or repro steps would be very helpful for investigating.

If so, a fix for that will also be landing in the upcoming patch.

Just a heads up that a fix for this should be landing whenever the 3.6.2 patch goes out. Hopefully people can confirm or share what they're seeing at that time.

3.6.2 patch is out. Hopefully you'll find with latest that this issue is fixed. Please let me know if you're still seeing this problem. Thanks!

It's hard to remember exactly what's up in the air right now, but I'd say wait for 4.0b5 because I know some significant fixes are landing in that one for sure.

But yes, users are reporting 3.6.2 is working for them. They got the fixes before 4.0beta5 did.

Note that there's a performance issue for some users in 3.6.2 that will be getting fixed in a 3.6.3 hotfix coming out... soon? If you're working on a very large project, you may want to wait for that first, but feel free to give it a try otherwise.