It's a double edged sword. Either the scenario you described (less likely IMO) or our grandmas are stuck with outdated Applications with known vulnerabilities for years because they don't go into App Stores and update manually.
Auto update is good default policy IMO. Most non-technical people don't care to update apps as long as the apps are working which could lead to unnecessary security issues or critical bugs left unpatched.
Perhaps technical people should take more care when making updates for their application? There's a negative sentiment over updates for software and it arose from how bad updates ruining things. Updating might help with security, but it also forces you to put up with every harebrained UI change and removal of features that developers come up with.
Eg tab groups were pushed onto mobile users in Chrome, yet it feels like the people who made the UI change don't actually use mobile chrome much, because the UX is awful. Luckily you can trudge through flags to change this behavior to the old one, but how long until we can't do that anymore?
I got tired of certain apps that kept changing behavior or UI every single week.
Some of them sneakily added antifeatures that were not there originally or move features to premium asking me to pay again.
In consequence I disabled auto updates and run an update when I remember...
I'd rather prefer to have auto updates for just security patches not for features.
That still gives power to the developer. O could add an anti-consumer change and call it a security feature, prompting devices to automatically update it.
Let's not act like Google would hand out any punishment, either.
Lol wut? Thousands of brilliant programmers who work for top tech companies push bug fixes and android gets a security update every few months. We are people, people make mistakes, we're not some code fairy queen.
Trying to restrict updates is in effect trying to prevent the original developer changing the behaviour of an app after installation.
Thats very hard to do, since in the extreme case the developer could code in a change of behaviour after a certain date/time, or depending on a response from a server on the internet.
I feel there's a qualitative difference between time-influenced or server-influenced code, and the ability to arbitrarily change the code itself. In the former, control is limited to whatever the dev thought of at the time the software was released. It's the difference between vetting a dev at a particular point in time, versus trusting them in perpetuity.
They could, but a developer won't design it that way unless they're already trying to sidestep update mechanisms. The point still stands that there's a difference between "I trust the developer now" and "I trust the developer forever".
My stock calculator app now asks for me to agree to terms and conditions. It didn't do that previously. Why on earth would I ever upgrade my calculator? (I always decline of course)
Any by the way, WHY does android even bother me with upgrades, if it's going to upgrade my apps anyway whether I want it or not?
While this is nice for those who have a significant number of applications installed e.g. through F-Droid repositories, it won't make things easier for "standalone" third-party apps that only update themselves, since they will continue to be marked as originally installed by a browser or file manager app.
I assume Epic Games already has a separate launcher app similar to that on the desktop that takes care of updating games.
What impact does being marked as "originally installed by a browser or file manager app" have? And how would that be different for Epic Games Launcher/Store?
The article mentions that even standalone apps can update themselves without user permission if they follow the requirements, Epic Games Launcher/Store is also a standalone app that needs to update itself at some point.
It doesn't change the initial installation dance with allowing "unknown sources" with all it's "scary" language and hoops a user has to jump through it seems; maybe that's what you meant?
At least for Epic this will still be a problem as they see this as a clear disadvantage: https://www.theverge.com/2020/4/21/21229943/epic-games-fortn...
> it won't make things easier for "standalone" third-party apps that only update themselves, since they will continue to be marked as originally installed by a browser or file manager app
I'm not 100% sure, but I think you're incorrect about this.
From TFA:
> However, user action won’t be required for an app install/update if all of the following conditions are met:
> ...
> The installer is either updating *itself* or installing an update to an app it first installed.
Emphasis added by me. If you request the new permission, target Android 10+, and update yourself, the user shouldn't be subsequently prompted.
there should be update policy for each app , I dont want to update automatically my calculator app. But my messaging app can update automatically.
Implementing a one fits all policy is a mistake and may open abusive updates and planned obsolescence.
> The app that’s being installed targets API level 29 (Android 10) or higher. (Google notes that the target API level requirement will advance in future Android versions, a policy that’s in line with Google Play policy on API target requirement.)
What legitimate reason (i.e. not forcing apps to adopt the API levels, and thus "security" restrictions, Google wants) is there for this requirement?
32 comments
[ 0.30 ms ] story [ 90.4 ms ] threadUpdates should be user requested, every time. Sure you can nag at them till they do, but the user should have the final say every time.
Eg tab groups were pushed onto mobile users in Chrome, yet it feels like the people who made the UI change don't actually use mobile chrome much, because the UX is awful. Luckily you can trudge through flags to change this behavior to the old one, but how long until we can't do that anymore?
In consequence I disabled auto updates and run an update when I remember...
I'd rather prefer to have auto updates for just security patches not for features.
What would be more helpful would be the ability to revert to previous versions (can't speak to Android, but this is certainly missing in iOS).
Let's not act like Google would hand out any punishment, either.
1. https://news.ycombinator.com/item?id=27175955 | An iOS app update that annoys me | Hacker News
Thats very hard to do, since in the extreme case the developer could code in a change of behaviour after a certain date/time, or depending on a response from a server on the internet.
Sounds just like the pre-Internet era to me.
My stock calculator app now asks for me to agree to terms and conditions. It didn't do that previously. Why on earth would I ever upgrade my calculator? (I always decline of course)
Any by the way, WHY does android even bother me with upgrades, if it's going to upgrade my apps anyway whether I want it or not?
The article mentions that even standalone apps can update themselves without user permission if they follow the requirements, Epic Games Launcher/Store is also a standalone app that needs to update itself at some point.
It doesn't change the initial installation dance with allowing "unknown sources" with all it's "scary" language and hoops a user has to jump through it seems; maybe that's what you meant? At least for Epic this will still be a problem as they see this as a clear disadvantage: https://www.theverge.com/2020/4/21/21229943/epic-games-fortn...
I'm not 100% sure, but I think you're incorrect about this.
From TFA:
> However, user action won’t be required for an app install/update if all of the following conditions are met:
> ...
> The installer is either updating *itself* or installing an update to an app it first installed.
Emphasis added by me. If you request the new permission, target Android 10+, and update yourself, the user shouldn't be subsequently prompted.
(If my reading is correct.)
Perhaps Google took that to heart. Or wants to protect the core businesses by sacrificing the less important ones.
I know there can be hidden changes in privacy and I don't treat my like in 2021 with an expectation of privacy.
My bigger deal is that I'd like deterministic builds on fdroid.
If that was easier to do, by using a standard environment (VM?) my trust would be through the roof.
Also shout out to fdroid, bromite, and new pipe. Living the high life.
What legitimate reason (i.e. not forcing apps to adopt the API levels, and thus "security" restrictions, Google wants) is there for this requirement?