1. 19 Mar, 2024 1 commit
  2. 04 Mar, 2024 1 commit
  3. 27 Feb, 2024 1 commit
  4. 08 Feb, 2024 1 commit
    • Daco Harkes's avatar
      Reland "Move native assets to `isolated/` directory" (#143055) · 4e70bfae
      Daco Harkes authored
      Reland of https://github.com/flutter/flutter/pull/142709.
      
      The revert of the revert is in the first commit, the fix in the commit on top.
      
      The move of the fakes for packages/flutter_tools/test/general.shard/resident_runner_test.dart was erroneous before, as it was trying to use setters instead of a private field. This PR changes the private `_devFS` field in the fake to be a public `fakeDevFS` in line with other fakes.
      
      ## Original PR description
      
      Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.
      
      This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.
      
      In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:
      
      * bin/fuchsia_tester.dart
      * lib/executable.dart
      
      The build_system/targets dir is already excluded in other build systems.
      
      So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.
      
      Context:
      
      * https://github.com/flutter/flutter/issues/142041
      4e70bfae
  5. 07 Feb, 2024 1 commit
    • auto-submit[bot]'s avatar
      Reverts "Move native assets to `isolated/` directory" (#143027) · ceca6066
      auto-submit[bot] authored
      Reverts flutter/flutter#142709
      
      Initiated by: vashworth
      
      Reason for reverting: `Mac tool_tests_general` started failing on this commit: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20tool_tests_general/15552/overview
      
      Original PR Author: dcharkes
      
      Reviewed By: {christopherfujino, chingjun, reidbaker}
      
      This change reverts the following previous change:
      Original Description:
      Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.
      
      This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.
      
      In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:
      
      * bin/fuchsia_tester.dart
      * lib/executable.dart
      
      The build_system/targets dir is already excluded in other build systems.
      
      So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.
      
      Context:
      
      * https://github.com/flutter/flutter/issues/142041
      ceca6066
  6. 06 Feb, 2024 1 commit
    • Daco Harkes's avatar
      Move native assets to `isolated/` directory (#142709) · a069e62e
      Daco Harkes authored
      Native assets in other build systems are not built with `package:native_assets_builder` invoking `build.dart` scripts. Instead all packages have their own blaze rules. Therefore we'd like to not depend on `package:native_assets_builder` from flutter tools in g3 at all.
      
      This PR aims to move the imports of `native_assets_builder` and `native_assets_cli` into the `isolated/` directory and into the files with a `main` function that are not used in with other build systems.
      
      In order to be able to remove all imports in files used by other build systems, two new interfaces are added `HotRunnerNativeAssetsBuilder` and `TestCompilerNativeAssetsBuilder`. New parameters are then piped all the way through from the entry points:
      
      * bin/fuchsia_tester.dart
      * lib/executable.dart
      
      The build_system/targets dir is already excluded in other build systems.
      
      So, after this PR only the two above files and build_system/targets import from `isolated/native_assets/` and only `isolated/native_assets/` import `package:native_assets_cli` and `package:native_assets_builder`.
      
      Context:
      
      * https://github.com/flutter/flutter/issues/142041
      a069e62e
  7. 01 Feb, 2024 1 commit
  8. 31 Jan, 2024 1 commit
  9. 25 Jan, 2024 1 commit
    • Andrew Kolos's avatar
      provide command to `FakeCommand::onRun` (#142206) · 295a9a20
      Andrew Kolos authored
      Part of work on [#101077](https://github.com/flutter/flutter/pull/141194). This is done as a separate PR to avoid a massive diff.
      
      ## Context
      1. The `FakeCommand` class accepts a list of patterns that's used to match a command given to its `FakeProcessManager`. Since `FakeCommand` can match a list of patterns, not just specifically strings, it can be used to match commands where the exact value of some arguments can't (easily) known ahead of time. For example, a part of the tool may invoke a command with an argument that is the path of a temporarily file that has a randomly-generated basename.
      2. The `FakeCommand` class provides on `onRun` parameter, which is a callback that is run when the `FakeProcessManager` runs a command that matches the `FakeCommand` in question.
      
      ## Issue
      In the event that a `FakeCommand` is constructed using patterns, the test code can't know the exact values used for arguments in the command. This PR proposes changing the type of `onRun` from `VoidCallback?` to `void Function(List<String>)?`. When run, the value `List<String>` parameter will be the full command that the `FakeCommand` matched.
      
      Example:
      ```dart
      FakeCommand(
        command: <Pattern>[
          artifacts.getArtifactPath(Artifact.engineDartBinary),
          'run',
          'vector_graphics_compiler',
          RegExp(r'--input=/.*\.temp'),
          RegExp(r'--output=/.*\.temp'),
        ],
        onRun: (List<String> command) {
          final outputPath = (() { 
            // code to parse `--output` from `command`
          })();
          testFileSystem.file(outputPath).createSync(recursive: true);
        },
      )
      ```
      295a9a20
  10. 24 Jan, 2024 1 commit
  11. 22 Jan, 2024 1 commit
  12. 19 Jan, 2024 1 commit
  13. 18 Jan, 2024 1 commit
  14. 17 Jan, 2024 1 commit
    • Daco Harkes's avatar
      Native assets: roll deps (#141684) · f5442bf9
      Daco Harkes authored
      Rolls the packages from https://github.com/dart-lang/native in the native assets implementation.
      
      Most notable we're refactoring `package:native_assets_cli` for `build.dart` use.
      Therefore, all imports to that package for Flutter/Dart should be to the implementation internals that are no longer visible for `build.dart` writers. Hence all the import updates.
      
      No behavior in Flutter apps should change.
      
      This PR also updates the template to use the latests version of `package:native_assets_cli` which no longer exposes all the implementation details.
      f5442bf9
  15. 16 Jan, 2024 1 commit
  16. 12 Jan, 2024 1 commit
  17. 03 Jan, 2024 2 commits
  18. 02 Jan, 2024 2 commits
  19. 20 Dec, 2023 1 commit
  20. 12 Dec, 2023 1 commit
    • Christopher Fujino's avatar
      [flutter_tools] catch SocketException writing to ios-deploy stdin (#139784) · fac41dde
      Christopher Fujino authored
      Fixes https://github.com/flutter/flutter/issues/139709
      
      This adds a static helper method `ProcessUtils.writelnToStdinGuarded()`, which will asynchronously write to a sub-process's STDIN `IOSink` and catch errors.
      
      In talking with Brian, it sounds like this is the best and most reliable way to catch `SocketException`s during these writes *to sub-process file descriptors* specifically (with a "real" hard drive file, the future returned by `.flush()` should complete with the write error).
      
      Also, as I note in the dartdoc to `writelnToStdinGuarded()`, the behavior seems to be different between macOS and linux.
      
      Moving forward, in any place where we want to catch exceptions writing to STDIN, we will want to use this new helper.
      fac41dde
  21. 08 Dec, 2023 1 commit
  22. 04 Dec, 2023 1 commit
  23. 30 Nov, 2023 1 commit
  24. 29 Nov, 2023 1 commit
  25. 22 Nov, 2023 1 commit
  26. 07 Nov, 2023 1 commit
  27. 01 Nov, 2023 1 commit
  28. 30 Oct, 2023 1 commit
  29. 25 Oct, 2023 1 commit
  30. 12 Oct, 2023 1 commit
  31. 28 Sep, 2023 1 commit
  32. 27 Sep, 2023 1 commit
  33. 26 Sep, 2023 1 commit
    • Victoria Ashworth's avatar
      Wait for CONFIGURATION_BUILD_DIR to update when debugging with Xcode (#135444) · 3cfe3720
      Victoria Ashworth authored
      So there appears to be a race situation between the flutter CLI and Xcode. In the CLI, we update the `CONFIGURATION_BUILD_DIR` in the Xcode build settings and then tell Xcode to install, launch, and debug the app. When Xcode installs the app, it should use the `CONFIGURATION_BUILD_DIR` to find the bundle. However, it appears that sometimes Xcode hasn't processed the change to the build settings before the install happens, which causes it to not be able to find the bundle.
      
      Fixes https://github.com/flutter/flutter/issues/135442
      
      --- 
      
      Since it's a timing issue, there's not really a consistent way to test it.
      
      I was able to confirm that it works, though, by using the following steps:
      1. Create a flutter project
      2. Open the project in Xcode
      3. `flutter clean`
      4. `flutter run --profile -v`
      
      If I saw a print line `stderr: CONFIGURATION_BUILD_DIR: build/Debug-iphoneos`, that means it first found the old and incorrect `CONFIGURATION_BUILD_DIR` before updating to the the new, so I was able to confirm that it would wait until it updated.
      3cfe3720
  34. 20 Sep, 2023 1 commit
  35. 18 Sep, 2023 1 commit
    • Victoria Ashworth's avatar
      Don't uninstall before retrying to connect during app launch (#134542) · abf8361a
      Victoria Ashworth authored
      When retrying to connect to the device during app launch, don't uninstall the app first.
      
      Latest test flake for https://github.com/flutter/flutter/issues/120808:
      https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8770202475999850785/+/u/run_hot_mode_dev_cycle_ios__benchmark/test_stdout
      
      Shows that it uninstalled and then tried debugging and failed, which would make sense since the app wasn't installed anymore.
      ```
      [2023-09-11 18:02:24.555646] [STDOUT] stdout: [   +6 ms] Lost connection to device. Trying to connect again...
      [2023-09-11 18:02:24.556949] [STDOUT] stdout: [   +1 ms] executing: /opt/s/w/ir/x/w/recipe_cleanup/tmp53fs1szo/flutter sdk/bin/cache/artifacts/libimobiledevice/idevicesyslog -u 00008030-00144DA10185402E
      [2023-09-11 18:02:24.557323] [STDOUT] stdout: [        ] executing: script -t 0 /dev/null /opt/s/w/ir/x/w/recipe_cleanup/tmp53fs1szo/flutter sdk/bin/cache/artifacts/ios-deploy/ios-deploy --id 00008030-00144DA10185402E --bundle build/ios/iphoneos/Flutter Gallery.app --app_deltas build/ios/app-delta --uninstall --noinstall --debug --no-wifi --args --enable-dart-profiling --disable-vm-service-publication --enable-checked-mode --verify-entry-points
      [2023-09-11 18:02:24.578010] [STDOUT] stdout: [  +20 ms] [....] Waiting for iOS device to be connected
      [2023-09-11 18:02:24.712631] [STDOUT] stdout: [ +134 ms] [....] Using 00008030-00144DA10185402E (N104AP, iPhone 11, iphoneos, arm64e, 16.2, 20C65) a.k.a. 'iPhone 11'.
      [2023-09-11 18:02:24.712725] [STDOUT] stdout: [        ] ------ Uninstall phase ------
      [2023-09-11 18:02:24.818293] [STDOUT] stdout: [ +105 ms] [ OK ] Uninstalled package with bundle id io.flutter.examples.gallery
      [2023-09-11 18:02:24.906833] [STDOUT] stdout: [  +88 ms] ------ Debug phase ------
      [2023-09-11 18:02:24.906924] [STDOUT] stdout: [        ] Starting debug of 00008030-00144DA10185402E (N104AP, iPhone 11, iphoneos, arm64e, 16.2, 20C65) a.k.a. 'iPhone 11' connected through USB...
      [2023-09-11 18:02:25.285252] [STDOUT] stdout: [ +378 ms] [  0%] Looking up developer disk image
      [2023-09-11 18:02:25.529937] [STDOUT] stdout: [ +244 ms] [ 90%] Mounting developer disk image
      [2023-09-11 18:02:25.545261] [STDOUT] stdout: [  +15 ms] [ 95%] Developer disk image already mounted
      [2023-09-11 18:02:25.587923] [STDOUT] stdout: [  +42 ms] Detected path to iOS debug symbols: "Symbol Path: /Users/swarming/Library/Developer/Xcode/iOS DeviceSupport/16.2 (20C65) arm64e/Symbols"
      [2023-09-11 18:02:25.857177] [STDOUT] stdout: [ +269 ms] Script started, output file is /dev/null
      [2023-09-11 18:02:25.857259] [STDOUT] stdout: [        ] Script done, output file is /dev/null
      [2023-09-11 18:02:25.857511] [STDOUT] stdout: [        ] ios-deploy exited with code 0
      [2023-09-11 18:02:25.858066] [STDOUT] stderr: [        ] Could not run build/ios/iphoneos/Flutter Gallery.app on 00008030-00144DA10185402E.
      [2023-09-11 18:02:25.858130] [STDOUT] stderr: [        ] Try launching Xcode and selecting "Product > Run" to fix the problem:
      [2023-09-11 18:02:25.858214] [STDOUT] stderr: [        ]   open ios/Runner.xcworkspace
      [2023-09-11 18:02:25.858537] [STDOUT] stdout: [        ] Installing and launching... (completed in 52.4s)
      [2023-09-11 18:02:25.858956] [STDOUT] stderr: [        ] Error launching application on iPhone 11.
      ```
      abf8361a
  36. 13 Sep, 2023 1 commit
  37. 10 Sep, 2023 1 commit
    • Daco Harkes's avatar
      Native assets support for MacOS and iOS (#130494) · aa36db1d
      Daco Harkes authored
      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.
      aa36db1d
  38. 05 Sep, 2023 1 commit