Yeah, well, we'd all be running Ice Cream Sandwich if they would just push out upgrades for all our phones. I've got a 3D 4G LG Thrive, it's got a dual 1.0Ghz processor so there's no reason why it couldn't run 4.0 yet the highest upgrade they've pushed out is 2.3, the same goes for all my other phones, at 2.3 they simply stopped pushing out upgrades? We're all like WTH?!
In my other pocket I've got iPhone S 4G, upgrades for this phone get pushed out to all the iPhones at the same time, which is a tad bit easier for Apple to do since the architecture for all the iPhones are pretty much the same, while each Android model is fairly unique.
I could complain that we simply don't get the option to upgrade our Android anymore, but aside from a screen layout change, I really have no idea what Android 4.0 can do the 2.3 can't, or even 2.2 for that matter, on the other hand, my iOS upgrades weren't simply upgrades, they were fixes for known major errors, like battery life or download speeds, etc. so we were forced to upgrade fix a major issue with our iPhone or suffer greatly with a crippled device.
The Android OS 2.2+ doesn't have huge fixes in it like iOS does, so I can somewhat understand why Android users are not even given the option at all to upgrade, but iOS users really have no other option because of critical errors in the OS that must be fixed, that's the real reason for such a huge difference in numbers.
Here is the problem: unlike Apple, Google phone manufacturers hav no financial incentive to update older phones. Until Google shares the revenue with the manufactures, Fragmentation it is.
But Google is so far in debt with Android at this point that even if they wanted to they couldn't. They've made plenty of money off the handset market but it's from the iPhone.
So how does this mean Android relates to Apple with regard to API/OS support?
In short, developing for either platform (any platform, really--this isn't limited to just mobile development) means before you perform non-standard operations that you know are supported on every platform (for example, asking the platform to identify what it's version is), you have to make a check to see if it's supported.
If you're building an application that automatically launches navigation on your iPhone, you need some logic in it that says "Does this device have iOS 6? If it does, does this device support Navigation?" because not all iOS 6 devices do.
Similarly, in Android your code would include logic saying "Does this version of Android support what this program wants to do? Does it include hardware capable of doing it?"
Regardless of platform, developers have to write the same type of deterministic logic to ensure their applications work correctly. The concept of "fragmentation" exists on every platform that has more than one version, and it's no different between iOS, Android, OS X, Windows, Linux, etc.
This isn't about whether the developer has to check if an API is available in their code. iOS 6 on a 3GS or a 4th gen iPod touch has hundreds of new APIs regardless of whether flyover is available in Maps and hence those APIs have much wider distribution than they would otherwise. That's the point.
Developers adopt these APIs because they're widely available. The same isn't true on Android. Some of these new APIs are very basic and the picture you paint of API adoption is far too simplistic. For example, in Android 3.x and 4.x Google added hardware-accelerated animation and made some extensions to the constraints system used for UI layout. In iOS 6, Apple has added a new richer set of constraints for UI layout and new features for localisation. As an iOS developer, if I'm starting a new app I can use these new features in the knowledge that my app will work, without changes, on the majority of iOS devices within a few months of iOS being released. That's fantastic news for me. If I wanted my app to work on devices that are stuck on iOS 5 I could, perhaps, create two different UIs and approach localisation differently in each case. It's much more likely I just wouldn't use those features at all. The same is true with Android. I could write different animation code for different versions of Android and lay out my UI differently, but it's far more likely than I'm going to either stick to the 2.3 way of doing things or make an app that works only on 4.x devices. Given the limited availability of 4.x devices, it'd be wiser to take the conservative route. That's the difference.
There are numerous examples of new APIs the adoption of which is an issue of basic development choices where it would be too costly or difficult to also support the old way of doing things. Changes in the UI (should I adopt storyboards?), changes to animation and rendering code, localisation, stuff like iCloud and Maps, etc. Sure, there's stuff I can just add, like Twitter support, without too much hassle. But there's a lot of basic stuff a developer starting a new app is going to want to avoid in Android 4.x if he wants to be compatible with 2.3. It's crazy to think Android apps aren't going to lag in adoption of new APIs and features.
"It's kinda sad that these guys feel the need to join an Apple centric forum to spout their drivel in support of a platform they know know in their hearts is subpar. The insecurity complexes must be strong indeed."
What a pompous ass*&%$ to come up with a remark such as this. Ikrup, You are the unfortunate epidemy of an apple user as highlighted in any NON-apple forum.
I happen to own both devices. One for work, and one for play. I play on my iphone, and I work on my android. Then again I am also a pc user... The android plugs right in, acts as a 20+ gig external hd (great for solidworks btw) and has a function to play my adobe flash demo videos.
I could care less when it comes to updating my phones OS. If I can jump on gmail, cruise the interweb, and call pizza hut... I am one happy camper!
Here is the problem: unlike Apple, Google phone manufacturers hav no financial incentive to update older phones. Until Google shares the revenue with the manufactures, Fragmentation it is.
and to complicate it further... the Carriers are the ones the drive upgrades... A carrier has to approve the upgrade before it can be pushed to it's users.
Apple's model makes the carriers into a dumb pipe selling bandwidth. Android's model makes them the final decision maker for any phone modification.
If a carrier can sell contracts with a 3 year old phone running a 4 year old operating system... they will do so, and expect 2 years of support on that combination from the OEM (who actually is the OS developer).
But Google is so far in debt with Android at this point that even if they wanted to they couldn't. They've made plenty of money off the handset market but it's from the iPhone.
Google isn't in debt over Android? Android is profitable for Google, but not in a "boatloads of cash on every device!" sort of way.
The last estimate I saw is that Google makes about $15 per Android device per year (in advertisements based on search), which is how and why Android is good for them. I think the figure I saw was around ~4 billion/year based on Android devices.
It's kinda sad that these guys feel the need to join an Apple centric forum to spout their drivel in support of a platform they know know in their hearts is subpar. The insecurity complexes must be strong indeed.
Fascinating! I didn't realize being an Apple elitist gave you divine insight into the hearts and minds of others.
APIs rarely (if ever) are changed once "set in stone." 95% of the API calls available in Android 1.0 (as this example) still work exactly as they did then in 4.1. In the guts of Android, how those features are implemented might change, but those changes are mostly abstracted away and neither users nor developers see them. If the call was "PlaySound(SomeFile.mp3)" in 1.0, and it would play the sound, that same call would work in 4.1.
As time goes on, new APIs are added to provide additional functionality. For example, NFC technology for Wallet-based tech is relatively new, and wasn't around in Android 1.0. Let's say Google adds support for NFC in Android 2.3. Starting in that API, new functions are available, for example, "TransmitPayment()" or something similar.
To deal with older devices, simple checks are made. In the application manifest (installer), the application can say, "I only support devices using Android 2.3 or above. I won't install on anything less." and it's simply not available for older devices. This is a hard-line approach, and while possible, many developers instead tend to evaluate the platform in their code and then make things available conditionally.
For example, a developer would have a check in the start of their logic that would behave like this: "Are we running on Android 2.3 or newer? If so, make all of our NFC functionality available. If not, disable all of the NFC functionality, but let the user know that it's not available because their phone doesn't support it."
(As a sidenote, in the case of NFC, not only would you want to check to be sure you have the supported APIs (Android 2.3), but also that the device in question actually has NFC hardware installed to use those calls.)
So how does this mean Android relates to Apple with regard to API/OS support?
In short, developing for either platform (any platform, really--this isn't limited to just mobile development) means before you perform non-standard operations that you know are supported on every platform (for example, asking the platform to identify what it's version is), you have to make a check to see if it's supported.
If you're building an application that automatically launches navigation on your iPhone, you need some logic in it that says "Does this device have iOS 6? If it does, does this device support Navigation?" because not all iOS 6 devices do.
Similarly, in Android your code would include logic saying "Does this version of Android support what this program wants to do? Does it include hardware capable of doing it?"
Regardless of platform, developers have to write the same type of deterministic logic to ensure their applications work correctly. The concept of "fragmentation" exists on every platform that has more than one version, and it's no different between iOS, Android, OS X, Windows, Linux, etc.
This is not exactly true. Old APIs sometimes get deprecated, meaning older apps may no longer work on newer OS versions. Not only that developer tools get updated with modern technologies as well that may not be supported by older versions of the OS.
You are correct that developers have always needed to check which OS version the app is running on and which APIs and hardware features are available, but that can be minimized when the user base can quickly be moved to the latest API set. This makes it much easier for the developer to concentrate on the app and not need to worry about all the other versions. As an iOS programmer I know that a vast majority of the user base is running the latest version, so I can target only that version. If I were an Android programmer, I can only imagine what a nightmare it would be to have to not only check all the different hardware configurations, but also the API levels as well.
A platform can't move forward if your user base is holding it back. This is clearly what's happening to Android because the users can't update their devices. Where's the incentive for the developer to support the newest OS when a majority of users are still using 2.3.x ?
Hundreds of new API calls? Can you point me to an Apple developer page where I can review all of the additions to iOS 6 over 5?
To address your comments, the Android framework facilitates supporting multiple versions in your application, and you can adjust how they behave based on the OS. I'm sure you're familiar with it--themes being the first example--and how they work. When I'm developing, I adjust based on OS support so that the application fits the theme--Gingerbread, ICS/Jelly Bean's "Holo", etc. Many of those changes are handled automatically by the framework (obviously), and some require extra effort (support fragments, etc.)
However, I'm not sure how that really differs. If you're supporting an iPad, you'll have additional checks and code to support them (as well as customizable views they may support) just as you would if you decided to support Android phones and tablets.
Lastly, the vast majority of API calls should remain the same. You should be able to write a large amount of programs for iOS using the iOS 3 API library and have them all work just fine on iOS 6. I don't develop for iOS, but are you telling me that Apple is dramatically changing the API between each release? If I was writing software for iOS that only required features available in iOS 3, I'd target it for iOS 3.
Google isn't in debt over Android? Android is profitable for Google, but not in a "boatloads of cash on every device!" sort of way.
The last estimate I saw is that Google makes about $15 per Android device per year (in advertisements based on search), which is how and why Android is good for them. I think the figure I saw was around ~4 billion/year based on Android devices.
First of all, that value was pulled out someone's ass without no metrics on how it was determined as an average for ALL Android-based devices in the world. Let's remember that most Android-based devices are little more than feature phones as noted by their activation numbers without any comparable internet presence.
Second, you have to factor in all the Android related costs. They paid $50 million for Android in 2005, $750 million for AdMob in 2009, and a whooping $12.5 billion for Motorola Mobility in 2011. Yes, MM counts because the patents they bought were to benefit Android. On top of that there are lesser known purchases like the $30 million for BumpTop in 2010 and at least a dozen others that are related specifically toward benefiting Android.
There investment is significant and it'll be a very, very, very, very long time before they are in the black that's even before you consider that Google's cost to profit ratio for non-Android-based systems which is excessively low since other companies are floating the bill to make those OSes and ecosystems function. Of course, Google is doing what Dell, HP, MS, RiM, Nokia et al. should have been doing all these decades and not simply rest on their laurels and to invest in controlling, understanding and eventually hopefully perfecting the entire widget. That said, it doesn't mean they are profiting directly from their efforts even if their investments are the right move.
PS: Editing someone's post to say "Summarized" isn't actually summarizing their post, it's deleting it. If you want to only respond to key points or to shorten it to reduce the quoted amount that would be a summary.
Does this mean that Jelly Bean will be available to install on handsets in July?
Or that it is being released by Google to carriers who will then dick around with it for another +6 months before making it available to their customers?
Pretty much screw around with it for 6 months.
Those custom skinned overlays like Touchwiz are the problem. If not for those then Android updates could roll out to all compatible smartphones/tablets very shortly after Google announced them, just like iOS. Note that the un-skinned devices like the Nexus get the most recent updates within a couple of weeks, not months, so Google isn't the problem. It's that they don't build their own devices, nor control their platform from design thru sale, nor highly restrict what licensees can do with it.
But Google is so far in debt with Android at this point that even if they wanted to they couldn't. They've made plenty of money off the handset market but it's from the iPhone.
According to some estimates they are about break even to slightly profitable on Android.
This is not exactly true. Old APIs sometimes get deprecated, meaning older apps may no longer work on newer OS versions. Not only that developer tools get updated with modern technologies as well that may not be supported by older versions of the OS.
You are correct that developers have always needed to check which OS version the app is running on and which APIs and hardware features are available, but that can be minimized when the user base can quickly be moved to the latest API set. This makes it much easier for the developer to concentrate on the app and not need to worry about all the other versions. As an iOS programmer I know that a vast majority of the user base is running the latest version, so I can target only that version. If I were an Android programmer, I can only imagine what a nightmare it would be to have to not only check all the different hardware configurations, but also the API levels as well.
A platform can't move forward if your user base is holding it back. This is clearly what's happening to Android because the users can't update their devices. Where's the incentive for the developer to support the newest OS when a majority of users are still using 2.3.x ?
When you develop for iOS, do you choose what platform you're targeting? Are you able to target iOS API level 3, for example?
I think perhaps there is a difference in development that's causing this rift in understanding. When you build for Android, you choose a minimum SDK version as well as a maximum SDK version you support. For example, I can say that my application supports Android 2.1 - 4.1, and the IDE will support API calls available to those platforms without spitting out errors that a given call is unsupported.
You are correct, some APIs are deprecated, but not many. Like I said, 95% of the original API calls presented in any release are still available, the vast majority of what makes a product is in it's API library. At this time, 95% of Android's library is contained within Android 2.3 or earlier--90% in 2.1 and earlier.
If I write a modern application for Android 4.1, unless I'm using some new technology that's just released, chances are I could build it for Android 2.1 and it'd work all the same.
Does iOS let you build an application that uses iOS 6 features (APIs), but can still run on an iOS 4 device and simply allow you to not implement those features on said older devices?
We need to keep in mind that Android and iOS are in different categories. iOS is the Olympian athletes and Android is some corporate softball or bowling team. There's a lot more of them but they aren't getting sponsorship (mindshare).
And yet they've managed to sell 400 million Android phones compared to 250 million iPhones and people keep buying them.
It doesn't even seem to deter the software developers who keep churning out the app's for Android.
In the end I don't think most people really give a damn. They buy the smartphone they like, download a few key app's, stick some music on it and away they go.
Why should they worry about upgrades. Most Windows users don't upgrade their OS - they just stick with the OS that came on their computer. They only upgrade when they buy a new computer.
worse it is really just devices that have been to Google Play. how many devices are out there that have never connected to said service and what are they running.
Yeah, well, we'd all be running Ice Cream Sandwich if they would just push out upgrades for all our phones.
But they're not going to do that ever. You'd think that you guys would complain about that or something, but you obviously don't. Meanwhile, four year old iPhones will be getting updates.
Comments
Yeah, well, we'd all be running Ice Cream Sandwich if they would just push out upgrades for all our phones. I've got a 3D 4G LG Thrive, it's got a dual 1.0Ghz processor so there's no reason why it couldn't run 4.0 yet the highest upgrade they've pushed out is 2.3, the same goes for all my other phones, at 2.3 they simply stopped pushing out upgrades? We're all like WTH?!
In my other pocket I've got iPhone S 4G, upgrades for this phone get pushed out to all the iPhones at the same time, which is a tad bit easier for Apple to do since the architecture for all the iPhones are pretty much the same, while each Android model is fairly unique.
I could complain that we simply don't get the option to upgrade our Android anymore, but aside from a screen layout change, I really have no idea what Android 4.0 can do the 2.3 can't, or even 2.2 for that matter, on the other hand, my iOS upgrades weren't simply upgrades, they were fixes for known major errors, like battery life or download speeds, etc. so we were forced to upgrade fix a major issue with our iPhone or suffer greatly with a crippled device.
The Android OS 2.2+ doesn't have huge fixes in it like iOS does, so I can somewhat understand why Android users are not even given the option at all to upgrade, but iOS users really have no other option because of critical errors in the OS that must be fixed, that's the real reason for such a huge difference in numbers.
Quote:
Originally Posted by Shidell
It'll be released for Nexus (Google) devices in mid-July.
For any other manufacturer, the source will be made available and they can elect to update (or not update) their devices--that's on them.
in other words...they'll never do it..
Why spend money to upgrade the OS when we can just sell you a new phone with the new OS!!
But Google is so far in debt with Android at this point that even if they wanted to they couldn't. They've made plenty of money off the handset market but it's from the iPhone.
Quote:
Originally Posted by Shidell
So how does this mean Android relates to Apple with regard to API/OS support?
In short, developing for either platform (any platform, really--this isn't limited to just mobile development) means before you perform non-standard operations that you know are supported on every platform (for example, asking the platform to identify what it's version is), you have to make a check to see if it's supported.
If you're building an application that automatically launches navigation on your iPhone, you need some logic in it that says "Does this device have iOS 6? If it does, does this device support Navigation?" because not all iOS 6 devices do.
Similarly, in Android your code would include logic saying "Does this version of Android support what this program wants to do? Does it include hardware capable of doing it?"
Regardless of platform, developers have to write the same type of deterministic logic to ensure their applications work correctly. The concept of "fragmentation" exists on every platform that has more than one version, and it's no different between iOS, Android, OS X, Windows, Linux, etc.
This isn't about whether the developer has to check if an API is available in their code. iOS 6 on a 3GS or a 4th gen iPod touch has hundreds of new APIs regardless of whether flyover is available in Maps and hence those APIs have much wider distribution than they would otherwise. That's the point.
Developers adopt these APIs because they're widely available. The same isn't true on Android. Some of these new APIs are very basic and the picture you paint of API adoption is far too simplistic. For example, in Android 3.x and 4.x Google added hardware-accelerated animation and made some extensions to the constraints system used for UI layout. In iOS 6, Apple has added a new richer set of constraints for UI layout and new features for localisation. As an iOS developer, if I'm starting a new app I can use these new features in the knowledge that my app will work, without changes, on the majority of iOS devices within a few months of iOS being released. That's fantastic news for me. If I wanted my app to work on devices that are stuck on iOS 5 I could, perhaps, create two different UIs and approach localisation differently in each case. It's much more likely I just wouldn't use those features at all. The same is true with Android. I could write different animation code for different versions of Android and lay out my UI differently, but it's far more likely than I'm going to either stick to the 2.3 way of doing things or make an app that works only on 4.x devices. Given the limited availability of 4.x devices, it'd be wiser to take the conservative route. That's the difference.
There are numerous examples of new APIs the adoption of which is an issue of basic development choices where it would be too costly or difficult to also support the old way of doing things. Changes in the UI (should I adopt storyboards?), changes to animation and rendering code, localisation, stuff like iCloud and Maps, etc. Sure, there's stuff I can just add, like Twitter support, without too much hassle. But there's a lot of basic stuff a developer starting a new app is going to want to avoid in Android 4.x if he wants to be compatible with 2.3. It's crazy to think Android apps aren't going to lag in adoption of new APIs and features.
"It's kinda sad that these guys feel the need to join an Apple centric forum to spout their drivel in support of a platform they know know in their hearts is subpar. The insecurity complexes must be strong indeed."
What a pompous ass*&%$ to come up with a remark such as this. Ikrup, You are the unfortunate epidemy of an apple user as highlighted in any NON-apple forum.
I happen to own both devices. One for work, and one for play. I play on my iphone, and I work on my android. Then again I am also a pc user... The android plugs right in, acts as a 20+ gig external hd (great for solidworks btw) and has a function to play my adobe flash demo videos.
I could care less when it comes to updating my phones OS. If I can jump on gmail, cruise the interweb, and call pizza hut... I am one happy camper!
Quote:
Originally Posted by winstein2010
Here is the problem: unlike Apple, Google phone manufacturers hav no financial incentive to update older phones. Until Google shares the revenue with the manufactures, Fragmentation it is.
and to complicate it further... the Carriers are the ones the drive upgrades... A carrier has to approve the upgrade before it can be pushed to it's users.
Apple's model makes the carriers into a dumb pipe selling bandwidth. Android's model makes them the final decision maker for any phone modification.
If a carrier can sell contracts with a 3 year old phone running a 4 year old operating system... they will do so, and expect 2 years of support on that combination from the OEM (who actually is the OS developer).
Quote:
Originally Posted by SolipsismX
But Google is so far in debt with Android at this point that even if they wanted to they couldn't. They've made plenty of money off the handset market but it's from the iPhone.
Google isn't in debt over Android? Android is profitable for Google, but not in a "boatloads of cash on every device!" sort of way.
The last estimate I saw is that Google makes about $15 per Android device per year (in advertisements based on search), which is how and why Android is good for them. I think the figure I saw was around ~4 billion/year based on Android devices.
Quote:
Originally Posted by lkrupp
It's kinda sad that these guys feel the need to join an Apple centric forum to spout their drivel in support of a platform they know know in their hearts is subpar. The insecurity complexes must be strong indeed.
Fascinating! I didn't realize being an Apple elitist gave you divine insight into the hearts and minds of others.
Quote:
Originally Posted by Shidell
I think this is a point of high confusion.
APIs rarely (if ever) are changed once "set in stone." 95% of the API calls available in Android 1.0 (as this example) still work exactly as they did then in 4.1. In the guts of Android, how those features are implemented might change, but those changes are mostly abstracted away and neither users nor developers see them. If the call was "PlaySound(SomeFile.mp3)" in 1.0, and it would play the sound, that same call would work in 4.1.
As time goes on, new APIs are added to provide additional functionality. For example, NFC technology for Wallet-based tech is relatively new, and wasn't around in Android 1.0. Let's say Google adds support for NFC in Android 2.3. Starting in that API, new functions are available, for example, "TransmitPayment()" or something similar.
To deal with older devices, simple checks are made. In the application manifest (installer), the application can say, "I only support devices using Android 2.3 or above. I won't install on anything less." and it's simply not available for older devices. This is a hard-line approach, and while possible, many developers instead tend to evaluate the platform in their code and then make things available conditionally.
For example, a developer would have a check in the start of their logic that would behave like this: "Are we running on Android 2.3 or newer? If so, make all of our NFC functionality available. If not, disable all of the NFC functionality, but let the user know that it's not available because their phone doesn't support it."
(As a sidenote, in the case of NFC, not only would you want to check to be sure you have the supported APIs (Android 2.3), but also that the device in question actually has NFC hardware installed to use those calls.)
So how does this mean Android relates to Apple with regard to API/OS support?
In short, developing for either platform (any platform, really--this isn't limited to just mobile development) means before you perform non-standard operations that you know are supported on every platform (for example, asking the platform to identify what it's version is), you have to make a check to see if it's supported.
If you're building an application that automatically launches navigation on your iPhone, you need some logic in it that says "Does this device have iOS 6? If it does, does this device support Navigation?" because not all iOS 6 devices do.
Similarly, in Android your code would include logic saying "Does this version of Android support what this program wants to do? Does it include hardware capable of doing it?"
Regardless of platform, developers have to write the same type of deterministic logic to ensure their applications work correctly. The concept of "fragmentation" exists on every platform that has more than one version, and it's no different between iOS, Android, OS X, Windows, Linux, etc.
This is not exactly true. Old APIs sometimes get deprecated, meaning older apps may no longer work on newer OS versions. Not only that developer tools get updated with modern technologies as well that may not be supported by older versions of the OS.
You are correct that developers have always needed to check which OS version the app is running on and which APIs and hardware features are available, but that can be minimized when the user base can quickly be moved to the latest API set. This makes it much easier for the developer to concentrate on the app and not need to worry about all the other versions. As an iOS programmer I know that a vast majority of the user base is running the latest version, so I can target only that version. If I were an Android programmer, I can only imagine what a nightmare it would be to have to not only check all the different hardware configurations, but also the API levels as well.
A platform can't move forward if your user base is holding it back. This is clearly what's happening to Android because the users can't update their devices. Where's the incentive for the developer to support the newest OS when a majority of users are still using 2.3.x ?
Quote:
Originally Posted by poke
Summarized.
Hundreds of new API calls? Can you point me to an Apple developer page where I can review all of the additions to iOS 6 over 5?
To address your comments, the Android framework facilitates supporting multiple versions in your application, and you can adjust how they behave based on the OS. I'm sure you're familiar with it--themes being the first example--and how they work. When I'm developing, I adjust based on OS support so that the application fits the theme--Gingerbread, ICS/Jelly Bean's "Holo", etc. Many of those changes are handled automatically by the framework (obviously), and some require extra effort (support fragments, etc.)
However, I'm not sure how that really differs. If you're supporting an iPad, you'll have additional checks and code to support them (as well as customizable views they may support) just as you would if you decided to support Android phones and tablets.
Lastly, the vast majority of API calls should remain the same. You should be able to write a large amount of programs for iOS using the iOS 3 API library and have them all work just fine on iOS 6. I don't develop for iOS, but are you telling me that Apple is dramatically changing the API between each release? If I was writing software for iOS that only required features available in iOS 3, I'd target it for iOS 3.
First of all, that value was pulled out someone's ass without no metrics on how it was determined as an average for ALL Android-based devices in the world. Let's remember that most Android-based devices are little more than feature phones as noted by their activation numbers without any comparable internet presence.
Second, you have to factor in all the Android related costs. They paid $50 million for Android in 2005, $750 million for AdMob in 2009, and a whooping $12.5 billion for Motorola Mobility in 2011. Yes, MM counts because the patents they bought were to benefit Android. On top of that there are lesser known purchases like the $30 million for BumpTop in 2010 and at least a dozen others that are related specifically toward benefiting Android.
There investment is significant and it'll be a very, very, very, very long time before they are in the black that's even before you consider that Google's cost to profit ratio for non-Android-based systems which is excessively low since other companies are floating the bill to make those OSes and ecosystems function. Of course, Google is doing what Dell, HP, MS, RiM, Nokia et al. should have been doing all these decades and not simply rest on their laurels and to invest in controlling, understanding and
eventuallyhopefully perfecting the entire widget. That said, it doesn't mean they are profiting directly from their efforts even if their investments are the right move.PS: Editing someone's post to say "Summarized" isn't actually summarizing their post, it's deleting it. If you want to only respond to key points or to shorten it to reduce the quoted amount that would be a summary.
Quote:
Originally Posted by Chris_CA
Does this mean that Jelly Bean will be available to install on handsets in July?
Or that it is being released by Google to carriers who will then dick around with it for another +6 months before making it available to their customers?
Pretty much screw around with it for 6 months.
Those custom skinned overlays like Touchwiz are the problem. If not for those then Android updates could roll out to all compatible smartphones/tablets very shortly after Google announced them, just like iOS. Note that the un-skinned devices like the Nexus get the most recent updates within a couple of weeks, not months, so Google isn't the problem. It's that they don't build their own devices, nor control their platform from design thru sale, nor highly restrict what licensees can do with it.
Welcome to ShidellInsider.com!
Quote:
Originally Posted by SolipsismX
But Google is so far in debt with Android at this point that even if they wanted to they couldn't. They've made plenty of money off the handset market but it's from the iPhone.
According to some estimates they are about break even to slightly profitable on Android.
Quote:
Originally Posted by mjtomlin
This is not exactly true. Old APIs sometimes get deprecated, meaning older apps may no longer work on newer OS versions. Not only that developer tools get updated with modern technologies as well that may not be supported by older versions of the OS.
You are correct that developers have always needed to check which OS version the app is running on and which APIs and hardware features are available, but that can be minimized when the user base can quickly be moved to the latest API set. This makes it much easier for the developer to concentrate on the app and not need to worry about all the other versions. As an iOS programmer I know that a vast majority of the user base is running the latest version, so I can target only that version. If I were an Android programmer, I can only imagine what a nightmare it would be to have to not only check all the different hardware configurations, but also the API levels as well.
A platform can't move forward if your user base is holding it back. This is clearly what's happening to Android because the users can't update their devices. Where's the incentive for the developer to support the newest OS when a majority of users are still using 2.3.x ?
When you develop for iOS, do you choose what platform you're targeting? Are you able to target iOS API level 3, for example?
I think perhaps there is a difference in development that's causing this rift in understanding. When you build for Android, you choose a minimum SDK version as well as a maximum SDK version you support. For example, I can say that my application supports Android 2.1 - 4.1, and the IDE will support API calls available to those platforms without spitting out errors that a given call is unsupported.
You are correct, some APIs are deprecated, but not many. Like I said, 95% of the original API calls presented in any release are still available, the vast majority of what makes a product is in it's API library. At this time, 95% of Android's library is contained within Android 2.3 or earlier--90% in 2.1 and earlier.
If I write a modern application for Android 4.1, unless I'm using some new technology that's just released, chances are I could build it for Android 2.1 and it'd work all the same.
Does iOS let you build an application that uses iOS 6 features (APIs), but can still run on an iOS 4 device and simply allow you to not implement those features on said older devices?
Quote:
Originally Posted by SolipsismX
We need to keep in mind that Android and iOS are in different categories. iOS is the Olympian athletes and Android is some corporate softball or bowling team. There's a lot more of them but they aren't getting sponsorship (mindshare).
And yet they've managed to sell 400 million Android phones compared to 250 million iPhones and people keep buying them.
It doesn't even seem to deter the software developers who keep churning out the app's for Android.
In the end I don't think most people really give a damn. They buy the smartphone they like, download a few key app's, stick some music on it and away they go.
Why should they worry about upgrades. Most Windows users don't upgrade their OS - they just stick with the OS that came on their computer. They only upgrade when they buy a new computer.
Nobody cares.
Quote:
Originally Posted by Quadra 610
Sad.
worse it is really just devices that have been to Google Play. how many devices are out there that have never connected to said service and what are they running.
Quote:
Originally Posted by Shaun, UK
And yet they've managed to sell 400 million Android phones compared to 250 million iPhones and people keep buying them.
Is that sold sold or Samsung sold
That's got to be the funniest spin yet that I've heard to downplay Android's fragmentation!
That deserves a tip of the hat. Your denial is just epic!
But they're not going to do that ever. You'd think that you guys would complain about that or something, but you obviously don't. Meanwhile, four year old iPhones will be getting updates.
You don't really see those, though.
So what's your plan of action going forward, since you won't have that much longer?
Then are you really part of this discussion?
Go ahead and make a portmanteau out of that.
"You just got Samsold!" as a disparaging remark when a company has sub-par sales.