pserwylo

F-Droid has spent many years trying to step out of the "only for technical/power users" into the "This is a tool that normal phone users should have and use". A one time 24hr wait moves back to the "F-Droid is only for technical users" big time.

Bought a new phone? Moved from iPhone to Android? Want help from your friend/family member/librarian/other to setup your new phone for getting apps? Sorry, you need to come back a day later before you can actually use it.

Guess what the normal/non-tech user does in this 24hr period? Go to Play Store, install a bunch of apps, forget that you had the desire to use an alternative.

This indeed does make F-Droid no longer a tool for normal people, but only a tool for those willing to do a bunch of "Advanced" things on their phone. By definition, not regular users.

And just like that, another major policy statement from the Android team that is completely devoid of actionable information for those impacted:

> Our new Registered App Stores program will provide a more streamlined installation flow for Android app stores that meet certain quality and safety benchmarks.

As with Developer Verification, I hold little confidence that the criteria for "certain quality and safety benchmarks" will be specified before this is rolled out (or even after).

Many people online and in person telling me "Google backed down" or "Google has an advanced flow" are typically referring to these two statements from Google staff:

> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. [0]

> Advanced users will be able to"Install without verifying," but expect a high-friction flow designed to help users understand the risks. [1]

Firstly - I am yet to see "ongoing conversations with the community" from Google. Either before this blog post or in the substantial time since this blog post. "The community" has no insight into whether any such "advanced flow" is fit for purpose.

Secondly - I as an experienced engineer may be able to work around a "high-friction flow". But I am not fighting this fight for me, I am fighting it for the billions of humans for whom smart phones are an integral part of their daily lives. They deserve the right to be able to install software using free, open, transparent app stores that don't require signing up with Google/Samsung/Amazon for the privilege of: Installing software on a device they own.

One example of a "high friction flow" which I would find unacceptable if implemented for app installation on Android is the way in which browsers treat invalid SSL certificates. If I as a web developer setup a valid cert, and then the client receives an invalid cert, this means that the browser (which is - typically - working on behalf of the customer) is unable to guarantee that it is talking to the right server. This is a specific and real threat model which the browser addresses by showing [2]:

* "Your connection is not private"

* "Attackers might be trying to steal your information (for example, passwords, messages or credit cards)"

* "Advanced" button (not "Back to safety")

* "Proceed (unsafe)" link

* "Not secure" shown in address bar forever

In this threat model, the web dev asked the browser to ensure communication is encrypted, and it is encrypted with their private key. The browser cannot confirm this to be the case, so there is a risk that a MITM attack is taking place.

This is proportionate to the threat, and very "high friction". I don't know of many non-tech people who will click through these warnings.

When the developer uses HSTS, it is even more "high friction". The user is presented all the warnings above, but no advanced button. Instead, on Chromium based browsers they need to type "thisisunsafe" - not into a text box, just randomly type it while viewing the page. On Firefox, there is no recourse. I know of very few software engineers who know how to bypass HSTS certificate issues when presented with them, e.g. in a non-prod environment with corporate certs where they still want to bypass it to test something.

If these "high friction" flows were applied to certified Android devices each time a user wanted to install an app from F-Droid - it would kill F-Droid and similar projects for almost all non-tech users. All users, not just tech users, deserve the right to install software on their smart phone without having to sign up for an "app store" experience that games your attention and tries to get you to install scammy attention seeking games that harvest your personal information and flood you with advertisements

Hence, I don't want to tell people "Just install [insert non-certified AOSP based project here]". I want Android to remain a viable alternative for billions of people.

[0] - https://android-developers.googleblog.com/2025/11/android-de...

[1] - https://x.com/matt_w_forsythe/status/2012293577854930948

[2] - https://wrong.host.badssl.com/

While this is true of many projects, F-Droid has a track record of sourcing funding for security audits. To date there have been at least three audits, in 2015, 2018, and 2022.

https://www.opentech.fund/security-safety-audits/f-droid/

https://f-droid.org/2018/09/04/second-security-audit-results...

https://f-droid.org/2022/12/22/third-audit-results.html

I was involved in addressing in issues identified in the first one in 2015. It was a great experience, much more thorough than the usual "numerous static analysers and a 100 page PDF full of false positives that you often receive.

The last two places I've worked I added a custom "debug bar" of sorts. We typically use in dev and lower QA environments, and they quickly become indespensible to help answer questions like "which version of service X is deployed", something that may be easy for a dev to answer as they can look at what is deployed on the server, but harder for a tester who can only access the frontend.

Other useful environmental information we find useful includes "which DB is being used", which OpenShift namespace (with a link to the console), traceability for the deployed artifact (e.g. links to the GitHub release tag, CI pipeline which built the artifact, docker registry with the correctly tagged image). Especially useful if you have downstream or upstream services, is to have colour coded status info about whether the services are up.

For the few days investment getting this up and running, it pays itself back in terms of time gained answering questions such as "Why doesn't this feature work? Oh, after investigation, this service was down during testing".

I find a good IDE that you are already familiar with from other languages/environments goes a long way. Pick your poison, but for me because I'm already using IntelliJ for Java at work and Android Studio for open source projects, I was able to get into Go relatively easily recently using IntelliJ.

The linter/autocompletion/auto-fix/refactoring/etc made it much simpler to a avoid having to rote-learn the syntax for functions, lambdas, structs, etc. To go with that, the error handling becomes much easier to learn because the editor is able to tell you when you've got the wrong number of return values / wrong type of values.

Yes, the compiler does all of this, but the way it happens in real time using the same keybindings/UI/UX that I use for my day job makes it all that much easier.

This is the discussion on implementing a popcon-style feature in F-Droid if you want to read through where the project got to: https://gitlab.com/fdroid/fdroidclient/-/issues/396

I love this so much. I remember reading about this game in a PS1 magazine as a kid, but I could never get my hands on it. For some reason, it stuck with me for all these years until I finally got around to making an open source Android game inspired by it: https://github.com/beat-feet/beat-feet. The idea of loading up your own MP3 files and playing levels is something I think should get a lot more mileage.

Those who enjoyed this should also have a laugh at:

"Vim Exit% Speedrun [WR - 2.50:13]"

https://www.youtube.com/watch?v=TLbfqZBL8t8

The Centennial Light mentioned in this article also features in a later chapter of the wonderfully written 17776 [0]. It will take a while to get through it, but very much worth the time.

[0] - https://www.sbnation.com/a/17776-football

I always loved over-the-top, somewhat impractical visual effects like this. Reminds me of growing up playing with Compiz Fusion.

For a retro Android game I maintain, I use the term "Gratuitous Eye Straining Effects" in the settings page. It needs to be toggleable, because I can only tolerate it for a short period. My naming was inspired by k9mail's settings called "Gaudy visual effects". May as well have some fun with words when implementing such effects.

I write and maintain a GPLv3 multiplayer game for Android to satisfy a creative itch. While writing the game, sustainability of the server component is top of my mind. I'd hate for the game to stop working for others down the line because I lose interest or am otherwise no longer able to tend to it.

For those interested, I've documented the process I adopted to try to increase the bus factor beyond one [0]. I want people who download the game and open it to be able to find a public server instantly from the main menu, even if I am unable to maintain the main server myself. This is done via the game requesting a manifest containing public servers from a GitHub repo, which accepts PRs from those willing to maintain their own servers. Although I am the only one able to accept those PRs right now, it would be silly not to be liberal in onboarding others who show an interest in maintaining the list. That way the game lives on beyond just me.

I also make sure to offer local multiplayer, and in other games I've built I which don't need realtime multiplayer, I try to offer "Play against others by sending an SMS invite" or other novel approaches that don't even need a server.

It is a fun space to work on and try to come up with novel solutions to ensure games continue working into the future.

[0] - https://peter.serwylo.com/2021/07/03/sustainable-server-infr...

When faced with the previous system [0] - where full table scans were the norm and filtering/sorting was done in Java afterwards - we certainly could have gone to proper database queries. I think it is mostly the first thing - that we wanted to move into the background instead of full table scans on the UI thread, and indeed CursorLoaders were an agreed upon way to do that with the (then, relatively new) RecyclerView.

But yes, you are correct that they are indeed an inconvenient database abstraction.

The only thing I will say is that despite the crummy abstraction, we did put the effort in to have good test coverage of each ContentProvider. It took a while to get the infrastructure up and running so that we even could test them, but once the plumbing was added, it became simple to add new tests to ensure they worked as expected.

This is important when you need to take into account things like "Get me all the apps, but filter on category, and then also limit those Apps to ones for which they have at least one Apk which is installable on my hardware, meets my AntiFeatures requirements, and then also pull back data about whether there is a version that can be upgraded to or not based on currently installed apps. I fell in love with the SQLite explain output. I found it really good at explaining what was going on with these mildly complex joins - much easier than the MySQL explain output I was familiar with.

[0] - https://gitlab.com/fdroid/fdroidclient/-/blob/b3773a156121cf...

Congratulations team. I was involved in the project for quite some time years ago. Indeed I ported the original “Read the full index.xml into Java memory using a giant DB class” with the first “Stream entries from XML into the database, and make use of ContentProviders” because they seemed like the “Android way to do things” at the time. I also worked on the migration from XML to JSON metadata. At the time this was done, we needed to updated the metadata format to support internationalisation of metadata and the inclusion of images.

To see Torsten and others working on replacing my crufty-passed-their-use-by-date ContentProvider code with a modern Kotlin + Room implementation is heart warming. If any of you are reading this, please accept my deepest sympathies for having to pull that code out and rework it - that is not something I would have enjoyed doing! It is even better that it all lives in libraries that other clients can adopt if they choose so they don’t need to reinvent the wheel.

For those interested, yes, I am also responsible for writing the bulk of the code for the “new” (now several years old) UI in the offical client which often gets maligned on HN (and this thread is no exception). At the time I did my best to fight off edge cases and quirks of the Android system. F-Droid needs to ask Android which apps are installed and what their signatures are, then cross verify that with its own database to tell you whether updates are available. It also needs to know whether new apps have been installed outside of F-Droid since last time you opened it, etc. It also needs to pass downloaded .apk files to the system and request for them to be installed, then wait for confirmation from the system. The API’s Android provide for this kind of work, but they always seemed flakey, unwieldily, and slow to respond. The whole experience is full of race conditions, and each bistro seems to handle it ever so slightly differently.

I am still proud of how much we managed to achieve, and I’m also very pleased with the fact we were able to do so much great work around internationalised metadata, screenshots, encouraging donations to app developers, etc. But I’d be lying if I said I wasn’t still a little disappointed that I couldn’t iron out all of the kinks.

Life circumstances meant that I drifted away from the project and no longer contribute (other than via Liberapay donations to the wonderful fdroiddata team). However I would love to revisit the project in the future to see if I can address some of those edge cases to ease the user experience for all of us. You may have noticed that for such an amazing project, used by many people (not just the client, but the entire infrastructure), there has been comparatively few contributors. Despite that, I am still extremely fond of the value they bring to the Free and Open Source ecosystem.

Although asking about books, I'll share my current experience as a software developer with 15 years experience trying to self-learn electronics.

1. "YouTube University" as per the top comment on this HN post [0]. I watch a few videos on the train to work or when winding down in my spare time. Over the past few months I've come to appreciate certain channels, your learning style may prefer others, but my list includes: The Engineering Mindset, Ben Eater, EEVBlog, learnelectronics, and ElectroBOOM, as well as whatever else I stumble upon when searching specific topics.

2. Reading theoretical concepts from text books. I've read https://www.allaboutcircuits.com/textbook/ recommended elsewhere in these comments and found it very well written for someone like myself just starting out. It covers the full gamut covering basic movement of electrons through to practical stuff - indeed much like the Ben Eater YouTube channel does).

3. Practicing mechanical skills like soldering (which also results in earning things I didn't know I needed to learn, such as "how do you keep this thing still while trying to work on it").

4. Prototyping with breadboards - both projects including micro controllers and those focusing on discrete electronics. This feels most like a literal application of my software dev skills, but with all of the theoretical electronics stuff sprinkled in. Although starting with just a basic collection of a few resistors, capacitors, LEDs, transistors was fine, now I enjoy having a steady stream of orders from AliExpress coming in. Each one is only the price of my morning coffee but takes a month to arrive, so whenever I am working on something and think I am lacking the components, I'll place an order then forget about it until it arrives.

5. Pulling apart things to see how they work - this is extremely satisfying because it helps not just with learning about how people lay out electronics projects, but also how the physical connections are made - how are PCBs mounted, where are springs and screws and other bits placed. It also helps practice desoldering skills.

6. Designing PCBs and getting them printed. It only costs about $5 to get a few copies of a PCB printed and mailed to you, designed using the free software KiCad. When I've got a toy project that worked on a breadboard, then also worked on a prototype board, I then go and design a PCB to print. So far in 2 months I've designed and printed 3 boards. This is also extremely satisfying, and also helps learn more skills on the software and design side of things.

Finally, I share liberally with my friends via SMS when I make progress. I have a few close friends who are good at electronics but don't do it professionally. By sharing my progress with them, I have people ask me how it is going, which keeps me honest and makes me want to keep making progress.

After 2 months of spending an hour or so each night after the family goes to bed, I feel like this time I may actually pick up the skills I wanted. Previous attempts over the past 10 years have all failed due to lack of motivation.

[0] - https://news.ycombinator.com/item?id=16775744

I write Android apps for my baby-now-toddler.

At a few months old I created BabyDots [0] as she loved this YouTube video of dancing dots [1] which really settled her when she was upset as a young baby.

At over a year old I added BabyPhone [2] to let her talk to family and have them “talk back” to her even when they were not available. I missed the timing on this and she didn’t enjoy it at all until literally this week when she started talking back to the little baby on the other end of the phone.

At 18 months old I made a book-building app [3] that takes titles of pages on Simple English Wikipedia, and creates pages for a book that can then be exported as a PDF and printed (or viewed on the phone). It also has a website [4] on a free heroku dyno which definitely won’t take much traffic. This was because when she gets interested in, e.g. planets, I don’t want to have to order a book on planets, I want to print one out 5 minutes later to keep her interested.

One of my proudest moments was at my new job where a team member said during our first standup “I have your baby dots app installed and although we don’t do screen time, the music really sooths our kid during nap time!”.

[0] - https://github.com/babydots/babydots [1] - https://www.youtube.com/watch?v=8DILz54aYFU [2] - https://github.com/babydots/babyphone [3] - https://github.com/babydots/babybook [4] - http://book.serwylo.com/

> F-Droid builds are custom signed and can be made by random parties without proper auditing after initial review.

F-Droid follows a similar model to traditional linux package managers which has shown time anda gain the they are both trustworthy and secure (or at least, they offer the user the freedom to choose the level of trust they have in the package signers).

When installing from a Debian repo, I'm typically installing a package that is not build/signed by the upstream developer. I am implicitly (in the case of a default install) trusting the Debian developers signing practices or explicitly (if you add a third party repo). This means you trust both those in charge of the building/packaging/signing as well as the upstream developers. The same is true of F-Droid.

Of course, the notable exception is that F-Droid also supports upstream packages signed by the developer if the builds are verifiably reproducible.

I'm in a fortunate enough position that the day job pays the bills and I enjoy it, such that I don't need income from my open source efforts.

However, about a year ago I did two things:

- Enabled sponsorship through GitHub and Liberapay.

- Put my GPL apps (freely available on FDroid) on GPlay for $1.

Since then, I've made a fun amount of ~$300 in little donations (a combination of one off and recurring sponsorships). Although a tiny amount of income in the scheme of things, it is still thrilling each time someone kicks a small donation my way even though there is no obligation to do so. Itis a nice pat on the back for things I do for free anyway.

Also, given that I do zero self promotion and very minimal nagging (just in some of my release notes), and given I spend probably less than a total 7hrs a week on all of my projects combined, it makes me think that this could be ramped up if I was to dedicate more time to it.

Some things I try to do with each project to help gain traction:

- Release often, so it appears at the top of the FDroid front page regularly.

- Take i18n seriously so that people around the world can benefit from the apps.

- Foster a sense of community and inclusion in any discussions (e.g. GitHub issues and PRs). I also try to add new apps whenever a new idea comes along. Hopefully a large diverse range of apps will find use with more people.

Hopefully in the future that $300 will grow to $500, $1000, or even more.

A good high level overview of the moving parts involved in front end dev is https://roadmap.sh/frontend. Not all of it is used all the time, but if you can talk intelligently about many of the parts you are doing fine.

My recommendation to people learning specific frameworks such as react is to start with vanilla react (their doc's are quite good). Then, after building a small app that solves a problem for yourself, you'll start realising when you have bugs and other maintainability issues related to state management. At that point, it is worthwhile looking into redux (or another state management library). Otherwise if you go straight to react + redux it can just feel like a lot of boilerplate for no reason.

Same with TypeScript. I think type safety offers a huge reduction in the number of bugs in large systems. But it isn't required when first learning react.

While I don't disagree about the fact it will likely cause a split similar to Angular, they seem quite explicit about the reasons (not to scratch the itch of the framework's designers).

For me, working in a large project with TypeScript vs one in vanilla JavaScript makes all the difference in terms of how maintainable it is. The number and the nature of the tests I need to write for such project changes, the IDE tooling available makes development much more pleasant, and I generally feel like it is harder to write code that is buggy, because a large amount of potential errors are avoided through use of the type system.

Whether or not they've made the right decision with this split is a different question that I can't answer.

The Android Firefox browser is great. Not only does it do everything you expect a modern mobile browser to do, but also supports extensions, including uBlock Origin.

Good point. We had great success doing this with our PHP code base. For us it wasn't about pretty or not-pretty code, but rather about type safety. The idea that you can have a method which accepts "WhereClause $constraints" instead of "string $constraints" means you can be much more confident that the code is correct.

We actually wrote a custom query builder because none of the available ones (e.g. Doctrine) had the type safety that we desired. A direct parallel to what we used is the Java library JOOQ, in terms of its querybuilder API [0].

[0] https://www.jooq.org/doc/3.10/manual/sql-building/sql-statem...

If someone is looking for the equivalent on Android, I'd recommend the free and open source Orgzly[0][1].

[0] - https://play.google.com/store/apps/details?id=com.orgzly

[1] - https://f-droid.org/packages/com.orgzly/

What you have described makes sense only if they were originally hired as penetration testers. I think an external hack of this nature, even if done by white hat hackers, should rightfully be treated differently.

Having said that, you raise an interesting point, because if this money was paid as a bug bounty, then perhaps the lines would be blurred again. I guess the difference is that a bug bounty would have more clearly defined parameters about how far the hack should go. Logging into AWS using credentials that were found lying around, then continuing on to download data, seems like it is beyond the realm of reasonable bug-bounty hunting and responsible disclosure.

We added a new metadata format for this release to deal with translatable metadata, feature graphics, screenshots, etc. The server tools output the old and new metadata to the repository webroot though, so the old version will still be supported for some time. I'm not aware of any plans to completely deprecate and remove it.

As a project, we are not very precious with version numbers. There have been many stable releases before this, but we named it 1.0 because of the shear amount of new features and improvements that went into it (Completely new UX, better management of updates, screenshots, feature graphics, and perhaps most importantly is internationalised metadata (descriptions, summaries, app names, screenshots).

We are aware that it is not to everyone's liking, but we've done our best to modernise and appeal to a wider audience, all the while conducting UX tests and responding to feedback.

One thing we'd really love is for there to be an "F-Droid Light" which forks the previous stable release, strips it down, and offers the essentially app store experience with no bells and whistles on the widest range of devices [0]. Alas we are a small volunteer team and this would add a maintinence burden we can't seem to muster at this point.

[0] - https://gitlab.com/fdroid/fdroidclient/issues/48

For those who are unfamiliar with the Attorney General George Brandis, this is one of the people instrumental in implementing two year mandatory data retention.

This is a famous interview he gave which is shows how little he understands about the concept of metadata, and is mandatory viewing for all who are not familiar with him:

https://www.youtube.com/watch?v=Hw1ryLGs2ws

His utter inability to understand the issues that he is legislating is distrubing.

"What people are viewing on the internet is not going to get caught ... What people are viewing on the internet while they surf is not going to get caught. What will get caught is the web address".

The legislation ended up retaining the IP address that you visit, but not the host or URL. I suspect this is the distinction he was trying to make, but nevertheless, it is still disturbing.

The government who changed away from FTTP is the more conservative (and pro small government) of the two major parties. As such, although I disagree, I can see why they may argue that it is not the governments responsibility to deliver broadband infrastructure and that private industry should pick up any slack.

However they didn't argue this.

They stuck with the concept of a nationally funded broadband network, but one which was sub-par on almost every metric except cost. This just doesn't make any sense to me, especially because they tried to sell it to the public by suggesting that things like "Why invest so much in fibre when it may be surpassed by another technology in the near future". There was also a lot of clever wording around how their version would be "delivered cheaper, faster, etc than the alternative" - I have no doubt these words were chosen because it sounds like the data rates themselves would be faster, whereas they actually meant it the build could be completed faster.

The post itself has a pretty good list of 10 sources of non-determinism:

  1. timestamps
  2. dates/times/authors etc. embedded in source files
  3. timezone sensitive code
  4. directory order/build order
  5. non-sanitized data stored into files
  6. symbolic links/paths
  7. general tool inconsistencies
  8. toolchain
  9. build information / tunables / environment
  10. making sure that the source tree has no local changes

With a bit of info on each.