Android 14 Preview 1 is Out, Will Officially Ban Installation of Old Apps (arstechnica.com) 48
Android 14 is here -- or the first preview is, at least. From a report: Google is kicking off the months-long developer preview process for Android's latest version, which will get a final release in the second half of the year. Even with multiple previews, Google likes to keep the final set of Android features under wraps at least until its I/O conference in May, so we can't look at the features here to determine the scope of Android 14. These are just some of the features Google wants developers to have a head start on. The biggest news is that Android 14 will block the installation of old Android apps. As Android changes over the years, new APIs and increased security, privacy, or background processing restrictions could break old apps, but Android's backward-compatibility system keeps these old apps running. Apps can declare the newest version of Android they support via a "Target SDK" flag.
To prevent old apps from breaking, new features and app restrictions in, say, Android 12 only apply to apps that target Android 12 or above. Older apps will continue to run with the older set of restrictions they're used to. (A different setting, called "Minimum SDK," determines if a new app can run on an old Android OS.) The system works great for honest developers, but if you're building a piece of malware, it's an easy decision to target a very old version of Android. While you'll get access to fewer features, you'll also be subject to fewer security and privacy restrictions. For the first time, Android 14 will close this malware loophole by simply refusing to install old apps. The cutoff point is generous enough that it shouldn't cause anyone problems; any app targeting the 8-year-old Android 6.0 or below will be blocked. Google says it picked Android 6 because it's the version that introduced runtime permissions, the allow/deny boxes that pop up asking for things like camera access. In addition, "some malware apps use a targetSdkVersion of [Android 5.1] to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0," Google said.
To prevent old apps from breaking, new features and app restrictions in, say, Android 12 only apply to apps that target Android 12 or above. Older apps will continue to run with the older set of restrictions they're used to. (A different setting, called "Minimum SDK," determines if a new app can run on an old Android OS.) The system works great for honest developers, but if you're building a piece of malware, it's an easy decision to target a very old version of Android. While you'll get access to fewer features, you'll also be subject to fewer security and privacy restrictions. For the first time, Android 14 will close this malware loophole by simply refusing to install old apps. The cutoff point is generous enough that it shouldn't cause anyone problems; any app targeting the 8-year-old Android 6.0 or below will be blocked. Google says it picked Android 6 because it's the version that introduced runtime permissions, the allow/deny boxes that pop up asking for things like camera access. In addition, "some malware apps use a targetSdkVersion of [Android 5.1] to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0," Google said.
Makes sense, but (Score:2)
Why can't they just come up with some way to enforce new permissions anyway, and if the app can't handle it then it just crashes and that's that?
Re: (Score:2)
Why can't they just come up with some way to enforce new permissions anyway, and if the app can't handle it then it just crashes and that's that?
Because lazy developers don't always get around to fixing the things your newer OS broke, and the user experience suffers. The average smartphone user isn't a techie, and when things are constantly crashing they'll just assume Android has become unreliable crap and will buy an iPhone instead.
Re: (Score:2)
Why can't they just come up with some way to enforce new permissions anyway, and if the app can't handle it then it just crashes and that's that?
I believe what you're describing to millions of fans of browser plugins, is begrudgingly known as The Firefox Effect.
Perhaps that's why others avoid that particular method of third party support.
Re: (Score:3)
One way to do it would simply be to return no data if the older app hasn't been granted permissions. Or "fake" data that tells you about the issue.
Like with contacts, it could return one fake contact named "Enable Permissions" with the note explaining what the user has to do.
With photos the "library" the app sees could just be a single JPG with text explaining how to enable permissions, and so on.
This would allow older apps to keep working and permissions would be respected, without having to worry about br
Re: (Score:2)
Re: (Score:2)
Why can't they just come up with some way to enforce new permissions anyway, and if the app can't handle it then it just crashes and that's that?
Because it's incredibly stupid to break userland apps on an OS level and because of the way permissions are designed you'd be breaking 100% of apps since basically no apps ever requested no permissions.
Re: (Score:2)
Because when the app crashes, users will blame (rightfully) on the OS, not on the app... "it worked before the upgrade, now it doesn't, upgrade was bad, never upgrade again"
Re: (Score:2)
Re: (Score:2)
Re:Unmaintained apps should be banned (Score:5, Insightful)
That depends on the app. Some apps should be able to go for many years without an update and be just fine. Like a calculator app. As well as many simple games.
Bring back the network access as a permission, and force it to be off for older apps, and you've pretty much solved the problem.
Re:Unmaintained apps should be banned (Score:5, Funny)
Re: (Score:2)
Bring back the network access as a permission
Why? Users already have permission fatigue. Requesting a permission that literally every app will ask for will just further weaken security by desensitising users to clicking yes repeatedly to get their toy working.
Re: (Score:2)
That's a fair point, but even if it's granted silently by default, I want to be able to turn it off manually. I would love to be able to see a list of apps with network access and turn off any that I don't want to have it.
Or maybe have that permission have an option of "allow for all apps" to stop getting asked.
Re: (Score:3)
Why would my calculator app need any updates at all?
Are you telling me that Google changed the way base10 arithmetics works?
Re: (Score:2)
Re: (Score:2)
The answer to all of those questions is "stop spamming irrelevant red herrings and address the actual question".
Make it a fail at hardware control (Score:3, Insightful)
So if you have other hardware controlled by a phone app (Roomba, lights, heating etc) when you upgrade your phone you may no longer be able to control the hardware if the manufacturer doesn't keep the software of old hardware up to date. So TWO companies can make your other hardware obsolete while it is still fully functional. FAIL!
Re: (Score:3)
To be fair to google, this was always the case, and this is not limited to google either.
Re: (Score:3)
From TFA:
adb install --bypass-low-target-sdk-block FILENAME.apk
Not ideal for most consumers who don't know what ADB is, but the option is there. Given these apps would have to have been abandoned 8 years ago to not have got an update to the minimum API version, the balance between protecting everyone from malware and screwing a few users whose 8+ year old hardware and a relatively new phone combination result in reduced functionality (their Roomba will still work, just no app for it) seems about right to me
So #14. No old apps and, ooh, let me guess, ... (Score:1)
This and Windows 11 with the Taskbar in a different place !
What a time to be alive.
Digital game preservation fails again (Score:3)
Re: (Score:2)
You could also fire up an Android 5.1 emulator and play 8 year old apks.
I can hear it now (Score:2)
Re: (Score:2)
Re: (Score:3)
I initially hated this idea when I first started reading it, but as I started to think about the ramifications, it made me angry... that this hasn't ALREADY BEEN done. Imagine if real life worked like Android apparently does: if you're older than a law, you're not bound by it...
Others in the thread have given a much better solution to this problem: If an old compatibility level is requested, provide a simple "all/nothing" option to either give it the data that's been requested, or give it false information. This was done with XPrivacy and PMP in that era; there's no reason Google couldn't do the same thing. It'd be an all/nothing in this case. Now, one could argue that it's not worth the development time to do this, or add some sort of sandboxing solution or such, but the point is
Re: (Score:3)
A better option would obviously be to just make this a setting you have to toggle in the OS. Just like the proper installation of apps from sources other than Play store needs to be enabled in settings now.
Frankly, the fact that normal local installation of software is something you need to separately enable, while installation from Officially Certified And Properly Monetized Source is automatic tells you that this has nothing to do with security. It has everything to do with wanting a bigger piece of the p
Block Network (Score:3)
What if they let older apps run, but blocked network access? How much in the way of malware would still do anything harmful without network access? Lots of legitimately older programs would then continue to run just fine, and in some cases better, as that would block ads (giving the creators an incentive to update them for once).
Along these lines, what I really miss is having network access be a user-controllable permission. Yes, you can install a local VPN app like NetGuard that lets you do that, but it's a clunky hack solution for something that the OS should just do for you.
Re: (Score:2)
How much in the way of malware would still do anything harmful without network access?
Absolute shitloads. Here's one example that took me a whole of 1.75seconds to come up with: malware pair, one using some old nasty security issue to exfiltrate data from sensitive apps and save it to the local device, and another that does something as innocuous as read a file from disk and upload it somewhere and would have no problem meeting the latest fancy security requirements.
Not going to affect anyone not sideloading (Score:4, Informative)
The Play Store has already made all apps that don't target API level 31 (Android 12) or newer undiscoverable. This means that if you want to install something from the Play Store the requirements are already far more restrictive than this (or API level 30 / Android 11 for wearable devices).
A lot has changed in the security of mobile devices on a API level over the years so I'm honestly surprised it took them this long to plug the hole.
Re: (Score:2)
Apple has been doing this for years too. Old apps get purged from the App Store, and because there is no side-loading it is impossible to back them up or re-install them any other way.
This makes sense to Google (Score:1)
Google is well aware that Android has two types of users:
1. The ones who make conscious choices about what they install and run.
2. The ones who Google (and the sellers of apps) can make money from.
This change could protect a few more of those precious Type 2 users.
And they don't give a shit about screwing Type 1.
No more "control with your phone" gadgets (Score:2)
google has the tech to do better (Score:2)
put the old apps in a parallel environment with very limited capabilities. Google already has plenty of container technology in their company they could leverage. And something lightweight like nsjail [github.com], podman [github.com], or enroot [github.com] could be adapted to work if there was better integration of Binder and kernel namespaces, or at least a slow-path emulation of Binder for the legacy apps.
Goodbye favorite calculator emulator (Score:2)
The point of an advertising platform (Score:2)
Most developers won't alienate their customers, so they will need to create a new product that supports Android 12-14: Expect Android software to become more expensive.
As most slashdotters have realized, the problem isn't the software, it's Android OS automatically approving the "full internet access" permission: Which this policy, won't so
Can't install old apps? (Score:2)
any app targeting the 8-year-old Android 6.0 or below will be blocked.
If Google doesn't want
Re: (Score:2)
If you really still want to install an app that old, an ADB command line flag - "adb install --bypass-low-target-sdk-block FILENAME.apk" - will bypass the block.