There are two remaining issues that need to be solved:

• androidx.window uses a newer version of kotlin, which is incompatible with version 1.3.50, used in templates. I updated kotlin to 1.4.32 but this is not compatible with AGP 3.3.0 - There is a test that specifically makes sure apps using AGP 3.3.0 still compile, which is no longer the case. I think this is a breaking change and it should be discussed. Theoretically, I think we can make this new kotlin version work with AGP 3.3.0 by asking the compiler to ignore the differences in metadata versions (which is what it complains about) - but I haven't tried this yet, might not work ok and seems like a temp solution. The test that fails:

  flutter/packages/flutter_tools/test/integration.shard/android_plugin_example_app_build_test.dart

  Line 24 in e7b7ebc

  test('plugin example can be built using current Flutter Gradle plugin', () async {

• androidx.window requires Android API 31. The camera plugin, which is used in one of the tests, uses code that is deprecated in API 31, and warnings are treated as errors. I have opened a separate issue for the camera plugin, which, once fixed, should also fix this test [Camera] CamcorderProfile deprecated in Android API level 31 #89578 . If we want to make this land faster, we can consider removing the -Werror flag. The test that fails is

  flutter/packages/flutter_tools/test/integration.shard/deprecated_gradle_settings_test.dart

  Line 17 in e7b7ebc

  test('android project using deprecated settings.gradle will still build', () async {

These version bumps (kotlin, android API and AGP) need to be dealt with eventually. Is there anything in the tooling or framework that helps with old plugins or old apps that I'm missing? @blasten Could you please advise? I'm asking because of #71964

@andreidiaconu I filed #89609. Does your change require to bump the targetSdkVersion/compileSdkVersion?

does it mean that your change will break older apps that don't update these?

This is problematic then. I'm not sure what the next step should be, other than split the changes so that the activation requires a manual step.

You mentioned that this is is hard to land as a plugin, but can a portion of this change land as a plugin? In particular, the code that brings the Android dependency, and requires a higher SDK?

@blasten The problem is not with targetSdkVersion / compileSdkVersion. The compatibility issue shows up between old versions of AGP and newer versions of kotlin, which is added with this engine PR.

For an application to run into issues, it would need to use AGP version 3. The framework templates is are set to version 4.1.0, which works fine with the latest kotlin 1.5.30. If an app stops building after this PR, it would only need to run flutter create .

Older apps still using AGP 3 are already forced to update if they try using plugins with newer version of kotlin. Here is an example issue of this happening #83834 . Moving forward, less and less apps will even be able to use AGP 3 due to this lack of compatibility with newer kotlin. It only takes one plugin to use it for the developer to be forced to update AGP.

For more exact numbers, androidx.window uses kotlin version 1.5.21 and this version is not compatible with AGP 3.3.0 (used in this test).

Thanks for the research. In this case, it sounds like reverting the targetSdkVersion/compileSdkVersion changes in this PR will fix the issue seen in #89609

@blasten I spoke to soon on compileSdkVersion. androidx.window does have minCompileSdk set to 31, which then requires anyone using it to have compileSdkVersion set to at least 31. From what I can see, there isn't anything specific in the library to warrant this requirement. I will try to see if this restriction can be dropped on their side, since it also contradicts their own guidelines -- assuming this was not intentional https://github.com/androidx/androidx/blob/androidx-main/docs/api_guidelines.md#choosing-a-minsdkversion-module-minsdkversion

I will keep you updated and sorry for my confusion

@blasten I discussed with the androidx team and they will not lower the minCompileSdk. They now use this configuration on all their libraries and doing this has standardisation advantages for them and their users.

Bringing in androidx.window forces us to use compileSdkVersion 31. targetSdkVersion can remain whatever developers prefer. This means that:

• Apps not yet using compileSdkVersion 31 will need to run flutter create . to update their android configuration
• Apps using methods deprecated in API 31 need to be updated because of the -Werror flag. A solution for not breaking these apps would be removing the -Werror flag. A better solution would be for the apps / plugins to manually fix or suppress the warnings.

compileSdkVersion 31 is fine as it only says 'we want the last features from Android 12' and not 'compatibility mode'. The issue is that every year there is a new version, and Flutter itself, its libraries and apps have been historically bad at keeping track of this.

Hey @andreidiaconu thank you for all of your work and research on this. I am just catching up on it. :)
Given your last update, do you want to proceed with this change using compileSdkVersion 31? I am here to help move this along, so let me know if there is anything I can do to assist.

Ok thanks for clarifying! :)
@blasten do you think this breaking change is acceptable if we go through the process and provide a migration guide?

Thanks @Piinks. Andrei, I'm sorry this is taking longer, or that this issue wasn't brought up earlier. (I was collecting information from the design doc reviewers.)

I'd like to see a proposal where we define an interface with a default implementation that doesn't require any of these changes to an app. At a high level, I'm mostly concerned that new features all the sudden require new embedding dependencies, or migrations guidelines for everyone, even if an app doesn't use these features.

AndroidX libraries themselves were carefully designed, so they can be included in an app as needed. I'd like to see how that model can work in Flutter as well.

There are exceptions to this model. e.g. Android's lifecycle was a necessary dependency that had our team debating for nearly a quarter (cc @xster).

Given that the communication channel between the framework and the native side is platform channels, what sort of limitation do you see by having an interface with two different implementations? That is, one shipped as a plugin that requires the changes to the app you are suggesting, and one with a default (no-op) implementation.

One limitation I see is that viewport metrics can get out of sync, which is
why (to my recollection) we opted to use existing engine methods directly
for delivering that data from android to engine to dart.

Looking at flutter/engine#24756, it seems doable to add a method (e.g. buildFlutterView()) to FlutterActivity that allows to override the implementation of FlutterView. You could subclass FlutterView and add the changes added to the engine that use the androidx.window.* packages.

Lastly, a plugin could have a FlutterView subclass as well as WindowInfoRepositoryCallbackAdapterWrapper class. Then, the only step for a developer becomes overriding the buildFlutterView() in FlutterActivity, and bumping compileSdkVersion.

Would there be an issue with this approach?

Are we doing all of this to avoid bumping compileSdkVersion from 30 to 31?

...and the embedding dependency.

Bumping compileSdkVersion has the potential to cause warnings. In this case, the only solution would be to disable warnings as errors if this is caused by a plugin.

Does luci-flutter turn green when all other checks are green? I'm a bit confused as to what I can do to make it pass.

It turns green when all tests are passing on master. In this case, one test failed in the last invocation, so I retriggered it.

From what I see, one of the red areas in https://ci.chromium.org/p/flutter/g/flutter/console relates to one of the tests also fixed in this PR (failure caused by firebase requiring minSdk 19 instead of 16).

Got it.