Hello everyone,
I am planning to bring F-Droid to WearOS. The plan would be to develop an Watchapp, that works as store and offers compatible apps. I am aware thet the initial setup includs installing “F-Droid-Wear” on the watch via adb.
As of now, micoG does not support GMS wich forces every FOSS companion app to use bluetooth. But there is currently some movement so support micgt be comming soon. Having this in mind, I would suggest the following:
Intended standard
- Phone app and Wear app share the same applicationId. This keeps the option open to adopt Google’s Data-Layer-API pattern later (which requires matching package names) without a package rename, a new F-Droid metadata entry, or forcing existing users to reinstall.
- The two variants are told apart purely through on the Wear build. The phone build does not declare this feature at all.
- Both variants share one monotonically increasing versionCode sequence (not a banded scheme like 1000 + …). I looked through the actual F-Droid client source (CompatibilityChecker.kt, UpdateChecker.kt, PackageV2.kt) and the index already models “one app, several Package/APK entries with different featureNames/nativecode/minSdk”. This is the exact same mechanism used today for ABI splits or minSdk-specific builds. CompatibilityChecker rejects any version whose required features aren’t present on the device, and UpdateChecker.getSuggestedVersion() / getUpdate() then picks the highest compatible versionCode. So a phone will never be offered the Wear build and vice versa, with zero changes to fdroidserver or the index schema.
Already researched
- There is no existing F-Droid client for Wear OS. Confirmed by TheLastProject (Catima maintainer) on the forum (“I do not believe an F-Droid client for WearOS devices currently exists”), and the earlier “WearOS version of F-Droid” thread never went anywhere.
- The Catima Wear companion thread (Question about submitting a WearOS companion app to F-Droid) is the closest prior art: fully FOSS, RFCOMM-over-Bluetooth instead of Play Services. Worth reading in full before starting.
- In that thread, someone actually tested which F-Droid clients correctly flag a Wear-only APK as incompatible on a phone: F-Droid and Droid-ify get it right, Flicky/Florid/Neo Store do not. I confirmed in the official client’s source why: it’s exactly the featureNames containment check mentioned above.
- fdroiddata issue #1941 proposes a new metadata field (“WearOS: yes/notification/no”). That solves app-listing/filtering in the UI. Variant selection is already solved by the existing index model, so I don’t think that field is a prerequisite for this plan.
- Installing on the watch today is done manually via Bugjaeger (ADB push from the phone). The wear-updater project (GitHub - colonelpanic8/wear-updater: Allowlisted updater for personal Wear OS apps · GitHub) shows the mechanism a future F-Droid-Wear client would need: REQUEST_INSTALL_PACKAGES + PackageInstaller, with the permission granted once via adb shell appops set REQUEST_INSTALL_PACKAGES allow since Wear OS doesn’t surface the grant dialog in its UI.
- One known trade-off: since both variants share one versionCode sequence, F-Droid’s normal archive pruning (keep only the newest N versionCodes in the main index, older ones move to the archive repo) can push the current Wear build into the archive just because several newer Phone releases shipped in between. New Wear users would then need to manually enable the Archive repo to find it. Mitigation is just a more generous pruning window for this app, not a design change. Or keep x versions of earch individual version of the app.
- Android’s developer verification enforcement (outside Play, phone/tablet only, starting Sep 2026 in BR/ID/SG/TH, global 2027) explicitly exempts ADB-installed apps for now. It is unclear yet whether Wear OS devices will fall under this in 2027.
Happy to hear pushback on any of this, especially from anyone who has actually sideloaded a store-like app onto real Wear OS hardware.
As i am an embedded developper by hard I only have an highlevel knowlege about Appdevelopment. Thus I would use AI to write code. of course I will review the code as far as my knowlege is enough.