We have a group of tests that verifies that we can build a flutter app across the range of AGP, Kotlin, and Gradle versions we claim to support. They currently only run on postsubmit.
This pr aims to make them run in presubmit as well, but only when changes are made to the templates (not just android templates, see https://github.com/flutter/flutter/pull/157196#discussion_r1807055791 as to why).
Allows applying of `include_flutter.groovy` via the `apply from:` syntax, which allows using a host app that is using the Gradle Kotlin DSL (the default these days when creating an Android app in AS).
Explanation: The `include_flutter.groovy` script is currently not able to be called by Kotlin gradle files, because it is [intended to be invoked with the following lines](https://docs.flutter.dev/add-to-app/android/project-setup#depend-on-the-modules-source-code):
```
setBinding(new Binding([gradle: this])) // new
evaluate(new File( // new
settingsDir.parentFile, // new
'flutter_module/.android/include_flutter.groovy' // new
))
```
`setBinding` isn't part of the Kotlin gradle DSL, and there isn't (that I can find) an easy Kotlin equivalent. If this binding isn't set, the reference to `gradle` in `include_flutter.groovy` is wrong, which breaks the script.
This PR modifies `include_flutter.groovy` to also support being invoked through the standard way of invoking a script via the Gradle Groovy/Kotlin DSLs, which is `apply from:` (or it's slightly different Kotlin syntax). The start of the script identifies which of the two approaches is being used by checking if the binding is set, and then initializes some variables differently depending on the case.
If we land this, I believe we should update the example Gradle files for both the `kts` and `groovy` cases to prefer the `apply from` syntax as I think this is the syntax most developers would be more familiar with already seeing in their Gradle files.
Tells our iOS bots to use the provisioning profile stored in the flutter_internal/mac/mobileprovision CIPD packages tagged `version:to_2025`.
This CIPD package contains an updated provisioning profile which supports both the current development signing certificate expiring in October 2024, and the updated signing cert expiring in August 2025.
CIPD packages can be seen at:
https://chrome-infra-packages.appspot.com/p/flutter_internal/mac/mobileprovision
This is a reland of #155052, except without the removal of the CIPD dependency from the devicelab bots. After landing the original, many devicelab bots (and only devicelab bots) started failing with signing errors. The devicelab bots *should* be getting their certs/provisioning profile via the devicelab Salt configuration server (Googlers, see: go/flutter-salt) but it's possible some tests are fetching it from the CIPD package instead. This new patch simply updates the CIPD package version wherever it was already present. We can attempt to remove the CIPD package dependency from devicelab bots in a followup PR, and switch those over to using the profile installed via Salt (these are the same profile).
Required for: https://g-issues.chromium.org/issues/366034566
Issue: https://github.com/flutter/flutter/issues/152888
Tells our iOS bots to use the provisioning profile stored in the flutter_internal/mac/mobileprovision CIPD packages tagged `version:to_2025`.
This CIPD package contains an updated provisioning profile which supports both the current development signing certificate expiring in October 2024, and the updated signing cert expiring in August 2025.
Also removes the CIPD dependency for devicelab tasks. On devicelab bots, the cert and provisioning profile are deployed via Salt, not via CIPD. We only need this dependency on the Chromium bots.
CIPD packages can be seen at:
https://chrome-infra-packages.appspot.com/p/flutter_internal/mac/mobileprovision
Required for: https://g-issues.chromium.org/issues/366034566
Issue: https://github.com/flutter/flutter/issues/152888
https://github.com/flutter/flutter/pull/151675 bumped module templates to AGP 8.1.
In doing so, I tried to work around a behavior change [that was new in AGP 8.0](https://developer.android.com/build/releases/past-releases/agp-8-0-0-release-notes):
> AGP 8.0 creates no SoftwareComponent by default. Instead AGP creates SoftwareComponents only for variants that are configured to be published using the publishing DSL.
by using AGP's publishing DSL to define which variants to publish in the module's ephemeral gradle files:
```
android.buildTypes.all {buildType ->
if (!android.productFlavors.isEmpty()) {
android.productFlavors.all{productFlavor ->
android.publishing.singleVariant(productFlavor.name + buildType.name.capitalize()) {
withSourcesJar()
withJavadocJar()
}
}
} else {
android.publishing.singleVariant(buildType.name) {
withSourcesJar()
withJavadocJar()
}
}
}
```
The problem is that this doesn't get applied to the plugin projects used by the module, so if a module uses any plugin it breaks. This PR fixes that by applying similar logic, but to each project (not just the module's project).
Tested manually with https://github.com/gmackall/GrayAddToApp, and also re-enabled an old test that tested this use case as a part of the PR.
Fixes: https://github.com/flutter/flutter/issues/154371
This test expects to run on 32-bit hardware, but the devicelab no longer
has 32-bit Android hardware. In particular, the test contains hand-coded
32-bit arm assembly for reading the stack pointer from Dart code via
`dart:ffi`.
This test was added in response to a framework change that caused stack
frames to be larger than expected while building widgets, leading apps
to crash with StackOverflow exceptions unexpectedly. Since then (>3
years ago) this test has not prevented any similar issue, so I believe
deleting it rather than fixing it is a better use of resources.
These same tests but running against API level 34 emulators are remaining as presubmit tests. The API level 35 tests should stay in staging while the emulator stabilizes. So we can collect flake data and continue to debug.
Related: https://github.com/flutter/flutter/issues/153445
These VMs are relatively inexpensive, so there's no reason not to
continue running on the API level 34 image while we work out how to deal
with the apparent instability in the 35 images.
Related: https://github.com/flutter/flutter/issues/152684
These tests were moved to staging when they were flaking at a high rate.
I landed a couple of changes to fix unrelated issues that were masking
the underlying cause. However, these tests are no longer flaking at the
same rate in staging as they were in prod. So, I am moving these back to
prod and will monitor the flake rate.
Related https://github.com/flutter/flutter/issues/152684
