Flutter 3.44.8 tvOS Engine Artifacts

tvOS engine artifacts for Flutter 3.44.8, built from flutter/flutter@058e0af2c2b57e369d905a03ac9748b0ebf543c6.

A real rebuild, not a republish

Unlike v1.0.1-flutter3.44.7 — which republished the 3.44.6 binaries — these are compiled from source against the 3.44.8 tree.

	3.44.6 → 3.44.8
DEPS	untouched — Dart stays at d684a576, so the AOT SDK hash does not move
engine source	Android only (AccessibilityBridge.java, FlutterRenderer.java, Android toolchain GN) plus a host-clang-arch fix in copy_info_plist.py
darwin/ios/BUILD.gn	an ASan-only copy rule — not compiled into a shipped framework
impeller/	untouched

Why these binaries differ from 3.44.7, and by how much

An earlier version of these notes said "within ~500 bytes". That was measured from one asset and generalised — the actual range is +3 to +1204:

asset	3.44.7	3.44.8	delta
host_debug_unopt.zip	14 984 806	14 984 809	+3
host_release.zip	10 893 675	10 893 679	+4
tvos_debug_sim_arm64.zip	105 808 785	105 809 331	+546
tvos_profile_arm64.zip	26 856 108	26 857 299	+1191
tvos_debug_arm64.zip	106 195 959	106 197 152	+1193
tvos_release_arm64.zip	25 388 252	25 389 456	+1204

The split is explained rather than build noise. copy_info_plist.py generates the Info.plist embedded in Flutter.framework, and in this range its subprocess.check_output gained text=True — changing the recorded clang version from a bytes repr to a plain string. The two assets that embed no framework moved 3-4 bytes; all four that embed one moved 546-1204.

This also corrects the claim above it: that file does reach a shipped Flutter.framework, via the Info.plist. No compiled code changed.

Verified before publishing

Every check ran against these exact zips, extracted fresh after clearing the previous extraction so no stale content could be reused:

• verify_artifacts.sh — all pass: platform triples, origin signature checked against a designated requirement (Developer ID, team 866PPL96Z4), the on-device JIT RWX fix, and the platform-identity patch in both host SDKs.
• Physical Apple TV 4K (tvOS 26.5) — debug/JIT, profile and release all install, launch and render. On-device hot reload works over the wireless tunnel with no mprotect crash, so the RWX fix is intact.
• tvOS 17.5 simulator — JIT/debug runs clean with zero Target OS is incompatible errors. This is the run that matters for shaders: tvOS 26 tolerates a wrong metallib platform triple and older runtimes reject every pipeline, so the old runtime is what actually catches a bad engine.
• Platform identity in all four modes (sim debug, device debug, device profile, device release): Platform.operatingSystem == "tvos", isIOS, isTvOS and the package-level FlutterTvosPlatform.isTvos all true, with defaultTargetPlatform == TargetPlatform.iOS — so the vm:platform-const fold is still being avoided correctly under AOT.
• CLI suite — 297 tests pass; dart analyze reports no errors or warnings.

Also in this cycle

engine/generate_patches.sh built patch 01 from a hardcoded file list that omitted runtime/vm/virtual_memory_posix.cc, silently dropping the tvOS 26 on-device JIT (RWX) fix from any regenerated patch set. Fixed in fluttertv/engine#8, which also adds a coverage assertion so a modified file captured by no patch fails generation outright. These artifacts are built from a patch set that includes it, and verify_artifacts.sh asserts its presence.

Version numbering

Tagged v1.0.1, not v1.0.0, for continuity: the v1.0.1 line carries the metallib fix that first shipped in v1.0.1-flutter3.44.6, and a v1.0.0-flutter3.44.8 would read as though it predates that fix.