Add Flutter to Existing Apps. With this configuration, you can support HotReload in debug. You can also print a Release package for distribution. However, there are some adjustments to be made in the process of use, so I hope it can be used for reference.
Project catalog adjustment
flutter create -t module
This command creates an Android Library that supports Flutter. The Android Library directory is in the hidden folder of the Flutter project. Android/Flutter. We will store the Flutter code and the Android code in two Git repositories. Depending on the submodule, you can copy the Library code to your project directory and modify the Flutter resource directory to your own relative path:
flutter { source ‘ your own flutter project directory ‘ }
Also Copy include_flutter. Groovy to your project directory and modify the corresponding folder to add Library dependencies.
Armeabi support
Flutter officially provides SO libraries for only four CPU architectures: Armeabi-V7A, ARM64-V8A, x86, and x86-64. However, the two project teams we are connected with support only Armeabi and armeabI-V7A respectively, so the official JAR package needs to be modified. Official SDK provides the jar package path in $flutterRoot/bin/cache/artifacts/engine, copy this several directory armeabi – so in the v7a armeabi under the path:
- android-arm
- android-arm-dynamic-profile
- android-arm-dynamic-release
- android-arm-profile
- android-arm-release
You can do this with the following script:
unzip flutter.jar lib/armeabi-v7a/libflutter.so
mkdir lib/armeabi
cp lib/armeabi-v7a/libflutter.so lib/armeabi/libflutter.so
zip flutter.jar lib/armeabi-v7a/libflutter.so lib/armeabi/libflutter.so
Copy the code
The build.gradle section of the Library adds dependencies to flutter. Jar from a local gradle file:
apply from: "$flutterRoot/packages/flutter_tools/gradle/flutter.gradle"
Copy the code
Gradle file and the flutter. Jar file we just processed into our own project path.
Project │ app └ ─ ─ ─ flutter │ │ build. Gradle │ │ flutter. Gradle │ │ include_flutter. Groovy │ └ ─ ─ ─ flutter - jars │ └ ─ ─ ─ android - arm | | flutter. The jar │ └ ─ ─ ─ android - arm - dynamic - profile | | flutter. The jar │ └ ─ ─ ─ android - arm - dynamic - release | | Flutter. Jar | └ ─ ─ ─ android - arm - profile | | flutter. The jar | └ ─ ─ ─ aandroid - arm - release | | flutter. The jar │ Settings. GradleCopy the code
Change the path of jar files in flutter. Gradle to local project:
debugFlutterJar = new File('flutter-jars/debug/flutter.jar')
profileFlutterJar = new File('flutter-jars/profile/flutter.jar')
releaseFlutterJar = new File('flutter-jars/release/flutter.jar')
dynamicProfileFlutterJar = new File('flutter-jars/dynamicProfile/flutter.jar')
dynamicReleaseFlutterJar = new File('flutter-jars/dynamicRelease/flutter.jar')
Copy the code
This way, an AAR can support both architectures.
Package AAR problem
In this configuration, we can print Debug HotReload and Release packages in the project, but if we print AAR to other business modules, we will crash:
must be able to initialize the ICU context.
This is a bug in Android Gradle Plugin 3.+. It will discard the /assets/flutter_shared/icudtl.dat file in flutter. This problem is not found in 2.+ version, so we need to use Android Gradle Plugin 2.+ version. However, one of the long-standing problems with Android Gradle 2 is that the Library does not get project-consistent buildTypes. By default, the Library only publishes Release AArs. This is because the release type is specified by default in Android:
private String defaultPublishConfig = "release";
private boolean publishNonDefault = false;
Copy the code
Gradle uses buildType to determine the buildmode of flutter. In Android Gradle Plugin 3.+, this buildtype problem has been solved. This may also be one reason for the 3.+ version of Flutter.
How about avoiding the 2.+ buildType problem? There are several options on the web for getting the project buildType configuration to the Library, For example, how to make library buildType consistent with APP buildType (freely define library buildType)? . My solution is to get rid of buildType to determine the buildmode of flutter. Instead, read the local parameters of local.properties directly, and manually change the mode of flutter. In particular, make sure to change the mode to Release when going online. However, in debug mode, the page is clearly displayed with the DEBUG flag, so it usually does not fail. Buildmodefor method for flutter. Gradle
private static String buildModeFor(buildType) {
if (buildType.name == "profile") {
return "profile"
} else if (buildType.name == "dynamicProfile") {
return "dynamicProfile"
} else if (buildType.name == "dynamicRelease") {
return "dynamicRelease"
} else if (buildType.debuggable) {
return "debug"
}
return "release"
}
Copy the code
Is amended as:
private String buildModeFor(Project project) {
return resolveProperty(project, 'flutter.buildMode'.'release')}Copy the code
This allows you to switch between debug and Release in local.properties:
flutter.buildMode=release
flutter.buildMode=debug
Mode switching crashes
The following crashes may occur when the project is first configured or when mode is switched:
Check failed: vm. Must be able to initialize the VM.
The solution is to delete all the contents of the build file and compile it in full once.
conclusion
These are some problems I encountered in the configuration of flutter project. Please forgive me for the style of writing. I only hope it can provide some reference for you. In addition, we have used FLUTTER in two modules of the project, and the development efficiency can be greatly improved. After all, only one person is required to develop FLUTTER at both ends, and the page effects required by UI sister can be fulfilled without any problems found after the launch. The next step is to establish an effective monitoring system, after all, relying on user feedback is not reliable and lagging. Believe that the future of Flutter must be bright!