cfc: copying files over the camera with animated codes

The camera as a one-way channel

The description in the repository is short and slightly strange, and the strangeness is the point.

It is a demo and test Android application for the cimbar library. Copy files over the cell phone camera.

The readme expands that into a design statement. The application receives data over the camera as a one-way data channel, and it does not use any antennas, such as wifi, bluetooth or near field communication, or other tricks. The consequence, stated directly, is that it works just as well in airplane mode.

That is a genuinely different constraint from every other file transfer tool, and it is worth thinking about where it is the right tool. If the target device has no network, or the network is not the kind of network you want to use, or you want a physical channel that leaves no radio trace and no log entry, then a camera pointed at a screen is a real solution. The cost is the obvious one, which is throughput, and the other cost, which is less obvious, is that a one-way channel means no feedback: the sender cannot know whether a frame was decoded, so the protocol has to be built to tolerate loss without a retransmission request.

The application reads animated cimbar codes, and the readme notes that nearly all the interesting logic comes from the separate library, included here as a git subtree rather than as a dependency.

How the two halves fit together

The two halves of the system are the encoder and the decoder, and the readme describes the division cleanly.

The sender component is a cimbar encoder, and you navigate to the web site for that, or use the native sending tool in the library to generate barcodes yourself. The receiver is this application, and the readme says the interesting logic is nearly all in the library.

The procedure is straightforward. Open a file to initialise the cimbar stream, and point the application and camera at the animated barcode. The file becomes the payload, the animated code becomes the transport, and the phone decodes it back into bytes and then into the file.

That is the whole design, and it is a good illustration of a separation of concerns that is worth copying. The hard part, which is the encoding and decoding of a file into a sequence of camera-readable frames, lives in a library that is usable from a command line, a desktop tool or a phone. The phone application is a camera and a file dialog, plus the glue.

The family of related projects is linked at the top of the readme: the main cimbar repository with an introduction and an about document, this camera application, and the library itself. The web site for the sender is given as well, so the two sides are easy to find.

The readme also notes that the code for the native sender in the library is invoked by name, which is a useful detail for anybody who wants to script the sending side rather than drive a web page.

Building it, in five steps and one external library

The build instructions are numbered and they are short, which is what you would expect from a repository that is mostly wrapper code.

First install Android Studio, then the Android NDK. Then download OpenCV for Android, and the readme links a specific release of the Android SDK package. Then create a project with this repository at the root, and finally update the properties file so that the OpenCV SDK key points at wherever you extracted that SDK.

opencvsdk

The author then points at a separate project, a native OpenCV Android template, and says he found it incredibly useful for getting started. That is a small piece of honesty about the state of the toolchain, and it is worth taking at face value: integrating OpenCV with the NDK is the fiddly part of this build, and a template that does it for you saves a day.

The four dependencies, the NDK, the OpenCV SDK, the git subtree of the library and the Gradle build, are all the moving parts. There is no server component, no signing configuration beyond the standard Android one, and no build of the library itself, because it arrives in the tree.

Two licences, and what they apply to

The licensing section is short and precise, and it is the kind of detail that gets a repository into trouble when it is wrong.

The code in this application, such as it is, is MIT licensed, and the readme describes it as mostly a blend of various tutorial apps plus wrapper code around the library.

The library code is MPL 2.0, and the library's own dependencies are described as a variety of MIT, BSD, zlib, boost and Apache licences.

So the tree carries an MIT application on top of an MPL 2.0 library. That combination is workable, because the MPL is a file-level copyleft: the library files stay under the MPL and the wrapper files can be MIT, and the application as distributed is a mix. It is worth checking the boundary in the tree if you plan to relicense or vendor it, and it is worth noting that the readme is explicit about which layer is which rather than leaving a single licence file to speak for the whole thing.

The readme also does not oversell the application. Calling itself a blend of tutorial apps and wrapper code is a fair description of what a camera application built in a weekend looks like, and it sets the right expectation about how much of the behaviour is in the library.

Distribution, and a single supported architecture

The application is distributed in the three usual places for an Android app, and there is a fourth that is worth naming.

It is listed on the free software repository, it is on the Play store, and the release packages are also published in the repository's own releases section, which is the route to take if you want the build without the store.

Then the platform note, and it is short: only the 64-bit ARM architecture is officially supported at the moment, because that is all the author can test for.

That is an honest constraint rather than a technical one, and it has a practical consequence. The application contains native code, since it uses the camera through a native library, so it will not run on an older or unusual device, and there is no 32-bit build to fall back on.

The release history shows a project that ships regularly. Version 0.6.6 came out in May 2026, 0.6.7 in July and 0.6.8 in August, with the last push on 2026-09-22 and the repository not archived.

The repository layout is a conventional Android project with the application directory, the Gradle build files, the fastlane configuration for store releases, and a submodule file, which is the mechanism for the library subtree. The homepage points at the cimbar site, and the topics are the honest ones for a proof of concept: barcode scanner, file transfer, proof of concept.

Editorial conclusion

cfc suits somebody who needs to move a file to a device that has no usable network path, whether because the network is air gapped, because the device is in the field, or because the point of the exercise is to demonstrate that the camera can carry data. It is a poor fit as a general file transfer tool, because the throughput of a camera is a few orders of magnitude below a radio link and there is no return channel, so the sender cannot learn whether a frame was received. Before you use it, check the arm64 requirement against your device, and remember that the application is a thin wrapper, so the real behaviour and the real limits are those of libcimbar.

Frequently asked questions

Official sources

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