I flash phones almost every other week. And tablets. I have been flashing since Androids came out. But never bricked. But maybe that is why I don't have any problems.
Lots of people brick their phones by relocking the bootloader when the Android SPL before flashing was newer than the newly flashed OS when the phone has downgrade protection (e.g. Fairphone 6). The Fairphone/e Foundation forums are pretty full of people making this mistake. Then the only solution is paying Fairphone to fix it.
"flashing" a phone is largely the same as any OTA update. There's of course always a risk of it going wrong, disk failures are always possible, but it's exceptionally hard to do so accidentally. Especially with custom ROMs where they basically never include a new bootloader, so "flashing" is no different than installing an OS on a desktop system - it's just writing to the boot partition. Which you can always do again since the bootloader is still available.
It is not 'largely the same as OTA' on phones with downgrade protection. Once you lock the device again, it's game over because the bootloader refuses to boot an older version of the OS, and you cannot unlock the phone anymore. Happens all the time in the /e/OS and Fairphone forums.
It really depends on the device. E.g. Pixel is quite hard to brick. Though they do sometimes increment the anti-rollback version:
In that case you have to be careful to not flash an older version to both slots and lock the bootloader, which is possible, because many non-Google/GrapheneOS images are often behind on security updates.
It is still largely the same, those downgrade protections apply to OTAs as well. Those anti-rollback don't brick the device, either. It might not boot to a working OS, but you can still get back to the bootloader to flash something newer. Unless you blindly lock the bootloader without testing if it boots first and the bootloader can't be unlocked again I guess, but that's quite a sequence of bad choices all around
It is still largely the same, those downgrade protections apply to OTAs as well.
But the Android SPL versions of OTA updates from Android vendors monotonically increase.
It might not boot to a working OS, but you can still get back to the bootloader to flash something newer. Unless you blindly lock the bootloader without testing if it boots first and the bootloader can't be unlocked again I guess,
This is false. As long as the boot loader is unlocked, many phones will boot the downgraded image fine. It stops booting it when you lock the boot loader and on many phones, you cannot unlock it again. You need to boot the OS to enable OEM unlocking again, but you cannot boot the OS because the bootloader refuses to.
The Fairphone community is full of people who though 'oh it boots, so I can lock', locked it and they were in a boot loop and had to send their phone to Fairphone to get it repaired for 60-70 Euro (I don't remember the exact price, but that is the ballpark).
There is an adb command that can fairly reliably detect whether the boot loader can be locked. But I'm not going to post it here, because people have to read the full flashing manual, plus in the past there was a bug where the anti-rollback would trigger even with a newer SPL.
At any rate, flashing is not for most people and it was much easier when there was no rollback protection. Of course, rollback protection does make phones much more secure.
---
I wonder if your experience is based on Pixel or older/other Android devices that do not have rollback protection.
> Are you seriously implying that flashing phones doesn’t risk bricking them or you’re not aware of that risk are you serious?
Yes, that is generally the case. As a general rule with an Android phone reflashing the OS itself or the bootloader carries no risk of bricking the device (meaning making it impossible to recover without specialized hardware and/or opening up parts that were not intended to be opened).
There are plenty of ways to "soft-brick" a device such that you might need to plug it in to a computer, and adb/fastboot can definitely be a pain in the ass to use (especially on Windows), but if you have a device with an unlocked bootloader it's very rare to be able to actually brick the device while doing normal things.
Now, if you're doing abnormal things like reflashing the radio firmware you can absolutely brick some devices there, but you don't have to do that just to boot an alternative OS and generally shouldn't be doing it without very good reason and specific knowledge of exactly what you're doing.
I'm not going to say there are no devices where the standard process to flash an alternative OS is dangerous, but none of the relatively common ones I've ever owned or used have been built that way because OEMs don't want their own official firmware updates to be dangerous either.
tl;dr: It is sometimes possible to brick a device by flashing the wrong thing incorrectly, but the risk of doing that if you are just installing an alternative OS through a standard process is basically zero.
I can't be bothered to change my phone's default ringtone and yet I've had very little issue installing LineageOS and GrapheneOS on the various phones I've owned over the years.
The challenge I've found when looking for instructions for flashing one of my old phones is the assumption of knowledge some rom builders have, or perhaps an assumption about their audience. This seems like it has the potential to bit someone in the ass because if they're relying on other sources like the lineageOS wiki or forum posts elsewhere for example there's no guarantee it'll stay available, complete, or relevant to their variant over time. It's an added burden for what is a gracious volunteer role, but it's a handicap if they want more people using the fruits of their labor.
Lol what an amazing con the oligarchs managed to pull. They get to reap all the rewards of their parasitic selfish behavior with basically none of the risk. Just make a corp.
AI coding sort of reminds me of when ninite originally came out for windows. It was like a "build your own OS". Check boxes and get what you need in a simple executable.
AI coding is kind of similar. You tell it what you want and it just sort of pukes it out. You run it then forget about it for the most part.
I think AI coding is kind of going to hit a ceiling, maybe idk, but it'll become an essential part of "getting stuff done quickly".
If the goal is reducing carbon emissions, making shipping emit half as much (650 Megatonne to 325 Mt) would be less of a gain than making trucking emit only 80% of its carbon (2,230 Mt to 1,830 Mt).
The question is which is easier to do (ROI)... to cut the shipping fuel carbon footprint by half, or over the road trucking (that's about 1/4th of all the shipping) by 20%? For that matter, moving 25% of the over the road trucking to rail would accomplish that too.
The wording and repetition made me think this was likely, at minimum, written by a non-english speaker who used AI to translate it.
But looking back at it with an AI nose going, it does have a ton of AI slop feeling to it. LinkedIn slop is kind of interesting to read. The repetition is pretty obvious, though. This reads like it was written by a 10th grade english class trying to fit a very specific structure. Like every section had to check a list of requirements, which it did cuz it's AI.
If you can install a linux distro you can flash a custom rom on a well-supported phone.
If it were more mainstream I could see GUI apps to manage all this for people, if they don't already exist. Idk I just use adb.
reply