[Impeller][GLES] ImageDecoderImpeller SIGABRT persists on Flutter 3.44.8 across Android 10 Mali devices

### Related closed issue

This is a follow-up to #188472, which I originally reported. That issue was closed while waiting for confirmation on a newer stable Flutter release. I later added a production confirmation for Flutter 3.44.6, but the issue remains closed. The closing bot explicitly requested a new issue when additional evidence became available.

There are no currently open issues matching `ImageDecoderImpeller + BlitPassGLES + Android 10`.

### Steps to reproduce

We still do not have a deterministic local reproduction. This is an intermittent production engine crash.

1. Run a release-mode Flutter app with Android Impeller enabled.
2. Use a Samsung Android 10 device with a Mali GPU.
3. Navigate through screens that decode and upload images.
4. The process intermittently aborts on the Impeller IO thread while uploading a decoded image through the GLES blit path.

The crash disappears for the affected cohort when the app starts Flutter with Skia instead of Impeller. We now apply that mitigation by Android API level and `Build.DEVICE` codename.

### Latest production environment

The latest base release is built through Shorebird with:

- Flutter: `3.44.8` stable
- Shorebird: `1.6.115`
- Shorebird Flutter revision: `c15ef6379403a0a55531a058bdb2c8e55bc05c98`
- Shorebird engine revision: `69f9831c360d9152862ec3897c67fb09ae843f3b`
- App build: `3.35.2 (113261)`
- Patch: base release / patch 0
- Renderer: Impeller enabled by default
- ABI: ARM64

A new event occurred on 2026-08-05 on Flutter 3.44.8:

- Samsung Galaxy A31 `SM-A315N`
- `Build.DEVICE=a31`
- Android 10 / API 29
- MediaTek MT6768 / Helio P65
- Mali-G52 MC2
- Crash type: `SIGABRT`
- Blamed library: `libflutter.so`

This is important because the original report was concentrated on Samsung Exynos/Mali devices. The A31 uses a MediaTek SoC but still uses a Mali GPU, so the observed boundary is broader than Exynos 9810.

### Exact symbolized stack

The current 3.35.2 Crashlytics export omits native frames, but it is grouped into the same Crashlytics issue and variant as earlier Build-ID-matched events. The exact stack below was symbolized from the production `3.34.0 (113182)` build using the matching ARM64 Shorebird engine symbols:

- Flutter: `3.44.6` stable
- Engine revision: `401254d5890cba1abe1ea364004f4d6bf8e58c24`
- `libflutter.so` Build ID: `730039c16a8d226e3597c77d059f4f0c863b15ba`

```console
fml::LogMessage::~LogMessage() logging.cc:186
impeller::BlitPassGLES::EncodeCommands() const::$_0 blit_pass_gles.cc:88
impeller::ReactorGLES::React() reactor_gles.cc:261
flutter::ImageDecoderImpeller::UnsafeUploadTextureToPrivate() image_decoder_impeller.cc:527
```

The complete native stack is:

```console
#00 libc.so (abort)
#01 libflutter.so (fml::KillProcess)
#02 libflutter.so (fml::LogMessage::~LogMessage)
#03 libflutter.so (impeller::BlitPassGLES::EncodeCommands() const::$_0)
#04 libflutter.so (impeller::ReactorGLES::React)
#05 libflutter.so (impeller::ReactorGLES::AddOperation)
#06 libflutter.so (impeller::BlitPassGLES::EncodeCommands)
#07 libflutter.so (flutter::ImageDecoderImpeller::UnsafeUploadTextureToPrivate)
#08 libflutter.so (flutter::ImageDecoderImpeller::UploadTextureToPrivate::$_0)
#09 libflutter.so (fml::SyncSwitch::Execute)
#10 libflutter.so (flutter::ImageDecoderImpeller::UploadTextureToPrivate)
#11 libflutter.so (flutter::ImageDecoderImpeller::Decode::$_1)
#12 libflutter.so (fml::MessageLoopImpl::RunExpiredTasksNow)
#13 libflutter.so (fml::MessageLoopAndroid callback)
#14 libutils.so (android::Looper::pollInner)
#15 libutils.so (android::Looper::pollOnce)
#16 libandroid.so (ALooper_pollOnce)
#17 libflutter.so (fml::MessageLoopAndroid::Run)
```

No Dart frame or app-owned Android plugin frame appears in this crash stack.

### Production impact after the previous issue was closed

From 2026-07-15 through 2026-08-06, the same Crashlytics variant produced **572 events across 113 installations** on Android 10. Counts are deduplicated by event ID and installation ID.

| Device | Build.DEVICE family | SoC / GPU | Events | Installations |
|---|---|---|---:|---:|
| Galaxy Note9 `SM-N960N` | `crownlte*` | Exynos 9810 / Mali-G72 | 401 | 78 |
| Galaxy S9+ `SM-G965N` | `star2lte*` | Exynos 9810 / Mali-G72 | 58 | 16 |
| Galaxy A31 `SM-A315N` | `a31*` | MediaTek MT6768 / Mali-G52 | 44 | 2 |
| Galaxy S9 `SM-G960N` | `starlte*` | Exynos 9810 / Mali-G72 | 36 | 8 |
| Galaxy S10+ `SM-G975N` | `beyond2*` | Exynos 9820 / Mali-G76 | 15 | 3 |
| Galaxy S10 5G `SM-G977N` | `beyondx*` | Exynos 9820 / Mali-G76 | 8 | 1 |
| Galaxy Tab S6 Lite `SM-P610` | `gta4xlwifi*` | Exynos 9611 / Mali-G72 | 5 | 3 |
| Galaxy S9+ `SM-G965F` | `star2lte*` | Exynos 9810 / Mali-G72 | 4 | 1 |
| Galaxy Note10+ 5G `SM-N976N` | `d2x*` | Exynos 9825 / Mali-G76 | 1 | 1 |

All rows above are Android 10. The issue is still heavily concentrated on Exynos 9810/Mali-G72, but it also occurs on other Mali generations and now on a MediaTek/Mali device.

### Expected results

Impeller should decode and upload images without aborting the process on Android 10 Mali/GLES devices.

If the underlying driver behavior cannot be handled safely, Flutter should consider a renderer denylist/fallback for the affected Android 10 Mali driver families instead of requiring each application to maintain a device-codename list.

### Actual results

The engine calls `fml::KillProcess` from `BlitPassGLES::EncodeCommands` during `ImageDecoderImpeller::UnsafeUploadTextureToPrivate`, terminating the app without an app-owned frame.

### App-side mitigation

We now force Skia only when both conditions match:

- Android API 29
- An observed `Build.DEVICE` prefix such as `crownlte`, `starlte`, `star2lte`, `beyond`, `d2x`, `gta4xlwifi`, `m20`, `a7y18lte`, `a50`, or `a31`

This requires a native release because renderer selection happens during Flutter process bootstrap. We will monitor whether the crash disappears after rollout, but this per-app device list is fragile and cannot protect other Flutter apps.

### Flutter doctor

flutter doctor -v

```console
[✓] Flutter (Channel stable, 3.44.8, on macOS 26.6 darwin-arm64, locale ko-KR)
• Flutter version 3.44.8 on channel stable
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 058e0af2c2 (2026-07-23)
• Engine revision 0cd610717b
• Dart version 3.12.2
• DevTools version 2.57.0
• Feature flags: enable-web, enable-linux-desktop, enable-macos-desktop,
enable-windows-desktop, enable-android, enable-ios, cli-animations,
enable-native-assets, enable-swift-package-manager,
omit-legacy-version-file, enable-lldb-debugging, enable-uiscene-migration

[✓] Android toolchain - develop for Android devices (Android SDK version 36.1.0)
• Platform android-36.1, build-tools 36.1.0
• Java version OpenJDK Runtime Environment 25.0.2
• All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 26.6)
• Build 17F113
• CocoaPods version 1.17.0

[✓] Chrome - develop for the web
[✓] Network resources

• No issues found!
```

### Request

Could the Impeller/engine team investigate why `BlitPassGLES::EncodeCommands` treats this Android 10 Mali failure as fatal, and whether Flutter should apply a built-in GLES/Impeller denylist or safe fallback for this driver cohort?

This report intentionally excludes private production session IDs, user identifiers, and application logs. I can provide additional Build-ID-matched native evidence if the engine team identifies a specific artifact or diagnostic needed.

Start by reading BlitPassGLES::EncodeCommands in blit_pass_gles.cc:88 and ImageDecoderImpeller::UnsafeUploadTextureToPrivate in image_decoder_impeller.cc:527, following the stack through ReactorGLES. Investigate the Android 10 Mali/GLES failure using the supplied production evidence, noting that no deterministic local reproduction is available. Done means the fatal crash is safely handled or an engine-level fallback or denylist is validated for the affected devices.

Written by the indexing model from the issue text.