You might want to contact the Google developer in charge of the Android Java as he was originally an outsider, i.e. he authored the legacy approach to handle legacy APIs and shamed Google to do a better job of handling legacy APIs with new android SDK features.
Prisoners of Google Android development
11–20 of 318 posts
Re: Prisoners of Google Android development
#12I've started frequently getting reviewed (from submission to approval) within hours, sometimes even within 10-15 minutes of submitting to Apple App Store. But it still varies and can take a day. I want to figure out a good cross plat strategy but would not want to ever deal with Play and Google.
It used to be a week!
Re: Prisoners of Google Android development
#13Based 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 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.
Re: Prisoners of Google Android development
#14I had the same thing happening to a bunch of apps based upon a framework I built. The newer API version had problems with existing dependencies, really a shit ton of work to get back to exactly the same place I was already.
I really respect Microsoft a lot more, where stuff from the 90's has less issues running on the latest Windows version that mobile apps I wrote four years ago on Android.
Re: Prisoners of Google Android development
#15TLDR; Written an article about a real-life case-study about Android app deployment/development problem where production version has a critical problem and update has been "in review" for 72h+ and there's nothing else we can do. If there's some (ex)-Googlers who could help to speed up update approval process then I would be really helpful, if not then let it just be as a warning for anyone else being involved with mob…
Behavior change hidden behind targetSdkVersion is a bear trap that keeps on providing trauma. It’s just a massively dangerous way to evolve API’s.
That said, automated regression testing, target environment deployment tests, and beta application groups are your friends. Yes, they cost money/time, but escapes are the Jack in the box cost of not having them.
Re: Prisoners of Google Android development
#16> It's time to move back to open (web) standards and take control back into our own hands! Wait till you discover that the web is also half controlled by the company that is causing your problem now (Google). And Apple who owns Safari, the only browser on iOS in the real sense, isn't really your friend either.
Yeah, that's also true, but at least this kind of problems can be handled by a roll-back or whatnot. Situation we're currently are in does not allow to do anything while we know that bad build is in production and phones are updating to it automatically. That's the worst situation to be in.
Re: Prisoners of Google Android development
#17It's a similar situation with Chrome extensions. Extension reviews are generally pretty quick (an hour or so), but every once in a while you get hit with a longer one (days+). In this type of environment, you need to ensure every release is as rock-solid as possible. For our extension, we have beta extension with a sub-group of opted-in users that we test on for a week or so before doing a production release. Then we…
Good point, but as I also wrote in the article then one and only reason for doing anything was an API level deprecation e-mail from Google less than 3 weeks from its deadline and it states that review could take a week (never happened before with me though). If I would have noticed the "extend to November" immediately then it would have left more time. But yeah, I'm not saying that this situation could not have handled better, I'm saying that as soon as you make a mistake then there's nothing you can do. And mistakes will happen, even when testing thoroughly with every Android version.
Re: Prisoners of Google Android development
#18Interestingly, Google apps (1P) are subject to the same review process, and can also get hung up. I experienced 72 hour waits to roll out an APK update.
Not really consolation, but interesting to note.
Re: Prisoners of Google Android development
#19Why not using an alternative to Google play store, at least as a fallback in case of emergency...
Re: Prisoners of Google Android development
#20Based 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…
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.