F-Droid packaging

[Doomsdayrs]

It would be nice to add this application to F-Droid as well

[Gargron]

https://gitlab.com/fdroid/fdroiddata/-/merge_requests/10909

[rugk]

i agree it would be great to see this Android app on F-Droid!

F-Droid is an Android app store specifically for free/libre open-source apps. It would be great if your app could be released there, as it is the number one for getting FLOSS Android apps for many people.
F-Droid also builds all apps from source (optionally even reproducible), so downloads from there can be trusted.

The app developer FAQ or the quick start guide may help you to get started.

BTW a release on F-Droid could also bring some (more) popularity (in case that is intended), as it will show up in the app (new apps are featured there).

[TinClound]

The official mastodon app appeared in IzzyOnDroid, may be available, also with repo IzzyOnDroid in F-Droid (https://apt.izzysoft.de/fdroid/repo). There also a lot of free software in this repository, too.

[WhyNotHugo]

In the meantime, is there an APK we can install manually? Maybe generated via CI?

[grishka]

There is one right here in releases

[yaomtc]

The official mastodon app appeared in IzzyOnDroid, may be available, also with repo IzzyOnDroid in F-Droid (https://apt.izzysoft.de/fdroid/repo). There also a lot of free software in this repository, too.

Anybody know why it has the NonFreeNet label there? I understand that being applied to Twitter apps for example, but I don't get this one

https://apt.izzysoft.de/fdroid/index/apk/org.joinmastodon.android

[Doomsdayrs]

The official mastodon app appeared in IzzyOnDroid, may be available, also with repo IzzyOnDroid in F-Droid (https://apt.izzysoft.de/fdroid/repo). There also a lot of free software in this repository, too.

Anybody know why it has the NonFreeNet label there? I understand that being applied to Twitter apps for example, but I don't get this one

https://apt.izzysoft.de/fdroid/index/apk/org.joinmastodon.android

Likely because of a reliance on google API

[Gargron]

It does not rely on it, it uses it when it's available. And that's reason enough for them to slap a red label on our app.

[yaomtc]

Wouldn't that be covered by the NonFreeDep label that's already on there?

NonFreeDep: The application depends on a non-free application (usually Google Services)

With software stored on F-Droid's repos I can usually find out why labels are applied by checking the RFP, but for Izzy's repo, idk, I'd have to ask Izzy I guess. https://mastodon.technology/@IzzyOnDroid

He did write an article about Mastodon on his site but it was last updated in 2020: https://android.izzysoft.de/articles/named/fediverse-2

[grishka]

Wouldn't that be covered by the NonFreeDep label that's already on there?

I read the word "depends" as meaning that the app can't function without a non-free dependency, like Google services. However, that's not the case here.

[IzzySoft]

It does not rely on it, it uses it when it's available.

Just say a word, @Gargron (I missed that it's "only used when available"). As you don't use the FCM libs for that, the label is not raised automatically with my repo (and thus my checker does not yell at me when I remove it – which I now just have done). With f-droid.org those labels are set manually in general (when a finding suggests it), but nobody gets "daily alerts" like with my repo. So we can leave it out there as well.

but for Izzy's repo, idk, I'd have to ask Izzy I guess

Usually you find the reason in the libraries section of an app's packages – with a few exceptions (like apps accessing YT or some other non-free service without using a specific library). In case of this app here it wouldn't be obvious either, as Eugen did take care to avoid proprietary dependencies (tapping my hat once more).

Hope I could clarify things a bit, and remove one obstacle caused by myself…

[trymeouteh]

Please add app to F-Droid for us degoogled Android users to be able to install and receive updates

[grishka]

The merge request was submitted ages ago. I don't think there's anything I can do to speed up the process — I'm not downgrading to Java 11 just so their build server can build it without downloading JDK 17 because downloading packages from places other than the debian repository is very very bad and dangerous apparently.

[davidbtc2009]

@Gargron what does the app do on a totally degoogled device? I don't seem to be getting push notifications from the app. Does it require GCM (Google Cloud Messenger) as its push service provider?

[grishka]

Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.

[davidbtc2009]

Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.

They could impliment a fallback to UnifiedPush. https://unifiedpush.org/ thame requirement of gcm may stop fdroid from including it

[IzzySoft]

@grishka

What else would send it push notifications?

Quoting from my collection:

• @UnifiedPush
• Gotify
• NoProvider2Push

Not on my list:

• XMPP
• MQTT
• probably more, maybe appwrite and Supabase as Firebase replacements include it as well. So there's not exactly a lack of alternatives 😉

And speaking of UnifiedPush: you could even include their FCM Distributor with your PlayStore build so PlayStore users wouldn't even notice the difference – while omitting it from the F-Droid/FOSS build lets other users choose freely from alternative backends.

[davidbtc2009]

Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.

They could impliment a fallback to UnifiedPush. https://unifiedpush.org/ thame requirement of gcm may stop fdroid from including it

Yep, i use ntfy and push support works great

[turtlegarden]

Yes, of course it does. What else would send it push notifications? It should work with open-source replacements like microG, but I haven't tested that myself. Yes, it does require passing the data through Google either way, but the content of the notifications is end-to-end encrypted.

They could impliment a fallback to UnifiedPush. https://unifiedpush.org/ thame requirement of gcm may stop fdroid from including it

Yes, this is a good idea- I use UnifiedPush for 2 apps and they deliver notifications very timely. I would say that this would be even better than GCM for notifications on an open app.

[realpixelcode]

It should work with open-source replacements like microG, but I haven't tested that myself.

I do use /e/ OS with microG and haven't had any problems with Mastodon so far. 🤷

[Cyastis]

As an update, there is a new issue on F-Droid for Mastodon Android packaging and they're currently working on reproducible builds:
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11874
F-Droid now runs Debian 11, which was a requirement for getting Mastodon Android working on the F-Droid build server

[Andre601]

As an update, there is a new issue on F-Droid for Mastodon Android packaging and they're currently working on reproducible builds: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11874 F-Droid now runs Debian 11, which was a requirement for getting Mastodon Android working on the F-Droid build server

From the looks of it has it been merged 4 days ago... Not sure if there is any extra steps/requirements needed for it to appear in F-Droid, as I can't see it right now on it.

Tho, I hope that with this, the app can be updated to allow feeds from other servers to be seen (This from what I understand was a delibarate exclusion as Google's app policy doesn't allow this?).

[grishka]

They wanted reproducible builds from me, though that would require changes to the way I build release builds. I opted not to do that for now. As far as I understand, they've figured everything out a week or two ago in terms of getting the build process to work with their CI system (I did an apparently fairly non-standard thing by requiring JDK 17).

[eighthave]

@grishka FYI reproducible builds are only a requirement if you want to publish on f-droid.org using your signatures on the APKs. If you're OK with the APKs being signed by the f-droid.org keys, then you can skip reproducible builds for now. They can always be added later, then new installs will automatically prefer the upstream-signed APKs.

[eighthave]

Also, our system has to be non-standard because we build everything from source, and we only use binary packages in the build process that we have confirmed can be built from source. This is the same standard as any reputable GNU/Linux distro (Debian, Ubuntu, Fedora, RHEL, Gentoo, etc). This goes against what Google is trying to with the Android ecosystem since they are pushing hard to get everything using their proprietary bits so that they can control the ecosystem.

https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

[linsui]

This app has been published in F-Droid 2 days ago. https://f-droid.org/en/packages/org.joinmastodon.android/

[IzzySoft]

@Gargron @grishka as usually shortly after this point I remove apps from my repo (given a 10..14d overlap), time for a short question: As Mastodon is set up for reproducible builds the question was asked whether I shall keep it in my repo, e.g. in case of a "stuck build" or "emergency release" – as my updater picks your APK within 24h of your tagging & attaching, while F-Droid's build cycle will require at least around 2..3 days. Thanks to the reproducible build, such cross-updates are possible.

Would that be in your interest? If you're not opposed to the idea, I would mark it to stay (so my "dupe checker" ignores it).

[grishka]

I thought it wasn't set up for reproducible builds because I didn't want to change the way I sign my release apks? As I understood, the issue was that signing with apksigner (which they use) vs with Android Studio apk export (which I use) apparently produces apks that are equivalent in everything (the content and the signature) except they aren't identical if you compare them byte-by-byte — and that wasn't reproducible enough for them.

[IzzySoft]

I thought it wasn't set up for reproducible builds because I didn't want to change the way I sign my release apks?

Reading above one certainly would get that impression, which is why I cross-checked with the org.joinmastodon.android.yml. And it says:

RepoType: git
Repo: https://github.com/mastodon/mastodon-android.git
Binaries: https://github.com/mastodon/mastodon-android/releases/download/v%v/mastodon-release.apk

The last line means there are upstream binaries to check against – which only makes sense if set up as reproducible builds. With that like, the build would fail if not reproducible. Plus, I've explicitly asked at our last team meeting and was told "yes". So some genius must have found a way 🤩

and that wasn't reproducible enough for them.

Looks like it worked out. Let me check the APK from F-Droid.org:

$ wget -q https://f-droid.org/repo/org.joinmastodon.android_39.apk
$ apksigner verify --print-certs org.joinmastodon.android_39.apk 
Signer #1 certificate DN: O=Mastodon, C=DE
Signer #1 certificate SHA-256 digest: a3f19b26da3fe12b0285685f6ecc41515e6a9adcc5530b47c95d847cdae4a7e8
Signer #1 certificate SHA-1 digest: 94f3b9548d24a6e8049f7b68d589919f1b9d7dea
Signer #1 certificate MD5 digest: 58593b36a6244c056a1a292598d62be4

Looks like your signature, no? At least it is the same output for the one from my repo, so they match.

So you're OK with me keeping it in my repo then? Or shall I remove it? Guess it cannot hurt keeping it, might even be useful (see above).

[linsui]

@obfusk add support for apks signed with gradle to apksigcopier so it works with mastodon now.

[obfusk]

Reproducible builds by definition require "bit-by-bit identical copies of all specified artifacts", which in the case of Android apps means bit-by-bit identical APKs.

Of course this can be hard to achieve. And metadata differences may seem irrelevant. But that's what it means for a build to be reproducible. Being of the opinion that "comparing whole apks byte-wise isn't a good idea to begin with" doesn't change that.

So no, an APK that wasn't bit-by-bit identical indeed "wasn't reproducible enough". Because it doesn't meet the definition of "reproducible build". Not only that, everything but the APK Signing Block must be bit-by-bit identical for any v2/v3 APK signature to verify.

Unfortunately, signflinger (used by gradle / Android Studio) uses different ZIP metadata for the v1 signature files than apksigner does, requiring modifications to the way we copy APK signatures.

Even more unfortunately, it also adds a 132-byte "virtual entry" at the beginning of the APK during signing. This "virtual entry" seems to serve no purpose whatsoever, but it certainly makes the APK no longer bit-by-bit identical.

We had to figure out what those "mystery bytes" were, how they came to be there, and how we could make signature copying work correctly and safely in their presence.

Which we did, now allowing us to publish apps signed with signflinger (like Mastodon) using reproducible builds.

[IzzySoft]

Thanks for explaining, @obfusk!

@grishka before my question is lost along the path: Shall I keep Mastodon in my repo, now that it's available at F-Droid? I was asked to and gladly comply, provided you're not opposed.

[grishka]

I'm not opposed.

[IzzySoft]

Thanks @grishka – then I'll now mark it for being kept, with a corresponding hint. If any questions arise later, be welcome to call me 😉

[linsui]

1.1.4 is not reproducible because:

1. The github release uses a different flavor. This is not a big problem, we can use the same flavor or you can upload the apk built from release flavor.
2. The png files are different.

res/CC.png
res/Je.png
res/nI.png
res/nr.png

This is caused by PNG optimization tools. You can either disable the optimization or commit the optimized png files to the repo directly.

Could you please take a look? Thanks!

[linsui]

By the way, those different files are the same images. Not sure why only these files are different.

[grishka]

Hm. It's not even supposed to be a png, it's a vector drawable 🤔
Why is android studio constantly trying to outsmart me?! No, I don't want to rasterize vector drawables unless absolutely necessary, and this doesn't look like absolutely necessary to me.

[linsui]

Then could you please add vectorDrawables.generatedDensities = [] to disable the behavior? This can make the apk reproducible again. See https://developer.android.google.cn/reference/tools/gradle-api/7.1/com/android/build/api/dsl/VectorDrawables.

[eighthave]

linsui:

Then could you please add `vectorDrawables.generatedDensities = []` to disable the behavior? This can make the apk reproducible again. See https://developer.android.google.cn/reference/tools/gradle-api/7.1/com/android/build/api/dsl/VectorDrawables.

That trick is new to me, would that make sense to document it on https://f-droid.org/docs/Reproducible_Builds/ ?

[linsui]

It weird that the doc says that For the PNGs to be generated, minimum SDK has to be below 21. but the minSdk is 23.

[eighthave]

Sadly not surprising, Android Studio is buggy.

[licaon-kter]

@grishka any timeline for me.grishka.appkit:appkit:1.2.16 being available in maven?

ref:
org.joinmastodon.android_84.log.gz

[grishka]

You're saying that like I'm intentionally withholding it. I just forgot. Again. Published now.

[licaon-kter]

Odd way to respond...

I just forgot. Again.

Thanks ❤️