A developer might not care whether or not a fun project earns them anything, but Apple and Google want their cut, so if they make distributing software through their store expensive and time consuming, the free stuff will fall by the wayside, so the only options for a simple tool are either ad-laden or have recurring expenses.
Also, I used to think that getting an FPGA IDE up and running was the most painful, unreliable, and bloated development environment possible, then I met Android Studio.
AFAIK, Apple also charges $99 per year to maintain a developer account on the Apple App Store, effectively shutting out any hobbyists who would like to provide their app with no monetization.
> the only options for a simple tool are either ad-laden or have recurring expenses.
Unfortunately, that indeed seems to be happening.
You can put free, user-friendly software into the Play store. The Play store shows whether software contains ads or in-app purchases. But the Play store doesn't let you search by those criteria, and IIRC developers used to be prohibited from clearly advertising the main distinguishing quality of their software in the title (couldn't find the rule in the policies anymore so this may have changed).
Likewise, users can't search or filter for app size, which not only affects how much space the app eats on your phone but is also a great proxy for how much crap is bundled inside it.
So in effect, the good apps will be impossible to find amid the sea of SEO-optimized and/or paid placements of ads that can afford to do that because they are full of ads.
It's not letting me do that either. Google Play Games (the separate app) has such a filter but it's seemingly random.
F-droid has nowhere near the reach of the Play Store. You can't tell your non-geeky friends to install F-droid to install apps from F-droid.
Native NDK is another can of worms, with updates linked to SDK or sometimes not, unclear documentation about device and API compatibilities, compiler behavior changes and other requirements (like the 16K one) that impact so many 3rd party native libraries.
But, of course, the rules on the uploading and the changes of the Console, that changes so often is what makes it painful.
The absolute nightmare is about giving Google the root signing key of your application, the unfinished business about app bundles (which should reduce the size of the downloaded app, and more often than not, make it bigger), the changes in compliance, letters to sign for different countries, the compatibility for Google form factors (XR, TV, Auto, Automotive), Inline installs and other Teacher Progams, Play for family and so on.
All of this changes non-stop and is very poorly documented :)
At least, the Play Store is still GPLv2 compatible, so for now, we're saved (VLC)
Thanks for sharing this. I agree with your sentiment as one of my Android apps use vox SDK. However, my experience is very limited compared to you to write about it.
> The absolute nightmare is about giving Google the root signing key of your application,
I haven't and I don't think it is required.
> the unfinished business about app bundles
Can you elaborate what's unfinished here?
> the compatibility for Google form factors (XR, TV, Auto, Automotive),
My app is disabled for Android Auto in production. If I re-enable, then it gets rejected during the review. I have never been able to precise fix the issue they are raising to let me re-enable Android Auto.
For Chromecast (TV), I have to run a web server inside the app to serve the media.
I wish more people talked about this. At Amazon, I helped with the early threat modeling around adoption of "App Signing by Google Play", which requires sending your app's root signing key to Google (and is now required, with no publicly-available opt-out for new apps.) It would have added some nice things for Android devs: app bundles, smaller downloads, instant apps, etc.
That said, we imagined the following scenario, and were unable to find a reasonable mitigation at the time:
It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal (ex: to exfiltrate keys). This would be nearly impossible to detect, especially if the modified APK were distributed to only an individual user, or a small group. A few people raised concerns [1], but I don't recall Google ever giving a reasonable response.
[1] https://commonsware.com/blog/2020/09/23/uncomfortable-questi...
Edit: clarify no opt out for _new_ apps
I didn't trust stock Android before, and I felt the sinking-gut feeling as soon as I realized where "upload root signing key" was going, but spelling it out here puts a ... fine point on things.
Thanks for the comment.
> It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal
Since when do you have to hand over your signing keys to Google? I seem to remember the Signal devs saying that they preferred publishing their app on Google Play as opposed to F-Droid because in the former case they control the signing keys. Has this changed?
Apps first published to the Play store before August 2021 are not required to upload their keys. [1] This likely includes Signal.
However, my understanding is that if you want to publish a new app (Signal-like, or not), in all cases you must upload your signing key.
My knowledge cut-off (haha) on App Signing by Google Play is ~August 2021.
[1] https://developer.android.com/guide/app-bundle
* Note that App Bundles mentioned in [1] requires App Signing by Google
Would be nice to get a confirmation of this as it sounds wild.
However a good way to minimise headaches with NDK is to stay by the Google rules, it is a complement to Java/Kotlin, with a specific set of APIs, and not a way to pretend Android is GNU/Linux.
> Material 2 was deprecated for Material 3. No clear migration guide was provided. I tried to upgrade
Why would you do that? This is a self-inflicted wound that exactly matches the title. This isn't like another example of some important system library you need that gets removed, forcing changes
> Crucial third-party libraries have been deprecated
Since you've used them at this state for the whole of app's existence, you can continue to do so without any extra maintenance?
I mean, if you view any non-breaking changes as breaking, especially when it comes to UI, the amount of maintenance is infinite anywhere.
Well, not, for example, "OkHttp 4.12.0 does not support Happy Eyeballs which is a major issue with IPv6 networks".
As I mentioned elsewhere in the article, each library supports a certain version of Android; your old library will not support newer versions. E.g. API 33 onwards there is an edge-to-edge display, and older UI libraries won't be able to handle it.
And then that absolutely retarted 12-testers rule
My original intent was to put my free, open-source apps on the platform, much as I had done before Android existed. But no -- Android doesn't work that way.
My best-known Android app is SSHelper (https://arachnoid.com/android/SSHelper/), a Secure Shell server meant for file transfers. Still works perfectly, dropped some time ago.
TankCalc (https://arachnoid.com/android/TankCalcAndroid/), same story. It's a well-known multi-platform app tank farm managers use to profile storage tanks. Still works, dropped from the platform.
And not just mine. Many other free, first-rate Android apps -- Termux (https://termux.dev/) comes to mind -- have been driven off the platform by Google's onerous demands and commercial focus.
It's as though a wall is going up between people who like programming and people who like money.
Do web? You're just pushing the problem of accessing lower levels (esp. files and camera) to the browser. Browsers are not consistent. Some devices don't even update their browsers and it would break POST on a very specific version of Android.
There's a high end Samsung gallery that has a very inefficient way of displaying thumbnails. This is the default gallery. If the user has over 10000 photos or so, it freezes. People who buy this phone will often have a lot of photos. And they're rich; usually the investor. This bug doesn't show up in typical tests because QA can't afford this phone. So the fix is to avoid built in galleries, and write a custom gallery for the app that utilizes binary search or something. Major apps like FB and WhatsApp will have implemented their own in built gallery software so these device owners end up blaming the apps that don't.
I've maintainted a Flutter app and it's 10% of the maintenance of a normal Android or iOS app. The only real breaking change they had in 6 years was the switch to strict typing.
Yeah, thankfully, the alphabet one is mostly used in marketing. The other two show up in documentation interchangeably.
jaoane•2h ago
Good. Really tired of installing an app, forgetting about it, and then getting a bs notification a couple of days later to get me to open it again.
ashishb•2h ago
I don't think that app can send a notification to you anyway. An app that's never opened by the user cannot be launched programmatically and cannot run background code.
sumanthvepa•2h ago
Gortal278•2h ago
anothernewdude•2h ago
ashishb•2h ago
chrismorgan•57s ago
muzani•1h ago
I'm still in full support of these. I keep telling people that social media apps are just massive violations of privacy and can just copy your password from clipboard or trace your location through images – I've been asked to code these at one time. At least these updates keep me from thinking I'm the paranoid one.