Is Android API 2.2.1 too obsolete to use? - java

What Android API version would you choose to begin developing a new Java application?
Recently I got a used smartphone running Android 2.2.1. Since I never experimentend with mobile development, I decided to use it as an occasion to try to develop a new app for Android.
I worked in Java from some year, and I feel comfortable with it, so since I already work as an independent software vendor I’ll try to sell the app on the Android market if I will be able to do a good one.
I don’t want to start developing with an outdated version of the API, so a I’m asking if starting my development and learning efforts using level 8 of the Android level API is the better choose to take, or if it would be better to use a newer version of the API.
I read why is Android API level 9 obsolete? and Which Android API to use? on S.O. about the same argument, but both the questions are pretty outdated now, and I think they left some question opened.
In particular, Jan Dragsbaek said in his answer:
You should always go for the lowest possible API to use. Simply
because the lower your API level is, the more users can you reach.
So looking at the current stats, you are able to reach 97.9% if you “dumb” yourself down to API level 7.
But why API level 9 is obsolete? One could not know for sure, but most likely because it had some major flaws.
Reading actual stats, this is the situation:
Platform Codename API-Lvl Distribution
Android 1.5 Cupcake 3 30,00%
Android 1.6 Donut 4 70,00%
Android 2.1 Eclair 7 550,00%
Android 2.2 Froyo 8 20,90%
Android 2.3 Gingerbread 9 0,50%
Android 2.3.2 -
Android 2.3.3 - 10 63,90%
Android 2.3.7 -
Android 3.0 Honeycomb 11 0,10%
Android 3.1 - 12 1%
Android 3.2 - 13 2,20%
Android 4.0 - Ice Cream Sandwich 14 0,50%
Android 4.0.2 -
Android 4.0.3 - 15 4,40%
Android 4.0.4
Total for Android 2.2 93,50%
Now the question is: What will I lose if I develop with level 8 of API in terms of features? And what do I gain in terms of stability or tool support?
EDIT:
I finally choose to use level 7 of the API, which offer me the features I really need to get started to experiment on my new phone. Eventually, when I think that app need some feature not available with the current level, then I will port the app to a next level of the API.
For now, I will try to follow Building a Custom Fancy ListView in Android and see if I'm missing something really useful from the beginning.

I think that you should look at your requirements too. Draw up the API's which is absolutely necessary for your app and narrow down to the minimum Android API level which you can use. Since it is correct that your outreach will be more if you make use of lower API levels.
Having said that, if you still feel uncomfortable with lower API level and find yourself restricted then you can infact use Android Support Libraries. Quoting from the description of the support library:
The Support Package includes static "support libraries" that you can add to your Android application in order to use APIs that are either not available for older platform versions or that offer "utility" APIs that aren't a part of the framework APIs. The goal is to simplify your development by offering more APIs that you can bundle with your application so you can worry less about platform versions.

Level 9 is obsolete because level 10 replaced it completely. Another way of saying that is that is Android 2.3.3 replaced Android 2.3, so now if you're aiming for 2.3 devices, you use the 2.3.3 API. Level 8 is not obsolete because there is not a similar API level to replace it (all the 2.2 updates were still level 8).
As for features lost, you can look at the list of all the new features in API 9 (API 10 doesn't really have any major new features but you can check it too on the same site). If you don't need any of those features, then no need to aim for 2.3.3. Same thing over again between 2.2 and 2.1; go with the lowest level that has the features you want, as you said. Speaking from experience, 2.1 provides everything you should need for regular use - internet, storage, graphics (although the advanced graphics get better as you go on), UI, etc.

You will neither gain nor loose nothing much.
Level 9 is obsolete as compared with level 10. Level 9 is GINGERBREAD and Level 10 is Gingerbread Maintenance Release 1 i.e. bug fixes.
Level 8 is 2.2 level 7 is 2.1 they are not obsolete, just old.

Related

Develop Android application for minimum Version 2

I have developed android application keeping minimum api level 8 and maximum 17. Used Api 14 compilation unit.When I run it on android phone the application crashes.I wan to create application for Android 2.0 -3.0 version i.e the application should be compatible on 2.0 version also. Kindly suggest how can i achieve this?
Because you compile against level 14 API, you might use methods or classes that are not available on API level 8, which will cause runtime errors on level 8 devices.
I suggest you compile your app against the API Level 8 SDK.
Android Lint tool in Eclipse can also find usages of methods that are not available on your app's minimum API level, but I'm not sure how much reliable its results are (It might not find all of the unavailable classes/methods).

Recommended Android API levels

I am learning the Android SDK and I am getting to the point of getting a bit more comfortable to start doing actual app development. I have done some reading here and there online, and based on my limited understanding, I as a developer, should include the Android API levels that I intend to make the app available to. My question is related to this...
Based on some charts online, it seems to make the most sense to support devices from 2.3 (Gingerbread) all the way to the current KitKat API. So that would mean API level 10 - current.
Question 1 Do I have to download all the API levels in between (i.e. 3.0, 4.0, 4.1, etc...)or is the lowest and highest be enough?
Question 2 If I do not end up downloading those API levels in between? What would a user running, say 4.0), experience? Would they be totally unable to run the app? Or would it simply mean that I, as a developer, would not be able to use any of the APIs states in those levels?
I understand that there might be some compatibility issues, from changes in the API which I would need to work out myself.
Thanks you for your clarification.
Answer to Question 1
You can develop your application using any API version. In Android Manifest.XML file, you specify the Minimum SDK version that your application supports. Based on that value, your application works in all API ranging from the min value to the current Value.
Please note that you can specify the MAX SDK value supported but this is not recommended.
Answer to Question 2
Once you develop an application, it is good if you test it on various API versions. If you download different platform versions, then you will be able to create different emulators and test your application. But your application will work successfully even if you install only latest version.
Also, as a developer, from the application code, you can make your application utilize certain libraries supported in higher version and do not use those SDK if the application is running in low API devices. You can do this through code.
Similarly, compatibility issues can also be addressed in code.
You just have to download the latest API. You can define in your app what the minimum Android version can run it (you should start low but as you add more and more features you're going to learn that you might have to increase it) and anything between the version you define and what the current highest version is (19, at the moment) can run it. They all might have slightly different experiences, but it'll all be similar in general (like, I have an ActionBar in my app and it looks pretty different between JellyBean and Gingerbread, but it's there nonetheless).
The main thing is that for backwards compatibility there are support libraries that you'll have to download and include in your app which aren't there by default (android-support-v4.jar for example).
A big tool you can use if you want to include certain features on higher API devices is check to see the current API of the device) and then implement accordingly. The most important thing is testing on different level APIs to make sure your app works on all of them.
You can configured minimum and Maximum API level in Manifest file.So that you can covered maximum device.Please put following code in your manifest file,
<uses-sdk
android:minSdkVersion="15"
android:targetSdkVersion="17" />
Thus your application can run on device having API level between 15 to 17.

Which versions of Android SDK support coding in which versions of Java?

I was writing an Android app for Android SDK 2.3.3 but then I was asked to test it on a device running Android 2.2.1. So I set my target to 8 instead of 10. But then java.util.concurrent.TimeUnit only had the Java 1.5 feature set instead of the Java 1.6/1.7 feature set of java.util.concurrent.TimeUnit. So I put the openjdk 6 implementation of TimeUnit into my package for my Android app and everything works fine.
Does anyone know where I can get some documentation that gives me a chart that tells me, for example, that when using the official SDK, Android 2.2 has to be coded using Java 1.5 keywords/syntax/APIs, Android 2.3.3 can be coded using Java 1.6 keywords/syntax/APIs, etc...?
You are trying to look at Android as a subset of Java which it is not. They are completely separated. Even though Android comes from Java, it as departed from it quite a bit and there is no correlation 'version-wise' anymore between the two.
What you can look at is the Android documentation. For every instruction/command/method/properties, at the top right you'll find the api level at which you are able to access said property.
Clicking on the api level will take you to a page which contains a table that translates api level to Android versions.
The easy way to find out if you are allowed to use a property is using eclipse and doing what you just did : Change the target api level. Then any call to methods or properties that are not available to you will produce fatal errors.

Why UsbAccessory class is added in API Level 12 not from API level 8?

I think most of the world today uses API level 8 and most of the programmers Developes application for API level 8, then why USB functionality not given here is it something special about this?
The problem is that the USB functionality relies on software that is installed on the phones.
This means if a phone is only running Froyo (Api Level 8) all the base classes and the usb stuff like drivers etc. is not installed on the phone.
Therefore it can not be used by apps. The users of this phones have to wait for their manufacturers to get an update ready that includes all the USB related stuff and all the other new things that are build in Honeycomb/Ice Cream Sandwich and release it to the devices.
You'd have to ask Google Android developers why that is so, but it is probably that the functionality wasn't developed at the time API level 8 was frozen. Something as complex as Android takes a lot of people a lot of time to develop. It can't be done in one go.
But at the end of the day, "why" is not really a question whose answer will help you develop Android apps.

Which are the most important features I will miss targeting Android API 3 (OS 1.5) instead of most recent API?

I'm beginning with Android development. I'm aware that there is a lot of Android devices still on OS 1.5 or 1.6 so I'm thinking about require API level 3 as minimum to support them.
What will I miss from 2.2?
You can make your app backward compatible. You will have to specify the target SDK as 2.2 and the min SDK as 1.5
There are a few strategies to use when you are making a backward compatible application. The thing you need to avoid is using functionality from a higher SDK (APIs etc) when your application is running on a phone that supports a lower SDK. Read http://developer.android.com/resources/articles/backward-compatibility.html for more information.
Another good read on how lazy loading of classes can be used for backward compatibility - http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
The thing I miss the most when I target Android 1.5 is a usable RelativeLayout. 1.5's implementation of RelativeLayout is famously buggy and often requires you to use all sorts of awkward workarounds and extra view nesting that can be avoided on Android 1.6+. For instance, the layout_center* properties rarely work properly on 1.5, and they're one of the most useful features of RelativeLayout.
Add to this list lack of "onClick" attribute in 1.5 layouts schema

Categories