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.
Related
I am building an app using Android Studio version 2.1.
I am testing it on a Lollipop device and a marshmallow one.
I was suggested to use support libraries, and I would like to make sure that it runs smoothly on Jelly Bean devices too.
I have looked it up, but can't quite understand if using v4 o v7 guarantees Jelly Bean compatibility (I am assuming it does, but not sure).
This is the first app I am developing and I just realised that I mistakenly used support versions in some activities, and native in others. I am fixing that.
Is there any tool which analyses all the code and then determines the earliest Android version that can run my app? Possibly giving suggestions on changes to make the compatibility broader?
All the answers I found so far confused me, they possibly require knowledge I don't yet have. I am a Java developer quickly trying to put together an app for a start up.
The minVersion in your manifest or gradle file determines the minimum SDK version that can use it. If you lower that number, any API call that doesn't exist on that version will cause an error or warning. Fix them.
BTW, KitKat is 19. So to have KitKat as the minimum SDK you don't need to use any support versions most likely. The best reason to do so is that it will provide a more consistent interface going forward- fewer version specific oddities when using support versions.
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 quite confused how application behaves when launched on different Android versions.
Let's say I'm compiling it using SDK level 4. Is it compiled in the code and when running it on phone with SDK 10 will still use the old SDK 4, or it will use SDK 10?
A simple example is Service's setForeground()-method, which was deprecated. If I run such code on phone with SDK 10, will the function have no effect or it will use the version from SDK 4?
The same goes for onStart() being deprecated. Is it going to be ignored on SDK 10 and it will try to call onStartCommand()?
I'd be thankful if somebody could explain me what's gonna happen here and why.
Is it compiled in the code and when running it on phone with SDK 10 will still use the old SDK 4, or it will use SDK 10?
SDK means Software Development Kit, thus devices do not run anything using the SDK. On the other hand, devices have different kind of OS which belongs to a specific API.
If you run a build compiled using SDK 4, and run it in a device which runs API 10, it will run it using the new API (that's called, backwards compatibility).
Usually, deprecated functions are supported on newer versions of the SDK. Most of them will work, but you must try to not use them. Of course, there are cases where you have no choice, for instance, when the method you are using is deprecated but there is no replacement in the old SDK that you are using.
Your service is just compiled bytecode - with own classes and references to other classes and methods. When it is deployed on newer android version, it (android, OS) will do whatever it sees fit - you have no influence there. As other java based systems, it will rely on proper class names / packages / interfaces, and try to resolve methods with certain signatures ( parameters and return values). If it behaves socially, it would first check if there is method from newer interface ( i.e. onStartCommand() ), and if it is available it will be called. Then it may (or not) fallback to older method. But usually you can rely that reverse compatibility is maintained pretty long time.
Most deprecated api calls on most phones will work...
However, some, like your given example of setForeground() have been removed due to the fact that developers have misused it (setting a service into the foreground without notifying users). So they WILL NOT work.
Unfortunately, there is no documentation to which ones are supported and which ones aren't so it's a trial and error thing...
Also, there are differences between different implementations (phone manufacturers / models) for some reason.
A good example is the old Contacts APi (pre V2.0) which works on some newer phones with Android 2.2/2.3 and doesn't work on others with the same OS versions...
The best bet would be NOT to use deprecated methods, and to adjust according to the current popularity of the Android OS version (currently 2.1, 2.2, 2.3.2, 2.3.3 are the popular versions: http://developer.android.com/resources/dashboard/platform-versions.html).
I currently have a application targeted at android 2.3 (api level 10), but went thinking that probably people using android 2.1/2.2 or older won't even be able to see the application in the market.
So I thought that using api level 3 would be the best to use, but I don't know if this will maybe make certain elements in my app work less good, and probably buggier, since it actually uses old android code. Is there a good way to find out which API level I should use, and also, how do I convert my application to that level?
You can find a breakdown of the different versions of Android in use here. Currently, if you target 2.1 (API 7) you'll only miss out on about 3% of the market. Targeting 2.2 will miss just under 20%, or a fifth of the market.
As for converting your app, you can check what API level things are available for in the Android Reference. You'll note a checkbox and dropdown menu on the top right of the browsing area that allows you to filter by API level - that's one way to help converting. The other is to set the target and minimum SDK versions which will help Eclipse know what to complain about in your code. The easiest way to see if something needs conversion, however, is to emulate and test.
EDIT: The API level dropdown moved from the top right to the top left, over the list of APIs.
This graph may help you make up your mind.
It is good to look at backward compatibility and in general, you should compile your application against the lowest possible version of the platform that your application can support.
You can determine the lowest possible platform version by compiling the application against successively lower build targets. After you determine the lowest version, you should create an AVD using the corresponding platform version (and API Level) and fully test your application. Make sure to declare a android:minSdkVersion attribute in the application's manifest and set its value to the API Level of the platform version. Good luck!
If you have
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="10"/>
then it will appear right down to 1.6, but make sure you don't use antyhing that they don't have in their API
edit: Don't bother with 3! :)
I started out developing for 1.5, but soon realized that only a small percentage of people still run 1.5. I generally develop at the 2.1 level, and leave it at that (unless you need features at a higher level). To change it, open your project properties, and while I don't have my environment open, there is an Android option where you will select what API level you want to target.
The Best API Level is contains follows
1) The best API covers 100% market but all are not prefect so our app should be covered at least 90% with all devices .
2)We have to care about backward compatibility issues and our code would adapt itself for upcoming versions.
3) Using the new Android SDK is a requirement to use any of the new APIs added in that level. It should be emphasized ... It is ultimately a business decision on whether supporting an additional 3% of devices is worth the development and testing .
4) check out this link https://developer.android.com/guide/practices/compatibility.html#defined
5) Finally choose the best API you will find best API
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.