alexey-salmin
9 months ago
> And even if you don’t want to update the app, Google will eventually start hiding apps from users if the app doesn’t target some minimum API version. This means you can’t just publish an app and leave it at that; it’s several days of work per app per year to keep up with the latest rug-pulls from Google.
That's something I just can't understand. If the old API is insecure or whatever, then surely the OS can put some sort of a secure emulator sandbox around old apps. You can run 35 years old NES games but not a 5 years old app? This doesn't make sense.
I never particularly liked Microsoft but userspace compatibility is something they got right and Google got wrong.
aniviacat
9 months ago
Take for example an old gallery app that request complete file access.
Now the new API adds fine-grained access and removes complete access.
What are they gonna do? Give the old gallery app fake file access, making it completely useless?
This would make for a very bad user experience. It works for emulators, because noone expects emulators to be well integrated with the system. But it doesn't work for native apps.
Many features cannot be preserved. They could preserve some features, but doing so would result in some weird 50% support for old APIs, which wouldn't be great either.
In my view, dropping old APIs entirely makes sense.
> I never particularly liked Microsoft but userspace compatibility is something they got right
With the result of having absolutely zero sandboxing.
londons_explore
9 months ago
> Give the old gallery app fake file access, making it completely useless?
Yes. When any API is used for the first time, pop up a toast saying "this legacy app is trying to use File Access permissions. [Allow access to whole device] / [ Restrict to apps own files ]".
If the user hits 'allow', grant the legacy API. If the user hits 'restrict', give a fake filesystem.
The dialogue box should be provided by the OS, and if the threading model doesn't allow pausing the app to wait for user interaction, simply kill the app to ask the question, and restart it with the permission.
parl_match
9 months ago
Except that legacy app owners regularly get offered money by bad actors, to purchase the apps and take over. Which means that anyone who "Allow access to whole device" suddenly gets a malicious update that cryptolocks them or steals their files.
Real scenario, real problem, semi-common attack vector. Enough that it's a serious problem for Google.
alexey-salmin
9 months ago
You don't have to give access to whole device. Ask the user what he wants to share, then present the app with a skeleton directory tree where only allowed parts are visible. App can as well think that is has a "full access" whatever that means, it's a matter of terminology.
growse
9 months ago
Most users will click on the option that they think will lead to the fewest number of future prompts.
alexey-salmin
9 months ago
Yes, but it has nothing to do with API versions.
If the new API can give a sensible way to restrict file access without too many prompts, then the old-over-new API layer can do exactly the same.
growse
9 months ago
How can the new API know this?
You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.
The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.
This stuff is highly non-trivial.
alexey-salmin
9 months ago
> You've got an old app that uses an API that assumes full access to the device. A new API that restricts that access _cannot_ just guess what the app actually needs / uses - the only sane thing to do is to ask the user what the app actually needs.
No. It knows which actual paths the app tries to access. They can be grouped into exactly the same permission bundles (access to camera images, access to downloads etc) which are used for newer apps. Then presented to the user for approval, like they are with newer apps.
The only difference is, you may not get all permission popups at once -- but that's already the case with many newer apps. They only ask for permissions to e.g use camera when you actually need it. And I like it so much better than the old approach when the apps would refuse to run without camera even though I don't need this particular feature.
> The problem there is that the user is not incentivised to precisely curate the permissions boundary of the app, they're incentivised to _make the damn popup go away_.
Right, and exactly the same problem applies to new apps natively built against the new API. The app can request unreasonably wide permissions and the user will make the damn popup go away. It's not relevant to the problem of maintenance of old apps.
out_of_protocol
9 months ago
Except tou can't upload new app version targeting old API version
exe34
9 months ago
updates have to use the new api. boom.
dietr1ch
9 months ago
But will implementing this secure you a promo? What about saying that most apps migrated to the newer and safer api for users?
Also, TBH dev convenience is secondary to user safety
alexey-salmin
9 months ago
How about user convenience? I'm pissed off that I can't install Euclidea for my kids and it's from 2020, not from 2000.
And anyway it's a false dichotomy. If the old API is implemented on top of the new API then it can be as safe as you want it.
user
9 months ago
bambax
9 months ago
>> I never particularly liked Microsoft but userspace compatibility is something they got right
> With the result of having absolutely zero sandboxing.
With the result of having useful machines that do useful work, instead of toys that "protect" users and prevent them from ever doing anything interesting.
slau
9 months ago
Doesn't the operating system show you a prompt to show which files you want to give the app access to? From the app's perspective, nothing has changed. It gets a handle to a directory and can list files in it. Whether that directory contains 1 or 10000 items makes no difference.
Just to be clear: I don't disagree with you. I think it's completely normal to have APIs be deprecated, and this means eventually your app will break and be removed from the store. I just don't think this specific example was entirely justified.
xprn
9 months ago
For the file system, the OS could do something similar to what iOS is doing when you want to share a picture - giving the user control over which pictures the app has access to. Yeah, for a gallery app it could render the app quite useless because of the UX, but it would solve the issue itself IMO.
ristos
9 months ago
> Now the new API adds fine-grained access and removes complete access. > What are they gonna do? Give the old gallery app fake file access, making it completely useless?
Can you elaborate on your example here? Couldn't they just do something like replace oldGalleryAppOpensOrWritesToAnyPlace() to askPermissionsForWhichFilesAndFoldersCanBeWrittenTo() or ifSensitiveDirIsNoLongerAccessibleAskPermissionOnWhichFolderToUseForCompat() ?
shaky-carrousel
9 months ago
They could intercept file access to common folders, showing you a pop up with the files you would like for the app to see and show only those files to the app.
seba_dos1
9 months ago
> Take for example an old gallery app that request complete file access.
This applies even to apps that don't request any permissions. I have some plain OpenGL games there and they still require this useless maintenance for them, which I'm probably won't be bothering with anymore.
alexey-salmin
9 months ago
> Many features cannot be preserved
Could you present a concrete example, outside of the "system configuration" apps? These are expected to break as the "system" moves on.
I fail to see though why 100% userspace apps that often have no permissions whatsoever can't be maintained.
lordnacho
9 months ago
Sure, but why is the API still changing now, after nearly two decades? It should be more or less locked down whether you do "file system is a free-for-all" or "every app is sandboxed".
I don't think people are complaining about API deprecation being a thing, either. They complain about it being a thing that happens too often.
johnnyanmac
9 months ago
>I never particularly liked Microsoft but userspace compatibility is something they got right and Google got wrong.
they both have their ups and downs. Windows 11 still has parts of the base OS that feel like they never updated from XP. and I'm sure there's a lot of legacy cruft that ultimately slows down the boot process or many low level OS management. you add a .lot of cruft to make sure you can support 30+ years of legacy software.
raincole
9 months ago
> You can run 35 years old NES games but not a 5 years old app? This doesn't make sense
If you are willing to fill your phone with emulators of every single version of Android, then yes, you can run any old app. This is how we run 35 years old NES games.
ristos
9 months ago
Would you need every single version of Android? or just a much thinner compatibility layer for deprecated APIs? Newer apps wouldn't be able to use the deprecated API but older apps don't just disappear either
raincole
9 months ago
You can (in some cases), but it's completely unrelated to "we can run 35 years old NES games".
alexey-salmin
9 months ago
It's all related. Emulation, compatibility and compatibility-through-emulation are very old and well-studied topics. The reason why it's not present on Android is because Google doesn't want to, not because they can't.
johnnyanmac
9 months ago
>The reason why it's not present on Android is because Google doesn't want to, not because they can't.
Sad as it may be, I imagine that lack of desire also comes from consumer demand. Most people don't care about running those 15 year old games, so what's the motivation?
For archival's sake, you should be able to seek old APKs and run older ROMS through an android emulator. So the minority of those who care have options.
yjftsjthsd-h
9 months ago
It seems perhaps more relevant to point out that WINE can run 30 year old win32 apps. I suppose that does include code that could be described as emulators for every single version of Windows, but it's less work because Microsoft, for their many other faults, preserves backwards compatibility so old APIs tend to just keep working.
eviks
9 months ago
Even if emulator was the only option, why would you need every single version instead of a few old ones that those older apps use?
2-3-7-43-1807
9 months ago
according to the post you reply to it's anyway not about being able to run an app. it's about not having it listed in the play store. and that won't change even with an older android version.
theshrike79
9 months ago
NES hasn't been updated and upgraded 35 times after the game has been released. That's the difference.
It doesn't make sense to keep supporting APIs only a fraction of the user base needs, progress means leaving some users behind.
bad_user
9 months ago
If apps get removed from the store as a consequence, that's going to be many more users left behind.
It's been mentioned time and time again, but it's worth mentioning again — Windows maintaining backwards compatibility is what maintained its hegemony, as compared to it, Linux and macOS look like hobby projects. For the young as well, because games still run on it, without worrying that Apple will invalidate their library due to not being in the mood to maintain 32-bits APIs.
theshrike79
9 months ago
The US Navy was paying $9M to keep Windows XP updated and patched just for them.[0]
I bet if you pay Apple similar amounts of money per year, they'll keep specific APIs available just for you.
And it's not like updating the app to a new iOS version is a massive undertaking, in most cases it's just a matter of opening the project in XCode, adjusting the OS version, compiling and publishing it again.
[0] https://money.cnn.com/2015/06/26/technology/microsoft-window...
bad_user
9 months ago
I can't speak about iOS, but when I open Steam on macOS, I see more than 2/3 of my library unavailable since macOS Catalina, which entirely ruined macOS for gaming for me. Clearly, updating those wasn't so simple.
And also, it's unreasonable to expect all software projects to need updates, forever. My hammer doesn't need updates.
theshrike79
9 months ago
IIRC this was a switch from 64/32 bit to only 64 bit executable support.
Something that just has to be done, and not doing it has a clear cost.
majewsky
9 months ago
If it "has to be done", then why have Windows and Linux etc. not done it?
theshrike79
9 months ago
Microsoft gets paid to support old versions.
Linux has dedicated people working for free to support the weirdest hardware and software
rini17
9 months ago
Because MS sells to business. They never hesitated to break compatibility to developers and non-commercial users if it won't affect business.
lynx23
9 months ago
All the smartphone vendors do that. I have lost several iOS apps I once bought, because the developer chased to regularily update his app, which eventually killed it.
fsflover
9 months ago
> All the smartphone vendors do that.
Except those selling GNU/Linux phones running desktop operating systems. Sent from my Librem 5.
stackghost
9 months ago
I don't think the Librem 5 is good enough at being a phone to be properly referred to as a phone.
fsflover
9 months ago
It depends on your needs. Far from an iPhone but good enough to be my daily driver.
stackghost
9 months ago
How's the battery management these days?
fsflover
9 months ago
One day in suspend and 4-5 hours screen time. Not much, but usable. Also the battery is replaceable without tools.
exe34
9 months ago
yes, my needs for a phone includes phonecalls and 5G. it's quite a niche to be fair.
fsflover
9 months ago
Phone calls are basically flawless on the Librem at this point. 5G is indeed lacking.
herbst
9 months ago
I always assumed that's their algorithm mostly and not related to the API levels. Apps that stand out most when you open the play store now are often these with heavily inflated user numbers through scummy ads or practice.