My Android app has a android:minSdkVersion="8" which I want to keep, but at the same time, for users running Android 3.0 and above, I want to create a widget backed up by a collection.
Following the steps here http://developer.android.com/guide/topics/appwidgets/index.html#collections
I run into a compilation error, because I need to use classes from API level 11 (RemoteViewsService).
So is there a way to do this? To keep the app available for people with Android 2.2+ but in it build a widget for people with Android 3.0+? It should be possible.
GMail does it, it's available for earlier versions of Android but also provides this kind of widgets for Android 3.0+ users.
Thanks
I think perhaps the following answer on SO can provide some insight:
Android Min SDK Version vs. Target SDK Version
In essence, you have two variables you can define: Min SDK and Target SDK. The above link will explain in great clarity how to use them.
Related
Im not strong developer in android development.
So.. Old application uses HERE SDK for Android (Starter Edition) 3.12
But it doesnt work with android 10+ (because of scoped storage)
How to upgrade version to 3.13 ?
The Starter Edition is no longer maintained. Using this legacy edition is not future proof. In the long run, consider to move to the HERE SDK for Android (Explore Edition). Even if your project contains a lot of code, this not so difficult to do as it sounds. Here is a link to a migration guide that may be of some help.
Scroll to the end of this guide and look for the example app tables, they contain links to old code versus new code.
First time developing for Android.
I've noticed that the latest SDK is v4.x but I've noticed informally that most people are running v2.3
If I develop an app using the 4.x SDK. will it refuse to run on 2.3 phones? Or will certain features be disabled?
Should I develop using the 2.3 SDK instead?
Before answering the question, something should be cleared up: There's a difference between the version of Android (2.3, 4.x, etc) and the version of the API it runs on (which is ALWAYS an integer: 10,11,12, etc). The relationship between Android platforms and their respective API versions can be found on this page. By way of example, Android 2.3 uses API 10, and Android 4.0 uses API 15.
Furthermore, there's only one SDK, which has downloadable modules for coding against various versions of the API. So it's not that you're using v4.x of the SDK, it's that you're using the SDK, period, and coding against version 15 of the API :).
That said: The best thing to do is set minSdkVersion to the minimum version of Android your application will run on, and set targetSdkVersion to the most current version of Android. Then you can use Build.VERSION_CODES to check for new versions of the platform at runtime, and activate new platform features as necessary. A good tutorial on how to do this is on the Android Developer blog, titled How to have your cupcake, and eat it too.
I would even recommend targeting 2.2 as I still have a large number of users (16%) running Android 2.2. Here is a break down of on one of my apps that shows what version users are currently running. (See attached picture). Like J. Maes said the lower you can build it the more users you can capture. Although there are trade-offs that you will have to make by using an older SDK. For most purposes I haven't had much of an issue targeting 2.2. It allows me access to a larger customer base.
You should use the lowest version that supports all the features you want to use in your app. If you think a 4.x feature is absolutely necessary in you app, then you should use it. If not, use 2.3, so more people can run it as Android is backwards compatible.
I see a whole bunch of platforms / SDKs, everything from 1.x to 4.x.
Does this mean I have to build my app separately for all different versions?
My goal is to wrap my HTML5 web app and make it available as a native app in app stores.
You typically build against the latest SDK that you plan to support and test against. This usually means "the current SDK" and is represented in the manifest as "targetSDKVersion". Another value called "minSDKVersion" that indicates how far back you support in terms of the API level. Google maintains the API consistency across past versions of the SDK, so it's usually in your best interest to test against what is current.
However, in newer SDKs, there may be things that cause your app to look or behave differently, so when you update the SDK, tools, and targetSDKVersion, you may have work to do to keep your app looking like it belongs.
Usually you can write an application targeting android 1.6 and deploy it to every device which supports a higher API level. You can compile an application which targets android 4.0 and it will still run on 1.6 as long as you're writing code which doesn't depend on API which isn't present in 1.6.
Since there are a lot of changes since 1.6 there is a compatibility library which you can use. This library doesn't include the actionbar. Therefore you could use Actionbar Sherlock.
With these two libraries you should be able to write applications for 1.6 without having the pain to pass on new techniques.
If you still depend on leatest API features, you could request the API level on runtime and implement features for new devices only. You should avoid to ever use this API on old devices. You can compile it but it would crash on runtime if you do.
I plan on creating an application for users to view their stats of a game I am currently in the process of making but my question is like the title. I am not sure if phones with Android 3.0, Android 2.0 or lower can use the apps? If not, how would I work around this? Would I just not be able to use the new API features such as NFC etc? All in all, if I start developing with Android 4.0 SDK, will all android phones be able to use my app?
My understanding of android development, is that you can build against a lowest common denominator if you build a single package, and it will run on that version, and most likely any newer version. But not the other way around.
The compatibility library (which we're now just calling the support library) doesn't use any special magic to pull this off. You can check Build.VERSION.SDK_INT at runtime and use classloader guarantees to access newer functionality when it's available. Some examples are here: http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
We recommend taking a graduated approach to supporting different platform versions. Provide a simpler version of your UI on older versions and layer features on top as they become available. The link above gives some examples of how to do this, and we're going to continue expanding the support library with more *Compat classes that do the version checking for you when using newer features that may or may not be available on all devices you want to support.
Chris is right. However this can be limiting. What if you want to be flexible and use features of the 3.0 and 4.0 android in you app if the device you're running on has them and then gracefully fallback if they don't? Enter the android compatibility package. You can do development using really old api's (all the way back to 1.6) and still have access to new api features.
I would like to know whether the Android provides any sort of compatibility i.e either forward or backward. It means as in Blackberry if develop an Application with JDE 4.2 then that application will work on any handset with OS 4.2 or higher which means it has forward compatibility. Is there anything similar in Android?
Suppose I develop application with Android SDK 1.5 then will that application work on any handset having OS 1.5 or higher.
Hope to get a reply soon.
Thanks & Regards
Sunil
Forward compat is somewhat assured on major versions. On Android you target a minimum api spec. As long as your are not calling private APIs, Google keeps compatibility going forward on devices that join in on their Open Mobile Alliance.
It doesn't mean someone can't get the Android source and release an Android based OS of their own that breaks all compatibility. These devices wouldn't get Google's Market Place because only licensed devices that Google tests get to use that. If that is where you are releasing, you probably won't have any trouble.
Because the Android documentation is licensed under the Apache license, I'm comfortable quoting a large section:
Android applications are generally forward-compatible with new
versions of the Android platform.
Because almost all changes to the framework API are additive, an
Android application developed using any given version of the API (as
specified by its API Level) is forward-compatible with later versions
of the Android platform and higher API levels. The application should
be able to run on all later versions of the Android platform, except
in isolated cases where the application uses a part of the API that is
later removed for some reason.
Forward compatibility is important because many Android-powered
devices receive over-the-air (OTA) system updates. The user may
install your application and use it successfully, then later receive
an OTA update to a new version of the Android platform. Once the
update is installed, your application will run in a new run-time
version of the environment, but one that has the API and system
capabilities that your application depends on.
...
Android applications are not necessarily backward compatible with
versions of the Android platform older than the version against which
they were compiled.
Each new version of the Android platform can include new framework
APIs, such as those that give applications access to new platform
capabilities or replace existing API parts.
-- From: http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
Though they are forward compatible, Android apps will not be able to use features of the SDK that were introduced after they were written, not surprisingly.
That's not what "forwards compatibility" means. You are thinking of "backwards compatibility". "Backwards compatibility" means that new versions of the platform (i.e. Android) will still run old software developed against an older version of the platform. "Forwards compatibility" is the precise converse -- older software developed against an older version of the platform will still be able to leverage new features of the new platform.
An example of backwards compatibility is that they rename one of the methods in ICS but still implement a deprecated version of the old method and have it forward to the new implementation.
While backwards compatibility is almost always guaranteed, forwards compatibility is only guaranteed in certain scenarios. An example of forward compatibility would be a situatation where they implement a new feature in the OS (for example, "pinch to zoom") and applications written before that feature existed are still able to enjoy this feature.
I think Android System is backward-compatible, and that ensures the forward compatibility of Android application.