My doubt is about the differences between different SDK's and how they affect our app development?
Let say i created an app with sdk api 22(lollipop) now can it be deployed to Android api 23(Marshmellow)?
And if possible what about the deprecated classes like Http from apache which is present in api 22 but deprecated in api 23?
Do i have to use different build tools to be able to deploy to different Versions?
And also what exactly does it mean to have a class deprecated?
I know this is a huge list of questions (more like whining) but these are a few doubts thats been nagging me for a while.
Thanking for your response!
You can deploy the app you developed with target api 22 to 23 by doing the following,
a. Change the target API to 23 or the latest and then recompile it again and build a new .APK
b. In case of changes like the one happened in M - they added run time permissions, we need to handle those, else there is no purpose you see.
Deprecated - What does "This method is deprecated" mean for application developers this one gives you good insights on deprecated
No, you need not use different builds, you can find out the BUILD on run time and handle. More on that here - How to deal with deprecated classes in Android to keep compatibility
All the best.
Related
First off, I know very little about android development, I am just getting started.
What is the Minimum SDK choice that you get when creating a project in android studio? Is there a downside to using an older one? And if I follow a tutorial is it essential that I use the same one so I can follow along?
Thanks.
What is the Minimum SDK choice that you get when creating a project in android studio?
That is the oldest version of Android that you are willing to support. It is expressed in terms of an API level. You can see common API levels in the Android dashboards, and the documentation will point out in many places where things need such-and-so an API level to work.
Is there a downside to using an older one?
Less stuff in Android will be supported. In your case, since you are following a tutorial, choosing a lower minSdkVersion may cause some more complaints from your IDE, saying that such-and-so is not available on your chosen minSdkVersion.
And if I follow a tutorial is it essential that I use the same one so I can follow along?
IMHO, that depends on your overall programming experience. If you are a veteran developer, and you want to play around with a lower minSdkVersion, go ahead, bearing in mind that the tutorial code might not run on that API level. If you are fairly new to programming overall, stick with what the tutorial tells you to do. If your concern is that your test device is not new enough for the tutorial, find a different tutorial, find a different device, or use the emulator instead of a device for testing this tutorial.
android:minSdkVersion
An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.
You can use your own min SDK but be careful about features you use. infact, minSDK with great number have more features.
Android platform sample codes and reference from the Android developer site is based on platform 1.5 I understand that newer platforms can support applications developed on older platforms but the reciprocal is not applicable which makes sense but is the coding different? Are codes that were used for developing 1.5 apps still useful in newer platforms or have newer classes and methods replaced them? It seems that eclipse is producing a lot of coding errors in its samples in relation to classes and methods also if a app that was developd by a IME is unable to be viewed on the emulator or how can it be tested or retrieved on the device? Any advice is welcome...sorry it's so long
If you look in the SDK folders, on windows it will be c:\<SDK location>\samples\android-x the samples are located according to api level so they will definitely be compatible there so I would look at these.
To answer your other questions, yes there are api changes as you go up an api level so they should cause warnings or compilation errors and some classes may even be completely removed. Generally the lower level stuff shouldn't change too much but the most important thing is that the semantics change rarely unless there was a design flaw in the original implementations.
The release notes for each version usually points out what has changed and the online documentation is generally superb in my opinion in informing you what exactly is deprecated. If you are just targeting old devices then your emulator is just set to target those api levels but if you are concerned about functionality then you could code using api 1.5 say, and run an ICS api level 15 emulator and check everything works OK, if not then you decide what the best strategy should be. Generally I would advise to target Android 2.2 and above for mobile devices and 3.0 for tablets but really it is up to you.
three are classes that are deprecated and can't be used anymore, like Contacts.People. There are also classes that are deprecated, they can still be used but they should be avoided in new projects. And there are new classes that were not available before. In some cases like for Fragment there are compatibility support libs to use the new features on the old platform but this is not true for classes like for example PreferenceFragment that are not supported on old platforms.
I'm developing an Android app which will target 2.1/2.2 devices, so I have my project set up to use the 2.2 SDK (API level 8), but allow for installation on devices with at least API level 7.
The problem is that during my daily development, I'm not always paying close attention to which API level of the methods/classes/constants that I'm using, which makes it very easy to break code on older devices. I have got dynamic classloading working, and as much as I dislike having a ton of extra factory classes and interfaces in my project, I'm willing to deal with that solution. Currently, the only way I have to check an older API level is to set my project's settings to the given level, rebuild, see what breaks, and then refactor. It's quite a pain.
What I would really like is the ability to scan my code and check compatibility for a given API level without changing my global project build settings. Is there some easy way to do this?
Android API Analysis Plug-In for Eclipse:
http://adt-addons.googlecode.com/svn/trunk/apianalysis/
Ok, so based on my research and the comment by #CommonsWare, there's no static analysis tool or some other easy way to do this. Shucks.
I currently have an app on the market that supports Android 1.5 (SDK level 3) and up. It also takes advantage of several features that are only present in Android 2.0 (SDK level 5) and up. I do this using Reflection.
I read a post on the Android Developer Blog that talks about how to support these new features while using no Reflection, which would be amazing.
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
I have tested this out and while it works there is one huge downfall. Currently if I try to add a SDK level 5 class, but I don't know that it's a SDK level 5 class, there is no worries. Eclipse isnt going to find the class and I'm not going to be able to add it.
Using Google's recommended method does allow me to add the classes and gives me no notification that this code is targeted just to SDK level 5 users. This opens up too big of a possibility of adding in code that would break some users without knowing.
Does anyone know of any plugins, options, etc that would warn me at the places I have targeted SDK level 5 to keep this from happening?
One possible way, and I havent tested this, would be to individually change Android manifest file and set android:targetSdkVersion to each SDK and try to compile. That way you will be able to sequentially test out each SDK support.
I have purchased an HTC Incredible and have dived into the world of android! Only to find myself totally confused about the API levels and backward compatibility.
My device runs the 2.1 OS, but I know that most of the devices out there run 1.5 or 1.6; and soon the 2.2 OS will be running on new devices. The SDK has gone through such enormous changes, that even constants have been renamed (from VIEW_ACTION to ACTION_VIEW for example). Methods have been added and removed (onPause replacing the earlier call, etc al).
So, If I want to write an application that will work from 1.6+, does that mean I have to install and write my code using the 1.6 API; then test on later versions? Or can I write using the 2.1 SDK and just set the minSDK level and not use "new" features?
I have never worked with an SDK that changes SO drastically from release to release! So I am not sure what to do....
I read through an article on the Android Development site(and this posting on stack overflow that references it: Should a legacy Android application be rebuilt using SDK 2.1?), but it was still not very clear to me.
Any help would be appreciated
The SDK has gone through such enormous
changes, that even constants have been
renamed (from VIEW_ACTION to
ACTION_VIEW for example). Methods have
been added and removed (onPause
replacing the earlier call, etc al).
Those were two years ago, on a beta version of the platform, before there were any shipping devices. Since Android 1.0, there has been very little that breaks forward compatibility, mostly in the area of settings that were moved into a secure API so SDK applications cannot mess with them.
So, If I want to write an application
that will work from 1.6+, does that
mean I have to install and write my
code using the 1.6 API; then test on
later versions? Or can I write using
the 2.1 SDK and just set the minSDK
level and not use "new" features?
You make it seem like those are mutually exclusive. In fact, they are largely identical.
Keep your toolset on the latest version of the Android development tools
Put the minSdkVersion in your manifest to state what is the lowest API level you want to support
Put the targetSdkVersion in your manifest to state what your "target" API level is, so Android can apply some compatibility helpers if your app runs on a newer version of Android (typically, you "target" the then-current API level)
Write your code mostly to the API level you specified in minSdkVersion, optionally using reflection or conditional class loading to access newer APIs on devices that support them
Test on everything you can get your hands on, at least emulators for the different API levels
You can use the current SDK and set minSDK level to whatever level you want. If you do this then you cannot use any functionality that is not in the minSDK. It is also a good idea though to test it on all versions of the SDK with the emulator.
<uses-sdk minSDK="4" targetSDK="8"/>
That lets it know that you are targeting 2.2 but the minimum SDK level you want your app to run on is 1.6. By doing that you can use some of the new xml stuff in the newer versions like supports-screen and different drawables for different screens, etc.