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 <[email protected]>wrote: > On Mon, Jan 18, 2010 at 7:22 AM, JP <[email protected]> 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.) > > > http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html > > 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. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > 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 [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en >
-- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
