5 Commits

Author SHA1 Message Date
afohrman
10fa73def7 Remove unnecessary looper calls in TextInputLayout's ViewActions.
Espresso does not need the uiController.loopMainThreadUntilIdle() calls, so I removed them. Verified that removing these calls didn't add flakiness by running them with --runs_per_test=100.

PiperOrigin-RevId: 161989235
2017-09-21 11:57:37 -04:00
afohrman
127dfe1255 Add graceful degradation for character counter and label text overflow color.
Previously, the character counter and label overflow color ended up as Color.MAGENTA, which actually is a sickly pink color. This appears to have been happening when the theme doesn't extend from Theme.Design, and therefore doesn't have textErrorColor. On API 23 and above, it gets set to MAGENTA instead of throwing an exception. The only reason this pink color was being used for the character counter and not the error text is because there already a fix for the error text - it just wasn't applied to the character counter.

I pulled the logic for the fix out to make this graceful degradation code reusable for both error and character text, and for future situations like this.

PiperOrigin-RevId: 159229718
2017-09-21 11:23:47 -04:00
Tenghui Zhu
c82b5dd94b Mark mediumTest for TextInputLayout's test
Test: both TextInputLayout*Test
Bug: 34767250
Change-Id: I56a8f3ecb1dc2e77d4e9f5ebe02e866093db0cff

PiperOrigin-RevId: 147117094
2017-03-14 17:20:37 -07:00
Alan Viverette
8b7af4099b Fix TextInputLayout's hint not expanding
Happens when the EditText is populated with
text from the layout, etc. Caused by some
state being set wrong in the constructor,
which makes the proceeding state update
no-op, since it thinks it is already in the
state.

BUG: 33585556
Test: included
Change-Id: I34c6e9aca3c41f864974ad32fcdbb6dc829645b8

PiperOrigin-RevId: 147067802
2017-02-09 17:32:24 -08:00
travisc
69a70219ad Restructure emulator tests for better bazel support.
Bazel wants a structure where the application used for testing and the tests themselves are in separate packages (which gradle is less picky about). Android has a gradle plugin for this setup (com.android.test), although it unfortunately has seemingly worse Android Studio support at this point. In any case, this change splits the code up a bit more, into 3 parts:

- lib: the files we actually distribute as a library to end users
- testing: the test application and its custom component subclasses that are tested by the emulator tests
- tests: the actual emulator test code

The structure is a tad strange for typical gradle projects (testing in particular, which has a build.gradle file for each individual Java package, at the same level as the actual source files), but it better matches the conventions of bazel while also avoiding the need for a ton of parallel directory structures at the top level.

Known issues as of this commit:
- Android Studio doesn't think the Java files in testing/ have the right package. I tried to fix this by bumping their java srcDir up to the java/ root and changing the includes, but Android studio seems unable to properly figure that out and instead acted like the Java files didn't exist at all, so I reverted that. We can possibly modify the iml files that get generated, but I'll save this for a follow-up commit since this is already very large.

- Android Studio seems unable to run emulator tests properly (but they work from the command-line). I don't quite know why they fail, but seems like lacking support for the com.android.test plugin. Hopefully this is something we can work around for find a fix for in the near future.

PiperOrigin-RevId: 146940681
2017-02-08 12:53:34 -08:00