From a cursory glance, their apps seem to be of the kind that don't need continuous updates and can be considered complete. Self-contained, offline software that serves a specific purpose: https://search.f-droid.org/?q=SECUSO&lang=en
Unfortunately, Google no longer recognizes this as a valid development strategy. If you want to publish on Google Play, you need to continuously release updates targeting an SDK released within the past year[0]. If you don't, they will send you constant warnings about how your app is violating their policies, they might derank your app, and eventually they'll stop making your app available to new users.
Updating the SDK is not that simple and it often introduces new bugs if you don't read through the full changelog and test thoroughly. I have 3 apps and it already feels like I spend too much time each year updating SDK, I can't imagine updating 30.
They talk about how this somehow improves security and enhances user experience, meanwhile this policy worsens user experience by pushing people towards ad-filled apps that have the resources and courage to release needless updates, and they still publish spyware on their store.
I've attempted to make this point to proponents of the walled gardens as a real benefit they are losing. There are app developers that just want to make useful stuff and share it. But Play (and the App Store) are completely designed around developers that are trying to make a living there (because that's how Google/Apple make money off the store). As such, the stores are quite hostile to community built software that changes rarely. This is a real loss, as I think that software is often the best available for a given purpose due to simplicity, privacy, and longevity.
I've had some thoughts in a similar vein, but I was thinking from a privacy perspective. The Google and Apple arguments for the walled gardens basically boil down to "You can't trust other stores to protect your privacy and security", but the obvious counter-argument to that is that other stores may actually be able to focus more on privacy and security than the walled gardens do.
Apple and Google inevitably have limited privacy protections, because they'd probably run off Meta and a bunch of other really popular / in-demand apps and cut into their own bottom-line if they really cracked down. In contrast, a third party store may be more free to only host apps that are more privacy-oriented or have been security audited, etc.
Look, to be blunt about it I think what Apple did to Facebook was a necessary evil, they (Facebook) seemed to buy Whatsapp as purely a way to entrench their network effects, get access to phone numbers and contacts etc, and their data hoovering practices are so severe that they tried to pin their own certificate (or something like that, I'm hazy on the details)
I get the Apple skepticism, I'm not happy with some of what they do, I think it's contentious when app stores ban something like Parler, but fine-grained granularity is something we kind of desperately need
Arguments in this day and age are soldiers[1], at least when they come from powerful people: (if you're a corporation or a government) they are things you send to fight for you. You don't have to actually believe them, and the most effective ones are often not ones that are true.
As a counter point - I just downloaded Canabalt from Apple Store, that wasn't updated in 7 years and it works just fine. The oldest app I found (that still had App page) are 10 years old without updates and I see many released in 2011 that I can download but doesn't have app page anymore.
My point is that one cannot make an argument over bad implementation. E.g. Sony is known for pulling down games or even stores for older devices whereas Steam allow people to download games bought decades ago.
It's hard for even developers and small companies TRYING to make a living there. Keeping an app active in the app stores requires a lot of extra overhead, but doesn't add significant value to the product in cases where it's a native cross-platform or browser-based app.
So many of the apps installed on my phone could be PWAs, but since the implementation of PWAs is quite limited - a native app is required in most cases.
Great point, and also: the walled garden operators don't make any money off of free apps, so they don't prioritize supporting creators of free apps. The result is that it becomes unsustainable for most developers to keep a free app on the store.
The incentive structure of walled garden app stores encourages the proliferation of paid apps for everything, including things like an instrument tuner or a notepad app that'd be free in a non-walled garden environment.
Compatibility is broken constantly on the web, but it is forward compatibility. This is why most browsers now auto-update to newer versions. Websites then require new features which will result in older browsers being non-functional.
Backward incompatible changes happen - they are more difficult due to lack of communication with/pressure on the sites they will break, and coordination of strategy with other browser vendors. This can actually be quite frustrating, as each browser has their own 1-3 month cadence for new releases and it is difficult to track whether a breaking change is going to land on any given browser soon enough to coordinate a new version of a site.
True, complicated websites need to be tested. But if a web site serves simple web pages then it generally doesn’t have a maintenance burden. (Though, link rot happens to everyone.)
> "Additionally, the app prevents devices from taking screenshots."
Why do the "security" apps ALWAYS have to have this anti-feature? It's especially annoying when employed by the banking apps.
Famously, Schwab had some issues where it didn't properly keep track of orders during highest loads (people ending up selling more shares than they had even in IRA accounts), yet conveniently they prevent users from taking screenshots of their app, so you wouldn't be able to prove that you did cancel or replace the order and did receive the cancel confirmation, before it executed anyways. Of course, if it's an IRA account, selling more shares than you own, is clearly Schwab's bug, but not being able to keep these things locally, is one of the biggest anti-features of modern apps.
> When a window is flagged with FLAG_SECURE, Android prevents screenshots from being taken and prevents the window from being displayed on a non-secure display, such as a TV or projector. This helps to protect the information that is being displayed in the window from being accessed by unauthorized people.
So the docs might imply that "the information" is your banking information, and the "unauthorized people" are, I guess, dudes with binoculars outside your window. But actually "the information" is Netflix and the "unauthorized people" are you.
That's why you can project your OTP codes on a 50-foot wall as long as your projector is HDCP-compliant.
> Why do the "security" apps ALWAYS have to have this anti-feature?
Every pen test I’ve seen for mobile apps has always had this as an item, even when it’s completely unjustified for the type of app. It’s on their checklist and they will always flag it to show they are doing their job. If you don’t have anybody in the team who is willing and able to say no to a pen tester on a security matter, this kind of thing will happen.
I'm the person who enjoys saying no to this kind of thing. Also, we will not disable copy and paste for password fields, and we will not make our users rotate their passwords every 11 days ("because we align with NIST guidelines which say not to do that").
This is exactly how I recognise bad "pentest" firms and tell all my friends and clients the same. If the pentest contains report any mention of [screenshot, obfuscation, root detection, attestation] it's bullshit and you should demand your money back (you won't get it, but still, you should demand it) and tell everyone in your circle to not give another cent to them.
I don't know if anything has changed but 10 years ago I was part of an effort to make the base OS of our product FIPS-compliant. FIPS was both prescriptive and outdated. And it turned out that the changes required to make everything FIPS-compliant actually made our product demonstrably less secure.
But we had to ship it anyway, otherwise a non-negligible portion of our customers could not legally buy our product.
Unfortunately the point of a pentest/audit isn't to do one, but merely to check the box saying you did one, and I'm sure bad ones must be cheaper and still allow you to check the box.
I simply delete and rate 1* any app that doesn't work, including Schwab.
Schwab's mobile website is actually decent, and, basically, works better than their app in every way.
I'm honestly disappointed Android doesn't do something about these broken apps that don't let me keep records of my own stuff.
It should not be possible for an app to prevent screenshot use 100% of the time.
There should also be a 180° on the checklists to flag any app that uses disable-screenshot 100% of the time, similar to how we went from requiring people to change passwords every 14 days, to removing the mandatory-password-change policy in its entirety.
At a previous employer of mine, it was common to share dev accounts for certain things. These were not security sensitive things. They were there purely for dev purposes and these were things like anayltics tools and stuff that the software being built had to integrate with, so they were basically development sandboxes.
Many of these tools had MFA enabled and so it was common to share MFA codes on Slack because the MFA code was sent to an email address that only one person had access to.
One lunch and learn a group of developers shared how they solved this problem by having the MFA codes pushed to a device that was effectively an on-prem server / dev box that they installed custom built software on to take a screenshot of the MFA code and broadcast it on the relevant Slack channel.
The main point of the lunch and learn, however, wasn't so much to share the tool that they had built, but to talk about how they got around the Mac OS security protections that are there to prevent this sort of thing.
My first thought was "we've just written malware."
I'm specifically responding to this sentence of yours:
> It's especially annoying when employed by the banking apps.
After my experience with that MFA code sniffer ... I know exactly why banking apps and other privacy/security-centred apps prevent taking screenshots :)
I fail to see how your conclusion follows from the premise.
Banking apps in the US don't even show any PINs for 2FA, so, why exactly is Schwab doing that again?
BTW, Google Wallet does let you take screenshots of all the views except for just one or two views where you enter card number, billing and card security code. Honestly, even that is an overreach; it's not like I can't use the camera to take a photo of my credit card with CVV in view, so, why should the camera function of any app prevent that again? Google never blocks screenshots of any transactions, last-4 of any card, or any other screens. If they ever did, I'd be far less happy with them, and would go out of my way to find an alternative contactless provider. Wells Fargo used to provide contactless on Android in their app for their own cards, but, probably thanks to Apple, this feature was removed for feature parity with iOS.
You're laser focusing on MFA sniffing, specifically. The point is that malware can take screenshots to harvest information. Your banking information has a ton of sensitive information about you that could be used for a variety of different purposes, such as for identity theft. My point was that making it impossible to take screenshots is trying to protect against the possibility that there is malware harvesting anything through screenshots.
>why should the camera function of any app prevent that again?
Because you taking a photo of it with a physical camera is intentional. Another app on the device screen recording that view may not be intentional by the user.
Starting the recording may have been intentional, but the recording of sensitive content may not be. For example Twitch streamers frequently leak their personal information by accident. If that personal information could automatically be blacked out it would save them from trouble.
I feel fairly confident asserting that users are not trained to go through the steps to enable screenshots. Blindly clicking allow is one thing. Going back and forth to enable restricted settings and then grant the permission is quite another. I use a screenshot app, and am pretty technical, and it took me multiple tries and several minutes including having to go read https://support.google.com/android/answer/12623953#allowrest... because Android is so concerned with protecting me.
Yes, by blindly clicking allow. But in this thread we're arguing about specifically problems with screenshots, which are behind much stronger permission gates that can't be blindly clicked through.
Why would headphones need contacts permissions? Where are you getting these headphones from?
I routinely deny permissions to most apps on Android, and never have any issues. In my years of using random apps, the only app I'm aware of, which doesn't work without permissions, is Capital One banking app, which refuses to work unless it gets the phone permission. So, I just 1-star Capital One in the Play Store, uninstall as defective, and move on.
BTW, where are the permission screens on iOS? Or is the blissful ignorance more secure than being able to click "deny" a few times?
Some do that, and it's super annoying. I take a screenshot, and then silently my login doesn't work, with a weird error returned instead. Get another PIN, type it in, take a screenshot before submit, again get a nondescript error that makes no sense.
Don't they star the PIN in any case?
Why exactly is me taking a screenshot of my signup process for my records suddenly a disqualifier for signing up?
If all these companies never lied to us about the terms of the deals we're signing up for, needing proof of what actually happened, we'd never be taking these screenshots.
Honestly, this whole "security" theatre ought to be investigated by the consumer protection agencies, and any app that prevents screenshots being taken, or gives these nondescript errors when someone takes it and is subsequently unable to sign-in, should be fined for their anti-consumer behaviours.
I replied to someone else with the same response. I'll repeat it here. The point of my reply wasn't to do with MFA codes, specifically, but the fact that MALWARE can take screenshots in order to harvest things, such as MFA codes or anything else. Preventing screenshots is likely, in my opinion, a defence against malware harvesting anything that way. Your online banking can present a lot of sensitive information visually that could be used for things like identity theft etc.
And yes, there are other ways that malware can harvest information and if your device has been root-kitted you're screwed no matter what. But the fact that there are 100 ways to attack you doesn't mean the banks don't see value in trying to prevent 50 of them.
a) I cancelled my "intelligent advisor" accounts (which was a pain to do by itself) and had the money xferred back into regular IRA accounts. After this was complete, I was no longer able to see any trade history for the past 12 years of those Intelligent Advisor accounts, *even though they were ostensibly backed by regular Schwab IRAs*, and my historical "wealth" tracking in Schwab made it look like I'd simply never had the $NNN^n that was in those accounts for that period of time, or in other words as if I'd added $NNN^n to my accounts on the day of the transfer. Definitely some hackery there. I had one Schwab rep who acknowledged this as a (rather severe) problem, but the other 3 I spoke to did not even understand why it was an issue.
That's a very shallow protection. Even if one has no other camera (phone, table, a real camera) there are always friends and relatives that can help and take a picture of the screen. Furthermore a picture of the screen and the phone around it has a more real feel than a screenshot that could be photoshopped.
A screenshot develops evidence of something happening or not happening according to the person who took the screenshot.
If you start claiming that it can be photoshopped, well, what prevents anyone from photoshopping a real camera shot? Or photoshopping a screenshot, and then taking a "real" shot with a camera? With AI, you can now even do this with video, too.
For practical purposes, your suggestion is simply unrealistic. It's unrealistic to be using a second phone to be taking random confirmations from your main phone, and it's even more unrealistic if you're doing trading where every second counts, and where the whole reason that Schwab cannot execute properly, is because orders are placed and cancelled than once. It's even yet more unrealistic because of focus and angle issues, and reduced precision, and increased file size etc.
BTW, I have personally encountered this consistency bug at Schwab Brokerage. I wasn't even using Schwab's app, precisely because it doesn't let you take screenshots. In my case, the loss was not major, and not worth pursuing.
But other people reported that their IRA accounts sold shares short as a result of this consistency issue, which is kind of a problem for everybody when you cannot buy it back if it has 10x'ed since the sale like GME once had, and cannot even add any more money even if you have it, because it's a tax-advantaged account with limits on how much you can add each year.
Yeah, SDK updates are a pain. I wrote ChromaDoze in 2010 so I've gone through several. Recently, the most annoying changes were:
- Foreground services used to require a persistent notification, now they're not allowed to have a notification unless you prompt the user. So I added a button to beg for POST_NOTIFICATIONS permission, but now permission can be granted after the service starts, so I had to build some magic to make the service refresh its own notification.
- Gesture navigation steals user input when swiping on the left/right edges of the screen, so I had to build some magic to automatically make my UI narrower when gesture navigation is enabled. Drawing apps can't really use setSystemGestureExclusionRects() because it's limited to 200dp.
- By default, apps now render edge-to-edge vertically, behind the semi-transparent status bar and bottom navigation buttons, so I had to build some magic to avoid those areas.
Now that gesture navigation is the default, many developers aren't testing with 3-button navigation, so I've noticed apps where I can't interact with the bottom because it collides with my navigation buttons.
> - Gesture navigation steals user input when swiping on the left/right edges of the screen,
Well I've seen even 1B+ dl apps failing to handle that (on a Google Pixel), so at this point I'm putting the blame on Google. I've switched back to three button navigation. Though even some trivial OS gestures like screen unlock fail reliably on my Pixel 6a. (As in, I do the gesture, it fails to register the gesture, i try to make the gesture "with more conviction" through the whole screen and it still fails, and after few minutes it ends up okay somehow)
Don't worry. Google broke it as well with shitty "edge-to-edge" nonsense to make the apps more "engaging" by forcing them to deal with the disappearing bottom bar. By default.
I also share this resentment. It became very hard to have a niche app for a family or a small circle. Not like it was easy before, but amount of time one needs to invest to keep it up to date with requirements is not sustainable. Web apps are also a hard thing once you consider hosting and storage expenses.
I think both of you and TFA misunderstand what the targetSdkVersion is.
If your app barely uses any permissions (like TFA's apps), you just need to update the targetSdkVersion in the manifest once per year and push the update. That's it. You're not updating SDKs or compiling against a newer SDK or anything.
It's not that simple. If it were that simple Android Studio wouldn't show you a big red error when you do that and they wouldn't have built an entire assistant for the purpose of incrementing a number[0]. The reason is that bumping the targetSdkVersion changes various behavior, sometimes in a breaking manner. A good recent example is that 34 -> 35 will force edgeToEdge rendering on all activities unless you opt-out per-window (and 35 -> 36 removes the opt-out). So simply doing what you said would probably lead to UI elements appearing behind the nav/status bars and the app being unusable (on API 35+ devices, from my understanding).
You do need a newer SDK to update the target-sdk-version though. And you may find that libraries you used are not compatible, unless you update them, and updating them may break things. Maybe for a minimal app in pure java or kotlin this won't be a problem.
There was an open-source app that hasn't been updated in a few years that was delisted from the store. I decided to try my hand at recompiling to target latest required sdk "target" or whatever. It used Xamarin / C# and some additional libraries. It does not talk to the internet, it's just a minimal remote-control and data-logger for a bluetooth multimeter. If you can find a copy of the last APK published and sideload it, it works. But if you try to update the SDK so you can target the required SDK version for the Play Store, compile fails, misc cryptic errors due to libraries. Updating libraries was tricky for me because while I'm quite familiar with C, C++, Python, Go (etc), I'm not at all familiar with Android, Java, Kotlin, nor C#, visual-studio, etc. After a few days of struggle I managed to update libraries and fix the build, but the app's layout was totally broken, only one button appears (and again I'm not familiar with any of this stuff).
This app really didn't need any updates. It's a < 20MB app to control a local device, and it still works. At least you can still side-load it. Sheesh.
> You do need a newer SDK to update the target-sdk-version though.
No you don't.
You probably should just use an older version of Android Studio for your case which supports the original compileSdkVersion from the original gradle build. Then update the targetSdkVersion in the manifest and that's it.
While you are technically correct (the best kind of correct), official guidance is to use support libraries that are at least as new as the targetSdkLevel, so if you follow that recommendation you still have to update.
Also, I try to at least do the bare minimum level of testing the app still works after rebuilding by launching the app in the emulator once (I don't usually have a phone that runs the newest API level), which means downloading at least a new emulator image.
In practice it's just easier to update the entire platform.
> If your app barely uses any permissions (like TFA's apps), you just need to update the targetSdkVersion in the manifest
And what if you do use permissions for stuff like, say, external storage access, don't you need a recent SDK so you can use the APIs for things like the run-time permission requests now mandatory? But I believe the Android SDK removed support for building with ant years ago. And lets say I'm using a legacy framework with an incredibly contrived ant- (and bash-)based build system which there's no way I'm rewriting. Therefore, I'm in big trouble, am I not? Honest question.
Runtime permissions where introduced in 2015 with Android 6.0 (SDK 23).
So you indeed need to use a new enough Android Studio and compile against SDK 23. You need to use the new API, I think the easiest way is to add a button and call requestPermissions() [1], you can leave the rest of the code unmodified.
Also, note that Google Play does not allow the external storage access permission except if it's a file manager app. It's better to use the SAF API (since Android 4.4 SDK 19) instead. Depending on your app, that may need bigger changes.
By the way, I'm working on a syscall interception framework[2] that could in theory intercept the file io syscalls and redirect them to use the SAF API. That would need only minimal changes to your app and also would allow to run things like syncthing unmodified.
You need to make these changes anyway, because Android 14+ can not install apps with targetSdkVersion < 23.
I find this kind of posting deeply ironic, since HN and ArsTechnica has been ripping Android a new one before this policy came into effect for allowing apps to exploit old APIs for stealing data, triggering popups, spamming notifications and many more changes that have been done from there. Many praises were sung to superiority of iOS and their demand to keep up to date with new policies and even new design.
And now we hear complaining again over things like... (a few posts lower)... having to implement permission dialog to show notifiactions? Right :D
The reality of the situation is that without required SDK changes, every single app - from your banking app to every game - would STILL demand access to all your files, all your documents, all your photos (and their locations) before they run. And then proceeded to spam you with notifications from background trying to sell you crypto.
Fixing those things unfortunately means that also the opensource developers need to move their behinds and implement APIs in a way that respect users more.
So just don't let developers push updates targeting old SDKs? Show a scary permission dialog on every app launch for dangerous permissions? Delist only the apps that actually use or at least register those permissions?
There are many possible solutions and none of them are "you have to recompile once per year or we ban you".
Noone is being banned because of this. You can't publish an update if it targets old Sdk and old sdk targeting apps don't appear to users (unless the user has already installed that app before).
That's it. Google is directly following your recommendation. Developers have usually more than a full year to comply (e.g. Android 16 has just released, developers will have to target Android 15 at the end of August. Android 15 beta was released around march 2024 giving developers ability to prepare and test).
What part of what I said suggested "old sdk targeting apps don't appear to users (unless the user has already installed that app before)" would be fine?
If the app works and doesn't do anything bad, there's no reason to delist it.
But the app is doing something bad - it has access to data it shouldn't have.
Unless you're saying that you solved the halting problem and can guarantee and verify that apps that still have all access to your data (because permissions aren't enforced) will NEVER in ANY codepath read data they don't need - you can sell that solution to Google Play then.
Sites like HN are different people with different opinions posting different views, so of course some of that will conflict. I don't get why this staggeringly obvious fact needs to be explained over and over again...
And beyond those things there are often performance / battery optimization related things as part of the update too. Just because an app claims it respects your privacy, it doesn't mean that it is a well behaved app.
Most other android app stores enforce a high target sdk. Fdroid is the only one I know that doesn't and allows apps as far back as Android supports. Android has been yearly, except Android 16 it seems, raising the minimum installable target sdk so eventually updates will be needed to run on new devices.
Also, those new SDKs make slightly older Android versions not work anymore with the updated applications, in some cases. My main Android tablet can't get updates for several apps, and some apps are updated but won't work with e.g. Chromecast anymore (and were updated _only_ because of the nag-system of Google, there are no changes in the apps themselves).
And going to the latest Android version isn't an option, that would imply buying a (at these times Really Expensive) new tablet, and what's offered now aren't even covering what I want from a tablet. Of course, if the vendors continued to provide updates to tablets and phones.. but they don't.
Totally agree - I have a platform with an app which hardly changes but I constantly need to do maintenance which doesn't help my platform or is a gain for my users.
The second app is often the Aurora Store app store app, from within the F-Droid app, which then lets you install Google Play apps without having to have a Google Account:
With these two apps installed first, on any Android device, whether locked or not, without any need for any computer or any other device, without having to type-in any Google Account details, you can then do pretty much whatever you require on the device, including installing bank apps, Amazon, Amazon Music, Audible, Prime Video, etc.
Sadly, iOS has no alternatives like this. Apple proudly reports terminating 128,961,839 customer accounts in 2024 (yes, Apple has terminated 129 million customer accounts in just one year), and they do NOT allow using an iOS device without an Apple customer account:
There's always a "later" or equivalent button in all of these setups, sometimes it does have a few prompts.
I personally have iPhone, Google Pixel, OnePlus, Motorola and Samsung devices, without any accounts on them. The iPhones are very limited without an account, obviously, but I never feel that way on Android.
All that I did to set them up, is click on the screen a few times, no extra tools or anything. Then just go into the browser, and follow the instructions for F-Droid installation; which can be done entirely on the phone, without a computer or any other phone, or any username/password.
For my Motorola, the "later" or equivalent did not appear if you connected to WiFi during setup. You have to have no network connection, first, to not have a Google Account.
Whenever I buy a new Android device I take the opportunity to pretend I'm a grandma getting her first piece of technology and create a brand new Google account, since it's one of the only signup pathways that doesn't require some kind of identity verification.
That's a nice trick to get a fresh Google Account without any verifications!
But why would you need so many Google accounts? I think at one point it may simply become cumbersome to keep track of all the accounts, so, using an account-less Aurora Store seems like a very easy pathway to take.
I honestly never feel disadvantaged in any way by not having a Google Account on my Android. Aurora Store works, Google Maps works, banking and streaming works, everything just works.
When something importantrequires a Google account, now you have a burner account you can use. If you somehow have so many you can't keep track of them then great, you can use one account for one thing. If you only have two or three, at least you can make correlating them harder - the perfect's the enemy of the good. (I expect that if you log into more than one on the same Google phone, Google internally marks them as related. Still, other apps don't have access to that fact.)
I usually expressly don't login into any account because I simply don't want to remember which device I've logged which accounts in. It's just easier that way.
On my main device, I'd use a regular Google Account. But if I'm getting a test device, or a device I simply play around with, it doesn't have to have a Google Account, and yet it can still have all the apps I'd ever want.
Unlike with iOS, where you're severely limited in trying out a device without having an Apple Account. Yet somehow it's Apple that's deemed to respect people's privacy, go figure.
> Top 10 guidelines or DPLA provisions cited for removal
> 1. Guideline 4.0 — Design: 42,2527
Does that line item mean that Apple is rejecting the largest body of apps for not meeting the design guidelines? Man... if I had a penny for every app still on the App Store that blatantly disregards the human interface guidelines...
It's such bullshit. Having been fed up with Google over the last year, since releasing for Android, I'm slowly moving away from them and prioritizing iOS. Haven't had to deal with nearly as much bullshit with them.
Please note that you can let people download the .apk from your website (for now!), and although the end user will have to bypass 2-3 scare screens, it's not possible at all on Apple products. (Even after the EU mandated Apple to make this possible and then fined them a few billions for not doing it, Apple still hasn't done it)
At this point, I've also basically abandoned my Google Play apps. I simply cannot afford the time to keep them up to date for no good purpose.
And it's absurd. They were a perfectly sustainable “business” with a single unobtrusive banner ad (no tracking, no permissions aside from internet), that was more than enough to cover server costs indefinitely, for around a million monthly active users. The ad free versions costed $2 but was actually less financially attractive to me (I only created it to give the 1% of users that said they wanted it the option).
They are replaced by apps with full screen ads, trackers and subscriptions.
SECUSO is a shining beacon in the Android app space! Thank you for all your work.
One wishes smartphones was less of a moving target so that the maintenance burden was reasonable. Recompiling all your Windows software every year would seem beyond silly, but here we are.
As of right now, if you want to be able to run new Windows software without risk of being quarantined by Microsoft Defender, it needs to be signed with a Microsoft-issued certificate.
Requiring periodic updates is not out of the question for Windows apps in the future perhaps with an exception enabled via group policy that's only available for Enterprise versions of Windows, and must be set for each and every individual .exe and .dll.
Same thing happened to all my apps. 10 years of games removed due to policy updates that I just couldnt rebuild quickly. Ended up hosting the APKs on my site. Self contained, no third party services but still failed checks.
I am in a similar situation and my solution was to switch to PWAs.
I translated the apps from Java to Dart and rolled my own UI with straight forward HTML.
My apps do not use notifications which seems to be an issue with PWAs.
A real downside for me is the lack of a simple i18n story and
I will likely roll my own.
On the plus side:
* PWAs can be easily packaged into an APK using:
https://www.pwabuilder.com/
* my apps can now be used on IOs and regular web browsers
Google has become more structured and strict in their mobile dev program but still much easier go cope with than Apple when exception handling is required. Apple fails in many fronts in these matters.
Hello. I see you're trying to log into some shitty website that somehow survived 20 years of changing internet. Probably you don't even know what email you used for registration, but there's a chance that some variation of your "all-websites password" will work. Maybe. The catch though is that you have 5 tries, after that your IP gets banned.
Don't shit your pants. The IP ban doesn't actually work.
On a somewhat related note, I am the founder of a company that relies on integrations with 3rd-party systems. Good luck building for Google, Shopify, Slack, etc without going though absurd number of requirements and sacrificing hard earned revenue just so that your own customers, the one you have managed to acquire yourself (not acquired through the market places of the said channels) can use your product on these platforms.
As a result, we've opted not to list our product on marketplaces in general. Instead, we support custom integrations directly with our customers.
I've also been burned in the past by Apple, Chrome, and Mozilla.
I understand that all of these companies run business and I understand that there are legitimate security and privacy concerns (I used to lead security teams, so this issue is close to my heart), but even so, these platforms often fall short of being truly developer-friendly, especially toward legitimate builders trying to create value - especially when this value is created outside of the said marketplaces.
I don't particularly agree with Epic's victory in the Google/Epic case, but the one thing I hope it accomplishes is to convince those in charge of the Play Store that it's finally time to have developer-friendly policies (otherwise someone else will). Play Store policies constantly virtue signal about security and privacy while continually making it harder for developers to release high quality apps.
These apps are great. They do exactly what it says on the tin. Pity to hear this, now people will have an even harder time getting nonshit bloatware from the Play store.
Good. Developers should follow suit. Each day I blame myself for having got into what the industry has become: a digital sisyphean nightmare. Either update or die.
not a developer here, but doesn't somebody make a service that can just "update" the app every day by moving functions around in the make file or something? Pointless rules deserve pointless solutions.
Let's count the days until someone builds an AI solution that does just that and adopts existing apps to the new SDK without breaking anything or changing functionality.
Anyone already started building this? :-).
Would bring my social RSS reader back to life too. Had the exact same experience others have described here: it's not worth the time investing anymore at some point...
Google's, somewhat difficult to swallow, official reasoning is:
> Android 15 builds on the the changes that were made in Android 14 and extends this security further. In Android 15, apps with a targetSdkVersion lower than 24 can't be installed. Requiring apps to meet modern API levels helps to ensure better security and privacy.
Supporting legacy apps makes no money. Microsoft used to pour pure gold into backwards compatibility, but they stopped once they realized that nobody outside hackernews cares.
It doesn't have anything to do with the people behind the project. It's a universal Play Store policy where developers must run on the treadmill of updating their apps for every new Android version, or they get removed.
I didn't find any noise or whining in the post. The text mentions "effort to keep the apps updated" which is more than just updating the API number. You are frequently requested to adapt the app, the signing process, fill in the ever increasing compliance data. Every request for change is accompanied with a threat.
My app had no privacy concerns, didn't collect any data or even require internet access.
I was still expected to jump through all kinds of hoops every few months. Even after I gave up and my app was delisted I still get regular requests for new hoops they came up with with more threats that they would delist (even more?).
And yes, the app was moved to F-Droid which makes it invisible for just about 100% of Android users. I still think these kinds of posts serve as a good deterrent so others don't invest the effort in the Google Play store. The store is meant for corporations. If you are enthusiast or a non-profit considering the app a one-time investment, it will pester you and wear you down.
> There's plenty to complain about with Google and Android. Massive API changes. But the Play store saying "please ensure you at least checked what happens when we draw the app edge to edge because Android 15 forces it" is not one.
The massive API changes are why it's not just bumping a number. That's the exact core problem
The massive API changes that break apps are tangential to the Play Store.
It's Android itself that's crap, and Fdroid or any other alternative app store isn't going to help on this particular issue. Note that iOS has the same issue.
Fdroid assists in this, as it allows apps targeting any Android SDK version that works.
Play, on the other hand, gives you a year to move to the latest or be banned. And maybe be banned during that 12 months based on heuristics. And maybe be banned once you update the app, because not enough changed.
They have more than 30 apps, not just a flashlight. It's mentioned right there in the post.
Do you really thing these people are complete idiots who can't increment a number? Obviously it's more than that. And the "wHy CaN I TrUSt yOu wITh mY prIvACy" shade throwing is just outright bizarre.
Updates get "tested", but unless it just immediately crashes on launch, this is not a reason for rejection.
Screenshot updates are not necessary (just recommend to improve your rankings), and eventually answering some questions like "do you handle personal information in the app?". There's a few edge cases where you need to prove that you're using a specific permission for good reason.
From a cursory glance, their apps seem to be of the kind that don't need continuous updates and can be considered complete. Self-contained, offline software that serves a specific purpose: https://search.f-droid.org/?q=SECUSO&lang=en
Unfortunately, Google no longer recognizes this as a valid development strategy. If you want to publish on Google Play, you need to continuously release updates targeting an SDK released within the past year[0]. If you don't, they will send you constant warnings about how your app is violating their policies, they might derank your app, and eventually they'll stop making your app available to new users.
Updating the SDK is not that simple and it often introduces new bugs if you don't read through the full changelog and test thoroughly. I have 3 apps and it already feels like I spend too much time each year updating SDK, I can't imagine updating 30.
They talk about how this somehow improves security and enhances user experience, meanwhile this policy worsens user experience by pushing people towards ad-filled apps that have the resources and courage to release needless updates, and they still publish spyware on their store.
[0] https://developer.android.com/google/play/requirements/targe...
I've attempted to make this point to proponents of the walled gardens as a real benefit they are losing. There are app developers that just want to make useful stuff and share it. But Play (and the App Store) are completely designed around developers that are trying to make a living there (because that's how Google/Apple make money off the store). As such, the stores are quite hostile to community built software that changes rarely. This is a real loss, as I think that software is often the best available for a given purpose due to simplicity, privacy, and longevity.
So glad I have F-Droid!
I've had some thoughts in a similar vein, but I was thinking from a privacy perspective. The Google and Apple arguments for the walled gardens basically boil down to "You can't trust other stores to protect your privacy and security", but the obvious counter-argument to that is that other stores may actually be able to focus more on privacy and security than the walled gardens do.
Apple and Google inevitably have limited privacy protections, because they'd probably run off Meta and a bunch of other really popular / in-demand apps and cut into their own bottom-line if they really cracked down. In contrast, a third party store may be more free to only host apps that are more privacy-oriented or have been security audited, etc.
Look, to be blunt about it I think what Apple did to Facebook was a necessary evil, they (Facebook) seemed to buy Whatsapp as purely a way to entrench their network effects, get access to phone numbers and contacts etc, and their data hoovering practices are so severe that they tried to pin their own certificate (or something like that, I'm hazy on the details)
I get the Apple skepticism, I'm not happy with some of what they do, I think it's contentious when app stores ban something like Parler, but fine-grained granularity is something we kind of desperately need
Let's not forget this data hoovering, where they set up some bullshit local http server on Android that lets them track you even in private mode
https://news.ycombinator.com/item?id=44169115#44170000
Arguments in this day and age are soldiers[1], at least when they come from powerful people: (if you're a corporation or a government) they are things you send to fight for you. You don't have to actually believe them, and the most effective ones are often not ones that are true.
[1] https://www.lesswrong.com/w/arguments-as-soldiers
As a counter point - I just downloaded Canabalt from Apple Store, that wasn't updated in 7 years and it works just fine. The oldest app I found (that still had App page) are 10 years old without updates and I see many released in 2011 that I can download but doesn't have app page anymore.
My point is that one cannot make an argument over bad implementation. E.g. Sony is known for pulling down games or even stores for older devices whereas Steam allow people to download games bought decades ago.
It's hard for even developers and small companies TRYING to make a living there. Keeping an app active in the app stores requires a lot of extra overhead, but doesn't add significant value to the product in cases where it's a native cross-platform or browser-based app.
So many of the apps installed on my phone could be PWAs, but since the implementation of PWAs is quite limited - a native app is required in most cases.
Great point, and also: the walled garden operators don't make any money off of free apps, so they don't prioritize supporting creators of free apps. The result is that it becomes unsustainable for most developers to keep a free app on the store.
The incentive structure of walled garden app stores encourages the proliferation of paid apps for everything, including things like an instrument tuner or a notepad app that'd be free in a non-walled garden environment.
Interesting how Web API’s and mobile have gone in different directions. If a web browser breaks compatibility too much then it’s a broken browser.
Compatibility is broken constantly on the web, but it is forward compatibility. This is why most browsers now auto-update to newer versions. Websites then require new features which will result in older browsers being non-functional.
Backward incompatible changes happen - they are more difficult due to lack of communication with/pressure on the sites they will break, and coordination of strategy with other browser vendors. This can actually be quite frustrating, as each browser has their own 1-3 month cadence for new releases and it is difficult to track whether a breaking change is going to land on any given browser soon enough to coordinate a new version of a site.
True, complicated websites need to be tested. But if a web site serves simple web pages then it generally doesn’t have a maintenance burden. (Though, link rot happens to everyone.)
For all practical purposes it works as long as it is Chrome, that is how modern Web development has become.
> "Additionally, the app prevents devices from taking screenshots."
Why do the "security" apps ALWAYS have to have this anti-feature? It's especially annoying when employed by the banking apps.
Famously, Schwab had some issues where it didn't properly keep track of orders during highest loads (people ending up selling more shares than they had even in IRA accounts), yet conveniently they prevent users from taking screenshots of their app, so you wouldn't be able to prove that you did cancel or replace the order and did receive the cancel confirmation, before it executed anyways. Of course, if it's an IRA account, selling more shares than you own, is clearly Schwab's bug, but not being able to keep these things locally, is one of the biggest anti-features of modern apps.
It's a choice that Google made to obfuscate their DRM by calling it "FLAG_SECURE", at the cost of usability and security for everyone else. Just check out this delightful doublespeak: https://developer.android.com/security/fraud-prevention/acti...
> When a window is flagged with FLAG_SECURE, Android prevents screenshots from being taken and prevents the window from being displayed on a non-secure display, such as a TV or projector. This helps to protect the information that is being displayed in the window from being accessed by unauthorized people.
What's a "secure display"? Why, none other than our old friend HDCP: https://source.android.com/docs/compatibility/16/android-16-...
So the docs might imply that "the information" is your banking information, and the "unauthorized people" are, I guess, dudes with binoculars outside your window. But actually "the information" is Netflix and the "unauthorized people" are you.
That's why you can project your OTP codes on a 50-foot wall as long as your projector is HDCP-compliant.
> Why do the "security" apps ALWAYS have to have this anti-feature?
Every pen test I’ve seen for mobile apps has always had this as an item, even when it’s completely unjustified for the type of app. It’s on their checklist and they will always flag it to show they are doing their job. If you don’t have anybody in the team who is willing and able to say no to a pen tester on a security matter, this kind of thing will happen.
Agreed.
I'm the person who enjoys saying no to this kind of thing. Also, we will not disable copy and paste for password fields, and we will not make our users rotate their passwords every 11 days ("because we align with NIST guidelines which say not to do that").
This is exactly how I recognise bad "pentest" firms and tell all my friends and clients the same. If the pentest contains report any mention of [screenshot, obfuscation, root detection, attestation] it's bullshit and you should demand your money back (you won't get it, but still, you should demand it) and tell everyone in your circle to not give another cent to them.
I don't know if anything has changed but 10 years ago I was part of an effort to make the base OS of our product FIPS-compliant. FIPS was both prescriptive and outdated. And it turned out that the changes required to make everything FIPS-compliant actually made our product demonstrably less secure.
But we had to ship it anyway, otherwise a non-negligible portion of our customers could not legally buy our product.
Unfortunately the point of a pentest/audit isn't to do one, but merely to check the box saying you did one, and I'm sure bad ones must be cheaper and still allow you to check the box.
I simply delete and rate 1* any app that doesn't work, including Schwab.
Schwab's mobile website is actually decent, and, basically, works better than their app in every way.
I'm honestly disappointed Android doesn't do something about these broken apps that don't let me keep records of my own stuff.
It should not be possible for an app to prevent screenshot use 100% of the time.
There should also be a 180° on the checklists to flag any app that uses disable-screenshot 100% of the time, similar to how we went from requiring people to change passwords every 14 days, to removing the mandatory-password-change policy in its entirety.
At a previous employer of mine, it was common to share dev accounts for certain things. These were not security sensitive things. They were there purely for dev purposes and these were things like anayltics tools and stuff that the software being built had to integrate with, so they were basically development sandboxes.
Many of these tools had MFA enabled and so it was common to share MFA codes on Slack because the MFA code was sent to an email address that only one person had access to.
One lunch and learn a group of developers shared how they solved this problem by having the MFA codes pushed to a device that was effectively an on-prem server / dev box that they installed custom built software on to take a screenshot of the MFA code and broadcast it on the relevant Slack channel.
The main point of the lunch and learn, however, wasn't so much to share the tool that they had built, but to talk about how they got around the Mac OS security protections that are there to prevent this sort of thing.
My first thought was "we've just written malware."
I'm specifically responding to this sentence of yours:
> It's especially annoying when employed by the banking apps.
After my experience with that MFA code sniffer ... I know exactly why banking apps and other privacy/security-centred apps prevent taking screenshots :)
I fail to see how your conclusion follows from the premise.
Banking apps in the US don't even show any PINs for 2FA, so, why exactly is Schwab doing that again?
BTW, Google Wallet does let you take screenshots of all the views except for just one or two views where you enter card number, billing and card security code. Honestly, even that is an overreach; it's not like I can't use the camera to take a photo of my credit card with CVV in view, so, why should the camera function of any app prevent that again? Google never blocks screenshots of any transactions, last-4 of any card, or any other screens. If they ever did, I'd be far less happy with them, and would go out of my way to find an alternative contactless provider. Wells Fargo used to provide contactless on Android in their app for their own cards, but, probably thanks to Apple, this feature was removed for feature parity with iOS.
You're laser focusing on MFA sniffing, specifically. The point is that malware can take screenshots to harvest information. Your banking information has a ton of sensitive information about you that could be used for a variety of different purposes, such as for identity theft. My point was that making it impossible to take screenshots is trying to protect against the possibility that there is malware harvesting anything through screenshots.
>why should the camera function of any app prevent that again?
Because you taking a photo of it with a physical camera is intentional. Another app on the device screen recording that view may not be intentional by the user.
> Another app on the device screen recording that view may not be intentional by the user.
Given how many permission prompts you have to go through to let any app see your screen, I feel to see how it would be unintentional.
Starting the recording may have been intentional, but the recording of sensitive content may not be. For example Twitch streamers frequently leak their personal information by accident. If that personal information could automatically be blacked out it would save them from trouble.
Not more then for any other app. Android design is such that it intentionally trains users to accept everything.
Yes, more than anything else: https://github.com/cvzi/ScreenshotTile?tab=readme-ov-file#te... Depending on method and version of Android, you have to jump through ridiculous steps to allow screenshots.
Their point was that you have to jump through ridiculous steps to allow anything at all, so users are trained to jump through them.
I feel fairly confident asserting that users are not trained to go through the steps to enable screenshots. Blindly clicking allow is one thing. Going back and forth to enable restricted settings and then grant the permission is quite another. I use a screenshot app, and am pretty technical, and it took me multiple tries and several minutes including having to go read https://support.google.com/android/answer/12623953#allowrest... because Android is so concerned with protecting me.
Not screenshots specifically. Every app requires you to accept a whole bunch of permission prompts.
Yes, by blindly clicking allow. But in this thread we're arguing about specifically problems with screenshots, which are behind much stronger permission gates that can't be blindly clicked through.
Yes. Plus these are not even ridiculous steps, not for capturing the screen.
The bigger issue is users being spammed permission requests in broad categories that you cant deny. Like a headphones needing contacts permission.
Why would headphones need contacts permissions? Where are you getting these headphones from?
I routinely deny permissions to most apps on Android, and never have any issues. In my years of using random apps, the only app I'm aware of, which doesn't work without permissions, is Capital One banking app, which refuses to work unless it gets the phone permission. So, I just 1-star Capital One in the Play Store, uninstall as defective, and move on.
BTW, where are the permission screens on iOS? Or is the blissful ignorance more secure than being able to click "deny" a few times?
Surely you're talking about Apple's design, no?
With Android, I routinely prohibit random app permissions from many apps, and everything still works just fine.
Does Apple even let you have as fine of a control of permissions as you can have on Android?
Yes, but that can be simply solved by the banking app to re-ask for the PIN instead of directly declining to take the screenshot.
If it asks me again my PIN when I'm about to hit "transfer" when sending money, there should be no problem in doing the same for the screenshot.
Instead at least my banking app forces me to navigate through an unfamiliar menu and donwload a PDF. A waste of time compared to taking a screenshot.
Some do that, and it's super annoying. I take a screenshot, and then silently my login doesn't work, with a weird error returned instead. Get another PIN, type it in, take a screenshot before submit, again get a nondescript error that makes no sense.
Don't they star the PIN in any case?
Why exactly is me taking a screenshot of my signup process for my records suddenly a disqualifier for signing up?
If all these companies never lied to us about the terms of the deals we're signing up for, needing proof of what actually happened, we'd never be taking these screenshots.
Honestly, this whole "security" theatre ought to be investigated by the consumer protection agencies, and any app that prevents screenshots being taken, or gives these nondescript errors when someone takes it and is subsequently unable to sign-in, should be fined for their anti-consumer behaviours.
I replied to someone else with the same response. I'll repeat it here. The point of my reply wasn't to do with MFA codes, specifically, but the fact that MALWARE can take screenshots in order to harvest things, such as MFA codes or anything else. Preventing screenshots is likely, in my opinion, a defence against malware harvesting anything that way. Your online banking can present a lot of sensitive information visually that could be used for things like identity theft etc.
And yes, there are other ways that malware can harvest information and if your device has been root-kitted you're screwed no matter what. But the fact that there are 100 ways to attack you doesn't mean the banks don't see value in trying to prevent 50 of them.
I've gone off Schwab big time over the past year.
a) I cancelled my "intelligent advisor" accounts (which was a pain to do by itself) and had the money xferred back into regular IRA accounts. After this was complete, I was no longer able to see any trade history for the past 12 years of those Intelligent Advisor accounts, *even though they were ostensibly backed by regular Schwab IRAs*, and my historical "wealth" tracking in Schwab made it look like I'd simply never had the $NNN^n that was in those accounts for that period of time, or in other words as if I'd added $NNN^n to my accounts on the day of the transfer. Definitely some hackery there. I had one Schwab rep who acknowledged this as a (rather severe) problem, but the other 3 I spoke to did not even understand why it was an issue.
b) For an example of their approach to data in general, take a look at their historical chart for the WEED ETF around the time of the reverse split in 2023, and compare it to how WEED themselves chart it, and how Fidelity charts it. Schwab's presentation of the price history isn't justifiable, and essentially omits information. (https://www.schwab.com/research/etfs/quotes/summary/weed, https://www.roundhillinvestments.com/etf/weed/, https://digital.fidelity.com/prgw/digital/research/quote/das...). Their support brushed this off.
That's a very shallow protection. Even if one has no other camera (phone, table, a real camera) there are always friends and relatives that can help and take a picture of the screen. Furthermore a picture of the screen and the phone around it has a more real feel than a screenshot that could be photoshopped.
A screenshot develops evidence of something happening or not happening according to the person who took the screenshot.
If you start claiming that it can be photoshopped, well, what prevents anyone from photoshopping a real camera shot? Or photoshopping a screenshot, and then taking a "real" shot with a camera? With AI, you can now even do this with video, too.
For practical purposes, your suggestion is simply unrealistic. It's unrealistic to be using a second phone to be taking random confirmations from your main phone, and it's even more unrealistic if you're doing trading where every second counts, and where the whole reason that Schwab cannot execute properly, is because orders are placed and cancelled than once. It's even yet more unrealistic because of focus and angle issues, and reduced precision, and increased file size etc.
BTW, I have personally encountered this consistency bug at Schwab Brokerage. I wasn't even using Schwab's app, precisely because it doesn't let you take screenshots. In my case, the loss was not major, and not worth pursuing.
But other people reported that their IRA accounts sold shares short as a result of this consistency issue, which is kind of a problem for everybody when you cannot buy it back if it has 10x'ed since the sale like GME once had, and cannot even add any more money even if you have it, because it's a tax-advantaged account with limits on how much you can add each year.
Yeah, SDK updates are a pain. I wrote ChromaDoze in 2010 so I've gone through several. Recently, the most annoying changes were:
- Foreground services used to require a persistent notification, now they're not allowed to have a notification unless you prompt the user. So I added a button to beg for POST_NOTIFICATIONS permission, but now permission can be granted after the service starts, so I had to build some magic to make the service refresh its own notification.
- Gesture navigation steals user input when swiping on the left/right edges of the screen, so I had to build some magic to automatically make my UI narrower when gesture navigation is enabled. Drawing apps can't really use setSystemGestureExclusionRects() because it's limited to 200dp.
- By default, apps now render edge-to-edge vertically, behind the semi-transparent status bar and bottom navigation buttons, so I had to build some magic to avoid those areas.
Now that gesture navigation is the default, many developers aren't testing with 3-button navigation, so I've noticed apps where I can't interact with the bottom because it collides with my navigation buttons.
> - Gesture navigation steals user input when swiping on the left/right edges of the screen,
Well I've seen even 1B+ dl apps failing to handle that (on a Google Pixel), so at this point I'm putting the blame on Google. I've switched back to three button navigation. Though even some trivial OS gestures like screen unlock fail reliably on my Pixel 6a. (As in, I do the gesture, it fails to register the gesture, i try to make the gesture "with more conviction" through the whole screen and it still fails, and after few minutes it ends up okay somehow)
> I've switched back to three button navigation.
I've been using it since forever, but recently noticed that the latest update broke the back button in certain scenarios I can't figure out yet.
> I've switched back to three button navigation.
Don't worry. Google broke it as well with shitty "edge-to-edge" nonsense to make the apps more "engaging" by forcing them to deal with the disappearing bottom bar. By default.
Just wanted to give my thanks for ChromaDoze. I use it on flights all the time to help drown out noise. A brilliant open source app.
I also share this resentment. It became very hard to have a niche app for a family or a small circle. Not like it was easy before, but amount of time one needs to invest to keep it up to date with requirements is not sustainable. Web apps are also a hard thing once you consider hosting and storage expenses.
If you have an app for a small restricted audience, it shouldn't need to meet Play Store requirements, just basic Android ones.
I think both of you and TFA misunderstand what the targetSdkVersion is.
If your app barely uses any permissions (like TFA's apps), you just need to update the targetSdkVersion in the manifest once per year and push the update. That's it. You're not updating SDKs or compiling against a newer SDK or anything.
It's not that simple. If it were that simple Android Studio wouldn't show you a big red error when you do that and they wouldn't have built an entire assistant for the purpose of incrementing a number[0]. The reason is that bumping the targetSdkVersion changes various behavior, sometimes in a breaking manner. A good recent example is that 34 -> 35 will force edgeToEdge rendering on all activities unless you opt-out per-window (and 35 -> 36 removes the opt-out). So simply doing what you said would probably lead to UI elements appearing behind the nav/status bars and the app being unusable (on API 35+ devices, from my understanding).
[0] https://developer.android.com/build/sdk-upgrade-assistant
You do need a newer SDK to update the target-sdk-version though. And you may find that libraries you used are not compatible, unless you update them, and updating them may break things. Maybe for a minimal app in pure java or kotlin this won't be a problem.
There was an open-source app that hasn't been updated in a few years that was delisted from the store. I decided to try my hand at recompiling to target latest required sdk "target" or whatever. It used Xamarin / C# and some additional libraries. It does not talk to the internet, it's just a minimal remote-control and data-logger for a bluetooth multimeter. If you can find a copy of the last APK published and sideload it, it works. But if you try to update the SDK so you can target the required SDK version for the Play Store, compile fails, misc cryptic errors due to libraries. Updating libraries was tricky for me because while I'm quite familiar with C, C++, Python, Go (etc), I'm not at all familiar with Android, Java, Kotlin, nor C#, visual-studio, etc. After a few days of struggle I managed to update libraries and fix the build, but the app's layout was totally broken, only one button appears (and again I'm not familiar with any of this stuff).
This app really didn't need any updates. It's a < 20MB app to control a local device, and it still works. At least you can still side-load it. Sheesh.
> You do need a newer SDK to update the target-sdk-version though.
No you don't.
You probably should just use an older version of Android Studio for your case which supports the original compileSdkVersion from the original gradle build. Then update the targetSdkVersion in the manifest and that's it.
While you are technically correct (the best kind of correct), official guidance is to use support libraries that are at least as new as the targetSdkLevel, so if you follow that recommendation you still have to update.
Also, I try to at least do the bare minimum level of testing the app still works after rebuilding by launching the app in the emulator once (I don't usually have a phone that runs the newest API level), which means downloading at least a new emulator image.
In practice it's just easier to update the entire platform.
> If your app barely uses any permissions (like TFA's apps), you just need to update the targetSdkVersion in the manifest
And what if you do use permissions for stuff like, say, external storage access, don't you need a recent SDK so you can use the APIs for things like the run-time permission requests now mandatory? But I believe the Android SDK removed support for building with ant years ago. And lets say I'm using a legacy framework with an incredibly contrived ant- (and bash-)based build system which there's no way I'm rewriting. Therefore, I'm in big trouble, am I not? Honest question.
Runtime permissions where introduced in 2015 with Android 6.0 (SDK 23).
So you indeed need to use a new enough Android Studio and compile against SDK 23. You need to use the new API, I think the easiest way is to add a button and call requestPermissions() [1], you can leave the rest of the code unmodified.
Also, note that Google Play does not allow the external storage access permission except if it's a file manager app. It's better to use the SAF API (since Android 4.4 SDK 19) instead. Depending on your app, that may need bigger changes.
By the way, I'm working on a syscall interception framework[2] that could in theory intercept the file io syscalls and redirect them to use the SAF API. That would need only minimal changes to your app and also would allow to run things like syncthing unmodified.
You need to make these changes anyway, because Android 14+ can not install apps with targetSdkVersion < 23.
[1] https://developer.android.com/training/permissions/requestin...
[2] https://github.com/lukasstraub2/intercept-anything
I find this kind of posting deeply ironic, since HN and ArsTechnica has been ripping Android a new one before this policy came into effect for allowing apps to exploit old APIs for stealing data, triggering popups, spamming notifications and many more changes that have been done from there. Many praises were sung to superiority of iOS and their demand to keep up to date with new policies and even new design.
And now we hear complaining again over things like... (a few posts lower)... having to implement permission dialog to show notifiactions? Right :D
The reality of the situation is that without required SDK changes, every single app - from your banking app to every game - would STILL demand access to all your files, all your documents, all your photos (and their locations) before they run. And then proceeded to spam you with notifications from background trying to sell you crypto.
Fixing those things unfortunately means that also the opensource developers need to move their behinds and implement APIs in a way that respect users more.
So just don't let developers push updates targeting old SDKs? Show a scary permission dialog on every app launch for dangerous permissions? Delist only the apps that actually use or at least register those permissions?
There are many possible solutions and none of them are "you have to recompile once per year or we ban you".
Ehm, that's EXACTLY what happens now.
Noone is being banned because of this. You can't publish an update if it targets old Sdk and old sdk targeting apps don't appear to users (unless the user has already installed that app before).
That's it. Google is directly following your recommendation. Developers have usually more than a full year to comply (e.g. Android 16 has just released, developers will have to target Android 15 at the end of August. Android 15 beta was released around march 2024 giving developers ability to prepare and test).
What part of what I said suggested "old sdk targeting apps don't appear to users (unless the user has already installed that app before)" would be fine?
If the app works and doesn't do anything bad, there's no reason to delist it.
But the app is doing something bad - it has access to data it shouldn't have.
Unless you're saying that you solved the halting problem and can guarantee and verify that apps that still have all access to your data (because permissions aren't enforced) will NEVER in ANY codepath read data they don't need - you can sell that solution to Google Play then.
Sites like HN are different people with different opinions posting different views, so of course some of that will conflict. I don't get why this staggeringly obvious fact needs to be explained over and over again...
And beyond those things there are often performance / battery optimization related things as part of the update too. Just because an app claims it respects your privacy, it doesn't mean that it is a well behaved app.
Most other android app stores enforce a high target sdk. Fdroid is the only one I know that doesn't and allows apps as far back as Android supports. Android has been yearly, except Android 16 it seems, raising the minimum installable target sdk so eventually updates will be needed to run on new devices.
Also, those new SDKs make slightly older Android versions not work anymore with the updated applications, in some cases. My main Android tablet can't get updates for several apps, and some apps are updated but won't work with e.g. Chromecast anymore (and were updated _only_ because of the nag-system of Google, there are no changes in the apps themselves).
And going to the latest Android version isn't an option, that would imply buying a (at these times Really Expensive) new tablet, and what's offered now aren't even covering what I want from a tablet. Of course, if the vendors continued to provide updates to tablets and phones.. but they don't.
Totally agree - I have a platform with an app which hardly changes but I constantly need to do maintenance which doesn't help my platform or is a gain for my users.
Saving grace is that it’s possible to sideload or use an alternative App Store.
Android has matured past a point of diminishing return, you can stay on an Android version 6 versions behind and not miss anything.
This page also has the list of apps, and each app has their own detailed description page: https://secuso.aifb.kit.edu/english/105.php
Not exactly constantly update, in past 4 years it was only 2 or 3 required updates to rebuild with latest SDK.
I hope this push from Google (and also from Apple) forces us, the developers, to create and most important USE the alternatives.
The F-Droid app store app is usually already the first app I ever install on any Android device:
https://f-droid.org/
The second app is often the Aurora Store app store app, from within the F-Droid app, which then lets you install Google Play apps without having to have a Google Account:
https://f-droid.org/packages/com.aurora.store/
With these two apps installed first, on any Android device, whether locked or not, without any need for any computer or any other device, without having to type-in any Google Account details, you can then do pretty much whatever you require on the device, including installing bank apps, Amazon, Amazon Music, Audible, Prime Video, etc.
Sadly, iOS has no alternatives like this. Apple proudly reports terminating 128,961,839 customer accounts in 2024 (yes, Apple has terminated 129 million customer accounts in just one year), and they do NOT allow using an iOS device without an Apple customer account:
https://www.apple.com/legal/more-resources/docs/2024-App-Sto...
How do you even get to the point of installing F-Droid without first setting up Android, which, in my experience, requires a valid Google login.
When I set up my Android device, there wasn't an option to set it up without a Google Account.
There's always a "later" or equivalent button in all of these setups, sometimes it does have a few prompts.
I personally have iPhone, Google Pixel, OnePlus, Motorola and Samsung devices, without any accounts on them. The iPhones are very limited without an account, obviously, but I never feel that way on Android.
All that I did to set them up, is click on the screen a few times, no extra tools or anything. Then just go into the browser, and follow the instructions for F-Droid installation; which can be done entirely on the phone, without a computer or any other phone, or any username/password.
For my Motorola, the "later" or equivalent did not appear if you connected to WiFi during setup. You have to have no network connection, first, to not have a Google Account.
That's not normal, that will probably be the vendor skin you use enforcing that. Maybe samsung, as they tend to try and be apple at home.
I have a Samsung phone and I was never forced to use a Google account.
Whenever I buy a new Android device I take the opportunity to pretend I'm a grandma getting her first piece of technology and create a brand new Google account, since it's one of the only signup pathways that doesn't require some kind of identity verification.
That's a nice trick to get a fresh Google Account without any verifications!
But why would you need so many Google accounts? I think at one point it may simply become cumbersome to keep track of all the accounts, so, using an account-less Aurora Store seems like a very easy pathway to take.
I honestly never feel disadvantaged in any way by not having a Google Account on my Android. Aurora Store works, Google Maps works, banking and streaming works, everything just works.
When something important requires a Google account, now you have a burner account you can use. If you somehow have so many you can't keep track of them then great, you can use one account for one thing. If you only have two or three, at least you can make correlating them harder - the perfect's the enemy of the good. (I expect that if you log into more than one on the same Google phone, Google internally marks them as related. Still, other apps don't have access to that fact.)
I usually expressly don't login into any account because I simply don't want to remember which device I've logged which accounts in. It's just easier that way.
On my main device, I'd use a regular Google Account. But if I'm getting a test device, or a device I simply play around with, it doesn't have to have a Google Account, and yet it can still have all the apps I'd ever want.
Unlike with iOS, where you're severely limited in trying out a device without having an Apple Account. Yet somehow it's Apple that's deemed to respect people's privacy, go figure.
> Top 10 guidelines or DPLA provisions cited for removal > 1. Guideline 4.0 — Design: 42,2527
Does that line item mean that Apple is rejecting the largest body of apps for not meeting the design guidelines? Man... if I had a penny for every app still on the App Store that blatantly disregards the human interface guidelines...
Honestly, thank you for this. I'm going to do this on an Amazon Fire Tablet I have lying around.
It's such bullshit. Having been fed up with Google over the last year, since releasing for Android, I'm slowly moving away from them and prioritizing iOS. Haven't had to deal with nearly as much bullshit with them.
Sorry to inform you that Apple has the same bs:
https://appleinsider.com/articles/25/07/15/developer-angry-t...
Please note that you can let people download the .apk from your website (for now!), and although the end user will have to bypass 2-3 scare screens, it's not possible at all on Apple products. (Even after the EU mandated Apple to make this possible and then fined them a few billions for not doing it, Apple still hasn't done it)
At this point, I've also basically abandoned my Google Play apps. I simply cannot afford the time to keep them up to date for no good purpose.
And it's absurd. They were a perfectly sustainable “business” with a single unobtrusive banner ad (no tracking, no permissions aside from internet), that was more than enough to cover server costs indefinitely, for around a million monthly active users. The ad free versions costed $2 but was actually less financially attractive to me (I only created it to give the 1% of users that said they wanted it the option).
They are replaced by apps with full screen ads, trackers and subscriptions.
SECUSO is a shining beacon in the Android app space! Thank you for all your work.
One wishes smartphones was less of a moving target so that the maintenance burden was reasonable. Recompiling all your Windows software every year would seem beyond silly, but here we are.
As of right now, if you want to be able to run new Windows software without risk of being quarantined by Microsoft Defender, it needs to be signed with a Microsoft-issued certificate.
Requiring periodic updates is not out of the question for Windows apps in the future perhaps with an exception enabled via group policy that's only available for Enterprise versions of Windows, and must be set for each and every individual .exe and .dll.
Same thing happened to all my apps. 10 years of games removed due to policy updates that I just couldnt rebuild quickly. Ended up hosting the APKs on my site. Self contained, no third party services but still failed checks.
I am in a similar situation and my solution was to switch to PWAs. I translated the apps from Java to Dart and rolled my own UI with straight forward HTML.
My apps do not use notifications which seems to be an issue with PWAs. A real downside for me is the lack of a simple i18n story and I will likely roll my own.
On the plus side: * PWAs can be easily packaged into an APK using: https://www.pwabuilder.com/ * my apps can now be used on IOs and regular web browsers
For context, something similar happened to an iOS game: https://appleinsider.com/articles/25/07/15/developer-angry-t...
Google has become more structured and strict in their mobile dev program but still much easier go cope with than Apple when exception handling is required. Apple fails in many fronts in these matters.
What is the partial derivative symbol doing in their email address (last line of the page)?
It's to fool primitive scrapers looking for e-mail addresses with the @ symbol. It's handled like that on the entire KIT website.
This can't be it because on mouseover I get the mailto: link with the @ symbol in it.
Contradictions like that are common. A popular example:
* Failed login: I can't tell you if the username/email or password was wrong, since that'd reveal if the the user exists
* Failed signup attempt with existing username/email: Cannot create an account, because a user with that username/email already exists
Hello. I see you're trying to log into some shitty website that somehow survived 20 years of changing internet. Probably you don't even know what email you used for registration, but there's a chance that some variation of your "all-websites password" will work. Maybe. The catch though is that you have 5 tries, after that your IP gets banned.
Don't shit your pants. The IP ban doesn't actually work.
On a somewhat related note, I am the founder of a company that relies on integrations with 3rd-party systems. Good luck building for Google, Shopify, Slack, etc without going though absurd number of requirements and sacrificing hard earned revenue just so that your own customers, the one you have managed to acquire yourself (not acquired through the market places of the said channels) can use your product on these platforms.
As a result, we've opted not to list our product on marketplaces in general. Instead, we support custom integrations directly with our customers.
I've also been burned in the past by Apple, Chrome, and Mozilla.
I understand that all of these companies run business and I understand that there are legitimate security and privacy concerns (I used to lead security teams, so this issue is close to my heart), but even so, these platforms often fall short of being truly developer-friendly, especially toward legitimate builders trying to create value - especially when this value is created outside of the said marketplaces.
I don't particularly agree with Epic's victory in the Google/Epic case, but the one thing I hope it accomplishes is to convince those in charge of the Play Store that it's finally time to have developer-friendly policies (otherwise someone else will). Play Store policies constantly virtue signal about security and privacy while continually making it harder for developers to release high quality apps.
I get apps only from F-Droid, so this is fine.
These apps are great. They do exactly what it says on the tin. Pity to hear this, now people will have an even harder time getting nonshit bloatware from the Play store.
Good. Developers should follow suit. Each day I blame myself for having got into what the industry has become: a digital sisyphean nightmare. Either update or die.
Agreed, and iOS devs should follow suit too. If the store you're distributing with isn't the best option for you, you should find a better partner.
not a developer here, but doesn't somebody make a service that can just "update" the app every day by moving functions around in the make file or something? Pointless rules deserve pointless solutions.
Let's count the days until someone builds an AI solution that does just that and adopts existing apps to the new SDK without breaking anything or changing functionality.
Anyone already started building this? :-).
Would bring my social RSS reader back to life too. Had the exact same experience others have described here: it's not worth the time investing anymore at some point...
Each new Android SDK has breaking changes to the API. All of them break compatibility.
Oh, nice. So they break it because they don’t care about devs…or they break it to test which apps are active enough to still get paid.
Google's, somewhat difficult to swallow, official reasoning is:
> Android 15 builds on the the changes that were made in Android 14 and extends this security further. In Android 15, apps with a targetSdkVersion lower than 24 can't be installed. Requiring apps to meet modern API levels helps to ensure better security and privacy.
Supporting legacy apps makes no money. Microsoft used to pour pure gold into backwards compatibility, but they stopped once they realized that nobody outside hackernews cares.
No issue is that with new Android versions, it wont work.
Meanwhile every ad my elderly family members get while playing some dipshit game on android is a literal scam and has been for ten fucking years...
"Malware detected" yeah I know where, too.
[flagged]
It doesn't have anything to do with the people behind the project. It's a universal Play Store policy where developers must run on the treadmill of updating their apps for every new Android version, or they get removed.
[flagged]
https://secuso.aifb.kit.edu/Team_Volkamer.php
> Prof. Dr. Melanie Volkamer is a full professor at KIT in the Department of Economics and Management. She leads the SECUSO research group.
[flagged]
[flagged]
I didn't find any noise or whining in the post. The text mentions "effort to keep the apps updated" which is more than just updating the API number. You are frequently requested to adapt the app, the signing process, fill in the ever increasing compliance data. Every request for change is accompanied with a threat.
My app had no privacy concerns, didn't collect any data or even require internet access. I was still expected to jump through all kinds of hoops every few months. Even after I gave up and my app was delisted I still get regular requests for new hoops they came up with with more threats that they would delist (even more?).
And yes, the app was moved to F-Droid which makes it invisible for just about 100% of Android users. I still think these kinds of posts serve as a good deterrent so others don't invest the effort in the Google Play store. The store is meant for corporations. If you are enthusiast or a non-profit considering the app a one-time investment, it will pester you and wear you down.
> There's plenty to complain about with Google and Android. Massive API changes. But the Play store saying "please ensure you at least checked what happens when we draw the app edge to edge because Android 15 forces it" is not one.
The massive API changes are why it's not just bumping a number. That's the exact core problem
The massive API changes that break apps are tangential to the Play Store.
It's Android itself that's crap, and Fdroid or any other alternative app store isn't going to help on this particular issue. Note that iOS has the same issue.
Fdroid assists in this, as it allows apps targeting any Android SDK version that works.
Play, on the other hand, gives you a year to move to the latest or be banned. And maybe be banned during that 12 months based on heuristics. And maybe be banned once you update the app, because not enough changed.
They have more than 30 apps, not just a flashlight. It's mentioned right there in the post.
Do you really thing these people are complete idiots who can't increment a number? Obviously it's more than that. And the "wHy CaN I TrUSt yOu wITh mY prIvACy" shade throwing is just outright bizarre.
Aren‘t updates reevaluated by Google.
So it‘s not just a simple rebuild and an upload but Google wants certain screenshots of the app and all kinds of additional information
Updates get "tested", but unless it just immediately crashes on launch, this is not a reason for rejection.
Screenshot updates are not necessary (just recommend to improve your rankings), and eventually answering some questions like "do you handle personal information in the app?". There's a few edge cases where you need to prove that you're using a specific permission for good reason.
Too bad there's no downvoting on HN.
There is, it's unlocked with enough karma
There is, for users with at least 501 karma[1].
[1] https://github.com/minimaxir/hacker-news-undocumented/blob/m...
Good to know, thanks!