[Android] Fix excessive memory usage for stream and resource-based image loading

[Shalini-Ashokan]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue Details

Stream-based and resource-based image loading consumed excessive memory on Android versus XAML image loading. Images were loaded at display dimensions instead of original dimensions, affecting all apps using embedded resources or streams.

Root Cause

Glide upscaled stream-based images to display dimensions without size constraints. XAML had proper size handling, but stream loading lacked overrides, causing memory to scale with screen size not image size.

Description of Change

Added size override in PlatformInterop.java to preserve original image dimensions. This prevents upscaling to display dimensions, making all loading methods produce consistent memory usage.

Validated the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #33239

Output ScreenShot

Before	After

[dotnet-policy-service]

Hey there @@Shalini-Ashokan! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[sheiksyedm]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[Copilot]

Pull request overview

This PR fixes excessive memory usage when loading images from streams or resources on Android by preventing Glide from upscaling images to display dimensions. The fix adds override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to stream-based image loading paths in PlatformInterop.java, ensuring images maintain their original dimensions rather than being scaled to match the display size.

Changes:

• Added size override to loadImageFromStream methods to prevent Glide upscaling
• Created UI test to verify image byte count remains reasonable for stream-based loading
• Created test page demonstrating the issue with embedded resource image loading

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/Core/AndroidNative/maui/src/main/java/com/microsoft/maui/PlatformInterop.java	Added .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to both loadImageFromStream methods to prevent image upscaling
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33239.cs	Added Android-specific UI test verifying image byte count after loading from resource
src/Controls/tests/TestCases.HostApp/Issues/Issue33239.cs	Added test page with embedded resource image and button to measure bitmap memory usage

[Copilot]

The hard-coded byte count value (786432) in this assertion is brittle and may cause test failures across different devices or Android versions. The actual byte count can vary based on bitmap configuration, pixel density, or image decoding behavior. Consider using a range check or verifying that the byte count is within a reasonable threshold of the expected original image dimensions instead of an exact match.

Suggested change

	Assert.That(resultText, Is.EqualTo("Image ByteCount: 786432"));
	var prefix = "Image ByteCount: ";
	Assert.That(resultText, Does.StartWith(prefix), "Result text did not start with the expected prefix.");
	var byteCountText = resultText.Substring(prefix.Length).Trim();
	if (!int.TryParse(byteCountText, out var byteCount))
	{
	Assert.Fail($"Unable to parse byte count from result text: '{resultText}'");
	}
	const int expectedByteCount = 786432;
	var tolerance = (int)(expectedByteCount * 0.2); // allow 20% variance
	Assert.That(
	byteCount,
	Is.InRange(expectedByteCount - tolerance, expectedByteCount + tolerance),
	$"Expected image byte count to be within ±{tolerance} of {expectedByteCount}, but was {byteCount}.");

[sheiksyedm]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Modified the test cases · eb7bec7

---

Issue: #33239 - [Android] Unexpected high Bitmap.ByteCount when loading image via ImageSource.FromResource() or ImageSource.FromStream() in .NET MAUI
PR: #33590 - [Android] Fix excessive memory usage for stream and resource-based image loading
Author: Shalini-Ashokan (community contributor, partner/syncfusion)
Platforms Affected: Android only
Files Changed: 1 fix file, 2 test files, 1 snapshot file

Issue Summary

On Android, loading images via ImageSource.FromResource() or ImageSource.FromStream() caused ~25MB Bitmap.ByteCount vs ~1MB for XAML-referenced images. Root cause: Glide (Android image loading library) upscaled stream-based images to display dimensions without size constraints, while XAML image loading had proper size handling.

Fix Approach

Added .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to both loadImageFromStream methods in PlatformInterop.java. This prevents Glide from upscaling images to display size, keeping them at their original dimensions.

Files Changed

Fix files:

• src/Core/AndroidNative/maui/src/main/java/com/microsoft/maui/PlatformInterop.java (+4/-2) — Two loadImageFromStream methods updated

Test files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue33239.cs (+106) — New HostApp page with embedded resource image and byte count measurement
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33239.cs (+25) — Android UI test asserting resource ByteCount equals file ByteCount
• src/Controls/tests/TestCases.Android.Tests/snapshots/android/DownSizeImageAppearProperly.png — Modified snapshot

Prior Review Note

A prior agent review (at commit 4a23114) requested changes due to a hardcoded byte count value (786432) in the test assertion. The author has since updated the test to compare resource image ByteCount vs file image ByteCount directly (Assert.That(resource, Is.EqualTo(file))), which is device-independent and more robust.

Reviewer Feedback

• copilot-pull-request-reviewer previously flagged hardcoded byte count — RESOLVED by author's test update
• Test change in current commit: now compares ResourceImageLabel vs FileImageLabel text, not hardcoded value

Disagreements / Open Questions

None — prior issues resolved.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33590	Add .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to both loadImageFromStream methods in PlatformInterop.java	⏳ PENDING (Gate)	PlatformInterop.java (+4/-2)	Original PR

---

🚦 Gate — Test Verification

---

📝 Review Session — Modified the test cases · eb7bec7

---

Result: ✅ PASSED
Platform: android
Mode: Full Verification (RequireFullVerification)
TestFilter: Issue33239

• Tests FAIL without fix ✅ (bug detected correctly)
• Tests PASS with fix ✅ (fix works correctly)

Fix Files Detected:

• src/Core/AndroidNative/maui/src/main/java/com/microsoft/maui/PlatformInterop.java

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Modified the test cases · eb7bec7

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-sonnet-4.5)	.centerInside() transformation on both loadImageFromStream methods	✅ PASS	PlatformInterop.java (+2/-2)	Prevents upscaling via transformation layer
2	try-fix (claude-opus-4.6)	.downsample(DownsampleStrategy.NONE) on both loadImageFromStream methods	✅ PASS	PlatformInterop.java (+3/-2)	Disables decode-level upsampling entirely
3	try-fix (gpt-5.2)	.downsample(DownsampleStrategy.AT_MOST) on both loadImageFromStream methods	✅ PASS	PlatformInterop.java (+3/-2)	Prevents upscaling; allows downscaling
4	try-fix (gpt-5.2-codex)	Read stream to byte[], decode bounds, override with explicit width/height	✅ PASS	PlatformInterop.java (~60 lines)	Bypasses view size measurement; very invasive
5	try-fix (gemini-3-pro-preview)	.downsample(DownsampleStrategy.CENTER_INSIDE) on both loadImageFromStream methods	✅ PASS	PlatformInterop.java (+3/-2)	Prevents upscaling; allows downscaling; semantically clear
6	try-fix (gpt-5.2)	Downsampler.FIX_BITMAP_SIZE_TO_REQUESTED_DIMENSIONS=false	❌ FAIL	PlatformInterop.java (+4/-2)	Deep Glide internal; doesn't affect this decode path
PR	PR #33590	.override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) on both loadImageFromStream methods	✅ PASS (Gate)	PlatformInterop.java (+4/-2)	Original PR fix; consistent with loadImageFromFont pattern in same file

Cross-Pollination Summary (Round 2)

Model	Response
claude-sonnet-4.5	Suggested thumbnail/format/cache ideas but concluded NO NEW IDEAS worth pursuing
claude-opus-4.6	NO NEW IDEAS — confirmed the Glide API surface is exhausted
gpt-5.2	NEW IDEA: DISABLE_BITMAP_POOL — tangential (controls memory reuse, not decode size)
gpt-5.2-codex	NEW IDEA: .disallowHardwareConfig() — unrelated to decode-phase upscaling
gemini-3-pro-preview	NO NEW IDEAS

Exhausted: Yes — remaining suggestions are tangential to decode-phase upscaling and won't yield better results.

Selected Fix: PR's fix — .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL)

Reason: The PR's fix uses the same pattern as loadImageFromFont already uses in PlatformInterop.java, maintaining internal consistency. It is semantically explicit ("load at original dimensions") and directly addresses the root cause. While DownsampleStrategy.CENTER_INSIDE or AT_MOST (Attempts 3 and 5) could be argued as more memory-efficient for large images (they allow beneficial downscaling), the PR's approach is the correct semantic for a stream/resource load where the developer controls display size via the Image control's Aspect/HeightRequest/WidthRequest properties. The agent could NOT beat the PR's fix.

---

📋 Report — Final Recommendation

---

📝 Review Session — Modified the test cases · eb7bec7

---

✅ Final Recommendation: APPROVE

Summary

PR #33590 fixes a genuine Android memory bug where ImageSource.FromResource() and ImageSource.FromStream() caused ~25MB Bitmap.ByteCount vs ~1MB for XAML images. The root cause (Glide upscaling stream-based images to display dimensions) is correct, the fix (.override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL)) is verified to work by Gate, and the test was updated to use a robust comparison approach (comparing resource vs. file image byte counts directly, rather than a hardcoded value).

The prior review (at commit 4a23114) requested changes due to a hardcoded byte count in the test. The author has addressed this — the current test uses Assert.That(resource, Is.EqualTo(file)), which is device-independent. Gate passed with this updated test.

The agent explored 5 alternative fix approaches and could not find a better solution than the PR's fix.

Root Cause

Glide's default behavior when loading from InputStream is to resize the decoded bitmap to match the ImageView's (or display) dimensions. loadImageFromFont in the same file already had .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to prevent this. The two loadImageFromStream overloads were missing this override, causing stream-based images (used by ImageSource.FromResource() and ImageSource.FromStream()) to be upscaled to display resolution (~25MB) rather than preserved at original dimensions (~786KB).

Fix Quality

Approach: Add .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to both loadImageFromStream overloads in PlatformInterop.java.

Assessment: ✅ Correct, minimal (4 lines), and consistent with the existing loadImageFromFont pattern in the same file. The agent tried 5 alternative approaches (all passed tests) but none were simpler or more semantically clear than the PR's approach.

Alternative approaches explored (all passed tests):

• .centerInside() transformation — prevents upscaling via transformation layer
• .downsample(DownsampleStrategy.NONE) — disables decode-level upsampling
• .downsample(DownsampleStrategy.AT_MOST) — prevents upscaling, allows downscaling
• Read stream to byte[], decode bounds, override explicitly — works but invasive (~60 lines)
• .downsample(DownsampleStrategy.CENTER_INSIDE) — semantically clear, allows downscaling
• Downsampler.FIX_BITMAP_SIZE_TO_REQUESTED_DIMENSIONS=false — ❌ FAILED

PR Finalize Review

Title: ✅ Accurate — [Android] Fix excessive memory usage for stream and resource-based image loading

Description: ✅ Good — contains NOTE block, issue details, root cause, description of change, platforms checkbox. Only minor enhancement: add "What NOT to Do" section.

Suggested description addition:

### What NOT to Do (for future agents)
- ❌ **Don't use `.dontTransform()`** — Only stops post-decode transformations; the upscaling happens during the decode phase and is not affected
- ❌ **Don't use `Downsampler.FIX_BITMAP_SIZE_TO_REQUESTED_DIMENSIONS=false`** — Deep Glide internal; doesn't affect stream-based image decode upscaling path

Code Review Findings

🟡 Medium Issues

1. Test can pass silently if both images fail to load

The test assertion Assert.That(resource, Is.EqualTo(file)) would pass if both labels contain "ByteCount:0" (e.g., if the images fail to load before the button is tapped). The GetBitmapByteCount fallback is also concerning — if the ImageView hasn't rendered yet when the button is tapped, it returns 0 for both, causing a false positive.

Recommendation: Add a guard that the byte count is non-zero:

Assert.That(resource, Is.Not.EqualTo("ByteCount:0"), "Resource image byte count should be non-zero");
Assert.That(resource, Is.EqualTo(file));

2. DownSizeImageAppearProperly.png snapshot changed (unexplained)

The DownSizeImageAppearProperly snapshot was modified by this PR, but the description doesn't explain why. Loading images at SIZE_ORIGINAL instead of display dimensions may change visual appearance if Glide was previously doing beneficial downscaling for this test. The snapshot change should be reviewed to confirm the new appearance is correct.

🟢 Minor Issues

3. Test only covers FromResource path, not FromStream

The test uses ImageSource.FromResource(). Both code paths converge on loadImageFromStream, so one test is sufficient, but a comment would help future contributors understand this:

// ImageSource.FromResource routes through loadImageFromStream in PlatformInterop.java,
// so this test covers both FromResource and FromStream scenarios.

✅ Looks Good

• Core fix is correct and minimal: 2×2-line change in PlatformInterop.java, consistent with loadImageFromFont pattern
• Test approach is robust: Comparing resource vs. file byte counts is device-independent
• AutomationIds are present and matched: HostApp and test correctly reference same IDs
• NOTE block present in PR description
• Platform labels accurate (Android only)

Platforms

• Android (tested by Gate + try-fix)
• iOS — not affected (fix is Android-only Java code)
• Windows — not affected
• macOS — not affected

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: [Android] Fix excessive memory usage for stream and resource-based image loading

Description: ✅ Good

Description needs updates. See details below.

✨ Suggested PR Description

[!NOTE]
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Root Cause

Glide's default behavior for stream-based image loading is to upscale the decoded bitmap to the display dimensions of the target ImageView. This caused ImageSource.FromResource() and ImageSource.FromStream() to produce bitmaps with byte counts proportional to the screen resolution rather than the original image dimensions. File-based loading (loadImageFromFile) and font-based loading (loadImageFromFont) were not affected — loadImageFromFont already used Target.SIZE_ORIGINAL to preserve original dimensions.

Description of Change

Added .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to both loadImageFromStream overloads in PlatformInterop.java:

• loadImageFromStream(ImageView imageView, InputStream inputStream, ImageLoaderCallback callback)
• loadImageFromStream(Context context, InputStream inputStream, ImageLoaderCallback callback)

This prevents Glide from upscaling the bitmap to the display size, ensuring stream/resource-loaded images consume memory proportional to their actual dimensions — consistent with the existing behavior for file-based image loading.

Note: Target.SIZE_ORIGINAL also prevents Glide from downsampling very large images. This is the correct behavior for MAUI (matching how file images are loaded), but very large embedded resources will use proportionally more memory.

Key Technical Details

Methods changed (PlatformInterop.java):

• loadImageFromStream(ImageView, InputStream, ImageLoaderCallback) — previously lacked size override, now uses Target.SIZE_ORIGINAL
• loadImageFromStream(Context, InputStream, ImageLoaderCallback) — previously lacked size override, now uses Target.SIZE_ORIGINAL

Unchanged (already correct):

• loadImageFromFont — already used Target.SIZE_ORIGINAL for both ImageView and Context variants
• loadImageFromFile — file loading was not affected by the upscaling issue

Issues Fixed

Fixes #33239

Platforms Tested

• Android
• Windows
• iOS
• Mac

Output Screenshot

Before	After

Code Review: ⚠️ Issues Found

Code Review — PR #33590

PR: [Android] Fix excessive memory usage for stream and resource-based image loading
Files reviewed: 4

---

🔴 Critical Issues

None.

---

🟡 Moderate Concerns

1. #if ANDROID Inside HostApp Method Bodies

File: src/Controls/tests/TestCases.HostApp/Issues/Issue33239.cs

Problem: The UI test guidelines say platform-specific logic should be moved to extension methods rather than using inline #if directives inside method bodies. The HostApp file uses #if ANDROID both inside OnMeasureClicked and to guard the GetBitmapByteCount helper method.

// Current — discouraged pattern
private void OnMeasureClicked(object sender, EventArgs e)
{
#if ANDROID
    int resourceByteCount = GetBitmapByteCount(_resourceImage);
    // ...
#endif
}

#if ANDROID
static int GetBitmapByteCount(Image image) { ... }
#endif

Recommendation: Move the Android-specific logic to a platform extension method (e.g., in a Issue33239.android.cs partial file), or at minimum consolidate the #if ANDROID guard to the class/file level rather than inside method bodies.

Severity: Moderate (guideline violation, doesn't affect functionality)

---

2. Target.SIZE_ORIGINAL Disables All Size Optimization

File: src/Core/AndroidNative/maui/src/main/java/com/microsoft/maui/PlatformInterop.java

Problem: Using Target.SIZE_ORIGINAL with Glide prevents both upscaling AND downscaling. This is correct for normal image sizes and matches the pre-existing behavior for loadImageFromFont. However, for very large images loaded via stream/resource (e.g., a multi-megapixel embedded resource), the full-resolution bitmap will be decoded into memory without any size-based downsampling.

// New behavior — loads at original dimensions always (no size cap)
RequestBuilder<Drawable> builder = Glide
    .with(imageView)
    .load(inputStream)
    .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL);

Context: The old behavior (upscaling to display dimensions) was arguably worse — a small image was wastefully upscaled. The new behavior is correct for the common case. This concern is primarily about documenting the edge case.

Recommendation: This is acceptable as-is and matches the existing loadImageFromFont pattern. No code change needed, but consider adding a comment noting that SIZE_ORIGINAL intentionally preserves original dimensions for both small and large images.

Severity: Moderate (potential OOM for very large embedded images, but this matches existing loadImageFromFont behavior and is better than the previous upscaling)

---

🟢 Looks Good

Fix is Correct and Minimal

The core fix — adding .override(Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL) to both loadImageFromStream overloads — is exactly the right approach. This matches how loadImageFromFont was already handled and directly addresses the root cause (Glide upscaling stream inputs to display dimensions).

Both Overloads Fixed

Both the ImageView-based and Context-based variants of loadImageFromStream are updated, ensuring consistent behavior regardless of which loading path is used.

Test Approach Is Sound

The Issue33239.cs test compares byte count of a resource-loaded image vs. a file-loaded image using Assert.That(resource, Is.EqualTo(file)). This is a meaningful test since both images are loaded from the same royals.png source — after the fix, both paths should produce the same byte count. This avoids the fragility of asserting an absolute byte count value.

Note on Outdated Review Comment: There is an existing review comment from copilot-pull-request-reviewer suggesting a range-based assertion around a hard-coded value of 786432. This comment is marked as outdated and refers to an earlier version of the test. The current test implementation does not use a hard-coded byte count and does not need this suggestion applied.

Test Class-Level #if ANDROID Guard Is Acceptable

The NUnit test file wraps the entire class in #if ANDROID at the class level (not inside a test method), which is an acceptable pattern for platform-specific tests where the test simply cannot run on other platforms.

---

[Shalini-Ashokan]

The AI summary suggested test did not work. so I updated the test case and verified that it now works as expected.