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.
It's a bit after the fact, but 2 things to keep in mind with regards to Android phones:
1. If you can, when you are shopping for an Android phone, opt for a Google Experience Device whose software is vanilla Android and is managed directly by Google.
2. If you already have a phone with a crappy Android build, the best solution is installing a custom ROM like CyanogenMod. Most custom ROMs remove all the manufacturer junk and also tend to work well. When there are bugs that need fixing, the custom ROMs have release cycles that are measured in days or weeks, rather than months or years.
That said, I do realize that not everyone has the time, inclination and knowledge to fiddle with their phone's ROM.
I'm not sure there are any Google Experience phones for sale.
The Verizon Galaxy Nexus does not appear to be a pure Google phone -- it comes preloaded with Verizon software and I have seen no statements from either Verizon, Samsung, or Google regarding when updates will be released, or who will publish them, or if they will first have to go to Verizon. (Here's one article discussing the issue: http://www.pcmag.com/article2/0,2817,2397377,00.asp - How CDMA is killing the Galaxy Nexus)
I am very interested in this question of when/where/who will publish the Galaxy Nexus updates -- I want to replace my Nexus One with a Galaxy Nexus. But much of the value I perceived of the Nexus One is that the updates came frequently and came directly from Google.
Yes, thank you, but even in that thread Jean-Baptiste Queru doesn't seem able to say where the OTA's will come from.
It seems to demonstrate that at least the Verizon hardware will take the pure AOSP builds, but perhaps not that the OTAs will come from Verizon in a timely fashion and that they will be pure AOSP or AOSP + Verizon stuff.
Yeah, as I said in a reply below, if I'd have waited another couple months, the Nexus S would have been announced, which probably would have changed my opinion completely.
As to your option 2, that's the type of option "the old me" would have considered; which is "ok, so maybe this thing I bought sucks, but I can root it and replace the software to do the things it should have done out of the box".
I've found that avoiding that line of reasoning has made my life much better. That's not meant to disparage people who do mess around with stuff like that, I think it's awesome that you can even replace the ROMs. I just hope that people who replace the ROMS on their phones are doing it because they derive enjoyment from hacking, and not because it's necessary to make their phone actually usable.
1. The Nexus One is not 2 years old yet and will not be getting ICS. So getting a Google phone is not a guarantee.
2. Having control over your phone is great. But that is not really what you paid for. So not really a solution unless you always intended to use a custom ROM in the first place.
I have to admit though, I don't think I have ever seen anything that says any smart phone, iPhone, Android or otherwise, will have software updates for at least the contract life (2yrs) of the phone. So maybe my argument has no feet to stand on and you are getting what you paid for.
So I agree with the OP. Checkout what you will actually get and look at the manufacturers track record of actually following through.
The Nexus S 4g (sprint) was the worst phone I ever owned. Terrible reception meant calls dropped constantly and therefore the battery never lasted a whole workday. On the flipside, my Motorola Photon has great reception and battery life, but is encrusted with Motororola customizations, and apparently unlocking the bootloader disables 4g. While I love the open nature of Android and I've enjoyed CyanogenMod immensely in the past, the fact is that right now I have a fairly locked-down phone which -- though powerful --is nowhere near as fun to use as ones I've had before.
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.
What problems were you having? I have a T-mobile G2 that runs pretty well, but I don't do much on it. The last upgrade actually seemed to introduce a random shutdown, making me actually regret upgrading the OS, but that's about the only problem I have.
It's unclear to me what I really need from further OS upgrades, as I'm not currently wanting any features. If the Galaxy S is really buggy I get you, but in general, I don't get the desire to upgrade Android rapidly.
I haven't dealt with Android technically, but my assumption would be that in Linux fashion, an older version isn't necessarily a bad thing as long as it still works for you (I have a 2.4 kernel on a netbook, for instance, who needs 2.6? I think even the 2.2 and possibly 2.0 kernel branches for linux are still used by certain projects).
It's been a while, but here are the issues I remember:
* GPS was completely broken (a known and admitted issue with the T-Mobile variant of the Galaxy). If you disabled it, you could use tower triangulation to get a rough position, but that made it unusable for things like driving directions.
* Battery life was terrible (probably not specific to that model, but it didn't get through a day the whole time I had it).
* The camera was awful (not unusual for smartphones at the time, but my old crappy N73 had a camera that was easily 10x better).
* If you unplugged the headset, the phone would automatically launch the music player and start playing music through the speaker, even if the music player wasn't running.
* USB mass storage mode didn't work, so you couldn't move files to it. The only workaround was to turn on debugging on the phone, which would then let it show up in as a USB device, but you'd have to enable/disable debug every time you plugged it in, as leaving it in debug made the screen not turn off.
* Lots of crap applications that you couldn't remove.
* Most of the menus had misspellings or bizarre word choices, like it had been passed through Google Translate (a nitpick concern, I realize, but it didn't give me a lot of faith in the quality control of Samsung).
Then there were all the issues with Android itself, which aren't specific to the phone, and I really don't want to hash out here, as some of them have been fixed by now, and I really have no desire to get into a debate about the merits of the platform.
I spent the next six months or so after returning the phone to see if the issues ever got addressed, just to see what would have happened if I kept it, and it seemed like most of them were still known issues. That made me feel better about my decision to return the phone.
I can identify with most of these issues on my Captivate, and that many of them were improved or resolved by installing Cyanogenmod (the big issues, GPS and camera, remain). That isn't a legitimate option for the vast majority or smartphone buyers, but it has extended my patience with an expensive purchase not living up to the claims of its maker.
Android OS upgrades almost always come with fixes for security flaws. You wouldn't be OK running your desktop with software that hadn't gotten updates for a year, right?
Depends on what security flaws they update, I've had my linux box up for over a year before, but I don't run many services and it sits behind a router. Windows is set to autoupdate, so it reboots pretty often, though.
I'm not saying I'm against updating, but if my phone is working (luckily it currently is), I shouldn't be forced to update unless there is something that actually is a problem for me, like someone being able to send an SMS to me that does something.
All the bugs the original poster notes would make me want an update, too, but I think returning the phone was the right thing to do. If my phone was that buggy from original purchase, I wouldn't want to wait for an update, either.
My HTC Desire actually got dramatically worse on the Android 2.1 -> 2.2 update: the backup function disappeared. It's apalling there's no supported way to backup and migrate data.
Yeah, I picked up an iPhone 4 eventually, and I absolutely love it.
What annoys me, though, is that had I waited another month or two instead of buying the Galaxy S, the Nexus S came out and by most accounts was a really nice phone.
Instead, I returned the Galaxy S, and put my SIM card back into an old Nokia N73 (which despite being old and Symbian, I vastly preferred to the Galaxy S).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
That's exactly what I'm saying. With Windows, you could follow as close to the cutting edge as you wanted. With Android, your hands are tied unless you want to hack your phone. For the hacker types that have so far pushed Android adoption, this is a big deal.
Windows users were still beholden to multiple parties for current hardware drivers.
I remember trying to install a late beta of windows 95 on then recent, but not cutting edge, hardware and being stymied. A few days later I installed RedHat on the same box and it all just worked.
Much more recently, I was looking for an ExpressCard USB3 adapter, but it seemed like most of the options didn't have working drivers for 64-bit windows 7
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.
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.
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.
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.
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.
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.
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.