For a report on Android fragmentation, I am researching about forward compatibility of the Android framework/SDK.
It is widely stated, that the Android SDK is forward compatible, meaning, that applications developed with one framework will run on devices, that are running a later one, i.e. on Forward or Backward Compatibility in Android?. When a feature or API is deprecated it is mostly stated on developer.android.com, that the feature will continue to work on devices, i.e. Google Maps Android v1.
Now, I experienced myself a case of incompatibility with Text-to-speech, when running a 2.2 application on to 4.1. This case is portrait here Text to Speech not working in Android 4.2 Jelly Bean. (Shortly, you are not supposed to check for the availability of TTS before using it anymore, because the existence of TTS on a device is mandatory from 4.1 onwards. And in fact, this check will falsely return false on 4.1, so your code that was written for on 2.x is not working properly on 4.1 onwards.)
Are there any other examples when an App or one of its functionalities stop working on a later version (apart from Apps developed for 1.x)? What are the specific deprecated features/APIs that make troubles on newer devices?
Related
So, I'm current trying to learn and become a programmer. I've recently worked with C# but I really want to get into mobile apps, since most small projects really tend to fit better as mobile apps, rather than desktop apps.
The easiest, for me, seems to be the Android platform, but I'm having a problem... I don't own an android phone, but I could possibly purchase an old model. Naturally these will have an older version of Android, so here is my question...
How compatible are these different versions? Like, are there major differences when moving from Icecream Sandwich to Jelly Bean, or from KitKat to Lollipop?
How do app developers deal with this array of Android versions?
When you develop an app for an old version of Android, it will run without errors on all newer version of Android, unless you do something involving low-level stuff like direct kernel calls, but you will never encounter such issues if you only use Java.
Worst issue you'll see is your app visual style looking outdated on newer devices.
If you target API level 23 / Android 6.0 Marshmallow, you will still need to run your app on Android 6.0 emulator, to be sure that it won't crash when using new Android permission dialogs to ask for SD card access etc.
I recently received an invite to use Inbox and it is using the new material design feature from 5.0. So this got me wondering if I can develop an app with the new SDK to enable BLE peripheral, but for a Jellybean or KitKat device. Does anyone know if this is possible?
Here is the list of updates: http://android-developers.blogspot.ca/2014/10/whats-new-in-android-50-lollipop.html
No.
There are support libraries released to help backport apps running on older versions of Android. Here's a list of all of the support libraries and what they allow you to do.
Perihiperal profile has only just been introduced, but hasn't made it's way in to the support libraries. My guess would be because it's rooted much further down in the OS and isn't something that an app can bring in. This suggests that it won't ever be possible (unless perhaps the user is running a custom ROM).
4.3+ already supports lots of Bluetooth LE features, it just doesn't support peripheral profiles. I have personally been waiting for this for a project of mine, so very excited that it's now available in Lollipop.
Hope that helps.
Should I use the latest 4.0 or 2.3? My phone has android 2.3.5 and it's a HTC Desire HD.
Does the runtime matter or will the applications work still?
First you should choose what device versions you'd like to target: http://developer.android.com/resources/dashboard/platform-versions.html
Based on those numbers it makes sense to currently support Android 2.1 and higher.
Also you should read about <uses-sdk> directive:
android:minSdkVersion and maxSdkVersion define the version range to which your app will be available. If device has Android version out of this range then app will not be visible for it.
targetSdkVersion is the vesrion that you are targeting and that you actually tested against. This attribute triggers Android's compatibility behavior: for instance targeting 2.3 will not show the new look on 4.0 devices.
I think this url will be helpful :
http://developer.android.com/resources/dashboard/platform-versions.html
All versions of android are backward compatible which means that an application designed to work with 2.0's api will work on 4.0 so it basically comes down to whats your target customers. there's still a vast majority that uses 2.x (unfortunately) so it is probably smart to develop for 2.1 and up..
but anyway this is a pretty common question and i'm sure google will produce a lot of useful information in the subject.
I'm starting to broad my developer skills also to the Android development.
I installed all the tools and configurations and every thing seem great, As a default settings I install the 3.2 SDK, but there is not too much docs on that one, mode of what is out there is on the 2.x SDKs.
Is it like IOS, does android have a good backward computability? Can I stay with the 3.x and count on it (with the features that are in the 2.x SDKs) to work on 2.x phones? What are the common version in the Android devices this days? I have lots of newbie develop questions like that, as i want to start from a good starting point and there are lots of materials and tutorials over the web that are not up to date.
Also, does any one know about a good site for this kind of Q&A?
Thank you,
Erez
As of July 5th the version with the largest market share (59.4%) is 2.2 (API Level 8) as shown here
http://developer.android.com/resources/dashboard/platform-versions.html so Consequently I would recommend using that as a starting point unless you are solely focusing on the new honeycomb tablets (<1% market share).
As for backward compatibility, android is completely backward compatible for the most part. Unless of course you use a new feature that is only available starting with a certain API level. Google's Android market is good about only allowing apps that will run on a certain API being visible to that phones user. This is enforced by the API level as recorded in the manifest file that is created with every Android app and set by the developer.
To help you with the API level, the SDK docs show what API a feature/object started with in the upper left hand corner. You can also view the specific changes in each platform and it's corresponding API level at http://developer.android.com/sdk/index.html.
As for a good website to get started I would recommend the developer site at developer.android.com and this website of course. Also the book Android Wireless Application Development by Shane Conder and Lauren Darcey (2 ed) Is very good. (I am not connected with the book just currently reading it). Make sure you get the latest edition.
Hope this helps,
George
Above is good info, but it would be advisable to develop for 2.1 and up at the moment, considering as of this answer's writing, 2.1 makes up 17.5% of the market and 2.2 makes up 59.4% of the market.
http://developer.android.com/resources/dashboard/platform-versions.html
OP should also be advised that version 3.x is specifically for tablets, so that may not be the best choice for a starting developer. My advice is to go with 2.1. Most of the documentation is up to date with that, and you won't have access to things you don't need yet (fragments, tablet-specific things)
Hope this helps!
You can read about application forward and backward compatibility in the docs.
Generally apps are forwards compatible but not backward compatible - new APIs introduced in one version are not available in an older version.
This pie chart shows distribution of devices accessing the Android Market and based on this I would try to target devices using 2.1 or newer to cover most of your users.
Your decision should be based on whether you need a feature introduced in a specific version. For example, if you want to add NFC to your app, you'll need Android 2.3.3 or newer, but otherwise there's no reason to exclude older devices.
I recommend learning about Fragments and using the compatibility package to use them on targets below 3.0. This will make it easier to reuse view elements on both tablet and phone devices. Note that if you only intend to develop for phones, 2.3.4 is the latest phone version of Android at the time of writing. Later this year, 3.0 for tablets will merge with the phone version to provide a unified OS version as with iOS.
Android 3.2 is just released publicly on friday, July 15th. You can start-off with Android 2.3.3 and 3.2 installation and development.
Android applications are mostly forward compatible. (But not always)
The best place to find all your answers is developer.android.com
For testing purposes I need to buy an android device. Can I get a tablet device with android 3.1 honeycomb and use this to test apps developed on older android versions? Are new android versions backward compatible with older apps?
Not entirely. In many cases yes, but there are exceptions:
There have been some api changes, and more importantly, there are a lot of apps out there which did things that weren't entirely proper, but worked on the devices they were developed for.
Some older apps were written to use input devices not present on recent phones or tablets - hardware trackballs or dpads, buttons, etc.
Also no small number of older apps will display in a phone-sized area leaving the rest of the tablet screen blank.
Unfortunately, the flip side of the vendor customizability of android is that if you really want to do comprehensive testing you need access to a variety of devices, even for a single api version.
Can I get a tablet device with android 3.1 honeycomb and use this to test apps developed on older android versions?
Yes.
Are new android verions backward compatible with older apps?
Yes.
Back version is compatible with android 3.1 but only simple application means without any animation (Like Games) and some special features etc.