I know PLENTY of people who bought a Samsung, Pixel, or iPhone because of the software support lifespan being a market leading 3/4-3/5 years, 3/5 years, or 7/7 years respectively compared to the standard 2/3 year support of Android OEMs. The average person now is going north of 4 years with their phone and rising. It's not about wanting to be "eco friendly" it's security, software support, and OS features being supported by some corpo instead of some teenager making a ROM.
This is a huge part of the reason why Androids depreciate so much faster on the used market, if you compare the Galaxy S20 to the even older iPhone 11, the iPhone 11 will likely receive 5 years of OS updates compared to 1 year for Samsung. Other OEMs like OnePlus or Sony will have already had support end. Maybe your average customer doesn't really understand why this stuff matters but they do understand that an old iPhone seems to work better than an old Android that cost the same at release.
Of course this is a great decision because people will be forced to buy a new phone more often right? No! People using your phone are a captive audience for selling high-margin services and accessories. If you don't support the phone they'll still use their old phone anyways but will be annoyed and likely to switch to the competition next purchase cutting off all your profit streams.
Pass a new "right to repair" law, such that any OEM that halts software patches on any network-connected device for more than 6 months will be required to unlock bootloaders and publish technical specs.
Apple and Android will see enormous and wonderful community involvement if that were to happen, and congress could force it, should we motivate them.
> Pass a law that taxes Google punitively for each app sale on an unmaintained phone, and see how quiclky they'll find a way to support their phones.
Wouldn't the result of that, be that phones that get anywhere even close to being unmaintained would stop dead (or close to it), so Google doesn't get exposed to a problem?
To me, that doesn't sound better than the situation you're trying to fix.
Selling apps to the long tail of older phones is probably worth throwing some money in a maintenance team. Especially with phones having a 3 year shelf life.
As long as there is also a minimum support window, say 3+ years, and full specs and source are community released, then why not?
The important part could easily be ensuring that older hardware can be accessed. We need an end to binary blobs, or, to force long term blob support and updates.
I imagine a scenario where you pay $20 per year for support and updates for your old device, to a third party.
Or of course, there could be foundations, compile it yourself, etc too.
But if the environment is the reason, why not share the load?
Manufacturers publishing code, sources, and docs is not trivial in of itself.
I'm not a fan of it, because that basically means that Google asks the community to take up the bill for a service they sell at extraordinarily high price.
I know that's the case for lots of open-source software, but since we're coming to that topic, Google's open-source policy that produces software that is either tightly aligned with their own interest (Chrome) or barely usable without their proprietary ecosystem (Android) is shameful. Quite frankly, I would much rather see open-source communities work on linux phones, no matter how useless that may be.
Another reason I'm not a fan of it is that if Google is allowed to transfer their responsibility to a community, I'm willing to bet that their initial support duration will drop even more, and that any issue will be blamed on open-source maintainers, log4j-style.
> But if the environment is the reason, why not share the load?
Does Google share the profits? Is their Android business barely profitable to justify getting free labour?
> will be required to unlock bootloaders and publish technical specs
is probably sufficient motivation. There's no way Apple would be willing to do that. Google might be, but they might have a lot of resistance from Qualcomm and possibly mobile carriers and other partners.
That is imo a bad fix, because it would be very easy for Google and Apple to make sure the technical specs are unreadable and the bootloaders complicated to use, without much recourse for the lawmaker.
Comparatively, it's much easier to make a law targeting the stores that's hard to avoid.
I'm sure that, was such a law allowed to pass, lawmakers and prosecutors would magically find a way to express their dissatisfaction if Google was trying to skirt the law in such a crude way.
My bet would be on Google successfully lobbying to kill the bill in the first place, or to cripple it and make it irrelevant (for instance with a long grace period that always gets extended).
Disagree. For certain vendors you can already get unlocked bootloaders and kernel sources. That's how various aftermarket android ROMs are built. However, even for a project like lineageos, there's only one or two maintainers per device. Do you think one or two volunteer maintainer (presumably working in their free time), can keep the entire kernel up to date and patched?
>Any locked device must brick itself after 6 months of no patches, to ensure the safety of the network.
What does this accomplish? Get people mad? Moreover, what prevents someone from making trivial patches to keep a device "up to date", kind of like how people make trivial changes to their passwords to keep up with password rotation policies?
> Do you think one or two volunteer maintainer (presumably working in their free time), can keep the entire kernel up to date and patched?
Maybe I misunderstand it, but I think it’s not that bad?
The kernel gets kept up-to-date by LineageOS, the device builds (official or unofficial) use the base builds, but add device-specific tweaks, and cherry-pick commits from elsewhere. And actually a level above that is AOSP which is maintained by Google.
>And actually a level above that is AOSP which is maintained by Google.
How do you think the CVEs get discovered? What about CVEs in the qualcomm specific code? How do you know that the amateur kernel developers wouldn't fall prey to c footguns and introduce new vulnerabilities?
Don't get me wrong, this is strictly better than the current state of affairs where there's zero patches, but I think people are underestimating how much effort it takes to keep a huge codebase patched.
> We need a lemon-like law for consumer electronics.
I wonder how this should apply to planned obsolescence of devices like smartphones.
On one hand, it's obscene that manufacturers expect us to routinely spend ~$1k on a device that will in the best case scenario last for three years. There's no inherent reason that a flagship Samsung from 2017 shouldn't be perfectly serviceable today, and likewise for a Pixel 6 or iPhone 13 in 2030. However, the discontinuation of security updates makes it so that for all practical purposes they are not.
On the other hand, we can't exactly compel speech or labor. It would be one thing if there were a kill switch triggered after N years, but in this case the obsolescence isn't caused by an active update, rather a lack thereof.
Here's a possible middle ground:
1. Block device manufacturers from arbitrarily deprecating hardware. We can't compel the release of new software, but we can block the release of new software. Require manufacturers to submit a filing with request for approval before the release of any new mobile OS update, which must include an exhaustive list of all supported devices. In the event that a device is dropped from the list in a subsequent filing, it must be explained to the satisfaction of regulators that a specific hardware limitation makes continued support for the device problematic or impractical. Given approval to drop support for a device from an OS release, there would be no obligation on the manufacturer to backport security updates to prior releases.
2. Block component manufacturers from arbitrarily deprecating hardware. Any hardware included in a publicly available consumer electronic device must have its manufacturer commit to providing up-to-date driver software with support for the latest OS for the lifetime of the device. Failure to provide this within a certain time frame (say, three months) following the request of a device manufacturer would open them up to a lawsuit, wherein they could be compelled to publish the most recent release of the driver as open source / public domain. #1 would provide the incentive for each device manufacturer to proactively enforce this, as their entire product roadmap would be effectively frozen if they allowed component manufacturers to drag their feet.
3. Ban irreversible bootloader locking in new devices. Maybe an initial bootloader lock would be acceptable, but power users should have some way to override the lock and install a custom ROM without relying on vulnerabilities in the software.
> but they do understand that an old iPhone seems to work better than an old Android that cost the same at release.
I suspect that the majority of Android-using techies that notice this are either on a faster new phone cycle than 3 years, or have already priced that difference into their total value calculation.
I also strongly suspect that the average customer does not indeed understand.
By this logic Google should do away with their QA department and product support staff.
You spend the $1M because it improves customer value by far more than $1M and that works out for everyone in the long run. This thread is a testament to what happens when you pinch pennies.
If you see the entire picture, it's the most expensive cost any department can ever present.
it is a "revenue-less $1M"! pure Career suicide.
Specially because marketing can't even use it. today only false-equality sells. Eco-thinking is so 90s.