Extracting Flutter Dependencies for Native Projects in a Mixed Development Environment

In a mixed Flutter‑Native project, many developers need to remove the direct Flutter dependency from the native codebase to simplify environment setup and comply with the company’s build system. This article describes the concrete implementation of extracting Flutter dependencies into a remote library that native projects can consume.

Analysis of native‑to‑Flutter dependencies

The native side depends on three parts of the Flutter project:

Flutter engine and framework libraries (e.g., libflutter.so , icudtl.dat , packaged in flutter.jar ).

Compiled Dart code and assets located under the lib directory of the Flutter module.

Custom Flutter plugins (aar or framework files).

By extracting these three artifacts and packaging them as an AAR, the native project no longer needs to reference the Flutter source directly.

Android implementation

1. Build the Flutter module:

echo "Clean old build"
find . -type d -name "build" | xargs rm -rf
./flutter/bin/flutter clean
echo "Get packages"
./flutter/bin/flutter packages get
echo "Build release AOT"
./flutter/bin/flutter build aot --release --preview-dart-2 --output-dir=build/flutteroutput/aot
echo "Build release Bundle"
./flutter/bin/flutter build bundle --precompiled --preview-dart-2 --asset-dir=build/flutteroutput/flutter_assets

2. Package flutter.jar and the compiled artifacts into an AAR:

project.android.buildTypes.each {
    addFlutterJarImplementationDependency(project, releaseFlutterJar)
}
project.android.buildTypes.whenObjectAdded {
    addFlutterJarImplementationDependency(project, releaseFlutterJar)
}
private static void addFlutterJarImplementationDependency(Project project, File releaseFlutterJar) {
    project.dependencies {
        String configuration = project.getConfigurations().findByName("implementation") ? "implementation" : "compile"
        add(configuration, project.files { releaseFlutterJar })
    }
}

3. Merge the Flutter assets into the native assets directory:

def allertAsset = "${project.projectDir.getAbsolutePath()}/flutter/assets/release"
Task mergeFlutterAssets = project.tasks.create(name: "mergeFlutterAssets${variant.name.capitalize()}", type: Copy) {
    dependsOn mergeFlutterMD5Assets
    from(allertAsset) {
        include "flutter_assets/**"
        include "vm_snapshot_data"
        include "vm_snapshot_instr"
        include "isolate_snapshot_data"
        include "isolate_snapshot_instr"
    }
    into variant.mergeAssets.outputDir
}
variant.outputs[0].processResources.dependsOn(mergeFlutterAssets)

4. Publish the AAR and plugin AARs to the internal Maven repository:

echo "Clean packflutter input(flutter build)"
rm -rf android/packflutter/flutter
mkdir -p android/packflutter/flutter/android-arm-release && cp $FLUTTER_ROOT/bin/cache/artifacts/engine/android-arm-release/flutter.jar android/packflutter/flutter/android-arm-release/flutter.jar
echo "Copy flutter asset"
mkdir -p android/packflutter/flutter/assets/release/flutter_assets && cp -r build/flutteroutput/flutter_assets/* android/packflutter/flutter/assets/release/flutter_assets/
cd android
if [ -n "$1" ]; then
    ./gradlew :packflutter:clean :packflutter:publish -PAAR_VERSION=$1
else
    ./gradlew :packflutter:clean :packflutter:publish
fi
cd ../

5. Native projects simply add the published AAR as a dependency, using a SNAPSHOT version during development:

dependencies {
    compile("com.taobao.fleamarket:IdleFishFlutter:${getFlutterAarVersion(project)}") {
        changing = true
    }
}
static def getFlutterAarVersion(Project project) {
    def resultVersion = project.flutter_aar_version
    if (project.hasProperty('FLUTTER_AAR_VERSION')) {
        resultVersion = project.FLUTTER_AAR_VERSION
    }
    return resultVersion
}

iOS implementation

1. Build the Flutter iOS artifacts:

echo "===清理flutter历史编译==="
./flutter/bin/flutter clean
echo "===重新生成plugin索引==="
./flutter/bin/flutter packages get
echo "===生成App.framework和flutter_assets==="
./flutter/bin/flutter build ios --release

2. Build each plugin as a static library for both device and simulator, then merge with lipo :

for plugin_name in $plugin_arr; do
    echo "生成lib${plugin_name}.a..."
    env xcrun xcodebuild build -configuration Release ARCHS='arm64 armv7' -target $plugin_name BUILD_DIR=../../build/ios -sdk iphoneos -quiet
    env xcrun xcodebuild build -configuration Debug ARCHS='x86_64' -target $plugin_name BUILD_DIR=../../build/ios -sdk iphonesimulator -quiet
    echo "合并lib${plugin_name}.a..."
    lipo -create "../../build/ios/Debug-iphonesimulator/${plugin_name}/lib${plugin_name}.a" "../../build/ios/Release-iphoneos/${plugin_name}/lib${plugin_name}.a" -o "../../build/ios/Release-iphoneos/${plugin_name}/lib${plugin_name}.a"
done

3. Build and merge the registration entry libraries ( flutter_plugin_entrance and flutter_service_register ) in the same way.

Continuous Integration

The CI pipeline automates the entire process: each time a native build is triggered, the Flutter module is compiled, packaged, and published to Maven, and the native project pulls the latest SNAPSHOT version. Version numbers follow a five‑segment scheme for internal testing and a three‑ or four‑segment scheme for releases, ensuring no conflicts across parallel development streams.

By extracting Flutter dependencies and automating their publication, native teams can work without installing the full Flutter SDK, reduce build‑system incompatibilities, and keep dependency versions consistent.