56 ms·

Prisoners of Google Android development

• lawgimenez 3y ago
  Not updating your app or submitting it to the app stores for an average of 1-2 years is a disaster. Always update as soon as possible.
• jarm0 3y ago
  TLDR; 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 mobile app development.
  • chaboud 3y ago
    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.
• roge7331 3y ago
  Whatever you do do not touch anything related to the app in the Google play console. Any change will reset the review
  • carstenhag 3y ago
    Not true, nowadays you have to send changes to review manually. It's not automatic anymore.
  • jarm0 3y ago
    Thanks for the tip!
• mrtksn 3y ago
  Interesting, Apple allows for expedited reviews in case of a critical bug or something time sensitive. IIRC you can demand that twice a year. I assumed Google would have the same.
• wahnfrieden 3y ago
  I'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.
  • mavamaarten 3y ago
    Our average in the Play Store is about an hour. Our average on the Apple side is a bit longer, but we've been blocked by them on multiple occasions for over a week while we turned out to be in the right.
  • dep_b 3y ago
    It used to be a week!
    • wahnfrieden 3y ago
      I remember when it was two weeks
      • dep_b 3y ago
        We now push to the store twice a week. I kind of liked the older pace of once-twice per month to be honest.
        • carstenhag 3y ago
          Just because one can, doesn't mean that one should. We still do releases every month or so and we fight back when more frequent releases are wanted.
• jeroenhd 3y ago
  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".
  • chaboud 3y ago
    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.
    • jeroenhd 3y ago
      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.
• o1y32 3y ago
  > 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.
  • jarm0 3y ago
    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.
    • giantg2 3y ago
      Sure, you own the servers so you can rollback. You don't own a user's device. If you want to rollback after a full rollout, all you do is build your new/rollback release from your previously working commit and update your version number.
      • l72 3y ago
        Right, but in this case, changing the target API is what broke the app. Since Google won't allow you to release an update with an old target API, you can't just revert the change and increase the build number.
        • giantg2 3y ago
          Yeah, I was talking about general rollback for Android. In this specific case, they chose to rush and they didn't test (boo-hoo). It's like me complaining that the tools shouldn't have let my bug go to PRD even though I didn't test (and apparently didn't know much about Android as evidenced by not having a physical Android device). Same thing if your site cert expires, or browsers start blocking specific functionality/code/tags. Seems like they just want to complain about the thing they aren't familiar with.
• drpixie 3y ago
  > I personally have been against developing mobile apps for years now for the exact same reasons described in here and other similar articles — as soon as you decide to develop mobile apps then you give control of your product/service away to a third party Hard to disagree with that. When "support" is hoping that HN or Twitter attracts helpful attention, we're going down the wrong path.
• scottfr 3y ago
  It'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 roll out the extension to production incrementally starting with 1% of users and slowly ramping that up to 100% (it seems Android has a similar staged rollout feature).
  • jarm0 3y ago
    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.
• dep_b 3y ago
  I 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.
  • kramerger 3y ago
    Unless the framework you used came from Google that is an unfair statement. You don't blame Microsoft for Adobe Flash not working on Windows 11 store, do you?
    • dep_b 3y ago
      If Google breaks the framework I built, I still blame Google.
      • kramerger 3y ago
        Why? Should Android be bloated with compatibility layers for every buggy framework ever existed? Including third part stuff such as Cordova and Ionic that have more or less stopped development? And it's not like Google is randomly breaking things. And even when there are breaking changes they provide support libraries and explain very clearly what has changed and why it needed to be changed. Still, no sympathy for app shops that work according to fire and forget.
        • dep_b 3y ago
          "Compatibility layers": it was a setting that is still a valid setting but you need special permissions for it nowadays. The code was compiling perfectly.
        • jonmb 3y ago
          > Including third part stuff such as Cordova and Ionic that have more or less stopped development? FYI - Ionic is in active development, along with Capacitor, their replacement of Cordova. I recently updated my app’s target to the new Google guidelines and Capacitor made it easy with an automated cli.
• fredgrott 3y ago
  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.
• xoogler20230827 3y ago
  Interestingly, 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.
• pagra 3y ago
  Why not using an alternative to Google play store, at least as a fallback in case of emergency...
  • jarm0 3y ago
    But how does that help end-users? They would still need to know that they need to use different store etc. It's a pain. At least Android allows (relatively) easy side-loading APK's for the most critical situations, but for iOS that would be a disaster (not sure if Apple's App Store has a way to delete/cancel/pull-back faulty release though).
  • mavamaarten 3y ago
    Honestly this is really not a solution for anyone making a living off apps, or working on apps in a professional setting. You simply reach much fewer people and certainly a different audience too.
• sylware 3y ago
  digital jail evolved: from msft/apple digital jail model to open source (SDK included) google/meta/etc digital jail. The new digital jail model is based on open source grotesquely and absurdely massive and complex software (and more and more private protocols), SDK included (c++/java syntax). Defense: simple and modular software(SDK included, write simple and plain C, not c++)/protocols, but able to do a good enough job, stable in time. Benchmark: not 47398437829 modules, and each modules could be coded by one normal developer in a reasonable amound of time. Ideas: to move from one module to another, proper URIs: irc[s]://|ircs:,mailto://,http[s]://,etc. We miss a really simple video/audio conf protocol, I mean REALLY simple (TCP based). Crypto-based authentication and end-to-end crypto will add a lot to do from those client programs to make it easy to use. We can imagine a One Desktop Application handling most/all of them, optionally deferring some protocol handling to external apps (Basically, what is doing current web engines the wrong way).
• TedDoesntTalk 3y ago
  Same experience here - forced to update a stable Android app due to minimum API requirements. Uploaded to the store - app does not crash but does not work as it does in the emulator. Customers pissed.
• pmontra 3y ago
  > I'm not even sure why are we, as developers, allowing this to happen — there's usually not any good reason to develop mobile applications at all anymore. It's time to move back to open (web) standards and take control back into our own hands! In general yes, but if I look at the apps on my phone I have A mail client, K9, old UI. This clearly can't be replaced by a web app because I'm using it to look at my mail in a few POP3 servers and then I'll download those messages on my laptop (Thunderbird) OSMAnd, offline maps and trop recording. Can't be web based. Password manager, with a local dB synced with Syncthing. Syncthing. Epub reader, from files stored on my phone. Photo gallery, for files on my phone. I backup to my laptop with Syncthing. Banking apps, that I must use for 2FA in the web sites of those banks. A network scanner, useful to debug networking issues. Etc. Of all the apps that are currently installed on my phone the ones that could be web apps are: Go4Go, to view game records of pro games. Elementary. Chwazi.
  • jarm0 3y ago
    Agree that not everything can be web-based and your list of apps seem to be non-typical if there exists a list of typical apps of course.
    • omniglottal 3y ago
      This list of apps is very typical for the class of user who chooses F-droid as a repo source.
  • moron4hire 3y ago
    > OSMAnd, offline maps and trop recording. Can't be web based. There's no reason this couldn't be browser based.
    • Filligree 3y ago
      Offline maps. Browsers tend to delete PWA data without asking the user first, which can be as threat to life and limb in this case.
• gumby 3y ago
  This is a no-win situation. MS expends an inordinate amount of effort on back compatibility, and much kudos to them. But it vastly increases their attack surface. Likewise many of the worst things about the unfairly maligned C++ come from a hardcore position on back compatibility: as much as possible, old code, and even old C code, should continue to compile and work as expected, even to the point of linking old binaries to which you’ve lost the source code. Most people don’t go to that effort and just invalidate old stuff in the name of maintenance, reliability, and security. Whichever branch cut you take you’re going to cause a problem for somebody. If not, nobody is using your code.
  • jarm0 3y ago
    Yes, that's definitely one side of the problem and I'm not chasing too much backwards-compatibility. My biggest concern in this particular situation is that there is no way (with Android, at least) to pull-back/cancel/rollback release and everything is blocked behind Google's review process. Why isn't it just possible to "yank" problematic release and continue showing previous release as the latest version. That would solve most of the issues within context of this problem.
    • imchillyb 3y ago
      Rollbacks allow malicious actors to /simply-easily/ circumvent device security and user preference. To allow rollbacks is to /significantly/ increase the attack surface of a device.
      • jarm0 3y ago
        What do you mean by that? Are you effectively trying to say that allowing upgrades does not have any risk of attack surface? I'm pretty sure that updating things have also a pretty high risk on introducing new previously non-existing security issues into your code-base/product.
      • rany_ 3y ago
        Not necessarily, Google has access to the developer's private key they use for signing their APKs so they could just make a fake release that has a bigger version number than the current version whenever a rollback is needed. No change is needed on Android itself, it's a Google Play issue.
• franczesko 3y ago
  We need appstore-less, fully device-private system. I'd be really happy to pay premium for that.
  • asddubs 3y ago
    well, there's always the librem and pinephone, although they're not at the point of maturity just yet
    • unnouinceput 3y ago
      the current system is already like this if you want to do sideloading/jailbreak/root of your devices. But that was the idea behind these stores: 'don't be like Microsoft and get viruses, we will make sure nooo malware ever enters our stores", which ofc is such a BS. As for the developer in the story, he could've just make this a .pkg to be sideloaded by their clients, circumventing Google altogether.
  • igor47 3y ago
    I would pay for an app store that maintained a currated list of apps which are actually checked for security and stability and tracking.
    • Wicher 3y ago
      Pretty much F-Droid.
• wouldbecouldbe 3y ago
  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.
  • jarm0 3y ago
    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/answer/11926878?hl=en 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.
    • wouldbecouldbe 3y ago
      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
    • wouldbecouldbe 3y ago
      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.
  • sirius87 3y ago
    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.
• denton-scratch 3y ago
  It 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.
  • moron4hire 3y ago
    > 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. Actually, both of those things can easily be done in a browser app. About the only thing that can't be done easily on mobile right now is GPU compute shaders. But that will also fall when WebGPU merges from desktop browsers. The only other thing I can think of is generic, system-wide file management. That probably won't ever be coming. Though the File System API does allow users to grant access to specific directories, I don't think the permission persists past a page reload.
  • donmcronald 3y ago
    > It was always obvious that Play Stores and their captive developer "communities" were a trap. Forced API upgrades are just one aspect of that. I was convinced the app stores would be a flop because I didn’t think there would be a critical mass of developers that were willing to give up the guarantee they could actually deploy their apps.
    • jowea 3y ago
      The big problem with this logic is that devs have to go where the users are if they want their money, no matter what.
  • SenAnder 3y ago
• binkHN 3y ago
  While 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.
  • jarm0 3y ago
    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?
    • binkHN 3y ago
      Unfortunately, as you noted, the game is rigged and you have to play within the sandbox provided. With that, and as you also noted, your testing simply needs to be better, especially since this is a customer-facing app and not an app that's solely used internally. As for dealing with the rollout when a serious bug is now in production, if you didn't roll out your app to 100% of the user base you could halt the roll out so it wouldn't affect any more customers. Then, while far from ideal, you could ask affected customers to uninstall the app and then reinstall it, and the newly installed version would reflect the previous version of your app.
• magic_man 3y ago
  One of the reasons why I appreciated windows. Even old software would run on newer versions.
  • natch 3y ago
    Unfortunately that also meant even old malware would run on newer versions.
    • fomine3 3y ago
      it's easier to block by simple antivirus
  • david_allison 3y ago
    Old software runs on Android as well. This is Google Play policy, not Android
• l72 3y ago
  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 the plugins, which haven't been updated yet, so it ended up being a full weekend of work and testing. Truthfully, 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. And the Play Store is still the first place users go to find apps. If google would just allow submitting a PWA directly to the app store, that'd be nice... I am not looking forward to doing this yearly. Professionally, we are also scrambling. We have a legacy app that some supported customers are still using until the end of the year. The app is a fairly complex application, and basic testing has already shown that just changing the target api version has broken quite a few things. We have gotten the extension, but we know this will take 1-2 weeks of developer time + 1-2 weeks of QA's time, for an update that does nothing but appease Google. All for an app we are going to officially remove from the store at the end of the year, once all customers transition to the new app is complete.
  • lutarezj 3y ago
    Not sure if it helps, but if I was in your situation I’d provide a few app updates with a screen to train users on how to install the PWA version and gracefully run away from these problems. Maybe also provide a some sort of a form to get some feedback over the difficulties encountered by users to get there. Good luck!
    • l72 3y ago
      The problem is that many of my users are temporary. For example, I have an app for the public transit system for a resort town in Colorado. The town has a decent, albeit small bus system. They technically have an app from their vendor, although it is not very good and is difficult to find. If you search for "$town_name transit app", it won't show up anywhere, where as my app does. And I think my app is much more user friendly. I wrote it because I visit this area a lot and hated the vendor app. My users are visiting this town for a few days, and are most likely going to open the app/play store and search for an app, use it for a few days, then leave the town and forget about it. The least amount of friction I can provide the better. My only goal is to support public transit and make it a smoother experience.
• Daril 3y ago
  IMHO, there are too many drawbacks to being forced to distribute an app through only one "self-authorised" app store and very few advantages. Pros (ironically): 1. the app store manager is supposed to check the app for malware and viruses before publishing it, ironically all the apps full of Google ads, Google and Facebook trackers of any kind are welcome ... 2. make it very easy for the user to search, install and update the apps, if he can find what they are looking for through billions of game apps and very similar apps that are only published to send advertisements to the user or to collect his personal data. Disadvantages: 1. you are tied to the whims of the app store manager 2. You have no control over the app publishing process: You cannot decide if you can publish your app or not, only the App Store Manager has the power to decide when and if it is convenient for him. I think only the user should have this right. I'd prefer to install the native commercial native apps (for example, the home banking app) on my phone by downloading them from the developer's website, in a private area that I have to access with my credentials, where the app is GPG signed and I can check the integrity of the package. An auto-update feature is doable. For open source apps, there is the F-Droid store where you can add your own repository (a bit technical and not for everyone, I admit : pre installing F-Droid on the new phones could help a lot, but I don't think Google will ever allow this). Another viable option is PWA. In my opinion, there are very few apps that need the native features, for all the others, almost everything is now doable with PWA technology, and you do not have to bother sending updates to users or asking them to upgrade. The monopolistic and commercial app stores, with the excuse of making life easier for users and in a supposedly "better security", are a "wonderful" way for Apple and Google to make billions on the work of independent developers and, in the case of Google, to collect and sell personal data about users and to sell ads of any kind in any way.
  • kmeisthax 3y ago
    You forgot another pro: it keeps the Boston Strangler[0] out of your house. By tying users' hands behind your back you can ensure that you dictate the terms by which they use your work. No piracy, no adblock, etc. This is why game developers largely fell in line with the "Licensed by Nintendo" model back in the 80s and 90s, and mobile app developers did the same thing with the iOS App Store in the late 2000s. They don't want to work directly with users to circumvent the platform owner, they want the platform owner to tie the users' hands, and they're willing to have their hands tied in the process. In the specific case of, say, your banking app; they want secure remote attestation so they can ban users that are running credential stuffing attacks against their app, prevent malware from opening your banking app and clicking the "pay fraudster" button, prevent users from extracting various tap-and-pay related encryption secrets, and also prevent them from injecting stolen secrets into their phone app. The app cannot, on its own, validate that the user's hands are tied; it needs a trustworthy (to them, not you) third party that lives in the boot chain and/or EL3 to validate that. So they don't want to just give you an app and a signature. They want Google to do it so that Google can tie your hands. It's important to note that all the user-facing benefits of app stores are backreasoning. The goal from the beginning was to tie users down, because to them, users are little thieving mosquitoes. This is the "quiet part" that they don't say out loud. Let's hope to dear god that Google's WEI proposal doesn't happen and PWAs never have access to attestation. Google already has the whole "we don't let you login on unknown browsers" nonsense and we don't need that cancer spreading. F-Droid is great. Google's shenanigans with Android need to be shut down. Hell, the EU was able to do that but the US needs to also do that and have it apply internationally. [0] MPAA code word for noncommercial small-scale copying, i.e. someone with a VCR taping shows off TV. Jack Valenti really was a piece of shit, wasn't he?
• Aulig 3y ago
  These minimum SDK requirements have been known for a very long time. It's correct that the email only got sent recently, but the requirements are usually announced 2 years in advance in this manner: After 0 days: New Android version comes out After 1 year: App Updates need to target the latest Android version After 2 years: Apps can't be downloaded on devices with the "new" Android version anymore unless they target the "new" Android version So normally there should be plebty of time to prepare. However, if you're an indie developer or not actively maintaining the app, then it definitely is annoying, since usually the apps would work perfectly fine on the new Android version without updating the targetSdk version.
  • sirius87 3y ago
    Many companies, institutions, public bodies hire external contractors to do a one-time development of a limited-scope app. I bet a bunch of them have their Google Play Console dev account email read by people in some engineering infrastructure function who know nothing about Android development. Updating their apps now means an internal scramble and unexpected project costs. Not saying its wrong or that we shouldn't move forward. Just saying many were complacent and contractors may have good opportunties in this space.
    • izacus 3y ago
      There's nothing "unexpected" about a process that takes 2 years to enforce restrictions and has been communicated and has been in place for years.
      • sirius87 3y ago
        Unexpected in the sense that at the time of commissioning the project years ago, they did not anticipate this event down the line.
        • izacus 3y ago
          This process has been in place for literal years and every professional Android developer part of such commissioning would know about it. Just like every iOS developer would know that apps need to be maintained for new iOS releases. This is just incompetent planning.
• nvm0n2 3y ago
  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).
  • gmiller123456 3y ago
    This is not about backwards compatability. Google is preventing users from installing apps that are 100% compatible with their phone.
    • nvm0n2 3y ago
      Yes, exactly. It is a "controlled" break. The OS is capable of being backwards incompatible but store policies create an equivalent of it being not backwards compatible.
• JoeyBananas 3y ago
  > 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."
• w0mbat 3y ago
  Murphy’s Law of app stores applies here: Any crashing build will be approved instantly, and the next build won’t be approved for days.
• mcsniff 3y ago
  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?
  • alain94040 3y ago
    Yes, not testing at all on a real device meshes nicely with their company's signature: Solutional is an *agile* software development company Emphasis on agile.
  • nvm0n2 3y ago
    > this is just shoddy maintenance The point being made by the author is that the app didn't actually need maintenance as far as its developers or users are concerned, which is a fair and reasonable complaint.
• giantg2 3y ago
  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.
  • mnau 3y ago
    Even .NET Core LTS is 3 years only (released every 2 years). Updates are pretty gradual and basically only add new features, but still.
• Snacklive 3y ago
  Perfect, this is exactly the same situation i am for this week. Need to update the targetSdk of 2 legacy apps. I know it's going to be fun :)
• natch 3y ago
  Author thinks that keeping up with security updates adds no business value. Got it.
• butz 3y ago
  Successfully updated my 10+ year old Android app to latest SDK. Of course, there are still loads of errors about deprecated function, but it seems to be working, as it is pretty simple application.
• ryandrake 3y ago
  This is a problem with software culture in general. 99% of us refuse to declare an application "done". We're always working on the next iteration, over and over forever. Cramming unwanted features, changing the UI over and over, updating dependency 2.8.1 to 2.8.2 and re-building. Most of it is change for the sake of change. The app stores obviously believe in this endless treadmill, too, and enforce it: Since everyone endlessly changes their software, you, too must endlessly change your software. If you don't believe this is a deeply ingrained culture problem, try proposing to your manager "Hey, this software is already really good and customers love it. Let's make this version the last one we release. We can work on something new." See what they say.
  • aleph_minus_one 3y ago
    > If you don't believe this is a deeply ingrained culture problem, try proposing to your manager "Hey, this software is already really good and customers love it. Let's make this version the last one we release. We can work on something new." See what they say. This description is rather an argument that this problem is deeply ingrained in management culture, and not in software culture.
  • brigadier132 3y ago
    > 99% of us refuse to declare an application "done". The article is literally about how they are not allowed to declare the app "done" because google is forcing them to upgrade to a new version. I'm sure the creators of this app wish they could just never touch it again.
    • ryandrake 3y ago
      That's the point. When you're that one person who wants to, you're swimming against the current.
• dan-0 3y ago
  There's plenty of reasons to complain about the things Google does, but this isn't one. This failure is purely on the author. 1. Google had been mentioning this change for a while 2. Target SDK update is a big deal, especially if you don't know what legacy stuff the app was built on, and surprise, can impact OS versions differently. 3. The emulator is not a good gauge of reality. I get this for a constrained team, but if it didn't cross your mind to even think of if Samsung or some other manufacturer has issues, you're showing you've done little Android Dev. 4. Straight 100% rollout. WTF. The other three, I can see some very isolated reasons for not knowing, but you manually have to change the rollout from 20% to 100% when you release. You said nah, I'm 100% sure of this code I don't know and pushed it. 5. The issue was realized after the customer reported the issue, and was almost ignored. Author released the app and didn't bother to look at crash reporting in the console which would have a strong indicator if any fresh crashes. If you gave half a care, you'd have been all over this the day of a release. I get it if you're a fresh web dev or something experimenting with Android, there will be surprises. And we can complain about Android backward compatibility and play store practices all day (I often do), but this isn't that. This was the mental equivalent of wanting to find out what lives in a hole in the forest by putting your hand in it first. Little to no thought of consequences or what a professional would do. I don't care if you don't like mobile, you're telling someone you know mobile enough to maintain their apps. You don't. This is negligence to a degree I'd be worried about getting fired, if not also sued over.
  • brokenbyclouds 3y ago
    100% rollout is the default for me when submitting an app. You're saying it's not for you?
    • MrDresden 3y ago
      Never do a 100% rollout. Partially release to your users and monitor the health of the release as it trickles out. If everything is fine then increase the percentage. Only very late increase to 100% as then there is no going back.
• sn_master 3y ago
  Meanwhile, Windows is still shipping MSVBVM6.dll and the IE-4-compatible OCX files for compatibility with apps made using mid-1990s APIs.
• clumsysmurf 3y ago
  Its actually much worse than what the author wrote about - he/she just messed up execution of roll-out. If they decided, the app was really not worth it, they could have unpublished it. However, even unpublished apps can jeopardize your account's standing by running afoul of a policy, which Google may have concocted long after the app was written. Unpublished apps in this state can get your account permanently banned. You have to support your apps for the rest of your life (if you care about your account).
• xipix 3y ago
  Best to ignore such messages. Call Google's bluff. I do, my apps keep paying out.
  • david_allison 3y ago
    Just to note: your apps won't be installable on Android 13
• mvdtnz 3y ago
  I do not sympathise with people who build apps for these evil stores. Google and Apple can only deliver value in their app stores because of you tending their gardens. As developers and businesses we must stop tending their gardens. Build on open platforms.
• pixel_tracing 3y ago
  I did both Android and iOS development professionally for years. I fully switched to iOS due to unprofessionalism from Google. IMO Apple does a far better job of QA and backwards compatibility story than Android. I can say this for sure since I’ve worked at both companies after being a consultant for both Android & iOS.
• Ozzie_osman 3y ago
  I don't get the comments tearing into OP. Sure, he could have been more careful. He could have tested the login on the latest version of Android. But what if it wasn't a login crash? What if it worked on the latest version but not others? At what point do you draw the line? At some point, you just have to say "OK this is a platform used by literally millions of apps and millions of developers, and mistakes will be made, and it should be easy to fix them by stopping your own rollout (without having to know tricks like doing a staged release) or immediately making an older, already approved version live again". It's such a basic design principle to make things revertible/recoverable, especially for something like an app store.
  • jarm0 3y ago
    I'm the OP and thank you for thinking along with me here. As stated in numerous replies already then I totally agree that I could have done better in terms of testing things out - of course, there's always room for improvement in that regard. There was a deadline set by Google (again, first time I heard about it was at 18th of August, not before), change seemed trivial at time and since app worked on an old Android version as it was before then I didn't expect it to fail so miserably. Again, I'm not a seasoned Android dev, but have 15+ years of experience in software development in general so I have some expectations how things will work or not and what to expect and be afraid of. I really didn't know that "best practice" is to do a staged roll-out of "99.99999999%" to have a way of partial "yank" possibility of the latest release. To find out that there's no way to cancel/delete a latest release to fall back to previous working version was just something I did not expect in my wildest dreams (I guess this is something you only learn during situations like these). Yes, everyone can blame me for not testing every functionality with every Android version and I do the same, but please open your eyes and understand that the way releases are currently handled by Play Store is not a sane person would do outside of Play Store. Everyone will have a problem like this at one point and I do hope that this article will and thread in here will lower the number of developers experiencing situation similar to this.
  • scarface_74 3y ago
    > What if it worked on the latest version but not others? At what point do you draw the line? This is a poor excuse. Even if it were a web app, you would still need to test on multiple browsers. Doing a smoke test on a new release is just basic professionalism. And having a phase roll out with a rollback is also not a new concept.
• kramerger 3y ago
  I am sorry, I have ZERO sympathy for the OP. First of all, new versions means its covered by improved security & privacy functions. Everybody should always upgrade to highest possible version. Google has nagged devs about this for YEARS. Also, if you never update your app and consider it "done", you are probably ignoring security erratas in your libraries Finally, who maintains an Android app, makes a major upgrade but doesn't have an Android phone to test it before pushing the update??
• foobarbazetc 3y ago
  Every forced Android minimum targetSDK update breaks literally everything. There’s also a breaking change coming up in SDK 34 around exact alarms. Google seems hell bent on making the platform more and more restrictive as time goes on because they started with no restrictions. Apple started off more restrictive and then loosened restrictions as they put actual thought into APIs. I don’t think there’s been a breaking change since iOS 8 or so.
• Phelinofist 3y ago
  Another aspect where we are prisoners: Java features take ages to get ported (if all ?). Also all the nice JVM stuff.
• deleted 3y ago
  [deleted]
• tamimio 3y ago
  Kudos to that user reporting the issue, sometimes when I report issues I am 90% no one read those. > There's nothing we as developers can do to speed up the reviewal process nor contact Google support in any way. There are no possible workarounds and we just have to wait. Wait until we're excused to put our fixes to production. A couple years ago, and out of self-learning process, I decided to develop an Android app, never did any smartphone app development, Flutter was new so got excited to try it out, long story short, I submitted the app to play store, and it remained “under review” for 40 days! Just like OP, Next day I was checking the dashboard, silly me thinking the process is smooth, after 3 days I stopped checking and later forgot about it until they sent an email after 40 days, I pulled the app later and decided never to touch anything again with smartphones app development, and that was play store, supposedly the easier one after reading some horror stories of the App store.
• 1vuio0pswjnm7 3y ago
  "First idea was to roll back to the older working version in the Google Play Store so that only users who were running latest Android and had the latest version of the app would be affected and then deal with that problem in a proper way at the next day. For my surprise I found out that this is not possible - there is no way using Android eco-system to pull back or cancel latest release." Perhaps this is an example of "anti-rollback technology". https://news.ycombinator.com/item?id=37218265 https://news.ycombinator.com/item?id=37218265 "I personally have been against developing mobile apps for years now for the exact same reasons described in here and other similar articles - as soon as you decide to develop mobile apps then you give control of your product/service away to a third party, which you can't replace when problems happen." What is an "app store". Computer owner cannot install any software they want on their own computer. Computer owner must select from pre-approved list provided by third party. The word "store" is misleading. 95%+ of the programs in the "store" are free. If the figure 95%+ is incorrect I apologise; I can get the exact figure. This has been publicly disclosed in litigation. These concepts can seem outrageous to anyone who has watched computer and internet use go from uncommon to common. There are HN commenters who want to pretend they are totally organic and perfectly fine. Hypernormalisation. Beyond question. Right. Maybe for those who were born into a world where computers and the internet are being dominated by a handful of online advertising services companies calling themselves "tech" companies, ideas like (a) "you cannot use a previous version of this software that you got for free or paid for; an advertising company will protect your privacy" and (b) "you must select from the following software chosen by an advertising company to run on your computer" are an easy sell. Those born into this hypernormalised environment are actually a minority of the population in the USA. For example, 66% were born before 1999. https://www2.census.gov/library/publications/decennial/2020/census-briefs/c2020br-06.pdf https://www2.census.gov/library/publications/decennial/2020/... We can change this "anti-rollback" and "app store" BS. (All falsely justified in the name of "security" and/or, ironically, "convenience", two mutually exclusive concepts.) The personal computer belongs to the person who bought it. They can use any software they like, any version they like, and they can write their own software to run on their own computer, without any payment to a third party. This was once where things were before the so-called "tech" companies threw a monyewrench into the wheels of progress.
• Ozzie_osman 3y ago
  This is actually ironic because one of Google's SRE principles is that "rollbacks are normal". https://cloud.google.com/blog/products/gcp/reliable-releases-and-rollbacks-cre-life-lessons https://cloud.google.com/blog/products/gcp/reliable-releases... "At Google, our philosophy is that “rollbacks are normal.” When an error is found or reasonably suspected in a new release, the releasing team rolls back first and investigates the problem second. A request for a rollback is not interpreted as an attack on the releasing team, or even the person who wrote the code containing the bug; rather, it is understood as The Right Thing To Do to make the system as reliable as possible for the user. No-one will ask “why did you roll back this change?” as long as the rollback changelist describes the problem that was seen."
  • david_allison 3y ago
    As of last year, due to a mix of Google Play policies and Android updates, if you're distributing an app on the Play Store, the only way to rollback is an uninstall + wipe user data. ---- * You cannot downgrade to a lower `versionCode` & `versionCode` is defined by the developer * Android 11 prohibits writing to 'permanent' storage of the phone, with the exception of media, or using the `DocumentFile` API, which treats a local folder as cloud storage. `DocumentFile` is unusable for many use cases * A developer can set `hasFragileUserData`, which should ask a user if they want to wipe their data on uninstall. There are Google/Android bugs which mean this dialog may not be shown * If an app is uninstalled and the user doesn't delete data, Android blocks a downgrade to a lower `versionCode` * You can use a regular java.io.File if you request `MANAGE_EXTERNAL_STRORAGE` * Google Play only grants `MANAGE_EXTERNAL_STRORAGE` in exceptional circumstances
  • michelb 3y ago
    "rollbacks for me but not for thee"
• belimawr 3y ago
  Not exactly a fan of Play Store policies, but for this situation, I'd say that Google gave ample time for developers to migrate to API 33, and all behavioral changes and API deprecations are documented (however annoying it is).
• lawgimenez 3y ago
  To add more context, the [1] policy has been around since last year. > Today, as part of Google Play’s latest policy updates, we are taking additional steps to protect users from installing apps that may not have the latest privacy and security features by expanding our target level API requirements. Starting on November 1, 2022, existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level. As new Android OS versions launch in the future, the requirement window will adjust accordingly. [1] https://android-developers.googleblog.com/2022/04/expanding-plays-target-level-api-requirements-to-strengthen-user-security.html https://android-developers.googleblog.com/2022/04/expanding-...
  • deleted 3y ago
    [deleted]
• darklycan51 3y ago
  Oh yeah all my old apps got taken down by Google because apparently, they don't like that I don't update my apps for no reason whatsoever, even though they were offline games...
  • anders_p 3y ago
    Times change. Hackers and scammers get more advanced. Vulnerabilities are discovered with time. Users expect more security today than 10 years ago. For Google & device manufacturers to be able to guarantee that level of security, they need to keep their store updated. And the apps on there shouldn't be using outdated insecure APIs. If you're not able to keep up with that, then you shouldn't have any expectation of getting new downloads on their platform.
• zeagle 3y ago
  Am I correct in understanding that if you have an Android 11 device, you will still be able to use existing apps that are updated but not new applications? Unfortunate for devices like boox ultra or the c version which were launched this year but unlikely to ever be upgraded to 12+ probably given SOCs.
• oaiey 3y ago
  Real life: Assume you are critical infrastructure of the whole world (as in people are in risk short term and thousands literally die in the long term because of potential delays ... as part of your day to day operations without special external event) and you need to run apps with proprietary third party sensors on millions of end users devices. Right now you run it with provisioned Android devices but users obviously complain about the lack of byod and customers about the costs. There is no way to have a risk free way of providing this service on Apple or Google stores even with perfect own behavior. App Stores and their procedures are a risk to public health. Period.
• david_allison 3y ago
  To anyone with practical issues with the SDK update: you can request an extension to November 31 from the Google Play Dashboard.
• SquidJack 3y ago
  The one and only reason I switched to web dev is the google they suspended my 4 years old play console account with 3 apps total download around 1.5 million they say I was Associated with an another account and they didn't provide any details about the other account I worked as a freelancer for almost 20+ app products it's hard to left android development and get In to web dev but I did I don't want someone to destroy all my 4 years Of work one email without any reason
• SillyUsername 3y ago
  "I don't know about you, but that doesn't sound professional way to solve any problems." By unprofessional, is he talking about his failure to test a build intended to run on the latest Android devices, on the latest Android version here? If not, I don't understand the problem, one shouldn't expect others to prioritise reviewing their work especially as a build already had attention within 24 hours (initial review). I hope he took this as a lesson learned to adequately test production code for an environment he really has no deployment control of or final QA sign off.
• thdespou 3y ago
  This occurrence happens more often that you think if you are working on Mobile Apps. You just have to be extra careful with testing and verification, since the mistakes can be costly.
• tomjuggler 3y ago
  Yeah I should have given up on Android development when they deprecated the menu button and broke all my apps back in the day. Should have learned - instead I kept updating on the treadmill until a few years ago luckily got a web gig and never looked back.
• olgeni 3y ago
  One has to wonder if these “review” mechanisms are not really engineered like a Skinner box, where the developer is the pigeon. I honestly cannot decide which is worse: app development, or the web ecosystem as a whole. But at least on “the web” you can push fixes at a resonable speed.