It’s unreliable and basically just KitKat anyway.

This should help us keep track of flakes so they don’t only appear
when someone makes a pull request.

The tests can both generate canonical output specific to one
or more Android SDKs and compare the current output to previously
generated images to detect regressions.

Ideally we can add top level tests for most Glide functionality
using these tests to detect regression across the library without
a ton of overhead either when new tests are added or when
functionality is intentionally.

See https://goo.gl/yCdtpF for details.

Avoids errors where we forget to check if the Bitmap is recyclable 
in callers.

Glide v4.2.x crashes because of wrong executor when using a custom UncaughtExceptionPolicy.

Both Android’s Resources class and AppCompat class will cache content
they decode. If they happen to decode a Bitmap or a BitmapDrawable,
it’s not safe for Glide to recycle or re-use the Bitmap or 
BitmapDrawable because the cached entry may eventually be returned 
again. To avoid this case, we now simply avoid recycling Bitmaps and
Drawables we don’t decode directly.

The transformation uses the same logic used by the ResourceBitmapDecoder
to try to convert non-Bitmap Drawables to BitmapDrawables. Exceptions 
are thrown that will cause the load to fail if the conversion can’t happen. The primary benefit of this approach is that transformations
work similarly for the non-Bitmap Drawables that we’re now decoding. 
Unfortunately this isn’t a super efficient process, so hopefully it’s
rare. 

Android's testing frameworks seem happier if there's a binary
to test against. Without the binary running tests on Firebase
is impossible at the moment. There's also some strange
behavior with regards to resource ids of Drawables that are
included in the test apk but not the binary apk.

Creating a dummy app resolves most of these issues and
seems straight forward to maintain moving forward.

We may want to more generically handle multiple RequestListeners in the
future, but for now we can at least avoid swallowing exceptions in 
RequestFutureTarget without allocating new Lists every time a RequestListener is added.

Google’s internal build system doesn’t exactly match gradle/android studio’s behavior. The biggest compromise seems to be resource ids, which aren’t available (or at least I haven’t figured out how to get them) internally.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172791960

Also parallelizes the build a bit so that samples, the library, and the
emulator tests are built and run independently.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172750122

This also adds support for an additional Uri format that uses an integer
resource id in the path instead of a type and a name. 

We can use the default themes from Activities and/or Context wrappers
to obtain placeholder Drawables, which can be more efficient than
forcing callers to call getDrawable when building their request and more
powerful/neater than having callers pass in a Theme.

This change does NOT pass through the Context or Themes to the decoder
that loads non-Bitmap drawables on a background thread to avoid memory
leaks.

Fixes #1267.

useAnimationExecutor can lead to deadlock in scenarios where useUnlimitedSourceExecutor is required. As a result, it’s safer to 
always prefer useUnlimitedSourceExecutor.

These are only used as memory cache options, so we
can safely change the keys without invalidating
disk cache values.