Towards https://github.com/flutter/flutter/issues/159000 as part of
debugging issues such as
https://github.com/flutter/flutter/issues/158560.
On a `bringup: true` shard, run a number of `flutter build apk` tests in
succession to try and routinely trigger timeouts and crashes, so we can
test other hypotheses on how to fix this problem (i.e. potentially
around increasing memory, changing daemon configuration, aggressively
killing processes, etc).
## Description
This makes the `focusNode` for `SelectableRegion` optional so that:
- Users of the widget are no longer required to use `SelectableRegion`
from within a `StatefulWidget`
- They aren't likely to forget to dispose of a node they didn't supply.
- Simpler to use, and the node is not used very often anyhow.
Also made the `SelectableRegion` sample actually use `SelectableRegion`.
## Tests
- Modified all the `SelectableRegion` tests to remove 3 identical lines
of boilerplate from each (except 2, which actually used their focus
nodes).
Currently the `NativeAsset` target in flutter tools is responsible for
two things:
* performing the dart build (in the app as well as all transitive pub
dependencies)
* taking output (shared libraries) from this build and copying them
around
This intermingling of responsibilities leads to more complex code and
potentially unnecessary work: If the source code changed (e.g. `.c`
files change) we have to run the dart build again. But doing so may
result in the same shared libraries (e.g. adding comments to the `.c`
code). Currently we're going to copy the shared libraries despite them
having not changed, which then may cause upstream things to be dirtied
(if it's based on timestamp of files) and re-built.
Instead this PR splits this `NativeAsset` into the two orthogonal pieces
* `DartBuild` target that is responsible for the dart build
* `InstallCodeAssets` that is responsible for copying shared libraries
to the right place and producing a `native_assets.yaml`.
This decoupling is also preparation for a future where a dart build can
produce other kinds of assets (e.g. data assets) and is used in the web
build as well. (The web build would use `DartBuild` but not
`InstalCodeAssets`).
After the dart build is done, the flutter tool has to bundle the
produced shared libraries, which it does that by copying them around.
Though the code assumed that all code assets are shared libraries to be
bundled, whereas in fact one can have code assets without any actual
code (ones that are installed on the target system already or artificial
code assets whose symbols get resolved from executable / process).
=> Using non-bundled code assets currently results in null pointer
exceptions and/or cast errors.
=> We update the copy code to only operate on code assets that have a
shared library to bundle.
We also update the copy routines by removing copy&past'ed - but slightly
different - printing code into the shared caller function.
In release builds linking of native assets is enabled. The build step is
only a temprary step, it's output is given to the link step which then
returns all final assets (effectively a map-reduce system). Assets that
aren't sent to a specific linker could be conceptually viewed as sent to
a linker that will emit it's input as-is.
=> The code currently took output of build & link step and therefore
accumulated assets that aren't explicitly sent to a linker twice.
=> This led to performing work twice for those (e.g. copying them twice)
This PR changes this such that if linking mode is enabled, we only rely
on the output of the link phase.
That in return means many tests that mock the native asset builds need
to be updated to mock the output of the link phase.
This started happening after moving DDS to launch from `dart
development-service` rather than `DartDevelopmentService` (see
33b402d24c2131dcf97e272ec3d59c0249762e7f) . This state error was
originally meant to be thrown when some string parsing failed, but is
currently wrapping the `DartDevelopmentServiceException`.
Fixes https://github.com/flutter/flutter/issues/158537
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Mac_x64 hot_mode_dev_cycle_macos_target__benchmark"
}
-->
Issue link: https://github.com/flutter/flutter/issues/158568
This adds support for web 1.x.x to be included in the plugin template, when creating a web plugin.
I don't have an issue referenced. Related to https://github.com/dart-lang/web/issues/316
I was poking around in logger.dart when I noticed a few classes have unnecessary exposed member variables. This PR reduces visibility of these in the pursuit of making these classes slightly easier to grok.
<details>
<summary> Pre-launch checklist </summary>
</details>
Cleans up https://github.com/flutter/flutter/pull/155800. In summary, `ResidentRunner`/`FlutterDevice` have branching behavior around logging that depends on the type of `DeviceLogReader` on the `FlutterDevice` instance. Let's instead move this behavior to the `DeviceLogReader` implementations.
My apologies for the large diff. Much of this is a refactor that was a bit too difficult to separate into its own commits.
Here are the main two changes
* Replaces the mutable `connectedVmService` field on the `DeviceLogReader` class with a new method `provideVmService`. This serves largely the same purpose as the mutable field, but it allows for asynchronous code. This is where we put the logic that used to exist in `FlutterDevice.tryInitLogReader`.
* Removes the `tryInitLogReader` method from `FlutterDevice`. This method served to set the `appPid` field on the `FlutterDevice`'s `DeviceLogReader` instance. This was only used in the case of Android to filter out logs unrelated to the flutter app coming from the device, so we can move this logic to `AdbLogReader`'s implementation of `provideVmService`.
Revised comments to clarify that clipping of child depends on clipBehavior of the parent widget, typically scrollable widgets that default to Clips.hard.
Noted that decoration features such as shadows , which render outside the widget boundary, may lead to undesirable effects.
Recommended using Clips.none in scenarios where shadow effects are used to avoid clipping issues.
Fixing Issue #156819
Adds special handling of the newly-imported `flutter_svg` and
`vector_graphics` family of packages in the triage flow chart, as they
should be directed to the engine team.
This PR adds a `MenuAnchor` test to check that `MenuAnchor.alignmentOffset` is correctly applied when `MenuAnchor.layerlink` is provided.
While reviewing https://github.com/flutter/flutter/pull/158255, I found that this new test would be useful.
Closes https://github.com/flutter/flutter/issues/158012.
This is (effectively) a user-facing NOP, which is exchanging an
on-by-default command-line argument (`--implicit-pubspec-resolution`)
for an off-by-default global feature flag
(`explicit-package-dependencies`). It matches the mental model better,
is less painstaking to maintain and feed throughout, and will be easier
to globally flip on/off in a future PR.
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
It would be nice to have somewhere to iterate and experiment with what we can do to either fix frequent timeout problems we have with `flutter build apk` (across platforms, to be clear, though I've just started with Linux) or get more information on why the crashes/timeouts happen.
Open to other ways to doing this (though preferably _not_ LED).
Fixes https://github.com/flutter/flutter/issues/156565
This update corrects the `TimeOfDayFormat` mapping for the Hindi language. Previously, the format was incorrectly set to `a_space_h_colon_mm` - (a h:mm), but it should be `h_colon_mm_space_a` - (h:mm a) since Hindi is a LTR language.
Fixes#158158
Similar to 154484, but addressing more fundamental causes. We should call the child's `didUpdateWidget` before the child's `build` when states change.
1. Remove redundant code but keep the old test because we don't need it after this fix.
2. Add getters of `lastShrinkOffset` and `lastOverlapsContent` that are needed when `SliverAppBar.update`.
3. Add a test with a custom TabBar to avoid breaking when some changes to the default TabBar.
This PR is for issue #154792
The Video recording shows the before and after
The first button with the text "Go" uses the default cursor
The second button with the text "With Cursor" uses a custom cursor that has been passed in the parameters
https://github.com/user-attachments/assets/e82ecd42-42b1-42c9-aa30-a6f3daddb436
Here is the code for the second button
```dart
CupertinoButton(
onPressed: () {
showCupertinoModalPopup<void>(
context: context,
builder: (BuildContext context) {
return CupertinoActionSheet(
title: const Text('The title'),
message: const Text('Message'),
actions: <Widget>[
CupertinoActionSheetAction(
cursor: SystemMouseCursors.forbidden,
child: const Text('One'),
onPressed: () {},
),
],
);
},
);
},
child: const Text('With Cursor'),
),
```
Fixes https://github.com/flutter/flutter/issues/154792
Reverts: flutter/flutter#158242
Initiated by: LouiseHsu
Reason for reverting: Flake rate is low, and the arm64 macs in the staging pools are having difficulties
Original PR Author: fluttergithubbot
Reviewed By: {LouiseHsu}
This change reverts the following previous change:
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Mac_arm64_ios hot_mode_dev_cycle_ios__benchmark"
}
-->
Issue link: https://github.com/flutter/flutter/issues/158241
In the future, it will be possible for Swift Package Manager to be enabled on one but not all platforms (see https://github.com/flutter/flutter/issues/151567#issuecomment-2455941279).
This moves the `usesSwiftPackageManager` property from the platform-agnostic `Project` to the platform-specific `IosProject` and `MacOSProject`.
This will allow the `IosProject` and `MacOSProject` to return different values for `usesSwiftPackageManager` in the future. For now, both of these projects will always return the same value.
Part of https://github.com/flutter/flutter/issues/151567
## Description
Adding reference to the Human Interface documentation about Haptics in the `HapticFeedback` docs.
The Human Haptic Guidelines documentation are excellent since they provide visualizations that show how these different haptics actually are with some interactive demos, for example with Impact haptics (see image below). Such helps developers decide what haptic to go for and understand when they should be used.
<img width="675" alt="Screenshot 2024-11-13 at 15 13 10" src="https://github.com/user-attachments/assets/909240d3-1981-4e25-9bed-b3b52154e662">
Closes https://github.com/flutter/flutter/issues/157629.
Avoids failures in the style:
```txt
00:37 +4597 ~3 -1: /Users/matanl/Developer/flutter/packages/flutter_tools/test/commands.shard/permeable/build_appbundle_test.dart: analytics logs success [E]
Expected: contains Event:<{"eventName":"flutter_command_result","eventData":{"commandPath":"create","result":"success","commandHasTerminal":false,"maxRss":147013632}}>
Actual: [
Event:{"eventName":"command_usage_values","eventData":{"workflow":"create","commandHasTerminal":false,"createProjectType":"app","createAndroidLanguage":"kotlin","createIosLanguage":"swift"}},
Event:{"eventName":"flutter_command_result","eventData":{"commandPath":"create","result":"success","commandHasTerminal":false,"maxRss":143261696}},
Event:{"eventName":"timing","eventData":{"workflow":"flutter","variableName":"create","elapsedMilliseconds":527,"label":"success"}},
Event:{"eventName":"command_usage_values","eventData":{"workflow":"appbundle","commandHasTerminal":false,"buildAppBundleTargetPlatform":"android-arm,android-arm64,android-x64","buildAppBundleBuildMode":"release"}},
Event:{"eventName":"flutter_command_result","eventData":{"commandPath":"appbundle","result":"success","commandHasTerminal":false,"maxRss":147013632}},
Event:{"eventName":"timing","eventData":{"workflow":"flutter","variableName":"appbundle","elapsedMilliseconds":10,"label":"success"}}
]
Which: does not contain Event:<{"eventName":"flutter_command_result","eventData":{"commandPath":"create","result":"success","commandHasTerminal":false,"maxRss":147013632}}>
```
I am guessing <https://api.flutter.dev/flutter/dart-io/ProcessInfo/maxRss.html> is not guaranteed to be stable while running, and as a result is not. This stabilizes the value for a test that I believe does not care about getting the "real" value anyway.
