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.
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.
I'm surprised that several audits didn't uncover this signing issue. GrapheneOS devs do not recommend f-droid. Instead, Play Store is the safest option for now, after Aurora Store
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".
Also handy (regardless of framework, language, etc) is if you use feature flags, if you're using actual valid credentials against a service or a local testing service (eg S3 vs minio, etc).
Enabling this for non-technical users really helped also report any issues they would see, it was great for testing environments.
Plus you would probably end up needing all this information anyway if you do any error tracking, so it probably exists somewhere already :-).
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.
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.
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.
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.
But Compiz Fusion wasn’t all about impractical visual effects: wobbly windows was seriously useful, and rather popular, perhaps the one thing that people would leave enabled after playing with all the fun ridiculous stuff for a bit.
When you have things that move or resize windows instantaneously, e.g. snapping to one side of the screen, the wobble in the windows was a transition, one that helped you keep track of elements rather than everything just… changing.
Seriously, so useful for floating window managers, it’s a simple and obvious form of transition, significantly better than what window managers have ended up at these days (if anything).
(Then I switched to i3, and more recently Sway. Not sure I’d appreciate wobbly windows in tiling window managers, though maybe with gaps (… which I’ve never understood the appeal of) it might be better.)
When you say "gaps", do you mean space between windows? I do that. Seeing a bit of the wallpaper is like seeing a bit of your desk between papers. Helps with mental context switching. Window borders probably serve the same function, but they've never worked as well for me.
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.
It's tough. In my experience in the games industry, a big reason source wasn't released historically was not antagonism towards the players or belief in the underlying IP. It was fear: someone in "China" would start running your game for "their" audience, and make a bundle there while you rot, totally unknown to you.
I'm not sure how often that actually happened. The only games with parallel universe East Asian audiences belonged to #1 genres like MOBAs. While there was a belief that you could be making the next MOBA, hardly anyone was making realtime multiplayer games at all, so it was extremely unlikely.
It was a misplaced reaction to Ketchapp, the real antagonist. They would rapidly clone and blitz-market games. Indie mobile developers spent a year or more discovering and refining an original, fun mechanic, only to see this well capitalized actor seize their audience by giving the mechanic away for free. From 2014 to 2018, in my opinion, indie mobile developers transitioned to more atmospheric fare, and iOS and Android nowadays are a marketing-and-sizing tool for your inevitable Nintendo Switch audience.
Which brings us back to: what is there exactly to protect? Ketchapp didn't need the source code to clone those games. Nobody needs the source. If you make a PC game and have an audience, it will show up in Steam charts, you can't really keep that secret. And if you don't have an audience, you have seriously nothing to worry about. Since every game usually starts at zero, why protect the source?
My card game Spellsource has been open source for a long time (https://github.com/hiddenswitch/Spellsource) and my colleague and I are in the process of rebooting it. This game is community authored, players write the cards, so it makes mechanical sense to be open source. On the flip side, for the narrative & atmospheric single player experiences indie developers are authoring, it is hard to define what they have to gain.
You could also make public servers do peer-to-peer discovery! Then if your server ever goes down, it would be enough for a single host to post the address of their server in the issues
I've had the idea for a while now to use torrent trackers as a server masterlist. Torrent trackers are already basically a way for computers to insert their IP into a list, so if you make up some fake torrent "announce hash" (I think that's the right name), then hardcode a few of the most popular open trackers, you can use the "peer list" from the tracker as a list of servers. Just haven't had a use case for it (yet).
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.
Thank you for everything that you've done! The Android ecosystem is uniquely hostile, and it's hard for an outsider to understand the public and private battles that you've inevitably faced over the years.
Hey @pserwylo, great to hear from you, and I especially appreciate your message here with the background. And I'd like to highlight your point that there is much less contributor time than people imagine. If anything, the F-Droid client UX design process back in 2016 has proven to be an immensely efficient exercise it putting together a UX that still works decently. Plus we managed to predict that bottom nav would rise in popularity and those sliding sidebars, which were recommended back in 2016, would fade.
You're of course welcome to contribute again! The hard part is that app stores are large and complicated apps, when done fully, so that makes it hard to contribute to. We do mark issues with "first-timer" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... and "help-wanted" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... if anyone is looking for a place to jump in. I think we can also see this in all the various other clients like G-Droid, M-Droid, Foxy, Droid-ify, NeoStore, etc. Many rapidly stop being maintained, and others leave out key functionality like localization and automatic mirror selection because it is a lot of work to implement. The new libraries should make it a lot easier for forks to implement these features.
What is (or was) the benefit of using ContentProviders compared to accessing the database directly? They seem useful for exchanging data between apps, but I can't figure out what their role is when they're internal to the app (not exported).
Is it just that they're required for using CursorLoader, so that you can easily load things in the background without having to create a custom Loader implementation? And they're basically just a fairly inconvenient database abstraction?
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.
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.