The last camera plugin manufacturer provided an AAR library that can be imported and used to render the interface directly with native UI controls, or to transmit the data called back by the plugin methods to the Flutter layer for display.

Today, the company provided the SDK of another camera. I thought I had learned the development of AAR plug-in, but this time they provided a set of JAR and SO files, which gave me another problem. According to Baidu, JAR file encapsulates methods for developers to call, while SO file is a function library that deals with the underlying layer, so it is related to the CPU architecture of mobile phones, generally divided into Armeabi, Armeabi-V7A, ARM64-V8A and other types of architecture. The original version was the 32-bit Armeabi, and the current mainstream phone is the 64-bit ARM64-V8A.

So it’s generally a good idea to offer different SDK packages for different architectures, but it’s also possible to just use ArmeABI, since the latter two architectures are backward compatible. As a result, some third-party vendors offer SDKS that include various architectures, with the added caveat that introducing armeabi will work just fine and reduce the package size.

However, our camera manufacturer only offers the armeabi architecture package

Because the test machine is a V8A architecture, and the flutter has been updated for several versions, when the flutter run cannot be directly specified as a 32-bit platform architecture, the SO file cannot be called, so there is a lot of trouble. This first press the table.

1. Import jar package and so file

Import the jar package

First, create a new libs folder in the plugin/android directory and put the JAR file there

Then import the dependencies one by one.

dependencies {
    implementation files('libs/hyfisheyepano.jar')
    implementation files('libs/mid - core - SDK - 4.0.7. Jar')
    implementation files('libs/org.apache.http.legacy.jar')
    implementation files('libs/wup - 1.0.0. E - the SNAPSHOT. Jar')
    implementation files('libs/Xg_sdk_4. 0.3 _20180720_1441. Jar')
    implementation files('libs/nv_sdk_v1. 0.0. The jar')}Copy the code

Import so file

The so package can be found in the editor by simply placing it in the specified location. In Android Studio, it needs to be placed in SRC /main/jniLibs, so just copy the package in one go.

If you have multiple architecture SO files, copy the package as a whole as well.

Run the

At this time, the program Can run normally, does not involve the plug-in function is normal, once the need to call the plug-in method, the program will directly rush out, check the console, prompt Can’t link the lib.

Hint statements here is used in the SDK try catch back, original intention is coundn ‘t find XXX. So, can’t find the document in the program, according to the method of import, how can’t link to, then looked down.

2. Load so file

Above, we ran it, and found that the method in the JAR package required to call the so file, but it could not be called. What is the problem?

Verifying the Installation Package

The first thing that comes to mind is to verify that the file is imported successfully. If the file is imported successfully, you can directly view the imported file in apK. So first find the location of the installation package

When flutter running in debug mode, the program will into an app – debug. Mr Apk file, stored in the project directory build/app/outputs/flutter – apk to this place, here, of course, also save the release version of the installer.

In the Android Studio menu bar, go to build -> Analyze Apk and open our app-debug.apk.

Our phone is ARM64-V8A. It is very logical for the application to look for the required file in the corresponding architecture. However, our file only has the armeabi version

The armeabi-V7A and ARM64-V8A architectures are backward compatible, so you’re smart enough to delete the other architectures and keep the content.

The solution

The solution is to add the following sentence to the build.gradle file:

android{
    defaultConfig{
        ndk {
            abiFilters 'armeabi'}}}Copy the code

We use abiFilters to specify the ABI that we want. We use the Analyze Apk function to specify the ABI that we want.

All that is left in the installation package is Armeabi, so when the basic 3 schema calls files, they will be called to the files in this package and the program will not crash.

Have to interject here because I’m developing a plug-in, at the time of this solution, I put this statement in the android/build gradle, do not have any effect, but should be written in example/android/build gradle this file, These are the parameters and configurations that the installation package depends on when it is generated. This little problem stuck me for nearly three hours.

Three, still can’t run up?

After the ABI is specified, the program will not crash because it simply won’t run.

Without further comment, or directly look at the console error, found that the most important file is missing – libfly.so. When the ABI was not specified at the beginning, v8A had this file in its package, and now it evaporates with it.

Still open Baidu first, input this key word, there are countless answers. For one thing, when Flutter builds the APK, it is necessary to specify the platform for the structure to generate the libflution.so file.

In the old version of The Flutter, it was possible to specify the platform by running the Flutter Run –target-platform Android-ARM name. This feature was removed from the new version. You can only specify the platform when you release it, but you can’t fix it every time you need to debug it.

There are many other methods on the Internet, but they don’t work very well. One of the most inelegant but practical ways to do this is to simply take a libflution. so file from another package and put it into the Armeabi package.

• 1. Make a copy before the ABI is specifiedapp-debug.apk.
• 2. Modify the file suffixapktozipAnd extract the
• 3, will folderlibs\arm64-v8aIn thelibflutter.soTake it out
• 4. Put it in pluginsarmeabiIn the
• 5, run again, no error.

Four,

It took 3 days to figure out how to import the AAR, 3 lines of code, and 3 days to figure out how to import the JAR&SO files with Ctrl C + Ctrl V.

I spent most of my time trying a sentence over and over again, wondering if I had misspelled a word, and still not understanding how the solution worked. The first thing you know is that you put so in a certain place, and you don’t know what the error means when you don’t get it, and then you realize that different CPU architectures request different packages, and you start looking for ways to specify the ABI. The method is very simple, a word, but put the wrong position, no effect, half a day open not to be out of the body. Finally in the final understanding of each piece in place, to solve the problem.