[pull] master from bumptech:master #63
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some devices, IE Pixel devices, will return p3. Others seem to default to SRGB. Allowing either isn't great, but still in line with the spirit of the test and better than spurious failures depending on which device the test is running on. PiperOrigin-RevId: 516284810
Glide.tearDown() already clears the disk cache, so we shouldn't need to do it a second time. PiperOrigin-RevId: 516325186
Right now this test relies on the fact that we happen to attempt to decode Bitmaps before BitmapDrawables. If we were instead to decode BitmapDrawables first, the test would fail because the FailEncoder we register would never be called. To make the test more robust to order changes, I've registered an encoder for both BitmapDrawable and Bitmap, which are the two types we could plausibly decode here. I've also removed some duplicate code by moving the initialization step for two of the test methods into a shared method. PiperOrigin-RevId: 516326606
These need to be bumped separately because we're not currently doing dot releases the way we are with the rest of Glide. The rest of Glide can just use 4.15.1, but we don't want to add the complexity of 1.0.0-alpha.3.1, so we have to bump the version with each dot release. PiperOrigin-RevId: 516360517
PiperOrigin-RevId: 516372431
PiperOrigin-RevId: 516429261
PiperOrigin-RevId: 516867999
ChromiumRequestSerializer creates an single thread executor for executing callbacks from cronet. In tests, we want to track all threads related to Glide and cronet through ActiveResource, so that the test result is deterministic. So we pass an active resource thread pool executor to ChromiumRequestSerializer, and the active resource will be tracked by ActiveResourceRule. PiperOrigin-RevId: 518069577
PiperOrigin-RevId: 518657355
I'm not sure how I managed to update this to a newer version without breaking the build, but it now appears to be broken. 1.5+ and I think 1.4+ require the usage of java8's desugaring. Glide's v4 doesn't currently do this, so we need to stay on an older version of the Fragment libraries. Fixes #5086 PiperOrigin-RevId: 519745378
PiperOrigin-RevId: 519774232
PiperOrigin-RevId: 520143565
PiperOrigin-RevId: 520149888
PiperOrigin-RevId: 520151194
For a while we've stripped some experimental methods when they're exported to GitHub. This prevents them from being included in a public release, which in turn prevents them from causing binary incompatibility issues between different versions of Glide if the methods are misused. However it also creates a maintenance burden where the internal and external versions of Glide are not the same. It adds some confusion for external developers because necessarily some number of useless classes, imports or variables are left in the exported version. Rather than rely on explicit stripping, we'll instead document and deprecate the experimental methods and continue to remove them when they're no longer useful. This is more transparent and easier to maintain, at the risk of some additional binary incompatibility issues in the future. Given that it's very unlikely that people will use these methods, especially in libraries, this seems like an ok tradeoff. PiperOrigin-RevId: 520157449
This class helps avoid some issues with hardware Bitmaps on Android O and P. It's been in use in production internally for a while for these older devices. Even if we don't use it on Q+ and we decide there are too many bugs with hardware Bitmaps on O, it's still useful to enable on P devices. PiperOrigin-RevId: 520157997
PiperOrigin-RevId: 520166967
PiperOrigin-RevId: 520172603
Glide is now built with GitHub actions, not travis-ci. PiperOrigin-RevId: 520176732
PiperOrigin-RevId: 520180505
PiperOrigin-RevId: 520201631
Prior to this change, the build fails because dokka fails to find the dokka task on a bunch of submodules. That's happening because we deliberately disabled the dokka task on irrelevant submodules. I have no idea how this worked originally. I even went back to my original commit (e5a29be) and tried building with dokka and it failed. But clearly 4.14's javadocs on the website were built with dokka. The fix seems to be to always add the dokka task, but to simply set it to disabled for submodules that aren't useful for developers. That's a relatively minor change that I've made here.
PiperOrigin-RevId: 520364928
PiperOrigin-RevId: 520393656
PiperOrigin-RevId: 520411345
getContext was only introduced in a newer API. getActivity has been around for a while. Fixes #5107 PiperOrigin-RevId: 520431972
Several of these are lint warnings that are properly checked, but there's at least one registry call that would allow the use of newer methods on an older API. I haven't yet seen any issue that results from that and this isn't new code, but we still should add the correct SDK check in RegistryFactory. Progress towards #5108 PiperOrigin-RevId: 520436921
Fixes #5091 PiperOrigin-RevId: 520518296
In particular: 1. Rename AppGlideModuleOnlyTests to OnlyAppGlideModuleTests so the class and file name are consistent 2. Move the 'simpleAppGlideModule' string into the SourceTestHelpers so it can be shared across tests without explicit cross-test dependencies. PiperOrigin-RevId: 521040266
## Description Bumping version to 5.0.0-rc02 ## Motivation and Context To tag --------- Co-authored-by: Ivan Melnikov <ivanempire@gmail.com>
Bump version to 5.0.0-rc04 We need the tag to match
PiperOrigin-RevId: 801078725
Bump version to 5.0.0-rc05
This should fix #5580 this time.
Bump version to 5.0.2
Fix gif_decoder publishing dep and Bump compose and ktx
Bump version to 5.0.3
Bump version to 5.0.4. Need to fix missing compiler dep in 5.0.3. See #5591
…with IPV6 addresses #5444 PiperOrigin-RevId: 805434429
PiperOrigin-RevId: 805978985
Bump ktx and compose versions to 1.0.0-beta08 In prep for 5.0.5.
Bump version to 5.0.5
… a decorator to all Runnables executed on that executor. PiperOrigin-RevId: 807916271
…. Triggers and logic are all the same as before, we're just doing everything through workflow files now to leverage caching. PiperOrigin-RevId: 809159300
PiperOrigin-RevId: 809203260
…tLock. This occurs because CallResourceReady only acquires 2/3 of the necessary locks to perform its runnable (SingleRequest.requestLock & EngineJob.this), and is missing the Engine.this lock. In this change, I changed SingleRequest.requestLock to always be Engine.this. Note that change only affects uses of SingleRequest built through RequestBuilder. Users of the public API SingleRequest.obtain are unaffected by this change. If this fix works as intended, we can consider providing a new SingleRequest.obtain API with the requestLock param removed and deprecating the current SingleRequest.obtain. PiperOrigin-RevId: 817821083
PiperOrigin-RevId: 818023760
…ttings.gradle` file in Kotlin DSL to kick off the process. Removed `git exec` command since we no longer have submodules. PiperOrigin-RevId: 820305020
…rst time. Will be cleaning up the `apply` blocks once we move to Kotlin DSL. PiperOrigin-RevId: 823192053
…. This will help with version management since everything is now in one place. PiperOrigin-RevId: 823245115
PiperOrigin-RevId: 826616347
Robolectric's Util.readBytes is being removed. PiperOrigin-RevId: 826666376
PiperOrigin-RevId: 829157965
When an app is moved to background, onTrimMemory() will be called, and LruBitmapPool/MemoryCache will be trimmed. However, the app could keep running and will new bitmaps will be retired to MemoryCache and LruBitmapPool. This change limits the sizes of LruBitmapPool/MemoryCache to zero when the app is in background, and restore the sizes to normal when it's moved out of background. We introduce an experimental API `setMemoryCategoryInBackground(MemoryCategory)` for this purpose, as well as a new `MemoryCategory.ZERO` for no pooling/caching. App can use this API to set the MemoryCategory to limit the pool/cache size when the app is in background. PiperOrigin-RevId: 852864309
PiperOrigin-RevId: 852944433
When an app is moved to background, onTrimMemory() will be called, and LruBitmapPool/MemoryCache will be trimmed. However, the app could keep running and will new bitmaps will be retired to MemoryCache and LruBitmapPool. This change limits the sizes of LruBitmapPool/MemoryCache to zero when the app is in background, and restore the sizes to normal when it's moved out of background. We introduce an experimental API `setMemoryCategoryInBackground(MemoryCategory)` for this purpose, as well as a new `MemoryCategory.ZERO` for no pooling/caching. App can use this API to set the MemoryCategory to limit the pool/cache size when the app is in background. PiperOrigin-RevId: 856285259
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )