Android's Andy Rubin is deluded

[MrCrispy]

http://www.engadget.com/2011/10/19/liveblog-from-asiad-andy-rubin-svp-of-mobile-at-google/

"Andy's making it super clear that ICS is killing this notion. If you're hunting for a Twitter app that looks different + takes advantage of the tablet screen space, don't count on it. Odd.

7:21AM Walt's suggesting that there are extremely few "tablet-optimized" apps on Android tablets. Andy: "There shouldn't be tablet-specific apps. It's not necessary to make the distinction. If someone writes an ICS app, it'll run on both. That's the remerging of these things. I want an app written on TVs to run on phones."

So an app on my phone should look the same on a tablet? Wtf?


"Walt accurately points out that we're raging on companies rolling out Android updates at random intervals, but Andy still says even that's not "called fragmentation." "It's called legacy," says Andy."

No you idiot, its fragmentation because you large parts of your user base with old Android versions who can't update their phones and have different user experiences. In fact its the very definition of fragmentation, and they refuse to even acknowledge it.

 

[Elledan]

I'm a professional Android dev and I really hope that Google shapes up and that ICS is the beginning of the end of the glitchy, incomplete APIs, missing features, laughable hardware performance (audio on Android is a sad joke) and so on. I'd also like them to allow us to use C++ without having to go through JNI, but I doubt that they'll be that kind

An app doesn't have to look exactly the same on a phone and a tablet, but it can use different layouts which have the same appearance, but re-arrange things to make them more suitable for the different resolutions and orientations.

 

[Tower]

Regarding applications running the same on different platforms:

The point Rubin is trying to illustrate is that applications that run on Android simply run on Android--a phone, a tablet, Google TV, or otherwise.

If you delve into the Android developer frameworks, you'll discover different views designed for differing device sizes. Additionally, fragments are a specific UI addition to views that help facilitate better UI/UX on different platforms.

Tools are in place to allow developers to determine device size and adjust or update their UI/UX as they prefer. For example, in Gmail on a phone, you view a single inbox at any given time. The developer can elect (when a device is detected with a larger screen) to display a "Fragment", which is a specific (and new as of Honeycomb) view addition which can show your inbox on one half of the screen, and devote the other half of the screen to reading any given selected email.

...Or, maybe the developer is lazy and didn't add any specific tablet or Google TV functionality to their application, and all you see is the phone UI/UX. It's dependent on the developer to take advantage of the tools available to them to craft whatever UI/UX they're aiming for.

The idea is that the platform is the same, and an application doesn't have to be written specifically for a device, or a platform--it's written specifically for Android. This does not mean that applications cannot, or should not, be optimized for an experience. It's an emphasis on universal support across any Android platform.

Regarding fragmentation:

Fragmentation is legacy. I feel like individuals who make comments regarding fragmentation do not have a firm grasp on the concept and are certainly not developers. I don't mean this in a derogatory way; rather, I want to explain why this is the case so it makes more sense to you.

These concepts apply to any software, but I'm going to use Android as it's the focal point.

Imagine you're working on Android. Your job is to design a function that synchronizes the user's data with Google's cloud services; your code pushes data from the phone to the cloud, and vice versa can retrieve it from the cloud and update a user's device. Pretty critical job, right?

In Android 1.0, you're told that you must synchronize Contacts, the Calendar, and Gmail. That's it. So you set off to work, and you write some amazing code, and your new API for synchronizing data is released to the public. Here is what it looks like:

bool SynchronizeData(Platform platform);

You instruct users via the SDK that they can call SynchronizeData with a platform object (which is just a piece of data), and perhaps there is a different function in the SDK that (when called) returns a platform object that represents the currently-running version of Android. Great, so now users can use your API like this:

Platform myPlatform = GetCurrentPlatform();
bool success;
success = SynchronizeData(myPlatform);

This is great; you can call SynchronizeData, which will synchronize Contacts, Calendar and Gmail for you automatically between your device and the cloud. Your API is flexible, so that in the future, with whatever changes that brings, it can be updated for differences as well.

Now, fast forward to Android 1.6, and you're informed that your API must also be able to store information about Wireless networks to the cloud, so that users don't need to re-enter those values when they reset their phone, get a new phone, etc. So now you need to make background changes to your API. However, because your API accepts a platform object, the same call is still valid for Android 1.0 and 1.6, even though the phone will do two different things (based on the OS.)

However, now Google decides that you might want to synchronize your Contacts independently of the rest of your data. Well.. crap. Your API only allows you to perform a synchronization on all of the data at once--even though it's smart enough to synchronize specific data based on OS.

Now you have to write a new function called SynchronizeContacts(Platform platform), which also takes a platform object. This is important because the data contacts can hold has changed between 1.0 and 1.6, and may change again in the future.

Now the "Synchronize Data" API has two functions:

SynchronizeData(Platform platform);
SynchronizeContacts(Platform platform);

Developers can still write code for Android 1.6 and use SynchronizeData() or they can be more specific and call just SynchronizeContacts() if that's all they need to do. Android 1.6 gives them expanded power, and in turn, the operation is faster because there is less data to synchronize.

This is just a single, small example. Imagine all of the components of Android (or any software), all the functionality, etc. Google continues to support the same APIs that were present in Android 1.0 (for the most part), but is constantly expanding to add new features and functionality to improve Android and make it a better experience. The APIs at the core of Android are still the same APIs that were designed for 1.0, although there are also newer APIs that can be optionally taken advantage of.

This is the life cycle of software. This happens to Windows, to OS X, to iOS, and to Android. The same things are true in iOS 4 as compared to iOS 5.

In closing:

Does this help you understand the nature of development and fragmentation on any platform?

 

[CHANG3D]

I'm a professional Android dev and I really hope that Google shapes up and that ICS is the beginning of the end of the glitchy, incomplete APIs, missing features, laughable hardware performance (audio on Android is a sad joke) and so on. I'd also like them to allow us to use C++ without having to go through JNI, but I doubt that they'll be that kind

Ain't gonna happen! It's Google! Gotta love them for listing things and code examples in their developer's guide that don't frigging work!

 

[Elledan]

Ain't gonna happen! It's Google! Gotta love them for listing things and code examples in their developer's guide that don't frigging work!

Call me silly but I actually have hopes for ICS

 

[Electrofreak]

Regarding applications running the same on different platforms:

[STUFF]

Does this help you understand the nature of development and fragmentation on any platform?

I found that extremely informative and I appreciate your post! Its rare that I get that kind of insight.

 

[kllrnohj]

http://www.engadget.com/2011/10/19/liveblog-from-asiad-andy-rubin-svp-of-mobile-at-google/

"Andy's making it super clear that ICS is killing this notion. If you're hunting for a Twitter app that looks different + takes advantage of the tablet screen space, don't count on it. Odd.

7:21AM Walt's suggesting that there are extremely few "tablet-optimized" apps on Android tablets. Andy: "There shouldn't be tablet-specific apps. It's not necessary to make the distinction. If someone writes an ICS app, it'll run on both. That's the remerging of these things. I want an app written on TVs to run on phones."

So an app on my phone should look the same on a tablet? Wtf?

Absolutely not. What is he is saying is that it's retarded to have a tablet app and a phone app as two separate apps. It's stupid to force consumers to install "twitter" on their phones but "twitter HD" on their tablets. Instead, it is just "twitter", and the APIs and the app are smart enough to figure out if the user is running a phone or a tablet or whatever, and adjust the UI accordingly - Android has actually made this incredibly painless for developers since 1.0, which is largely why the transition to high DPI devices was a piece of cake for Android. There will still very much be apps that use a different UI on tablets vs. phones, it will just be the same app.

This has some incredibly awesome advantages. One, you don't have to buy two versions of the same fucking thing but repackaged. Two, the OS can actually switch form factors. Dock your phone into a tablet? Now everything is running in tablet mode. Dock your phone into your TV? Now everything is running in TV mode.

No you idiot, its fragmentation because you large parts of your user base with old Android versions who can't update their phones and have different user experiences. In fact its the very definition of fragmentation, and they refuse to even acknowledge it.

No, that isn't the definition of fragmentation at all - or at least, it wasn't. Back in the early days of Unix, there were many competing flavors. Unfortunately, none of them were really compatible with each other. Developers had to use very similar, but subtly different APIs and specifically target each one. It was a pain in the butt. THAT is what fragmentation is, when the APIs have subtle differences or quirks on each platform. Android doesn't have that. On Android, if you target 2.1 it will run on *all* 2.1 devices, *all* 2.2 devices, *all* 2.3 devices, *all* 3.0 devices, etc... Zero real fragmentation.

Unfortunately "fragmentation" is a fun sounding word so ignorant tech bloggers latched onto it like crack and now the word has lost any meaning whatsoever.

I'm a professional Android dev and I really hope that Google shapes up and that ICS is the beginning of the end of the glitchy, incomplete APIs

Such as?

laughable hardware performance (audio on Android is a sad joke)

So unfortunately true

Well, low latency audio is a joke anyway - supposedly the OpenAL support will solve that.

I'd also like them to allow us to use C++ without having to go through JNI, but I doubt that they'll be that kind

You already can. Gingerbread added support for fully native activities, and Honeycomb opened up the RenderScript APIs (RenderScript is basically C that compiles to LLVM bytecode which is then compiled to native on device - so you end up with portable C)

 

[Electrofreak]

One of the Google devs recently mentioned a new audio effects API for ICS. I'd be interested to know more about that.

 

[Elledan]

OpenAL support on Android? Last I heard OpenSL support was added in 2.3.3 with no plans to add OpenAL, despite it being the industry standard. Good to hear about the native support. Will have to look into it.

As for glitchy APIs, have fun putting a consistent UI together. Most of the time I spent developing the last project for a client I was fixing UI glitches using a variety of methods, including adjusting the dimensions of ImageViews and such while constructing the layout and after adjusting the orientation in the code as there was no way to do this in the XML file. Video codec support is also very unreliable, with the client's Galaxy SII having severe issues with h.264 playback, resulting in having to use the older MPEG-4 codec.

Those aren't things you would encounter on an iPhone and feel ashamed that Samsung's flagship phone at this moment has such deficiencies while my own Huawei U8800 has no such issues. It just shows the fragmentation issues which is causing unpredictable behaviour when testing across a number of Android devices. It promotes conservative programming and designing.

 

[MrCrispy]

kllrnohj, I was talking about fragmentation not from a software developer's perspective, but a user, and even more, an operator. I know that Linux does not have a standard binary interface and thus the norm is to compile source. So what they are doing to ensure a consistent dev environment is very valuable and will lead to write one run anywhere apps hopefully, though I haven't seen any details on how exactly ICS exposes device capabilities so e.g. an app decides what fragments to show and if hardware buttons are present.

But users don't care about this nor should they. The fact is someone who had iPhone 1 with iOS 1.0 would still use iPhone 4S with iOS 5 in 99% the same way. This cannot be said of Android. People are locked into devices with no software upgrades for years, and have to root to get improvements. Google does not care about this obviously - to them its a carrier problem. Thus the user experience on Android is fragmented - I hope I made myself clearer this time. And I'm not sure how forward compatible Android api's will remain - at some point Google will have to deprecate old api's and retire them.

 

[kllrnohj]

The fact is someone who had iPhone 1 with iOS 1.0 would still use iPhone 4S with iOS 5 in 99% the same way. This cannot be said of Android.

The same can absolutely be said of Android. You still interact with the home screen the same way, which is all anybody really cares about.

But more importantly that is absolutely not an advantage. The fact that iOS hasn't improved its UI after 4 years is hardly an advantage.

People are locked into devices with no software upgrades for years, and have to root to get improvements. Google does not care about this obviously - to them its a carrier problem.

No, to them it's a "those aren't our devices, we don't support them" problem. They support their own devices just fine.

Thus the user experience on Android is fragmented

No it isn't. People only have one phone and upgrade every 2 years. There is zero fragmentation, unless you are a reviewer or a gadget whore (like me )

 

[Elledan]

No it isn't. People only have one phone and upgrade every 2 years. There is zero fragmentation, unless you are a reviewer or a gadget whore (like me )

The Android Market statistics do not agree with that assessment: http://developer.android.com/resources/dashboard/platform-versions.html

Percentage-wise, the uptake of newer Android versions, including API 10, Android Gingerbread 2.3.3+ has been abysmal. Android 2.2 and below still take up about 50% of the market out there, meaning that you simply can not afford to use the newer APIs lest you abandon part of your target market. Granted, 1.5 and 1.6 devices out there probably aren't worth targeting anyway due to the slow hardware and smaller screens, but still.

For new Android projects, including freelance projects for clients, I generally target 2.1+. 3.x isn't even a consideration, nor 2.3.3+. Before ICS will become the 75+% marketshare contestant we still have a long way to go. At least it'll run on both tablet and phones, but I still don't see a way to upgrade my Android phone to ICS unless I go the custom ROM route. I doubt Huawei will be generous enough to provide an ICS update for my phone considering that they haven't upgraded it to 2.3 anything yet...

 

[MrCrispy]

No, to them it's a "those aren't our devices, we don't support them" problem. They support their own devices just fine.

That's the problem. They are all Android phones, and Google should treat them as 'their' devices. The fact that Google considers Nexus phones as the only ones they need to support is a huge mistake. People don't think 'oh its not a Nexus so its fine', they think 'Android sucks'. Android is the brand, not Google.

Microsoft has many oem's for WP7, they don't let the oem's dictate when the phone gets an update or what crapware goes on it. Like I said, Google just doesn't care.

 

[Chibo]

 

[CHANG3D]

Love that chart! LOL

As we all know by now, HW acceleration is ICS (4.0) only. And I don't see us making ICS specific apps until 1.5 years later. We're on 2.1, and we're going to continue 2.1 development until 2.3 or something takes 90% of the market. It's up to me to propose that we start multiple apk support, and I just don't see the point in terms of revenue. I'm wondering if you developers are also facing this dilemma.

 

[MrCrispy]

Awesome chart. Tell me that isn't fragmentation (or pick another word if you like).

 

[Elledan]

Awesome chart. Tell me that isn't fragmentation (or pick another word if you like).

It just visualizes the decision process I and every other Android developer faces when settling on an API version to target for a project. It also means that any Android device you buy, you have to accept that the version it comes with is most likely the last update you'll ever see for it.

ICS development in 1.5 years from now seems hopelessly optimistic. Just look at 3.x app support and weep. IF Google had followed the Apple/Microsoft model and pushed out a single version of Android for all Android devices out there without opportunities for providers to control updates, things would have been different. Phones would be on 2.3.3+ and tablets on 3.2, with them all getting an upgrade to ICS within a few months time. Instead we'll be limping along with 2.1 as the only realistic development target...

I really hate being an Android dev at times. I am seriously looking into WP7 development at this point and hope that it takes off as a development platform.

 

[Tower]

Love that chart! LOL

As we all know by now, HW acceleration is ICS (4.0) only. And I don't see us making ICS specific apps until 1.5 years later. We're on 2.1, and we're going to continue 2.1 development until 2.3 or something takes 90% of the market. It's up to me to propose that we start multiple apk support, and I just don't see the point in terms of revenue. I'm wondering if you developers are also facing this dilemma.

To be accurate, you do not "develop" an application for ICS. To create an application, you use the available APIs, the majority of which were introduced in Android 1.0. You can create an application that is _only_ available for ICS users, and takes advantage of newly-available ICS APIs, but that's it.

The idea that we'll see "Android 2.2" applications for the next two years is absurd. You might as well say that we'll see Android 1.0 applications for as long as Android is Android, because if you're writing an Android application, you're using the Android API set, of which the majority was released when the platform became available, which is Android 1.0.

Awesome chart. Tell me that isn't fragmentation (or pick another word if you like).

What it really emphasizes is that the mobile space needs a paradigm shift towards that of the desktop. Mobile devices are simply computers, and users should be able to install whatever OS they prefer on their hardware (given support.)

There is no reason I shouldn't be able to install Ice Cream Sandwich on my phone, provide it with the device drivers it needs, and set it up just like a computer.

We simply need the paradigm shift to occur in the industry.

ICS development in 1.5 years from now seems hopelessly optimistic. Just look at 3.x app support and weep.

What about Android development is making you weep? The applications I've written for Android are generally created to support the latest iteration available (e.g. ICS), and I write code to remove that functionality from older devices that can't support it.

For example, one of my applications automatically launches Android's "Car Mode" UI when docked in the car. Car Mode, and it's associated APIs, were made available starting in Android 2.2. In my application, if the detected OS is earlier than 2.2, that functionality is simply not available. That way I can support old devices with as much functionality as possible (Android 1.6), while adding additional support and capability based on subsequent releases.

With ICS, for example, I'm debating adding a feature to disable "Face Unlock" and have the device unlock via pattern, combination, etc. It would be difficult (at best) to do a Face Unlock while your phone is docked. Obviously this is an ICS-only feature, and wouldn't be available to older OSes.

 

[Chibo]

I really hate being an Android dev at times. I am seriously looking into WP7 development at this point and hope that it takes off as a development platform.

I'm an IOS person at heart and I agree on the WP7 sentiment. The phones coming out with WP7 look fucking great too... if I hadn't just gotten a 4S I'd probably give some serious thought to going with the Lumia 800.

 

[Elledan]

What it really emphasizes is that the mobile space needs a paradigm shift towards that of the desktop. Mobile devices are simply computers, and users should be able to install whatever OS they prefer on their hardware (given support.)

There is no reason I shouldn't be able to install Ice Cream Sandwich on my phone, provide it with the device drivers it needs, and set it up just like a computer.

We simply need the paradigm shift to occur in the industry.

I agree on this. Android is the biggest offender in this, as with iOS and WP7 devices you can at least upgrade to the latest version, while Android doesn't even allow for this. Having the OS on the device completely customizable is kind of happening already with Cyanogenmod and such custom ROMs.

What about Android development is making you weep? The applications I've written for Android are generally created to support the latest iteration available (e.g. ICS), and I write code to remove that functionality from older devices that can't support it.

For example, one of my applications automatically launches Android's "Car Mode" UI when docked in the car. Car Mode, and it's associated APIs, were made available starting in Android 2.2. In my application, if the detected OS is earlier than 2.2, that functionality is simply not available. That way I can support old devices with as much functionality as possible (Android 1.6), while adding additional support and capability based on subsequent releases.

With ICS, for example, I'm debating adding a feature to disable "Face Unlock" and have the device unlock via pattern, combination, etc. It would be difficult (at best) to do a Face Unlock while your phone is docked. Obviously this is an ICS-only feature, and wouldn't be available to older OSes.

Okay, so then we'll be about at the point where Javascript and websites were about 8 years ago, where detecting the browser version and type was crucial to make things work JS and CSS-wise. What you're describing sounds like a nightmare to develop and test. It's not an approach I'll ever be using unless it somehow makes sense to do so.

I'm an IOS person at heart and I agree on the WP7 sentiment. The phones coming out with WP7 look fucking great too... if I hadn't just gotten a 4S I'd probably give some serious thought to going with the Lumia 800.

I might be in the market for a new phone soon, and I am more than tempted to get a WP7 phone at that time. Mango looks yummy indeed

 

[kllrnohj]

Love that chart! LOL

As we all know by now, HW acceleration is ICS (4.0) only. And I don't see us making ICS specific apps until 1.5 years later. We're on 2.1, and we're going to continue 2.1 development until 2.3 or something takes 90% of the market. It's up to me to propose that we start multiple apk support, and I just don't see the point in terms of revenue. I'm wondering if you developers are also facing this dilemma.

Market already supports multiple APKs, it just isn't really needed because Android's architecture isn't hopelessly broken.

You can absolutely target Android 2.1 and still leverage features of ICS including HW acceleration. It's very, very trivial. Take your 2.1 app and add 'android:hardwareAccelerated="true"' - works perfectly on every 2.1 device and higher, although obviously only 3.x and higher will benefit. Oh, and in case you didn't notice that HW acceleration isn't an ICS-only feature, it's a Honeycomb (3.0) feature.

And in case you aren't aware, resources can be version targeted. Makes leveraging newer themes and UI conventions quite trivial as well. You can also have your target API be higher than the min API to avoid hitting the compatibility mode in 3.x and higher. This is all incredibly simple, and a huge reason why the supposed "fragmentation" is a pointless argument - in doesn't actually matter in the real world.

I recommend reading the "Best Practices" section of the dev guide (starting with http://developer.android.com/guide/practices/compatibility.html ) - it seems you need a refresher.

That's the problem. They are all Android phones, and Google should treat them as 'their' devices. The fact that Google considers Nexus phones as the only ones they need to support is a huge mistake. People don't think 'oh its not a Nexus so its fine', they think 'Android sucks'. Android is the brand, not Google.

Microsoft has many oem's for WP7, they don't let the oem's dictate when the phone gets an update or what crapware goes on it. Like I said, Google just doesn't care.

No, Google *can't* support devices they don't make. ARM is nothing like x86. It is impossible for them to make a ROM for a device they don't ship. They simply can't do it, it's not technically possible. Moreover, only the OEM that made the initial ROM even has the system signature keys, meaning Google can't even install stuff into the system much less replace the ROM. "caring" is completely irrelevant. It doesn't matter how much you care, that doesn't change the reality of the situation.

MS side steps the problem by limiting everyone to a single, very strict hardware set. They have one supported CPU, one supported GPU, one supported chipset, etc... They then also prevent OEMs from customizing it. Even still, the updates don't go out to everyone at once. AT&T's devices had the updates delayed for months. WP7's updates are far from a sure thing.

The Android Market statistics do not agree with that assessment: http://developer.android.com/resources/dashboard/platform-versions.html

Context is important. Go back and re-read the quote I was responding to. kthxbai.

Percentage-wise, the uptake of newer Android versions, including API 10, Android Gingerbread 2.3.3+ has been abysmal. Android 2.2 and below still take up about 50% of the market out there, meaning that you simply can not afford to use the newer APIs lest you abandon part of your target market.

The support library disagrees with you.

 

[MrCrispy]

These are all business issues, not technical. Android obviously runs on many different SoC's - that work has already been done. No one is suggesting Google make rom's for every Android device. The work needed to port a new Android release is incremental, and oem's are more than happy to do it - that's why Samsung is able to add hardware acceleration in the Galaxy phones, which Android lacks.

Google could very easily have required each Android licensee to support upgrades for X years, make sure devices are updated, and make sure crapware is user uninstallable. But they didn't, they were more interested in signing up as many partners as possible. They definitely had the clout after the initial success. It has everything to do with caring about your brand.

 

[Impulse]

I don't know about that, you could make the opposite argument... That they didn't achieve that clout until they managed to capture the market penetration that they have, which might not have been possible if they were more selective or strict with their partners. MS took Apple's approach in this regard and they're still languishing, altho I do believe they have the clout and resources to eventually capture a large portion of the market... They'll probably be Google's biggest competitor in the long run imo, not Apple.

I do think it's not too late for Google to nudge partners in this way tho... Their tablets are seeing much more timely updates even from relatively minor players, and certain flagship devices have had relatively good track records with updates, tho it takes a manufacturer AND carrier commitment for that to happen. Too many people are quick to blame manufacturers or Google alone but carriers hold up updates for a variety of reasons and for very lengthy stretches.

AT&T was screwing around with their WP7 updates for months (nevermind the mess with their Android portfolio)... On the opposite end of the spectrum you got a combo like Sprint/HTC who recognized a particular model would be a big seller for more than a year so they went the extra mile on it, the EVO 4G went from 2.1 to 2.2 and later 2.3 relatively quickly compared to many other popular phones.

Programming for the lowest common denominator isn't exactly new tho... I don't see how legacy/fragmentation would really scale into a larger issue. Most consumers don't care what version of an OS they're running and there's always gonna be a portion of the market with outdated hardware, more so in the long run as the market matures. You think Apple's tight grip or MS' single hardware platform approach is really gonna cope with that much better?

Apple is constantly leaving out features from OS updates on their older phones, sometimes seemingly for no reason than to sell more new phones, is that sustainable? Why isn't Siri implemented across the board? I'm more interested in how MS approach will evolve tho, specially as they loosen it up for the likes of Nokia.

 

[CHANG3D]

Market already supports multiple APKs, it just isn't really needed because Android's architecture isn't hopelessly broken.

You can absolutely target Android 2.1 and still leverage features of ICS including HW acceleration. It's very, very trivial. Take your 2.1 app and add 'android:hardwareAccelerated="true"' - works perfectly on every 2.1 device and higher, although obviously only 3.x and higher will benefit. Oh, and in case you didn't notice that HW acceleration isn't an ICS-only feature, it's a Honeycomb (3.0) feature.

And in case you aren't aware, resources can be version targeted. Makes leveraging newer themes and UI conventions quite trivial as well. You can also have your target API be higher than the min API to avoid hitting the compatibility mode in 3.x and higher. This is all incredibly simple, and a huge reason why the supposed "fragmentation" is a pointless argument - in doesn't actually matter in the real world.

I recommend reading the "Best Practices" section of the dev guide (starting with http://developer.android.com/guide/practices/compatibility.html ) - it seems you need a refresher.



No, Google *can't* support devices they don't make. ARM is nothing like x86. It is impossible for them to make a ROM for a device they don't ship. They simply can't do it, it's not technically possible. Moreover, only the OEM that made the initial ROM even has the system signature keys, meaning Google can't even install stuff into the system much less replace the ROM. "caring" is completely irrelevant. It doesn't matter how much you care, that doesn't change the reality of the situation.

MS side steps the problem by limiting everyone to a single, very strict hardware set. They have one supported CPU, one supported GPU, one supported chipset, etc... They then also prevent OEMs from customizing it. Even still, the updates don't go out to everyone at once. AT&T's devices had the updates delayed for months. WP7's updates are far from a sure thing.



Context is important. Go back and re-read the quote I was responding to. kthxbai.



The support library disagrees with you.

thanks, finally heard someone who knows about this! Where were you guys a couple of weeks ago?

BTW, who cares about 3.0! Didn't know I could just add that line... Thinking outside the box for way too long and sometimes just needs to get back into the box!

 

[Harry1969]

I dont care about fragmentation because I buy my phones for what they can do now not 5 years from now. Most people upgrade their phones for free every two years anyway. Apple can rant all they want about fragmentation the iphone 3g runs like shit on the latest ios and doesn't have all the features of the new iphone even with Apples perfect ecosystem.

 

[Aurelius]

I dont care about fragmentation because I buy my phones for what they can do now not 5 years from now. Most people upgrade their phones for free every two years anyway. Apple can rant all they want about fragmentation the iphone 3g runs like shit on the latest ios and doesn't have all the features of the new iphone even with Apples perfect ecosystem.

The iPhone 3G doesn't run iOS 5. You're thinking of iOS 4, which did run badly.

iOS 5, meanwhile, not only runs on the iPhone 3GS, it runs faster than the OS it replaced. Two and a half years old, still actively supported. It's only locked out of features that are hardware-dependent (Siri we have yet to know for sure if it would run well on pre-4S hardware, since the hacks are rough and aren't working properly).

We need to stop making excuses for Android, since there's very real, practical limitations that come from being on an abandoned phone: official or important apps that won't run, missing out on certain parts of the web, and getting security patches. You shouldn't be punished with a significantly greater risk of a hack or being unable to see modern websites just because you don't replace your phone every year.

And on the tablet front: I know what Andy Rubin was getting at with universal apps, but he's still wrong. Certain apps would only ever work on a tablet-sized screen or would lose a lot going to a small screen. Likewise, certain phone apps don't translate well to larger screens or to the usage habits of a tablet (an app that needs an always-on connection, for example). In those cases, it doesn't matter how elegantly you can reorganize the app if no one really wants to use it that way.

Remember, Apple is the one that dominates the tablet market where Android is a small sliver and declining: Motorola shipped just 100,000 Xooms in the summer, and even Samsung, which likes to brag about any sales milestone it hits, has said squat about the Galaxy Tab 10.1's numbers. I wouldn't want to take Rubin's point of view given that he's marginalized Android in tablets and has made it bloody hard to find optimized apps in Android Market.

 

[Ozymandias]

(Siri we have yet to know for sure if it would run well on pre-4S hardware, since the hacks are rough and aren't working properly).

Most of the natural language processing and text parsing that makes Siri tick is done in the cloud, so the app itself runs fine on older hardware. Apple keeps Siri exclusive to the 4S to move phones.

 

[Impulse]

Not giving Siri to the older models was just a way to sell the underwhelming 4S, tho frankly I think it's a very substantial hardware upgrade (the media's just underwhelmed because it didn't change physically or bring a 4G radio, and the latter was out of Apple's hands unless they compromised battery life). It's plainly obvious Siri works mainly off cloud processing like every other voice command system of it's ilk.

Not that I'm making excuses for the Android update situation... I think at some point they're gonna have to either slow the update pace to the point where support on older phones becomes irrelevant (though the issue will persist) or they're gonna have to implement some sorta framework to facilitate the update process for manufacturers so that they have no excuse to support their entire lineup.

 

[kllrnohj]

We need to stop making excuses for Android, since there's very real, practical limitations that come from being on an abandoned phone: official or important apps that won't run, missing out on certain parts of the web, and getting security patches. You shouldn't be punished with a significantly greater risk of a hack or being unable to see modern websites just because you don't replace your phone every year.

Yes, there is. I don't see anyone making excuses for OEMs not updating their phones, though. Of course, OEMs are actually updating phones, contrary to popular belief. It may be slower than many would like, but it is actually happening.

And on the tablet front: I know what Andy Rubin was getting at with universal apps, but he's still wrong. Certain apps would only ever work on a tablet-sized screen or would lose a lot going to a small screen. Likewise, certain phone apps don't translate well to larger screens or to the usage habits of a tablet (an app that needs an always-on connection, for example). In those cases, it doesn't matter how elegantly you can reorganize the app if no one really wants to use it that way.

No, not really. An app that only works on Android tablets is still just an Android app, it just happens to want a 7-10" screen. Market fully supports developers specifying such restrictions, by the way.

Remember, Apple is the one that dominates the tablet market where Android is a small sliver and declining: Motorola shipped just 100,000 Xooms in the summer, and even Samsung, which likes to brag about any sales milestone it hits, has said squat about the Galaxy Tab 10.1's numbers. I wouldn't want to take Rubin's point of view given that he's marginalized Android in tablets and has made it bloody hard to find optimized apps in Android Market.

Android is running on ~6 million tablets. No idea how you consider that "declining". (source: http://thisismynext.com/2011/10/19/andy-rubin-6-million-android-tablets-out-there/ )

 

[Neurofreeze]

Most of the natural language processing and text parsing that makes Siri tick is done in the cloud, so the app itself runs fine on older hardware. Apple keeps Siri exclusive to the 4S to move phones.

You have no idea if it runs fine on older hardware. You can currently run it on a jailbroken 4, but it runs like dog crap (fyi my brother upgraded to a 4S and gave the 4 to our dad, and we tried running Siri on it yesterday; not good at all). Whether it's because there is enough of it processed on the phone that the single core CPU is bogged down or if it's just because the hack is not very well optimized is irrelevant, what it means is that there is currently no proof whatsoever that Siri runs okay on a pre-4S phone, so your statement is not one you can really make.

 

[Neurofreeze]

Yes, there is. I don't see anyone making excuses for OEMs not updating their phones, though. Of course, OEMs are actually updating phones, contrary to popular belief. It may be slower than many would like, but it is actually happening.

I think nearly everyone in this thread is forgetting that OEMs are only a part, and a considerably more minor part, of the problem. The bigger issue are US carriers. The carriers are shit with continued support because it nets them practically no profit. They're used to doing no work for massive margins (e.g. selling us texting service for $15 a month when it costs them pennies). They're actually complaining about not being able to get 10000% profit these days.

So you have an annoying, but not totally unreasonable, wait from the OEMs added on top of the ridiculous wait from the carriers.

 

[Ozymandias]

You have no idea if it runs fine on older hardware. You can currently run it on a jailbroken 4, but it runs like dog crap (fyi my brother upgraded to a 4S and gave the 4 to our dad, and we tried running Siri on it yesterday; not good at all). Whether it's because there is enough of it processed on the phone that the single core CPU is bogged down or if it's just because the hack is not very well optimized is irrelevant, what it means is that there is currently no proof whatsoever that Siri runs okay on a pre-4S phone, so your statement is not one you can really make.

Performance looks fine to me.

 

[Chibo]

Performance looks fine to me.

That video showed nothing. You can show the siri menu, cool, that means that performance isn't bad.

 

[kllrnohj]

You have no idea if it runs fine on older hardware. You can currently run it on a jailbroken 4, but it runs like dog crap (fyi my brother upgraded to a 4S and gave the 4 to our dad, and we tried running Siri on it yesterday; not good at all). Whether it's because there is enough of it processed on the phone that the single core CPU is bogged down or if it's just because the hack is not very well optimized is irrelevant, what it means is that there is currently no proof whatsoever that Siri runs okay on a pre-4S phone, so your statement is not one you can really make.

The actually voice processing happens on a server somewhere. That is definitely true. The rest is just the UI, and there is no reason that Siri's UI is too demanding for the iPhone 4. The 4S doesn't have any extra RAM afaik, so that pretty much limits possible hardware reasons for the Siri being limited to the 4S. Apple has done this before, restricting new features to new hardware just to differentiate the new from the old. Not sure why you find it surprising that they are doing it again.

I think nearly everyone in this thread is forgetting that OEMs are only a part, and a considerably more minor part, of the problem. The bigger issue are US carriers. The carriers are shit with continued support because it nets them practically no profit. They're used to doing no work for massive margins (e.g. selling us texting service for $15 a month when it costs them pennies). They're actually complaining about not being able to get 10000% profit these days.

So you have an annoying, but not totally unreasonable, wait from the OEMs added on top of the ridiculous wait from the carriers.

Absolutely. Compare how quickly the international Galaxy S got updates compared to the US versions. Given that the hardware is the same, the carriers are almost certainly the entire reason for the many months delay the US updates experienced.

 

[Impulse]

That video showed nothing. You can show the siri menu, cool, that means that performance isn't bad.

Enough with the RDF already, it wasn't back ported to sell phones...

http://www.youtube.com/watch?v=p8GLwG4_qBY&sns=em

 

[Cipherr]

Enough with the RDF already, it wasn't back ported to sell phones...

http://www.youtube.com/watch?v=p8GLwG4_qBY&sns=em

Oh wow.... yeah, that looks absolutely fine. That's crazy. They definitely held it back just to sell phones, it appears to be running just fine.

 

[ilkhan]

Nobody can call Android fragmented until Apple starts selling (and supporting) more than 1 version of their phone per year. No, a different size ROM chip doesn't count.

Support is pretty damn easy when you control every aspect of the phone from development to release to sale to updates to garbage bin.

 

[Impulse]

There's an in between approach tho, WP7... I'm not saying any of them have the perfect model mind you, they've all got room to improve. Technically speaking Apple usually sells two different models year round btw (3GS & 4 before, now 4 and 4S probably), at different price points, not that it changes much... They did make a conscious choice to do it that way tho just, just as Google did the opposite. Big question is, can MS carve market share with a middle ground aproach? Will it change how either of the other two do things?

 

[Tower]

The argument in this thread is that people are frustrated with a lack of updates to their Android devices.

Their options are to purchase an Apple device, wherein you'll receive updates directly from Apple (but have to succumb to their desires, including what you can and cannot do with your device), or MS, where essentially every device is the same (or about the same, with a slight deviation in clock speed.)

Android is the truly established "platform", and we need a paradigm shift to be able to control and install operating systems of our own preference on our own devices, much like we're able to do with PCs.

We are mired down in a backwards, old-fashioned style of computing on mobile phones that is akin to the idea of receiving updates on your Compaq laptop straight from Compaq. Windows 8 comes out and you want it? Too bad, ask Compaq.

This mentality needs to change.

 

[MrCrispy]

Carriers are indeed the problem. And Google is the only one who can dictate terms to them (not the oem's). Just like Apple did. Just like Microsoft did. But with people like Rubin, Google is content to let the carriers load crap on Android phones as long as they get to sell the one true Nexus phone.

Why are people defending Siri? It's so obvious its a money grab by Apple and a way to force people to upgrade. Why doesn't it run on the iPad, which is just as (or even more) powerful than the 4S? Similar voice recognition runs fine on much lower powered Android and WP7 headsets - all the phone has to do is encode your voice in a very low bitrate audio (which is done in hardware) then send it to servers, and show the responses. It's not exactly rocket science on the client.