Replace the ZXing Java implementation with the C++ fork.
The C++ fork is faster, actively maintained and supports the MicroQR
Code barcode format.
The original Java implementation is in "Maintenance Mode Only",
what means that no new features or barcodes will be accepted.
Because the C++ fork is much faster, we can now drop RenderScript
which has been deprecated by Google anyway. Also, this removes a lot
of complications. RenderScript was never very robust.
Makes building app bundles finally work for Android 7+.
For Android 6 and lower, app bundles are still broken - but an APK
still works!
With R8 and build tools 4.0.1, we can also build on macOS Catalina
again, even when an NDK is available. So hopefully, this commit
should also fix builds by F-Droid where we cannot disable the NDK
(for details see issue #111).
At the time of writing, it's important to _not_ have the NDK available
when compiling the custom rotation kernel. This will produce a broken
build for some ARMv7 devices running Android 6 (e.g. One Plus X,
Yotaphone 2, Moto E) while it works for newer Android versions.
And remove it from the metadata.
ZXing can read MAXICODEs only in PURE mode what means the
source image must be monochrome, unrotated and unskewed.
Of course, this isn't the case for a camera frame and this
is why Binary Eye cannot read MAXICODEs.
And use these screenshots instead of the ones in gh-page in
the README.
It's probably better to put those screenshots in the master
branch anyway. This way, the images can always be displayed
even when offline.
Apparently, at least for Android builds, Travis CI just doesn't
cut the mustard.
After updating the SDK version to 27, Travis CI *always* fails
to build the project because the android-27 license is not accepted.
I've done everything https://docs.travis-ci.com/user/languages/android/
told me to but still, it won't build.
So I've got enough of Travis CI and that's it. If that thing can't
build a standard Android project, it's simply not useful to me.
