Bump flutter-tvos to Flutter 3.47.4

[MAUstaoglu]

Flutter 3.47.4 cherry-picked flutter/flutter#192301, which made LLDB.attachAndStart take a required IOSDeviceSupport. The release train re-pinned dev and stopped at compile:

lib/tvos_device.dart:777:28: Error: Required named parameter 'deviceSupport' must be provided.

The port cannot land ahead of the re-pin (the parameter does not exist in 3.47.3), so this carries both, in the same shape the train produces: 1.10.2 → 1.10.3, engine pin unchanged.

The port

Upstream's IOSDeviceSupport hardcodes ~/Library/Developer/Xcode/iOS DeviceSupport. LLDB.attachAndStart uses it for two things: platform select remote-ios --sysroot <symbols> whenever it finds symbols, and the message printed when the attach passes one minute. 3.47.4 also added a platform status step to every attach, which does not depend on the class and runs on tvOS as on iOS.

TvosDeviceSupport (new, lib/tvos_device_support.dart) implements the interface for Apple TV:

• Looks in tvOS DeviceSupport/<model> <version> (<build>), named from devicectl's productType, osVersionNumber and osBuildUpdate. Checked against a real device: AppleTV14,1 26.6 (23L773) is the directory Xcode created.
• existingDeviceSupportSymbols is always null, so lldb is never sent the remote-ios sysroot for an Apple TV and finds tvOS symbols on its own, as on 3.47.3. The rest of 3.47.4's attach sequence applies unchanged.
• missingSymbolsWarning never returns null, because upstream turns null into an error asking for a flutter/flutter bug. It reports missing or unfinished support with the directory (.finalized plus Symbols marks a finished copy, directly or one level down, the Xcode 27 iOS layout), a likely slow wireless connection when the copy is complete, or a path-less message when the device cannot be identified. With warnWhenSymbolsExist it calls a complete copy stale and gives the rm -rf to remove it.
• prepareDeviceSupport is a no-op; upstream only calls it from IOSDevice.startApp.

TvosDevice.attachLldb (extracted from startApp) makes the attach call with the device's own support, keeps the attach timeout, and turns lldb's libobjc.A.dylib is being read from process memory line into a warning, as IOSDevice does. It used to reach only the verbose log.

Verified

Against Flutter 3.47.4, at 2d7f31e:

• bin/flutter-tvos --version compiles and starts
• dart analyze --fatal-infos lib/ test/ bin/: no issues; packages/flutter_tvos flutter analyze --fatal-infos: no issues
• dart test test/: 468 passed, 15 of them in tvos_device_support_test.dart. Beyond the class, they cover the device building its support from HOME and devicectl output, attachLldb handing lldb that same object and surfacing the missing-symbols line, and a hung attach giving up at the timeout. Each of the five mutations from review, and dropping the log hook, fails the suite.

End-to-end, run locally with release-train/tools/e2e.sh against c15f8c1 (before the review changes): engine artifacts verified; sim-debug 10/10; on an Apple TV 4K (tvOS 26.6, Xcode 26.6) device-debug 10/10 including hot reload and hot restart taking effect, device-profile and device-release passing with all 10 FFI symbols exported. 23 passed, 0 failed. The debug run attached through lldb without falling back to the Xcode debugger, which shows 3.47.4's attach sequence works on tvOS. It attached in under a minute, so it did not exercise the slow-attach messages; those are covered by the unit tests. The review changes move the attach call into attachLldb without changing its arguments or timeout.

Also in this PR: the repository front page

Folded in from #83 so it ships with the same release. Docs and workflow only, no code:

• README: logo, badges (latest release, Test on dev, flutter_tvos on pub.dev, license) and a link row. The hand-maintained "Current version" block, which the train never updates, is replaced by a "Versions" section explaining the v<flutter>-tvos.<cli> tag, so the release badge is the source of truth.
• Issue forms: bug report (asks for flutter-tvos --version, macOS, Xcode, simulator/device, tvOS version, build mode), plugin port request, feature request, and routing for questions and security reports.
• release.yml: the GitHub release body is now that version's CHANGELOG entry with a Flutter/CLI footer, falling back to the link with a warning. Verified against the current CHANGELOG with the real v3.47.3-tvos.1.10.2 tag. This release, v3.47.4-tvos.1.10.3, is the first to use it.
• doc/assets/flutter-tvos-logo.png, transparent so it works on both GitHub themes.

Merging releases v3.47.4-tvos.1.10.3.

[DenisovAV]

Reviewed at cc59746 against upstream flutter_tools at 3.47.3 and 3.47.4, the #192301 cherry-pick and #189284.

The compile fix and the cli-only call are right: the 3.47.3 → 3.47.4 diff touches only packages/flutter_tools, so engine-87021d7a… still describes the engine. The release.yml notes extraction handles 1.10.3 vs 1.10.30, falls back cleanly, and passes the tag to the new step through env:. The issue forms are valid.

The points below are mostly about what the release notes will say, and since merging publishes v3.47.4-tvos.1.10.3 with this CHANGELOG entry as its body — and a re-run skips an existing release (release.yml:111-113) — they're cheapest to fix before merge.

Release notes and description

"the end-to-end matrix did not run for this release" (CHANGELOG.md:21-22). The description reports a full e2e.sh run, 23/23, including device debug, profile and release on an Apple TV 4K. As written, the release page will tell users this version got less validation than it did.

"the attach sequence on an Apple TV is the one 3.47.3 used" (CHANGELOG.md:33-34, tvos_device_support.dart:22-23, description). The sysroot step is skipped, but 3.47.4 changed the sequence in two other places that the tvOS path reaches, because it calls attachAndStart directly:

• platform status is now sent on every attach, blocking until lldb prints Platform: (lldb.dart:162, :274-281). The device run shows this completes on Xcode 26.6, so it isn't a hang — but it is a new step.
• The 60 s timer changed (lldb.dart:131-145). When missingSymbolsWarning() returns null it now calls printError with "file a bug including the verbose logs at https://github.com/flutter/flutter/issues/new". missingSymbolsWarning returns null exactly when symbols are complete, and tvos_device.dart:444-445 notes that tvOS attaches "can take well over a minute". So a user with correct Device Support and a slow tunnel gets an error sending them to flutter/flutter. Returning a tvOS-specific slow-tunnel message instead of null would keep it on our side.

"so the new TvosDeviceSupport path is the one that ran" (description). A fast attach doesn't exercise the class: missingSymbolsWarning is only called from the 60 s timer, and existingDeviceSupportSymbols is constant null. The run shows the new upstream attach sequence works on tvOS; it doesn't cover the directory naming or the warning.

The "Device debug on an Apple TV is unchanged…" entry sits under ### Fixed (CHANGELOG.md:24); it describes no fix.

Xcode 27

#189284 is that Xcode 27 writes iOS symbols to <device>/arm64e/Symbols, lldb's own lookup misses them, and launch hangs for minutes. Upstream's fix is existingDeviceSupportSymbols preferring <device>/<arch>/Symbols plus the remote-ios --sysroot step.

Keeping the sysroot off is reasonable — the command hardcodes remote-ios in a private method (lldb.dart:263-270), and the class doc already says selecting it for tvOS is untested. It does mean tvOS keeps relying on the lookup that broke for iOS. If Xcode 27 moves tvOS DeviceSupport the same way:

• missingSymbolsWarning checks only <device>/Symbols (tvos_device_support.dart:76), so a complete, .finalized copy would be reported as "Xcode has not finished preparing debugger support", and waiting in the Devices window would never clear it.
• The attach would run into the 180 s limit and fall back to the Xcode debugger, which tvos_device.dart:833-834 says does not reliably sustain a tvOS session.

Nothing here shows whether tvOS gets the same layout — #189284 is iOS-only, and devicectl reports an A12 Apple TV as arm64, not arm64e. Not blocking this release, but worth an issue and one device run on the Xcode 27 beta; a real fix would mean overriding the sysroot step with remote-tvos, not just returning a path.

Related: 3.47.4 also warns when lldb logs libobjc.A.dylib is being read from process memory (devices.dart:940-952, missingSymbolsWarning(warnWhenSymbolsExist: true)). On tvOS lldb lines only go to printTrace (tvos_device.dart:763-764), and TvosDeviceSupport ignores warnWhenSymbolsExist (:68-79), so neither the missing-symbols nor the stale-copy case reaches the user.

Tests

The new tests cover TvosDeviceSupport in isolation; nothing covers how tvos_device.dart builds it or hands it to lldb. Each of these leaves dart test test/ at the same result:

mutation	location
modelCode: null	tvos_device.dart:368
operatingSystemVersion: osVersion (the tvOS 26.6 23L773 string)	tvos_device.dart:369
homeDirectory: null	tvos_device.dart:365-367
pass TvosDeviceSupport(homeDirectory: null, modelCode: null, operatingSystemVersion: null)	tvos_device.dart:800
drop the Symbols requirement, so .finalized alone counts as finished	tvos_device_support.dart:76

All five silently turn off the slow-attach warning. A test that builds a TvosDevice from devicectl output and asserts deviceSupport.deviceDirectory would catch the first four.

Minor: the prepareDeviceSupport doc (:62-63) reads as if upstream's copy would run here if it weren't a no-op, but upstream's only caller is IOSDevice.startApp, which tvOS doesn't use.

[MAUstaoglu]

Thanks, all of it checked out. Addressed in d0ee1c4; description updated to match.

Release notes

• The 1.10.3 entry now reports the end-to-end run (simulator, and debug/profile/release on the Apple TV) instead of saying it did not run.
• The "attach sequence is 3.47.3's" claim is gone from the CHANGELOG, the class doc and the description. They now say 3.47.4's platform status step and new timer apply to tvOS, and only the remote-ios sysroot is skipped.
• The entry under ### Fixed that described no fix is rewritten under ### Added.
• The description no longer says the E2E run exercised TvosDeviceSupport. It says the run shows 3.47.4's attach works on tvOS, attached in under a minute, and so did not reach the warning, which the unit tests cover. It also notes the run was at c15f8c1, before these changes.

Slow attach with complete symbols. missingSymbolsWarning() no longer returns null. With a finished copy it says the wireless connection is the likely cause and points at restarting the Apple TV and FLUTTER_TVOS_LLDB_ATTACH_TIMEOUT_SECONDS. For a device it cannot identify it gives a path-less message instead of null. Nothing reaches upstream's flutter/flutter error on tvOS any more.

libobjc.A.dylib is being read from process memory. The attach moved into TvosDevice.attachLldb, which turns that lldb line into a warning, as IOSDevice does. TvosDeviceSupport now honours warnWhenSymbolsExist: with a finished copy it calls it probably stale and gives the rm -rf. LLDB._ignoreLog still lets the line through once, and not at all if the timer already warned, so there is no double warning.

Xcode 27. Opened #84 for the layout question, the beta device run and a remote-tvos sysroot. One small change here meanwhile: a .finalized copy with Symbols one level down counts as complete, so the warning will not report a finished copy as unfinished if tvOS adopts the new layout. The sysroot stays off.

Tests. 15 in tvos_device_support_test.dart, 468 overall. New ones build a TvosDevice from devicectl output under a fake HOME and assert deviceSupport.deviceDirectory. They also run attachLldb against a fake LLDB to check it receives same(device.deviceSupport) and that the missing-symbols line becomes a warning, check that a hung attach gives up at the timeout, and check that .finalized without Symbols still warns. I applied your five mutations, plus dropping the new log hook, and each one fails the suite.

prepareDeviceSupport doc now says upstream only calls it from IOSDevice.startApp, which tvOS does not use.

[DenisovAV]

Re-checked at d0ee1c4. 468 tests, analyzer clean, and all six mutations now fail: modelCode: null, operatingSystemVersion: null, homeDirectory: null, a fresh all-null TvosDeviceSupport passed to lldb, .finalized alone counting as prepared, and dropping the new log hook. The CHANGELOG, the class doc and the description now describe what the code does, _isPrepared accepting <device>/<arch>/Symbols covers the Xcode 27 layout question ahead of #84, and attachLldb keeps the timeout and arguments it replaced.

One interaction between the two new messages, from reading lldb.dart:

missingSymbolsWarning() never returning null means the 60 s timer always warns, and warning sets _warnedAboutMissingSymbols (lldb.dart:131-143). _ignoreLog then drops every later libobjc.A.dylib is being read from process memory line (:388-394) before it can reach the forwarder (:202, :217). So on any attach that passes a minute, the warnWhenSymbolsExist: true warning can no longer fire — and a slow attach is exactly when symbols are being read over the network.

What the user sees in that case is the prepared-copy message: "Debugger support for this Apple TV is in place, so the delay is most likely the wireless connection". A stale copy produces the same slow attach, and the message that would have named it is now suppressed.

Since the second warning may never arrive, the prepared-copy message is the only place that can say it: naming the stale copy as the other cause, with the same rm -rf, would cover it. Independently of that, :202 only forwards after the attach completes, so the hook covers symbol reads during the run, not during the attach.

Approving — this is one message's wording, and the behaviour it guards is the same as before this PR.

[MAUstaoglu]

Right, confirmed in lldb.dart: the timer sets _warnedAboutMissingSymbols, _ignoreLog then drops the line, and _startLLDB only forwards once _isAttached. Since the release notes ship with the merge, fixed now in 2d7f31e:

• The prepared-copy message keeps the wireless connection as the likely cause, then adds: if it is slow every time, the prepared copy may be stale, followed by the same rm -rf "<device dir>" and prepare-again steps. The test for that message now asserts both.
• The attachLldb and missingSymbolsWarning docs say the log hook covers symbol reads during the run, not during the attach, and that the second warning never follows a slow attach.
• The CHANGELOG bullet names the stale copy for a slow attach, and says the process-memory warning is for "during a debug session".

468 tests pass, analyzer clean.