Repository navigation
☂️ Build hooks & Code assets #129757
Description
Activity
- added a commit that references this issue
on Sep 10, 2023 - added 2 commits that reference this issue
on Sep 27, 2023 38 remaining items
In #112727 I proposed adding similar functionality to the flutter tool, one of the use cases was to provide support for rust plugins. I was imagining calling cargo at the appropriate time and linking the generated library to the final flutter binary. Then we could call into it with a c interface. This sounds like it could handle that case at a better layer.
Reacted by smit-ai@gaaclarke, there is already native_toolchain_rust that does that for native assets / hooks, it's just really out of date and I need to find time to update it as there have been many, many, many breaking changes meanwhile :)
Reacted by gaaclarke, Francesco Iapicca and smit-aiReacted by Daco Harkes and smit-aiSorry if I got the wrong end of the stick but @gaaclarke is what you are suggesting covered by #47718 ? or would libs into a Flutter exe be different to what is required for a standalong Dart exe ?
Sorry if I got the wrong end of the stick but @gaaclarke is what you are suggesting covered by #47718 ? or would libs into a Flutter exe be different to what is required for a standalong Dart exe ?
I didn't really specify, I was just talking generally. If a rust target created a static library I would expect it to be linked statically, which would make what happens between dart and flutter very similar. That's what's covered in that issue. Dynamic libraries are a bit more complex for flutter versus dart because each target platform (iOS, Android) has different preferences about where it wants to find dynamic libraries, has different tools/file formats, etc. I haven't been following Daco's work but I'm sure he's been considering that.
Reacted by smit-aiSorry if I got the wrong end of the stick but @gaaclarke is what you are suggesting covered by #47718 ? or would libs into a Flutter exe be different to what is required for a standalong Dart exe ?
I didn't really specify, I was just talking generally. If a rust target created a static library I would expect it to be linked statically, which would make what happens between dart and flutter very similar. That's what's covered in that issue. Dynamic libraries are a bit more complex for flutter versus dart because each target platform (iOS, Android) has different preferences about where it wants to find dynamic libraries, has different tools/file formats, etc. I haven't been following Daco's work but I'm sure he's been considering that.
Yes, the code assets support in Flutter (and Dart) takes care to rewrite dynamic loading paths, code signing, etc.
Static linking against the AOT-compiled Dart code is actually more tricky, as the Dart code is not output in the native format for each OS currently. With the work on link hooks (dart-lang/native#153) we'd already get tree-shaking of native code based on what Dart code is tree-shaken. So, static linking would only remove the dynamic linker call and make FFI calls static calls into the C code, but at considerable engineering effort. Therefore, we're focussing on dynamic libraries for now and we're not working actively on dart-lang/sdk#47718, dart-lang/sdk#49418 , and https://dart-review.googlesource.com/c/sdk/+/251263.
Reacted by smit-aiReacted by smit-aiIn older versions it's available behind an experimental flag on the master channel:
flutter config --enable-native-assets.@dcharkes Just to confirm, does this the
flutter config --enable-native-assetsoption does nothing on the latest stable? Should we deprecate/remove this option from the Flutter tool?In older versions it's available behind an experimental flag on the master channel:
flutter config --enable-native-assets.@dcharkes Just to confirm, does this the
flutter config --enable-native-assetsoption does nothing on the latest stable? Should we deprecate/remove this option from the Flutter tool?The experiment is not enable-able on stable, and is on by default and disable-able on beta and master. So the experiment still serves a purpose. Once we also enable it on stable, we can remove it.
Reacted by Renan and smit-aii think native assets are available in 3.38?
https://github.com/flutter/flutter/blob/3.38.0/packages/flutter_tools/lib/src/features.dart#L189Yes, build hooks and code assets support in Flutter is available in stable since 3.38 and Dart 3.10:
flutter create --template=package_ffi [package name].Ongoing work for tree-shaking and other features related to hooks can be tracked in: Native Assets
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 -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Nov 28, 2025
Build hooks and code assets support in Flutter is available in stable since 3.38 and Dart 3.10:
flutter create --template=package_ffi [package name].Ongoing work for tree-shaking and other features related to hooks can be tracked in: Native Assets
A high level tracking issue for supporting native assets.
Native assets enables packages to specify a top-level
build.dartthat is invoked by launchers (dartdev and flutter_tools) to build/download native libraries and communicate back which native libraries need to be bundled and under which "asset id".From a Flutter context, the native assets feature will enable testing native code with
flutter test, which the FFI plugins do not support. From a Dart+Flutter context packages will be compatible with both Dart and Flutter, removing the need for publishing two versions on pub (one for Dart and one for Flutter).More details can be found in:
Current ongoing work can be tracked in: Native Assets
Dart standalone support has landed behind an experimental flag (
dart --enable-experiment=native-assets).This issue tracks implementing native assets in flutter tools
Use cases that should be supported
flutter runflutter builddebug/release/profileflutter test/dart testflutter build macos-frameworkfor MacOS)flutter run -dflutter-testerTest coverage will be through end-to-end integration tests that exercise the dynamic libraries provided by packages.
Landing plan is to land this behind an experimental flag on the main branch only. This has the following benefits:
build.dartprotocol until before we get it out of experimental. Users should not publish packages on pub.dev while this feature is in experimental phase.Please feel free to note additional use cases that we have missed or ask questions on this issue.
Foot notes:
References:
cc @stuartmorgan @vashworth
Ongoing work related to native assets, build.dart and link.dart hooks:
hook/link.dartsupport in flutter_tools #146263hook/build.dartData assets support #146264hook/link.dartconsume data assets from pubspec.yaml #146265native_assetsto the App Store. #148044flutter cleanshould delete all native assets #151890flutter run#154425package_ffitemplate language options #151646flutter test integration_test#168961