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
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.
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 updates the `.flutter-plugin-dependencies` file format to separate iOS's and macOS's SwiftPM enablement. For now, these platforms will always have the same value.
This `.flutter-plugin-dependencies` file is read by our CocoaPods scripts to determine whether we should use CocoaPods or not to inject plugins.
Part of https://github.com/flutter/flutter/issues/151567
Fixes https://github.com/flutter/flutter/issues/153777.
To summarize that issue, `ErrorHandlingFileSystem.systemTempDirectory` calls [`LocalFileSystem.systemTempDirectory`](45c8881eb2/packages/flutter_tools/lib/src/base/file_system.dart (L229)), which makes a `Directory.createSync` call, which can throw exceptions that _should_ be handled and result in a graceful tool exit (e.g. insufficient storage). However, we aren't catching those, hence this issue.
All we need to do is wrap that call with the `FileSystemException`-handling logic we already have in the tool. See the diff.
I don't think I'll be cherry-picking this since 1) it's not an extremely common crash and 2) users can probably pick apart the crash message and figure out that they need to clear some storage space to proceed.
<details>
<summary> Pre-launch checklist </summary>
</details>
This PR addresses an issue where the `CupertinoAlertDialog` was not fully visible in dark mode. The dialog now adapts better to dark mode themes, ensuring proper contrast and readability across different UI elements.
Fixes: #80921
Removes duplicated constants and ensures consistency by using package:vm_service as a source of truth for RPC error codes for requests made with package:vm_service.
**PR Title:**
Remove block and line comments when detecting `'.flutter-plugins'` in `settings.gradle`
---
**Description:**
This PR modifies the `configureLegacyPluginEachProjects` function to remove block (`/* ... */`) and line (`// ...`) comments from the `settings.gradle` or `settings.gradle.kts` file content before checking for the presence of the `'.flutter-plugins'` string. This ensures that only uncommented, meaningful code is considered during the detection, preventing false positives when the string appears within comments.
**Why is this change necessary?**
In some cases, the `'.flutter-plugins'` string may be present inside comments in the `settings.gradle` file. The existing implementation does not account for this and may incorrectly detect the string even when it's commented out. This can lead to unintended behavior, such as configuring plugin projects when it is not necessary.
By removing comments before performing the check, we prevent false positives and ensure that the detection logic is accurate, only acting when the `'.flutter-plugins'` string is present in active code.
**Changes Made:**
- **Added comment removal logic:**
- Removed block comments (`/* ... */`) using the regular expression `/(?s)\/\*.*?\*\//`.
- The `(?s)` flag enables dot-all mode, allowing `.` to match newline characters.
- Removed line comments (`// ...`) using the regular expression `/(?m)\/\/.*$`.
- The `(?m)` flag enables multi-line mode, so `^` and `$` match the start and end of each line.
- Combined both comment removal steps into a single chain for efficiency.
- **Updated the string detection:**
- The check for `'.flutter-plugins'` is now performed on the uncommented content of the `settings.gradle` file.
- This ensures that only meaningful, uncommented code is considered during detection.
**Issue Fixed:**
- Fixes [#155484](https://github.com/flutter/flutter/issues/155484)
---
---
If you need any further assistance or have questions, feel free to reach out!
---
**Links:**
- [Contributor Guide]
- [Tree Hygiene]
- [Flutter Style Guide]
- [Features we expect every widget to implement]
- [CLA]
- [flutter/tests]
- [breaking change policy]
- [Discord]
- [Data Driven Fixes]
This change makes `_SelectableRegionContainerDelegate` public so it can be reused and extended by users of `SelectionContainer`. Extending `MultiSelectableRegionContainerDelegate` does not by default provide selection managing across multiple selectables, so often users will copy the implementation found in `_SelectableRegionContainerDelegate`.
`_SelectableRegionContainerDelegate` -> `StaticSelectionContainerDelegate`.
Work towards https://github.com/flutter/flutter/issues/56591.
I explicitly want an LGTM from @andrewkolos @jmagman @jonahwilliams before merging.
---
After this PR, `<Plugin>.isDevDependency` is resolved based on the following logic, IFF:
- The plugin comes from a package _A_ listed in the app's package's `dev_dependencies: ...`
- The package _A_ is not a normal dependency of any transitive non-dev dependency of the app
See [`compute_dev_dependencies_test.dart`](51676093a3/packages/flutter_tools/test/general.shard/compute_dev_dependencies_test.dart) for probably the best specification of this behavior.
We (still) do not write the property to disk (i.e. it never makes it to `.flutter-plugins-dependencies`), so there is no impact to build artifacts at this time; that would come in a follow-up PR (and then follow-up follow-up PRs for the various build systems in both Gradle and Xcode to actually use that value to omit dependencies).
Some tests had to be updated; for the most part it was updating the default `ProcessManager` because a call to `dart pub deps --json` is now made in code that computes what plugins are available, but there should be no change in behavior.
_/cc @jonasfj @sigurdm for FYI only (we talked on an internal thread about this; see https://github.com/dart-lang/sdk/issues/56968)._
_/cc @camsim99 @cbracken @johnmccutchan for visibility on the change._
Adding control over the cursor to CupertinoSearchTextField: cursorWidth, cursorHeight, cursorRadius, cursorOpacityAnimates and cursorColor.
fixes https://github.com/flutter/flutter/issues/158239
The test was immediately checking the contents of stdout after the daemon indicated that the hot reload had completed. This could cause a race since the reloaded code may not have had time to execute.
Fixes https://github.com/flutter/flutter/issues/158245
Almost all of the code is just adopting to changes to the APIs of
`package:native_assets_builder`, `package:native_assets_cli` and
`package:native_toolchain_c`
There's only two semantic changes
* Removes a test that checks for a verification error if a build hook
produces a static library if the preferred linking mode is dynamic:
=> The test is written in a very hacky way. By monkey patching the build
config.json that flutter build actually made. This monkey patching
relies on package:cli_config which is now no longer used.
=> The actual code that checks for this mismatch lives in
dart-lang/native repository and is tested there. So there's really no
need to duplicate that.
* The `package:native_assets_builder` no longer knows about code assets.
This is something a user of that package (e.g. flutter tools) adds. Now
the dry-run functionality will invoke build hooks who produce code
assets without an architecture.
=> The `package:native_assets_builder` used to expand such a code asset
to N different code assets (one for each supported architecture)
=> This logic was now moved to flutter tools. => In the near future
we're going to this dry-run complexity, which will then also get rid of
this uglyness (of expanding to all archs of an OS).
## Description
This PR fixes some typos on `MenuAnchor` and improve the readability of a `DropdownMenu` test utility function.
@justinmc I'm still considering creating a test utils file for DropdownMenu but there are few utilities and I'm worried that helper functions in utils file will cripple completion results (not a big deal because it is just for people working on the framework) but I think this should be used carefully. For instance the function `getButtonMaterial` would have to be renamed to something less generic if exposed more broadly (`getMenuItemButtonMaterial` for instance).
This PR fixes the `shouldCloseOnMinExtent` flag in `draggable_scrollable_sheet.dart`.
*The `shouldCloseOnMinExtent` flag was not functioning correctly in the `DraggableScrollableSheet` widget. This PR ensures that the flag is properly handled, preventing the sheet from closing when it reaches the minimum extent if the flag is set to false. Before/after screenshots are not applicable for this change.*
In the code sample below, before my fix, the sheet would close when scrolled down. After my fix, it behaves as expected by respecting the `shouldCloseOnMinExtent` parameter.
### Code Sample
```dart
import 'package:flutter/material.dart';
Future<void> main() async {
runApp(const MaterialApp(
home: Home(),
));
}
class Home extends StatelessWidget {
const Home({
super.key,
});
@override
Widget build(BuildContext context) => Scaffold(
body: Center(
child: FilledButton(
onPressed: () async => showModalBottomSheet(
context: context,
isScrollControlled: true,
isDismissible: false,
builder: (context) => DraggableScrollableSheet(
expand: false,
maxChildSize: 0.9,
minChildSize: 0.25,
initialChildSize: 0.5,
shouldCloseOnMinExtent: false,
builder: (context, scrollController) => Navigator(
onGenerateRoute: (settings) => MaterialPageRoute(
settings: settings,
builder: (context) => ListView.builder(
controller: scrollController,
itemExtent: 100,
itemCount: 100,
itemBuilder: (context, index) => Center(
child: Text('$index'),
),
),
),
),
),
),
child: const Text('Open sheet'),
),
),
);
}
```
While doing some hacking on `Cache` in https://github.com/flutter/flutter/pull/158081, I noticed that [`Cache.test`](de93182753/packages/flutter_tools/lib/src/cache.dart (L139)) allows the caller to tell Cache to use some given directory as the flutter root (instead of depending on the static global [`Cache.flutterRoot`](4f3976a4f2/packages/flutter_tools/lib/src/cache.dart (L206))). This has a default value, `/cache`. However, `/cache` is an unintuitive name for the root directory of a Flutter installation.
This led to confusion when updating some tests. I wanted to create `/bin/cache/engine-dart-sdk.stamp` for tests, but in reality I needed to create `/cache/bin/cache/engine-dart-sdk.stamp`.
This PR changes this default to the current directory of the file system (which I'm guessing is `/` for all intents and purposes).
<details>
<summary> Pre-launch checklist </summary>
</details>
Currently the bot that runs `flutter update-packages` makes PRs that
fail due to native asset integration tests failing.
The root cause is due to incompatible versions on `package:logging`. The
bot tries to upgrade `package:logging` from `1.2.0` to `1.3.0`.
Here's what seems to happen:
* `flutter update-packages` will update
`dev/integration_tests/link_hook/pubspec.yaml` with `package:logging` to
`1.3.0` (as it does with all other `pubspec.yaml` files in the flutter
repository)
* `flutter create --template=package_ffi` will generate a template with
`package:logging` `^1.2.0`
* The test in question
* creates ffi template (which will use `^1.2.0`)
* make it depend on `dev/integration_tests/link_hook` (which uses
`=1.3.0`)
* changes logging dependency from the template from `^1.2.0` to `=1.2.0`
IMHO
* `flutter update-packages` is doing what it's supposed to
* `flutter create --template=package_ffi` can generate templates with
versions it determines (maybe there are use cases where we want to
generate templates with older versions)
* The problematic part is the test:
* it makes the generated template depend on `link_hook` and
* changes template generated pubspec to use pinned dependencies
This PR makes the test package (created via template) use the pinned
package versions from `dev/integration_tests/link_hook` (for
dependencies that are common among the two).
All other dependencies that the template has on top of
`dev/integration_tests/link_hook` it can pin as it does currently.
This will give us deterministic CI behavior (as we use flutter pined
packages and remaining deps being pinned via template) It avoids
changing the `flutter update-packages` and `flutter create
--template=package_ffi` (as their behavior seems reasonable)
Should fix https://github.com/flutter/flutter/issues/158135
removed public modifier from this methods :`getVersionCode` , `getVersionName`.
add static to :`pluginSupportsAndroidPlatform` ,`buildGradleFile`,`settingsGradleFile`
`getCompileSdkFromProject` ,`getAssembleTask`
refactor `==null` usage to `:?` to unify the usage
see https://github.com/flutter/flutter/issues/147122 for context
