This should fix https://github.com/flutter/flutter/issues/134636.
The column can get really tall, especially when there's line wrapping. This is the layout on a tablet, so on a motor g4 this column is likely going to overflow.
```
RenderParagraph#66251 relayoutBoundary=up3
â creator: RichText â Text-[<'status'>] â Column â
â FutureBuilder<TestStepResult> â Padding â
â KeyedSubtree-[GlobalKey#0f29e] â _BodyBuilder â MediaQuery â
â LayoutId-[<_ScaffoldSlot.body>] â CustomMultiChildLayout â
â _ActionsScope â Actions â â¯
| parentData: offset=Offset(0.0, 600.0); flex=null; fit=null
```
Xcode uses the CONFIGURATION_BUILD_DIR build setting to determine the location of the bundle to build and install. When launching an app via Xcode with the Xcode debug workflow (for iOS 17 physical devices), temporarily set the CONFIGURATION_BUILD_DIR to the location of the bundle so Xcode can find it.
Also, added a Xcode Debug version of the `microbenchmarks_ios` integration test since it uses `flutter run --profile` without using `--use-application-binary`.
Fixes https://github.com/flutter/flutter/issues/134186.
Support for FFI calls with `@Native external` functions through Native assets on MacOS and iOS. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for MacOS and iOS.
Dylibs are bundled by (1) making them fat binaries if multiple architectures are targeted, (2) code signing these, and (3) copying them to the frameworks folder. These steps are done manual rather than via CocoaPods. CocoaPods would have done the same steps, but (a) needs the dylibs to be there before the `xcodebuild` invocation (we could trick it, by having a minimal dylib in the place and replace it during the build process, that works), and (b) can't deal with having no dylibs to be bundled (we'd have to bundle a dummy dylib or include some dummy C code in the build file).
The dylibs are build as a new target inside flutter assemble, as that is the moment we know what build-mode and architecture to target.
The mapping from asset id to dylib-path is passed in to every kernel compilation path. The interesting case is hot-restart where the initial kernel file is compiled by the "inner" flutter assemble, while after hot restart the "outer" flutter run compiled kernel file is pushed to the device. Both kernel files need to contain the mapping. The "inner" flutter assemble gets its mapping from the NativeAssets target which builds the native assets. The "outer" flutter run get its mapping from a dry-run invocation. Since this hot restart can be used for multiple target devices (`flutter run -d all`) it contains the mapping for all known targets.
### Example vs template
The PR includes a new template that uses the new native assets in a package and has an app importing that. Separate discussion in: https://github.com/flutter/flutter/issues/131209.
### Tests
This PR adds new tests to cover the various use cases.
* dev/devicelab/bin/tasks/native_assets_ios.dart
* Runs an example app with native assets in all build modes, doing hot reload and hot restart in debug mode.
* dev/devicelab/bin/tasks/native_assets_ios_simulator.dart
* Runs an example app with native assets, doing hot reload and hot restart.
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for iOS, MacOS and flutter-tester.
* packages/flutter_tools/test/general.shard/build_system/targets/native_assets_test.dart
* Unit tests the new Target in the backend.
* packages/flutter_tools/test/general.shard/ios/native_assets_test.dart
* packages/flutter_tools/test/general.shard/macos/native_assets_test.dart
* Unit tests the native assets being packaged on a iOS/MacOS build.
It also extends various existing tests:
* dev/devicelab/bin/tasks/module_test_ios.dart
* Exercises the add2app scenario.
* packages/flutter_tools/test/general.shard/features_test.dart
* Unit test the new feature flag.
Fixes https://github.com/flutter/flutter/issues/89683.
The changes to `getFlutterView` in `FlutterDeviceScreenshot` are the fix that was required, everything else was done to get tests running (such as re-generating some lockfiles and modifying the android manifest).
The code was all currently not unit tested, and there were no other easy examples to base these java unit tests off in flutter/flutter, so let me know if this approach to testing is wrong.
Resolves#134070
Adds a flag to the `test_runner.dart test` script that will cause the test runner to exit upon first failure (or, said another way, exit without retrying).
This is in parity with the `--exit` flag of `dev/devicelab/bin/run.dart`.
Fixes#134154
This PR also changes the default value of the `--exit` flag from `true` to `false`. Effectively, this is not a change in behavior since `--exit` didn't previously work.
## Description
This fixes the top level links to the platform embedders in the README that is used to create the landing page on https://master-api.flutter.dev
Fixes https://github.com/flutter/flutter/issues/133790
Provides help text for the `--task-args` option of the `test_runner` devicelab command. The current help text is just copypasta from another option's help text
Bug:None
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Some places where we are missing a forward of the `--local-engine-host` values in the benchmark code preventing local running of the benchmarks (does not affect CI usages which don't override local engine).
Add benchmarks that measure the overhead of the benchmark harness itself. We want the overhead to be minimal. Also, these numbers are useful to judge the quality of real benchmarks. If a real benchmark's result is too close to the harness overhead, then it's likely not measuring enough of useful work.
Bumps [activesupport](https://github.com/rails/rails) from 6.1.7.3 to 6.1.7.6.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/rails/rails/releases">activesupport's releases</a>.</em></p>
<blockquote>
<h2>v6.1.7.6</h2>
<p>No changes between this and 6.1.7.5. This release was just to fix file permissions in the previous release.</p>
<h2>6.1.7.5 Release</h2>
<h2>Active Support</h2>
<ul>
<li>
<p>Use a temporary file for storing unencrypted files while editing</p>
<p>[CVE-2023-38037]</p>
</li>
</ul>
<h2>Active Model</h2>
<ul>
<li>No changes.</li>
</ul>
<h2>Active Record</h2>
<ul>
<li>No changes.</li>
</ul>
<h2>Action View</h2>
<ul>
<li>No changes.</li>
</ul>
<h2>Action Pack</h2>
<ul>
<li>No changes.</li>
</ul>
<h2>Active Job</h2>
<ul>
<li>No changes.</li>
</ul>
<h2>Action Mailer</h2>
<ul>
<li>No changes.</li>
</ul>
<h2>Action Cable</h2>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="56bcc0abd3"><code>56bcc0a</code></a> Preparing for 6.1.7.6 release</li>
<li><a href="1f03e9dcbf"><code>1f03e9d</code></a> Bumping version for new release</li>
<li><a href="3a1b6150a9"><code>3a1b615</code></a> Preparing for 6.1.7.5 release</li>
<li><a href="c2af5781a9"><code>c2af578</code></a> bumping version / changelog</li>
<li><a href="c85cc667eb"><code>c85cc66</code></a> Use a temporary file for storing unencrypted files while editing</li>
<li><a href="7d949d7c81"><code>7d949d7</code></a> Preparing for 6.1.7.4 release</li>
<li>See full diff in <a href="https://github.com/rails/rails/compare/v6.1.7.3...v6.1.7.6">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/flutter/flutter/network/alerts).
</details>
This makes two changes to prepare for incoming changes to skwasm in the web engine:
* We will (at least for now) be depending on the `WebAssembly.Function` constructor in `skwasm`, which is hidden behind the `--experimental-wasm-type-reflection` flag. We need to pass that when running skwasm benchmarks.
* We are going to be upgrading the skwasm build to a newer version of emscripten, which exposes the wasm exports via the `wasmExports` property instead of the `asm` property. Make sure to support either, if passed.
Reverts flutter/flutter#133083
failing on cocoapods:
```
[2023-08-22 16:28:37.783355] [STDOUT] stdout: [ ] Error output from CocoaPods:
[2023-08-22 16:28:37.783379] [STDOUT] stdout: â³
[2023-08-22 16:28:37.783402] [STDOUT] stdout: [ ] [!] The version of CocoaPods used to generate the lockfile (1.12.1) is higher than the version of the current executable (1.11.3). Incompatibility issues may arise.
[2023-08-22 16:28:37.783423] [STDOUT] stdout:
[2023-08-22 16:28:37.783445] [STDOUT] stdout: [!] Automatically assigning platform `iOS` with version `11.0` on target `Runner` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`.
[2023-08-22 16:28:37.783469] [STDOUT] stdout:
[2023-08-22 16:28:37.784059] [STDOUT] stderr: [ ] Error: CocoaPods's specs repository is too out-of-date to satisfy dependencies.
[2023-08-22 16:28:37.784102] [STDOUT] stderr: To update the CocoaPods specs, run:
[2023-08-22 16:28:37.784126] [STDOUT] stderr: pod repo update
[2023-08-22 16:28:37.784147] [STDOUT] stderr:
```
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20new_gallery_ios__transition_perf/10590/overview
The `generate_gradle_lockfiles.dart` script was generating the gradle wrapper by building a flavor that didn't exist. In the time since the script was written, the `--config-only` flag was created and should be used instead.
Context https://github.com/flutter/flutter/pull/132406#discussion_r1300352602
## Description
This re-lands #132353 with some additional options for keeping around the staging directory, so that the recipe for publishing docs can give those options and have the staging directory left around for deploying to the website.
Reverted in #132613
## Related Issues
- https://flutter-review.googlesource.com/c/recipes/+/49580
This enables our various date picker classes to have a null `initialDate`.
It also fixes the logic of some of the widgets which used to do something when you _changed_ the `initial*` parameters, which is wrong for `initial*` properties (they by definition should only impact the initial state) and wrong for properties in general (behaviour should not change based on whether the widget was built with a new value or not, that violates the reactive design principles).
Fixes https://github.com/flutter/flutter/issues/638.
