How Google updated Android without releasing version 4.3 | Hacker News Reader

How Google updated Android without releasing version 4.3

arstechnica.com

90 pointsshawndumas29 comments

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.

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!)

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.

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

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.

I think you're underestimating the value of the publicity Apple gets with each new iOS update. By releasing a slew of new features in one go, at a high profile keynote presentation, they get maximum exposure. If they just pushed out a safari update randomly during the year the geeky tech press might cover it, but they'd get zero mainstream media coverage. For Google it makes no difference because they werent going to get the mainstream coverage anyway.

When there's a new iOS version and iPhone out my wife asks about it because all her nursey mates on the ward are talking about it. It's think how much that's worth.

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.

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

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

I wonder why Google does not make a "Google suite" available for download. What would be the down-side to providing the Google ecosystem, as an installable package, to, for example, Amazon Kindle users? Android has very good app compatibility across the same API level even when Android has been heavily modified, as in Kindle.

Doing that would not only make it possible for emulators to run an environment that is similar to a Nexus device, it would enable end-users to join the ecosystem that Google makes money for Google even if their Android device isn't an official Google device.

I could have sworn they announced emulator support in yesterday's Google Play Services session. Maybe I completely misunderstood what they were talking about (was developing at the time).

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.

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.

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.

And then Apple releases another form factor and developers scramble!

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.

They'll change, some things will break, we'll endure thousands of blog posts proclaiming the end of the iPhone, 80% of devs will race to fix their apps, life will go on...

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.

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.

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

You can already do that. At least with Chrome. Are you referring to the old stock browser?

yeah, sry. this.

Right now?

https://play.google.com/store/apps/details?id=org.mozilla.fi...

i run ff mobile nightly also.

The stock browser (on my old Galaxy Nexus) and Dolphin (on my newer phone) are the only browsers that don't screw up the font size depending on the depth of the displayable text in the DOM tree.

If you're lucky enough to have a stock browser and didn't need to installing Dolphin I'd say you should count yourself lucky.

I have a community of 30,000 users who all complain about the font sizing issue on mobile, and the vast majority of whom use Android and have had to install Dolphin to overcome this single issue.

Unfortunately the software we're using is so restricted in it's templating system that it's unresolvable by us (short of replacing the whole system which we're doing but takes more time). It's crappy to tell people not to use Chrome or Firefox, but there you go.

Take joy in the stock browser whilst it still does sane things.

Edit: And don't get me started on how many sites have CSS menus that simply do not work in Chrome on Android. They work everywhere else, but just not Chrome on Android. Again, be thankful you haven't been upgraded... you've got something that works.

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?

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

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

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.

Reply on news.ycombinator.com