FOSS Android calorie trackers (OpenNutriTracker, Waistline, FoodYou) rely almost entirely on Open Food Facts and USDA FoodData Central, leaving German, Indian, Brazilian, and other non-Western users with sparse food coverage and inaccurate portion data. Multiple open GitHub issues on these projects explicitly request regional databases (German BLS, Indian INDB, Brazilian TACO/TBCA), all confirmed still unimplemented as of May 2026 by a core contributor.
builder note Don't build another tracker front-end—build the regional food database as a standalone Kotlin library or REST API that OpenNutriTracker and Waistline can plug into, and you become shared infrastructure for the whole FOSS ecosystem without competing with anyone.
landscape (3 existing solutions)
The entire FOSS calorie tracker ecosystem has standardized on the same two databases (Open Food Facts + USDA), creating identical blind spots across all apps. Regional databases (BLS, INDB, TACO) are openly licensed—the gap is a standalone library or API layer that any FOSS app can integrate.
OpenNutriTracker USDA + Open Food Facts only; no regional database support; German, Indian, and Brazilian users report missing or wrong food entries as a persistent issue. Waistline Primarily Open Food Facts; experienced intermittent API failures on German food lookups (issue #956, May 2026); no regional database fallback. Cronometer Covers regional foods well but is subscription-based, closed-source, and cloud-dependent—not viable for FOSS or privacy-conscious users. sources (2)
healthnutritionfossandroidfood-database
Starting September 2026 in Brazil, Indonesia, Singapore, and Thailand (global rollout from 2027), Google requires identity-verified developer registration before apps can install on certified Android devices—including sideloads. F-Droid, which hosts FOSS apps from pseudonymous developers, calls this existential. An opt-in advanced flow lets technically sophisticated users sideload from unverified developers, but it adds enough friction that mainstream F-Droid distribution becomes impractical. The gap: a distribution mechanism that preserves developer anonymity without forcing every end user through a manual override flow. High-stakes users include AndroidAPS (DIY diabetes management) and privacy tools for at-risk populations who legally cannot use official channels.
builder note Target the medical app category first (AndroidAPS, Loop, DIY diabetes) — these devs legally cannot use official channels, the community is organized and will fund a real solution; broad F-Droid advocacy has political energy but not purchasing power.
landscape (3 existing solutions)
Google's verification program creates a structural incompatibility with pseudonymous open-source development. The advanced flow provides an opt-in exception for technically sophisticated users but is not a viable mainstream distribution path. The only zero-friction compliant path requires developer identity registration, which pseudonymous FOSS contributors cannot satisfy.
F-Droid Faces existential threat; cannot require government ID from pseudonymous FOSS contributors; its own signing infrastructure won't satisfy Google's registered-developer requirement for certified devices after September 2026. Obtainium Installs APKs direct from GitHub/GitLab/URLs but still subject to device-level enforcement—unregistered packages won't install on certified Android devices after September 2026. Google Advanced Flow sideloading UI-based opt-in flow (distinct from ADB) that lets users explicitly install apps from unverified developers, launching globally August 2026. Does not require developer identity. However, it requires users to manually navigate advanced settings—most mainstream users will not find or use this flow, making it impractical as a general distribution path for F-Droid's audience. sources (2)
fossandroidsideloadingdistributionprivacy