Build scanner binary component (for F-Droid/etc scanning support)

[joshtrichards]

the scanner binary component is OSS yet it means that nextcloud would need to build and include a build process for this binary shipped by the scanner lib dependency ourselves.

So anybody could build and contribute this but it is currently not a priority for Nextcloud. So we are happy to see folks contributing this in order to also have document scanning capabilities in the f-droid version. 👍

Originally posted by @AndyScherzinger in #10195 (comment)

[stefan-niedermann]

Maybe using the Document Scanner API might be a good solution? It's used by Google Drive but depends on proprietary Play Services. (More information)

[PhilLab]

@tobiasKaminsky I'd like to invest some time into building a tiny OpenCV from source to have the document scanning available on F-Droid.
Is this something which would get reviewed, if I had a PR for it? Just wanting to confirm that I don't waste my time experimenting with this?

And what about a more fundamental improvement of the scanner, updating the computer vision to newer standards - is that also something which would get reviewed?

[AndyScherzinger]

@PhilLab yes, definitely. The answer to both questions. The potential effort to build the native components of the use scanner library have always been rated too high. So yeah, a contribution would be highly welcomed and even step one would be a huge improvement since it would also the scanner feature to ship with f-droid as well. 👍

CC @tobiasKaminsky

[PhilLab]

@AndyScherzinger @tobiasKaminsky Great to hear. The root issue is that to keep Nextcloud's apk small, a custom Tiny OpenCV is used, which is not built from source when included from the Document Scanning SDK which Nextcloud uses.
Both of which are not really maintained and use old Computer Vision approaches.

To make it easier to upgrade to a more modern OSS scanning library, would it be an alternative approach for me to split the generated .apks per ABI (x86, x86_64, arm64-v8a, armeabi-v7a), which will make it much smaller, and accept a larger scanner library instead?. Of course, still trying to keep the library small, but with a bit more wiggle room, not sacrificing everything to this one requirement.

For what its worth, I am currently eying FairScan for this: pynicolas/FairScan#87

[PhilLab]

@AndyScherzinger @tobiasKaminsky and a second question: As a plan B, or as an intermediate measure, would it also be acceptable if the Nextcloud app would open an Open Source scanner app via Intent (FairScan will soon support this), and only if it is not installed, fall back to the built-in scanner - or nothing, if it is a F-Droid build?

It would not change anything for those who don't have the scanner app installed, but it would be a viable alternative for F-Droid users to get a smooth scanning UX.

Then, in another PR, I could work on building a library for it, to be included with Nextcloud, to offer it to all users without the additional burden of installing another app.

[AndyScherzinger]

I'll leave it to @tobiasKaminsky but I do like the idea of your "Plan B" approach to interact with the FairScan app called via Intent. Splitting the APK doesn't seem to be worth it, but that is more of an opinion than hard facts, also can't tell if this is supported by f-droid.

[tobiasKaminsky]

👍 for

• Gplay uses opencv
• Fdroid uses FairScan (if installed, can be recommended), if not nothing like now

I think this is best trade off between current state (no scanner on Fdroid) and "perfect" state (have opencv in Fdroid)