This allows const GlobalObjectKey(0) to be concisely formatted as
[GlobalObjectKey int#0000] in both Dart 2 and Dart 1 modes.
Without this change it would be formatted as
[GlobalObjectKey<State<StatefulWidget>> int#0000] because in Dart 2
types are instantiated to bounds.
In addition to retaining general readability this also fixes few
tests that rely on this short string representation (see
test/widgets/global_keys_duplicated_test.dart).
The current ARM64 back end generates code that crashes on some devices,
including Pixel phones. With this change, the android-arm64 target will
not be used by "flutter run" unless explicitly requested.
This is intended as a workaround until we can roll out an engine with the
required Dart VM fix.
See https://github.com/flutter/flutter/issues/14454
By default flutter run will build a 64-bit APK if the attached Android device
is 64-bit. Specifying --target-platform=android-arm will deploy a 32-bit APK
to a 64-bit device.
Fixes https://github.com/flutter/flutter/issues/14526
Channels don't preserve Map and List type arguments: Map<String, Object>
arrives as Map<dynamic, dynamic> to the receiver.
In Dart 2 type system dynamic no longer serves as bottom type so
Map<dynamic, dynamic> can't be assign to a variable of type
Map<String, dynamic>.
Issue #14556
Use mockito in the Dart 2 compliant way:
* use typed(...) in appropriate places to wrap matchers like any;
* don't pass matcher directly into the calls - use `argThat(matcher)`.
Also rename paintColorMatcher to hasColor to match how other similar
functions are named and how the code reads.
* Use explicit types for onClick handler in diagnostics_test.
This test formats it to string and expects exact match.
Before this change onClick had type () => dynamic in Dart 1 and () => Null in
Dart 2.
* Fix strong mode issues in packages/flutter/test/material/dropdown_test.dart
Pass explicit type argument to renderObjectList(...) in expressions like
List<RenderBox> l = tester.renderObjectList(...).toList();
Dart 2 mode inference is not strong enough to infer RenderBox as a type argument
fto renderObjectList and passes RenderObject instead, which later leads to
runtime check failures (because List<RenderObject> is not List<RenderBox>).
* Fix strong mode issues in packages/flutter/test/material/theme_test.dart.
Pass type argument explicity to widgetList. Dart 2 type inference can't infer
it by itself.
* Fix strong mode issue packages/flutter/test/widgets/unique_widget_test.dart
Pass correct type argument to GlobalKey.
* Fix type annotation in packages/flutter/test/material/app_test.dart.
pushNamed returns Future<Object> not Future<String>.
There were some problems I introduced with the last PR for this. It passed the test, but failed in practice.
This adds tests for those failure cases, adds a "--help" and fixes the test so that it doesn't try and actually download MinGit as part of the Windows test.
I added package:platform as a dependency, so I did a force upgrade on the packages.
Also, re-enabling 'create package' in the cache warming code, now that #14448 is fixed.
Looks in default install locations on Mac, Linux and Windows for VS Code. If found, looks in default extension location to see if Dart Code is installed.
If VS Code is not installed, nothing is reported. If VS Code is installed without Dart Code, a warning is shown.
* Reject requests for hot reload if a hot reload is already in progress.
Fixes#14184
* Implement TODO, verifying further hot reloads complete sucessfully.
* Fix year on new file.
* Add missing type annotations to fix lints
* Add run_machine_concurrent_hot_reload to manifest for CI
* Reformat document
... but undo things that cause lints (like single-line ifs)
* Extract std stream transformations
* Make inProgressHotReload private
* Disallow all types of reload while hot reload in progress
* Simplify code handling in-progress hot reloads
While the documentation for MaterialType.canvas described it as
an infinite shape. The implementation has been clipping it to the
bounding rectangle for a while. And it is already used in the wild as a
rectangular piece. So we just update the documentation to match that.
Applies horizontal and bottom safe area insets to the Shrine demo in the
Gallery. Top insets are not applied due to the presence of the
omnipresent sliver app bar. Specifically, this ensures that the grid
cards are inset inside the iPhone X notch in horizontal mode, and that
the bottom of the grid is positioned above the iOS home indicator.
This changes the publishing of archives so that it happens on the chrome_infra bots when they build a packaged branch instead of as part of the dev_roll process.
It uses the tagged version in the branch, and leaves the git repo that it clones checked out on the branch and hash used to build the package.
It updates metadata located at gs://flutter_infra/releases/releases_.json (where is one of macos, linux, or windows) once published, since it would be complex to do the proper locking to keep them all in one shared .json file safely.
A separate [change to the chrome_infra bots](https://chromium-review.googlesource.com/c/chromium/tools/build/+/902823) was made to instruct them to build packaged for the dev, beta, and release branches (but not master anymore).
This adds an API for defining the semantic node traversal order.
It adds a sortOrder argument to the Semantics widget, which is a class that can define a list of sort keys to sort on. The keys are sorted globally so that an order that doesn't have to do with the current widget hierarchy may be defined.
It also adds a shortcut sortKey argument to the Semantics widget that simply sets the sortOrder to just contain that key.
The platform side (flutter/engine#4540) gets an additional member in the SemanticsData object that is an integer describing where in the overall order each semantics node belongs. There is an associated engine-side change that takes this integer and uses it to order widgets for the platform's accessibility services.
Previously, the iOS ApplicationPackage subclasses did not mark the
bundleID constructor parameter as @required. This is passed up to the
ApplicationPackage constructor as the id parameter which is already
marked @required and is asserted to be non-null.
When diagnosing a failed Xcode build, if neither the development team
(for automatic provisioning) nor the provisioning profile (for manual
provisioning) is set, display the appropriate error message. Previously,
this method would not output the appropriate error message if a
only a development team was set.
