My app needs Renderscript since it performs some image processing that would take several seconds in Java. Before publishing I have tested it on a number of devices, even some older models (e.g. Samsung Galaxy Tab 2, API 17), and the app worked quite well, even on these devices. From this, I didn't see a reason to set the minimum API higher than 17. Now, some weeks after publishing on Google Play I see that the app crashes on certain devices such as Galaxy S3 (m0) with API 17 or Galaxy S3 Mini Value Edition (goldenvess3g) with API 18.
android.support.v8.renderscript.s: Error loading RS jni library: java.lang.UnsatisfiedLinkError: unknown failure
As such that is not surprising, since I knew about certain processor types that do not support Renderscript or other device specific issues that can cause problems. Questions:
Is there a (approximative) way to find out, which of the 6'811 Android devices with API >= 17 do NOT support Renderscript? For example based on the terms in brackets (m0, goldenvess3g) which are possibly related to processor types? If so, I could exclude these devices on Google Play.
If there is no such possibility, would you recommend to set minimum API higher, e.g. API 19? Sounds naive, but I didn't find consistent info on this.
Thanks a lot for your feedback.
According to android.renderscript documentation, it is available since API level 11. Since your min API level is 17, I would recommend to use it instead of android.support.v8.renderscript.
Support library APIs are meant to be used if one is targeting devices running lower versions of Android, which, apparently, is not the case for you.
Related
I am new to Android development and had a question on what should be the minimum Android version to pick for an app (phones only, not tablet) that is intended for the USA market.
I have been looking at this (https://developer.android.com/about/dashboards/index.html) and thinking may be API 10(Gingerbread) is the way to go. However some folks have suggested that I can safely pick API 15(Ice Cream Sandwich) and I should be fine.
What are other app developers doing?
Android Studio has it defaulted to ICS (API 15), which will get you 100% of tablets.
This table shows that API 15 would get you 85.8% of all Android Devices currently being used.
The problem is that some of the APIs use methods that are preferred over the older APIs and you will run into a lot of times where you need to handle one way for an older API level, and a second way for a newer API. So you have a lot of potential for if < API 16 do x, else do y.
So you need to weigh the maintenance cost vs what percent of the market you want to capture. Personally, I chose API 16 because the 11% of tablets created more work to maintain API 15 then benefit of having that user base.
I am starting to learn android development. I downloaded adt-bundle-windows-x86 from the android site. Now when I open the SDK manager that comes with the bundle it enlists a number of API levels. My phone has ICS. But when I saw wiki for the same it seems we can have more than one API levels for a single code name.
Which one is to be used? I want backward compatibility and also not miss on the new features that might have been introduced in ICS. what do these API levels mean and how do I decide which one to use?
Here is a link to the list of Platform Version - API Level - VERSION_CODE - Notes
This link shows data about the relative number of devices running a given version of the Android platform.
I recommend:
minimum sdk version = Android 2.3.3 - Gingerbread - Api level 10
target sdk version = Android 4.3 - JellyBean - Api level 18
NOTE the target sdk version most of the time should be the latest release which at current is JellyBean
Here you can find a list of api levels, code names and usage statistics.-
http://developer.android.com/about/dashboards/index.html
You should try making your application compatible with as much devices as possible, so I'd recommend to make sure that works fine at least on Android 2.3.3 - Gingearbread - Api level 10
Regarding new features, sadly, keeping in mind old devices sometimes means forgetting about some new cool features or apis which are included to make our lives much easier.
I think this can help you a lotclick
You should set api level as minimum as possible like 2.3.3 gingerbread. 35% of android devices still runs on Gingerbread. But as per your question it seems like you wanted to start development from 4.0.4 ICS. So set your min SDK 14. And as far as new graphical or library changes google provides support library for use.
One suggestion set max api level as high as possible. I mean 4.3 for now. hope this would help
Currently, I tend to target all my app development to API 8, so that I can hit the largest number of devices 'out there', basically from Android 2.2 upwards.
Do any experienced Android developers reading this have a perspective on what features, as a developer am I 'missing out' on, and more importantly, what are my users missing out on? In this day and age, what API is the 'best' one for my apps to target? Or is there no such thing, and each app should be targeted for a given API on its merits?
I'm not looking for pointers such as read the android developer docs (I have, or at least what I consider the salient parts), I'm more interested in the views of experienced developers as to how they decide which API to target.
Thanks.
if you set your target and minSdkVersion to 7 and use support (compatibility) library v4, then your app will support nearly 95% of all android phones, and still you are able to use modern features of newer APIs (by using support library).
I usually target the minimum API required by the apps functionality. If there is a minor feature needing a higher API, I make it optional instead of increasing the minimum for the whole app. In addition to using ActionBarSherlock and the compatibility libraries, I occasionally back port a few things from later APIs to keep the current basis.
While I decide the minimum on a per app basis, most of my apps target 2.1, as they were written almost one and a half years ago. Now days, I have new apps target 2.2, though I plan to change it to 2.3 very soon.
I guess my point is that there is no defined minimum API target. You should choose the one which offers maximum user reach, along with as much major functionality as possible. UI elements like the action bar and ViewPager can be used via libraries, and the ones not available in libraries can sometimes be back ported. However, it is usually not worth it to sacrifice users running a lower API version just for a better UI.
I am using a textbook which uses android V2.0. Can you tell me which version of android can run apps for version 2.0 without any problems ?
If you are going for just running the app, then any device with API level 5 (Android 2.0) and up (that includes Jelly Bean and any future versions) will be able to run your app without any problems. The developer docs have an API level guide here.
However, you should familiarize yourself with subsequent versions of Android so that you can make an informed decision on what version you should use, and what features you will be unable to use.
For example, you can see on the Supporting Multiple Screen Sizes page that Android 3.2 (API level 13) introduced new features for supporting multiple screen sizes. If you use API level 5, your application may not scale correctly on some devices (namely tablets).
Though it is tempting to try to support as many devices as possible, there is a definite trade off involved with using a lower API level. For some apps, it doesn't really matter if it scales correctly, but it is something that you need to take into consideration when choosing a target or minimum API level.
When developing an Android app, let's say I want it to be compatible with 1.6 (API Level 4) devices, but still enabling 2.2 (API Level 8) features such as adding android:installLocation to enable moving app to SD card. Therefore I set Eclipse to compile against 2.2 SDK instead of 1.6 SDK.
Adding unknown attribute like android:installLocation doesn't crash the app when running in 1.6 device, but in case when coding I call some API that is unavailable in 1.6, such as android.util.Pair or Base64, the app will crash when running in 1.6.
Is it possible (e.g. via an Eclipse plugin) in build-time (not in run-time!) to check whether the project is still compatible with 1.6, in other words, check whether there is any API calls to any of the methods/classes requiring more than 1.6 (API Level 4)?
The best way to check if your app uses a non-existing API on older handsets is to change the target to the old version (starting from the minimal one you support) and seeing if you have any compilation errors... This will point you to non-compatible API calls.
At least that's the way I do it.
This is a tough problem to handle gracefully in code. I asked a very similar question here.
It seems to me that you may be asking the wrong question. Checking for calls to new API features is reasonable, but if you want to make your app work well over multiple versions, you will have to have code that makes calls to old and new API levels as appropriate. There are many ways to do this and it's considered a best practice.
In that case, you may want to downgrade your target version and check that all the errors that come up in Eclipse are handled well in your code (and of course try it in the right emulator versions).
I know this question is ancient, but there is a "holy grail" solution to this issue (at least from your users' point of view):
You can publish two versions of your app, one requiring API level 8 and another requiring API level 4. Then, use versionCode 100, 101, 102, 103, ... for your level 4 version and versionCode 200, 201, 202, 203, ... for your level 8 version.
That way, if a user has API level 8 available, they get offered only the level 8 version of your app as it has the higher versionCode. And users that only have API level 4 through 7 available, get offered only the other version as the other one is incompatible.
It's a little bit more of a pain to maintain, but it has the (potentially huge) advantage that you can customize the reduced-features version to still provide a complete experience (no grayed-out buttons, etc.), and you can even keep the APK size smaller for that version as you don't even need to ship the code or related resources for the unavailable features.
You can find more details in Android's Multiple APK Support documentation.