UPDATE: At first this was going to be just a call to fix the updating process, but I've realized is not just the updates Google needs to take control of.
Now is the time to address the fragmentation issue that's starting to plague the platform, before there are hundred of handsets and the whole thing spins out of control. I believe we've seen enough evidence that the updating process through the carriers doesn't work, many phones are left behind and the whole thing is a mess, today we're already talking about the next update (2.5 Froyo?) while there are phones out there stuck on 1.5, the fragmentation is only going to get worse as we move on.
Imagine when 3.0 gets here, and we have hundreds of handsets with 1.5, 1.6, 2.1, 2.5, 2.7, 3.0 some with Sense UI, MotoBLUR, etc. It's going to be hell for developers and even more confusing for consumers, driving everybody away from the platform. You guys need to take control of this at least for the Google Experience phones. I'm not sure if Google updating the handsets directly would bring legal issues with the carriers/manufacturers, if it would, please enlighten me.
So how do we fix this? I'm pretty sure you guys have already thought about this and I wouldn't be surprised if a solution was coming soon, since it''s such an obvious problem. However, here's my two cents, the solution is very simple, a desktop application for syncing/updating/ media playback/android market/amazon mp3, lets call it Android HQ or Android Home for the sake of argument.
The updates would be available to consumers as soon as they're released, instead of months, years, or never depending on carriers. This way most users would've the latest version as well as the developers would have the latest SDK, developers would be able to take advantage of the new APIs each updates bring and innovate faster, instead of spending time supporting older versions.
Android HQ would also address the next two biggest problems with the platform, they're: media ecosystem and media syncing/backing. Also, the Android Market badly needs a desktop client.
The fragmentation issue is the biggest obstacle the platform is facing today and it will most likely decide its success, I've sensed a couple of times that Google stance on these issues is to let manufactures/ carriers make the decisions on a phone to phone basis (multi-touch anyone?) but that won't work, it'll eventually slow the momentum we have now and kill the platform (WinMo?) Google needs to have a more hands-on approach to Android if it wants it succeed.
Anyway, the guys/gals in the Android Team want the platform to succeed as much as me, I'm sure they've given this a lot of thought, and a solution is probably on the works.
Il giorno sab, 16/01/2010 alle 20.06 -0800, Alberto ha scritto:
> So how do we fix this? I'm pretty sure you guys have already thought > about this and I wouldn't be surprised if a solution was coming soon, > since it''s such an obvious problem. However, here's my two cents, the > solution is very simple, a desktop application for syncing/updating/ > media playback/android market/amazon mp3, lets call it Android HQ or > Android Home for the sake of argument.
> The updates would be available to consumers as soon as they're > released, instead of months, years, or never depending on carriers. > This way most users would've the latest version as well as the > developers would have the latest SDK, developers would be able to take > advantage of the new APIs each updates bring and innovate faster, > instead of spending time supporting older versions.
I quite like your idea (but please make it cross-platform, or at least for Windows, OSX and Linux, and open source), even if I prefer mounting the SD card as a mass storage and manage it myself.
But I think the main problem today with manufacturers upgrades is with kernel drivers.
If all the kernel drivers were open source, I think now we could have them integrated in the official kernel, and upgrades could be smooth.
But a recent implementation of Android 2.0 for the Samsung Galaxy had to revert to "backport Android 2.0 to 2.6.27 kernel" because of missing driver sources.
It is the same problem plaguing Linux on the desktop. We need hardware developers to release hardware tech specs.
There is also the issue of phone manufacturers that want to customize Android in order to control the user experience. Since it is an open source application, they are free to do as they wish, even if it means running a version or two behind the official Android release. This is common in the open source world, for instance, KnoppMyth and other specialized distributions of Linux tend to lag behind the official releases.
What might be useful is to come up with a finite range of releases that developers should be expected to support. It also might be a good idea to create some kind of notification system that alerts developers as to changes in Android that might affect their applications. Google could set up the marketplace so they could get a list of applications, and hence developers, that use given features. When those features are going to be changed in an upcoming release, an automatic email could be sent to alert the developers. That might make it easier to ensure our applications aren't tripped up by the latest release.
It might eventually be possible to introduce a compatibility mode so older applications could run in the latest versions of Android, but I suspect that is a ways off since it is likely memory intensive.
Alessandro Pellizzari wrote: > Il giorno sab, 16/01/2010 alle 20.06 -0800, Alberto ha scritto:
>> So how do we fix this? I'm pretty sure you guys have already thought >> about this and I wouldn't be surprised if a solution was coming soon, >> since it''s such an obvious problem. However, here's my two cents, the >> solution is very simple, a desktop application for syncing/updating/ >> media playback/android market/amazon mp3, lets call it Android HQ or >> Android Home for the sake of argument.
>> The updates would be available to consumers as soon as they're >> released, instead of months, years, or never depending on carriers. >> This way most users would've the latest version as well as the >> developers would have the latest SDK, developers would be able to take >> advantage of the new APIs each updates bring and innovate faster, >> instead of spending time supporting older versions.
> I quite like your idea (but please make it cross-platform, or at least > for Windows, OSX and Linux, and open source), even if I prefer mounting > the SD card as a mass storage and manage it myself.
> But I think the main problem today with manufacturers upgrades is with > kernel drivers.
> If all the kernel drivers were open source, I think now we could have > them integrated in the official kernel, and upgrades could be smooth.
> But a recent implementation of Android 2.0 for the Samsung Galaxy had to > revert to "backport Android 2.0 to 2.6.27 kernel" because of missing > driver sources.
> It is the same problem plaguing Linux on the desktop. We need hardware > developers to release hardware tech specs.
> It might eventually be possible to introduce a compatibility mode so > older applications could run in the latest versions of Android, but I > suspect that is a ways off since it is likely memory intensive.
On the whole, older applications run quite delightfully in newer versions of Android.
Some small percentage of apps will need to be modified for any given Android release (e.g., those apps using contacts may need a revamp to deal with the new contacts API introduced with Android 2.0). And applications may need updates to take full advantage of newer capabilities (e.g., improved multiple screen resolution support introduced in Android 1.6).
Marks right, generally things work well. Although there do appear to be some differences between handsets in terms of their openGL support - seems like droid has some issues with png formats (at least from what I've seen on message boards)
On Jan 17, 2:35 pm, "Mark Murphy" <mmur...@commonsware.com> wrote:
> > It might eventually be possible to introduce a compatibility mode so > > older applications could run in the latest versions of Android, but I > > suspect that is a ways off since it is likely memory intensive.
> On the whole, older applications run quite delightfully in newer versions > of Android.
> Some small percentage of apps will need to be modified for any given > Android release (e.g., those apps using contacts may need a revamp to deal > with the new contacts API introduced with Android 2.0). And applications > may need updates to take full advantage of newer capabilities (e.g., > improved multiple screen resolution support introduced in Android 1.6).
There's also the issue that developers have to face about when to abandon a percentage of their users.
Take for instance, "Radar Now!" This app has 32% of the users still on 1.5 while over 50% are Droids (see http://www.radarnow/statistics.htm for details). The question begs, should I update the app to take advantage of the 1.6+ features so that the Droid and other non 320x480 devices can have a better experience or do I continue to support the 1.5 people at the expense of the greater user base?
If there were more timely upgrades to the OS for everyone, this dilemma wouldn't exist.
The fragmentation problem is mainly with the newest APIs, and applications taking advantage of them.
Official, or supported APIs barely change, and if they do, the older API is backward compatible. Take for instance the contacts API before 2.0 (Contacts.People), and the newest (ContactsContract) that supports multiple contacts sources (multiple google accounts syncing contacts). Using the Contacts.People API on newer versions (2.0+) still works, its just limited to display the contacts from the main account but it works, it doesn't break.
However, when it comes to newer APIs, like lets say Text-to-Speech (introduced in 1.6), and Dock support (introduced in 2.0), it's a pain in the butt to make the apps backward compatible with "older" or outdated devices, and take advantage of those APIs in "newer" or updated devices, yes, there are ways to introduce these new features, but its very painful to keep those users that are on older versions of android happy, without errors and such.
As of now it is an issue, not that big of an issue but it's there, and it can just become worse. Keeping track of 3-4 versions is not that big of a deal, but manufacturers need to move, because I would shoot myself if I had to keep supporting 5-6 versions of android (1.5, 1.6, 2.0, 2.1, 2.5?, 2.7?, 3.0?)... that my friends, will be extremely painful for MOST developers out there.
First.. let me ask for those of you that have apps in the market.. if I have a 1.5 version out there.. it shows up on any device that is 1.5 or later, right? Now..if I update it to run on 2.0.. will the update be made available or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later users in their market?
As someone else said, one of the appeals of Android, and no doubt one of the biggest reasons every carrier and manufacturer has jumped on board is the ability to customize it. For example, the new Sony phone coming out... it has a really nice custom in-house notification manager that no other phone has. It's that capability that is going to bring a lot of vendors and carrier to Android. Also keep in mind.. competition. If every android device looks/operates exactly the same.. then the only difference really is hardware and name brand recognition. A driving force behind all these companies supporting Android and building to it is to distinguish themselves from others. They want people to buy their phones because the Sense UI is "better" or "easier" than others. Android allows them to do this, and quite easily for the most part compared to say building on Palm's or other OSs out there. So without a doubt you're going to see different UIs and us developers may face UI issues trying to have apps integrate within those custom UIs. HOWEVER, I stand firm when I say.. if your app does NOT work on a given devices customized UI, its the fault of the customizer, not your app. They should absolutely be held to the same standards we are when it comes to developing on Android. If they make custom capabilities that do not work on other devices, what's the point of even using them? Honestly if Sony's custom scrolling notification system is accessible to us Android developers, then really it's only of use to build custom apps specific to that phone. It doesn't benefit Sony to make such a custom modification in hopes that us one-offs will build something from it that only runs on the Sony phone. Most likely they will do in-house stuff with it and offer custom apps for their phone only. I think this is possible, because Verizon has a tab on my moto droid, which I assume is only verizon and/or moto droid apps. So I would imagine Sony could provide a tab on the market specific to their phone, and place apps under it that will only show up for those using that phone. I am not for sure on this tho.
Lastly, while I agree it will be a pain for us developers to maintain multiple versions.. keep in mind that updates generally aren't more than a couple a year and as Mark and others said, most things work on newer updates. So unless you get issues with your app for specific API changes, you shouldn't have to worry too much about future updates. Even if you do, I don't see this being much different than most jobs I've had, where we have older versions of software that we still support, fix bugs in, and continue on with newer versions. As for display size changes. as far as I knew, if you built your app to the SDK.. your displays would resize properly in most cases. Not sure about video games, but at least most text based apps with the right layouts should work on any screen size. What are some examples of different screen sizes causing problems? I am curious for my own knowledge to be prepared as I haven't seen that issue brought up much.
On Sun, Jan 17, 2010 at 11:40 AM, Daniel <velaz...@gmail.com> wrote: > The fragmentation problem is mainly with the newest APIs, and > applications taking advantage of them.
> Official, or supported APIs barely change, and if they do, the older > API is backward compatible. > Take for instance the contacts API before 2.0 (Contacts.People), and > the newest (ContactsContract) that supports multiple contacts sources > (multiple google accounts syncing contacts). Using the Contacts.People > API on newer versions (2.0+) still works, its just limited to display > the contacts from the main account but it works, it doesn't break.
> However, when it comes to newer APIs, like lets say Text-to-Speech > (introduced in 1.6), and Dock support (introduced in 2.0), it's a pain > in the butt to make the apps backward compatible with "older" or > outdated devices, and take advantage of those APIs in "newer" or > updated devices, yes, there are ways to introduce these new features, > but its very painful to keep those users that are on older versions of > android happy, without errors and such.
> As of now it is an issue, not that big of an issue but it's there, and > it can just become worse. Keeping track of 3-4 versions is not that > big of a deal, but manufacturers need to move, because I would shoot > myself if I had to keep supporting 5-6 versions of android (1.5, 1.6, > 2.0, 2.1, 2.5?, 2.7?, 3.0?)... that my friends, will be extremely > painful for MOST developers out there.
> -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
1) It depends on your Manifest.xml file, if your minSdk is set to, lets say 4 (1.6), then new users on Android 1.6 and above will be the only ones that see it. UNLESS, users on 1.5 already had your app (it shows as installed, or purchased), then those users on sdk 3 (1.5) will still see it and be able to download that update, then it will forceclose and have all kinds of VerifyErrors when it comes to where you use the new APIs....
2) Completely agree, if manufacturers will create their own custom UI, then they need to NOT break official Android's APIs and that all android apps are compatible with their custom UI. Also, Verizon's tab on the Android market, as well as other carriers, are not showing apps that are specific to the phone you are using, those apps are just apps that are recommended by that specific carrier. T-mobile's tab has this as well (and they have an app called "AppPack", that lists the same apps apparently).
3) Agree, the problem comes when you need to update your app to support new stuff, for example when version 2.0 showed up, users wanted to see support on the Dock on several apps... or when 1.6 showed up, users wanted to see apps using the Text-to-Speech API on some apps, etc, etc... there are solutions, but they are very painful.
On Jan 17, 3:26 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> First.. let me ask for those of you that have apps in the market.. if I have > a 1.5 version out there.. it shows up on any device that is 1.5 or later, > right? Now..if I update it to run on 2.0.. will the update be made available > or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later > users in their market?
> As someone else said, one of the appeals of Android, and no doubt one of the > biggest reasons every carrier and manufacturer has jumped on board is the > ability to customize it. For example, the new Sony phone coming out... it > has a really nice custom in-house notification manager that no other phone > has. It's that capability that is going to bring a lot of vendors and > carrier to Android. Also keep in mind.. competition. If every android device > looks/operates exactly the same.. then the only difference really is > hardware and name brand recognition. A driving force behind all these > companies supporting Android and building to it is to distinguish themselves > from others. They want people to buy their phones because the Sense UI is > "better" or "easier" than others. Android allows them to do this, and quite > easily for the most part compared to say building on Palm's or other OSs out > there. So without a doubt you're going to see different UIs and us > developers may face UI issues trying to have apps integrate within those > custom UIs. HOWEVER, I stand firm when I say.. if your app does NOT work on > a given devices customized UI, its the fault of the customizer, not your > app. They should absolutely be held to the same standards we are when it > comes to developing on Android. If they make custom capabilities that do not > work on other devices, what's the point of even using them? Honestly if > Sony's custom scrolling notification system is accessible to us Android > developers, then really it's only of use to build custom apps specific to > that phone. It doesn't benefit Sony to make such a custom modification in > hopes that us one-offs will build something from it that only runs on the > Sony phone. Most likely they will do in-house stuff with it and offer custom > apps for their phone only. I think this is possible, because Verizon has a > tab on my moto droid, which I assume is only verizon and/or moto droid apps. > So I would imagine Sony could provide a tab on the market specific to their > phone, and place apps under it that will only show up for those using that > phone. I am not for sure on this tho.
> Lastly, while I agree it will be a pain for us developers to maintain > multiple versions.. keep in mind that updates generally aren't more than a > couple a year and as Mark and others said, most things work on newer > updates. So unless you get issues with your app for specific API changes, > you shouldn't have to worry too much about future updates. Even if you do, I > don't see this being much different than most jobs I've had, where we have > older versions of software that we still support, fix bugs in, and continue > on with newer versions. As for display size changes. as far as I knew, if > you built your app to the SDK.. your displays would resize properly in most > cases. Not sure about video games, but at least most text based apps with > the right layouts should work on any screen size. What are some examples of > different screen sizes causing problems? I am curious for my own knowledge > to be prepared as I haven't seen that issue brought up much.
> On Sun, Jan 17, 2010 at 11:40 AM, Daniel <velaz...@gmail.com> wrote: > > The fragmentation problem is mainly with the newest APIs, and > > applications taking advantage of them.
> > Official, or supported APIs barely change, and if they do, the older > > API is backward compatible. > > Take for instance the contacts API before 2.0 (Contacts.People), and > > the newest (ContactsContract) that supports multiple contacts sources > > (multiple google accounts syncing contacts). Using the Contacts.People > > API on newer versions (2.0+) still works, its just limited to display > > the contacts from the main account but it works, it doesn't break.
> > However, when it comes to newer APIs, like lets say Text-to-Speech > > (introduced in 1.6), and Dock support (introduced in 2.0), it's a pain > > in the butt to make the apps backward compatible with "older" or > > outdated devices, and take advantage of those APIs in "newer" or > > updated devices, yes, there are ways to introduce these new features, > > but its very painful to keep those users that are on older versions of > > android happy, without errors and such.
> > As of now it is an issue, not that big of an issue but it's there, and > > it can just become worse. Keeping track of 3-4 versions is not that > > big of a deal, but manufacturers need to move, because I would shoot > > myself if I had to keep supporting 5-6 versions of android (1.5, 1.6, > > 2.0, 2.1, 2.5?, 2.7?, 3.0?)... that my friends, will be extremely > > painful for MOST developers out there.
> > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en
On Jan 17, 9:26 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> First.. let me ask for those of you that have apps in the market.. if I have > a 1.5 version out there.. it shows up on any device that is 1.5 or later, > right? Now..if I update it to run on 2.0.. will the update be made available > or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later > users in their market?
By specifiying minSdkVersion and maxSdkVersion, you can provide different versions for different sdks. Every user would only see one version in the market, if I'm not mistaken. But you don't really want to do that unless you really need those different versions.
Man..now that sucks. That is a bug if you ask me.. the market should NOT show a 1.5 users a 1.6 SDK app update. That's just pure stupidity. That makes no sense at all and I am shocked and disturbed that this is how it works. They basically want you to submit a brand new 1.6 app so that 1.5 users don't get the update.. how hard is it to actually put a little code in the market app that checks the min SDK and even IF the user has the app, if their OS is not 1.6, don't show it. Very bad design of the market app developers/designers.
On Sun, Jan 17, 2010 at 2:03 PM, Christine <christine.kar...@gmail.com>wrote:
> On Jan 17, 9:26 pm, Kevin Duffey <andjar...@gmail.com> wrote: > > First.. let me ask for those of you that have apps in the market.. if I > have > > a 1.5 version out there.. it shows up on any device that is 1.5 or later, > > right? Now..if I update it to run on 2.0.. will the update be made > available > > or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later > > users in their market?
> By specifiying minSdkVersion and maxSdkVersion, you can provide > different versions for different sdks. Every user would only see one > version in the market, if I'm not mistaken. But you don't really want > to do that unless you really need those different versions.
> -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
You can have only *one* version of an app. Your app's ID is determined by its package-name. The code in your app should be able to run on a phone with an OS equal to minSdkVersion or higher.
You can specify that your app only supports (i.e. runs on) a certain number of SDKs:
minSdkVersion: Any user with a phone with an OS lower than this version, won't see the app in the Market and the OS won't allow it to be installed.
targetSdkVersion: Tells the software that an OS equal to this version running the app, needs no 'compatibility' code to be able to run this app.
maxSdkVersion: Any user with a phone with an OS higher than this version, won't see the app in the Market and the OS won't allow it to be installed.
On Jan 17, 5:14 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> Man..now that sucks. That is a bug if you ask me.. the market should NOT > show a 1.5 users a 1.6 SDK app update. That's just pure stupidity. That > makes no sense at all and I am shocked and disturbed that this is how it > works. They basically want you to submit a brand new 1.6 app so that 1.5 > users don't get the update.. how hard is it to actually put a little code in > the market app that checks the min SDK and even IF the user has the app, if > their OS is not 1.6, don't show it. Very bad design of the market app > developers/designers.
> On Sun, Jan 17, 2010 at 2:03 PM, Christine <christine.kar...@gmail.com>wrote:
> > On Jan 17, 9:26 pm, Kevin Duffey <andjar...@gmail.com> wrote: > > > First.. let me ask for those of you that have apps in the market.. if I > > have > > > a 1.5 version out there.. it shows up on any device that is 1.5 or later, > > > right? Now..if I update it to run on 2.0.. will the update be made > > available > > > or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later > > > users in their market?
> > By specifiying minSdkVersion and maxSdkVersion, you can provide > > different versions for different sdks. Every user would only see one > > version in the market, if I'm not mistaken. But you don't really want > > to do that unless you really need those different versions.
> > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en- Hide quoted text -
What I said is that you _can_ specify that a user sees only the one relevant version of your app in the mp. The mp _does_ read minsdkversion and maxsdkversion.
On Jan 17, 11:14 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> Man..now that sucks. That is a bug if you ask me.. the market should NOT > show a 1.5 users a 1.6 SDK app update. That's just pure stupidity. That > makes no sense at all and I am shocked and disturbed that this is how it > works. They basically want you to submit a brand new 1.6 app so that 1.5 > users don't get the update.. how hard is it to actually put a little code in > the market app that checks the min SDK and even IF the user has the app, if > their OS is not 1.6, don't show it. Very bad design of the market app > developers/designers.
> On Sun, Jan 17, 2010 at 2:03 PM, Christine <christine.kar...@gmail.com>wrote:
> > On Jan 17, 9:26 pm, Kevin Duffey <andjar...@gmail.com> wrote: > > > First.. let me ask for those of you that have apps in the market.. if I > > have > > > a 1.5 version out there.. it shows up on any device that is 1.5 or later, > > > right? Now..if I update it to run on 2.0.. will the update be made > > available > > > or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later > > > users in their market?
> > By specifiying minSdkVersion and maxSdkVersion, you can provide > > different versions for different sdks. Every user would only see one > > version in the market, if I'm not mistaken. But you don't really want > > to do that unless you really need those different versions.
> > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en
I agree with Mark that older apps, like 1.6 apps, run "happily" on newer sdks. Most apps can do without the newer features, if you accept that sometimes you have to do more work, or the feature you build is slightly less attractive. Or, you can have a Factory class that returns the right version class to use. As far as I have seen, you can have 2.1 classes in a 1.6 app, as long as you don't instantiate them.
On Jan 18, 10:26 am, Christine <christine.kar...@gmail.com> wrote:
> What I said is that you _can_ specify that a user sees only the one > relevant version of your app in the mp. The mp _does_ read > minsdkversion and maxsdkversion.
> On Jan 17, 11:14 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> > Man..now that sucks. That is a bug if you ask me.. the market should NOT > > show a 1.5 users a 1.6 SDK app update. That's just pure stupidity. That > > makes no sense at all and I am shocked and disturbed that this is how it > > works. They basically want you to submit a brand new 1.6 app so that 1.5 > > users don't get the update.. how hard is it to actually put a little code in > > the market app that checks the min SDK and even IF the user has the app, if > > their OS is not 1.6, don't show it. Very bad design of the market app > > developers/designers.
> > On Sun, Jan 17, 2010 at 2:03 PM, Christine <christine.kar...@gmail.com>wrote:
> > > On Jan 17, 9:26 pm, Kevin Duffey <andjar...@gmail.com> wrote: > > > > First.. let me ask for those of you that have apps in the market.. if I > > > have > > > > a 1.5 version out there.. it shows up on any device that is 1.5 or later, > > > > right? Now..if I update it to run on 2.0.. will the update be made > > > available > > > > or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later > > > > users in their market?
> > > By specifiying minSdkVersion and maxSdkVersion, you can provide > > > different versions for different sdks. Every user would only see one > > > version in the market, if I'm not mistaken. But you don't really want > > > to do that unless you really need those different versions.
> > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to android-developers@googlegroups.com > > > To unsubscribe from this group, send email to > > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en
I believe that maxsdkversion has already been or is in the process of being depreciated, meaning the market no longer looks at that tag in the manifest. Which makes sense because if the OS updated to a newer version but not all the apps did, they would dissapear in the market to that user, despite the fact that most would still work perfectly fine.
-theSmith
On Jan 18, 5:48 am, Christine <christine.kar...@gmail.com> wrote:
> I agree with Mark that older apps, like 1.6 apps, run "happily" on > newer sdks. Most apps can do without the newer features, if you accept > that sometimes you have to do more work, or the feature you build is > slightly less attractive. Or, you can have a Factory class that > returns the right version class to use. As far as I have seen, you can > have 2.1 classes in a 1.6 app, as long as you don't instantiate them.
> On Jan 18, 10:26 am, Christine <christine.kar...@gmail.com> wrote:
> > What I said is that you _can_ specify that a user sees only the one > > relevant version of your app in the mp. The mp _does_ read > > minsdkversion and maxsdkversion.
> > On Jan 17, 11:14 pm, Kevin Duffey <andjar...@gmail.com> wrote:
> > > Man..now that sucks. That is a bug if you ask me.. the market should NOT > > > show a 1.5 users a 1.6 SDK app update. That's just pure stupidity. That > > > makes no sense at all and I am shocked and disturbed that this is how it > > > works. They basically want you to submit a brand new 1.6 app so that 1.5 > > > users don't get the update.. how hard is it to actually put a little code in > > > the market app that checks the min SDK and even IF the user has the app, if > > > their OS is not 1.6, don't show it. Very bad design of the market app > > > developers/designers.
> > > On Sun, Jan 17, 2010 at 2:03 PM, Christine <christine.kar...@gmail.com>wrote:
> > > > On Jan 17, 9:26 pm, Kevin Duffey <andjar...@gmail.com> wrote: > > > > > First.. let me ask for those of you that have apps in the market.. if I > > > > have > > > > > a 1.5 version out there.. it shows up on any device that is 1.5 or later, > > > > > right? Now..if I update it to run on 2.0.. will the update be made > > > > available > > > > > or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later > > > > > users in their market?
> > > > By specifiying minSdkVersion and maxSdkVersion, you can provide > > > > different versions for different sdks. Every user would only see one > > > > version in the market, if I'm not mistaken. But you don't really want > > > > to do that unless you really need those different versions.
> > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Android Developers" group. > > > > To post to this group, send email to android-developers@googlegroups.com > > > > To unsubscribe from this group, send email to > > > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > > > > For more options, visit this group at > > > >http://groups.google.com/group/android-developers?hl=en
Hmm, I've toyed with that a while back, and as far as I remember, the app won't even launch, and crash with a class-not-found exception (makes somewhat sense). AFAIK, you cannot slide in dummy classes in Android's namespace work around that either. Or did I miss something?
On Jan 18, 2:48 am, Christine <christine.kar...@gmail.com> wrote:
On Mon, Jan 18, 2010 at 7:22 AM, JP <joachim.pfeif...@gmail.com> wrote: > Hmm, I've toyed with that a while back, and as far as I remember, the > app won't even launch, and crash with a class-not-found exception > (makes somewhat sense).
If you just do things correctly, it is fine. And correctly means: make sure that the code that runs when on an older version of the will never reference code that uses newer APIs.
An article on doing this is here; note in particular the last part, about how you can have classes that use new APIs and detect whether to use those classes. (You could also just check the platform version to decide whether to use it.)
Also note that simple constants like integers get compiled in to your app instead of referencing the original symbol, so you don't need to do anything when using new constants like flags. There are a lot of other things that conveniently work out as well -- for example, here is sample code for a Service that uses the new 2.0 APIs if available but still works on older versions of the platform:
// This is the old onStart method that will be called on the pre-2.0 // platform. On 2.0 or later we override onStartCommand() so this // method will not be called. @Override public void onStart(Intent intent, int startId) { handleStart(intent, startId); }
@Override public int onStartCommand(Intent intent, int flags, int startId) { handleStart(intent, startId); return START_NOT_STICKY; }
void handleStart(Intent intent, int startId) { // do work }
If there are specific issues people are having with using newer APIs in an a compatible way, it would be really useful to post a question about them (please in a separate thread) so that they can be addressed. Hopefully in most cases it is just a matter of knowing the tricks to do, though there may be ways we have done some new APIs that make them needlessly more difficult to use that we should avoid in the future.
Finally, as far as dealing with multiple versions of the platform -- how different is this, really, than Windows and MacOS where there are three or more different major versions of those platforms in active use? (And on MacOS, for quite a while now different CPU architectures!) You just do on Android exactly the same thing you do on those platforms: look at the distribution of versions to decide the minimum one you want to target, and do the appropriate thing for using newer APIs when you want to do that.
Honestly I get really frustrated when people talk about different versions of the platform as "fragmentation." Where does that come from?? Is Windows fragmented? Is MacOS fragmented? People talk about Android fragmentation in these terms as if it is this unique, novel, killer issue in Android, and yet it is little different than other platforms.
The main difference is, yes, a user of a particular phone can't go out and buy a newer version of the platform in order to run your app. Unfortunately there isn't really a solution to this -- nobody but the hardware manufacturer can supply newer versions of the platform to their device, since they need to include the drivers and customization that are needed for that device. On the other hand, if you are doing your app on Windows, what is the chance that they would upgrade from XP to Windows 7 just to buy and run it?
(Then we can go off on web-based apps and the various browser versions that need to be supported.)
But let's look at the current situation: the oldest version of the platform that developers need to worry about is 1.5, which was finished less than a year ago. It appears to me that most of the manufacturers that have such devices on the market have pledged to update them to 2.x. If things proceed how it sounds, I think the bulk of the devices will be running a platform version released in the last year. So that gives you an upper bound of maybe 4 platform versions to support. (And keep in mind -- doing 4 significant platform releases in a year is pretty extreme, and maybe not something that will continue. If you think it is hard on you, imagine the poor platform developers. :p)
Now I wouldn't be surprised to see the active versions spread out over time, as older devices are no longer supported so stay on an older version of the platform. But if we assume the active lifetime of a smartphone is around 2 years, there are going to be strong bounds on how old a version of the platform you need to go down to, to support most active phones.
And even if 1.5 continues to ship on new phones for years and you need to support it to get 80% of the market -- that platform release is a very rich and functional base. There are a few things that you'd need to do to work well on newer platforms (supporting the new Contacts API probably being the biggest), but for the most part you can just focus on that platform version and write a perfectly fine app.
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
Good reply Dianne. I get pissed when I read blogs about how fragmented Android is as well. I don't get how it's fragmented. The only fragmentation that seems slightly just is the issue where individual phone vendors are providing their own special UI and extra features. I think the biggest issue that we may face is if our app doesn't work on those devices due to them rebuilding android for their device that may affect our apps running on them as they should. I personally don't know if this is happening. So far most posts I've seen indicate the issue of phones that are 1.5 to 2.1 with 1.5 apps not working on 2.0 or vice versa.
Dianne, can you clarify the issue of updates... if I have a 1.5 app and update my app, changing the minsdk to 2.1, will a user on a 1.5 phone be able to update to the 2.1 version? One post here indicated that once a user has installed the app, which was fine for the 1.5 app on a 1.5 phone... that they can then get the updates even if the minsdk of the updated app is higher than the phone it's to be run on? That doesn't make any sense that if it's not installed, it wont even show up (which is good), but if you installed it then update it to work on newer versions, that the older api phones can still update to it, most likely causing it to not work any more. It seems to me we're forced to build a new app for the later api IF it might not work on the older api devices due to some api calls, such as the contacts api.
On Mon, Jan 18, 2010 at 10:35 AM, Dianne Hackborn <hack...@android.com>wrote:
> On Mon, Jan 18, 2010 at 7:22 AM, JP <joachim.pfeif...@gmail.com> wrote:
>> Hmm, I've toyed with that a while back, and as far as I remember, the >> app won't even launch, and crash with a class-not-found exception >> (makes somewhat sense).
> If you just do things correctly, it is fine. And correctly means: make > sure that the code that runs when on an older version of the will never > reference code that uses newer APIs.
> An article on doing this is here; note in particular the last part, about > how you can have classes that use new APIs and detect whether to use those > classes. (You could also just check the platform version to decide whether > to use it.)
> Also note that simple constants like integers get compiled in to your app > instead of referencing the original symbol, so you don't need to do anything > when using new constants like flags. There are a lot of other things that > conveniently work out as well -- for example, here is sample code for a > Service that uses the new 2.0 APIs if available but still works on older > versions of the platform:
> // This is the old onStart method that will be called on the pre-2.0 > // platform. On 2.0 or later we override onStartCommand() so this > // method will not be called. > @Override > public void onStart(Intent intent, int startId) { > handleStart(intent, startId); > }
> @Override > public int onStartCommand(Intent intent, int flags, int startId) { > handleStart(intent, startId); > return START_NOT_STICKY; > }
> void handleStart(Intent intent, int startId) { > // do work > }
> If there are specific issues people are having with using newer APIs in an > a compatible way, it would be really useful to post a question about them > (please in a separate thread) so that they can be addressed. Hopefully in > most cases it is just a matter of knowing the tricks to do, though there may > be ways we have done some new APIs that make them needlessly more difficult > to use that we should avoid in the future.
> Finally, as far as dealing with multiple versions of the platform -- how > different is this, really, than Windows and MacOS where there are three or > more different major versions of those platforms in active use? (And on > MacOS, for quite a while now different CPU architectures!) You just do on > Android exactly the same thing you do on those platforms: look at the > distribution of versions to decide the minimum one you want to target, and > do the appropriate thing for using newer APIs when you want to do that.
> Honestly I get really frustrated when people talk about different versions > of the platform as "fragmentation." Where does that come from?? Is Windows > fragmented? Is MacOS fragmented? People talk about Android fragmentation > in these terms as if it is this unique, novel, killer issue in Android, and > yet it is little different than other platforms.
> The main difference is, yes, a user of a particular phone can't go out and > buy a newer version of the platform in order to run your app. Unfortunately > there isn't really a solution to this -- nobody but the hardware > manufacturer can supply newer versions of the platform to their device, > since they need to include the drivers and customization that are needed for > that device. On the other hand, if you are doing your app on Windows, what > is the chance that they would upgrade from XP to Windows 7 just to buy and > run it?
> (Then we can go off on web-based apps and the various browser versions that > need to be supported.)
> But let's look at the current situation: the oldest version of the platform > that developers need to worry about is 1.5, which was finished less than a > year ago. It appears to me that most of the manufacturers that have such > devices on the market have pledged to update them to 2.x. If things proceed > how it sounds, I think the bulk of the devices will be running a platform > version released in the last year. So that gives you an upper bound of > maybe 4 platform versions to support. (And keep in mind -- doing 4 > significant platform releases in a year is pretty extreme, and maybe not > something that will continue. If you think it is hard on you, imagine the > poor platform developers. :p)
> Now I wouldn't be surprised to see the active versions spread out over > time, as older devices are no longer supported so stay on an older version > of the platform. But if we assume the active lifetime of a smartphone is > around 2 years, there are going to be strong bounds on how old a version of > the platform you need to go down to, to support most active phones.
> And even if 1.5 continues to ship on new phones for years and you need to > support it to get 80% of the market -- that platform release is a very rich > and functional base. There are a few things that you'd need to do to work > well on newer platforms (supporting the new Contacts API probably being the > biggest), but for the most part you can just focus on that platform version > and write a perfectly fine app.
> Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them.
> -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
On Jan 18, 10:35 am, Dianne Hackborn <hack...@android.com> wrote:
> On Mon, Jan 18, 2010 at 7:22 AM, JP <joachim.pfeif...@gmail.com> wrote: > > Hmm, I've toyed with that a while back, and as far as I remember, the > > app won't even launch, and crash with a class-not-found exception > > (makes somewhat sense).
This means having to cut off users on older Android releases, no? Kevin illustrates the problem nicely. It's unfortunate that some of the carriers and manufacturers haven't caught on to the idea of bringing their products along for the ride, at least not yet, which I believe is one core issue of the barrage of complaints.
> Finally, as far as dealing with multiple versions of the platform -- how > different is this, really, than Windows and MacOS where there are three or > more different major versions of those platforms in active use? (And on > MacOS, for quite a while now different CPU architectures!) You just do on > Android exactly the same thing you do on those platforms: look at the > distribution of versions to decide the minimum one you want to target, and > do the appropriate thing for using newer APIs when you want to do that.
It is different in that XP through Windows 7 have been released over the course of, what, eight years now? Users are much more educated and experienced in what to expect. At work, I, like many users (hopefully), "just" pick up the phone or send an email, and the problem will be taken care of. On a mobile device however... it just kindof ought to work, which isn't an unreasonable expectation. Being facetious with the backwards logic, the level of support that Google set aside to support the release of the N1 seems to confirm that idea. As far as OS X goes, during a couple of years of transition, Apple supported "fat" binaries just like they did when they switched OpenSTEP from Motorola to Intel a decade earlier. There's experience with that, and in the mobile environment, this is all new stuff and needs to be managed accordingly, IMHO. I want to add, no question of course, it would be unjust to criticize anybody that an expectation wasn't set that Android would be subjected to a degree of fragmentation when Android was first released "wayback". Yet, here we are, and it would be disappointing to see the issue glossed over.
> But let's look at the current situation: the oldest version of the platform > that developers need to worry about is 1.5, which was finished less than a > year ago. It appears to me that most of the manufacturers that have such > devices on the market have pledged to update them to 2.x. If things proceed > how it sounds, I think the bulk of the devices will be running a platform > version released in the last year. So that gives you an upper bound of > maybe 4 platform versions to support. (And keep in mind -- doing 4 > significant platform releases in a year is pretty extreme, and maybe not > something that will continue. If you think it is hard on you, imagine the > poor platform developers. :p)
On Mon, Jan 18, 2010 at 1:58 PM, JP <joachim.pfeif...@gmail.com> wrote: > It's unfortunate that some of the carriers and manufacturers haven't > caught on to the idea of bringing their products along for the ride,
There's no incentive. The (phone) sale has already been made, why on earth would they then want to also support it?
Exactly. That's how they operate. Kindof enticing when you're a dev. Crank it out, push it to the consumer, hope it runs and if there's nothing major (like Rogers' 911 issue), leave the code behind and move on to the next thing.
On Jan 18, 12:03 pm, Greg Donald <gdon...@gmail.com> wrote:
> On Mon, Jan 18, 2010 at 1:58 PM, JP <joachim.pfeif...@gmail.com> wrote: > > It's unfortunate that some of the carriers and manufacturers haven't > > caught on to the idea of bringing their products along for the ride,
> There's no incentive. The (phone) sale has already been made, why on > earth would they then want to also support it?
> -- > Greg Donald > destiney.com | gregdonald.com
On Mon, Jan 18, 2010 at 10:57 AM, Kevin Duffey <andjar...@gmail.com> wrote: > Good reply Dianne. I get pissed when I read blogs about how fragmented > Android is as well. I don't get how it's fragmented. The only fragmentation > that seems slightly just is the issue where individual phone vendors are > providing their own special UI and extra features. I think the biggest issue > that we may face is if our app doesn't work on those devices due to them > rebuilding android for their device that may affect our apps running on them > as they should. I personally don't know if this is happening. So far most > posts I've seen indicate the issue of phones that are 1.5 to 2.1 with 1.5 > apps not working on 2.0 or vice versa.
Yeah manufacturer customization is definitely the kind of fragmentation that is more unusual to Android, and something we care a lot about. There have certainly been some issues there, but I think a lot of this is just everyone learning how to do things (manufacturers, developers, and the platform) to avoid the problems. Certainly, it is not yet anywhere near like what MIDP got like, which is the scary monster that people are conjuring up (whether they realize it or not) when they say "fragmentation."
> Dianne, can you clarify the issue of updates... if I have a 1.5 app and > update my app, changing the minsdk to 2.1, will a user on a 1.5 phone be > able to update to the 2.1 version? One post here indicated that once a user > has installed the app, which was fine for the 1.5 app on a 1.5 phone... that > they can then get the updates even if the minsdk of the updated app is > higher than the phone it's to be run on? That doesn't make any sense that if > it's not installed, it wont even show up (which is good), but if you > installed it then update it to work on newer versions, that the older api > phones can still update to it, most likely causing it to not work any more. > It seems to me we're forced to build a new app for the later api IF it might > not work on the older api devices due to some api calls, such as the > contacts api.
I don't work on the Market team, so I'm not sure of the current situation, but if you say minSdkVerion=5 then your app should never be delivered to a device running something < 5. If there are cases when it can be, then that needs to be fixed.
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
On Mon, Jan 18, 2010 at 12:14 PM, JP <joachim.pfeif...@gmail.com> wrote: > Exactly. That's how they operate. Kindof enticing when you're a dev. > Crank it out, push it to the consumer, hope it runs and if there's > nothing major (like Rogers' 911 issue), leave the code behind and move > on to the next thing.
Actually I am seeing a lot of positive change in this regard -- most of the major manufacturers (HTC, Motorola) seem to have publicly stated that they will be delivering a significant update to their current devices.
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
Um. No? The entire article is about how to use newer APIs while remaining compatible with older platforms. Am I missing something?
> Kevin illustrates the problem nicely.
What is that exactly? I see him talking about incompatible manufacturer customizations and how fixing those are the responsibility of the manufacturer (true), about newer platform versions being compatible with older ones and maintaining support for older ones not being a big deal, and concern about minSdkVersion not filtering app from older platforms which should definitely not be true.
I'd just like to understand what the specific concern is.
> It is different in that XP through Windows 7 have been released over > the course of, what, eight years now?
True, we have gone through a number of releases in the last year. Of course windows has also gone through lots of service packs etc. But regardless, in both cases basically one release builds on another, so you are looking at targeting release X through Y and whatever number of intermediate steps there are between is not that much of an issue (though you will certainly want to be testing against intermediate release to verify there are no surprises).
> Users are much more educated and > experienced in what to expect. At work, I, like many users > (hopefully), "just" pick up the phone or send an email, and the > problem will be taken care of. > On a mobile device however... it just kindof ought to work, which > isn't an unreasonable expectation. Being facetious with the backwards > logic, the level of support that Google set aside to support the > release of the N1 seems to confirm that idea.
Sorry I am really not following this part. :} Yes, you should be able to just pick up a phone and use it, and for the most part that is the case (as long as developers properly mark their minSdkVersion to not be visible on older platforms, and the occasional manufacturer-specific bug here and there). I don't know how much support you think Google set aside for the N1 (was it large or small? support for what?) so I am pretty lost there.
> As far as OS X goes, during a couple of years of transition, Apple > supported "fat" binaries just like they did when they switched > OpenSTEP from Motorola to Intel a decade earlier. There's experience > with that, and in the mobile environment, this is all new stuff and > needs to be managed accordingly, IMHO.
Sure and when 1.6 came out to introduce new screen support, it also included a lot of compatibility design and code to ensure that existing applications would work on the new screens. (Or when not possible, such as QVGA screens, require that applications be explicitly updated and marked as compatible with them before allowing them to be available to users of those devices).
What's different here?
> I want to add, no question of course, it would be unjust to criticize > anybody that an expectation wasn't set that Android would be subjected > to a degree of fragmentation when Android was first released > "wayback". Yet, here we are, and it would be disappointing to see the > issue glossed over.
I'm not sure how things are being glossed over...?
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
Exactly, some carriers won't go through the trouble of doing OTA updates, your Android experience would vary depending on what carrier you're. Also when I talk about fragmentation, I'm not just talking about apps compatibility, but also the user experience is very different from 1.6 to 2.1, some people might hate or love Android depending on what version they're using.
Dianne: I understand the issue with manufacturers and drivers, but even if manufacturers have to prepare the updates for each handsets, wouldn't be possible for Google to distribute those updates through their own channels instead of going the carriers' way, for example, correct me if I'm wrong in any of this:
1. Google releases the source code 2. Manufacturers customizes it for their handsets (drivers, etc) 3. They send it back to Google 4. Google updates most Android phones through their own channel at the same time, very quickly most phones are running the latest version
I know this is oversimplifying it a lot, and in the real world it doesn't work like this, but I think I'm onto something, if the updates are left to the carriers some phones will get the updates and others won't, maybe that's something you guys can live with.
With all that said, even if there's nothing Google can do about the updates, a companion desktop application for Android would help keep the platform together, kind of like the lowest common denominator that every "Google Experience" phone can plug into.
