Maybe this will help:
I’ll send you a link to a new build via PM.
diff.zip (343.5 KB)
The build id is not removed. And there are many embeded path. You need to remove them with prefix remap. See https://github.com/fcitx5-android/fcitx5-android/blob/33f1153e0b33c7a8dad93cb19a811f808b360538/lib/libime/src/main/cpp/CMakeLists.txt#L39 for example.
I don’t know why the build-id isn’t removed, but this commit does remove the path prefix, so maybe it is good enough to have a stable build-id:
@Licaon_Kter I’ll send you a new APK file
Now only the build-id is different.
Okay, that’s good progress.
This will remove the build-id:
$ readelf -n ./app/build/intermediates/stripped_native_libs/fdroidRelease/out/lib/armeabi-v7a/libfairemail.so
Displaying notes found in: .note.android.ident
Owner Data size Description
Android 0x00000084 NT_VERSION (version)
description data: 15 00 00 00 72 32 35 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 39 35 31 39 36 35 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Test release:
https://bitbucket.org/M66B/fairemail-test/downloads/FairEmail-v1.2114a-fdroid-3eb689cb1f-release.apk
The commit to use is in the filename.
It’s reproducible now. 
That’s nice to hear.
What I was wondering: people installed the F-Droid build signed by F-Droid. So, how will this be distributed? I hope the F-Droid app won’t reinstall the current version because this would anger people for sure. If this is the case, I don’t want a reproducible build to be published because in the end people complain to me.
Currently, with Binaries we publish upstream apks only, with signature files we publish both apks.
So, basically, I only have to run this task before committing a new release tag?
And there is no reference APK file needed, correct?
I checked how newpipe looks in the F-Droid app, but it isn’t visible at all, which is the F-Droid build and which is the repro build. I think that’s rather confusing. How can the user decide which version to install, knowing about the advantages and disadvantages? As it is, the user doesn’t even know which version (s)he’s installing.
Since the GitHub and F-Droid build of FairEmail are not the same and since they will become interchangeable because they will have the same signature, I’m not sure if I want a reproducible build to be published, even though I have everything ready for it now. It can lead to problems, like for example, Play Store purchases not being recognized anymore, without the user knowing.
I like the concept of reproducible builds, but it does not seem ready to me.
They can’t. 
I thought so. Generally we only enable reproducible build for new apps. If you still want to get some benefits from reproducible build, you can publish the hash of the unsigned apk so that we can check if our build is reproducible.
While there are two variants for the same version, they’re for different architectures. One is 32-bit and another is 64-bit, and both are reproducible builds.
Only people who already had NewPipe installed a long time ago when it was not a reproducible build receive updates that are signed by F-Droid, and all new installs are signed by NewPipe. The same would apply to FairEmail (as far as I understand).
This would only happen if the user installed FairEmail from GitHub or Play Store and then updated it with a clean version (without any proprietary crap) from F-Droid. Which is basically user error.
I don’t think 32 vs 64 bits is correct. I think it is F-Droid signed vs developer signed (reproducible build).
Every month I am answering several thousands of questions, and I guess it would surprise you what types of questions I get. Saying that it is ‘user error’ is too short-sighted, also because the developer has a responsibility too. Anyway, I am rather careful to not get more questions, and this might be a reason to not go for a reproducible build.
The Play Billing API is proprietary, but it won’t and can’t do anything if there are no Play Services on the device because there is no service to interface with. So, the benefit of having a reproducible build is limited anyway.
No, I checked and its just two different architectures.
There are two benefits:
-
You don’t have to trust F-Droid with your app any more because it’s signed by you.
-
F-Droid builds the app from source and checks it against the APK signed by you to verify that the APK is indeed compiled from the same source. Meanwhile, nobody knows if the APK on Play Store or GitHub is built from that same source and there is nothing malicious included in it that isn’t in the source code.
I think there is a way to solve this. Would it make sense to sign it with a different key? (Not a developer so I don’t know if this makes sense).
Desn’t a fact that F-Droid build can’t be updated with GitHub or Play Store build and vice versa bring more questions and issues?
The chances of someone downloading FairEmail from Play Store or GitHub, making a purchase then updating it with an F-Droid build seems pretty slim.
I’m not sure which problem you are trying to solve, but signing with yet another eky will result in only more confusion.
1 Like
I was talking about this problem.
I just noticed this note on F-Droid:
Note that OAuth was not approved by Google, etc for the F-Droid build. For this you’ll need to use the Play store version or the GitHub release.
You could make another note or modify this existing one if you’re fine with doing so. It could look something like this:
Note that OAuth was not approved by Google, etc for the F-Droid build. If you install this, Play Store will not be able to recognize your purchase too. For these you’ll need to use the Play store version or the GitHub release.
That’s unrelated… You can still use F-Droid version with Gmail, if you use per-app passwords, eg. News: access removal of "Less Secure Apps" in Google - #68 by Licaon_Kter
1 Like
Then I guess that note can be replaced with the one about Play Store purchases, no? Or is that note still useful?
I already asked back then (News: access removal of "Less Secure Apps" in Google - #69 by Licaon_Kter) so maybe somebody can dare to open a PR lol
1 Like
I think it is pretty logical that Play Store purchases are available to apps installed via the Play Store only.
Also, people installing via the Play Store or people installing via another way (GitHub, F-Droid) are seldom the same people.
1 Like