Kudos to Google for doing this but this could be even more effective if Google committed to say, 15 years of security updates or something along those lines.
Not to mention they were incredibly slow and unwieldy even when they were new.
Especially for something like Android where if you compare a flagship from 5-7 years ago with a brand new Android Go phone the level of performance & feature set is not really that different. So it's not like the OS gets to actually start expecting things like a high end Vulkan capable GPU & neural net accelerators or anything. It still has to work with what is essentially old hardware anyway just in a brand new body.
I'm having trouble finding an Android Go phone released this year, the most recent I can find are from 2020, like the Nokia 1.3. Compared with the Galaxy S8, the Nokia has a lower rez camera, less RAM, lower quality build, lower quality display, lower spec SoC, no biometrics, and no fast charge. Perhaps there are higher spec'd Android Go phones, but at least a 3-year-gap is not enough to overcome the premium-vs-entry-phone tier difference.
It's pretty easy to find videos showing you how to replace those batteries.
>Jerry Rig Everything: iPhone 6S Battery Replacement in 3 minutes (Easy Method)
Nope - you just think it does.
It has been spectre'ed and friends to oblivion.
I don't know if security support horizons are going to expand as CPU manufacturers clean up their hardware, but the rear view mirror is a support permutation nightmare.
I know I isntalled both specifically for Spectre mitigation and it slowed down certain things that I thankfully do not use much. My CPU and Mobo are from 2014
Baseline security is a part of many people's requirements.
The 1-5 year upgrade cycles that so many companies are pushing seem criminally wasteful to me.
If you were in 2011 you couldn’t really say the same about a desktop computer from 2000. You’d be comparing a 2/4/6/8 core 64-bit processor to a NetBurst Pentium 4.
I think it’s reasonable that relatively young phones aren’t usable at this point in time. But maybe in 2030 I might expect to be able to keep using a phone from 2020, assuming I’ve replaced the battery.
It feels to me like the generational difference in hardware products has been flattening out so 15 years may not be an outrageous practical service life, really.
That behavior is the only reason that 15+ year old machines can still run current Linux. There's at least someone out there interested in keeping them working.
https://fosdem.org/2022/schedule/event/mobile_kernel_snapdra...
Android should take a similar path. Mainline the kernel drivers, keep the minimum system requirements low (which you'll want to do anyway for 3rd world handsets), add developer modes to test apps with constrained RAM and throttled CPU, rank "eco-friendly" apps that have lower storage requirements higher on the play store.
As far as the human resources required, see Ubuntu or Redhat Enterprise, which manage to do ten year support cycles for servers. I think handsets could be easier if you keep upgrading the kernel and core components instead of only applying security updates to the existing software. If you can do that then there's no more security work than you would otherwise be doing, since your latest handsets would need those security updates too.
Android is Linux on ARM but it also abstracts the hardware platform from the OS & apps, that's the whole "Project Treble" thing Google was talking about a few years back. https://android-developers.googleblog.com/2017/05/here-comes...
But that's the easy non-answer. Abstractions can't add features. Like Windows 11 dropped support for old hardware not because the right abstractions weren't in place, but because you can't add things like a TPM in software. It needs full stack support. Similarly if it turns out a device driver had a bug in its implementation of the interface, you're kinda stuck with that. And the workaround may or may not be reasonable to put up with, if a workaround exists at all.
Oh, and btw there are soft TPMs, which are the defaults on most new machines, and is probably part of the reason MS made it a requirement. But as others have shown by getting win11 to run without a TPM, it is entirely artificial, like when they decide not to ship IE/directX/whatever on an older OS. If a random hacker type can get it to work in a reasonable timeframe, there isn't really an excuse for MS not to just add the functionality with a little "your machine doesn't have a TPM so your not secure as you could be" notice somewhere.
Its mostly laziness and market segmentation.
And no, your claims of "just emulate it" is not accurate, nor is that how any other OS works. If you're missing a GPU feature on your Linux system (or, more likely, if your driver is even if your hardware supports it) it's up to everything that uses the GPU to not hit that path. Nothing is emulating it or in any way pretending to have a feature it doesn't "natively" have.
Frankly, having a solid software reference model/fallback path likely makes peoples jobs easier because its easier to track down bugs by doing a/b testing.
Oh, and BTW, you can likely boot your linux machine without your graphics card driver, and it will still be able to run your desktop/etc and simple openGL/etc applications like glxgears. How is that, because linux can and does fallback to software emulation, using... mesa.
It's complete unacceptable for everyone if an os update suddenly means your GPU is entirely unused because it doesn't support some new extension or feature, so now you're stuck with only CPU emulation. That's not a viable solution.
You should read:
https://www.freedesktop.org/wiki/Software/gallium/
for example:
"The Draw module provides point/line/polygon rendering services such as vertex transformation, polygon culling and clipping. It will be used by drivers for hardware which lacks vertex transformation (such as the i915/i945). It may also be instantiated and used directly by the state tracker to implement some API functionality that doesn't map well to hardware capabilities. "
And on and on... This doesn't mean that all the extensions exist for any piece of hardware, only that there is a pretty solid baseline. Its why I can run a gforce 7600 (which I was messing with a few days back) with a fairly recent rolling linux distro and it continues to work, and provide some level of acceleration.
And while i'm at it:
And for example from that Gallium page:
> The new driver interface will assume the presence of programmable vertex/fragment shaders and flexible memory objects.
It essentially was a hardware HAL rev, and did not attempt to support hardware that couldn't be updated to the new HAL.
Which is actually the Linux way for most all hardware. Either the driver stays up to date, or the hardware is abandoned and no longer supported. The push there is to upstream the driver so that the community can maintain it, but the end result is more or less the same. It either gets updated, or it's no longer supported. Linux has never had and actively rejects attempts to introduce any form of a driver API/ABI. In terms of policy then Linux basically provides 0 days of support for anything that isn't open source & upstreamed. Even 2 years would be an unfathomably long support window.
But even ignoring all that, GPUs are above average in flexibility for hardware drivers. Compare to something like a camera ISP. A huge complaint of fragmentation for app devs on Android is around the camera, because it turns out you just can't layer a lower level, more flexible API on top of a higher level, more restricted HAL. That's the Camera1 vs. Camera2 API mess on Android in a nutshell.
I suggest you look at llvmpipe (for shader emulation). Because abstractions can be extended both to higher level concepts as well as lower. The whole concept of shaders were bolted onto the GL specs.
The fact that a certain ecosystem is unable to extend their abstractions, as you mention with the camera situation, is less about abstractions and more about the mindset of that ecosystem. I'm fairly sure that I can design an API that provides much of what one gets with camera2 in a way that allows most apps to continue to behave like nothing changed, while allowing newer apps that need that functionality to request it of the existing API, while also maintaining ABI compatibility with older drivers, and allowing newer drivers to provide said extensions either via an extension mechanism, or alternatively a shim that layers the older API on top of a newer driver API (and therefor providing two driver ABIs one for older drivers and a newer one for newer drivers). The vulcan/GL situation is informative here. Having SW or HW that supports one or the other doesn't preclude the opposite.
And things like FP16, which are used mostly to provide higher perf/efficiency machine learning, already usually have some kind of abstraction in place to just use FP32 in places where FP16 isn't available.
The point being that the "success" of the android/arm disposable software/HW model shouldn't imply its not possible to build abstraction, and extend them.
The API that apps use, that's irrelevant. That's "trivially" kept stable. It's the API that hardware uses, and adding features to it retroactively that's extremely difficult if possible at all.
In the cases where it is possible to do layering, it's almost always in the reverse direction. Such as ANGLE implementing WebGL/GLES onto things more powerful & flexible than GLES is.
> And things like FP16, which are used mostly to provide higher perf/efficiency machine learning
I wasn't clear on this but I was referring to FP16 FBOs, which was something GLES 3 added that GLES 2 didn't have (instead of 8888 FBOs)
That way the old HW/driver that doesn't have the new feature continues to work.
AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working. Sure your OS now has support for 3d headsets, that doesn't mean that it should fail to continue playing games when the user doesn't have that hardware, it just means they don't get that experience, or the games that only work in that environment aren't compatible.
Its not actually that hard, windows/linux on x86 prove that its possible to run newer OSs and frequently applications on old hardware, and in the case of windows frequently without upgrading drivers for decades because the underlying driver API/ABI is extended rather than replaced.
EX, there is hardly a game in place that requires the ray tracing features of the newer RTX/etc series GPUS, but there are plenty of games that support that feature at the same time they work without it.
No no no, that's not the problem. The problem is that optional things are fragmentation, and that has a real impact to the application ecosystem.
Here's an extremely simple example (that also happened in the real world). Go back 20 years and make your camera driver abstraction layer. Let's say your API ends up being:
Image takePicture(bool useFlash)
void setFlashEnabled(bool enable)
bool canEnableFlash()
void setFlashEnabled(bool enable)
Of course it's "not hard" to make things optional - Android (and the web platform for that matter) are full of examples of that (this is in fact the adopted policy of Android's hardware abstraction layer with Treble - it's been something Android's been doing in practice for real for over 5 years now). The problem it it's fragmentation and is what Android (and web) devs constantly rant about vs. their iOS counterparts. Your argument is essentially that the answer to fragmentation is fragmentation. That's the part where I was saying far above that it's the easy non-answer. It doesn't address the actual complaint of fragmentation. It's something nobody has come up with a good solution to, but that doesn't make it an invalid complaint.
Oh, and I'd actually be on board with some sort of paid update program and/or crowdfunding after some point. Say 5 years of bug and security patches included in the price of the phone, and after that a small monthly fee that you use to keep up with the marginal cost of maintaining that device's unique drivers and code.
Could you illuminate me?
They delivered three years of updates as promised and after that it's a security risk.
You know Google apps are available on iOS as well as other Android phone though, right?
How much do you think that will add to the cost of a product? Software engineers are not cheap.
PCs are the proof that manufacturers don’t have to push security updates for decades. But in the phone world, they would have to because they don’t want to open the platform. So the user is dependent on the manufacturer for updates. But it don’t have to be like that.
[1] https://www.reddit.com/r/tmobile/comments/l74hto/this_is_app...
Surprisingly this is not the case. The x200 can run coreboot and related forks like libreboot: https://www.coreboot.org/Board:lenovo/x200
> unsupported Pixel phone will not get modem or sensor/wifi firmware updates
That's a good point. The removal of 2g/3g made the modems in a lot of phones non-functional. Even without cell support a phone would still be useful as a small wifi tablet if it could run up-to-date software.
Yes, yes, BIOS is supported by third-party vendor. Still leaves the microcode problem.
>That's a good point. The removal of 2g/3g made the modems in a lot of phones non-functional. Even without cell support a phone would still be useful as a small wifi tablet if it could run up-to-date software.
That's not what I'm talking about. Some phones required a modem update to work around a bug caused by broadcasting a different LTE signalling message they couldn't handle. It would crash the phone's baseband. Similarly some security group like Google Project Zero could figure out vulnerabilities in the modem (maybe unprivileged code execution using specially crafted status messages or something of the like). This is the sort of thing you will not get updates for, and the updates you've received til now won't detail much because SoC vendors have all that shit under NDA.
The solution already exists, it’s called a PC. Just make standard and compatible hardware. And it works.
The only time I see problems, is when the system-level software requires new hardware features that older models do not have.