Merge main into dev after the 1.4.3 release - #46
Merged
Conversation
* Bump to Flutter 3.44.8 (1.4.3)
Engine artifacts are rebuilt from source against the 3.44.8 tree rather than
republished, so v1.0.1-flutter3.44.8 is a genuine rebuild.
Nothing in the 3.44.6..3.44.8 range reaches the tvOS engine. DEPS is untouched,
so the Dart submodule stays at d684a576 and the SDK hash our AOT artifacts
embed does not move. The engine-source changes in the range are Android-side
(AccessibilityBridge.java, the Android toolchain GN file), a host-architecture
fix for the clang path in copy_info_plist.py, and an ASan-only copy rule in
darwin/ios/BUILD.gn — none of which are compiled into a shipped
Flutter.framework. impeller/ is untouched. The rebuilt zips land within ~500
bytes of the 3.44.7 artifacts, which is the expected result.
On the tooling side, 3.44.8 changes UnpackDarwin.thinFramework to run
lipo -verify_arch once per architecture (an Xcode 27 fix). flutter-tvos does
not use UnpackDarwin — it copies the engine framework itself — so nothing
needed mirroring. The four upstream build-graph classes this CLI subclasses
(KernelSnapshot, CopyFlutterBundle, DartPluginRegistrantTarget, AotElfRelease)
are byte-identical to 3.44.7, so the tvOS overrides are unchanged.
Verified against the freshly built artifacts, extracted through precache after
clearing engine_artifacts/ so no stale extraction could be reused:
verify_artifacts.sh all pass, incl. the designated-requirement origin
signature and the on-device JIT RWX fix
dart analyze lib/ 0 errors, 0 warnings (135 infos)
CLI suite 297 passed
tvOS 17.5 simulator debug: launch, hot reload, hot restart, 10/10 FFI
symbols, zero "Target OS is incompatible"
Apple TV 4K, tvOS 26.5
debug/JIT (incl. hot reload over the wireless tunnel),
profile and release: launch + 10/10 FFI symbols, and
os=tvos / isIOS / isTvOS / ffiIsTvOS all true with
target=TargetPlatform.iOS in every mode
The 17.5 run is the one that matters for shaders: tvOS 26 tolerates a wrong
metallib platform triple and older runtimes do not.
* Run the package suite in CI; correct the 1.4.3 changelog entry
Addresses review on #44.
CI ran `dart test test/`, path-scoped to the root suite, so the 103 tests in
packages/flutter_tvos/test/ never ran in either workflow. They are widget
tests and need the flutter runner rather than `dart test`. That set includes
rcu/protocol_drift_test.dart, which pins the RCU wire protocol against
FlutterTvRemoteProtocol.h — the test most likely to catch engine-side drift on
a version bump, and so exactly what should be running on a PR that moves the
engine. All 103 pass locally.
Changelog corrections:
- The "~500 bytes" figure was understated. It came from comparing one zip and
generalising; the real range is +3 to +1204. The entry now carries the
per-asset table and the explanation, which is a stronger argument than an
unexplained delta: copy_info_plist.py generates the Info.plist embedded in
Flutter.framework and gained `text=True` in this range, changing the
recorded clang version from a bytes repr to a plain string. The two zips
with no embedded framework moved 3-4 bytes; all four with one moved
546-1204. This also corrects the previous claim that none of the changed
engine files reach a shipped Flutter.framework — this one does.
- DartPluginRegistrantTarget was listed among classes this CLI subclasses.
TvosDartPluginRegistrantTarget extends Target directly and replaces the
stock target. That matters in the opposite direction from what the entry
implied: a replacement inherits no upstream fixes, so drift is a behavioural
risk rather than a non-event. tvosGenSnapshotArgs is named for the same
reason.
- The change enumeration read as exhaustive but omitted FlutterRenderer.java
and the test/CI-only files.
- The verification block recorded only the tvOS 17.5 simulator, while device
testing across debug, profile and release had actually been run. Both 1.4.1
and 1.4.2 record on-device verification, so omitting it here read as though
it had been skipped for the one release in the series that rebuilds the
engine from source.
- isTvos/isTvOS were collapsed into one line; they are different getters
(dart:io Platform.isTvOS versus the package's FlutterTvosPlatform.isTvos)
and both are checked.
- Noted that the range is quoted from 3.44.6 because the 3.44.7 artifacts were
republished 3.44.6 binaries, and that Dart is a gclient revision pin rather
than a submodule.
* Fetch Flutter tags in CI so `flutter test` can resolve the SDK version
The package-test step added in the previous commit failed CI with:
The current Flutter SDK version is 0.0.0-unknown.
Because flutter_tvos requires Flutter SDK version >=3.19.0, version
solving failed.
Both workflows clone Flutter and fetch the pinned commit without --tags, so
`git describe --tags` cannot name a version. `dart test` never noticed
because it does no pub resolution against a `flutter:` SDK constraint;
`flutter test` does, and any package declaring one fails version solving.
bin/internal/shared.sh already passes --tags for this exact reason and says
so in a comment. CI now matches.
Passed locally from a clean state (.dart_tool removed, so `flutter test`
does its own implicit pub get): 103 tests.
Re-establishes a common ancestor after the 1.4.3 release. main is only reachable by squash merge, so promoting dev created a new commit there with the same tree but a different SHA — leaving the two branches one commit apart in each direction with no content difference at all. Left unmerged, the next dev->main promotion conflicts on exactly the files this release touched (version pins, CHANGELOG), because git would see two unrelated commits changing the same lines. This merge is a no-op on content and only fixes the history.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-establishes a common ancestor between
devandmainafter the 1.4.3 release.No content change. This branch's tree is byte-identical to both
devandmain— the diff against either is empty. It exists purely to fix history.Why it is needed
mainonly accepts squash merges, so promotingdev(#45) created a new commit onmainwith the same tree but a different SHA. That left:Left unmerged, the next
dev→mainpromotion conflicts on exactly the files a release touches —bin/internal/*.version,pubspec.yaml,CHANGELOG.md— because git sees two unrelated commits changing the same lines. Merging now costs nothing and removes that conflict from the next cycle.Same pattern as #42 after the previous release.