Android 14 Set To Block Certain Outdated Apps From Being Installed (9to5google.com) 35
To help reduce the potential for malware, Android 14 will begin fully blocking the installation of apps that target outdated versions of Android. 9to5Google reports: For years now, the guidelines for the Google Play Store have ensured that Android developers keep their apps updated to use the latest features and safety measures of the Android platform. Just this month, the guidelines were updated, requiring newly listed Play Store apps to target Android 12 at a minimum. Up to this point, these minimum API level requirements have only applied to apps that are intended for the Google Play Store. Should a developer wish to create an app for an older version, they can do so and simply ask their users to sideload the APK file manually. Similarly, if an Android app hasn't been updated since the guidelines changed, the Play Store will continue serving the app to those who have installed it once before.
According to a newly posted code change, Android 14 is set to make API requirements stricter, entirely blocking the installation of outdated apps. This change would block users from sideloading specific APK files and also block app stores from installing those same apps. Initially, Android 14 devices will only block apps that target especially old Android versions. Over time though, the plan is to increase the threshold to Android 6.0 (Marshmallow), with Google having a mechanism to "progressively ramp [it] up." That said, it will likely still be up to each device maker to decide the threshold for outdated apps or whether to enable it at all. The report notes that it'll still be possible to install an outdated version of an app "through a command shell, by using a new flag."
According to a newly posted code change, Android 14 is set to make API requirements stricter, entirely blocking the installation of outdated apps. This change would block users from sideloading specific APK files and also block app stores from installing those same apps. Initially, Android 14 devices will only block apps that target especially old Android versions. Over time though, the plan is to increase the threshold to Android 6.0 (Marshmallow), with Google having a mechanism to "progressively ramp [it] up." That said, it will likely still be up to each device maker to decide the threshold for outdated apps or whether to enable it at all. The report notes that it'll still be possible to install an outdated version of an app "through a command shell, by using a new flag."
I like to run old apps (Score:3)
A lot of the best emulators and some other good apps haven't been updated since Jelly Bean or so.
I can't compile my own Android apps. I don't know those languages and don't know how to use the toolchain.
But if I have to do that in order to keep playing Shark! Shark! [wikipedia.org] for the Intellivision on my phone, I might learn how.
Re: (Score:2)
Why hasn't someone made good emulators that run on the latest Android devices and use the latest APIs then?
Although I do wonder what Android APIs the Android version of RetroArch is compiled against and whether it has emulators that are any good...
non updated apps are a big security risk (Score:1)
Re: (Score:3)
Because requiring people to rewrite everything every time an API changes is not reasonable, especially for niche products. That's not computer science.
Come on... half the time breaking changes are made for political reasons. Old software could work for 20+ years because the PC industry wasn't mainstream at that time period. Today, computers are just toys, and vendors don't care if their stuff breaks after 6 months.
Re: (Score:2)
The reason Google is doing this is for security. Either they have to actively maintain those old APIs, or simply disable parts of them and have apps that use them crash. Back then it was rare for apps to handle APIs not working, where as now it's common because the user can randomly deny access to all sorts of stuff.
If the app is open source and useful then someone will probably update the API version. It's not actually that difficult, unless it happens to rely heavily on deprecated functions. I don't think
Re: (Score:3, Interesting)
The real reason they do this is to push the Google Play Store and make life for other stores or people like me who install everything via apk's more difficult.
Re: (Score:3)
The reason Google is doing this is for security.
Either they have to actively maintain those old APIs, or simply disable parts of them and have apps that use them crash.
Of course it is. "Security" is ALWAYS the go-to excuse for EVERYTHING.
In this case there is zero reason compatibility can't be maintained. Managing complexity is what programming is all about. Interface and abstraction is the entirety of what operating systems do. If maintaining ABIs over decades is a manageable no big deal for a Linux kernel implemented using low level systems language spare me the excuses for why all of the sudden its now too much work to keep doing in userland Android.
Back then it was rare for apps to handle APIs not working, where as now it's common because the user can randomly deny access to all sorts of stuff
Permissions sys
Here we go again! (Score:5, Insightful)
OK, many moons ago, I posted about the issues with browsers refusing to support older versions of Java, and how no, when you have over (really!) a million devices with a older version of out of band management, simply refusing to let the end user decide to allow a security exception is shooting your users in the foot.
I fail to see, if there is no technical way to bypass this in Android, how it is any different than the asinine treatment browser users got shoved on them in the past. Folks, not every user's experience and work conditions are something you can arbitrarily decide don't apply in your rubric and lock them out.
Re: (Score:2)
Re: (Score:2)
OK, many moons ago, I posted about the issues with browsers refusing to support older versions of Java, and how no, when you have over (really!) a million devices with a older version of out of band management, simply refusing to let the end user decide to allow a security exception is shooting your users in the foot.
If you really have to use an old version of Java, why not just use (or keep) an older version of whatever browser as well for just that specific use? Presumably on locked down workstations or VMs anyway? I've had to keep older browsers around to support older TLS versions on legacy equipment in the past. Browser was used just for that and nothing else, in keeping with its insecure status.
Re: (Score:3)
Basically what we did with bastion servers and strict firewall rules was exactly what you point out. It's always a headache during security audits as we have to pull the configs on everything to prove our PII, CC, SOX, HIPPA, ect. compliance. I don't do the EU stuff, the folks that do say it's much worse.
Re: (Score:2)
It's just not fair to the entire world of non technical users to increase security risk in any degree whatsoever across now billions of devices, just so you can continue to play some old version of snake in Java or an older OS.
I'm saying nothing of the sort, why do you presume I do? I'm saying that sufficiently technical people should be allowed to assess the security implications. By the way, when I said " over a million", I wasn't joking. It impacted over two million, seven hundred thousand devices in pr
Re: (Score:1)
For zero gain.
The gain was significant, you just can't see it. That is what *I* am saying.
And nothing of real value was lost.
Re: (Score:3)
There IS a way to bypass it. It's right there in TFS:
The report notes that it'll still be possible to install an outdated version of an app "through a command shell, by using a new flag."
Given the fact that, according to Google, malware deliberately targets earlier versions of Android with known exploits, I'm not sure I can really agree that this is an unreasonable policy. Like it or not, smartphones are not just targeting tech-savvy users. They're really targeting the masses, so to me, it makes sense to put policies in place that will protect users from unknowingly installing malware on their devices.
Sure, it's a bit of a pain, becaus
Re: Here we go again! (Score:2)
Re:Here we go again! (Score:4, Interesting)
Sure, it's a bit of a pain
Disclaimer: I'm one of the few crazies that actually builds an AOSP-based GSI for their own devices.
Yes it is a pain. It's yet another hoop to jump through because the almighty Google said "Jump."
As others have already stated, very few people actually sideload anything on an Android device as is. Most that do are of the techie / power user type, and when they do it's just to install something like F-Droid, or to install an older version of an app from before the developer changed to much for the user's liking. There's literally nothing to be gained from this change. Most people will never see nor hear of it. Those that do are already bombarded by scary popups urging them to stay within the sacrosanct auspices of Google. After having to step through multiple settings screens to get to that choice, and having to download multiple split APKs specific to your device's architecture, and finding out what your device's specific architecture is and what architecture the app you want supports, and having to find out what said "architecture" term even means, and having to go through some very shady looking websites to even find the app outside of Google Play. If you still need even more "protection" from yourself, despite multiple warnings and making crap as cumbersome as possible to do, you shouldn't be using any modern device let alone a smartphone. After all, it has a greater intelligence than you do.
As I've already posted it below, I'll be brief here. The linked code change in the article / summary, as of this posting, gives a 404 / Permissions error. But the second I find out what it is, it's going on my revert list for the next AOSP build I do. I already have to make code changes to my phone's ROM just to get call recording apps and microg to work. This is just yet another thing that I'll have to patch out.
Sadly, others will be stuck with this inconvenience. Which is the real threat here. Google loves dictating how your device is going to work for them. They've already shoved as much of the OS as they could into Google Play Services. Effectively locking out users who don't want Google's spying on their devices when microg is insufficient to run an app. They've already taken away the ability to change the user truststore without a non-dismissable scare notification permanently taking up residence on your quick menu. They've already taken away the ability to grant certain permissions to an app that without them is rendered completely useless. They've already taken away the ability to use a custom ROM without breaking SafetyNet (and every stupid app out there that thinks it's protecting anything from a malicious root user.) Hell, depending on how you got your phone, custom ROMs may not even be an option for you despite having full ownership of the device. (I.e. It wasn't a carrier subscription device.) This could easily be the opening salvo against sideloading an app in general, and it should be fought against. Full stop.
Like it or not,
They're really targeting the masses,
Like it or not, the "masses" need to grow the fuck up. I'm fed up with every Authoritarian power grab being justified because Joe Sixpack can't be expected to tie his shoes. If Joe Sixpack really is that far gone, then we need to bring back the asylums. Like it or not, society has to be able to have expectations of it's members. This includes intelligence and the willingness to learn. Especially when public and personal safety is at risk. No, your phone / computer / device isn't smart enough to decide everything for you. That means you have to make up for it bucko. Don't want to? Then don't use it. Plain and simple. Stop expecting that everyone else's ownership rights shouldn't apply anymore because you can't handle your own.
Re: (Score:2)
Seems like you spend a lot of time mucking with the internals of AOSP.
I presume that this precludes you from running any Google apps like Play on your devices?
If so, why not just use a different open source phone and OS instead of a Googlely one?
Re: (Score:2)
Seems like you spend a lot of time mucking with the internals of AOSP.
I presume that this precludes you from running any Google apps like Play on your devices?
If so, why not just use a different open source phone and OS instead of a Googlely one?
I'd love to do that. But iPhones are out for obvious reasons, and the Pinephone still isn't ready for 'daily driver' status - battery life is terrible, MMS doesn't work reliably, and even voice calling can be problematic according to reports I've read. AFAICT that leaves Android derivatives as the only other choice. If I'm wrong, please tell me - I'd be happy to have an alternative.
Just now I have a Samsung with LineageOS on it. I bought the phone refurbished and immediately installed Lineage. From that poi
Re: (Score:2)
Given the fact that, according to Google, malware deliberately targets earlier versions of Android with known exploits, I'm not sure I can really agree that this is an unreasonable policy. Like it or not, smartphones are not just targeting tech-savvy users. They're really targeting the masses, so to me, it makes sense to put policies in place that will protect users from unknowingly installing malware on their devices.
Protecting the sideloading masses is an oxymoron.
Sure, it's a bit of a pain, because practically speaking, any abandoned app is eventually going to be blocked. But at the same time, such an app can also be viewed as a security hazard. It's a pretty classic convenience vs security issue.
Appstores are freemium malware driven races to the bottom with governance resembling the times of antiquity.
It still blows my mind a few people can make these types of value judgments globally for everyone with no debate, no vote, no oversight, no study, no nothing.
Perhaps the computer I'm typing this on should be destroyed by edict of the king for my own "security". The processor and all kinds of hardware is full of known defects and unpatched vulnerabiliti
Re: (Score:2)
I wouldn't have a problem with this if Google had made it easier to update Android versions without relying on cell phone carriers to give a fuck. My Moto g6 (from rhymes with "hack phone") had 9 out of the box, and quickly found an update to 10. This was two years ago, I think Google had just released 11 or 12. My previous phone with them (from around ten years ago) had a version of 4.x and updated to another version of 4.x, so it's not like I was expecting much from them. Still, I thought I read a few yea
One fence at a time (Score:2, Interesting)
to build a walled garden.
In 5-10 years, open mobile OS will be something other than Android and iOS.
Hope someone figures the recipe for K9 mail 5.6 (Score:2)
The newer version is appalling. Idiot developer destroyed his app.
Re: (Score:2)
Move to FastMail. You won't regret it. It's a pleasure to use.
Re: Hope someone figures the recipe for K9 mail 5. (Score:2)
I appreciate the suggestion, but looks like that's an email service, not an app, and the app doesn't do anything like what K9 used to do.
Re: (Score:2)
Re: Hope someone figures the recipe for K9 mail 5. (Score:2)
Last I knew, developer still hadn't restored the multi-account summary page, still was going to remove pop3, still had controls at the top, was still unresponsive to feedback.
Basically it turned from a highly useful app for someone with multiple email accounts to a poor Gmail clone.
So, will it do it politely.. (Score:2)
Or will it knock out the super saiyan out of the outdated applications via a crotch punch like in the movie?
Microsoft (Score:1)
Whoever would have predicted they will end up as the good guys back in the 90s? 20 year old apps run without any tricks, while open source Linux is dead last when it comes to source or binary compatibility. For an average user software freedom also has a practical component and its biggest advocates have falling short in supporting that.
commentsubject (Score:1)
sideloading is already a sufficiently "not supported, user accepts bugs, runs at their own risk" landscape, in need of no further safety-scissors treatment, even from liability-obsessed americans
99% of users wouldn't know how, and of those that do 99% don't care, most "involved" tasks have better devices to operate from
so you have a tiny fucking pool of people making use of sideloads, and you decided there was some important (yet never-mentioned) reason you needed to go walled garden on them
i'm not even aff
404 on the summary's linked change (Score:3)
Buy new software (Score:2)
That's a problem when an app is abandoned, or not earning sufficient new customers to justify the time spent maintaining old software. This is forcing Android users to buy new software from an active publisher. Remember Google gets 30%.
Microsoft did a lot of dumb shit but something they got right was improving OS security and sand-boxing (well, until Windows 11) so old software couldn't interfere with the rest of the OS.
what does this mean for Android 8 phones? (Score:2)
Android User Hates Android (Score:2)