[native assets] Specify supported OS, Arch, minimum SDK version
- Dominant language
- Dart
- Stars
- 275
- Forks
- 144
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 47
Description
### Background
Flutter has a way for describing what OSes an app/plugin runs on via the pubspec and what minimal SDK version and architecture an app/plugin runs from via the native build files (Gradle, XCodeBuild, etc.)
Dart standalone hardcodes the MacOS version:
```dart
/// The lowest macOS version that Dart supports.
///
/// From https://dart.dev/get-dart#system-requirements
const minimumSupportedMacOSVersion = 12;
```
We don't have minimal versions for Linux, Windows, and Fuchsia.
These versions are passed in to the hook, which means that the only possible thing currently is to fail the hook if an OS version is not supported.
### Proposal
We should consider if we would like to be able to express version constraints in a way that easier accessible.
1. Dart standalone apps would be able to express an OS constraint different from the Dart supported OS version. We can check these constraints in Dart in the same way Flutter does: The minimum SDK version of the app should be at least as high as the lowest SDK version of all packages.
2. We could surface such info on pub.dev (https://github.com/dart-lang/pub-dev/issues/8010).
### Options
I believe we have two main directions we could go in here.
### 1. List in the pubspec
```yaml
platforms:
android:
architectures:
- arm64
- x64 # simulator
minimum-sdk: 123
ios:
architectures:
- ...
```
Pros:
* Declarative.
* Could be used for existing plugins, not only native assets.
Cons:
* Could get out of sync with the build hook if native assets are used.
### 2. Let the hook report it
Pros:
* Most hook implementations would use one helper to both report the supported archs as well as produce the native code assets.
Cons:
* Requires invoking a script (in a sandbox) in order to get the info.
* Does not work for existing Flutter plugins.
Related notes on specifying external versions (SDK versions, but also versions such as Java version) in internal doc: [go/native-assets-external-versions](http://goto.google.com/native-assets-external-versions)
### Concerns
Having a Flutter-agnostic way would create duplication with what Flutter already does in native build files, so we'd want to try to get the versions and architectures in the native build files read from the pubspec/hooks. https://github.com/flutter/flutter/issues/154425#issuecomment-2325794117
If Flutter moves to an embedder purely written in Dart without any native build files, we'd need a way to express OS version constraints there as well. So maybe that would be the right point in time to address this.
### Discussion
Any options I'm missing? Have you seen patterns of how to deal with external versions (OS API version, etc.) @mkustermann @mraleph?
Contributor guide
Assessment
This issue has not been assessed yet.