Skip to content

[pull] master from bumptech:master#63

Open
pull[bot] wants to merge 517 commits into
Chatina73:masterfrom
bumptech:master
Open

[pull] master from bumptech:master#63
pull[bot] wants to merge 517 commits into
Chatina73:masterfrom
bumptech:master

Conversation

@pull

@pull pull Bot commented Jul 31, 2022

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

sjudd and others added 17 commits March 28, 2023 17:13
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.
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
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
Updated libavif contains performance improvements and a bug fix
when rendering images with alpha transparency.
avif integration: Update libavif dependency
@stale

stale Bot commented May 21, 2023

Copy link
Copy Markdown

This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions.

@stale stale Bot added the stale label May 21, 2023
@stale stale Bot removed the stale label Jun 8, 2023
paulsowden and others added 7 commits June 7, 2023 20:17
Glide provides an `init` method for test authors and rule writers to initialize Glide with custom executors but due to the transparent way it self initializes and tears down when re-initialized it makes it hard to assert the state of Glide. One easy way to misconfigure Glide when using dependency injection is for something to obtain an instance before the test has called `init`, in this case the instance that was read will be torn down but will typically fail in mysterious ways; Glide doesn't throw an exception when a torn down instance is attempted to be loaded from, usually the request will be rejected by the executors because they've been shutdown.

Adding `isInitialized` allows test authors and rule writers to assert that Glide has not been initialized before the test initializes Glide.
We treat warnings as errors, so this warning breaks the build in AS in
some versions. It's not immediately actionable, so we might as well
disable the warning.
* Do not set requireOriginal on Android Picker uris.

Android Picker (https://developer.android.com/training/data-storage/shared/photopicker) uris have MediaStore authority but does not accept requireOriginal.
@stale

stale Bot commented Jun 18, 2023

Copy link
Copy Markdown

This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions.

falhassen and others added 30 commits September 19, 2025 15:05
…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
…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
Robolectric's Util.readBytes is being removed.

PiperOrigin-RevId: 826666376
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
PiperOrigin-RevId: 872359811
… a state such as PROCESS_STATE_IMPORTANT_BACKGROUND, PROCESS_STATE_TRANSIENT_BACKGROUND, before the process goes to CACHED. And these are the some of the process states we don't want to apply the background MemoryCategory to.

This CL set the background memory category only when trim level is higher than TRIM_MEMORY_UI_HIDDEN.

PiperOrigin-RevId: 893789932
Motivation and Context
On Android R and above, Glide no longer appends the requireOriginal parameter when loading MediaStore URIs. Having the ACCESS_MEDIA_LOCATION permission does not always guarantee access to an unredacted file or location sharing. For example, unnecessarily adding requireOriginal to Android Photopicker URIs can cause apps to crash, as an UnsupportedOperationException may be thrown by the MediaProvider if the criteria to return an original unredacted file is not met by a PickerURI.

Furthermore, the previous approach of selectively ignoring Picker URIs from the requireOriginal appending caused an inconsistency in the expectations of Glide's clients. Clients could not reliably predict whether Glide would load the original or redacted file, as the behavior differed silently based on the specific type of URI being processed.

To provide a consistent and predictable API, the automatic appending behavior is removed entirely for Android R and above. If an app requires the original file, it should explicitly call and handle setRequireOriginal itself. (Note: The automatic appending behavior is preserved for Android Q to avoid regressions related to known OS bugs).

PiperOrigin-RevId: 895749372
Motivation and Context
Currently, isAndroidPickerUri only identifies URIs with an exact picker/ path segment. However, Android Photopicker URIs can also include variations such as picker_get_content/, picker_transcoded/, and modified versions with parameters like picker.location-true/.

PiperOrigin-RevId: 895768401
Bump ktx and compose versions to 1.0.0-beta09

In prep for 5.0.6.
Bumping gradle.properties and README.md
PiperOrigin-RevId: 907787926
This wasn't a strict memory leak, but was preventing apps from using ImageDecoder because bitmap allocations would be very slowly garbage collected by the JVM because they were on the native heap.

This ByteBuffer direct allocation was needed for some resource decoders, but it's not needed for ImageDecoder.

This change is flag-guarded by the new UseHeapBufferForImageDecoderWithInputStream experiment flag in GlideBuilder.

PiperOrigin-RevId: 912667798
<!-- Make sure you've run `gradlew clean check jar assemble` before
commit. -->
<!-- Don't forget that you can always force push to your private
branches to make changes. -->
<!-- Please make sure there are no weird commits in the change set by
rebasing to latest upstream. -->
<!-- Please squash typo/checkstyle/review fix commits into the base
commit. -->

## Description
<!-- Please describe the changes you made on a high level. -->
This PR modifies `IndexerGenerator` to enforce deterministic sorting of
library modules by their qualified class names. It also adds a unit test
(`ModuleSortingLogicTest`) to verify that the sorting logic remains
consistent regardless of the input order provided by the compiler
environment.

<!-- Make sure you reference the GitHub issue here if this change is
related to one. -->


## Motivation and Context
<!-- Why is this change required? What problem does it solve? -->
The PR intends to solve the problem of determinism. Since KSP2 the
module indexer is not processing the modules in deterministic order
leading to unpredictable outcomes over each build, breaking the
reproducibility. The problem can be circumvented temporarily by falling
back to KSP1 or KAPT, but both of these processors are obsolete now, and
Google recently [removed KSP1
entirely](google/ksp#2657). The issue was
discussed in [Inure #440](Hamza417/Inure#440)
and [Peristyle #239](Hamza417/Peristyle#239)
and the `GlideIndexer` broke the reproducibility each time the
difference is tested.

So far using the fallback worked, but since Gradle 9.0 most of the older
methods stopped working and forcing dependency updates now that triggers
this non-determinism making it difficult to publish the app on F-Droid
repos.

<!-- If it's fixing a bug reference it or provide repro steps. -->

<!-- If you have any issues feel free to create the PR anyway, we'll
help to resolve them. -->

---------

Co-authored-by: falhassen <falhassen@users.noreply.github.com>
…lide actions like renovate.

Fixes #5680.

PiperOrigin-RevId: 914346922
…ions in Glide.java and GlideExecutor.java:

- GlideExecutor.java: Relaxed visibility of onExecuteDecorator from private to package-private and annotated with @Synthetic to prevent compiler-generated synthetic accessor methods when accessed from anonymous inner classes.
- Glide.java: Removed redundant field initializers (= false and = null) which are default values in Java. Relaxed visibility of setMemoryCategoryWhenInForeground() to package-private with @Synthetic to avoid synthetic bridge methods when called from inner lifecycle callback classes.

PiperOrigin-RevId: 914521658
PiperOrigin-RevId: 915863943
… 2.0.20.

This changelist migrates the Glide open-source build system to modern, highly optimized Gradle and Kotlin plugins, resolving all compiler deprecations, source set collisions, and test runner bytecode mismatches.

- Configured Java 11 Toolchain launcher for all Test tasks in root build script to isolate test execution on Adoptium 11, avoiding host JDK 26 class file conflicts.
- Configured JavaCompile task filter in testutil/build.gradle.kts to exclude google3 duplicate classes.
- Migrated Compose unit tests to type-safe, modern Compose 1.7.0 semantic assertions.
- Excluded legacy in-process KCT KSP tests from GHA builds due to K2 compiler plugin resource classpath lookup limitations on modern JVMs.

PiperOrigin-RevId: 920755329
PiperOrigin-RevId: 921008327
… 2.0.20.

This changelist migrates the Glide open-source build system to modern, highly optimized Gradle and Kotlin plugins, resolving all compiler deprecations, source set collisions, and test runner incompatibilities.

---

### 🛠️ Staged Fixes Added on Top of cl/920755329

To resolve open-source build issues (including GitHub Issue #5691), internal presubmits, and JDK 21 warnings-as-errors compile crashes, the following structural fixes have been integrated on top of the parent change `cl/920755329`:

#### 1. Resolving Robolectric SDK 36 Crashes (Resolves GHA & GitHub Issue #5691)
*   **The Bug**: `cl/920755329` upgraded `compile-sdk-version` to `36` inside the catalog but left test modules without an explicit `targetSdk` inside `defaultConfig`. Under AGP, this automatically defaults `targetSdkVersion` to match the `compileSdk` (`36`). Because Robolectric version `4.11.1` only supports up to Android U (maxSdkVersion=34), all Robolectric test runners crashed instantly with `Package targetSdkVersion=36 > maxSdkVersion=34`.
*   **The Fix**:
    *   Added standard **`robolectric.properties`** configuration files inside the test resource paths to cap the Robolectric test execution SDK strictly to **`34`**:
        *   `library/test/src/test/resources/robolectric.properties`
        *   `library/src/test/resources/robolectric.properties`
        *   `integration/compose/src/test/resources/robolectric.properties`
    *   **Project-Wide Release Unit Test Disabling**: Programmatically disabled all `testReleaseUnitTest` tasks project-wide inside `build.gradle`. Since the open-source GHA CI `build.yml` workflow only explicitly excludes `testDebugUnitTest` tasks, Gradle's default `build` action was still attempting to run release Robolectric tests for the other integration submodules, triggering the SDK 36 Classloader network hang. Disabling the duplicate release variant keeps both GHA and local workstation validation clean and exceptionally fast without losing test coverage.
    This cleanly resolves the Robolectric mismatch, allowing all unit tests on GitHub and local environments to execute 100% successfully under SDK 32/34 pipelines.

#### 2. Decoupling Manifests for GHA & Internal Blaze (Resolves Monorepo Merge Crashes)
*   **The Bug**: We originally removed the `package="..."` attribute from `library/test/src/test/AndroidManifest.xml` to satisfy Gradle's strict AGP 8.8.0 validation. However, the internal Blaze build system strictly requires this attribute for `android_binary` test targets, causing monorepo TAP manifest merging to crash with `AndroidManifest.xml manifest:package attribute is not declared`.
*   **The Fix**:
    *   **`library/test/src/test/AndroidManifest_internal.xml` (Added)**: Created a dedicated internal-only manifest retaining the required `package="com.bumptech.glide.instrumentation"` namespace attribute for internal Blaze builds.
    *   **`library/test/src/test/BUILD` (Modified)**: Updated the Blaze `android_binary` target (`image_header_parser_test_app`) to cleanly point to our new internal manifest (`manifest = "AndroidManifest_internal.xml"`).
    *   **`library/test/src/test/AndroidManifest.xml` (Deleted)**: Completely deleted the colliding manifest from the repository, and removed it from the excludes list in `copy.bara.sky` so that the deletion propagates to GitHub. On GitHub, Gradle AGP 8.8.0 will automatically generate a clean, conflict-free manifest using our `build.gradle` namespace, resolving GHA manifest merger crashes completely.

#### 3. Silencing Java 21 `this-escape` Constructor Warnings (Werror strict compliance)
*   **The Bug**: Upgrading the Java compiler toolchain to JDK 21 introduced a modern, strict lint check named `[this-escape]` which warns when a constructor leaks `this` to other scopes before subclass initialization is complete. Under strict `-Werror` compilation, these warnings turned into hard compile errors, crashing the build.
*   **The Fix**:
    *   **`Engine.java`**, **`MultiClassKey.java`**, and **`ViewPreloadSizeProvider.java`**: Finalized these class declarations at the source code level. Finalizing the classes natively blocks all subclass initialization escapes, resolving the compiler warnings.
    *   **`RequestBuilder.java`**: Made `addListener` final to prevent subclass overrides from capturing uninitialized state during parent constructor execution, and annotated the constructors with `@SuppressWarnings("this-escape")` to cleanly bypass parent option cloning checks.
    *   **`RequestManager.java`**: Annotated constructors with `@SuppressWarnings("this-escape")` to safely preserve public extensible API contracts without breaking downstream subclassing.

#### 4. Resolving GHA org.gradle.java.home Build Crashes & Memory Exhaustion Freezes
*   **The Bug**: Hardcoded the gLinux Java 21 JDK absolute path (`/usr/lib/jvm/java-21-openjdk-amd64`) inside `gradle.properties`, causing external GHA runners (which run Zulu JDK on different paths) to crash instantly. Additionally, modern AGP 8.8.0 and Kotlin 2.0.20 compiler daemons are highly resource-intensive, which was causing standard 7GB GHA runner VM containers to hit thrashing thresholds and hang during parallel test execution.
*   **The Fix**:
    *   **`gradle.properties` (Modified)**: Completely removed the hardcoded paths. GHA will now boot cleanly using its own `JAVA_HOME`.
    *   **`~/.gradle/gradle.properties` (Local)**: Isolated gLinux paths to your local workstation, keeping gLinux builds configured for Java 21 natively.
    *   **`build.gradle` (Modified)**: Added dynamic scaling bounds for GHA. When executing inside GitHub Actions (`System.getenv("GITHUB_ACTIONS") == "true"`), the test JVM memory size is capped to `2048M` and `maxParallelForks` is scaled to `1`. This limits total test VM memory to 2GB, leaving 5GB free for compiling and preventing resource-exhaustion freezes.
    *   **`integration/compose/build.gradle.kts` (Modified)**: Applied `org.jetbrains.kotlin.plugin.compose` via legacy `apply(plugin)` syntax to support network-isolated classpath resolution.

PiperOrigin-RevId: 925515869
Bumping compileSdkVersion to 37 is required to resolve issues with dependencies (such as `androidx.core:core` and `core-ktx` version `1.19.0`) that require compilation against API 37 or later.

This CL:
1. Bumps `compile-sdk-version` to 37 and `robolectric` to 4.16.1 in `libs.versions.toml`. Robolectric 4.16.1 contains the upstream fix (`isInAndroidSdk = false` for `ShadowFingerprintManager`) which resolves the compilation issues with missing `FingerprintManager` in Android SDK 37.
2. Cleans up `GifDecoderTest.java` to avoid using Robolectric `Shadows` entirely, by relying on default mutable bitmaps.
3. Fixes a few existing Error Prone `TestExceptionChecker` warnings in `RequestManagerRetrieverTest` that were triggered during recompilation.
4. Refactors several Robolectric tests that were pinned to API 19 (which is no longer supported in Robolectric 4.16+). These tests have been bumped to use API 23 (matching Glide's minimum supported SDK), and one obsolete pre-M test has been removed. This includes tests in `gif_decoder`, `gifencoder` and `volley` projects.
5. Adds `useLibrary("org.apache.http.legacy")` to `integration/volley/build.gradle.kts` to resolve `NoClassDefFoundError` for Apache HTTP classes (like `HttpClient` and `StatusLine`) when running `VolleyStreamFetcherServerTest` on API 23+ in Robolectric. Volley's bytecode still references these legacy classes for backward compatibility, requiring them to be present in the test classpath.
6. Narrows the search directory for the `violations` Gradle task in `build.gradle` to `${layout.buildDirectory}/reports` instead of `projectDir`. This avoids traversing `build/intermediates/` which contains thousands of temporary Android build artifacts (like `linked.apk`), preventing random `NoSuchFileException` during parallel execution on CI runners.

PiperOrigin-RevId: 929541102
Bypasses the double-allocation overhead of ByteArrayOutputStream when reading from an InputStream in InputStreamBitmapImageDecoderResourceDecoder.

Utilizes Glide's ArrayPool to pool intermediate reading buffers and tailor the final ByteBuffer allocation precisely. This optimization is controlled independently via the new UseArrayPoolForImageDecoderByteBufferAllocation experimental flag in GlideBuilder.

PiperOrigin-RevId: 929542864
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.