Question about submitting a WearOS companion app to F-Droid

1

Hey all (I guess above all @linsui and @Licaon_Kter),

Someone has been working on a WearOS companion app for Catima (companion meaning “will need to talk to the phone app to work”) which is almost ready to be published (see https://github.com/CatimaLoyalty/Android/pull/3185 for more details).

The app is fully FOSS, not using any of the regular proprietary libraries but instead using Rfcomm over Bluetooth for communication, and I would like to submit it to F-Droid. (As a sidenote: do note though that connecting a WearOS device to an Android device will often require a proprietary app, so full FOSS usage is not possible unless someone reverse engineers the proprietary vendor apps like Google Pixel Watch, Galaxy Wearable, etc. However, due to the Bluetooth communication, it would be possible to create other gadgets that talk to Catima over Bluetooth.)

While I do not believe an F-Droid client for WearOS devices currently exists, I think submitting would still be good to prove the app is FOSS and give people another way to download it than directly from GitHub or Google Play.

Normally, this would be quite simple: just a new app inclusion request. However, WearOS companion apps have one very stupid requirement: the package name must be the same as that of the phone app: https://developer.android.com/training/wearables/packaging#packaging.

While this requirement is not 100% a hard requirement (it will break communication over the proprietary “Data API”, but I don’t use that, and it will break Google Play being able to automatically install the WearOS companion when you have a WearOS watch), I would like to stick with it as I don’t want to maintain 2 flavors unnecessarily and can’t know for certain Google won’t introduce more limitations based on the package name.

So, I have the following questions:

  1. Is it possible to submit a second app with the same package name as the first app? I am willing to ensure the version codes don’t match. For example: make sure the Android app always uses an even version code and the WearOS app always uses an uneven version code.
  2. Can F-Droid correctly deal with not offering installation of apps with <uses-feature android:name="android.hardware.type.watch" /> on non-watches?
  3. Can F-Droid ensure at least one version of regular Catima will remain available, even if I end up having to make several WearOS releases in a row and would go over the archive policy?

And before someone asks: yes, non-WearOS smartwatches are already supported (since 2023!) through Gadgetbridge: Gadgetbridge 0.76.0/0.76.1: Material 3, and a lot of new devices supported - Gadgetbridge.

Looking forward to hearing what’s possible :slight_smile:

2

I thought the easiest approach is publishing the phone app and the watch app at the same time with different version codes. E.g., 167 and 168. Always release new versions of them at the same time. Then everything should just work.

No idea but if the phone app has higher version codes the watch one won’t be installed on phones.

Unless you want to maintain the metadata manually.

1 Like
3

I can do that, release 2 APKs each release (one for wear and one “regular”) and have the regular have a higher version code. And then F-Droid’s build recipe can run another command depending on if versioncode is even or not?

I’ll make the Android app use even and WearOS app use odd version codes.

Also wondering: What signature will the WearOS app use? Using my signature so people can easily switch sources would be preferable to me, but given we can’t swap Catima Android to my signature (because we’d be breaking updates), is it even possible to easily use a RB signature for the Wear app given they’re the same package name?

4

Do they need to use the same signature?

5

I remember reading in the documentation that the Data Layer Api needs matching package name and signature, but I can’t find it back now. I’m not using the Data Layer Api because proprietary, but given it’s a companion app and who knows what Google would do in the future.

So I guess it may be ever so slightly better to use the same signature type for Android + WearOS. So I guess it’s fine to use the F-Droid signature for the Wear app too to keep stuff simpler as long as we can keep the “fail if not RB” trick in place for the WearOS build too.

6

It’s easy to do anyway. Would google do something that can affect F-Droid apks?

7

Google did force developer verification on me, because Google Play account, but the F-Droid signature is verified for the main APK. I think they may force me to also verify the F-Droid signature for the WearOS again but that should not be a problem.

8

Ping me when there is a release. :slight_smile: Both work for me. Also see bot: Update Taler Wallet to 844 (!40057) · Merge requests · F-Droid / Data · GitLab.

9

Am I reading correctly that that has 4 F-Droid-signed builds and 4 non-F-Droid-signed builds? So, for each release, both F-Droid signed and dev-signed builds are published? That would be the absolute best if possible for Catima with no extra work. I can totally do something like this:

xx0 → F-Droid signed WearOS build
xx1 → F-Droid signed Android build
xx2 → Dev signed WearOS build
xx3 → Dev signed Android build

And then make sure I always use only versionCode 2 and 3 myself to leave 0 and 1 free for F-Droid.

I’ll ping you if there is a release yeah, but I’ll need to make sure we agree on version codes before that so I set them in a good way :slight_smile:

10

The version codes work for me.

11

Been thinking about this a bit more, but won’t having F-Droid edit the version codes break the “soft RB” check? Is there a way to keep that check to have the F-Droid signed build fail if it isn’t reproducible?

I suppose nothing super simple? At best an extra foss_legacy flavour or something which is the exact same as the regular foss flavour but just with the lower version code and I keep uploading the sha sums of those?

If you have any suggestions let me know :slight_smile:

12

@linsui
Spun up a quick repo to test on all currently maintained clients and got the following result with my test Wear OS APK and what happens on phones there:

  • Droid-ify: Won’t install because incompatible: “Requires android.hardware.type.watch”
  • F-Droid: Refused to add the repo unless the URL ended with /repo with “Invalid repository: org.fdroid.download.NotFoundException” :confused: But after I changed the URL and tested again it correctly marks it as incompatible
  • Flicky: Doesn’t see it as incompatible
  • Florid: Doesn’t see it as incompatible
  • Neo Store: Incorrectly only blocks it because the version code is lower, not because it is a Wear OS app you’re trying to install on a regular Android

So, 3 out of 5 apps get it wrong. I think Neo Store getting it wrong is a problem as it’s quite popular, but Flicky and Florid are quite rare. Sadly, the F-Droid website will likely also not filter out apps with android.hardware.type.watch or put a message for them and I honestly while thinking this through more started to strongly dislike the idea of having to release 2 apps when I only update 1, so if I publish it in F-Droid I guess manual repodata maintenance is the only option.

(Sidenote: I wonder if supporting Wear OS in F-Droid even makes sense, given it seems to be a fully proprietary platform with no AOSP counterpart, which seems to make it unlikely we’ll ever see a LineageOS-like this for it)

If we go for the manual route (even though I would have preferred automation), I think there should probably be 3 requirements:

  1. Catima Android is always displayed first (to work around clients and the website not filtering)
  2. Even if many Wear OS updates are released, Catima Android never disappears
  3. No need to publish updates for one app just because the other one has an update

Maybe a good fix would be to just seriously bump the Android version code? Start at 1002 for Android (keeping 1001 available for F-Droid-signed builds of Catima), and continue in the 100 range for Wear OS? Maybe we just always build only the Wear OS version signed with my key only to keep it simple, as we don’t have to support a “legacy update path” there?

Sorry for changing my mind so much, Wear OS is quite a mess and it kinda feels useless to do this (given the likely big lack of FOSS users of Wear OS) but it also feels wrong to not publish it on either F-Droid or IzzyOnDroid because, you know, screw Google being the only one publishing it :sweat_smile:

13

Please let me know if F-Droid can work with this, @linsui (see build.gradle.kts files there too): Versioning and CHANGELOG changes for new Wear OS setup by TheLastProject · Pull Request #3247 · CatimaLoyalty/Android · GitHub

14

I thought this is what you mean. :))

Can you report this bug to them?

We can also decide which flavor should be built from the tag. It’s doable but hacky.

But even manual maintaince can’t meet the 3 requirements. If you give the android app a high version code then if we want to show the wearos app we have to keep all future android app versions in repo and can’t archive them.

Up to you.

15

If you give the android app a high version code then if we want to show the wearos app we have to keep all future android app versions in repo and can’t archive them.

I mean I don’t mind :wink: But I can imagine you all will because it will bloat the main repo json. I think telling Wear OS users who want to get it from F-Droid that they have to enable the archive (if it at least does get built and pushed there) would be the least bad option of the options we have?

In the future, having some archive rules or something in fdroidserver for this would be nice, hell, even just a manual “archive: true” flag on APKs so we can prioritizes what gets archived and ArchivePolicy only runs on what’s left over would already suffice.

Can you report this bug to them?

Haven’t gotten a response yet sadly but will ping again.

We can also decide which flavor should be built from the tag. It’s doable but hacky.

I am planning to use tags with -wearos suffix for the WearOS releases, so that sounds great then.

16

Not very good to users… How to they install the apk to the wearos? Do they need to install F-Droid on wearos first?

17

I mean I’m quite new to Wear OS myself but from my experience it seems to be most people install the seemingly proprietary app Bugjaeger (https://play.google.com/store/apps/details?id=eu.sisik.hackendebug) and use that to ADB push apps from their phone.

I don’t know if non-google app stores on WearOS can even install stuff. I don’t see much useful written on guides like https://xdaforums.com/t/how-to-install-apps-on-wear-os-all-methods.4510255/. I guess the thing I hope for is an F-Droid client which detects Wear OS running and if so also installs the Wear OS companion app on the watch when starting an install on the phone, which I think is how Google Play does it.

There is a fair chance this is all a complete waste of time that nobody will ever use, but making a foss app exclusive to Google Play / GitHub just feels wrong :slight_smile:

18

Just for clarity: F-Droid cannot run on Wear OS because it doesn’t require android.hardware.watch and I don’t know of any F-Droid client that does (understandable, given the lack of apps)

19

So the user always needs to download the wearos apk manually and push it with adb. Then I thought you can download the wearos apk in the android app directly.

20

Well, to talk to an app it will first have to be installed. Wear Sync for Breezy - IzzyOnDroid F-Droid Repository can push updates for itself, but not the initial setup for example. I don’t really want to push updates from Catima, I want app stores to do app store stuff like installing apps and updates instead of having every app reinvent the wheel.

So I am hoping that, if more Wear OS companion apps land in F-Droid, someone will write the code to push apps and updates from F-Droid to the watch after a one-time setup.

Someone has to be the first. Without install support, nobody will bother publishing apps. Without apps, nobody will bother writing install support. So maybe Catima can break that cycle :slight_smile: