Site says 7 years of OS versions.
Apple fixed that glitch: https://www.ifixit.com/Answers/View/802054/Unable+to+verify+....
Hell, I don't even trust that they'll still own/maintain _Android_ in 7 years.
Interesting product, thanks for mentioning it, you can limit how much you charge your phone battery the same way as a Tesla.
[1]: https://googleprojectzero.blogspot.com/2023/03/multiple-inte...
The recent watchOS update from Apple is incredibly disappointing https://furbo.org/2023/09/28/the-timer-in-watchos-10/
https://www.androidpolice.com/2021/08/31/pixel-3-and-3-xl-ph...
Quoting from Apple’s page [2]
> “Note: Because of dependency on architecture and system changes to any current version of Apple operating systems (for example, macOS 13, iOS 16 and so on), not all known security issues are addressed in previous versions (for example, macOS 12, iOS 15 and so on).”
[1]: https://arstechnica.com/gadgets/2022/10/apple-clarifies-secu...
[2]: https://support.apple.com/en-us/guide/deployment/depc4c80847...
nobody's going to say that, for example, this isn't at least as good as a pixel 3: https://www.amazon.ca/OnePlus-Android-Display-Unlocked-Charg...
You can see the full OTA history for every device going all the way back to the Nexus S:
https://developers.google.com/android/images
Note that there's no weird gap around the transition from Nexus to Pixel, both were supported concurrently during the overlap.
The replacement guide suggests about an hour to complete the task. https://www.ifixit.com/Guide/Google+Pixel+6+Battery+Replacem...
For contrast, some people need YouTube videos with step-by-step instructions to even open the hood of their car. They will take far longer to replace a car battery than it took you. Likely they'll also need to purchase a screwdriver.
https://www.samsung.com/us/mobile/phones/galaxy-xcover/galax...
Edit: This is getting downvoted, but it's a regularly-updated phone line from a mainstream manufacturer with decent specs. You can absolutely vote with your wallet here as OP laid out.
When a chip is supplied by a vendor and needs to be supported in the kernel, the whole thing can be EoLed by one stubborn vendor. That's one of the promises of Fuchsia - decoupling hardware support from the rest of the system, so you can keep everything else up-to-date even if Qualcomm tells you to kick rocks.
> A portable battery shall be considered readily removable by the end-user where it can be removed from a product with the use of commercially available tools, without requiring the use of specialised tools, unless provided free of charge with the product, proprietary tools, thermal energy, or solvents to disassemble the product.[0]
So, for example, Apple's chunky multi step DIY battery swap kit is perfectly allowable if it's provided for free.
"Commercially available tools" also includes stuff like Torx screws. So, again, the current system by most manufacturers is doable with very minor modifications. Open a few Torx screws, slowly pull off the command strip sticker under the battery, replace new battery, done.
The HN/Reddit crowd's minds went right back to the 90s and 00s where you could (and had to) carry 3 separate batteries and could swap them on the go, which isn't the goal of this regulation at all.
[0] https://data.consilium.europa.eu/doc/document/PE-2-2023-INIT... - article 11
Granted it might be faster (though looking at Geekbench scores between budget Android phones [0] and the 5-year-old iPhone XS [1] I’m not overly convinced of that either), but the price of manufacturing “nice” doesn’t drop nearly as fast as silicon.
Budget phones often compromise on build and camera and screen quality (even though the latter two often look great on spec sheets) and I think the average person would notice that far more than raw performance.
Fairphone is worth a look for this: https://shop.fairphone.com/fairphone-5
"A portable battery should be considered to be removable by the end-user when it can be removed with the use of commercially available tools and without requiring the use of specialised tools, unless they are provided free of charge, or proprietary tools, thermal energy or solvents to disassemble it. Commercially available tools are considered to be tools available on the market to all end-users without the need for them to provide evidence of any proprietary rights and that can be used with no restriction, except health and safety-related restrictions."
I think a deposit for specialised tools is fair to ensure a return of the tools, other than that, there is nothing controversial here.
Why not actually link to the page?
https://store.google.com/magazine/trade_in?hl=en-US#trade-in...
https://browser.geekbench.com/v6/cpu/2900039
Aside from all the other problems a genuine pixel 3 (or iPhone XS) battery is bellow 3000 mah, so like replacing your redmi battery with a defective one.
How quickly we forget history. I'm not going to say they were the absolute first to do this as I'm not doing a full survey of 2007 phones, but before that (a) there was not a single phone I or my friends had that didn't have a simply replaceable battery and (b) there was a ton of conversation and press when the iPhone was first released about how unique the decision was to have a glued-in battery here.
For contrast, here are instructions for replacing the battery on the famous Nokia 3310 https://devices.vodafone.com.au/nokia/3310-2017-proprietary-....
Let's be real here: if having difficult-to-replace batteries was a money loser for Apple and other manufacturers, they would fix the situation in a heartbeat - it's not like this is a hard problem. The only reason they do this is because of desired planned obsolescence - tons of people will think "Oh, getting the battery changed is such a hassle, might as well get a new phone."
Again, essentially every consumer electronic device pre-2007 (except maybe some Mac laptops?) had easily-replaceable batteries. Convincing people that using glued-in batteries was a necessary design change, instead of a corporate decision to make more money, was a real coup for corporate marketing.
https://www.reddit.com/r/GooglePixel/comments/y039zn/i_compi...
In terms of Camera, Haptics, Construction material it probably isn't
Why indeed.
A major part of the problem is instead of charting a coherent strategy for backups from the beginning, Google constantly changes their minds as to how it should work and what behavior is expected from users and app developers.
Once upon a time a simple pair of adb backup and restore commands did the trick.
Then they introduced the android:allowBackup="false" app manifest flag[1], which silently breaks adb backup. (Yes, this got me once, resulting in lost data). That effectively wrenched sovereignty over your data out of your hands and shifted its control into the hands of app publishers, many of whom couldn't be bothered to change defaults. There are also limits (e.g. even when enabled, I gather Google's cloud only allows 25MB of data per app). I think more recently it's been enhanced with a flag that allows backups only if encrypted.
All this degraded the user experience upgrading phones, so they carved out a Google-only exception in the form of a Device-to-Device (D2D) transfer process which has the privilege of totally ignoring the flag (so it can capture apps that advertise themselves as do-not-backup). But I've never seen a means of triggering that process without first being forced to turn on backups to Google servers[2], and allowing Google Play services to collect data like your email address.
It's a horrible state of affairs that makes it impossible for third-party solutions like SeedVault to work reliably (to the point where users have suggested bastardizing/impersonating D2D to bypass the restrictions[3][4]).
I don't understand why anti-trust efforts aren't examining lock-in like this, which forces you to use Google's cloud instead of your own, and intentionally creates an unequal playing field for competitors whose clouds you might trust more. It causes real harm to users like me.
The only reliable method is rooting your phone, which recovers your sovereignty and allows apps like Titanium to bypass all this nonsense. I suspect that's a major reason some people still choose to root, despite all the security warnings against it. Of course depending on what exactly you're backing up you can still run into issues if restoring to a different model phone or version of the OS (although in the past I've had some success surgically extracting the desired records via a sqlite explorer).
I wish someone would compile a flavour of Android with a Developer Option that undoes or ignores the effects of android:allowBackup. Depending on your viewpoint that would "break the Android security model", or fix it.
Some users have even resorted to decompiling their app's stock APK, patching android:allowBackup to true, self-signing and recompiling [5], which I presume would have to be done after every app update (maybe there's a niche market opportunity for a service that automates this).
If I created a mobile device platform I'd make darn sure critical functions like backup, restore, migration, maintaining "hot standby" devices, etc. just work(tm), seamlessly and reliably, out of the box. The architecture would make it easy and simple (instead of difficult and convoluted) for developers to ensure user data is captured (incidentally the normalized Palm pdb system didn't do a bad job of that), provide tools and examples of how to maintain forward compatibility, and generally funnel developers into good habits. It's not an easy problem to solve but I'm convinced it can be done with 100X more elegance. And users would have the power to backup to wherever they choose, with an easy way to custody their own encryption keys (with peer-to-peer recovery models e.g. X of Y friends or commercial-designates).
[1] https://stackoverflow.com/questions/12648373/what-is-android...
[2] https://support.google.com/android/answer/6193424?hl=en
[3] https://github.com/seedvault-app/seedvault/issues/165
[4] https://github.com/seedvault-app/seedvault/pull/562
[5] https://stackpointer.io/mobile/android-enable-adb-backup-for...