Live data from Hacker News

Prisoners of Google Android development

solutional.ee

61–70 of 318 posts

Re: Prisoners of Google Android development

#61
In theory this kind of "controlled" backwards compatibility break is good, it lets old apps work whilst encouraging developers to keep up with platform changes. In practice it has the nasty side effect of preventing the scaling of the software industry, and with it, industrial society. Therefore Google should drop this policy and allow old programs to be distributed forever.

With near perfect backwards compatibility, the amount of software that society can consume is in effect unlimited. The number of software developers is finite, but the amount of software they can create isn't: only the growth rate is finite. Thus society can benefit from an ever-expanding library of programs which increases overall wealth. Indeed, tool creation is the only way to increase wealth in countries with a flat or falling population (productivity * population = gdp, more or less). In this mode, software is like knowledge. It accumulates and compounds.

With imperfect backwards compatibility you are forced to engage in continuous maintenance of all existing software. Suddenly there is now a fixed limit on how much software society can have, it's a function of how many maintenance developers there are. You can literally reach a limit where things can slide backwards. Problems can become un-automated. In this mode, software is more like oil. It can run out.

Google want to force continuous maintenance because the Android team justify their existence with constant change, and if a platform is full of unmaintained apps then it will feel old and tired compared to a platform full of apps that have the freshest new looks and features. But that often doesn't matter, especially for non-consumer or specialized software used only by a small number of people (but for high leverage impact). Because Google and Apple are unapologetically consumer focused cultures, they care far more about things like how apps look and stuff that's irrelevant in business contexts (consumer privacy).

Re: Prisoners of Google Android development

#62

I’m still working on the updates. Was quite a lot of libraries to update for us. And only got the warnings last weekend. Anyone knows the impact of not updating on time? Google’s message seems conflicting.

I shudder to think what happens in another 5 years or so when the min target is bumped. We have an app built with about 6-8 Jetpack Compose libraries that is already flaky (even after using BOM) and only a magic combination of library versions ensures the app runs across SDK versions.

If you think developer libraries provided by Google for Android are stable, battle-tested and you feel this is akin to first-party "platform code", please be advised that it can be a hellscape with you fighting Google's build tools and the IDE/dev env on one side and zero help on SO to debug device-specific issues with lengthy stacktraces on the other. You end up landing on an Android issue-tracker where some kind soul mentioned the device name, only to find that issue in limbo asking for a working reproduction.

Re: Prisoners of Google Android development

#63
> I took the approach of better safe than sorry and prioritized this task even though it would add no business value — it was only required to be completed because Google said so.

Lol, maintaining the app provides "no business value." More like "If it doesn't come from above, it doesn't exist."

Re: Prisoners of Google Android development

#64
post #46
post #43

Earlier quoted context omitted.

Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy. This is well-known to anyone who has been doing Android development for a while.

Totally understand that a roll-back is more complex, but it doesn't explain why pulling back/pausing/deleting/yanking a release is not possible either - customers who got the newest faulty release can uninstall & install to get the previous version back (no need to worry about incompatibilities here) and the ones who did not get the updated version yet can stay using the old one until a new fixed version will be rele…

This is exactly what staged rollouts are for. The author ignored that best practice. You can halt any release as long as it is in progress. Once you mark it complete (defined as rolled out to 100%), you can’t roll it back.

Each track in Google Play (alpha, beta, canary, prod) can hold up to one release at a time. It would get really confusing if it allowed more than one. And with the other rollout safeguards provided decelopers, it’s quite possible and very easy to do exactly what you’re asking for.

Re: Prisoners of Google Android development

#66
I'm sorry, but this is on the developer / maintainer.

Google has been putting out these warning messages for a while, and any decent Android developer should know about target SDK versions.

Didn't test the app on the platform they were updating to?

Didn't function test the app on a physical device that surely had on hand?

Somehow this is Google's fault?

I dislike the stronghold Apple and Google have as much as anyone else, but this is just shoddy maintenance and you've effectively advertised that your "agile software company" can't update an app without proper process, lack the ability to keep on top of well-defined changes within Android app development, and to top it off have the gall to claim Google is being unprofessional?

Re: Prisoners of Google Android development

#67
post #43
post #37

Earlier quoted context omitted.

I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still go…

Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy. This is well-known to anyone who has been doing Android development for a while.

"may" is the reason why not supporting rollbacks at the OS level is baddesign

Re: Prisoners of Google Android development

#68
post #51

I also got this email, but professionally and personally. Personally, I voluntarily built and run open source apps for 16 different cities for their transit system. This gave me two weeks to update 16 apps, for no benefit of anyone. My app is a PWA, and the Android version just uses cordova + a few plugins to add a few native options. Unfortunately, updating cordova to support the new target android api broke some of…

> I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this

I think you misunderstood users, it's not just ignorance. I want apps to go back in the direction of real(not cordova) apps, not some low effort web thing. Basically zero web apps match the experience of a well crafted actual app.

Re: Prisoners of Google Android development

#69
I mean, this is pretty much the paradigm for everything now. Angular versions go out of LTS in about 18 months, Android apps need an update in about the same timeframe, etc. Makes COBOL look like a dream - build a functional app that just works for 20 years.

Re: Prisoners of Google Android development

#70
post #51

I also got this email, but professionally and personally. Personally, I voluntarily built and run open source apps for 16 different cities for their transit system. This gave me two weeks to update 16 apps, for no benefit of anyone. My app is a PWA, and the Android version just uses cordova + a few plugins to add a few native options. Unfortunately, updating cordova to support the new target android api broke some of…

I have compassion with you, some of my private apps were also affected. But we were being told this deadline for many months now. It was clear that at some point they would show it more in your face. I also disliked the way it was formulated, also, even if everything was fine in production, it complained when testing versions didn't comply (doesn't make sense). Also, it was always only about pushing new updates (it's…

My understanding from earlier notifications was that updates would not be accepted unless you targeted a new api version. That is fine, since I haven't updated the Google Play "app" since I first released it. This is because the real app is a PWA that I update through the web, and the Play Store app is just a shell around that.

The first time I was aware that the app would be delisted in the Play Store for new devices was in the August 18th email.

Post reply on HN