The legacy Open Food Facts Android app and its four product databases

A scanner that now mainly serves the sister databases

The repository describes itself plainly in its own title line as the legacy native version of Open Food Facts on Android, and it opens with a warning banner pointing to the new app at openfoodfacts/smooth-app. That framing sets the terms for everything else.

Underneath the legacy label there is a working product. Open Food Facts is a collaborative database of food products covering ingredients, allergens and nutrition facts, with those values feeding computed scores such as Nutri-Score, NOVA groups and Eco-Score. The app is the capture device for that database: scanning a barcode, photographing the product and its label, and uploading the result for volunteers to review. The project is run by a non-profit association of volunteers.

The remaining user base is explicit in the README. This codebase is currently only deployed for the Open Beauty Facts, Open Pet Food Facts and Open Products Facts apps on F-Droid, and Open Beauty Facts, Open Pet Food Facts and Open Products Facts have been unpublished from the Google Play Store, which the README describes as limiting the remaining impact of the codebase to F-Droid mostly. So the people who still matter here are contributors to those three apps and anyone maintaining a fork of the food scanner.

A note on scale figures: the README quotes 0,5M users and 1,6M products for Open Food Facts on Android. Those numbers describe the wider project and its iPhone app included, so read them as context rather than as a measurement of this app.

Four flavors share one Kotlin source tree

The build is organized as product flavors, and picking the wrong one is the most common way for a new contributor to waste an afternoon. The installation notes are explicit: in Android Studio, make sure to select OFF as the default flavor for Open Food Facts, with OBF for Open Beauty Facts, OPF for Open Products Facts and OPFF for Open Pet Food Facts. All four apps are built from this same codebase.

The second trap is the package identifier, which is not what a newcomer would guess. The README states that the package name on the Play Store is org.openfoodfacts.scanner, and that for historic reasons it is openfoodfacts.github.scrachx.openfood in the code and on F-Droid. The Makefile in the repository root encodes the same value in a PACKAGE variable set to openfoodfacts.github.scrachx, with a comment asking writers to change it there.

Around that sits a conventional Android project layout: an app module, Gradle build scripts written as build.gradle.kts and settings.gradle.kts, a gradle directory with the wrapper, gradle.properties, a fastlane directory, a Gemfile with a Gemfile.lock for the release tooling, and a version.txt holding the version. Documentation lives in docs/, and there are also PROJECTS/, ROADMAP.md, CHECKLIST.md, SECURITY.md and a CHANGELOG.md alongside a CHANGELOG.OLD.md. The default branch is develop, so branches taken for work are not the release line.

Scanning, uploads and the database behind the scores

The data flow starts with the camera and the barcode, and ends in a shared, public database. Contributors scan a product, photograph the packaging and the label, and upload those images; the values entered then feed the computed grades mentioned earlier, Nutri-Score, NOVA groups and Eco-Score. The database itself is published as open data and is described as reusable by anyone, which is the stated reason the project exists in open form.

The service layer is conventional Android. The library list in the README names Dagger 2 as a fast dependency injector for Android and Java, Retrofit for turning a REST API into a Java interface, and OkHttp as the HTTP and SPDY client underneath it. Mockito appears as the mocking framework used in unit tests. The list is explicitly open to correction: the README invites pull requests that fix libraries that were added or are no longer used.

Two documentation surfaces matter for anyone trying to understand the code quickly. User flows are documented visually on Figma under a navigation file, and the source documentation is generated automatically from the code, with improvements to code documentation published automatically to GitHub pages. That second point means the docs track the code rather than drifting behind it, which saves a newcomer from reading a stale wiki.

The app is also localized through Crowdin, with a project badge in the README and both crowdin.yml and crowdin-fastlane.yml at the repository root, so translations are pulled into the build rather than hand-merged.

Building in Android Studio and cutting a release with Fastlane

The documented setup path is Android Studio rather than a command line toolchain. Download the latest stable Android Studio, and on first run it asks you to install the Gradle dependencies. New contributors are pointed at a Setup Guidelines document in the repository root before they start. From there you can install the app on a phone over a USB cable or run it in an emulator.

Release automation is handled by Fastlane, and the first checkout needs the Ruby bundle installed at the root of the project:

bundle install

After that, lanes are launched through bundler, for example the release lane:

bundle exec fastlane release

Fastlane is used to automate release and screenshot generation. One piece of housekeeping is worth noting: the project is moving Fastlane related things to a separate openfoodfacts/fastlane-descriptions repository, so release configuration is being split out of this tree.

Legacy API documentation can be regenerated locally from the Makefile, whose html target runs javadoc over the package and writes the output into the app docs directory, with encoding set to UTF-8:

javadoc "$(PACKAGE)" -d "$(OUTPUTDIR)" -encoding UTF-8

The CONTRIBUTING and CODE_OF_CONDUCT files at the repository root are the rules to read before sending a pull request, and the README asks newcomers to ask for feedback on the #android channel and to document what they intend to code before starting.

A contributor pipeline built around labels and milestones

The README points contributors at a specific milestone, the 3.6.6 milestone, for issues and feature requests, and links a curated issue list as well as P1 labels and a small-issues label for Hacktoberfest. Label-based triage is the entry mechanism rather than a general task board.

That is the whole contribution surface for people who cannot write code, and the README is unusually concrete about it: scanning new products is listed as a contribution in its own right, and donations are offered to help pay for hosting and general costs. Translation is the third route, through the translate.openfoodfacts.org service, described as requiring no technical knowledge and taking a minute to sign up.

Contacting people works the same way. Any member of the Android team or the contact address at [email protected] can be reached, and there are #android and #android-alerts rooms on Slack with invites through slack.openfoodfacts.org. The team also runs a weekly meeting, since the #android-alerts channel is described as a discussion room, which is the practical way to find a mentor in a volunteer project.

The size claim in the README about contributors and products is promotional in tone and, being about the wider ecosystem rather than this app, is best treated as background. The useful detail is structural: an open issue list, labelled priorities, a Slack channel and a chat-style contact address form a route from a new contributor to a merged pull request.

Release tags stopped in 2023 while commits kept arriving

This is the tension to hold in mind when evaluating the project. The most recent GitHub releases are v3.10.2 on 2023-04-06, v3.10.1 on 2023-04-01 and v3.10.0 on 2023-02-01. The repository itself is not archived, and the last push was on 2026-10-19, so work continues in the tree even though no new release tag has been published through that path in a long while.

The explanation sits in the README's warning banner rather than in the release history. The main Open Food Facts app has moved to the new smooth-app codebase, and this tree is deployed only for the three sister apps, which have been pulled from the Google Play Store and are distributed on F-Droid. A codebase whose shipping surface shrank to one store explains why tagged releases stopped while pull requests continued.

The practical effect for an adopter is that the app is distributed through F-Droid rather than through Google Play for those three flavors, and that the Play Store package identifier may still resolve for the main food scanner for historical reasons even though the main scanner now comes from a different app. Anything depending on automatic Play Store updates should be checked against what F-Droid actually ships.

The licence is Apache-2.0, with the text in the LICENSE file at the repository root, which is permissive for reuse of the code itself but does not cover the Open Food Facts database, whose licensing is a separate question handled by the project itself.

This codebase against the new smooth-app

The alternative is not a competing scanner but a successor. The README names the new Open Food Facts app as living in the openfoodfacts/smooth-app repository, and points every user there first. The difference in approach is visible in what each tree is for.

This repository is the native Kotlin app, structured around Android Studio, Gradle product flavors and Fastlane, and it exists now to keep the three sister databases usable on Android while the food scanner migrates. Its own documentation is generated from source code and published to GitHub pages.

The smooth-app repository is where new Open Food Facts app work happens. For anyone starting a new feature on the Open Food Facts scanner, choosing this legacy tree means contributing to a codebase whose primary user-facing distribution has been narrowed to F-Droid.

There is a third path that is worth not confusing with either. Contribution to Open Food Facts as data work, scanning products and translating strings, does not require either codebase, and for many volunteers it is the higher-impact route. The two Android trees matter when you intend to change how the app behaves.

Editorial conclusion

Use this codebase if you contribute to the Open Beauty Facts, Open Pet Food Facts or Open Products Facts Android apps, or if you want to study a Kotlin Android app with Dagger 2, Retrofit and OkHttp that a large volunteer community still maintains. New Open Food Facts scanner work belongs in the smooth-app repository, and end users who want the main food scanner should install that app rather than this one. Before picking this up, confirm which flavor you need in Android Studio and remember that the Play Store package name is org.openfoodfacts.scanner while the code and F-Droid use openfoodfacts.github.scrachx.openfood. The last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openfoodfacts/openfoodfacts-androidapp on GitHub
3. Project website
4. README
5. Releases