Now that Flutter requires AGP 7+, we can use Java 11 as the compatibility version in the plugin template rather than 1.8, avoiding warnings with newer toolchains, and we can remove the check for 'namespace' existing that was only necessary to support AGP 4.1.
See also https://github.com/flutter/packages/pull/7795 which made this change in Flutter-team-owned plugins.
Part of https://github.com/flutter/flutter/issues/156111
Migrates existing instantions of `--template plugin_ffi` to deal with Android 15 16kb memory pages.
Issue:
* https://github.com/flutter/flutter/issues/155933
@reidbaker I could only find migrations that run from the root application. However the file needing to be migrated is a plugin. The plugin is being referenced from the example in the example dir and that's where the migrator is run, so I wrote the code so that it walks up to find the plugin. Do you know of a way to run migrators to non-root projects? (Can we even safely do so, e.g. the non-root could be in the pub cache, could be a different project on the users' system etc. So maybe checking if we are in the examples dir is the only sane thing to do?)
Tests:
* Added unit tests in `test/general.shard/android/migrations/cmake_android_16k_pages_migration_test.dart`
This PR addresses an issue where the `--target-platform` flag was not being respected when building APKs in debug mode. Previously, debug builds would always include `x86` and `x64` architectures, regardless of the specified target platform. This change ensures that the `--target-platform` flag is honored across all build modes, including debug.
To achieve this, `BuildApkCommand` has been slightly changed to become responsible for list of archs that should be built in the current run,rather than just parsing arguments. Previously, this responsibility was distributed to gradle, which could be frustrating (in my opinion)
Fixes#153359
Android 15 support 16k page sizes, it need [enable 16kb elf alignment](https://developer.android.com/guide/practices/page-sizes#compile-r26-lower).
the current plugin_ffi template will have below error if run on android 15 16k emulator
```
Failed to load dynamic library 'libffigen_app.so': dlopen
failed: empty/missing
DT_HASH/DT_GNU_HASH in
"/data/app/~~Ixsgxu2mj5fKxP1cXpjV6Q==/com.example.ffigen_app_example-6d_efR__WGu
4dsF4tLIaHw==/lib/arm64/libffigen_app.so"
(new hash type from the future?)
```
Adds `-u`/`--unit-id-debug-info` arguments to `flutter symbolize` to pass paths to DWARF information for deferred loading units. The argument passed via `-u` should be of the form `N:P`, where `N` is the loading unit ID (an integer) and `P` is the path to the debug information for loading unit `N`. The DWARF information for the root loading unit can either be passed by `-d`/`--debug-info` as before or by `--unit-id-debug-info 1:<path>`.
Partial fix for https://github.com/flutter/flutter/issues/137527. Additional work is needed to adjust tools built on top of `flutter symbolize` to store and pass along this additional information appropriately when there are deferred loading units.
This PR modifies the warning message regarding Java compatibility to make it consistent with the Flutter style guide.
**Current message looks like this**
```
[RECOMMENDED] If so, to keep the default AGP version 8.1.0, make
sure to download a compatible Java version
(Java 17 <= compatible Java version < Java 21).
You may configure this compatible Java version by running:
`flutter config --jdk-dir=<JDK_DIRECTORY>`
Note that this is a global configuration for Flutter.
Alternatively, to continue using your configured Java version, update the AGP
version specified in the following files to a compatible AGP
version (minimum compatible AGP version: 7.0) as necessary:
- /home/user/project/testproj/android/build.gradle
See
https://developer.android.com/build/releases/gradle-plugin for details on
compatible Java/AGP versions.
```
**After Modification**
```
To keep the default AGP version 8.1.0, download a compatible Java version
(Java 17 <= compatible Java version < Java 21). Configure this Java version
globally for Flutter by running:
flutter config --jdk-dir=<JDK_DIRECTORY>
Alternatively, to continue using your current Java version, update the AGP
version in the following file(s) to a compatible version (minimum AGP version: 7.0):
/home/user/project/testproj/android/build.gradle
For details on compatible Java and AGP versions, see
https://developer.android.com/build/releases/gradle-plugin
```
Fixes#152460
`flutter downgrade` fails if you haven't used `flutter upgrade`:
```
$ flutter downgrade
There is no previously recorded version for channel "stable".
```
It's not clear what actions a user should take from this error message. Here's the new error message:
```
$ flutter downgrade
It looks like you haven't run "flutter upgrade" on channel "stable".
"flutter downgrade" undoes the last "flutter upgrade".
To switch to a specific Flutter version, see: https://flutter.dev/to/switch-flutter-version
```
Depends on https://github.com/flutter/website/pull/11098
Re-lands https://github.com/flutter/flutter/pull/136880, fixes https://github.com/flutter/flutter/issues/136879.
Additions to/things that are different from the original PR:
- Adds an entry to `gradle_errors.dart` that tells people when they run into the R8 bug because of using AGP 7.3.0 (https://issuetracker.google.com/issues/242308990).
- Previous PR moved templates off of AGP 7.3.0.
- Packages repo has been moved off AGP 7.3.0 (https://github.com/flutter/packages/pull/7432).
Also, unrelatedly:
- Deletes an entry in `gradle_errors.dart` that informed people to build with `--no-shrink`. This flag [doesn't do anything](https://github.com/flutter/website/pull/11022#issuecomment-2297294421), so it can't be the solution to any error.
- Uniquely lowers the priority of the `incompatibleKotlinVersionHandler`. This is necessary because the ordering of the errors doesn't fully determine the priority of which handler we decide to use, but also the order of the log lines. The kotlin error lines often print before the other error lines, so putting it last in the list of handlers isn't sufficient to lower it to be the lowest priority handler.
Hide the `--web-renderer` option in the Flutter Tool. The defaults already cover all fully supported modes:
- `flutter build web` provides canvaskit + dart2js
- `flutter build web --wasm` provides skwasm + dart2wasm
We do not want to encourage production usage of any other permutations (e.g. `auto` or `html`), in particular those that simply do not work (e.g. `skwasm` + dart2js).
Fixes https://github.com/flutter/flutter/issues/140096
Fixes https://github.com/flutter/flutter/issues/151786
This reverts commit 7cdc23b3e1.
The failure in the `native_assets_test` integration test on Windows was caused by the DevTools process not being shutdown by the `ColdRunner` when running the profile mode portion of the test. This resulted in the test being unable to clean up the project created by the test as DevTools was still holding onto a handle within the directory. This PR adds back the mistakenly removed DevTools shutdown logic in the `ColdRunner`.
Reverts: flutter/flutter#152049
Initiated by: cbracken
Reason for reverting: iOS builds failing in post-submit
Original PR Author: loic-sharma
Reviewed By: {jmagman}
This change reverts the following previous change:
Changes:
1. Enables Swift Package Manager by default on the main/master channel
2. Fixes tests that fail if Swift Package Manager is enabled
Corresponding docs change: https://github.com/flutter/website/pull/10938
Addresses https://github.com/flutter/flutter/issues/151567
1. Instead of getting the `FULL_PRODUCT_NAME` Xcode build setting (`Runner.app`) instead use `PRODUCT_NAME` since most places really want the product name, and the extension stripping wasn't correct when the name contained periods.
2. Don't instruct the user to open the `xcarchive` in Xcode if it doesn't exist.
Fixes https://github.com/flutter/flutter/issues/140212
Reverts: flutter/flutter#146593
Initiated by: zanderso
Reason for reverting: Consistently failing `Windows_android native_assets_android` as in https://ci.chromium.org/ui/p/flutter/builders/prod/Windows_android%20native_assets_android/2533/overview
Original PR Author: bkonyi
Reviewed By: {christopherfujino, kenzieschmoll}
This change reverts the following previous change:
This change is a major step towards moving away from shipping DDS via Pub.
The first component of this PR is the move away from importing package:dds to launch DDS. Instead, DDS is launched out of process using the `dart development-service` command shipped with the Dart SDK. This makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the removal of instances of DevTools being served manually by the flutter_tool, instead relying on DDS to serve DevTools. This will be consistent with how the standalone Dart VM serves DevTools, tying the DevTools lifecycle to a live DDS instance. This will allow for the removal of much of the logic needed to properly manage the lifecycle of the DevTools server in a future PR. Also, by serving DevTools from DDS, users will no longer need to forward a secondary port in remote workflows as DevTools will be available on the DDS port.
There's two remaining circumstances that will prevent us from removing DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory profiles
This PR also includes some refactoring around `DebuggingOptions` to reduce the number of debugging related arguments being passed as parameters adjacent to a `DebuggingOptions` instance.
This change is a major step towards moving away from shipping DDS via
Pub.
The first component of this PR is the move away from importing
package:dds to launch DDS. Instead, DDS is launched out of process using
the `dart development-service` command shipped with the Dart SDK. This
makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the
removal of instances of DevTools being served manually by the
flutter_tool, instead relying on DDS to serve DevTools. This will be
consistent with how the standalone Dart VM serves DevTools, tying the
DevTools lifecycle to a live DDS instance. This will allow for the
removal of much of the logic needed to properly manage the lifecycle of
the DevTools server in a future PR. Also, by serving DevTools from DDS,
users will no longer need to forward a secondary port in remote
workflows as DevTools will be available on the DDS port. This code is currently
commented out and will be enabled in a future PR.
There's two remaining circumstances that will prevent us from removing
DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory
profiles
This PR also includes some refactoring around `DebuggingOptions` to
reduce the number of debugging related arguments being passed as
parameters adjacent to a `DebuggingOptions` instance.
While exploring https://github.com/flutter/flutter/issues/107607, I noticed that flutter_tools test results change based on whether `dart test` is run from a terminal or from a process (such as a Dart program). I also ran into this while writing tests for https://github.com/flutter/flutter/pull/150667.
This is due to tests that rely on the global `Stdio` instance, on which the `hasTerminal` property depends on whether the tool is being invoked from a terminal.
Ideally, `testUsingContext` would require any tests that depend on `globals.stdio` to define an override for `Stdio`, but this is not the case. Until a solution to this more general problem is figured out, I think we should have `testUsingContext` always provide a `Stdio` override by default.
This PR changes the project name logic for `flutter create` to look for the name in the pubspec.yaml `name` field,
before falling back to the directory name.
Fixes https://github.com/flutter/flutter/issues/53106
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Reverts: flutter/flutter#150969
Initiated by: goderbauer
Reason for reverting: Failing test in https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8743574743030691569/+/u/run_android_obfuscate_test/stdout
Original PR Author: gmackall
Reviewed By: {christopherfujino, reidbaker}
This change reverts the following previous change:
After the land of https://github.com/flutter/engine/pull/53592, there is some log spam:
```
e: /Users/mackall/.gradle/caches/transforms-3/c1e137371ec1afe9bc9bd7b05823752d/transformed/fragment-1.7.1/jars/classes.jar!/META-INF/fragment_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /Users/mackall/.gradle/caches/transforms-3/d86c7cb1c556fe1655fa56db671c649c/transformed/jetified-activity-1.8.1/jars/classes.jar!/META-INF/activity_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
...
```
I think this is harmless, but still annoying. Upgrading the AGP version fixes it. To be honest, I don't know why (I expected the Kotlin version would do it). But after https://github.com/flutter/flutter/pull/146307, our tests have been running on AGP/Gradle 8.1/8.3 for a while, so it makes sense to upgrade anyways.
In a follow up PR:
1. Also upgrade the tests that were left behind in https://github.com/flutter/flutter/pull/146307, as I think removal of discontinued plugins paved the way here.
After the land of https://github.com/flutter/engine/pull/53592, there is some log spam:
```
e: /Users/mackall/.gradle/caches/transforms-3/c1e137371ec1afe9bc9bd7b05823752d/transformed/fragment-1.7.1/jars/classes.jar!/META-INF/fragment_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
e: /Users/mackall/.gradle/caches/transforms-3/d86c7cb1c556fe1655fa56db671c649c/transformed/jetified-activity-1.8.1/jars/classes.jar!/META-INF/activity_release.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.
...
```
I think this is harmless, but still annoying. Upgrading the AGP version fixes it. To be honest, I don't know why (I expected the Kotlin version would do it). But after https://github.com/flutter/flutter/pull/146307, our tests have been running on AGP/Gradle 8.1/8.3 for a while, so it makes sense to upgrade anyways.
In a follow up PR:
1. Also upgrade the tests that were left behind in https://github.com/flutter/flutter/pull/146307, as I think removal of discontinued plugins paved the way here.
If the user specifies the `--no-web-resources-cdn` or `--local-web-sdk`, we should use the local version of CanvasKit. `flutter.js` now has a flag that can be specified in the build configuration that tells it to load locally instead.
Also, added a link to the relevant docs in the web template warnings.
This addresses https://github.com/flutter/flutter/issues/148713
Also fixes https://github.com/flutter/flutter/issues/145559
