1. 05 Jan, 2024 1 commit
  2. 03 Jan, 2024 1 commit
  3. 02 Jan, 2024 2 commits
  4. 20 Dec, 2023 1 commit
  5. 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
  6. 08 Dec, 2023 1 commit
  7. 04 Dec, 2023 1 commit
  8. 30 Nov, 2023 1 commit
  9. 29 Nov, 2023 1 commit
  10. 22 Nov, 2023 1 commit
  11. 07 Nov, 2023 1 commit
  12. 01 Nov, 2023 1 commit
  13. 30 Oct, 2023 1 commit
  14. 25 Oct, 2023 1 commit
  15. 19 Oct, 2023 1 commit
  16. 18 Oct, 2023 2 commits
  17. 17 Oct, 2023 2 commits
    • auto-submit[bot]'s avatar
      Reverts "Skip injecting Bonjour settings when port publication is disabled" (#136750) · 54c0a350
      auto-submit[bot] authored
      Reverts flutter/flutter#136562
      Initiated by: vashworth
      This change reverts the following previous change:
      Original Description:
      Some of our tests in CI are triggering the `NSLocalNetworkUsageDescription` dialog when they're not supposed to (https://github.com/flutter/flutter/issues/129836) since it's disabled via flags (`--no-publish-port` for flutter/flutter and `--disable-vm-service-publication` for flutter/engine).
      
      Normally, we inject `NSLocalNetworkUsageDescription` (and other bonjour settings) to the Info.plist during the project build for debug and profile mode since by default they will publish the VM Service port over mDNS.
      
      To help diagnose the issue, though, this PR changes it so that we don't inject `NSLocalNetworkUsageDescription` (and other bonjour settings) when port publication is disabled since it shouldn't be needed. Hopefully, this will give us better error messages or cause the app to crash and end the test early (rather than timeout after 30 minutes).
      54c0a350
    • Victoria Ashworth's avatar
      Skip injecting Bonjour settings when port publication is disabled (#136562) · 0383d8ba
      Victoria Ashworth authored
      Some of our tests in CI are triggering the `NSLocalNetworkUsageDescription` dialog when they're not supposed to (https://github.com/flutter/flutter/issues/129836) since it's disabled via flags (`--no-publish-port` for flutter/flutter and `--disable-vm-service-publication` for flutter/engine).
      
      Normally, we inject `NSLocalNetworkUsageDescription` (and other bonjour settings) to the Info.plist during the project build for debug and profile mode since by default they will publish the VM Service port over mDNS.
      
      To help diagnose the issue, though, this PR changes it so that we don't inject `NSLocalNetworkUsageDescription` (and other bonjour settings) when port publication is disabled since it shouldn't be needed. Hopefully, this will give us better error messages or cause the app to crash and end the test early (rather than timeout after 30 minutes).
      0383d8ba
  18. 27 Sep, 2023 1 commit
  19. 26 Sep, 2023 2 commits
  20. 21 Sep, 2023 1 commit
  21. 19 Sep, 2023 1 commit
    • Greg Spencer's avatar
      Remove 'must be non-null' and 'must not be null' comments from non-framework libraries (#134994) · 4ce7fdd9
      Greg Spencer authored
      ## Description
      
      This removes all of the comments that are of the form "so-and-so must not be null" or "so-and-so must be non-null" from the cases where those values are defines as non-nullable values.
      
      This PR removes them from the library in the repo that don't have anything to do with the framework.
      
      This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
      
      In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
      
      This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases.  I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
      
      ## Related PRs
      - https://github.com/flutter/flutter/pull/134984
      - https://github.com/flutter/flutter/pull/134991
      - https://github.com/flutter/flutter/pull/134992
      - https://github.com/flutter/flutter/pull/134993
      
      ## Tests
       - Documentation only change.
      4ce7fdd9
  22. 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
  23. 13 Sep, 2023 1 commit
  24. 12 Sep, 2023 1 commit
  25. 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
  26. 05 Sep, 2023 1 commit
  27. 31 Aug, 2023 1 commit
    • chunhtai's avatar
      Removes ios universal link vmservices and let xcodeproject to dump js… (#133709) · 0b3b8cd5
      chunhtai authored
      …on file
      
      The deeplink validation tool will become an static app so it can't no longer access vm services.
      
      The goal will be then to turn them into flutter analyze command similar to `flutter analyze --android --[options]` that static app can use on.
      
      This pr only removes vm services and turn the api to dump a output file instead of printing everything to stdout.
      0b3b8cd5
  28. 16 Aug, 2023 1 commit
  29. 15 Aug, 2023 1 commit
  30. 14 Aug, 2023 1 commit
    • Victoria Ashworth's avatar
      Fix log filtering and CI tests for iOS 17 physical devices (#132491) · ec0b7443
      Victoria Ashworth authored
      Fixes a couple of issues introduced in new iOS 17 physical device tooling: https://github.com/flutter/flutter/pull/131865.
      
      1) Duplicate messages were being filtered out too aggressively. 
      
      For example, if on the counter app, you printed "Increment!" on button click, it would only print once no matter how many times you clicked.
      
      Sometimes more than one log source is used at a time and the original intention was to filter duplicates between two log sources, so it wouldn't print the same message from both logs. However, it would also filter when the same message was added more than once via the same log.
      
      The new solution distinguishes a "primary" and a "fallback" log source and prefers to use the primary source unless it's not working, in which it'll use the fallback. If the fallback is faster than the primary, the primary will exclude the logs received by the fallback in a 1-to-1 fashion to prevent too-aggressive filtering. Once a flutter-message has been received by the primary source, fallback messages will be ignored.
      
      Note: iOS < 17 did not regress.
      
      2) There was a race condition between the shutdown hooks and exiting XcodeDebug that was causing a crash when deleting a file that doesn't exist. This only affects CI  - for the new integration tests and when testing with iOS 17 physical devices.
      ec0b7443
  31. 09 Aug, 2023 1 commit
    • Victoria Ashworth's avatar
      New tooling for iOS 17 physical devices (#131865) · d631b262
      Victoria Ashworth authored
      This PR includes the following changes. These changes only apply to iOS 17 physical devices.
      
      | Command | Change Description  | Changes to User Experience |
      | ------------- | ------------- | ------------- |
      | `flutter run --release` | Uses `devicectl` to install and launch application in release mode.  | No change.  |
      | `flutter run`  | Uses Xcode via automation scripting to run application in debug and profile mode. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
      | `flutter run --use-application-binary=xxxx` | Creates temporary empty Xcode project and use Xcode to run via automation scripting in debug and profile. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal.  |
      | `flutter install` | Uses `devicectl` to check installed apps, install app, uninstall app.  | No change.  |
      | `flutter screenshot` | Will return error.  | Will return error.  |
      
      Other changes include:
      * Using `devicectl` to get information about the device
      * Using `idevicesyslog` and Dart VM logging for device logs
      
      Note:
      Xcode automation scripting (used in `flutter run` for debug and profile) does not work in a headless (without a UI) interface. No known workaround.
      
      Fixes https://github.com/flutter/flutter/issues/128827, https://github.com/flutter/flutter/issues/128531.
      d631b262
  32. 08 Aug, 2023 1 commit
  33. 04 Aug, 2023 1 commit
    • Victoria Ashworth's avatar
      Check for simulator runtime in flutter doctor (#131795) · b39604e0
      Victoria Ashworth authored
      Redo of https://github.com/flutter/flutter/pull/130728 - code is the same as before. That PR was stuck in Google testing and then I messed up the rebase so started over.
      
      ----
      
      Starting in Xcode 15, the simulator is no longer included in Xcode and must be downloaded and installed separately. This adds a validation to `flutter doctor` to warn when the needed simulator runtime is missing.
      
      Validation message looks like:
      ```
      [!] Xcode - develop for iOS and macOS (Xcode 15.0)
          ! iOS 17.0 Simulator not installed; this may be necessary for iOS and macOS development.
            To download and install the platform, open Xcode, select Xcode > Settings > Platforms,
            and click the GET button for the required platform.
      
            For more information, please visit:
              https://developer.apple.com/documentation/xcode/installing-additional-simulator-runtimes
      ```
      
      It may also show an error like this when something goes wrong when checking for the simulator:
      ```
      [!] Xcode - develop for iOS and macOS (Xcode 15.0)
          ✗ Unable to find the iPhone Simulator SDK.
      ```
      
      Note: I'm unsure of in the future if the SDK and the simulator runtime will need to match the exact version or just the major. For now, it only checks against the major version.
      
      Part 3 of https://github.com/flutter/flutter/issues/129558.
      b39604e0
  34. 17 Jul, 2023 1 commit
  35. 13 Jul, 2023 2 commits