Binary Eye: An Android Barcode Scanner Built on ZXing-C++

What Binary Eye Is For, and What It Is Not

Binary Eye is an Android barcode scanner distributed on Google Play and F-Droid. The README describes it as "yet another barcode scanner for Android" and states it is free, without ads, and open source. It works in portrait and landscape orientation, reads inverted codes, follows Material Design, and can generate barcodes as well as read them.

The problem it solves is narrow and practical. If you need to read a barcode on an Android phone and you do not want to build scanning into your own application, Binary Eye is an installable app that does the reading and hands the result back through a documented interface. The README explicitly separates this from the library path: if you want to integrate a scanner into your app, it points to BarcodeScannerView or to ML Kit barcode scanning on Android instead. That distinction matters, because Binary Eye is an app first. Its integration surface is Android intents and URI deep links, not a Gradle dependency you embed.

Who it is for: Android users who need a scanner, and Android developers who want a scanning step in a workflow without writing camera code. Who it is not for: anyone on iOS, anyone who needs a desktop scanner, and anyone who wants an embedded camera view inside their own layout. The README gives no iOS build and no desktop build.

ZXing-C++ Under the Hood and the Format Lists

Binary Eye uses the ZXing-C++ ("Zebra Crossing") barcode scanning library, according to the README. The repository topics list zxing and renderscript alongside android-camera and kotlin-android, which places the decode work in native code reached from a Kotlin Android app.

The README lists what ZXing can read and what it can generate, and the two lists are not the same. On the read side it names AZTEC, CODABAR, CODE 39, CODE 93, CODE 128, DATA MATRIX, DX FILM EDGE, EAN 8, EAN 13, ITF, MAXICODE (partial), PDF417, Telepen, QR CODE, Micro QR Code, rMQR Code, RSS 14, RSS EXPANDED, UPC A, UPC E and UPC EAN EXTENSION. On the generate side the list is shorter: AZTEC, CODABAR, CODE 39, CODE 128, DATA MATRIX, EAN 8, EAN 13, ITF, PDF 417, QR CODE and UPC A. CODE 93, DX FILM EDGE, MAXICODE, Telepen, Micro QR Code, rMQR Code, RSS 14, RSS EXPANDED, UPC E and UPC EAN EXTENSION appear on the read list but not the generate list.

The MAXICODE entry carries the qualifier "partial", which is the one place in the format lists where the README admits incomplete support. If your workflow depends on MaxiCode, that word is the whole story the documentation gives you. Note also that these lists describe what ZXing supports, not necessarily what the app surfaces in every screen; the README does not map formats to UI controls.

Installing Binary Eye from F-Droid or Google Play

The README has a Download section with two badges: F-Droid and Google Play. There are no build-from-source install steps in the README itself, so the shortest path is one of those two stores. The application ID is de.markusfisch.android.binaryeye, which is the string you search for in either store.

If you build from source instead, the repository has a Makefile at the top level with a debug target that calls the Gradle wrapper:

make debug

That runs ./gradlew assembleDebug. To put the debug APK on a connected device, the Makefile has an install target that installs app/build/outputs/apk/debug/app-debug.apk with adb, and a start target that launches the debug splash activity:

make install
make start

The Makefile defines PACKAGE as de.markusfisch.android.binaryeye and starts $(PACKAGE).debug/$(PACKAGE).activity.SplashActivity. There is also a release target that runs lint and test before ./gradlew assembleRelease, and a bundle target that runs the same checks before ./gradlew bundleRelease. The README does not document a signing configuration, so treat release signing as something you resolve from the Gradle files rather than from the README.

For a first real use, the fastest check is a deep link. The Makefile carries a testview target that fires the scan URI at the device:

adb shell am start -W -a android.intent.action.VIEW -d 'binaryeye://scan'

The device should open Binary Eye in scanning mode. The same file has testencode, which passes content and format to the encode URI, and testscan, which shows the return-URL form.

Deep Links and the SCAN Intent: Two Integration Surfaces

Binary Eye exposes two ways for other software to drive it. The first is a URI deep link. The README gives binaryeye://scan and http(s)://markusfisch.de/BinaryEye for decoding, and binaryeye://encode plus http(s)://markusfisch.de/encode for encoding. The encode links accept content and format arguments, and adding execute=true (or just execute) generates the code immediately. The README's own example is binaryeye://encode?content=Test&format=QR_CODE.

Decoding can return the result to a URL. You add a ret query argument holding a URL-encoded URI template, and Binary Eye substitutes the scanned values. The README's example template is http://example.com/?result={RESULT}. Three symbols are documented: RESULT for the scanned content, RESULT_BYTES for the raw result as a hex string, and FORMAT for the barcode format. This is the mechanism to reach for when the consumer is a web page or a service rather than an Android activity, because it does not require the two apps to share a process.

The second surface is the SCAN intent. Binary Eye answers com.google.zxing.client.android.SCAN, the same action used by the older ZXing Android client, so code written against that action works without change. The README shows the legacy startActivityForResult form and the AndroidX registerForActivityResult form, and in both cases the payload arrives under the SCAN_RESULT string extra. The README does not document a failure extra for cancelled scans, so a RESULT_OK check is the only signal it describes.

Bluetooth Forwarding and the Companion App Caveat

Binary Eye can forward scans to a computer over Bluetooth. The README lays out three steps: pair the phone and PC, run a companion receiver on the computer, then enable "Forward scans with Bluetooth" in Binary Eye's settings and pick the target host.

The receiver is not part of this project. The README states plainly that the companion apps are neither developed nor maintained by the author of Binary Eye, and it names two: BinaryReceptor for Windows and bin_eye_bt_receiver for Linux. That is an unusual arrangement and worth reading as a maintenance boundary. The forwarding feature lives in Binary Eye, but the other half of the link is third-party code with its own release cadence. If a receiver stops working against a new Android version, Binary Eye's settings screen will still show the toggle.

The README does not describe the wire format, the pairing requirements beyond Bluetooth pairing, or what happens when the receiver is offline. There is no documented queue-and-retry behaviour. Treat forwarding as a convenience for a desk setup where you control both ends, not as a delivery guarantee.

Where Binary Eye Is the Wrong Tool

The clearest limitation is platform. Binary Eye is an Android app. The README has no iOS section, no desktop build and no web build, and the repository is a Gradle Android project with app/ and fastlane/ directories. If your users are on iPhone, this project does not help them, and no amount of deep linking changes that.

The second limitation is the integration model. Binary Eye is a separate app that takes over the screen. If you want a camera preview embedded in your own activity, with your own overlay and your own result handling, the README sends you elsewhere: BarcodeScannerView if you also want ZXing-C++, or ML Kit barcode scanning on Android. Using an intent means the user leaves your app, and on Android that handoff is visible and can be interrupted. The README does not document a way to run Binary Eye's scanner headlessly inside another process.

Third, the return-URL mechanism is only as reliable as the network and the receiving endpoint. The README describes the template substitution but says nothing about retries, timeouts or what the app does when the target URL is unreachable. If a scan result must not be lost, a URL callback is a weaker guarantee than an in-process result. Finally, MaxiCode is listed as partial, so a MaxiCode-dependent workflow should be tested against real symbols before you commit to it.

Binary Eye Compared with an Embedded Library

The real alternative is not another scanner app. It is embedding a scanning library in your own Android app, and the README names two: BarcodeScannerView, which it pairs with ZXing-C++, and Google's ML Kit barcode scanning.

The difference in approach is where the camera lives. With Binary Eye, your app fires an intent or a deep link and a different application owns the camera, the preview and the decode loop. Your code receives a string. With an embedded library, your app owns the camera surface and the decode callback, which means you control the framing UI, you can scan continuously without leaving your activity, and the result arrives in your own process. You also take on the camera permissions, the preview lifecycle and the decode dependency yourself.

Binary Eye wins when the scanning step is occasional and the app boundary is acceptable, or when the consumer is not an app at all and a return URL is the simplest bridge. The embedded route wins when scanning is the core interaction, when you need custom overlays, or when a round trip through another app would break the flow. The README's own framing points this way: it presents the intent path and the library path as two options and does not argue that one replaces the other.

Licence, Releases and Upgrade Cost

Binary Eye is MIT licensed, and the LICENSE file sits at the top level of the repository. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are retained. That matters if you fork the app or ship a build of it. It does not, by itself, settle anything about the ZXing-C++ library the app depends on, whose terms are separate and not stated in the README. If you redistribute a build, check that dependency's licence as well. This is a description of the licence text, not legal advice.

The release cadence is visible in the repository. The most recent releases are 1.75.4 on 2026-09-09, 1.75.3 on 2026-08-26 and 1.75.2 on 2026-08-12, and the last push to the default branch was on 2026-09-09. That is a steady patch rhythm at roughly two-week intervals across those three releases, and each is a patch-level bump rather than a major version change. The README does not describe a deprecation policy or a supported-version window, so if you depend on a specific behaviour, pin the release you validated.

Upgrade cost for a consumer is low: the app updates through F-Droid or Google Play. Upgrade cost for a fork is higher, because you are tracking an Android Gradle project with a native decode dependency, and the repository includes a CHANGELOG.md at the top level as the place to read what changed between versions. The README does not document a migration path for the deep link or intent interfaces, so treat those as stable by observation rather than by promise.

Editorial conclusion

Adopt Binary Eye when your scanner is an Android app rather than a library, or when you want a barcode reader and generator in one install. Do not adopt it for iOS, for a desktop scanner, or for an embedded scanning view inside your own app; the README points at BarcodeScannerView or ML Kit for that. Before committing, verify the read and generate format lists against your symbols, and confirm the deep link return template your target app expects.

Frequently asked questions

Official sources

1. License: MIT
2. markusfisch/BinaryEye on GitHub
3. Project website
4. README
5. Releases