
How Google updated Android without releasing version 4.3 - shawndumas
http://arstechnica.com/gadgets/2013/05/how-google-updated-android-without-releasing-version-4-3/
======
HorizonXP
Having done quite a bit of Android development in the past few months, and for
the foreseeable future, I'd have to say that people really are missing the
point of OS releases.

The way Google is currently updating their core apps is the right way to do
it, and should have been done from the beginning. Honestly, it seems counter-
intuitive that it isn't that way on iOS. I realize why, Apple does stuff that
requires tight OS-level integration that they don't expose to others. But the
fact that Google and BlackBerry do this means to me that Apple made an
architectural choice that will ultimately slow their speed of deployment of
key updates. BlackBerry and Google can update their maps apps whenever they
want, and regularly do. Apple had to wait for an OS release.

With all that said, I am tremendously disappointed that we didn't see another
Android point release. I understand why to an extent, but there are glaring
omissions in the OS that make it exceedingly difficult to build an app that
has significant features that interface with hardware and peripherals. The
Camera API is lackluster, and the Bluetooth support (Or lack thereof ) is just
shameful.

The only saving grace of Android is that you can fix these problems yourself,
if you know what you're doing. But it isn't easy, and is beyond they
capabilities of most devs.

Here's hoping Apple announces something awesome at WWDC. I still love Android
for what it is, but they do need to catch up in a few key areas.

~~~
drivebyacct2
Android is getting a better BT stack for 4.3. Big improvements including LE
and multimedia protocol (the name escapes me). Rumor has it, it was meant to
be announced yesterday. The Bluetooth group accidentally releasing something
acknowledging new functionality in a new point release of Android (oops, not
yet!)

~~~
HorizonXP
AVRCP? Is that what you meant?

I honestly haven't explored the Bluetooth stack too extensively, but I know
the lack of a unified LE stack hurt a number of people I know developing
products. And it will have ramifications for a long time due to the slow pace
of OS updates on the platform.

It's the decisions that Google made when implementing the Camera and
MediaRecorder classes that hurt me the most, and will continue to for a long
time going forward. What's easy on iOS and BlackBerry 10 is exceedingly
difficult on Android. It's a PITA, but also a good thing for me since it makes
the barrier to entry by my competitors much higher that I can rest a bit
easier. And I can take a page from Google's book and port it back to older OS
versions to fix it on all devices so that other devs can use it. Such are the
pros and cons of the platform.

~~~
drivebyacct2
I can't really speak to the other points in your post, I either don't know or
have no experience, etc.

That having been said, if you want more BT info, I can help :P

edit: forget those links, I should've known to just seek out the Android
Police article - most details including AVCHR or whatever it is:
[http://www.androidpolice.com/2013/05/15/bluetooth-low-
energy...](http://www.androidpolice.com/2013/05/15/bluetooth-low-energy-and-
avrcp-1-3-coming-to-android-with-api-level-18/)

~~~
HorizonXP
Good to see this. But like I said, because they're so late to the party, the
impact it has had on the peripheral and hardware scene will last for a few
more years still.

------
clumsysmurf
One unfortunate side effect of adding APIs to Google Play Services, is that it
becomes almost impossible to test your app on Google's own SDK emulators. Play
Services does not run in any emulator. You can try to find the Vending and
related apks from CM or wherever, but Google doesn't help you do that .. and
its a pain ;)

So if you want to use the new Play Services Maps API, you'll need a device.

I really wish they would find a workaround, because I use the x86 emulators to
test various screen configurations.

Also, while this does provide a layer Google can update independently, it
doesn't impact most of the OS. So security fixes, or fixes to the framework,
sqlite, dvm, kernel drivers, still need to be handled differently.

~~~
soyangel
You can use AndroVM for this. It's a VirtualBox image with Google Play and
speed like the Intel one.

~~~
clumsysmurf
AndroVM is now a commercial product; I'd rather Google just improve the
experience of the official SDK tools.

------
akennberg
Or, they simply allowed for apps to release on their own schedule, because the
OS point version wasn't ready. If they could of announced it all together they
would of.

This, however, does nothing to solve update fragmentation. OS updates change
the OS, and certain devices simply don't have the memory, or other hardware
restrictions, to allow for newer updates. Those did not include app-stuff, the
app announcements were just coupled with OS announcement.

~~~
ChrisClark
It's not actually about the apps being de-coupled from the OS. It's all about
the Android compatibility library and the Google Play Services library that
gets pushed to all devices through the Play Store is the important part.

When they introduced fragments in 3.0 they decided to backport them and push
them out to older devices. All the new UI libraries get pushed out to older
devices, this allows app developers to use some of the latest and greatest
parts of Android on all versions.

It's kind of strange they didn't include the Action Bar in the library, but
Action Bar Sherlock takes care of that.

With the addition of Sherlock you can follow the latest UI guidelines and APIs
without much worry. It makes it extremely easy then to support multiple sized
devices, small phones, tablets, laptops.

There is some fragmentation in other parts, like sensors and cameras and such
that can be troublesome, but for most apps there really isn't a fragmentation
problem. I've never run into anything that wasn't solved in an afternoon.

Of course, if you compared it to writing for iOS, yes it's trickier. If an iOS
developer decides to jump into Android without actually learning how the UI
works, he's going to have a horrible time. iOS design can almost be pixel
perfect, Android is more like a responsive CSS design.

Without the compatibility library being pushed to older devices a lot of this
wouldn't be possible.

~~~
eridius
_iOS design can almost be pixel perfect_

I would go so far as to say that iOS design can be and often _is_ pixel
perfect.

~~~
zmmmmm
It's going to be really interesting if (as rumoured) they make major UI theme
changes in iOS7. Until now Apple has reaped the benefits but not really had to
pay the true price for the relatively inflexible approach with the UI. If they
update the UI to look different, every app that hard coded images, colors,
dimensions or other facets of the UI is going to suddenly look broken. It'll
be really interesting to see how it goes.

~~~
rimantas
Not sure if I follow. If app uses custom styling it means it does not use OS
theme, and hence is not influenced by its change. Also, developers will get an
early access so they can test and fix things in advance.

~~~
RyanZAG
Some apps use default styling for half of their UI, and custom for the other
half. When the default styling changes, it's going to have a strange effect of
the custom components no longer fitting in.

------
leeoniya
when can i update the [stock] browser without the os? when google?

~~~
bad_user
Right now?

[https://play.google.com/store/apps/details?id=org.mozilla.fi...](https://play.google.com/store/apps/details?id=org.mozilla.firefox&hl=en)

~~~
leeoniya
i run ff mobile nightly also.

------
ZeroGravitas
Google's been doing this for literally years. Why has the internet only just
noticed this, and now that they have why haven't they realised this isn't a
new thing?

------
senthilnayagam
android device manufacturers and telecom companies have no incentive for
updating the OS, they would prefer to sell new devices with new releases, so
chrome style versioning is the reason for the mess.

lets not compare iOS, Apple devices are pricier but they are fully supported
for hardware and software for 3years, and most users do update their operating
systems within days and weeks of a new release

------
drivebyacct2
Koush had a similar (and far more succinct) conclusion for those familiar with
him or Android that don't need Ars' verboseness:
[https://plus.google.com/103583939320326217147/posts/QiNCtSxu...](https://plus.google.com/103583939320326217147/posts/QiNCtSxuYNg)

~~~
mtgx
Sounds great to me. Google needs more standardization in the Android
ecosystem, not less. The fragmentation problems were bad enough as they were.
This should fix the problem quite a bit, at least for developers.

