You must log in or register to comment.
Imagine only having one copy of the system so when a situation like this occurs, you lack the ability to automatically switch to a working one, re-download and retry, without danger of this occurring.
This was fixed a decade ago with Android. They could have literally taken the source code from aosp and added it, or at least converted it (if in different programming language), and never had this issue. It would cost $0 and minimal time. But no. That won’t ever happen. It’s built ford tough.
I work on consumer electronic ear buds. Frigging ear buds, and we support this…
While the implementation of an A/B update system wouldn’t be drag and drop from Android to a different OS, they absolutely could implement the same idea to prevent this issue.
The likely reason as to why is storage space, you need two copies of the system, while only one is running at a time. They probably put as little space into these infotainment systems as possible.
If they put more in new models, they’d then have to support two methods of updating the system. It’s easier to tell the customer on the rare occasion that an error does happen “oops we made a fucky wucky it’s on you to fix it”
Even some decent modern Wi-Fi routers have such protection. There’s working and backup partition. If a firmware update fails, it boots using the previous working partition.
This is a better explanation (in this case for Cisco Linksys EA3500):
Like several other Linksys devices, the EA3500 has a dual firmware layout: working and backup partitions. Unless you manually choose which partition by doing a manual uboot/tftp install, firmware flashes occur on the backup partition and the EA3500 shall reboot from the backup partition following from a firmware flash. The backup partition becomes the new working partition when the reboot was successful. The former working partition becomes the new backup partition.
