Hacker News Reader

Comment by jeroenhd | Hacker News Reader

Based on the crash behaviour, it sounds like Google never bothered trying to log in to the application if it passed review.

This also makes me wonder, was the app already crashing on Android 13 before updating the target SDK version? I suppose the backwards compatibility layers must've kept the app alive on modern phones?

Personally, as a user, I like that Google forces developers to update their apps, because the old API designs were terrible for privacy, but they won't be enforced unless devs update their targetSdk. Breaking installed apps is not an option, but forcing the issue in Google Play works well. I'd also say their testing times were reasonable, if it weren't for the fact that they don't see obvious problems such as "app was never even tested on Android 13".

View on HN

As a user, I’d rather that Google make stable and coherent APIs the priority.

If the strategy is: 1. Make breaking API changes, but gate them behind the targetSdkVersion. 2. Force app devs to lift the targetSdkVersion to stay up to date by gating device access in the store.

It has a few effects: - Developers can be slow to move. There will be zero million new addressable endpoints initially, and customers may similarly build an expectation of new devices being problematic/best-avoided. - QA burden increases for split behavior *forever*. - The play store becomes an integral element of the privacy and security picture of the device, something that should be the OS’s job.

What would I rather? I’d rather an API evolution plan that doesn’t rely on targetSdkVersion as a means of controlling behavior of APIs. It’s an attempt to have one’s cake and eat it, too, and it clearly falls apart, anyway.

I’m wary of any plan that basically amounts to needing people from other companies to do something in order to succeed.

The stable and coherent APIs Google wanted to make all the way back in Android 4.4 was met with strong resistance by power users and data collection companies.

Many API changes are either extremely minor ("set this flag if you want to keep the worse, legacy handling behaviour") or extremely important ("actually ask the user before you drain their battery tracking their location in the background"). The new handling of notifications (requiring explicit permission) is also a godsend.

Google hosts and distributes apps effectively for free (let's be honest, how many Android users actually even pay for apps). The least you can do to keep the app running is to make it work with the modern API once every three years, with an announcement about the API bump requirement a year in advance.

Before Google did this, the Play Store was filled with crap from the Android 2 era that crashed on startup. Paying the one-time $25 developer fee and chucking an APK over the wall isn't exactly a good way to create a decent app store.

You don't have to comply with Google's desires if you don't want to, but you'll have to host the APKs some place else. Termux has had to do this, unfortunately.

Apps that don't get updated can't be easily installed on new devices. They'll still work and be easily installable on old devices (matching the targetSdk version) in case you rely on an Android 9 tablet embedded into your POS.

I think it's entirely fair to expect a yearly "is everything still okay" check from application developers.

> Google hosts and distributes apps effectively for free

Google rakes in money from all the in app sales, store sales, and subscriptions. Further, google is often the provider of in app ads. Not to mention all the money they get from advertising with google searches and adwords built into (practically) every android device.

And, let's be frank here, a 1, 20, 100mb APK isn't exactly a huge amount of data to host. Especially since there's almost always a linear correlation with the popularity of an app and the amount of revenue google makes from that app.

They aren't exactly operating a charity here. The least they could do with all this money flowing in is support backwards compatibility on their platform.

> And, let's be frank here, a 1, 20, 100mb APK isn't exactly a huge amount of data to host.

It definitely can be with scale. Distributing a 33MB app: Google says they've served 70TB, and this would be 170TB without their optimizations

If you were paying google hosting fees, that'd be $700. I'm guessing the cost to them is far lower than that, though. ($0.01 per GiB)

That also equates to over 5 million downloads.

I'm guessing this app is likely pulling in a lot more than $700 for google.

https://cloud.google.com/vpc/network-pricing

FOSS app. No IAPs/subscriptions. Google's taking the hit on this one

10MM+ downloads on the Play Store (Unsure if Google gives us actual figures on the dashboard)

The cost of having a thorough inventory of apps that being in monetization is vending apps that have none. It's part and parcel of keeping users inside the walled garden.

Google takes a hit on some apps to sell and advertise with others. What's hurting Google in this case is the release of an app update that is bad for customers and bad for the business. While it's just one papercut, the "huh, my iPhone version works just fine" razzing will ring just a bit more true for customers who got bit by the update. Do it enough, and they'll get tired of the hassle and jump.

It's a rough balance, building something scalable that also holds high quality, and separate policy decisions can sometimes lead to truly Kafkaesque journeys for developers and users. It's at least instructive for others. Making and evolving APIs and ecosystems is hard. Think very carefully about the holistic impacts of decisions.

Google’s review process is weird; I’ve had application crash fully. And see in the logs it also happened to the Google review phones. Yet they still approved it.

It was working with Android 12+ before without problems. Upgrading API target level made some flags mandatory (for PendingIntent to be specific), which throw RuntimeException. But as I also wrote in the article itself then this is a legacy application, which does not seen any active development for more than a year and tasks like these need to prioritized instead of other active developments and since app was working after testing then it didn't seem to be that a big of a deal. However, should have been tested on newer Androids too. But even when the problem happened in production then I was not that worried since Google reviews usually take few hours max. The problem is that it has been taken so long for now and there's no way to cancel/pause/delete latest faulty release. That's the scariest part.

Reply on news.ycombinator.com