Best practice for changing min SDK

by Warren » Tue, 03 Aug 2010 01:23:38 GMT


Sponsored Links
 I have a sizable install base already on some apps with Android 1.5
set as the minimum version.  I want to update the apps to take
advantage of some of the newer features offered in Android 2.0 and
greater. What is the best way forward so I don't break things for my
current 1.5 and 1.6 users?

If I simply update the application with a new min SDK version, will
1.5 and 1.6 users be prompted to uninstall? Or will they just not see
the update?

What about future development that I want to apply for everyone, say a
bugfix. Will I have painted myself into a corner?

Another solution would be to fork and create a new app for 2.0 users,
but that is undesirable for several reasons.

This must be a somewhat common problem. Have you seen any good ways to
handle it?

Warren

--



Best practice for changing min SDK

by TreKing » Tue, 03 Aug 2010 01:43:25 GMT


 



Use reflection or check the build version to determine if you can use newer
APIs.



I assume they will not see the update. There's no reason to do this though.



Not if you do it correctly.



Yeah, don't do that.



Repeat: use reflection or check the build version to determine if you can
use newer APIs.

There's a blog post on this subject. Go find it =)

-------------------------------------------------------------------------------------------------
TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices

--


Sponsored Links


Best practice for changing min SDK

by Warren » Tue, 03 Aug 2010 04:55:34 GMT


 Thanks.

I found this post for others who are looking:

 http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html 

Warren







--



Re: Best practice for changing min SDK

by Robert Massaioli » Wed, 16 Mar 2011 08:15:35 GMT


 >

Just out of interest though does anybody know what would happen if you just 
did this anyway? What happens when you bump the min SDK version up?

Thanks,
Robert 

-- 



Re: Best practice for changing min SDK

by TreKing » Wed, 16 Mar 2011 08:53:29 GMT


 On Tue, Mar 15, 2011 at 7:15 PM, Robert Massaioli <robertmassai...@gmail.com





AFAIK, your app disappears from the Market for those people that don't have
the right OS version, though they keep the app. They cannot update and if
they uninstall, they cannot redownload the app. Tread carefully.

-------------------------------------------------------------------------------------------------
TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices

-- 



Re: Best practice for changing min SDK

by Robert Massaioli » Wed, 16 Mar 2011 09:03:18 GMT


 Thanks for the response. That makes sense, in that case I was considering 
releasing my app so that it supported version 3 of the SDK because that 
would be easy to do, however I really want the android.accounts package so 
maybe I will just make the min SDK level be 5 and ignore those on old 
phones. (And then I don't have to do that backwards compatibility reflection 
mess to get the android.accounts package)

They only make up a really small segment of the market anyway: 
 http://developer.android.com/resources/dashboard/platform-versions.html 

Thanks,
Robert

-- 



Re: Best practice for changing min SDK

by TreKing » Wed, 16 Mar 2011 09:18:38 GMT


 On Tue, Mar 15, 2011 at 8:03 PM, Robert Massaioli <robertmassai...@gmail.com




That says 3.0%. The new Developer Console stats say 5.1%. Personally, I
wouldn't trust either since they come from the Market app which has proven
to be completely unreliable in reporting these statistics. Add your own
analytics if you can and base your decision on that.

-------------------------------------------------------------------------------------------------
TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices

-- 



Re: Best practice for changing min SDK

by Robert Massaioli » Wed, 16 Mar 2011 09:34:11 GMT


 Well that is annoying, cannot even trust the statistics pages. Now I 
actually have to debate what to do. Not as fun as I was planning. Ah well, I 
guess that is the price that people pay for newer and better versions of 
Android. Though Google really needs to get ontop of those statistics then; I 
hope they are working on that now.

Thanks for letting me know though. Actually...can you please post the 
statistics that the developer console gives you for device distribution? I 
don't have an account yet or an app online and I would really appreciate it.

Thanks again,
Robert

-- 



Re: Best practice for changing min SDK

by TreKing » Wed, 16 Mar 2011 10:17:47 GMT


 On Tue, Mar 15, 2011 at 8:34 PM, Robert Massaioli <robertmassai...@gmail.com





First value is from the console, second from the chart linked, blanks are
not available. 2.1 is the only one that's even remotely close.

Android 3.0 0.2%
Android 2.2    57.1% 61.3%
Android 2.1    29.3% 29.0%
Android 1.6    7.0% 4.8%
Android 1.5    5.1% 3.0%
Android 2.3.3  0.6% 1.0%
Android 2.3    0.2% 0.7%
Android 2.0.1  0.1%
Android 1.1    0.1%
Android 1.0    0.1%
Android 2.0    0.0%

-------------------------------------------------------------------------------------------------
TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices

-- 



Re: Best practice for changing min SDK

by Robert Massaioli » Wed, 16 Mar 2011 10:43:25 GMT


 Thankyou, these are really useful statistics though it is really confusing 
that they tell different stories. However it does say that everything below 
v7 of the SDK is only about ten percent of the market which I think means 
that app developers will ditch those platforms in the future. (If not right 
now)

-- 



Re: Best practice for changing min SDK

by String » Wed, 16 Mar 2011 15:12:59 GMT


 


everything below v7 of the SDK is only about ten percent of the market which 


I don't know about you, but I'm disinclined to unilaterally chop 10% off my 
sales. After the recent Market ranking shenanigans, they're shaky enough as 
it is.

String 

-- 



Re: Best practice for changing min SDK

by Robert Massaioli » Wed, 16 Mar 2011 19:05:10 GMT


 Actually I made that comment a little flippantly; 10% still translates to a 
whole bunch of users when you are talking about an OS like Android. I have 
changed my mind and I will suffer a little bit of that 
Backwards Compatibility pain in order to cater for every user.

-- 



Re: Best practice for changing min SDK

by lbendlin » Wed, 16 Mar 2011 19:35:20 GMT


 You will have to keep in mind that the 1.5 phones have no chance of
ever being upgraded. So they are there to stay, as long as the owner
thinks they are devcent as a phone (most are). You'll need to support
1.5 for at least another two years. I have my MinSDK set at 3 and use
reflection successfully.

Once you understand that it's not much more than an additional "shell"
that prevents the system from checking if an object is compatible with
the target SDK you'll find reflection pretty easy to use.

On Mar 16, 6:52am, Robert Massaioli <robertmassai...@gmail.com>



-- 



Re: Best practice for changing min SDK

by Lance Nanek » Fri, 18 Mar 2011 02:35:44 GMT


 Isn't the chart a measurement of the phones with Market installed
whereas the console statistics we are talking about are for all apps?
So if Market is installed on one Android 1.5 phone and one Android 2.0
phone, that's 50/50 for the chart. Now if the first phone had 1 app
and the second phone had 3 apps, that would be 25/75 for the console
stats, all apps readout? Just saying the definitions could be
different, thus it would make sense for the numbers to be different.





-- 



Re: Re: Best practice for changing min SDK

by TreKing » Fri, 18 Mar 2011 02:41:02 GMT


 



As usual, the only people that can answer that with any certainty are not
going to, so let's all keep making stuff up.

-------------------------------------------------------------------------------------------------
TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices

-- 



Other Threads

1. Kernel module development

Hello there,

I'd like to learn how to write kernel modules for Android. And I don't
know how to start. I'm working on Windows XP and Ubuntu 9.10.
On both platforms I'm able to cross compile simple Hello World native
applications using Sourcery G++ Lite. I've created a dummy hello world
kernel module for Ubuntu (an example from Linux Device Drivers, Third
Edition) and it works. Now I'd like to do the same for Android - I
hope it's possible at all.Where should I start? Getting sources from
source.android.com (which project, all of them). How to build it.

Thank you
    Rafa Grzybowski

-- 
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: 

2. Extending KeyEvent (or another way of adding new KeyCodes)

Why do you need to add new keycode if it only has 4 buttons?
What functions do you expect to add?

If you really want to do, see my patch for how to add
PageUp & PageDown to android.

https://review.source.android.com/#change,10065

(it is verified, but I don't understand why it's still not been added
to AOSP)





-- 
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: 

3. Extending KeyEvent (or another way of adding new KeyCodes)

4. Does Intent use Binder driver to implement?

5. Update language in Widget

6. What am I doing wrong?

7. msm72k_udc: msm72k_dequeue() fi