iFixit and Google Are Launching a Genuine Pixel Parts Program
ifixit.com
ifixit.com
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...
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.
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?
So not launching anything after all. This, Samsung announcement (overpriced half a clamshell with integrated LCD for only two flagship models, no batteries at all) and Apple pathetic IRP (cant buy anything, only parts exchange 1:1, spying on your company books for a couple of years etc) is a sign manufacturers already see that Right to Repair legislation is coming no matter how much money they keep throwing at lobbyists, and are desperately trying to limit its scope by claiming they already offer everything advocates want (spare parts) while offering almost nothing (screens only at the price of fully working unit at a second hand market).
Before that I only bought android phones where I knew that I can find either scrapped parts or replacement parts on ebay.
[1] https://pine64.com/product-category/smartphone-spare-parts/
If I say "I am having a 50th birthday party" that means I'm talking about an event that's happening in the future. It doesn't mean I'm having it immediately. It's a statement that's in the "future perfect" tense. Besides, people would be very confused. I'm 45.
If Google say they are launching something, the same thing applies. It means they're launching it at some point. That doesn't have to be right now. They're using the future perfect tense.
Saying "I am having a 50th birthday party" is not talking about an event that's happening in the future. You can say that and be referring to a party which is presently happening.
In my work life I've started hundreds of projects, and a few actually make it beyond a line in a planning document!
I've got a Pixel 3a XL with a cracked screen. I'm coping with it cracked, but if I'd seen this announcement and was able to order, I probably would have ordered right now. As it is I just see "coming soon", and will probably forget about it by the time it's actually live.
I think the only reason Google and their friends are doing this is to remain in control (how, when, if). They don't want to end up like the car industry.
I hope regulators don't fall for this trap.
They give great pricing to iFixIt and there you go, the margin they may lose on the phones through this is off-set to an extent via the common parts they’re now supplying.
They also know if they don’t provide the parts, which is to say they need to produce the top 5-10 components in a single fashion instead of an assembly line, someone else will so they seem to be getting ahead of the game.
They are actually modeling the car industry because folks are insanely specific about wanting OEM parts to the extent you have to specify in many contracts you can use OEM or equal quality 3rd party parts.
There are even some warranties (which cost more) that specify they will only use OEM parts so Google probably also sees they can charge a premium for “OEM” similar to the auto industry.
(I work in Auto)
Of course we need to be skeptical of programs that are just designed to look like they promote repair while being useless. But we also should give credit where credits is due.
iPhones on the other hand are easier to open and replace parts even though Apple mostly doesn't allow 3rd party parts.
Of course Google wants to get their grubby hands in the pie by getting these systems/programs in place so they can tell legislators "See, you don't need to have that pesky right to repair stuff, we supply the parts for the users!" - while completely ignoring the actual reasons and benefits of RtR. I hope we don't see Google pulling an Apple and using the US government as an enforcement arm to make sure "bootleg" screens don't make it into the hands of people trying to save a buck in this economy.
Neat.
Can I buy every part needed to assemble a phone from scratch yet?
(source: https://uspirg.org/blogs/blog/usp/examining-google%E2%80%99s... )
From the position of Apple, the Google Pixel was always a poison in the profit pool so that the monopoly would be held in a different part of the value chain (the Search versus the Hardware). In this regard, Apple's loss is the consumers' gain.
By making the Pixel really repairable and parts exchangeable, the Pixel can be shown as a shining beacon of right-to-repair. Techies will applaud how great it is, and have an object to contrast the iPhone with.
However, if the iPhone is forced to go the same path via right-to-repair laws (or due to consumer sentiment), their profits will be a lot lower. People won't need to replace iPhones as much. They couldn't price discriminate using different size SSD drives as much, etc.
And that's the whole game to Google -- again to reduce the hardware part of the profit chain, and to increase the search part of the profit chain. It's basic MBA stuff / Michael Porter's 5 Forces.
Google of 2022 is run by more MBA's than ever... Everything is now a profit center. They don't do anything big 'just because it's cool/useful/good for society'.
Their published AI research over past 10 years has been hugely beneficial to the field and society. While true they probably wouldn't be spending so much on this R&D (100B last 5 years, 31B last year) if they didn't expect a future profit, it's hard to deny the value of the research.
I suspect Apple could tweak other factors to adjust e.g. software lifetime more like Google, or changing styles more frequently. Also it really depends on the cost of parts — especially the screen: if a screen is truely expensive then consumers will prefer to upgrade than fix. I have usually had to replace my Android phones due to breaking the screen (also USB connectors - fucking unreliable things).
Just be happy companies are doing things you want. Don't expect it to be done for altruistic reasons on top of that. It's unreasonable to expect a business to do things for non-business reasons.
Market demand and/or legislation are the main reasons changes like this happen, and that's the way market economies are supposed to work, and that's fine.