FIRST-Tech-Challenge
Expand ExternalLibraries
The newly added (7.0) support for external libraries is cool. But it currently sounds like it is restricted to onBot and Blocks. It seems like it could serve the needs of Android Studio developers as well - making it so external libraries don't have to be packaged with the robotcontroller apk. It would provide a consistent way for transferring/storing .so files on the RC and copying them to protected storage and loading them. It seems like this would help with things like openCV, vuforia, and others.
Personally I see it completely the other way. Keeping everything in Android Studio helps for configuration control and consistency when using different devices. Also, this would still require building against external libraries in Android Studio in order for the compilation to succeed, just you'd be adding the dependencies as compile-only instead of runtime. And then you could have the possibility for version conflicts between the version you built against and the version used at runtime.
Thanks for the response @Windwoes. Maybe you can help me understand. EOCV uses OpenCV-Repackaged (as api in build.gradle) and RobotCore as compile-only. Is it not possible for EOCV to get conflict with the RC version?
OpenCV-Repackaged takes care of version conflict using MD5 checks. And it currently limits EOCV and RC to armeabi-v7a. It looks like the approach in ExternalLibraries supports both armeabi-v7a and arm64-v8a - with the loaded libraries checked for match against the RC type. Instead of a hardcoded MD5 check, could there be a minimum required library version check or similar?
Also, OpenCV-repackaged has the opencv java code files to compile against, but doesn't appear to actually generate the opencv .so files - instead it relies on manual transfer of the prepackaged .so files.
We were previously using a old home grown system for loading libraries (primarily opencv). But the strategy could apply to others. That is why I was looking to see if there was a somewhat generic approach that could do what OpenCV-repackaged has a specialized solution for, and what ExternalLibraries seems to provide (but limited to onbot/blocks).
I am interested in learning more on this. Thanks.
EOCV uses OpenCV-Repackaged (as api in build.gradle) and RobotCore as compile-only. Is it not possible for EOCV to get conflict with the RC version?
Oh, it's absolutely possible does happen - due to API/ABI changes in SDK v7.0, EOCV versions before 1.5.x will blow up on a 7.0 RC due to changed method signatures.
Also, OpenCV-repackaged has the opencv java code files to compile against, but doesn't appear to actually generate the opencv .so files - instead it relies on manual transfer of the prepackaged .so files.
Building the OpenCV native library is a pain, and the OpenCV Android SDK provides them prebuilt, so I just reuse those. Essentially OpenCV-Repackaged is just the vanilla OpenCV Android SDK, but packaged nicely on Maven so it can be pulled in from Gradle. I could absolutely package the native library inside the AAR so the user doesn't need to copy it manually - but I specifically did extra work for the dynamic load to avoid bloating the APK with the 10MB native library. The OnBotJava EOCV bundle uses prepackaged native libraries (for both 64 and 32 bit) because that's a one-time thing (doesn't affect build times) and it just makes the install process easier. The Android Studio version currently only supports 32-bit for sake of simplicity. I could provide an alternative artifact on Maven like the OBJ version which has the 64 and 32 bit libraries prepackaged to make the install super simpler at the expensive of APK size. shrug