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.

Fixes #2396.

More progress toward #2270.

Fixes #2462.

Previously we were obtaining the requested image size. The requested
image size is ignored in roundedCorners because the transformation 
doesn’t scale. As a result we were weirdly stretching the image with
some combinations of image and requested dimensions.

Fixes #2472.

Our normal source executor is often used to load data from networks. Glide’s default networking library runs all networking operations on Glide’s source executor. OkHttp runs the initial connection on its own
thread pool, but we still read and write the body of each request to our ache on Glide’s source executor. Even libraries like Volley that buffer
the entire request into memory will still require a few hundred milliseconds of Glide’s source executor’s time to write the request to 
cache.

Scrolling through a list of images will enqueue a large number of requests. If each request is relatively time consuming, it’s likely that
all of Glide’s source executor threads will end up blocked for 
significant periods of time, even if the longer requests are lower priority. Using a different executor for GIF frames and other animations
lets us avoid junk during playback. 

Unfortunately there is a CPU and memory hit to using an additional executor. I’ve tried to limit that here by using only one or two threads
and a cached thread pool so that few threads are created and are only
created when an animation is actually run.

Fixes #899

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

It warns when we use Target.SIZE_ORIGINAL which is currently a negative
value.

It’s perfectly possible to load a valid image or video frame from raw resources as well as drawables resources.

I've basically just added a helper method that calls thumbnail()
recursively for you. It seems like it eliminates some of the especially
confusing nested thumbnail logic.

Unfortunately it requires @SuppressWarnings("unchecked") whever it's
used because it uses varags with a parameterized type (RequestBuilder).
I can't currently use @SafeVarargs because that requires a final method.
I can't make the method final without preventing mocking in tests
(minor) and breaking the generated API (major). By splitting out a
separate base class for RequestBuilder I actually probably can fix this
in the future, but that's a pretty substantial change that I don't want
to make right now.

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

This should also be a slight accuracy improvement since we're now using
a somewhat more efficient density multiplier in some cases, especially
when downsampling.

Fixes #2459.

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