1. 26 Jan, 2024 2 commits
    • Andrew Kolos's avatar
      Remove duplicate global declaration of `UserMessages` (#142281) · 69c98bd9
      Andrew Kolos authored
      Fixes https://github.com/flutter/flutter/issues/142286
      
      This is a refactor. No code behavior changes should be observed.
      69c98bd9
    • Pierrick Bouvier's avatar
      Enable native compilation for windows-arm64 (#141930) · 37c3978b
      Pierrick Bouvier authored
      It's now possible to natively compile a flutter app for windows-arm64. Cross-compilation is not yet implemented.
      
      Uses arm64 artifacts now available for Dart/Flutter. Platform detection is based on Abi class, provided by Dart. Depending if Dart is an arm64 or x64 binary, the Abi is set accordingly. Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking PROCESSOR_ARCHITECTURE environment variable, which is the way to detect host architecture on Windows.
      
      This is available only for master channel (on other channels, it fallbacks to windows-x64).
      
      On windows-x64, it produces an x64 app. On windows-arm64, it produces an arm64 app.
      37c3978b
  2. 25 Jan, 2024 1 commit
  3. 18 Jan, 2024 2 commits
    • auto-submit[bot]'s avatar
      Reverts "Enable native compilation for windows-arm64 " (#141809) · 1901d6fa
      auto-submit[bot] authored
      Reverts flutter/flutter#137618
      Initiated by: Jasguerrero
      This change reverts the following previous change:
      Original Description:
      It's now possible to natively compile a flutter app for
      windows-arm64. Cross-compilation is not yet implemented.
      
      Uses arm64 artifacts now available for Dart/Flutter.
      Platform detection is based on Abi class, provided by Dart. Depending if
      Dart is an arm64 or x64 binary, the Abi is set accordingly.
      Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking
      PROCESSOR_ARCHITECTURE environment variable, which is the way to detect
      host architecture on Windows.
      
      This is available only for master channel (on other channels, it
      fallbacks to windows-x64).
      
      On windows-x64, it produces an x64 app. On windows-arm64, it produces an
      arm64 app.
      1901d6fa
    • Pierrick Bouvier's avatar
      Enable native compilation for windows-arm64 (#137618) · 54055920
      Pierrick Bouvier authored
      It's now possible to natively compile a flutter app for
      windows-arm64. Cross-compilation is not yet implemented.
      
      Uses arm64 artifacts now available for Dart/Flutter.
      Platform detection is based on Abi class, provided by Dart. Depending if
      Dart is an arm64 or x64 binary, the Abi is set accordingly.
      Initial bootstrap of dart artifacts (update_dart_sdk.ps1) is checking
      PROCESSOR_ARCHITECTURE environment variable, which is the way to detect
      host architecture on Windows.
      
      This is available only for master channel (on other channels, it
      fallbacks to windows-x64).
      
      On windows-x64, it produces an x64 app. On windows-arm64, it produces an
      arm64 app.
      54055920
  4. 16 Jan, 2024 1 commit
  5. 03 Jan, 2024 1 commit
  6. 02 Jan, 2024 2 commits
  7. 14 Dec, 2023 1 commit
  8. 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
  9. 08 Dec, 2023 1 commit
    • auto-submit[bot]'s avatar
      Reverts "Support conditional bundling of assets based on `--flavor`" (#139787) · 21766a4f
      auto-submit[bot] authored
      Reverts flutter/flutter#132985
      Initiated by: christopherfujino
      This change reverts the following previous change:
      Original Description:
      Provides support for conditional bundling of assets through the existing `--flavor` option for `flutter build` and `flutter run`. Closes https://github.com/flutter/flutter/issues/21682. Resolves https://github.com/flutter/flutter/issues/136092
      
      ## Change
      Within the `assets` section pubspec.yaml, the user can now specify one or more `flavors` that an asset belongs to. Consider this example:
      
      ```yaml
      # pubspec.yaml
      flutter:
        assets:
          - assets/normal-asset.png
          - path: assets/vanilla/ice-cream.png
            flavors: 
              - vanilla
          - path: assets/strawberry/ice-cream.png
            flavors:
              - strawberry
      ```
      
      With this pubspec,
      * `flutter run --flavor vanilla` will not include `assets/strawberry/ice-cream.png` in the build output.
      * `flutter run --flavor strawberry` will not include `assets/vanilla/ice-cream.png`.
      * `flutter run` will only include `assets/normal-asset.png`.
      
      ## Open questions
      
      * Should this be supported for all platforms, or should this change be limited to ones with documented `--flavor` support (Android, iOS, and (implicitly) MacOS)? This PR currently only enables this feature for officially supported platforms.
      
      ## Design thoughts, what this PR does not do, etc.
      
      ### This does not provide an automatic mapping/resolution of asset keys/paths to others based on flavor at runtime.
      
      The implementation in this PR represents a simplest approach. Notably, it does not give Flutter the ability to dynamically choose an asset based on flavor using a single asset key. For example, one can't use `Image.asset('config.json')` to dynamically choose between different "flavors" of `config.json` (such as `dev-flavor/config.json` or `prod-flavor/config.json`). However, a user could always implement such a mechanism in their project or in a library by examining the flavor at runtime.
      
      ### When multiple entries affect the same file and 1) at least one of these entries have a `flavors` list provided and 2) these lists are not equivalent, we always consider the manifest to be ambiguous and will throw a `ToolExit`. 
      
      <details>
      For example, these manifests would all be considered ambiguous:
      
      ```yaml
      assets:
        - assets/
        - path: assets/vanilla.png
          flavors: 
            - vanilla
      
      assets:
        - path: assets/vanilla/
          flavors: 
            - vanilla
        - path: assets/vanilla/cherry.png
           flavor:
            - cherry
      
      # Thinking towards the future where we might add glob/regex support and more conditions other than flavor:
      assets:
        - path: assets/vanilla/**
          flavors:
            - vanilla
        - path: assets/**/ios/**
          platforms: 
             - ios
      
      # Ambiguous in the case of assets like "assets/vanilla/ios/icon.svg" since we 
      # don't know if flavor `vanilla` and platform `ios` should be combined using or-logic or and-logic.
      ```
      
      See [this review comment thread](https://github.com/flutter/flutter/pull/132985#discussion_r1381909942) for the full story on how I arrived at this decision.
      </details>
      
      ### This does not support Android's multidimensional flavors feature (in an intuitive way)
      
      <details>
      
      Conder this excerpt from a Flutter project's android/app/build.gradle file:
      
      ```groovy
      android {
          // ...
      
          flavorDimensions "mode", "api"
      
          productFlavors {
              free {
                  dimension "mode"
                  applicationIdSuffix ".free"
              }
      
              premium {
                  dimension "mode"
                  applicationIdSuffix ".premium"
              }
      
              minApi23 {
                  dimension "api"
                  versionNameSuffix "-minApi23"
              }
      
              minApi21 {
                  dimension "api"
                  versionNameSuffix "-minApi21"
              }
          }
      }
      ```
      
      In this setup, the following values are valid `--flavor` are valid `freeMinApi21`, `freeMinApi23`, `premiumMinApi21`, and `premiumMinApi23`. We call these values "flavor combinations". Consider the following from the Android documentation[^1]:
      
      > In addition to the source set directories you can create for each individual product flavor and build variant, you can also create source set directories for each combination of product flavors. For example, you can create and add Java sources to the src/demoMinApi24/java/ directory, and Gradle uses those sources only when building a variant that combines those two product flavors.
      > 
      > Source sets you create for product flavor combinations have a higher priority than source sets that belong to each individual product flavor. To learn more about source sets and how Gradle merges resources, read the section about how to [create source sets](https://developer.android.com/build/build-variants#sourcesets).
      
      This feature will not behave in this way. If a user utilizes this feature and also Android's multidimensional flavors feature, they will have to list out all flavor combinations that contain the flavor they want to limit an asset to:
      
      ```yaml
      assets:
        - assets/free/
          flavors:
            - freeMinApi21
            - freeMinApi23
      ```
      
      This is mostly due to a technical limitation in the hot-reload feature of `flutter run`. During a hot reload, the tool will try to update the asset bundle on the device, but the tool does not know the flavors contained within the flavor combination (that the user passes to `--flavor`). Gradle is the source of truth of what flavors were involved in the build, and `flutter run` currently does not access to that information since it's an implementation detail of the build process. We could bubble up this information, but it would require a nontrivial amount of engineering work, and it's unclear how desired this functionality is. It might not be worth implementing.
      
      </details>
      
      See https://flutter.dev/go/flavor-specific-assets for the (outdated) design document. 
      
      <summary>Pre-launch Checklist</summary>
      
      </details>
      
      [^1]: https://developer.android.com/build/build-variants#flavor-dimensions
      21766a4f
  10. 07 Dec, 2023 1 commit
    • Andrew Kolos's avatar
      Support conditional bundling of assets based on `--flavor` (#132985) · 016eb851
      Andrew Kolos authored
      Provides support for conditional bundling of assets through the existing `--flavor` option for `flutter build` and `flutter run`. Closes https://github.com/flutter/flutter/issues/21682. Resolves https://github.com/flutter/flutter/issues/136092
      
      ## Change
      Within the `assets` section pubspec.yaml, the user can now specify one or more `flavors` that an asset belongs to. Consider this example:
      
      ```yaml
      # pubspec.yaml
      flutter:
        assets:
          - assets/normal-asset.png
          - path: assets/vanilla/ice-cream.png
            flavors: 
              - vanilla
          - path: assets/strawberry/ice-cream.png
            flavors:
              - strawberry
      ```
      
      With this pubspec,
      * `flutter run --flavor vanilla` will not include `assets/strawberry/ice-cream.png` in the build output.
      * `flutter run --flavor strawberry` will not include `assets/vanilla/ice-cream.png`.
      * `flutter run` will only include `assets/normal-asset.png`.
      
      ## Open questions
      
      * Should this be supported for all platforms, or should this change be limited to ones with documented `--flavor` support (Android, iOS, and (implicitly) MacOS)? This PR currently only enables this feature for officially supported platforms.
      
      ## Design thoughts, what this PR does not do, etc.
      
      ### This does not provide an automatic mapping/resolution of asset keys/paths to others based on flavor at runtime.
      
      The implementation in this PR represents a simplest approach. Notably, it does not give Flutter the ability to dynamically choose an asset based on flavor using a single asset key. For example, one can't use `Image.asset('config.json')` to dynamically choose between different "flavors" of `config.json` (such as `dev-flavor/config.json` or `prod-flavor/config.json`). However, a user could always implement such a mechanism in their project or in a library by examining the flavor at runtime.
      
      ### When multiple entries affect the same file and 1) at least one of these entries have a `flavors` list provided and 2) these lists are not equivalent, we always consider the manifest to be ambiguous and will throw a `ToolExit`. 
      
      <details>
      For example, these manifests would all be considered ambiguous:
      
      ```yaml
      assets:
        - assets/
        - path: assets/vanilla.png
          flavors: 
            - vanilla
      
      assets:
        - path: assets/vanilla/
          flavors: 
            - vanilla
        - path: assets/vanilla/cherry.png
           flavor:
            - cherry
      
      # Thinking towards the future where we might add glob/regex support and more conditions other than flavor:
      assets:
        - path: assets/vanilla/**
          flavors:
            - vanilla
        - path: assets/**/ios/**
          platforms: 
             - ios
      
      # Ambiguous in the case of assets like "assets/vanilla/ios/icon.svg" since we 
      # don't know if flavor `vanilla` and platform `ios` should be combined using or-logic or and-logic.
      ```
      
      See [this review comment thread](https://github.com/flutter/flutter/pull/132985#discussion_r1381909942) for the full story on how I arrived at this decision.
      </details>
      
      ### This does not support Android's multidimensional flavors feature (in an intuitive way)
      
      <details>
      
      Conder this excerpt from a Flutter project's android/app/build.gradle file:
      
      ```groovy
      android {
          // ...
      
          flavorDimensions "mode", "api"
      
          productFlavors {
              free {
                  dimension "mode"
                  applicationIdSuffix ".free"
              }
      
              premium {
                  dimension "mode"
                  applicationIdSuffix ".premium"
              }
      
              minApi23 {
                  dimension "api"
                  versionNameSuffix "-minApi23"
              }
      
              minApi21 {
                  dimension "api"
                  versionNameSuffix "-minApi21"
              }
          }
      }
      ```
      
      In this setup, the following values are valid `--flavor` are valid `freeMinApi21`, `freeMinApi23`, `premiumMinApi21`, and `premiumMinApi23`. We call these values "flavor combinations". Consider the following from the Android documentation[^1]:
      
      > In addition to the source set directories you can create for each individual product flavor and build variant, you can also create source set directories for each combination of product flavors. For example, you can create and add Java sources to the src/demoMinApi24/java/ directory, and Gradle uses those sources only when building a variant that combines those two product flavors.
      > 
      > Source sets you create for product flavor combinations have a higher priority than source sets that belong to each individual product flavor. To learn more about source sets and how Gradle merges resources, read the section about how to [create source sets](https://developer.android.com/build/build-variants#sourcesets).
      
      This feature will not behave in this way. If a user utilizes this feature and also Android's multidimensional flavors feature, they will have to list out all flavor combinations that contain the flavor they want to limit an asset to:
      
      ```yaml
      assets:
        - assets/free/
          flavors:
            - freeMinApi21
            - freeMinApi23
      ```
      
      This is mostly due to a technical limitation in the hot-reload feature of `flutter run`. During a hot reload, the tool will try to update the asset bundle on the device, but the tool does not know the flavors contained within the flavor combination (that the user passes to `--flavor`). Gradle is the source of truth of what flavors were involved in the build, and `flutter run` currently does not access to that information since it's an implementation detail of the build process. We could bubble up this information, but it would require a nontrivial amount of engineering work, and it's unclear how desired this functionality is. It might not be worth implementing.
      
      </details>
      
      See https://flutter.dev/go/flavor-specific-assets for the (outdated) design document. 
      
      <summary>Pre-launch Checklist</summary>
      
      </details>
      
      [^1]: https://developer.android.com/build/build-variants#flavor-dimensions
      016eb851
  11. 21 Nov, 2023 1 commit
  12. 16 Nov, 2023 2 commits
  13. 14 Nov, 2023 1 commit
  14. 31 Oct, 2023 1 commit
    • Daco Harkes's avatar
      Fix formatting (#137613) · 4f606f79
      Daco Harkes authored
      Badly formatted code causes distraction when reading, and costs people energy when understanding code.
      4f606f79
  15. 30 Oct, 2023 1 commit
  16. 27 Oct, 2023 1 commit
    • Andrew Kolos's avatar
      give `throwsToolExit` a more useful description (#136694) · 1328997b
      Andrew Kolos authored
      Fixes https://github.com/flutter/flutter/issues/136698.
      
      Alters how `throwToolExit` creates its matcher. This results is an improved description of the matcher.
      
      The mismatch description isn't improved by this, but I writing an entirely custom matcher to fix this isn't ideal either. We can instead mitigate the issue by augmenting the `toString` implementation of `ToolExit` to include the exit code, if it is non-null.
      
      With these changes, the first few lines of output from a test would look like this:
      
      ```
      Expected: throws <Instance of 'ToolExit'> with `exitCode`: <42> and `message`: contains 'message'
        Actual: <Closure: () => Never>
         Which: threw ToolExit:<Exit code: 41232. Error: message>
      ```
      1328997b
  17. 26 Oct, 2023 1 commit
  18. 16 Oct, 2023 1 commit
  19. 10 Oct, 2023 1 commit
  20. 28 Sep, 2023 1 commit
  21. 20 Sep, 2023 1 commit
    • Camille Simon's avatar
      [Android] Add Java/AGP/Gradle incompatibility warning to `flutter create` (#131444) · 594ff98a
      Camille Simon authored
      Adds warning to `flutter create` command that checks if detected Java version is compatible with the template AGP and template Gradle versions. If a developer is building for Android and their Java version is incompatible with either the AGP or Gradle versions that Flutter currently supports by default for new Flutter projects, then
      
      - a warning will show noting the incompatibility and
      - steps will be shown to fix the issue, the recommended option being to configure a new compatible Java version given that Flutter knows we can support the template Gradle/AGP versions and updating them manually may be risky (feedback on this approach would be greatly appreciated!)
      
      Given that the template AGP and Gradle versions are compatible, this PR assumes that the detected Java version may only conflict with one of the template AGP or Gradle versions because:
       - the minimum Java version for a given AGP version is less than the maximum Java version compatible for the minimum Gradle version required for that AGP version (too low a Java version will fail AGP compatibility test, but not Gradle compatibility).
      - the maximum Java version compatible with minimum Gradle version for a given AGP version is higher than minimum Java version required for that AGP version (too high a Java version will fail Gradle compatibility test, but not AGP compatibility test).
      
      Fixes https://github.com/flutter/flutter/issues/130515 in the sense that `flutter create foo`; `cd foo`; `flutter run` should always be successful.
      594ff98a
  22. 13 Sep, 2023 1 commit
    • Christopher Fujino's avatar
      [flutter_tools] Run ShutdownHooks when handling signals (#134590) · 3d7cd359
      Christopher Fujino authored
      Fixes https://github.com/flutter/flutter/issues/134566.
      
      Prior to this fix, `ShutdownHooks` were run in the private helper
      function `_exit()` defined in the `package:flutter_tools/runner.dart`
      library. Independent of this, the tool had signal handling logic that
      traps SIGINT and SIGTERM. However, these handlers called `exit()` from
      `dart:io`, and didn't run these hooks.
      
      This PR moves the `_exit()` private helper to
      `package:flutter_tools/src/base/process.dart` and renames it to
      `exitWithHooks()`, so that it can be called by the signal handlers in
      `package:flutter_tools/src/base/signals.dart`.
      3d7cd359
  23. 12 Sep, 2023 1 commit
  24. 31 Aug, 2023 1 commit
  25. 23 Aug, 2023 1 commit
  26. 22 Aug, 2023 1 commit
  27. 18 Aug, 2023 1 commit
  28. 17 Aug, 2023 1 commit
  29. 10 Aug, 2023 1 commit
  30. 07 Jul, 2023 1 commit
  31. 23 Jun, 2023 1 commit
    • Oleh Prypin's avatar
      Prepare for making `intl` `toBeginningOfSentenceCase` non-nullable (#127488) · 71228e02
      Oleh Prypin authored
      I intend to edit `toBeginningOfSentenceCase`'s return value to be non-nullable because it really is never null. That will mean that non-null asserts around it will become flagged as unnecessary, although right now they are necessary. So, apply a workaround - instead use a function that does a non-null assert without triggering any lints even after it becomes unnecessary.
      71228e02
  32. 09 Jun, 2023 1 commit
    • William Hesse's avatar
      [testing] Make the FLUTTER_STORAGE_BASE_URL warning non-fatal (#128335) · 0d39f646
      William Hesse authored
      Presubmit testing and CI testing of Flutter using a custom storage location for engine artifacts must be able to use the --fatal-warnings flag without failing due to the custom artifact location.
      
      This change adds an option that makes this warning non-fatal. The new --no-fatal-storage-url-warning flag makes the --fatal-warnings flag ignore the warning that a custom artifact download URL is being used by setting the environment variable FLUTTER_STORAGE_BASE_URL.
      
      Bug: #127683
      
      - [X ] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
      - [X ] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
      - [X ] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
      - [X ] I signed the [CLA].
      - [X ] I listed at least one issue that this PR fixes in the description above.
      - [X ] I updated/added relevant documentation (doc comments with `///`).
      0d39f646
  33. 24 May, 2023 1 commit
  34. 23 May, 2023 1 commit
    • Ian Hickson's avatar
      Give channel descriptions in `flutter channel`, use branch instead of upstream... · 9c7a9e77
      Ian Hickson authored
      Give channel descriptions in `flutter channel`, use branch instead of upstream for channel name (#126936)
      
      ## How we determine the channel name
      
      Historically, we used the current branch's upstream to figure out the current channel name. I have no idea why. I traced it back to https://github.com/flutter/flutter/pull/446/files where @abarth implement this and I reviewed that PR and left no comment on it at the time.
      
      I think this is confusing. You can be on a branch and it tells you that your channel is different. That seems weird.
      
      This PR changes the logic to uses the current branch as the channel name.
      
      ## How we display channels
      
      The main reason this PR exists is to add channel descriptions to the `flutter channel` list:
      
      ```
      ianh@burmese:~/dev/flutter/packages/flutter_tools$ flutter channel
      Flutter channels:
        master (tip of tree, for contributors)
        main (tip of tree, follows master channel)
        beta (updated monthly, recommended for experienced users)
        stable (updated quarterly, for new users and for production app releases)
      * foo_bar
      
      Currently not on an official channel.
      ianh@burmese:~/dev/flutter/packages/flutter_tools$
      ```
      
      ## Other changes
      
      I made a few other changes while I was at it:
      
      * If you're not on an official channel, we used to imply `--show-all`, but now we don't, we just show the official channels plus yours. This avoids flooding the screen in the case the user is on a weird channel and just wants to know what channel they're on.
      * I made the tool more consistent about how it handles unofficial branches. Now it's always `[user branch]`.
      * I slightly adjusted how unknown versions are rendered so it's clearer the version is unknown rather than just having the word "Unknown" floating in the output without context.
      * Simplified some of the code.
      * Made some of the tests more strict (checking all output rather than just some aspects of it).
      * Changed the MockFlutterVersion to implement the FlutterVersion API more strictly.
      * I made sure we escape the output to `.metadata` to avoid potential injection bugs (previously we just inlined the version and channel name verbatim with no escaping, which is super sketchy).
      * Tweaked the help text for the `downgrade` command to be clearer.
      * Removed some misleading text in some error messages.
      * Made the `.metadata` generator consistent with the template file.
      * Removed some obsolete code to do with the `dev` branch.
      
      ## Reviewer notes
      
      I'm worried that there are implications to some of these changes that I am not aware of, so please don't assume I know what I'm doing when reviewing this code. :-)
      9c7a9e77
  35. 19 May, 2023 1 commit
  36. 16 May, 2023 1 commit