by ashishb on 6/8/25, 5:52 AM with 79 comments
by jbk on 6/8/25, 7:18 AM
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)
by dlcarrier on 6/8/25, 6:57 AM
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.
by lutusp on 6/8/25, 7:53 AM
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.
by askvictor on 6/8/25, 7:35 AM
by jaoane on 6/8/25, 6:49 AM
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.
by chrismorgan on 6/8/25, 9:57 AM
The actual article title omits “in Google Play Store”, and it would be good for that change to be made here too.
by muzani on 6/8/25, 8:14 AM
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.
by dedicate on 6/8/25, 8:44 AM
by fuomag9 on 6/8/25, 8:38 AM
by seanalltogether on 6/8/25, 8:27 AM
by charcircuit on 6/8/25, 6:46 PM
The check in the OS just checks if your app currently has a resumed activity. It doesn't require a ton of code. All activities receive a callback when they become resumed, onResume, and a callback when they are paused onPause. Yes you can use ActivityLifecycleCallbacks to have callbacks for all activities of your app in one place to track the state for each activity one place if you are not firing the toast from a specific Activity.
The onStart callback is not relevant here. And the article that was linked improperly assumes that an app only has one Activity going through lifecycle events at once which is not true. The article is trying to solve a different problem, a problem that probably shouldn't need to be solved. It's trying to avoid callbacks when an app gets recreated when the device rotates, but nowhere else in the OS avoids such a thing. During rotations the OS freezes the display to hide the fact that your app is closing and reopening. It's going to be hacky to trying and pretend to stay open during such an event.
by tslocum on 6/8/25, 3:04 PM
by postsantum on 6/8/25, 7:37 AM
And then that absolutely retarted 12-testers rule
by like_any_other on 6/8/25, 4:26 PM
by tomjuggler on 6/8/25, 9:43 AM
Just make a web app, works everywhere
by alongsampe on 6/18/25, 6:00 PM
by eviks on 6/8/25, 7:35 AM
> 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.
by alongsampe on 6/18/25, 6:00 PM
by Jyaif on 6/8/25, 9:21 AM