-
Notifications
You must be signed in to change notification settings - Fork 27.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump targetSdkVersion to 31 and organize static values #91719
Conversation
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
@@ -25,7 +25,7 @@ apply plugin: 'com.android.application' | |||
apply from: "$flutterRoot/packages/flutter_tools/gradle/flutter.gradle" | |||
|
|||
android { | |||
compileSdkVersion 30 | |||
compileSdkVersion flutter.compileSdkVersion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We risk breaking people by accident when we bump the supported SDK versions in the future without the developer's knowledge, correct? I am all for the centralized sdk versions as this makes it much cleaner, but what is an acceptable level of potential breaking in the future?
One way to put it is that with this change, developers would have to opt out of automatic sdk bumps by editing the build.gradle if they encounter issues rather than opt into sdk bumps by manually bumping the number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be determined exclusively by the engine dependencies.
+1 on why not compileSdk also to 31? Does it have to do with something like #74915 where something does not support 31 yet? |
I explained the issue in regards to plugins in #91771
I'm in favor of keeping compileSdkVersion up to date. I just don't fully know all the implications. I'm planning to send a separate PR just to see what issues I run into. |
Ok, keeping up to date rather than latest sgtm then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This seems to have broken |
Bumps the targetSdkVersion to 31, and also moves the versions for
minSdkVersion, compileSdkVersion, and targetSdkVersion to flutter.grade.