- 31 10月, 2017 2 次提交
- 30 10月, 2017 3 次提交
- 29 10月, 2017 5 次提交
-
-
由 Sam Judd 提交于
It’s unreliable and basically just KitKat anyway.
-
由 Sam Judd 提交于
This should help us keep track of flakes so they don’t only appear when someone makes a pull request.
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
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.
-
- 27 10月, 2017 1 次提交
-
-
由 Sam Judd 提交于
-
- 26 10月, 2017 2 次提交
- 25 10月, 2017 2 次提交
- 24 10月, 2017 4 次提交
-
-
由 Sam Judd 提交于
See https://goo.gl/yCdtpF for details.
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
Avoids errors where we forget to check if the Bitmap is recyclable in callers.
-
由 Stéphane Nicolas 提交于
Glide v4.2.x crashes because of wrong executor when using a custom UncaughtExceptionPolicy.
-
- 23 10月, 2017 8 次提交
-
-
由 Sam Judd 提交于
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.
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
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.
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
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.
-
由 Sam Judd 提交于
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.
-
- 21 10月, 2017 5 次提交
-
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
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.
-
由 judds 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=172791960
-
由 Sam Judd 提交于
Also parallelizes the build a bit so that samples, the library, and the emulator tests are built and run independently.
-
- 20 10月, 2017 2 次提交
-
-
由 Sam Judd 提交于
-
由 pkorth 提交于
------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=172750122
-
- 19 10月, 2017 3 次提交
- 18 10月, 2017 3 次提交
-
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
-
由 Sam Judd 提交于
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.
-