The Problem
Many Android users rely on proprietary applications without knowing free‑software alternatives. Identifying those apps and presenting vetted replacements requires a local inventory scan, a curated database, and a simple UI—something most users cannot assemble themselves.
What This Does
LibreFind is an Android‑only Kotlin app that scans the device’s installed packages, queries a Supabase‑hosted database, and displays FOSS alternatives together with a “sovereignty score.”
Scanning lives in app/src/main/java/com/jksalcedo/librefind/domain/usecase/ScanInventoryUseCase.kt, which pulls package data via DeviceInventoryRepoImpl.kt and stores temporary results in the Room cache (AppCacheDao.kt).
Data access is handled through the repository layer (SupabaseAppRepository.kt, SupabaseAuthRepository.kt) and the local Room DB (AppDatabase.kt, IgnoredAppDao.kt, ReclassifiedAppDao.kt).
Presentation is split into composable screens under app/src/main/java/com/jksalcedo/librefind/ui/… (e.g., DashboardScreen.kt, DiscoverScreen.kt). Dependency injection is wired in di/KoinModule.kt and di/SupabaseModule.kt.
The UI follows Jetpack Compose, and the build is driven by app/build.gradle.kts and the top‑level build.gradle.kts.
How To Use It
| Step | Action |
|---|---|
| Prerequisites | Android Studio 2022+ or command‑line Gradle with Android SDK ≥ 24. |
| Clone & sync | bash<br>git clone https://github.com/jksalcedo/librefind.git<br>cd librefind<br>./gradlew clean assembleDebug |
| | Configure Supabase | Place a supabase.properties file (key/value) in app/src/main/assets/ – the repo already contains a placeholder. The app reads it via PreferencesManager.kt. | | Run | Open the project in Android Studio and launch the LibreFindApp application, or install the generated APK (app/build/outputs/apk/debug/app-debug.apk). | | Testing | bash<br>./gradlew testDebugUnitTest
runs the single unit test (ExampleUnitTest.kt). Instrumented tests are available under androidTest. |
No additional CLI or server components are required; the app is fully client‑side apart from the Supabase backend.
Real‑World Use
A corporate device‑management team could ship LibreFind to employee phones to audit installed software. After installation, the user opens the app, taps “Scan,” and receives a list of proprietary packages with direct links to open‑source replacements. The SubmitScreen.kt lets users propose new alternatives, feeding the same Supabase table that powers the community database.
Code Health & Issues
Low – Limited test coverage – Only one unit test (ExampleUnitTest.kt) and one instrumented test exist; most business logic is untested. Med – Hard‑coded Supabase endpoint – SupabaseModule.kt contains the URL in source; rotating endpoints would require code change. Low – No automated unit‑test CI – GitHub Actions runs CodeQL and release workflows but lacks a test job; failures could go unnoticed. Low – Potential UI thread work – ScanInventoryUseCase performs package enumeration; without explicit coroutine context it may block the main thread on low‑end devices. Info – License present – MIT license in LICENSE. Info – Dependency hygiene – Gradle version catalog (libs.versions.toml) centralizes versions; no obvious outdated libraries. Info – Secrets management – No API keys are committed; the only config file (supabase.properties) is ignored by .gitignore.
Overall the repository follows modern Android architecture (Clean Architecture, DI, Compose) and includes CI for static analysis, but the paucity of tests and missing test CI are the primary risk factors.
The Bottom Line
LibreFind is a well‑structured, Compose‑based Android client that delivers its core purpose—discovering proprietary apps and suggesting FOSS replacements—out of the box. It is suitable for individual users or small teams that can tolerate limited test coverage and are comfortable managing the Supabase backend. Larger enterprises should consider adding unit‑test CI and reviewing UI thread handling before wide deployment.