Reverts: flutter/flutter#158242
Initiated by: LouiseHsu
Reason for reverting: Flake rate is low, and the arm64 macs in the staging pools are having difficulties
Original PR Author: fluttergithubbot
Reviewed By: {LouiseHsu}
This change reverts the following previous change:
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Mac_arm64_ios hot_mode_dev_cycle_ios__benchmark"
}
-->
Issue link: https://github.com/flutter/flutter/issues/158241
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Mac_arm64_ios hot_mode_dev_cycle_ios__benchmark"
}
-->
Issue link: https://github.com/flutter/flutter/issues/158241
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Mac_benchmark complex_layout_scroll_perf_macos__timeline_summary"
}
-->
Issue link: https://github.com/flutter/flutter/issues/158251
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Mac_benchmark animated_complex_opacity_perf_macos__e2e_summary"
}
-->
Issue link: https://github.com/flutter/flutter/issues/157423
I've noticed Linux tool_integration_tests 5_5 has come very close to timing out. See https://github.com/flutter/flutter/issues/155317 for more context, I am not 100% confident that increasing the subsharding here will help given that we just very recently increased subsharding from 4 to 5, but the results could be interesting regardless.
<details>
<summary> Pre-launch checklist </summary>
</details>
<!-- meta-tags: To be used by the automation script only, DO NOT MODIFY.
{
"name": "Linux_pixel_7pro service_extensions_test"
}
-->
Issue link: https://github.com/flutter/flutter/issues/157852
Using `Mac_arm64` would require these to go through a `bringup: true`
dance, which would require not running in presubmit. Instead, this PR
just adds the `cpu` property to pin to `arm64` without changing the task
name.
Towards https://github.com/flutter/flutter/issues/157758
Reverts: flutter/flutter#157032
Initiated by: gmackall
Reason for reverting: https://github.com/flutter/flutter/pull/157032#issuecomment-2436336078
Original PR Author: gmackall
Reviewed By: {reidbaker, bartekpacia}
This change reverts the following previous change:
I recently noticed the following log when building an app in verbose mode:
```
This Android Gradle plugin (8.1.0) was tested up to compileSdk = 33 (and compileSdkPreview = "UpsideDownCakePrivacySandbox").
You are strongly encouraged to update your project to use a newer
Android Gradle plugin that has been tested with compileSdk = 35.
```
It looks like AGP would like us to use a newer AGP version if we want to use compileSdk 35 (which we do). This pr upgrades the tests, in advance of updating the templates.
I recently noticed the following log when building an app in verbose mode:
```
This Android Gradle plugin (8.1.0) was tested up to compileSdk = 33 (and compileSdkPreview = "UpsideDownCakePrivacySandbox").
You are strongly encouraged to update your project to use a newer
Android Gradle plugin that has been tested with compileSdk = 35.
```
It looks like AGP would like us to use a newer AGP version if we want to use compileSdk 35 (which we do). This pr upgrades the tests, in advance of updating the templates.
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
