commit 7d86bdb311c9538e860447ce5e409b57b7b941a5
author David Herman <davidherman@google.com> Tue Feb 12 18:37:11 2019 -0800
committer David Herman <davidherman@google.com> Sat Feb 16 09:22:56 2019 -0800
tree 96b94432fa9dcb20d9b40010c944c3866ae24408
parent f16d39a0ffb1757f6c648e70a29633f89f666a69

Skip over generated code when creating BR constants

Normally, a field that's marked with @Bindable has an
associated BR constant created for it, e.g.

  @Bindable
  public int mDemo;

will create an associated

  class BR {
    ...
    demo = 234;
    ...
  }

constant.

However, variables defined in layout XMLs will also generate
a BR constant. That is,

  <variable name="demo2" ... />

will similarly generate a 'BR.demo2' constant.

However, trouble happens because XML variables also generate
@Binding fields, although their name may get transformed to
follow standard Java camel-case naming conventions.

So, this:

  <variable name="snake_case_var" ... />

will generate this:

  class BR {
    ...
    snake_case_var = 123;
    ...
  }

as well as this:

@Generated({"Android Data Binding"})
class DemoBinding {
  @Bindable
  mSnakeCaseVar;
}

which in turn generates this:

  class BR {
     ...
     snakeCaseVar = 567;
     ...
  }

This latter constant is particularly problematic because it
doesn't actually get used in code generated by data binding.

In practice, this case should be pretty rare. As such, we
fix the bug by skipping over generated classes when searching
for @Bindable annotations from which to generate BR constants.

Change-Id: I06c6fba165809c42701955ff6485517ba0014ed6
Fixes: 124076237
Test: Covered by existing tests