Publish to F-Droid

[qazip]

Have you thought about publishing baldphone to F-Droid?

[walrus543]

@qazip You may know Izzy's F-Droid repo. Baldphone can be downloaded from there. (+ automatic updates)

@UriahShaulMandel Since Baldphone is mainly developed for elderly or handicapped people they don't know what Github or F-Droid are.
May I suggest you to consider publishing Baldphone on Google Play? I set automatic updates on Google Play for the device of my grandmother.
I already know what I'll have questions from her as soon as the first update will reach her phone lol

[UriahShaulMandel]

Hi @Primokorn
BaldPhone was on the google play, for several months.
Then came this
BaldPhone should not be affected, especially because it's Open Source and google can see that no information is being taken.
Iv'e sent a lot of emails, even mailed the ceo of Google in israel, tried for 3 weeks (until the deadline) to convince them to give BaldPhone permission to read the call log but got no response (only bot responses) and sadly had to remove the app from the play store.
I hope that more users will use the BaldPhone, and perhaps the GitHub repo will have more traffic, and mabye someone from Google will see how cool the project is and will help me to reupload it to the play store.

[UriahShaulMandel]

And apparently, I can use a different branch on f-droid, like this
So expect BaldPhone on F-Droid soon :)

[walrus543]

@UriahShaulMandel Thanks for the explanation. F-Droid is a decent alternative (that I use for years) but still hard to explain to an elderly person.

[DJCrashdummy]

@Primokorn if you can somehow gain root access of the device, i advise to install F-Droid Privileged Extension additionally, then you can configure f-droid to check for, download and install updates completely unattended.
...so no explanations needed at all. 😉

[walrus543]

@DJCrashdummy I know but I don't want to root her phone (too much power for an elderly person).

[DJCrashdummy]

@Primokorn
with an ("unrooted") custom ROM (like LineageOS) you don't need to provide root access at all... simply flash the zip-package and you are ready to go. even some custom ROMs have it pre-installed/-flashed by default, but i'm not sure which of them.

or at some custom ROMs you can also deactivate root access or also unroot the phone completely after installing F-Droid Privileged Extension... no idea if this is possible with a stock android (never even thought about it, nor done it).

---

or e.g. i installed and activated root on a bunch of phones, but granted root access just for AdAway, oandbackup and if needed Wrong PIN Shutdown... a very short timer to ask for root permissions (default answer is "no") does the rest.
i only got a very few questions, "what is this window which disappears by itself?", but never had a problem with a messed up phone by their users via root access. 😉

but that's clearly getting OT, sorry for that.

[UriahShaulMandel]

Made me think perhaps I can release a fork of LineageOS, preinstalled with BaldPhone, with system access so it has auto-update enabled.

[DJCrashdummy]

@UriahShaulMandel not sure if this is worth the effort: because you need an pretty techy "admin" resp. friend to flash no matter what custom ROM. and after that, setting up f-droid to do the auto-update is easy peasy at least for this techy admin... and if the "F-Droid Privileged Extension" is preinstalled, not just for them.
so IMHO, publishing via fdroid has a much much higher priority than an own BaldPhone ROM! not to mention that the user base of an fdroid build would be much higher then the user base of an own ROM, but with considerable less effort.

[UriahShaulMandel]

Yes, right now I'm on vacation, but as soon as I come back, I'll release BaldPhone on F-Droid

[DJCrashdummy]

no pressure from my side... i just wanted to help organize priorities and balance effort & use.
enjoy your vacation @UriahShaulMandel! 🏖️

[UriahShaulMandel]

Hi, mainly targeted towards @IzzySoft , which is a maintainer of F-Droid, but every help will be appreciated

I want to release BaldPhone to F-Droid main repo too as you suggested.

I've added an F-Droid branch, which doesn't use BaldPhone in-app updating mechanism, you can check it out here

I found a way to keep working only in the master branch, and only before releasing a new version I merge the new changes into the F-Droid Branch.

With that said, I've encountered a problem:
The master flavor, used by a lot of users, depends on the releases mechanism of GitHub,
It uses Releases API to find the last version, and if it's newer than the current one, BaldPhone downloads the APK attached with the version.
I understood that the official repo of F-Droid uses the releases mechanism too, and compiles the last release itself.
So my question is, can F-Droid detect that a new release was released, but compile a different branch, and not the branch that was released?
If it can't, the only workaround I can think of is to publish releases with the F-Droid compatible code, but attach the master APK, which sounds to me like a bad practice, because the attached APK won't match the source code. It'll work, with both of the versions, but I would like to avoid this workaround if possible.

Any suggestions?

[IzzySoft]

I'm not a dev and neither a packager, so please forgive any inconsistencies etc.:

Are you familiar with build flavors? That's what's normally used in such cases. AFAIR F-Droid cannot easily work on a different branch – but then, what might work (and here comes the "I'm no packager" part):

• you work on the master branch. You make a "normal" release, and tag it as usual (i.e. creating a tag matching the versionCode)
• now you merge to/update the fdroid branch, and create a new tag on its latest commit, naming it e.g. fdroid-<versionCode>. So that tag points into the fdroid branch.
• at F-Droid, we tell the updater to watch out for tags named fdroid-%c. So the update checker finds the new F-Droid tag (while it would ignore all the non-fdroid tags), and creates a new build block for it. So the build server would fetch the tree at that commit – and should get the fdroid branch (that's the only one having it).

Not 100% sure if that works that way – because if it is, why was there talk about issues with branches? So build flavors (aka build variants) would be the better approach – and should also save you from maintaining two branches and from the merging otherwise needed.

[UriahShaulMandel]

Hi @IzzySoft , I added build variants as you suggested.
You're right, it's much easier and overall a better technique, thanks!

I did it like this project, now I have two build variants,
baldUpdates - the current system of updating via the apk attached in the latest release
and
fDroid - the one which F-Droid will compile and upload to the store

Is there anything else I need to do before uploading BaldPhone to F-Droid?
Thanks again!

[IzzySoft]

The only thing coming to my mind is establishing Fastlane structures (see here to get an idea: no need to install Fastlane, just create the structures and fill in screenshots etc). That way you could provide (selected) screenshots, and also could maintain summary/description yourself – even for multiple locales (I guess you'd like to have at least Ivrit next to English), plus per-release changelogs (which then would be shown "inline" with the app description when viewing it in the client). Then have a tag covering this – and I'd say after that go for it. If we missed anything, we'll find out then.

When ready for the RFP, just let me know: I can provide the metadata template as that's mostly a copy-paste from my repo, just with the build details needing to be added.

[UriahShaulMandel]

Hi, I added the screenshots and the texts in this commit.
Right now I'll keep things English only, there are some things I have to do first.
But in some weeks from now, I'll update the texts and screenshots, and translate them to multiple languages. I would still like to have BaldPhone in the store right now as is.

The only thing I wasn't sure about was how to add the changelog, which I didn't add. Can F-Droid just use the changelog from the releases? Aside from that, I think BaldPhone is ready :)

[IzzySoft]

There are two ways to provide access to changelogs: via a link ( Changelog:) in Metadata (which the user then has to "press" explicitly), or via fastlane/metadata/android/en-US/<versionCode>.txt changelog files in Fastlane (which get shown "inline"). One doesn't exclude the other, so you can have both.

Fastlane structure looks good! Though I'd recommend not to use "framed" screenshots: the frames waste useful screen estate. Consider your "bald ones" evaluating your app on a 5" mobile screen: the less "clutter" around, the better they can visualize the "real important stuff". Just a recommendation, not mandatory – but especially in context of this app's purpose I felt the need to mention it 😉

I'd setup the RFP in the evening if you wish – to give you a little time to (optionally replace the screenshots by non-framed ones and) tag the latest commit (F-Droid grabs only what is tagged, so currently it would not "see" the Fastlane structures).

[UriahShaulMandel]

I've done it, and I think I'll show the changelog via a link at the meantime.
Thank you very much for everything!

[UriahShaulMandel]

You're both right, I changed, waiting for tests to complete and releasing :)

BaldPhone/fastlane/metadata/android/en-US/short_description.txt

Line 1 in ca4dcf5

Replace your phone's interface with a big, simple and friendly one

[IzzySoft]

Great! Will be automatically picked up (if I remember correctly, we've set it up that way, to check the tags).

[UriahShaulMandel]

Hi, I saw BaldPhone in F-Droid, very cool :)
But I noticed a few problems:

1. The latest release is shown as Version 11.3.4 (80), but I published a new one.
2. "App not installed" error is shown when trying to install the apk

[IzzySoft]

1. As this was the initial merge, our system could not have known about "updates" (of what was not yet there). The new version should appear soon (we did enable auto update check, didn't we?)
2. Could it be you have some "remains" from a previous install there? Keep in mind the signature has changed, so the two would certainly clash. Can you retry with a "clean device"?
3. Would you prefer I keep your app a little longer in my repo? You tell me when I shall remove it (to avoid users getting confused when installing from one source and trying to update from another – again, signature mismatch).

[DJCrashdummy]

ad 1. auto update seems to be enabled and that it has worked for Version 11.4.0 (81). 👍 👏

[UriahShaulMandel]

Everything is working! @DJCrashdummy and @IzzySoft Thank you very very much!
@qazip I thought you may want to know too.
The only thing I noticed, which isn't that important, is that BaldPhone is not in the "latest" tab in the F-Droid app. Thought it could be nice to have there, so more users will see it.

Would you prefer I keep your app a little longer in my repo? You tell me when I shall remove it (to avoid users getting confused when installing from one source and trying to update from another – again, signature mismatch).

@IzzySoft You know better than me, but I don't see any problem with keeping BaldPhone in your repo too. The more the better :)
Thank you all, I'm closing this issue.

(You can still comment in this issue if you have something to add)

[IzzySoft]

that BaldPhone is not in the "latest" tab in the F-Droid app.

That tab is mislabeled for a while now and should read "featured". In order to have an app show up there, it must have screenshots and per-release changelogs. Baldphone's Fastlane directory lacks the latter.

As for the "double keep": Updates are definitely faster with my repo, as long as you keep attaching the APKs. Users who installed it from one repo won't get update recommendations from the other. The only thing I'm not sure about is: even with both repos having the same version, which one would be recommended to the user on first install? I've just checked: though the one from the main repo is listed one day newer, it's the APK from my repo (I had expected the official one getting preference). Seems like the algorithm is "pick the (first) one with the highest versionCode". I'd rather give the "more trusted source" (i.e. the official repo) preference – but that's nothing we can change. We could only work around that (e.g. using a different package name) – but is it worth the effort?

Just remember that cross-updates are not possible; so whatever source a user is installing it from initially, (s)he is stuck with until uninstall. Which is why I usually remove apps from my repo at this point, with few exceptions. Some apps have their APKs in both places:

• beta/test versions in mine (usually going by different package names, like appending .beta: Bitmask, RiseUp)
• different feature sets (things not complying with F-Droid's inclusion policy but meeting mine: MTG Familiar)
• two apps I've initially installed from my repo and was too lazy to switch (that I should fix soon: one (aRevelation) doesn't have its own data, so switching should be easy – and the other (Camera Roll) currently has its development stalled anyway)
• one returned to my repo when F-Droid didn't deliver an important update in time (due to technical issues) and I could remove again
• one (FairEmail) was brought back to my repo on demand of several users, as the app updates almost daily and F-Droid thus skips a few versions everytime
• several cannot be updated in F-Droid anymore due to introducing dependencies not conforming to F-Droid's inclusion criteria (e.g. FBReader)

Shall we have a poll? 😄 With the two of us undecided, what do the other two you just pinged think?

[UriahShaulMandel]

@IzzySoft After doing a lot of thinking I think it's best to remove the current version of BaldPhone from your repo, and to add a beta version of BaldPhone there instead. I really need to start ab testing and it can solve both of the problems at once. Is it OK? How should I do it? Can you take pre-released versions and change their package name?

Again, Thank you very much for everything!

[IzzySoft]

That would be perfect, and I gladly comply!

I can't change package names (and neither can I sign), so I'd need signed APKs with a different package name to start with. You could use a build variant for that, which basically is identical to the "standard one" with the exception of using a different package name (I'd suggest appending .beta to the real one, so com.bald.uriah.baldphone.beta – Gradle has an automatism for that even, applicationIdSuffix (see the example on the linked page), so you'd just need to provide the suffix and it would join the two on build; F-Droid's build server doesn't support that currently, so only use it for the beta build, please). A "product flavor" (described on the same page) would work as well, whichever is easier for you.

Then we need to take care with the tags/releases, to have the F-Droid build process ignore the betas (and mine ignore the "real releases"). Update check at F-Droid must use %c currently (tag name corresponds to versionCode) – so for the betas, you could use %v instead (tag name corresponds to versionName). Easy to adjust on my end (just let me know when it's ready), and no adjustments needed for the official repo. Note that for version compare, my update checker will ignore letters (so e.g. 1.0.2-alpha3 would be considered newer than 1.0.2-beta1 because 1.0.2-3 > 1.0.2-1 – you have no idea what funny tag names people come up with making that necessary).

[DJCrashdummy]

[...] BaldPhone is not in the "latest" tab in the F-Droid app. Thought it could be nice to have there, so more users will see it.

just an idea: maybe it is possible to introduce BaldPhone at #TWIF? ...because i really don't know a similar FOSS project and think thereby it will get some additional attention (which it definitively deserves).

citing from the last TWIF:

Do you have important app updates we should write about? Send in your tips via Mastodon! Send them to @fdroidorg@mastodon.technology and remember to tag with #TWIF. Or use the TWIF submission thread on the forum. The deadline to the next TWIF is Thursday 12:00 UTC.

General feedback can also be sent via Mastodon, or, if you’d like to have a live chat, you can find us in #fdroid on Freenode, on Matrix via #fdroid:f-droid.org or on Telegram. All of these spaces are bridged together, so the choice is yours. You can also join us on the forum.

---

sorry for adding this to this old issue, but i just wanted to mention it and not sure if it deserves its own issue.

[UriahShaulMandel]

Thank you very much @DJCrashdummy !
It looks great, I'll send BaldPhone now :)

[UriahShaulMandel]

@DJCrashdummy do you know how to submit BaldPhone to TWIF? I went to the forums and it's not clear...

[DJCrashdummy]

well, not really... i'm just a FOSS-enthusiast and advanced user (resp. reader in this case) who really cares.

i guess regarding TWIF it is the best to contact the fdroid-team via Mastodon with #TWIF or their forum and ask/suggest to include BaldPhone.
additional i'm quite sure it is more likely to get picked up resp. get picked up faster, if there is already a nice sober text/article they can use.

...if you face problems, i guess they would be also glad to help at Freenode, Matrix, Mastodon, Forum or Telegram (as also linked in the previous quote).
...or perhaps @IzzySoft can help in this case too?

[IzzySoft]

I'm not involved with TWIF. But sending a note to @fdroid@mastodon.technology on Mastodon should raise the attention. Their forum thread which you linked probably as well. Not sure if there's a separate (GitLab) repo used for tracking (none going by a name including "twif").

[UriahShaulMandel]

Hi @IzzySoft ,
I've released an update a few days ago, and it doesn't show up on the official F-Droid repo. How long should it take? Perhaps the build failed? How can I know?

[IzzySoft]

Oh, it sometimes takes a little. Cannot show up before a new index is released (which is easiest to check via my repo browser here – which currently tells you the last index update happened on August 13). You can also check build activities here and see there haven't been any since your release.

(Apologies for the delayed response, but I was AFK)

[UriahShaulMandel]

Ok, thanks!
Does updating always take that long?

[IzzySoft]

No. Sometimes it takes longer. And other times it just happens the next day. Unpredictable due to the manual steps involved which only a single person can perform (the one who has the keys to sign with).

[UriahShaulMandel]

Not sure why it's still open, everything is working :)
Thank everyone who helped, I'm closing this issue

[IzzySoft]

@UriahShaulMandel maybe you kept it open because we wanted to switch your copy in my repo to test builds, while keeping production builds in the official repo? Currently both have the production builds.

Oh, and you might like to add the attachment to your project (after unpacking) – just made for you 😉

baldphone-fastlane.zip