Android dashboards show that only half of devices have Android 5.0 and above, but numbers look different for our customer data set - it's over 93% of our users. So we've decided to abandon support for devices with Android version lower than 5.0 and change minSdkVersion from 15 to 21.
This upgrade require from us to review all of obsolete functionalities and clean some hacky workarounds which we applied to support older versions. One of main functionality which we can apply now is to replace android.support.v4.app.Fragment with android.app.Fragment. It sounds like good idea, especially when we know that fragment API had been reviewed and improved.
Just to make sure that I’ll take right path and android.app.fragment won’t surprise me I would like to paraphrase question from this stackoverflow thread - Are you using fragments from the support library, even though they are already available, when developing for Android 5? Are there any bugs in fragment API which occur on Android 5.0 and above and were fixed in support library?
Update
After Android-KTX release, Jake Wharton made the following statement in one of PRs:
Thanks for taking the time to make the PR (with tests!), but we would like to encourage that developers only use the support library fragments. The next version of Android will deprecate the version of fragments that are part of the platform. Thus, we aren't going to add any extensions to support them in this project.
So using fragment from support library is the right thing to do.
I would suggest using the support library fragments anyway, for a few reasons:
Future features may be added and backported, and then you'd need to rewrite to use them
Consistency. The support library works to make sure support fragments always work the same. Whereas the native fragments may have subtle differences between versions.
The support library can contain bug fixes to the platform and can be updated much more frequently.
Edit: As of 2018, the OS level Fragment is deprecated. Google's path forward technically is to do less in the OS library and more in add ons. So for Fragment this is absolutely now support library, and likely to go this way for more items.
We started a fresh Android app few months back and we were wondering the same thing.
IMO, you should always try to use android.app.Fragment if it is possible. This way, you are certain that Android developers optimize, update and support this API and they will give you a quality product.
Right now, we are using android.support.v4.view.ViewPager and other similar components that provide different functionality in Support library than in the normal API.
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.
For some reason the original Aviary framework has stopped working and this has forced me to migrate our code to use the new CreativeSDK instead.
Unfortunately this new SDK has a minSdkVersion of 14 = Android 4.0, but a lot of our customers still use older versions (a little over 20 % according to Googles statistics for our app).
We cannot release an app update that cuts away that many users, but is there a way to compile the app with a lower api level and then just disable the image editing for the "old api" users?
is there a way to compile the app with a lower api level and then just disable the image editing for the "old api" users?
Tricky question. You can try build the app with api lv < 14 but then the creativeSDK will not be able to compile, resulting in a build error, so no.
Android 4.0 is already ~4 years old. It happens more and more that libraries drop support for older android versions (for good reason I think. Just update already!), as is the case with the creativeSDK. The minSDK requirement went from 2.3 in the aviary framework to 4.0 in the creativeSDK.
Adobe has to have done this for a reason. It is too much of a hassle to provide compatibility for 'old' versions of android, especially for complex functionality.
It is mentioned here, here and here that the creativeSDK now really requires api 14, and compatibility for older versions is not mentioned anywhere, meaning it very much likely doesn't exist.
To come back to your question, I think what would be a solution for you is to create multiple APKs for different API levels. There is some work to be done, but it is officially supported by Android, and the steps on how to achieve it are described clearly in the documentation I linked to.
Other than that, you have two options:
Drop the SDK and use another library.
Contact support and ask if they had forseen this issue and how they suggest you go about solving it.
As noted by Tim, the Adobe Creative SDK supports Android API 14 and up. It won't work for anything lower than that.
If you're using the Image Editor UI component, it's also worth noting that for APIs 14 and 15, the AviaryIntent.Builder will not work.
There is a workaround for that issue documented here.
Update: Note that starting in version 0.9.7 of the Creative SDK, the Image Editor supports Android API 16 and up only. This is noted in the Getting Started guide.
As far as I know, support library is using because old devices don't have new APIs. For example they don't know what Fragment is and how to implement it. Therefore, these behaviors are defined in support library.
So, my main question is, what is/are difference(s) between library of Fragment in support library with its twin which is introduced in API 11 (Android v3.0, Honeycomb).
My second question is, If its possible to put every new API in support library, why we have two types of libraries? I mean Android can release all APIs just under support library rather than support library and Android version X.xx library.
As far as I understood, support libraries may work as alternative of built-in APIs, but they are not supposed to be, because they directly effect the size of the application.
For example, a support library is of 2MB, and to use its functionality, it takes all classes, resources, etc (of 2MB), so now classes.dex (Dalvik executable file of all classes being used in application) of my application also include that support library classes, and same for resources. So, if without support library my app size was 1MB, then now with support library the size is 2MB extra, which means 3MB total.
Now, suppose this support library feature is so common that on single device, if I have 10 apps, then at least 9 are using this same support library, so 9*2 = 18MB on my device is being used by the same support library, which is repeated in every application, which is bad, because for now 18MB might not be so much, but the space required can increase, if you have more applications using that support library.
Thus, the best option is to have that 2MB support library already in your OS for any number of apps, instead of having it for each application. So, support libraries are meant to be used when you really want some efficient features in your app to support older versions.
Another question arise here:
why not this support library is added to the OS as its own update, so that every app without size problems can access that functionality?
The answer is that there could be a lot of errors. Suppose some user doesn't have that update (support library) installed...
There is also the chance that as an update, it may not work as efficient as supposed to be, or may cause problems while integrating with the OS, as we already seen that each OS (windows, Linux, mac) comes with new versions, instead of just giving updates for life time for all new features.
Android 4.0.x (ICS) has a lot of added features compared to lets say Android 2.3.x (Gingerbread). The compatibility libraries are there to bridge some of those changes that were added to ICS that -could be- supported by Gingerbread. "could be" being the key phrase here because there are a ton of changes made to ICS that would never work with Gingerbread and those, of course, will not get a compatibility library.
Fragments for example, which you brought up, are actually done slightly different in ICS than in the compatibility library because ICS has more features it can use. If you look at the code for ICS for the Fragments class, they are not the same as those in the compatibility library. Its a whole second set of code to make something "like" the Fragments in ICS be used in an older version like Gingerbread without the programmer noticing much difference.
That is the point of compatibility libraries and the reason why they aren't used to extensively patch Gingerbread to use all of the features in ICS (they just can't). The point of the compatibility libraries is to interface things available in newer versions of android such as ICS, done the ICS way into older versions such as GB, done the GB way.
As far as why they don't just keep the support library growing and leave the same base OS -- the answer to that is compatibility issues. If a user only has v4 and v12 is out, what happens? Android right now uses the Android API version of the OS as a basis for application compatibility and developers have an option to include support libraries (increasing file size of their app, but giving them newer features). Every application that uses support libraries, independently includes them (meaning 4 apps = 4x included).
The idea is, you may only download apps supported by the current API version of your OS (as far as Google Play is concerned) and you may choose to include support libraries to keep the look and feel of your app supported for older APIs, that do not yet have features that you elect to have available for those users on newer APIs. It's really a look and feel consideration more than anything else.
Hope that clears things up :)
What has been said already it is true. Although there are some details missing.
In fact, I had the chance to attend to a session in the last Google IO where they specially talked about that.
It was actually surprising for me to get to know that support library doesn't host the code for all the posible API versions, rather it's an adaptation of the new features which they think are relevant enough to make them available to older platforms. So the way it works it is generally the following:
Let's say we need to use the brand new (available from API 16) ConnectivityManager to keep track of network changes
We include support libraries v4 and we use the class
The way it works after is that the system will check our API version and will run built-in native code in case we are in API 16 or will run the code of the support library in any other case.
So it's acting like some kind of route gateway. Reason being is that it's generally more efficient (and performing) to use the last code optimized for the last OS and the last system improvements (ie.: hardware acceleration).
Nonetheless there are some elements that weren't translated to the compat library as they are in the native built-in code. For instance fragments weren't meant to be re-written as they are from API13 since they are a huge component that need to run in a wide range of different scenarios within system and devices with less capabilities.
Ultimately and because all this, it is recommended to use compats libraries which is known as a good practice, specially if you intend to make your apps / code available for older versions (which should be the ideal way)
The support library does not in fact have everything that is in the newer APIs. It does support parts of the Fragment API, but it does not yet support ActionBar. For that you need another library like ActionBar Sherlock.
Why are there two libraries?
Because part of the problem was Google only back ported some of the stuff, but my understanding is that, additionally, some of the new functionality can't be back ported due to core OS framework limitations and missing APIs deep in the core of the Android UI framework.
Android came up with cool features of fragments and action bar in recent releases.
Now if we want to use these features and also support older version of android then we will have to write highly messy version dependent code, which is not good.
To save us from all these mess, android came up with support library which does not provide full support of new features but is good enough to allow developers to write neat code which is supported on all devices.
Answer to your second question is very simple, fragments are integrated part of v3.0 and if you want you application to run only on v3.0+ then you really don't have to include external library.
Fragments from Support library equivalent to fragments of Honeycomb+.
To second quest, from documentation:
v13 is a superset of v4 and includes additional support classes to work with v13 APIs
ie the same functional, just adapted to v13 API.
I am use modified v4 support library - with maps.
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.