6 ms·

Google's Android Update Alliance Is Already Dead

82 points by adeelarshad82 15y ago

calloc 15y ago
This fragmentation is already causing issues for myself and many other developers. I work at a small startup doing gov't work and we develop Android applications that talk to massive server based backends. Yay cloud! On 2.2 we were seeing issues with the GC not firing enough, especially after shutting down a thread and no longer requiring the data allocated therein and thus we would run out of memory (heap size being set to 24 MB), on our 2.3 devices we were not seeing that issue because 1, the heap size was set to 32 MB, but 2, because our app used much less memory, from what we could see when a thread went away the GC properly cleaned up the memory associated with it, not only that but the same functionality had a difference of almost 5 MB of heap size. The 2.3 VM was more efficient compared to the 2.2 VM. We have also found many issues with BouncyCastle, the default Android encryption/decryption library that we couldn't reproduce with Java JCE, we filed bugs with BouncyCastle and they said they were features/that we were using it wrong/that they wouldn't fix it. We ended up writing our own CTR block mode (no, we didn't rewrite AES) to fix one of the many issues we found with BouncyCastle. Also, the SQLite version on the 2.x line of Android OS allows certain constructs that are technically not legal in the versions it claims to be but it accepts and ignores that bad input. The developer had taken output from MySQL workbench and put it in as SQL directly into the SQLite stuff on Android no realising some of his stuff was being ignored because it wasn't valid, no errors were thrown though. As soon as we ran our APK on an Android 3.0 tablet the app would crash because the SQLite there DOES throw errors. Yes it was a simple fix, but it shouldn't have been allowed in the first place! We also found a whole range of issues with various different keyboards that you can download from the market. Some were causing our app to crash, others would cause the text entry field to show random characters yet when reading back the text from the field in code just the user inputted stuff was there. We'd have our software designed to have a button in a certain location but with certain keyboards up the button was no longer a clickable target and you had to first exit the keyboard. Looking at our bug tracker keyboard related issues are HUGE and there are plenty. It is even worse because the same keyboard on one device may work just fine but move to another device from a different manufacturer and it may be completely broken making it hard to verify bugs do exist. We now have almost 20 test devices that we have to manually test our software on to make sure it looks right, that nothing is overlapping, and that it works correctly. Designing for multiple different sizes of screen, and then for landscape mode on those screens is absolutely horrible. On some screens elements get so stretched in landscape it just looks terrible and on others everything is so squashed together in portrait mode that it makes it hard for the user to accurately hit a target. Fragmentation is driving me personally insane. I wonder how much of my work related stress is from having to deal with that kind of crap.
- theatrus2 15y ago
  Just out of curiosity, how was CTR mode broken? Were you using the JCE provider or "direct" API?
  - calloc 15y ago
    The CTR mode in bouncy castle does not allow one to do partial block encryption. So if you want to encrypt 4 bytes you need to pad it to the full 16 bytes. It will always want to do a full block. This also means that you can't do a partial offset into the CTR. You can increment the counter correctly, but you can't start encrypting from within a partial block. Lets say you need to encrypt 17 bytes and write them to a file, which later can be opened in append mode to append more data to it using AES-128/CTR-BE mode: 1234567890ABCDEF\0 C-style terminated string. That is 2 blocks in CTR mode (1 full block used, 1 partial block (1 byte out of a 16 byte block)). The next time you open the file you want to append data to it, what you would do is this: 1. Load your previous key, and counter into AES-128/CTR 2. Increment the counter by the full blocks already used 3. Update the location into the current block by encrypting a random byte 4. Provide the rest of your plaintext which will now be correctly encrypted for appending to an already encrypted segment Now you can read your file back using the following: 1. the AES key, counter for the start of the file 2. Use CTR to "decrypt" the content from start to finish So that would look something like this in Java code with JCE: Cipher c = Cipher.getInstance("AES/CTR/NoPadding"); SecretKeySpec keySpec = new SecretKeySpec(aeskey, "AES"); IvParameterSpec ivSpec = new IvParameterSpec(iv); c.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec); I've left out some stuff like creating the iv (really the counter), so now if we wanted to advance into the first block what we could do (and this works with JCE) is this: c.update(new byte[count]); Where count contains the amount we want to offset into the next block. On JCE this does exactly what I described above, it moves forward "count" characters into the next block and then you can do: CipherOutputStream cipher_out = new CipherOutputStream(output, c); where "output" is DataOutputStream(new FileOutputStream("filename", true)) which is a file opened in append mode. Now you can write stuff to the file using the normal functions used by an OutputStream. This will then correctly append your new data to the end of the file so that if you start reading at the beginning of the file you can read through the end and get valid data. (We are using this to encrypt log files that are opened in Append only mode). Where BouncyCastle breaks down is that you can not use c.update() to move forward into the block, thus appending is not possible because if you don't end on a block boundary your next write is going to have overlap. The only thing you can do in c.update() is provide it the amount of bytes that is the same as the block size. So you have to pad all input into c.update() to 16 bytes. Basically instead of being a stream cipher that allows seeking it has become yet another block cipher.
silentscope 15y ago
In order to ensure our security and continuing stability, the Republic will be reorganized into the first Galactic Empire, for a safe and secure society which I assure you will last for ten thousand years.
- headhuntermdk 15y ago
  <lil jon>Hwhaat??</lil jon>
bad_user 15y ago
Samsung took a really long time to update Galaxy S to Android 2.3 To make matters worse, not all countries / mobile operators benefited from the update at the same time. The update for my mobile carrier was released on Sep 26th - less than 2 months ago. So after almost a year (since December 2010) waiting to get the update - I finally tried upgrading. It doesn't work. I probably have another version than the mobile carrier's norm (it was on sale, maybe that's why). Now I have to go through their service department and yell at them. And they'll probably pass the blame (mobile carrier blaming Samsung, Samsung blaming the mobile carrier). So if Samsung does update the S line, then maybe they'll surprise me for next year's Christmas.
- veeti 15y ago
  The international Galaxy S was actually the first non-Google phone to receive 2.3. It seems that the carriers are more at fault in the SGS's case.
  - bad_user 15y ago
    That could be the case, I'll don't really know. All I know is that nothing came through Kies for me.
m0nastic 15y ago
When I was debating whether or not to keep or return my Galaxy S (the most recent Android phone I owned), the crux of my concern was whether or not I had faith that Samsung/Google/T-Mobile was going to fix the laundry list of problems I was having, and if so, how long it would take. I ended up deciding to return the phone, because I didn't actually believe that it would be upgraded in a timely fashion, and it was sort of my breaking point. I felt like an idiot for buying something that was a POS on the promise that eventually it would be fixed and would be great. Over the years, I've amassed piles of kit that at the time I bought them weren't very good, but would be made "better" over time (drawer full of Maemo tablets; I'm looking squarely at you). I've had to become more cut-throat now. I don't buy something unless it actually works and does what I want it to at the time I buy it. If the thought of your Android phone (or any device) never being updated (or not being updated quickly) makes you not want to buy it, then don't buy it. I know it's made difficult by the fact that presently there's an arms race in mobile phones, and things are still getting better frequently; but I really think you'll be avoiding frustration if you just base your decisions around what the device does here and now. Odds are; they aren't going to stop drinking, or get in shape, or resolve their childhood issues, or become a dog person. If you don't love them as they are, you're just setting yourself up for disappointment.
- xer0 15y ago
  I was pretty pissed to realize that my Epic, that cost as much as a small PC, would not likely enjoy updates for very long, certainly not the life of the phone. Coincidentally, because of my personal recession I've backgraded to an old feature phone I had, and no data plan. And I'm of a mind to just stand pat when my personal economic recovery kicks in. I feel like an idiot paying that much for a phone with a short support life (and CM does not support that phone), and a horrendously expensive data plan.
- beatle 15y ago
  did you end up buying an iPhone? serious question.
  - m0nastic 15y ago
mksreddy 15y ago
I use DroidX. Moto/Verizon combo seems better than alternatives in US for Updates.
shareme 15y ago
The stumbling block is not OS customization ... Let me explain..OEMs give a price to MOs on the update services. These OEMs have consistently underestimated the number of upgrades and work required to get updates to the MOs.That under estimate impacts the resources at the OEM brought to bear on the problem.
- fpgeek 15y ago
  If you're right, then most OEMs are really missing the boat by not engaging with the Android ROM development community more seriously. Cyanogenmod (and other community projects) have already done (for Gingerbread) and are already doing (for ICS) most of the non-customization work (including many of the tedious parts) required to produce OS updates for almost all devices with an unlockable or hackable bootloader, including many of the phones that currently fall through the cracks. If OEMs focused on resolving key roadblocks (like binary graphics drivers and the 911 issue that made Cyanogenmod drop a few phones) and getting updated phones through carrier certifications, they'd spend less money and get more phones upgraded and would have a more customer-friendly, transparent process to boot.
  - vetinari 15y ago
    The development part of upgrades is not a problem, neither resources or time-wise. The real problem are certifications. Alternative firmware developers like Cyanogen or MIUI do not have bother with this, they are not selling products based on their software, but phone vendors have to go through them. This is the big sink of money and time. Recently, there were articles by Motorola and Sony Ericcson, that shed a little bit of light on this topic.
darrenhinderer 15y ago
I thought that the update alliance agreement was once the carrier released an ICS phone they had to keep it up to date, not that they had to update all their phones to ICS.
ajross 15y ago
What's really frustrating is that a clear open source strategy would just plain fix this with no cost to Google or the carriers at all. The Nexus phones (and a handful of others) get Cyanogenmod updates with new features all the time. But almost no one wants to ship a phone that the community can modify. And even Google treats CM like crap: they get no visibility into the process, so have to scramble to synchronize with each major release needlessly.
- bryanlarsen 15y ago
  It's not just that they treat CM like crap, they treat all their vendors the same way. Only the nexus team at Samsung had access to ics before launch.
  - magicalist 15y ago
    I guess it depends on what you mean by 'launch'. There was an ICS image released like a month ago, and a friend was running a CyanogenMod 9 alpha build shortly after.
  - sklnd 15y ago
    They do not[1] treat all their vendors the same way. It has been documented that Google provides early access to particular vendors, in order to suit their own desires for the launch of each version of Android. It has been going on at least since the original Droid launch on Verizon. [1] http://www.bbc.co.uk/news/technology-14836102 http://www.bbc.co.uk/news/technology-14836102
- wmf 15y ago
  I think "just use third-party ROMs" is going too easy on the phone makers. Customers deserve official updates.
  - ajross 15y ago
    That's confusing two issues. You're talking about a corporation "blessing" the use of some software on some device. I'm talking about people actually doing the work to make the software work on the device. We currently lack the latter because the former is perceived as "expensive" by the companies who need to provide the support. That equation changes rapidly if the product starts out as a blessed version of an active community project.
zmmmmm 15y ago
seems a tiny bit early to declare it "dead". the crux of the article is that some manufacturers didn't respond to their emails yet or haven't made up their minds. most of them only got the ICS source a couple of weeks ago - it doesn't seem entirely unreasonable that they are still figuring out which devices they can support.
paul9290 15y ago
This is one of three facts why I prefer other mobile OS's over Android. Other reasons - there are so many Android phones which for me water downs the excitement for the platform. The issue that all apps are not available on all Android phones and there is no Android/Google store to take my device to for a quick fix. Hopefully they solve these issues when Google/Motorola starts releasing phones; force other manufacturers to follow same UX/UI. Also, possibly open stores as Sony & Microsoft has done following Apple's lead.
cageface 15y ago
People like to analogize the Android vs iOS battle of today with yesterday's Mac vs Windows battle to make gloomy predictions about the long-term market share prospects of iOS. But would Windows have been so successful with a host of meddlesome third parties deploying major updates out of sync according to their own various incompatible agendas?
- potatolicious 15y ago
  Sorry, but I'm not really parsing your post correctly. You're saying that people are comparing iOS with Android, and drawing parallels to Mac vs. Windows, and saying that in the end the more open, free-form platform will win (i.e. Windows triumphant over Mac). But Windows did (and still does) have a host of meddlesome third parties all deploying major software out of sync with each other according to their own whims. It's succeeded despite that. Think: graphics drivers, browsers, office suites, etc etc. I don't think this is really the issue, the issue is that most Android users have no ability to upgrade their phones. Even if you buy a store-configured Dell box, when Windows 8 comes out, you can drive to Best Buy, get a copy of Windows, come home, pop the disc in, and bam, you've got all the new hotness. Android would be a lot more compelling if users could do this. I'm sure a significant segment of the market would even pay for such upgrades. As it is though, regardless of willingness to pay, the average Android user cannot install new versions until their OEM allows it. This actually reminds me more of old graphics drivers. In the old days, no matter what graphics chipset you had in your laptop, you couldn't get drivers directly from NVidia/ATI/etc. You had to wait until your OEM (Dell/Toshiba/Lenovo/etc) ported the reference drivers and released them to you. Suffice it to say, they didn't do this. At all, and mobile graphics chipsets were a nightmare of incompatibilities, bugs, and general misery. At some point NVidia started requiring all their vendors make their hardware compatible with the reference driver, and started offering drivers themselves. The situation improved dramatically almost overnight. Maybe this is what Google needs.
  - jsight 15y ago
    How many real PC end-users upgrade their operating systems? In the long run, this matters even less for Android than it does now.
navs 15y ago
So in the end, pick a Stock Android phone. I recently upgraded my iPhone3G to an iPhone 4. Hopefully, I'll get the latest updates for the next 2 years. Hopefully.
gangadhargs 15y ago
Why would the device manufacturers and carriers offer automatic upgrades if the new OS makes the users want to buy new devices? This is also a factor to be considered.

82 points by adeelarshad82 15y ago

This fragmentation is already causing issues for myself and many other developers. I work at a small startup doing gov't work and we develop Android applications that talk to massive server based backends. Yay cloud! On 2.2 we were seeing issues with the GC not firing enough, especially after shutting down a thread and no longer requiring the data allocated therein and thus we would run out of memory (heap size being set to 24 MB), on our 2.3 devices we were not seeing that issue because 1, the heap size was set to 32 MB, but 2, because our app used much less memory, from what we could see when a thread went away the GC properly cleaned up the memory associated with it, not only that but the same functionality had a difference of almost 5 MB of heap size. The 2.3 VM was more efficient compared to the 2.2 VM. We have also found many issues with BouncyCastle, the default Android encryption/decryption library that we couldn't reproduce with Java JCE, we filed bugs with BouncyCastle and they said they were features/that we were using it wrong/that they wouldn't fix it. We ended up writing our own CTR block mode (no, we didn't rewrite AES) to fix one of the many issues we found with BouncyCastle. Also, the SQLite version on the 2.x line of Android OS allows certain constructs that are technically not legal in the versions it claims to be but it accepts and ignores that bad input. The developer had taken output from MySQL workbench and put it in as SQL directly into the SQLite stuff on Android no realising some of his stuff was being ignored because it wasn't valid, no errors were thrown though. As soon as we ran our APK on an Android 3.0 tablet the app would crash because the SQLite there DOES throw errors. Yes it was a simple fix, but it shouldn't have been allowed in the first place! We also found a whole range of issues with various different keyboards that you can download from the market. Some were causing our app to crash, others would cause the text entry field to show random characters yet when reading back the text from the field in code just the user inputted stuff was there. We'd have our software designed to have a button in a certain location but with certain keyboards up the button was no longer a clickable target and you had to first exit the keyboard. Looking at our bug tracker keyboard related issues are HUGE and there are plenty. It is even worse because the same keyboard on one device may work just fine but move to another device from a different manufacturer and it may be completely broken making it hard to verify bugs do exist. We now have almost 20 test devices that we have to manually test our software on to make sure it looks right, that nothing is overlapping, and that it works correctly. Designing for multiple different sizes of screen, and then for landscape mode on those screens is absolutely horrible. On some screens elements get so stretched in landscape it just looks terrible and on others everything is so squashed together in portrait mode that it makes it hard for the user to accurately hit a target. Fragmentation is driving me personally insane. I wonder how much of my work related stress is from having to deal with that kind of crap.

theatrus2 15y ago
Just out of curiosity, how was CTR mode broken? Were you using the JCE provider or "direct" API?
- calloc 15y ago
  The CTR mode in bouncy castle does not allow one to do partial block encryption. So if you want to encrypt 4 bytes you need to pad it to the full 16 bytes. It will always want to do a full block. This also means that you can't do a partial offset into the CTR. You can increment the counter correctly, but you can't start encrypting from within a partial block. Lets say you need to encrypt 17 bytes and write them to a file, which later can be opened in append mode to append more data to it using AES-128/CTR-BE mode: 1234567890ABCDEF\0 C-style terminated string. That is 2 blocks in CTR mode (1 full block used, 1 partial block (1 byte out of a 16 byte block)). The next time you open the file you want to append data to it, what you would do is this: 1. Load your previous key, and counter into AES-128/CTR 2. Increment the counter by the full blocks already used 3. Update the location into the current block by encrypting a random byte 4. Provide the rest of your plaintext which will now be correctly encrypted for appending to an already encrypted segment Now you can read your file back using the following: 1. the AES key, counter for the start of the file 2. Use CTR to "decrypt" the content from start to finish So that would look something like this in Java code with JCE: Cipher c = Cipher.getInstance("AES/CTR/NoPadding"); SecretKeySpec keySpec = new SecretKeySpec(aeskey, "AES"); IvParameterSpec ivSpec = new IvParameterSpec(iv); c.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec); I've left out some stuff like creating the iv (really the counter), so now if we wanted to advance into the first block what we could do (and this works with JCE) is this: c.update(new byte[count]); Where count contains the amount we want to offset into the next block. On JCE this does exactly what I described above, it moves forward "count" characters into the next block and then you can do: CipherOutputStream cipher_out = new CipherOutputStream(output, c); where "output" is DataOutputStream(new FileOutputStream("filename", true)) which is a file opened in append mode. Now you can write stuff to the file using the normal functions used by an OutputStream. This will then correctly append your new data to the end of the file so that if you start reading at the beginning of the file you can read through the end and get valid data. (We are using this to encrypt log files that are opened in Append only mode). Where BouncyCastle breaks down is that you can not use c.update() to move forward into the block, thus appending is not possible because if you don't end on a block boundary your next write is going to have overlap. The only thing you can do in c.update() is provide it the amount of bytes that is the same as the block size. So you have to pad all input into c.update() to 16 bytes. Basically instead of being a stream cipher that allows seeking it has become yet another block cipher.

silentscope 15y ago

In order to ensure our security and continuing stability, the Republic will be reorganized into the first Galactic Empire, for a safe and secure society which I assure you will last for ten thousand years.

headhuntermdk 15y ago
<lil jon>Hwhaat??</lil jon>

bad_user 15y ago

Samsung took a really long time to update Galaxy S to Android 2.3 To make matters worse, not all countries / mobile operators benefited from the update at the same time. The update for my mobile carrier was released on Sep 26th - less than 2 months ago. So after almost a year (since December 2010) waiting to get the update - I finally tried upgrading. It doesn't work. I probably have another version than the mobile carrier's norm (it was on sale, maybe that's why). Now I have to go through their service department and yell at them. And they'll probably pass the blame (mobile carrier blaming Samsung, Samsung blaming the mobile carrier). So if Samsung does update the S line, then maybe they'll surprise me for next year's Christmas.

veeti 15y ago
The international Galaxy S was actually the first non-Google phone to receive 2.3. It seems that the carriers are more at fault in the SGS's case.
- bad_user 15y ago
  That could be the case, I'll don't really know. All I know is that nothing came through Kies for me.

m0nastic 15y ago

When I was debating whether or not to keep or return my Galaxy S (the most recent Android phone I owned), the crux of my concern was whether or not I had faith that Samsung/Google/T-Mobile was going to fix the laundry list of problems I was having, and if so, how long it would take. I ended up deciding to return the phone, because I didn't actually believe that it would be upgraded in a timely fashion, and it was sort of my breaking point. I felt like an idiot for buying something that was a POS on the promise that eventually it would be fixed and would be great. Over the years, I've amassed piles of kit that at the time I bought them weren't very good, but would be made "better" over time (drawer full of Maemo tablets; I'm looking squarely at you). I've had to become more cut-throat now. I don't buy something unless it actually works and does what I want it to at the time I buy it. If the thought of your Android phone (or any device) never being updated (or not being updated quickly) makes you not want to buy it, then don't buy it. I know it's made difficult by the fact that presently there's an arms race in mobile phones, and things are still getting better frequently; but I really think you'll be avoiding frustration if you just base your decisions around what the device does here and now. Odds are; they aren't going to stop drinking, or get in shape, or resolve their childhood issues, or become a dog person. If you don't love them as they are, you're just setting yourself up for disappointment.

xer0 15y ago
I was pretty pissed to realize that my Epic, that cost as much as a small PC, would not likely enjoy updates for very long, certainly not the life of the phone. Coincidentally, because of my personal recession I've backgraded to an old feature phone I had, and no data plan. And I'm of a mind to just stand pat when my personal economic recovery kicks in. I feel like an idiot paying that much for a phone with a short support life (and CM does not support that phone), and a horrendously expensive data plan.
beatle 15y ago
did you end up buying an iPhone? serious question.
- m0nastic 15y ago

mksreddy 15y ago

I use DroidX. Moto/Verizon combo seems better than alternatives in US for Updates.

shareme 15y ago

The stumbling block is not OS customization ... Let me explain..OEMs give a price to MOs on the update services. These OEMs have consistently underestimated the number of upgrades and work required to get updates to the MOs.That under estimate impacts the resources at the OEM brought to bear on the problem.

fpgeek 15y ago
If you're right, then most OEMs are really missing the boat by not engaging with the Android ROM development community more seriously. Cyanogenmod (and other community projects) have already done (for Gingerbread) and are already doing (for ICS) most of the non-customization work (including many of the tedious parts) required to produce OS updates for almost all devices with an unlockable or hackable bootloader, including many of the phones that currently fall through the cracks. If OEMs focused on resolving key roadblocks (like binary graphics drivers and the 911 issue that made Cyanogenmod drop a few phones) and getting updated phones through carrier certifications, they'd spend less money and get more phones upgraded and would have a more customer-friendly, transparent process to boot.
- vetinari 15y ago
  The development part of upgrades is not a problem, neither resources or time-wise. The real problem are certifications. Alternative firmware developers like Cyanogen or MIUI do not have bother with this, they are not selling products based on their software, but phone vendors have to go through them. This is the big sink of money and time. Recently, there were articles by Motorola and Sony Ericcson, that shed a little bit of light on this topic.

darrenhinderer 15y ago

I thought that the update alliance agreement was once the carrier released an ICS phone they had to keep it up to date, not that they had to update all their phones to ICS.

ajross 15y ago

What's really frustrating is that a clear open source strategy would just plain fix this with no cost to Google or the carriers at all. The Nexus phones (and a handful of others) get Cyanogenmod updates with new features all the time. But almost no one wants to ship a phone that the community can modify. And even Google treats CM like crap: they get no visibility into the process, so have to scramble to synchronize with each major release needlessly.

bryanlarsen 15y ago
It's not just that they treat CM like crap, they treat all their vendors the same way. Only the nexus team at Samsung had access to ics before launch.
- magicalist 15y ago
  I guess it depends on what you mean by 'launch'. There was an ICS image released like a month ago, and a friend was running a CyanogenMod 9 alpha build shortly after.
- sklnd 15y ago
  They do not[1] treat all their vendors the same way. It has been documented that Google provides early access to particular vendors, in order to suit their own desires for the launch of each version of Android. It has been going on at least since the original Droid launch on Verizon. [1] http://www.bbc.co.uk/news/technology-14836102 http://www.bbc.co.uk/news/technology-14836102
wmf 15y ago
I think "just use third-party ROMs" is going too easy on the phone makers. Customers deserve official updates.
- ajross 15y ago
  That's confusing two issues. You're talking about a corporation "blessing" the use of some software on some device. I'm talking about people actually doing the work to make the software work on the device. We currently lack the latter because the former is perceived as "expensive" by the companies who need to provide the support. That equation changes rapidly if the product starts out as a blessed version of an active community project.

zmmmmm 15y ago

seems a tiny bit early to declare it "dead". the crux of the article is that some manufacturers didn't respond to their emails yet or haven't made up their minds. most of them only got the ICS source a couple of weeks ago - it doesn't seem entirely unreasonable that they are still figuring out which devices they can support.

paul9290 15y ago

This is one of three facts why I prefer other mobile OS's over Android. Other reasons - there are so many Android phones which for me water downs the excitement for the platform. The issue that all apps are not available on all Android phones and there is no Android/Google store to take my device to for a quick fix. Hopefully they solve these issues when Google/Motorola starts releasing phones; force other manufacturers to follow same UX/UI. Also, possibly open stores as Sony & Microsoft has done following Apple's lead.

cageface 15y ago

People like to analogize the Android vs iOS battle of today with yesterday's Mac vs Windows battle to make gloomy predictions about the long-term market share prospects of iOS. But would Windows have been so successful with a host of meddlesome third parties deploying major updates out of sync according to their own various incompatible agendas?

potatolicious 15y ago
Sorry, but I'm not really parsing your post correctly. You're saying that people are comparing iOS with Android, and drawing parallels to Mac vs. Windows, and saying that in the end the more open, free-form platform will win (i.e. Windows triumphant over Mac). But Windows did (and still does) have a host of meddlesome third parties all deploying major software out of sync with each other according to their own whims. It's succeeded despite that. Think: graphics drivers, browsers, office suites, etc etc. I don't think this is really the issue, the issue is that most Android users have no ability to upgrade their phones. Even if you buy a store-configured Dell box, when Windows 8 comes out, you can drive to Best Buy, get a copy of Windows, come home, pop the disc in, and bam, you've got all the new hotness. Android would be a lot more compelling if users could do this. I'm sure a significant segment of the market would even pay for such upgrades. As it is though, regardless of willingness to pay, the average Android user cannot install new versions until their OEM allows it. This actually reminds me more of old graphics drivers. In the old days, no matter what graphics chipset you had in your laptop, you couldn't get drivers directly from NVidia/ATI/etc. You had to wait until your OEM (Dell/Toshiba/Lenovo/etc) ported the reference drivers and released them to you. Suffice it to say, they didn't do this. At all, and mobile graphics chipsets were a nightmare of incompatibilities, bugs, and general misery. At some point NVidia started requiring all their vendors make their hardware compatible with the reference driver, and started offering drivers themselves. The situation improved dramatically almost overnight. Maybe this is what Google needs.
- jsight 15y ago
  How many real PC end-users upgrade their operating systems? In the long run, this matters even less for Android than it does now.

navs 15y ago

So in the end, pick a Stock Android phone. I recently upgraded my iPhone3G to an iPhone 4. Hopefully, I'll get the latest updates for the next 2 years. Hopefully.

gangadhargs 15y ago

Why would the device manufacturers and carriers offer automatic upgrades if the new OS makes the users want to buy new devices? This is also a factor to be considered.