Consider bumping the Android min SDK from 16 to 19

@tvolkert

According to Android Studio, 98.1% of users are running Android SDK 19 or higher.

Platform views require SDK 19. In an effort to update the SDK constraint in WebView, and Google Maps, some users will receive a build failure if they add one of these plugins to their pubspec.yaml:

uses-sdk:minSdkVersion 16 cannot be smaller than version 19 declared in library [:webview_flutter] /tmp/cirrus-ci-build/all_plugins/build/webview_flutter/intermediates/library_manifest/release/AndroidManifest.xml as the library might be using APIs not available in 16
	Suggestion: use a compatible library with a minSdk of at most 16,
		or increase this project's minSdk version to at least 19,
		or use tools:overrideLibrary="io.flutter.plugins.webviewflutter" to force usage (may lead to runtime failures)

FAILURE: Build failed with an exception.

Note that the current state is: "Your app will crash on Android <20" if you use virtual displays. Unfortunately, this is the common case if they install Google Maps today, or WebView prior to hybrid composition, but since the impact is small this hasn't been bumped in the queue.

Another consideration is that we don't have proper coverage on these SDK versions.

I also think that some code paths in the engine can be removed, and implementations simplified with higher hit rates.

Another possible option is to add code to the Flutter tool to capture these situations, and provide a more user Friendly message if the conclusion is that 1.9% is still high and significant for us.

cc @tvolkert @Hixie

1.9% of Android users is more than the population of South Africa. Or Italy. It's literally more people than live in the Czech Republic, the Dominican Republic, Sweden, Portugal, and Azerbaijan put together.

We should provide a more user-friendly message.

@Hixie

@Hixie - just to clarify. is it ok to change the min SDK for the plugins, but then have a manual step to update build.gradle to bump the SDK?

It's "ok" for us to do nothing at all (e.g. require people to write all their gradle files manually). I think that's the wrong framing. I would look at this more from the perspective of "what's the most polished experience we can provide given the time we have"? It may be that some other bug has a bigger "bang for the buck" in terms of improving the developer experience. It may be that given the effort required, the best thing we can do is print a message, and then make some other aspect of Flutter's developer experience amazing. Or it may be that the most effective way of making Flutter a good developer experience is to move the entire Android ecosystem away from Gradle. Or it may be that we should autoupdate gradle files in situations such as these. It's hard to say in the abstract, one has to look at all the options and see where we can be most effective.

There needs to be a way to change the default minSdkVersion for the auto generated /.android folder for flutter add2app modules since that auto generates a build.gradle file with minSdkVersion 16 on every pub get (also the IOS deployment target for the /.ios auto generated folder for the same reason to resolve similar issues on iOS). WIthout that, webview_flutter 2.0.6+ just breaks building the module by itself right now.

that's a good point. The current option is to do the following in your host app build.gradle:

appAppProject = project(':flutter')
appAppProject.afterEvaluate{
  appAppProject.android {
    defaultConfig {
        minSdkVersion <version>
    }
  }
}

This is kind of related:
flutter-team-archive/plugins#3894 changed the minSdkVersion for the webview package to 19.
This also applies even if you're not using hybrid composition?

Edit: I guess if I'm not using hybrid composition, it doesn't even work on SDK 19.

It's "ok" for us to do nothing at all (e.g. require people to write all their gradle files manually).

Or maybe warn users about how flutter upgrade affects their working project?!

@nima-dvlp

@nima-dvlp that comment was sarcasm.

The discussion in this issue is saying not to bump the min Android SDK level.

@Hixie

@Hixie the number we alienate has now gone down to 0.4% if you look at file-new-project from Android Studio which is the only way i know to look at it.
In addition file-new project's default is 21 it looks like, and so many things changed in 19,20,21.

These devices have end of life and lack of security updates and other issues. Do we as a community really want to contribute to someone thinking a device nine major OS levels old is viable for anything at all?

jetpack compose requires 21 and google play services requires 19 as of nearly a year ago.

https://android-developers.googleblog.com/2021/07/google-play-services-discontinuing-jelly-bean.html

so I propose that we are actually aiding the community and serving the users and ecosystem by bumping the api level, and that in the last year the "real users" mentioned will have dropped to close to zero anyway.

webview and share are huge reasons to increasea imho

Also firebase requires 19. Most firebase apps will have or want to have crashlytics or analytics if nothing else

i also hope we create and link a few new issues in the future such as

Best ways to continue giving devs options, good messages, workarounds, etc
Give users a way to choose when creating a flutter module what the .android directory will contain
a more solid process for discussing and deciding when to make the next minapi updates ongoing etc. Flutter had improvements around its release cycle from the beginning etc, so solidifying the process of when and how this happens would be awesome.

Handling stuff like this better as an ecosystem is one of the things that make flutter better than the other guys, and flutter is awesome, so thanks for doign what you do flutter team!

webview and share are huge reasons to increasea imho

webview_flutter already requires 19, so would be unaffected by the change proposed here. The error message issue was already addressed in the flutter tool.

share_plus could choose to require 19 today if they wanted to. They could also add new features conditionally, as discussed in the linked issue; that's done frequently in our 1P plugins, and is straightforward to do.

@stuartmorgan

@stuartmorgan the webview etc it's affected is because it causes a bug in flutter module that uses webview, firebasea, play services etc.
Having flutter modules that feel like they "just work" (esp in MVP/POC) when run standalone without the host project is a big asset.

So then the .android dir is autogenerated (and regenerated) and in gitignore, thereby making "just edit the biuld.gradle" something that doesn't really work

@neiljaywarner

@neiljaywarner 0.4% of 2.5 billion users is 10,000,000 users. That's more people than live in Gibraltar, Bermuda, Liechtenstein, the Cayman Islands, Barbados, Luxembourg, the Bahamas, Gambia, Montenegro, Ireland, Iceland, and Greenland put together.

Teach our fork of the engine to build on Android arm32 (#5)

Closing this as done, as noted in https://docs.flutter.dev/reference/supported-platforms. We also landed a migrator that will automatically bump the min sdk version for most apps https://github.com/flutter/flutter/pull/129729/files.

For anyone who is curious (I went looking) the engine now uses NDK 22 to build (not too long ago it used v16):
https://github.com/flutter/engine/blob/main/tools/android_sdk/packages.txt#L6

Teach our fork of the engine to build on Android arm32 (#5)

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Consider bumping the Android min SDK from 16 to 19 #82000

53 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Consider bumping the Android min SDK from 16 to 19 #82000

Description

Activity

Hixie commented on May 6, 2021

blasten commented on May 6, 2021

Hixie commented on May 6, 2021

DennisLit commented on May 19, 2021

blasten commented on May 19, 2021

TheJulianJES commented on May 20, 2021

nima-dvlp commented on Jun 4, 2021

tvolkert commented on Jun 4, 2021

neiljaywarner commented on Jun 15, 2022

stuartmorgan-g commented on Jun 15, 2022

neiljaywarner commented on Jun 15, 2022

Hixie commented on Jun 15, 2022

53 remaining items

gmackall commented on Sep 12, 2023

eseidel commented on Sep 12, 2023

github-actions commented on Sep 26, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions