Slashdot Mirror
Google's 'Project Treble' Could Lead To Faster Android Updates (arstechnica.com)
Thelasko quotes a report from Ars Technica: Ahead of Google I/O, Google has just dropped a bombshell of a blog post that promises, for real this time, that it is finally doing something about Android's update problems. "Project Treble" is a plan to modularize the Android OS, separating the OS framework code from "vendor specific" hardware code. In theory, this change would allow for a new Android update to be flashed on a device without any involvement from the silicon vendor. Google calls it "the biggest change to the low-level system architecture of Android to date," and it's already live on the Google Pixel's Android O Developer Preview. This is not a magic bullet that will solve all of Android's update problems, however. After an update is released, Google lists three steps to creating an Android update:
1. Silicon manufacturers (Qualcomm, Samsung Exynos, etc) "modify the new release for their specific hardware" and do things like make sure drivers and power management will still work.
2. OEMs (Samsung, LG, HTC) step in and "modify the new release again as needed for their devices." This means making sure all the hardware works, rebranding Android with a custom skin, adding OEM apps, and modifying core parts of the Android OS to add special features like (before 7.0) multi-window support.
3. Carriers add more apps, more branding, and "test and certify the new release."
1. Silicon manufacturers (Qualcomm, Samsung Exynos, etc) "modify the new release for their specific hardware" and do things like make sure drivers and power management will still work.
2. OEMs (Samsung, LG, HTC) step in and "modify the new release again as needed for their devices." This means making sure all the hardware works, rebranding Android with a custom skin, adding OEM apps, and modifying core parts of the Android OS to add special features like (before 7.0) multi-window support.
3. Carriers add more apps, more branding, and "test and certify the new release."
More and more I just want a mobile linux device that isn't android and isn't easy/consumerified and just has mobile data and I can use SIP or other IP-phone.
What I don't need is for my mobile device to update more often! What I need is for it to want updates less often.
I don't want new features unless there is hardware that is finally small enough to be mobile. And when it happens, I want it to use one of the existing computer interface paradigms.
More and more I just want a mobile linux device that isn't android and isn't easy/consumerified and just has mobile data and I can use SIP or other IP-phone.
What I don't need is for my mobile device to update more often! What I need is for it to want updates less often.
I don't want new features unless there is hardware that is finally small enough to be mobile. And when it happens, I want it to use one of the existing computer interface paradigms.
Yes, but KB0337827328 fixes the Tagalog rendering issue!
That's been on our books for years now, and it's something you want!
This will allow third party ROMs to be built and released for nearly every phone much more easily. I envision the golden age of customized ROMs on the way.
Is it just me, or did Google's PR team just announce a hardware abstraction layer and everybody went nuts?
So, what will this do for the Android 4.2, 4.4 and 6.0 tablets I already own and are stuck at those versions? Do they continue to be abandonware?
If Google tells me I just need buy one more tablet, and it'll get system updates, "for real this time, no matter what the hardware manufacturers say or do", they can go fuck themselves. I'm done with Android.
Somehow the summary only presents the problems of the current situation (pre-project treble), instead of summarizing the key ideas of the proposal (which is very interesting, by the way). Some excerpts from the link that would help understand:
Project Treble aims to do what CTS [Compatibility Test Suite (CTS), more than a million tests to validate API compatibility] did for apps, for the Android OS framework. The core concept is to separate the vendor implementation — the device-specific, lower-level software written in large part by the silicon manufacturers — from the Android OS Framework.
This is achieved by the introduction of a new vendor interface between the Android OS framework and the vendor implementation. The new vendor interface is validated by a Vendor Test Suite (VTS), analogous to the CTS, to ensure forward compatibility of the vendor implementation.
What needs to happen is to remove step 3 from the picture. Take control of Android devices away from carriers and do what Apple does and have OEMs (including Google with its own-branded phones) be 100% responsible for updates.
Plenty of times where an OEM has released an update but carriers (making up some BS excuse but who really just want you to buy a new phone) refuse to update their branded devices (or take months to actually follow the OEM with an update)
If the vendors like Samsung... like SAMSUNG... don't want to role out Android updates in a timely manner, you still won't get them in a timely manner. Or ever.
-- I ignore anonymous replies to my comments and postings.
So, basically, Google is going to push Agile updates on everyone, and turn the userbase into alpha testers instead of just beta testers.
I can't wait.
nice that it's modular. sucks that the phone maker, chipset foundry, and carrier are still in the mix, because they don't move an inch on old phones they no longer make. so, great effort and cost for nothing. sorry, still as stiff as Gargoyle on updating.
if this is supposed to be a new economy, how come they still want my old fashioned money?
I Wonder what this means in the kernel.
But a shame as this would seem to remove a lever to help push hw vendors to GPL their drivers.
Why don't Google push vendors to open source if they want to be part of Android. Which is a pretty big stick.
Do the carriers really even want to update ? I think they want the OS to grow stale and to use that as a reason to force users to update to this weeks new hardware. The cost of maintaining the branded OS and apps on last springs 'in' phone or device is not worth it for them, they just want you to by the 'new' fashion accessory phone. Cobalt blue is the new 'secure' device dejour.
errr....umm...*whooosh* *whoosh* Is this thing on ?
There's a disconnect somewhere in the editing (go figure). In reality, the silicon and device vendors need only be involved in the initial development phase of a given device's ROM. After that, provided Google doesn't change any APIs (and they generally don't as doing so would break apps as well), the underlying Android core can be updater, even wholesale replaced, by Google.
New APIs and features can be added by Google as they are developed, and the silicon and device vendors can update their apps and drivers to take advantage of those new APIs and features, or not; the user still gets to benefit from them in the form of being able to run the newest apps on the newest version of Android. Also, security patches for the Android core can come direct from Google. Security patches for vendor-supplied apps and drivers still need to come from the vendor, but there's really nothing Google can do to change that.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
This won't be news until Google completely removes the third parties from the update equation.
What needs to happen is to remove step 3 from the picture. Take control of Android devices away from carriers
That might not do much, as Wi-Fi-only tablets routinely get stuck at a particular version of Android even though they skip step 3.
the entire lot of us stick it to the manufacturers, who refused to provide updates, in the form of a series of class action suits
Under what legal theory would a remedy be available at law? My first guess is the implied warranty of merchantability, that Internet-connected computers without security updates are not "fit for the purposes such goods are ordinarily used." But if you plan to sue on grounds of failure to honor the implied warranty, I thought it was common practice for manufacturers to disclaim implied warranties after a product's express warranty has expired.
If it depends on the jurisdiction, use the United States as an example. It's the home country of Alphabet and Slashdot Media.
Even taking the carriers out of the mix wouldn't be much better. The manufacturers hardly ever update either. With phone updates having to go through 3 steps, it's almost 100% doomed not to make it to your phone. Ever Android phone I've ever owned (with the exception of the Nexus 5x that I bought my wife), has at most only seen one update after the initial purchase.
The REAL questions that need to be addressed, is why we as consumers have allowed phones to be handled so different from PC's.
If I buy a laptop that comes with windows. When I first start it up for the first time, I give it an admin login credentials, and have full admin rights on the PC. Phones, you are locked out, with no admin rights unless you root it, which voids the warranty. Why shouldn't we have admin rights on these things by now, they are multi-purpose computers these days. People would freak out if a new laptop only came with 'basic user' login rights, and you couldn't have access to admin rights under windows. It would not be acceptable on a PC, and shouldn't be acceptable on a phone.
Also, why do the manufacture's and carriers get to 'bake' all kinds of crapware on the phone that can't be removed at all? Again, if I bought a Dell laptop, sure it might come with some Dell apps, but they can be removed. Samsung apps on a phone, not so much. Best Buy doesn't get to then add more crapware onto the Dell PC it sells as well, so that when you buy it has Dell bloatware and BestBuy bloatware baked into windows with no way to remove the apps or disable them. Phone do though, all kinds of crap from the manufacturer like Samsung store and other crap and about a dozen AT&T apps that you can't get rid of. not to mention that they bake-in normal apps too now, like my S5 has Uber preloaded, and baked in. Can't uninstall it or get rid of it. I've never used uber, and it's available in the Play store if I want it. Why is it locked onto my phone!
If Samsung wants to give it a branded skin, or some extra functionality, then fine. But if the first problem (admin rights) were respected, if we didn't like it, we would be able to easily wipe the ROM and put a vanilla android ROM on the phone like you can with a PC when you buy it. Same with the "permanent apps" that are preinstalled on the phone as well, admin rights would allow the removal of all of these. This would solve the update process, as I could opt to update to the latest version at any point. When microsoft releases a patch or update to windows, PC users don't have to wait until Dell (or HP/Asus/etc) get the update and add all their crap onto it, and pass it off to then to BestBuy/Walmart/NewEgg for the retailers to all their specific crap to it, before it gets pushed to your laptop. Why the hell does it work that way with phone?!?
It seems to me, that unfortunately, we as consumers allowed them to do this at the beginning and get away with it, and we didn't make a big enough stink over it. Now we are forever stuck with no admin rights, and several layers of 'baked-in' bloatware from everyone in the chain of manufactures and carriers. Why did we let them get away with it in the first place. And why do people accept it, when they wouldn't accept it with a PC.
Google has already done that partially by putting a lot of functionality into Google Play Services, but it would be nice to be able to get security fixes from Google instead of having the OEM's in the way.
The REAL questions that need to be addressed, is why we as consumers have allowed phones to be handled so different from PC's.
For mass market products, the market needs to create options. Currently, only 2 major options are available. Both do the same thing.
New things are always on the horizon
The law, specifically around automobiles, stipulates that manufacturers must allow aftermarket parts to be manufactured and sold, so there are still parts available and plenty of places to have a vehicle serviced even after the manufacturer shuts down the lines.
Not so for phones.
Are John Deere tractors more like automobiles or more like phones? See "American Farmers Are Still Fighting Tractor Software Locks".
"Why don't Google push vendors to open source if they want to be part of Android. Which is a pretty big stick."
The end of the blog post says:
"In addition to the architectural changes, we're working with our silicon and device partners to take their code changes, such as features for a carrier network in a specific country, and move them into the common Android Open Source Project (AOSP) codebase. For example, Sony and Qualcomm contributed dozens of features and hundreds of bugfixes to Android O so they no longer need to rework these patches with each new release of Android."
It genuinely looks like Google is doing their part to address the problems, we can only hope consumers are clever enough to buy models from OEMs who do their part too.
Maybe you mean the GPLv3.
I meant GPLv2.
The GPLv2, the version of the licence used by the Linux kernel, was written before software patents were such a problem, and doesn't have soecific requirements regarding patent licensing that the GPLv3 has.
Though the patent provisions the GPLv2 are less "soecific" than those in the GPLv3, they still exist. GPLv2 section 7 bans licensees of Linux from adding patented code under a royalty-bearing license and then distributing the result:
GPLv2 section 8 even had a geographic limit option that appears to have been dropped from GPLv3: