A low-carbon computing platform from your retired phones
research.googleYou should not be connecting these old devices to an internet accessible network.
Google notably does well here with 7 years of support, but others such as Sony are 4 years, and Xiaomi on non-flagship devices are similar, or Samsung on their lowest budget models...
But... if Google can do so if handed a random pile of old phones, then why would a consumer not be given the same option for their phones? If it works only for phones sold by Google once, same question holds. And applies to other vendors.
As you said: the "phone becomes useless just because OEM drops support" cycle needs to be broken. Well.. that and ability for end-users to replace batteries, screen, fix connectors etc.
Also it's unclear how data would move in & out of these old-phone-compute-nodes. USB-C? Article is a bit light on details there.
End users don’t need to replace screens, ports and batteries if there is reasonable cost parts and skilled labour available.
I’m happy with a trade off where a device has extreme miniaturisation and water resistance but needs someone with some surface mount soldering skill and the right tools to work on it.
Regardless, many (most?) phones hardware will last longer than the software running on it.
For phones before the Project Treble era (~2018), the OS, the kernel, and the vendor blobs were all deeply intertwined with each other. Because you can't get newer blobs from the hardware vendors, it's generally not possible to run a newer OS on those devices. Community-made custom ROMs (like CM/LOS) had to rely on hacky workarounds to get newer Android versions to run on older kernels, which lead to stability issues and the famous "what works/what doesn't work" meme.
For Treble-supported phones, the OS framework is decoupled from the vendor implementation. This means that you can run the latest OS (using a Generic System Image) on top of the older vendor blobs. BUT you are usually still stuck with an older kernel, as those proprietary blobs still rely on the vendor's specific kernel drivers, although it's a bit more stable compared to pre-Treble due to the decoupling and the standardised vendor interface.
In either case (pre/post Treble) the main problem is that your low-level firmware remains permanently out-of-date, which puts your device at risk. An up-to-date OS can mitigate application-level risks, but not all of it. For eg, it cannot protect against attacks targeted towards the baseband modem, the Wi-Fi or Bluetooth controllers. If a vulnerability is found in the cellular modem firmware (like the infamous Broadpwn or Kr00k exploits), no custom ROM or other OS (PostmarketOS etc) can patch it because only the chipset OEM has the source code to update that specific chip.
So unless all the various chipset OEMs come to the party and either release the sources or provide updated blobs, these devices can never be trusted for use in a production environment.
Not sure about the IO interface, could reuse the USB, but maybe there is some internal (and standard enough) bus to reuse too...
The article seems to refer to a 2023 Pixel Fold as one of their candidates - I guess a good opportunity if those fragile screens get damaged but not a cheap used device otherwise.
Even normal slab pixel devices have limited support for true android replacements like PostmarketOS let alone cheaper 3rd party devices usually running Mediatek/Exnos SOC that have zero open docs or support.
Couldn't Google somehow fix this? Since they control the substrate (Android) and they would be doing it for their convenience
They're actively working on closing the ecosystem even more (no more sideloading), DRM features, etc.
Maybe they'd do it for themselves, but they clearly don't want you, the customer, to do whatever you want with the device you bought and paid for.
Does anyone in the industry know why so much firmware is proprietary?
It's also a huge pain in the ass for them to release software as open source. They would need to track all the different forks and modifications in an organized manner (they often do a lot of copy paste and one-off nonsense). They run pretty light staffing on a lot of these components and doing all of that is just another chore for their overworked devs.
Lastly, I've heard they sometimes use other commercial, closed-source software components which they can't easily relicense.
Is this all bullshit? Yes absolutely. I'm not defending them but these are the excuses they give.
I would think the main factor against such clusters is cost. Even if the four year old phones are free, they have to be dismantled, tested, and supporting hardware/software has to be developed. All of that would have to be done on an ongoing basis. While Google may have the volume to be able to build uniform clusters with a given generation of hardware, generations are measured in months. Using four year old hardware also trims four years off the expected life expectancy of the components, and that is comparing like to like (not consumer grade hardware to server grade hardware). I've got to wonder how all of that extra work affects the carbon-footprint they are trying to reduce. It would probably be more effective to increase the use life of the phone as a phone.
All of that is fine for a research project or, on smaller scales, hobby projects. It would be extraordinarily difficult to make it commercially viable.
So, OEM just have to let us unlock the bootloader, just let us unlock it after they stop selling it, and it would reduce so much waste.
They are just so greedy
Approximately nobody is throwing away phones because the OEM stopped providing security patches. They're doing it for more practical reasons, like the phone getting slow, the battery wearing out, or wanting a better camera.
Moreover being able to replace firmware blobs/kernels/whatever doesn't mean such updates will actually materialize. For lineageos, many phones are stuck on 22.2 (android 15) because android 16 requires linux 5.4 and above, which means phones with earlier kernels are out of luck. Prior to this, there were phones from as early as 2016 (eg. the original Pixel) that could be upgraded to the latest Android. This isn't a "firmware blobs" or "locked down systems" problem. The kernel sources are available, and the kernel can be replaced, but nobody is going to bother upgrading the kernel for a 10 year old phone.
https://lineageos.org/Changelog-30/#legacy-devices
>You should not be connecting these old devices to an internet accessible network.
This depends on the use case. If you're using this as some sort of NAS or compute cluster running trusted workloads, you should be fine as long as there isn't some sort of RCE in the kernel.
Apple just shipped iOS 27, which has support for 2019's iPhone 11. So we are around 7 years there. It's probably fine for many people's use!
For a task like openclaw or hermes, or even something more aggressively graphical & GUI, it's not hard to imagine an 8 year old phone doing fine.
Relative to ever rising hw requirements of apps they obviously get slower. That is why I personally buy new phones.
The big obvious central smoking gun that you'll get to in computer science 200 level classes is Amdahl's Law, which states:
> the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used
You queue up some work for an agent. The LLM is going to do a bunch of work over time, and spend 20 minutes crunching on a task. Let's generously say it takes your PC 2 minute of it's CPU time for it to do the tool calls, to run the build, to run tests. If we expand this to 10 minutes to run it on a phone, that's indeed starting to be a big enough difference to notice. But in 99.9999% of cases, I don't think the harness consumes that much CPU and I don't think the growth factor is 5x to move to phone, and even if it did, it's still only an increase from 22 to 30 minutes: it's an async job either way, and the time budget is not dominated by the phone or PC running the harness.
Ideally yes, there's some intelligence to see: oh, we are about do to a build. Send the build to the build server, that's a 384 core 1U with terabytes of memory bandwidth and let it do that. But most work is not like running builds and tests. The harness doesn't need that. We need some small local computers cheap that we can have lots of running.
Model performance might radically improve in time, and that might change the Amdahl's Law calculations here. If you're paying for Turbo or Plaid or whatever, yeah, you maybe have the money to spend on a better harness too. I'd say that ideally these workloads become live migrate-able, that we can CRIU checkpoint/restore them across systems, ideally, anytime, so that we can give performance people performance when it actually counts, like the build concern above, when the agent is fast. LLM's built for speed like LFM2.5-8B-A1B (DiffuseGemini feels unlikely as it's fast, but low concurrency, but perhaps?), double the speed of many models, so that 20 minutes could become significantly less. But right now it feels like we need a lot of cheap not-performance critical harnesses that can sit around running, and that performance for them is not critical. https://www.liquid.ai/blog/lfm2-5-8b-a1b
If folks aren't aware, I also suggest taking a peak at Google Ax and Google Scion, two agent runtimes designed for scaling out, that are both kind of neat. https://github.com/google/ax https://github.com/googlecloudplatform/scion https://news.ycombinator.com/item?id=47675213
This becomes a practical reason more quickly than you think. If a company only provides 4 years of security updates and they only provide 2 android MV releases, you quickly become out of date. I had a BlackBerry Key2 that I bought in 2018, I had to replace it in 2024 and I was really holding onto it despite a lot of practical problems - Slack dropped support for the version of Android a year earlier, it was only when I tried to install Google Wallet and could not that I finally decided despite the hardware and software functioning fine it really wasn't practical to use a device that was stuck on such an old version of Android. (I would've tried to figure out the kernel myself if the bootloader wasn't locked.)
I thought that, but a surprising number of people think that no support means that their device becomes vulnerable on the very next day. Not all of them act upon it but that seems to be the understanding of people who know what a security update is (not my grandma, but my mom for example) but aren't real techies or just not in this area. And it's not like these people are installing non-OEM patches! Nice as that would be...
Some time before and during covid, I feel like security update awareness became a lot more mainstream. Maybe because there's not much else to talk about in smartphones anymore anyway, so you shift from "ooh this fancy new one has a fingerprint reader in the power button and its notification LED on the back!" to "I don't want a new one; which one can I use for the most amount of years to avoid this hassle"
Probably also a culture thing. I guess most people in low- and middle-income countries have other worries; I'm speaking from a northwestern european viewpoint
I did this just last year because my Pixel 4a stopped getting security updates and some app I needed to use for work (I think Duo?) refused to install or run because of it. The phone was otherwise running perfectly fine and I had no reason to change it. I'm on a Pixel 8 now which is supposed to have 7 years of security updates, and I don't see myself replacing it until then.
They might not understand the paranoia is real.
Remember people running 20 virus scanners and 3 firewalls on their win xp machine? Then it finds 12 suspicious cookies?
caused by the very same Google...
I personally have lots of batch jobs like CFD simulations that could easily run on a fleet of phones with no real reliability issues, and I’d love to reuse old hardware and give it a second life. I’m already considering running old servers from e.g ETB but the cycles per watt on a phone are probably much better.
Yet I 100% agree on a generic computing device and they're not really that different in the end. Maybe that it needs to be unlockable after it has been on the market for 4 years or so (all units, no matter when they were sold, no matter if support ended)
Or maybe undercutting the competition like this to make it back later on games is not a profit model we should want? And that everything should just be unlockable insofar as it has X amount of memory, CPU power, capable of doing IP traffic... something like that. (Seems silly to require a firmware unlock on your toaster)
Sure it’s fair, and manufacturers could price accordingly. Legally enforceable is another story.
Yes, but I'm confident Android smartphones aren't. Maybe Google is an exception here, but all the other manufacturers profit mostly from the hardware and not from the Apps. Samsung has its own app store, but I think only a tiny minority of users spend money there.
I think there should be a 20 year rule for all released commercial software to release the source code outside of national security concerns.
You factor in the expense of having your code releases escrowed by a third party (where part of the escrow contract itself is: "must be buildable from sources as provided"), and have a post-release pipeline that automatically uploads the new version. At the end of the term, the escrow holder releases all the versions.
This is a fairly common arrangement in high finance. If you want to supply services to a bank/insurer/etc. they will typically require an escrow arrangement as a contingency plan against you as a vendor going away. And yes, they pay the escrow costs.
From my observations, phones get destroyed, used until the battery swells and breaks them, or handed down to kids or less careful users. No one I know has a bunch of old phones that are still useful but unused.
I recycled them wheb carriers decided to block a bunch of phones.
Does anyone have recommendations for novels, movies or video games with that topic?
https://windupstories.com/books/pump-six-and-other-stories/
Also I guess Silo / WOOL by Hugh Howey is perhaps closer to what you wrote literally but probably not quite the vibe maybe.
In general, you should look into the ‘solarpunk’ genre, especially post-apocalyptic solarpunk.
This earlier comment referenced it :)
I wonder how long this takes per phone. Presumably it could be a pretty fast shucking process if you don't care about any of the other components. I can't see it making much economic sense if it takes more than 1 minute/phone.
It’s a genuine shame how locked down iPhones are compared to even Android. Hypothetically you could run Linux inside UTM[0] but outside the EU Apple makes it intentionally difficult, and there’s still memory restrictions and performance penalties.
My group’s senior year project was a computing cluster on phones (specifically targetting LLM inference) [1]. Instead of installing a new OS we built separate apps per OS. Our devices were older, so the Android phones had worse hardware and the iPhones had more software restraints.
[0] https://getutm.app/ [1] https://github.com/orgs/rmcluster/repositories
[0] https://docs.google.com/presentation/d/1jsJ5euZ4VXcwL4fbgJKM...
???
You can still install alternate OSes (eg. grapheneos) on their latest phones.
>And now, they're making it illegal to install custom apps too: https://keepandroidopen.org/
Besides the questionable use of "illegal" (what are they going to do, send you to jail?), that's not even accurate. You can still install apps after a 24 hour wait, or no wait at all if you use adb.
The article is pretty clear in the opening lines that this is a Google Research grant to the University of California, not even primarily done by Google employees.
Google is requiring it be closed and leaving the unlock entirely optional. That's a choice
So people are to blame, not the companies shoveling ads, offering promotions to buy new phones, and in general creating the huge demand that they later, "are forced to satisfy".
- Are these phone processors really as compute-pet-watt efficient as a regular data center processor?
- There’s so little embodied carbon in a phone motherboard - and presumably some embodied carbon in whatever custom racking hardware up is being used to house these. Is that really compute-power-per-embodied-carbon-footprint efficient than making a new server?
But yeah, these are great questions which are not obvious at all and should be answered when proposing such a system.
I have no numbers to back up my argument, but smart phones are very power efficient by their nature are they not? I can play a 3d game, with impressive graphics, on a tiny device powered by a battery... With very little heat generated.
If your goal is to run LLM inference on a gpu in a power efficient manner, I bet a smart phone is a good place to start.
Edit: yes, 25. Found my go-to reference for this quickly after all
> The report about the cost of planned obsolescence by the European Environmental Bureau [7] makes the scale of the problem very clear. For laptops and similar computers, manufacturing, distribution and disposal account for 52% of their Global Warming Potential (i.e. the amount of CO₂-equivalent emissions caused). For mobile phones, this is 72%. The report calculates that the lifetime of these devices should be at least 25 years to limit their Global Warming Potential. —https://wimvanderbauwhede.codeberg.page/articles/frugal-comp...
Not sure if I should take this as a joke or a sign of an internal power struggle. If it's the former, there's still some catching up to do before you can match Samsung's "Upcycle", but you're on the right track.
Modern phones typically use TLC or QLC within a inch of their physical limits (signal to noise ratio), thus qualified typically only up to 500 FDW, which translates into several years of use.
There are other mechanisms at play which further degrade this number, such as WAF (write amplification) and others
That consumer rate isn't datacentre use, but not every task is write-to-persistent-storage intensive. You can also replace the sdcard and write to that instead if this is a worry (that's what I've been doing on my phones since I use them quite intensively; maybe that's overkill nowadays idk)
And the balcony camera didn’t work out because I wanted it to be solar powered and the angles of sunshine available to me without active tracking don’t give me sufficient energy on a daily basis.
But the machine is still a good machine. I will perhaps return to one of these projects. It’s annoying how much power access dominates everything.
Anyway, this is a cool project!
> With Google’s support, [researchers at the University of California San Diego] plan to deploy a datacenter built from 2,000 Pixel smartphones
Ah.. well maybe success here will give internal folks some ammo for enabling more reuse of the mountain of Android (and Chromebook) devices.
c'mon Google, release that shit.
You can already run any workloads on it at a fraction of a price of traditional cloud services.
However it does worry me that I've never heard of acurast... I consider myself pretty well read on the subject of decentralised projects, has it just not taken off?
This also solves alot of the security issues as your in a sandbox.
Applications could offload all kinds of tasks.
You dont even need to invent useful applications the community will do it for you. But if you insist, think all kinds of cheap smart devices that offload the smart part.
I was dreaming at the time to ship a mobile phone at every large store (e.g. Target) to process the data in-situ. It could hold its own database (partitioned for the tenant), it would have its own UPS (battery), and have enough CPU power to serve the POS requests of one store, even the largest ones.
A mobile phone would be our on-prem server.