Slashdot Mirror
Why Android Upgrades Take So Long
adeelarshad82 writes "Last month Google released the Android 4.0 'Ice Cream Sandwich' code base to the general public and manufacturers but it may be a while yet before it's actually rolled out to existing phones. In an attempt to explain why it takes so long, Motorola and Sony Ericsson shed some light on the process. Motorola described the long testing process involved in getting the new code out there, whereas Sony focused on explaining the time-consuming certification process."
So, this long and rigorous testing process is why smartphones are known for their rock-solid stability, seamless integration between hardware and software, and general lack of baffling fail, right?
OEMS: I takes time to integrate our own buggy, irremovable software into the kernel.
Summation 2
"Operators then may want to customize the software, and the OS must be localized for the market and language."
I think that is where the bulk of the time is spent.
Is it because the handset manufacturers don't make any money from the software and are probably more interested in selling you a new phone? After a year or so of support, they've generally shown almost no interest in pushing out additional upgrades as they probably don't even sell that particular model of phone any longer. Unless it's a Nexus phone, or a particularly popular model, support is pretty sketchy. There are a lot of promises to update phones to ICS, but I won't be surprised when a lot of those plans get canceled or delayed indefinitely.
Wading through the code and carrier requirements certainly tacks on some additional time, but considering that these companies don't have much incentive outside of brand loyalty, which may not even exist to any serious extent, to update their old hardware, I don't think that they try too terribly hard to get it done in a timely fashion.
(16GB to compile ICS? jesus fuck why?)
16GB recommended, not required, and it's because they're using memory-intensive optimization flags set.
I know I am going to get flamed for being an apologist, but you know that until about a year ago Dell was selling computers preloaded with Windows XP, right? Windows XP, which made its debut in 2001? They were selling (and people were glad to get) a computer with 9 year old software on it. Now we have Android OS from Google and the turnaround can be anywhere from 4 months to a year before it is running on a good portion of the install base, and we complain about it? Why? If the phone doesn't do what you want it to, don't buy it thinking that some software release will come along next week and make it all better (even if the retailers want to insist that)...
Learn from history: buy the phone that does today what you want your phone to do today. For a crowd of computer dorks who know all too well the ups and downs of the software development lifecycle, we here on /. sure do like to play dumb...
A kernel does not an operating system make.
Some of the same reasons they don't want you upgrading the OS yourself. They don't want you to get the latest features without paying them a big pile of money or extending your contract.
I'm sure they also have to make sure the latest version is festooned with crapware before they unleash it on the public.
You're welcome.
http://unlockbootloader.sonyericsson.com/
it's in my head
It actually ISN'T that complicated on the carrier side where the real delays come from, they just make it that way. When all the DRM and bloatware and crapware and bandwidth throttlers and tethering blockers and Carrier IQ loggers that are all designed to BREAK your phone or compromise its security go in, its damn difficult to make it run at all.
Look at cyanogenmod and how little time it takes them to get new versions out once they have all the roadblocks in the device figured out.
Digital is, by definition, imperfect. Analog is the way to go.
In the first Ice Cream Sandwich source code that was released, the Hardware Abstraction Layer (HAL) – the software layer giving applications direct access to the hardware components – was to some extent adapted for a Texas Instruments hardware platform. However, for all 2011 Xperia phones, we used a Qualcomm hardware platform. This means we have to replace the default HAL coming with first source code released for Ice Cream Sandwich, with our own HAL.
The HAL changes have impact on several features on a phone, including the camera, different sensors (such as proximity, light, accelerometer and compass), audio, Bluetooth, Wi-Fi, GPS, as well as multimedia and graphics components. Thus, we do not only have to modify and configure the HAL according to the Qualcomm hardware platform, but also all the other hardware components used in a phone.
Wow, I sure hope they're just mixing up terminology here. The entire point of a HAL is that you just plug in your drivers. If you have to modify the HAL because you're using different hardware than the reference device, you're doing it wrong.
You actually aren't giving a good comparison. XDA takes a long time because of the all the PURPOSEFUL breakages and blocks that are put in by the manufacturers and the carriers.
The manufacturers and carriers take a long time because they have some many artificial limiters and blocks and DRM that they all have to work together.
Google and XDA timeframes are understandable. Google is doing the REAL development work to make an Operating System. XDA is doing the best they can with what they have to work with with DRM and spyware riddled garbage.
The carriers and manufacturers spend their time screwing everything up on purpose.
Digital is, by definition, imperfect. Analog is the way to go.
Buying your own phone doesn't matter with Verizon or Sprint. Non-Sprint phones can never be activated under a Sprint account (they can roam, but never be the phone for a real Sprint account). Verizon will let you do it if you twist their arm and escalate it high enough (possibly due to a consent decree inherited from AT&T years ago), but they won't actually *help* you, and you'll never get EVDO to work, only 1xRTT due to radio firmware funkiness unique to Verizon. There's no actual engineering reason why it HAS to be this way (it's purely a matter of software and business process; the hardware is identical), but unfortunately, that's the way it is.
In theory you could buy an unsubsidized phone for AT&T or T-Mobile, but in most cases you'd only be able to use GPRS and EDGE on T-Mobile (most foreign phones can't do 1700/2100 HSPA+), and I'm pretty sure most imported phones can't do HSUPA on AT&T (and often, the only models that can do 850MHz UMTS are the ones intended for Australia, which are so expensive when imported to the US that you could almost buy a Verizon phone and pay for the service for two years for what you'd pay for the imported phone alone).
The unfortunate truth is that America's mobile phone market is as structurally fragmented and messed up as Japan's, and only slightly more likely to untangle itself over the next 25 years into something resembling tortured interoperability.
Comment removed based on user account deletion
A kernel does not an operating system make.
Yoda, is that you?
Yoda would more likely say "Make an operating system, a kernel does not."
There's a difference between Yoda-speak and German-speak. Yoda-speak is OSV (object subject verb; "a fine mess this is") or VOSv (verb, object, subject, helping verb; "help you I will"), in contrast with the SVO or SvVO order of English (and presumably of standard Galactic Basic). The "X does not Y make" pattern is SvOV, as commonly used in German and Dutch and occasionally in English until the early modern (17th century) period. It's an allusion to a Richard Lovelace poem.
The Moar You Know ...:::*
Unfortunately the manufacturer is right here. Currently in the ARM world every printed circuit board (PCB) model requires its own kernel version - even if the SoC is the same. Even if the components in the board are exactly the same, a new kernel version is required if the components are just wired differently!
Why is this? Because in the ARM world there is no any universal bus like PCI is in the x86 world. Typically components are connected by using quite primitive buses like I2C or SPI, which has no bulletproof way to do a listing of connected components. Also ARM is heavily power optimized - also in the PCB-level. There are software controlled regulators powering different components ON when needed and OFF to save power. Because there is no any standard way to do this - every manufacturer is designing the powering differently. Power and the communication bus are not connected by any means - powering the component on/off might require using a totally different bus - not told to software by the communications bus. This knowledge is typically just put (hacked) into the kernel code.
In PC world most of the hardware is initialized by BIOS and all the peripherals are usually nicely listed by the PCI bus (try lspci -command in your x86 linux box). Drivers can be easily attached into peripherals by unique device IDs. The same driver works for all boards even if the PCI bus address is different.
No such luxury in the ARM world. Typically you can see multiple versions of drivers for the exacly same component in the Linux kernel source tree. Just because the ARM architecture has brought too many obstacles for developers to easily use the same driver for different boards. You can imagine - it is a total mess. Also typically those drivers do not enter into mainline kernel so there is again more work for phone makers to port drivers for the new kernel version. Also Android kernel has some differences to normal Linux kernel.
Correct me if I'am wrong, but in my understanding the Android HAL-interface is in the user space - not kernel space. The HAL-interface might change a lot between Android versions. But not only the interface has changed - also the kernel space interfaces - those on the top manufacturer have to implement the HAL-interfaces - have changed breaking the existing drivers the manufacturer has made.
But there is hope in the future. Developers of linaro.org have work in progress and already very good demonstrations of how this mess can be sorted out. But we are not there yet and the work is huge. It needs also some common standards and practices to be adopted by the ARM hardware makers.
See also: The Ugly State of ARM Support On Linux http://linux.slashdot.org/story/11/06/20/2039229/the-ugly-state-of-arm-support-on-linux
But this ARM-problem is not just related to Linux. Windows Phone 7 is currently working only on Qualcomm SoC, probably because Microsoft wants to keep things simple at this point. Apple has solved the problem by making its own hardware and SoC and probably standardized the hardware in house.