How to Solve Flutter Multi‑Instance Conflicts When Integrating AAR into Android Apps

Introduction

Flutter CLI can package a Flutter module as an Android AAR for external use. Using a Flutter AAR inside an Android project that already contains a Flutter app leads to the “Flutter multi‑instance” problem.

Packaging Options

Two ways to distribute a Flutter SDK: Flutter Package/Plugin (source) and Android AAR. The AAR approach hides source code and avoids requiring the host to use Flutter, but introduces conflicts when both a Flutter app and a Flutter AAR are present.

Typical Conflicts

Flutter version and embedding JAR mismatches.

Plugin and resource version clashes.

GeneratedPluginRegistrant.java duplication.

libapp.so AOT library conflict.

Runtime errors: multiple AOT libraries in one engine, asset/font manifest overrides.

Solution Overview

The proposed solution avoids engine modifications and extra host changes. It uses a custom ClassLoader to load a DEX file containing all AAR‑dependent classes, renames native libraries (libflutter.so, libapp.so) to avoid collisions, and isolates Flutter resources.

Class Conflict Handling

Package the AAR’s plugin classes and embedding JAR into a DEX placed in assets. At runtime copy the DEX to a private directory and load it with a DexClassLoader that overrides findClass to prefer the child loader.

Native Library Conflict Handling

Rename the engine library ( libflutter.so) and the AOT library ( libapp.so) and adjust the loading logic in FlutterLoader and the native engine options ( --aot-shared-library-name) to point to the renamed files.

Resource Conflict Handling

Either merge the JSON manifests at compile time or publish a separate resource package that the host Flutter app depends on, ensuring the final build contains a combined AssetsManifest.json and FontManifest.json.

Pros and Cons

No engine modifications → high maintainability.

Independent Flutter versions for app and AAR.

Increased APK size and memory due to two engine instances.

Conclusion

By isolating class loading, renaming native libraries, and managing resources, a Flutter AAR can coexist with a Flutter app, enabling SDK development with Flutter while preserving the benefits of cross‑platform development.