

Google's Android Update Alliance Is Already Dead - adeelarshad82
http://www.pcmag.com/article2/0,2817,2397729,00.asp

======
m0nastic
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.

~~~
theoj
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.

~~~
jerrya
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)

Even the imported GSM Galaxy Nexus is being questioned as perhaps not a google
phone as it seems to have shipped with substantially different roms that may
have different update policies. ([http://www.xda-developers.com/android/is-
the-galaxy-nexus-st...](http://www.xda-developers.com/android/is-the-galaxy-
nexus-still-a-nexus/) <https://news.ycombinator.com/item?id=3341959> )

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.

~~~
tonfa
> The Verizon Galaxy Nexus does not appear to be a pure Google phone

If Google publishes the base firmware (which is the case for the Verizon
version), it probably counts as a Google experience device.

[https://groups.google.com/forum/#!msg/android-
building/mpRKT...](https://groups.google.com/forum/#!msg/android-
building/mpRKTbyNI8U/XRq0yScuAPYJ)

~~~
jerrya
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.

------
calloc
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
Just out of curiosity, how was CTR mode broken? Were you using the JCE
provider or "direct" API?

~~~
calloc
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.

~~~
X-Istence
I've written code for this before, I have it over at Github:

<https://gist.github.com/fd98541dd158d7e7be9e>

So if anyone wants a full example they can run and play with themselves. Your
example stuff looks like it was pulled from the code I wrote above...

~~~
calloc
Yes, I found your stuff through a Stackoverflow post you created.

------
ajross
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
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.

~~~
sklnd
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>

------
bad_user
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
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
That could be the case, I'll don't really know. All I know is that nothing
came through Kies for me.

------
darrenhinderer
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.

------
paul9290
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
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
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.

~~~
cageface
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.

~~~
easp
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

------
zmmmmm
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.

------
navs
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.

------
shareme
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
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
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.

------
gangadhargs
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.

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

------
silentscope
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
<lil jon>Hwhaat??</lil jon>

