81–90 of 108 posts
Earlier quoted context omitted.
It worked for Microsoft to impose hardware designs on PCs, the big difference was that OEMs did not had the source code of MS-DOS and later Windows available to them, to do whatever they felt like it.
OEMs can't do whatever they like with Android outside of China PR. They need Google play services.
Glad to see improvements are coming! Articles like this make me more and more curious whether Fuchsia is an alternative bid to resolve relevant kernel vulnerabilities in a more centralized, architecturally driven fashion, not just a way to get out from under the GPL.
There must be an economic incentive for device manufacturers to maintain/update their drivers, otherwise it cannot happen. Users want to buy new devices, not pay directly or indirectly for updating their old devices; this basically seals the deal.
Android should really use a modern kernel. All the forking mess involved in Android updates is a terrible problem predicated by the lack of generic drivers on mobile devices. Copperhead[0] has been working to apply security patches to the kernel for some time and PostMarketOS[1] has an eventual goal of using the mainline upstream kernel. Really pulling for PMOS. [0]: https://copperhead.co/android/ [1]: https://www.po…
I hope regulators (EU in particular) will act on this and require manufacturers to provide support for products for a reasonable amount of time.
Devices should be clearly labelled with a "best before" date, until which the vendors should provide (at least) security updates. Right now the situation is unbearable, you buy a phone for $200 to $700 and you don't know how long it is good for. A technically oriented or security minded person can deal with the situation but almost everyone has a smartphone. Billions of unsecure devices out there isn't good for anyone.
It shouldn't be unreasonable to assume that a smartphone should be good for 5+ years.
Earlier quoted context omitted.
Main reason is that there is a lot of hardware that never got binary blobs / drivers updated for newer kernels. We're talking input controllers, wifi, bluetooth, nfc chips, gyroscopes, amps and half a dozen other parts that never attempted to have drivers mainlined in Linux kernel. It's a chicken and egg problem - they won't make updated blobs until Android doesn't include newer kernel. Android won't use newer kernel…
Yes, and I addressed that in my comment. Google, however, can effectively do whatever they want. If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind. I bet most of them do enough business supplying parts for Android phones that they'd get their shit together. And it' not hard! Writing an initial driver for some hardware might take a lot o…
This leaves Google with a version of Android that does not run on anything. There are less than a handful of relevant SoM manufacturers that are capable of delivering consumer grade SoMs capable of running hardware accelerated Android; Google can not alienate these.
Android should really use a modern kernel. All the forking mess involved in Android updates is a terrible problem predicated by the lack of generic drivers on mobile devices. Copperhead[0] has been working to apply security patches to the kernel for some time and PostMarketOS[1] has an eventual goal of using the mainline upstream kernel. Really pulling for PMOS. [0]: https://copperhead.co/android/ [1]: https://www.po…
A similar issue happened recently between AMD and the kernel maintainers (AMD wanted a stable API for GPU drivers that would allow the same drivers to run on Windows, Mac, desktop Linux, and Android; and AMD had already built this API and was willing to maintain it).
In the end, this can only be solved if the Linux kernel gets a stable driver API, and with Oreo, Google added exactly that for their own fork of the kernel.
Earlier quoted context omitted.
Yes, and I addressed that in my comment. Google, however, can effectively do whatever they want. If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind. I bet most of them do enough business supplying parts for Android phones that they'd get their shit together. And it' not hard! Writing an initial driver for some hardware might take a lot o…
> If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind. This leaves Google with a version of Android that does not run on anything. There are less than a handful of relevant SoM manufacturers that are capable of delivering consumer grade SoMs capable of running hardware accelerated Android; Google can not alienate these.
It has worked quite well for those that tried.
Earlier quoted context omitted.
OEMs can't do whatever they like with Android outside of China PR. They need Google play services.
Yet Google decides, sadly for us, not to use that as enforcement for the updates.
If Google would have promoted Android the way it did with Chrome OS (and the open source Chromium OS), it wouldn't be in this situation, and we'd be getting updates often. But I guess hindsight is 20/20. I still wish they did more about the support of Android devices throughout the ecosystem, not just for the highest-end devices.
Glad to see improvements are coming! Articles like this make me more and more curious whether Fuchsia is an alternative bid to resolve relevant kernel vulnerabilities in a more centralized, architecturally driven fashion, not just a way to get out from under the GPL.
Switching to Fuchsia (which will never happen because it is a toy project to occupy bored engineers) does not magically solve the problem that device vendors want to minimize the work in maintaining their drivers. Even enforcing open source drivers (for the sake of discussion) will not help, because at a certain complexity, the device driver writer requires knowledge about undocumented internals of the device that is…
Android should really use a modern kernel. All the forking mess involved in Android updates is a terrible problem predicated by the lack of generic drivers on mobile devices. Copperhead[0] has been working to apply security patches to the kernel for some time and PostMarketOS[1] has an eventual goal of using the mainline upstream kernel. Really pulling for PMOS. [0]: https://copperhead.co/android/ [1]: https://www.po…
Earlier quoted context omitted.
> If they require kernel X, and a manufacturer doesn't support it, they'll either get their shit together, or they'll get left behind. This leaves Google with a version of Android that does not run on anything. There are less than a handful of relevant SoM manufacturers that are capable of delivering consumer grade SoMs capable of running hardware accelerated Android; Google can not alienate these.
For sure Google can do it, what would they do, sell handsets with their own OS, based on a fork from GNU/Linux? It has worked quite well for those that tried.