Broaden version checking for mediatek workaround - #189534

/gemini review

Tested this PR on the affected device with a locally built engine from this PR's HEAD (ac8d095b843) — the crash still reproduces with the patch active (twice in one afternoon).

Test setup

• Device: OPPO CPH2203, ro.board.platform=mt6779 (Helio P90, PowerVR Rogue GM9446), Android 13 (API 33) — same device class as [Impeller/GLES] Recurring SIGSEGV in libGLESv2_mtk.so (glClear) on raster thread on MediaTek **Android 13** device — please extend the #187404 workaround beyond API 29 #189190
• Engine built locally with et build -c android_release_arm64 from this PR's HEAD; verified the binary contains the new mt6779/MT6779 platform strings; libflutter.so BuildId 762f884672006f769b9c2851d00c28a7e898c3d4
• The crash tombstones show that exact BuildId in the backtrace, so there is no ambiguity about which engine crashed
• Device satisfies the broadened gate (sdk=33, platform mt6779), so ShouldClearContextBetweenFrames() returned true — the workaround was active
• (Note: there are no CI artifacts for this PR, and a local checkout of the PR branch silently resolves to the base engine via the merge-base content hash — hence the local build.)

Result

Release build, normal usage: two crashes (~86 min and ~22 min into their sessions), identical signature to the production reports in #189190 — null-pointer dereference in libGLESv2_mtk.so at glClear+564 on the raster thread, each preceded within ~0.5s by a PowerVR driver job-pool exhaustion burst on the same thread:

15:48:09.479 32325  5803 E IMGSRV  : :1136: RM_GrowJobPool: Number of job pool chunks in use is too large to allow growth
15:48:09.479 32325  5803 E IMGSRV  : :1197: Failed to grow job pool
15:48:09.479 32325  5803 E IMGSRV  : :2800: RM_InsertJob_NoLock: Failed to allocate Job
15:48:10.049 32325  5803 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 5803 (1.raster)

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 — null pointer dereference
  #00 pc 019e794  libGLESv2_mtk.so (BuildId: 5f0230c5c21f5c7f1d1c30e576a5e1fd)
  #01 pc 00f737c  libGLESv2_mtk.so
  #02 pc 00afab4  libGLESv2_mtk.so
  #03 pc 00b0150  libGLESv2_mtk.so (glClear+564)
  #04 pc 09e9834  libflutter.so (BuildId: 762f884672006f769b9c2851d00c28a7e898c3d4)

Why the workaround doesn't help here

• The failure mode is driver job-pool exhaustion, not the idle-context eglMakeCurrent race this workaround targets. The driver fails to allocate an internal job and its glClear path dereferences null on that failure (a driver bug Flutter can only avoid triggering, not fix). In a separate observation, the same exhaustion burst landed on the IO thread's texture-upload path and the process merely logged and survived — the crash is just "exhaustion landing on the glClear call site".
• Trigger state: the crashes and all precursor bursts occurred while the app sat idle on a screen with auto-playing content (banner carousel: periodic image decode → IO-thread texture upload + small animation frames). GL mtrack was a normal ~150–250 MB throughout — this is not memory pressure. An hour of aggressive scripted scrolling + activity transitions never produced a single IMGSRV error. That points at many small GL submissions (per-upload fence + glFlush from image_decoder_impeller.cc / ContextGLES::AddTrackingFence, plus per-pass submissions) outpacing the driver's job retirement in low-load states.

What does work (experimental, validated on this device)

To confirm the diagnosis I built a variant gated to ro.board.platform starting with mt67:

1. ContextGLES::AddTrackingFence returns false → image uploads fall back to the WaitUntilCompleted (glFinish) path, so uploads retire driver jobs immediately instead of accumulating fences; and
2. CommandBufferGLES::OnSubmitCommands calls glFinish on every 64th submission to periodically drain the driver's queue.

That build has been running clean for 3+ hours under the exact reproduction conditions (idle on the carousel screen, plus heavier interactive load), with zero RM_GrowJobPool precursors — versus crashes at 11–106 min on every other build tested today. A production-quality fix would presumably be finer-grained (cap in-flight fences / batch flushes rather than glFinish), but the direction — reducing submission pressure on these drivers — is what actually moves the needle, and broadening the context-clear gate does not.

Happy to run same-day soak tests on this device for any experimental build; the RM_GrowJobPool logcat precursor makes validation fast because we don't have to wait for an actual crash.

Greetings from stale PR triage! 👋
Is this change still on your radar?