Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android Plugin custom arch support #211

Merged
merged 6 commits into from
Aug 16, 2024
Merged

Conversation

einsitang
Copy link
Contributor

@einsitang einsitang commented Aug 13, 2024

I'm use opencv_dart on my project , but release apk files that are getting to big,I try to optimize file sizes,so I found the apk with some binary file is no need.

so I find a way to exclude so file on useless arch.

this PR just for Android Plugin work , just work well on me , I did't compile and test complete opencv_dart , can't change code with C/C++/MAKEFILE chain tool thing because I not work on these and no executable environment.

you may need complete build/testing pipeline to verify merge code.

I added OPENCV_DART_ANDROID_SUPPORT_ARCHS flag on file android/build.gradle.

can let user set environment before build apk (Android only) , android gradle prebuild task will only copy support arch .so file with only need.

here is use case:

flutter build release without OPENCV_DART_ANDROID_SUPPORT_ARCHS define

unset OPENCV_DART_ANDROID_SUPPORT_ARCHS
flutter build apk --release
✓ Built build/app/outputs/flutter-apk/app-release.apk (200.1MB)

flutter build release with OPENCV_DART_ANDROID_SUPPORT_ARCHS define arm64-v8a,armeabi-v7a

export OPENCV_DART_ANDROID_SUPPORT_ARCHS=arm64-v8a,armeabi-v7a
flutter build apk --release 
✓ Built build/app/outputs/flutter-apk/app-release.apk (141.8MB)

flutter build release with OPENCV_DART_ANDROID_SUPPORT_ARCHS define arm64-v8a,armeabi-v7a

and specified --target-platform=android-arm,android-arm64 (not include libflutter.so on x86/x86_64)

export OPENCV_DART_ANDROID_SUPPORT_ARCHS=arm64-v8a,armeabi-v7a
flutter build apk --release --target-platform=android-arm,android-arm64
✓ Built build/app/outputs/flutter-apk/app-release.apk (123.9MB)

OPENCV_DART_ANDROID_SUPPORT_ARCHS FLAG an only receive 'x86_64', 'arm64-v8a', 'armeabi-v7a' for now

subject to ARCHS on android/build.gradle

def ARCHS = ['x86_64', 'arm64-v8a', 'armeabi-v7a']

which mean if you type in an arch that doesn't exist / support , will skip it

[opencv_dart] OPENCV_DART_ANDROID_SUPPORT_ARCHS is defined : x86_64,arm64-v8a,x86
[opencv_dart] Support arch: x86_64
[opencv_dart] Support arch: arm64-v8a
[opencv_dart] Unsupport arch: x86
[opencv_dart] OPENCV_DART for Android support arch : [x86_64, arm64-v8a]

issues :

in addition, I found that the ios makefile script only supports os64 arch, no arm64 and os64, which means opencv_dart can’t run on ios emulator ? I did’t test yet.

remind :

I saw your license not add name of copyright owner

@rainyl
Copy link
Owner

rainyl commented Aug 13, 2024

@einsitang first of all, thanks for your contribution!

however, i personally think it's not necessary, flutter support splitting for different abi, check at here: https://docs.flutter.dev/deployment/android#build-an-apk

@einsitang
Copy link
Contributor Author

einsitang commented Aug 13, 2024

https://docs.flutter.dev/deployment/android#build-an-apk

I know it . but split abi mean multiple Archs cannot be supported at the same time . we did't know which chip of arm on device

@rainyl
Copy link
Owner

rainyl commented Aug 13, 2024

oh, all right, that's reasonable. will review it later.

in addition, I found that the ios makefile script only supports os64 arch, no arm64 and os64, which means opencv_dart can’t run on ios emulator ? I did’t test yet.

os64 is an universal xcframework for both x86_64 and arm64, so it works on simulator.

I saw your license not add name of copyright owner

thanks~ will add later.

@einsitang
Copy link
Contributor Author

einsitang commented Aug 13, 2024

This FLAG scenario will only occur in private/enterprise internal distribution, non-professional test platform distribution, network distribution.

if download from app store , the package containing the appropriate abi is automatically selected for distribution , so not need it.

may need to update instructions for these.

os64 is an universal xcframework for both x86_64 and arm64, so it works on simulator.

👍🏻

@rainyl rainyl self-requested a review August 13, 2024 14:29
@rainyl
Copy link
Owner

rainyl commented Aug 13, 2024

Almost fine, I have renamed some variables' names to make it clearer, hope you wont mind it.

@rainyl rainyl mentioned this pull request Aug 13, 2024
Closed
3 tasks
@einsitang
Copy link
Contributor Author

yes , make it easier to read

but you remove task "cleanupExtractLibs" , that mean if not clean pub cache , exist abi file will pack in apk with next build

@rainyl
Copy link
Owner

rainyl commented Aug 14, 2024

we shouldnt make it clean and extract libs again and again every time the app is built, comparing to this, i prefer to let users clean the cache manually, we can provide a new setup option to simplify this, then users can run dart run opencv_dart:setup --clean-cache to remove the cached libs. What do you think?

@einsitang
Copy link
Contributor Author

At the beginning, the way I conceived was to hope that flutter's explicit commands and parameters could be read when prebuild, but after some searching, I did not find a way to meet the scheme, so I could only use the hack method of environment variables to achieve it.

If you skip the cleaning step, executing the command every time the user wants to package the abi on demand will look like this:

dart run opencv_dart:setup --clean-cache
export FLAG=arm64-v8a,armeabi-v7a
flutter build apk --target-platform=android-arm,android-arm64

It seems too complicated and mentally taxing

Or you could change it to:

dart run opencv_dart:setup --arch=arm,arm64 // default all and run once
flutter build apk --target-platform=android-arm,android-arm64

opencv_dart: The way setup replaces the environment variable FLAG, all the custom devices are grouped into this script, which is easier to understand and more reasonable to use.

You can move the download and extract files out of SOURCE_DIR and into CACHE_DIR, where --clean-cache requires re-download, extract.

Clear SOURCE_DIR/jniLibs each time you prebuild and copy from CACHE_DIR

@rainyl
Copy link
Owner

rainyl commented Aug 14, 2024

Now I think it works fine.

if OPENCV_DART_ANDROID_ENABLED_ABI is defined, all specified ABIs will be processed as:

  • check and download .tar.gz for all specified ABIs.
  • if an existed ABI folder is not included in OPENCV_DART_ANDROID_ENABLED_ABI, remove it.
  • if the corresponding libopencv_dart.so already exists, skip.
  • if libopencv_dart.so not exists, extract it.

And then you can:

export OPENCV_DART_ANDROID_ENABLED_ABI="arm64-v8a,armeabi-v7a"
flutter build apk --target-platform=android-arm,android-arm64

@einsitang what do you think now? Whether it works for you?

delete "${SOURCE_DIR}/src/main/jniLibs"
}

task extractLibs(dependsOn: [downloadLibs,cleanupExtractLibs]) {
println "[opencv_dart] Extracting libraries..."
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete clean up task, unnecessary extraction and copy will be run if added.

README.md Outdated
Comment on lines 162 to 168
> Android only
>
> if you want build Android apk with custom arch , you can set `OPENCV_DART_ANDROID_SUPPORT_ARCHS` environment variable before **flutter build**
>
> e.g., `export OPENCV_DART_ANDROID_SUPPORT_ARCHS=arm64-v8a,armeabi-v7a`(for Unix-like)
>
> or `$env:OPENCV_DART_DISABLE_AUTO_BUILD=arm64-v8a,armeabi-v7a`(for Windows)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will be moved to Q&A #212

@rainyl rainyl merged commit ea923b9 into rainyl:main Aug 16, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants