Earlier quoted context omitted.
It used to be a week!
I remember when it was two weeks
We now push to the store twice a week. I kind of liked the older pace of once-twice per month to be honest.
Prisoners of Google Android development
31–40 of 318 posts
Re: Prisoners of Google Android development
#32Based 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 ol…
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.
Re: Prisoners of Google Android development
#33It was always obvious that Play Stores and their captive developer "communities" were a trap. Forced API upgrades are just one aspect of that.
There are certainly tasks that are best done by a phone or mobile app; usually, these are things that involve moving around, such as navigation, or depend on phone sensors, such as working out which way is "up". But nearly everything else can be done by a website.
I'd hate to be a one-man developer trying to maintain a cross-platform mobile app. I sympathise. But strictly from the sidelines; I long ago decided that I wasn't interested in playing games with proprietary platforms and gatekeepers.
Re: Prisoners of Google Android development
#34While I concur with the author on the challenges of Android development, the author made two major mistakes.
One, he didn't test his app on the latest version of Android. This a very major mistake and the reason why we keep 11 virtual machines around with all the versions of Android that our app is supported on. Two, when you release an app on Google Play, you never, never, never deploy the app to 100% of your user base, at least not initially. Staged rollouts are the norm and we never initially deploy an app to more than 10% of the user base after a release is published. Additionally, when we finally feel confident with a release, we deploy the app to 99% of our user base and not 100%. The reason for this is, if we need to halt a roll out for whatever reason, we are easily able to do so, so long as the release is not deployed to 100%.
For better or worse, both of these tactics are well-known by more experienced Android developers.
Re: Prisoners of Google Android development
#35I’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.
Agreed about conflicting message. And even better - e-mail was pretty vague and had to Google a separate link (https://support.google.com/googleplay/android-developer/answ...) for more info. If I could go back in time then I would press that button, which asks for time until November, because as happened to us - it was not possible to go back to previous version in any way.
Re: Prisoners of Google Android development
#36I’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.
Agreed about conflicting message. And even better - e-mail was pretty vague and had to Google a separate link ( https://support.google.com/googleplay/android-developer/answ... ) for more info. If I could go back in time then I would press that button, which asks for time until November, because as happened to us - it was not possible to go back to previous version in any way.
Yeah you just saved me; was working late last night to get all updated. But still some issues; and was worried about testing. So thank you. Sorry you didn't see it on timme
Re: Prisoners of Google Android development
#37While I concur with the author on the challenges of Android development, the author made two major mistakes. One, he didn't test his app on the latest version of Android. This a very major mistake and the reason why we keep 11 virtual machines around with all the versions of Android that our app is supported on. Two, when you release an app on Google Play, you never, never, never deploy the app to 100% of your user b…
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 going to happen mistakes and the real problem is that there is no way to pull-back/cancel/rollback release.
How would staged roll-out help in this situation for all customers? When end-user gets the faulty version of the app, does he/she have a way of getting the non-faulty version somehow?
Re: Prisoners of Google Android development
#38We need appstore-less, fully device-private system. I'd be really happy to pay premium for that.
well, there's always the librem and pinephone, although they're not at the point of maturity just yet
Re: Prisoners of Google Android development
#39Based 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 ol…
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 similar…
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.
Re: Prisoners of Google Android development
#40I’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.
Agreed about conflicting message. And even better - e-mail was pretty vague and had to Google a separate link ( https://support.google.com/googleplay/android-developer/answ... ) for more info. If I could go back in time then I would press that button, which asks for time until November, because as happened to us - it was not possible to go back to previous version in any way.
Now that I've check all accounts of several clients.
It's very mixed. Some haven't received a warning.
Some have a warning that no updates can be published.
Some have 2 warnings; one that no updates can be published & one that it won't be available to new users.