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).
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.
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.
Even that this is a general question, I'll ask it with an example that it would be easier to understand.
Scenarios:
I'm using support library 7 and using the action bar feature. A user is installing the app on a device with Android 2.2 (API 8).
I'm using support library 7 and using the action bar feature. A user is installing the app on a device with Android 4.3 (API 18).
It is obvious that at run time scenario 1 would run the code of the supported library. But what will happen on scenario 2? Would it run the OS code or the support library code.
I really hope that it runs the OS code.
EDIT
I know that the way Java work is that methods are resolved by their fully qualified name determined at build time (as #adelphus wrote). And therefore the Support library code will run. But if I was the one that implementing the support library, I would have been doing the following:
Check the version of the OS on run time
In case that the OS has the current object/method I would call to the OS implementation (Actually in this case the support library is only a wrapper for the OS functionality).
In case that this is an old OS, I would have implementing the behavior myself
So, does it act on newer version as a wrapper, or on both cases it using the internal implementation?
Thanks
It will run the support library.
The way Java (and therefore Android Apps) work is that methods are resolved by their fully qualified name determined at build time. Since you would have built the App against the support library, that is what will be called, regardless of the version of Android it is executing on.
In reality, it should make no difference to the end user. The point of the support libraries is to provide the same behavior for older versions of Android which don't have the functionality of the new versions. Why would you care whether it is calling the support library or not if the end result is the same?
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 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.