This code is some basic code to set up tabs in Android.
final ActionBar actionBar = getActionBar();
actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS);
If you write this code in a project where targetSDK < 20 or compileSDK < 20 (I don't know what the difference is between versions of compileSDK and targetSDK) then it is fine.
However, if you have compileSDK higher, e.g. 23, then Android Studio will tell you that the code above is deprecated (and moreover is removed from SDK, I guess).
And it will crash my app if i run it on device (btw on Android level 20, though the target of project was set to 23 and compiled version too 23, so it crashes because it is deprecated and removed from SDK level 23).
Questions:
1) What happens if I compile my project with compileSDK version and
targetSDK version set to 20 (where there is no problem with being
deprecated) and try run it on Android with SDK 21 or 23 where these
functions are obviously removed from SDK? Will the app crash or work?
2) What happens if I decide to target the "high" SDK (e.g. 23)? That
is, I will leave the "old" code mentioned above and will use some
"new" code for tabs, which appeared in SDK 23 or so (which didn't
exist in lower SDK); then I will try to run the application on
Android with lower SDK, e.g. 20. Will the app crash or work?
edit:
Btw now i launched project with targetSDK and compileSDK 20 on Android with level 22 and it worked.
So it seems the only thing that really matters is the compileSDK version? Doesn't even matter on the SDK version of device but it really matters the compileSDK?
Because as i said about the two tests - project with bad HIGH SDK launched on device with good LOW SDK = crash. Project with good LOW SDK launched on devide with bad HIGH SDK = not crash.
But the logic of course say that it must also matter on android version of device (eg to access some new functions.. or really only matter on compiledSDK or at least from view of backwards-functionallity)?
Need some opinions of experts on this.
However, if you have compileSDK higher eg 23, then Android Studio will tell you, the code above is deprecated (and moreover removed from SDK i guess).
No. getActionBar() is not deprecated. setNavigationMode() is deprecated but not removed.
What happens, if i compile my project with compileSDK version and targetSDK version eg 20 (where is not problem with deprecated) and will try run it on Android with SDK eg 21 or 23 where are these functions from SDK obviously removed? Will app crash or work?
The app should work fine. "Deprecated" means "we think that there is a better solution and we would prefer that you use it".
What happens, if i decide to target the "high" SDK that means eg 23, i will leave the "old" code mentioned above and will use some "new" code for tabs, which appeared eg in SDK 23 or so (that means didn't exist in lower SDK) and i will try run the application on Android with lower SDK, eg 20? Will app crash or work?
First, I am not aware of any "'new' code for tabs, which appeared eg in SDK 23". The Design Support library has the only new tab implementation that I can think of, and it works back to API Level 7.
Second, your app should fail to compile, if you are trying to use something that is newer than your minSdkVersion without adequate checks (e.g., using Build.VERSION.SDK_INT and bypassing that code on older devices).
In the end, if you refer to a class, method, field, interface, and so on that does not exist on the older API level, your app will crash if and when that code gets executed. A typical error is VerifyError, though it depends a bit on the nature of what it is that you are trying to use that does not exist.
With respect to tabs, there are countless implementations available to you. Most come in the form of third-party libraries tied to ViewPager. In terms of the Android SDK, there the aforementioned TabLayout from the Design Support library, FragmentTabHost, and PagerTabStrip (though the latter has a bug in the 23.0.0 edition of the support-v4 library, apparently).
Deprecated API are still available, so you're free to use them - the app won't crash on neither of platforms. However, it's advised that you read the documentation to understand why the API have been deprecated: usually developers provide alternative solutions.
Here is some explanation on compile/target/minSDK.
1) What happens, if i compile my project with compileSDK version and
targetSDK version eg 20 (where is not problem with deprecated) and
will try run it on Android with SDK eg 21 or 23 where are these
functions from SDK obviously removed? Will app crash or work?
Android Studio is probably only warning you that the API has been deprecated, but not removed. If it had been removed, setting the compile SDK to 23 should break your compilation. Your application should work fine even if it is using a deprecated API, but you should update that when you have the time as it is no longer the recommended one.
2) What happens, if i decide to target the "high" SDK that means eg
23, i will leave the "old" code mentioned above and will use some
"new" code for tabs, which appeared eg in SDK 23 or so (that means
didn't exist in lower SDK) and i will try run the application on
Android with lower SDK, eg 20? Will app crash or work?
When you use an API that has been introduced in SDK 23, you will need to set compileSDK to 23 as well. In case you set your minSDK to 22, you will be able to install it on a device that is using SDK 22, however, your app will crash with a NoSuchMethodError if you try to use that method. You can however check the SDK running on the device (use Build.VERSION.SDK_INT) and not call that method in this case.
Related
I am a complete beginner in Android Development and just downloaded Android SDK to integrate it with Eclipse.
However, I don't know which Android version I should select in SDK Manager to allow a maximum number of people to download and use my app.
Here's a screenshot of the manager that is showing up on my screen.
Any kind of help would be really appreciated.
Thanks.
In fact, you don't need to download an OLD SDK just to allow OLD Devices to use your app.
This is done in your project settings via target SDK version and min API level(AndroidManifest.xml or build.gradle).
Define Audience
First, define the audience to your app.
HERE you can find the market share for every Android Version (this can change for each country but it may help).
If you check that table, you can see that only few devices are still using API 15 or older.
So, if you support API<15, you will only reach ~3% more people. If you can support them without lose any feature, good (not all android features are supported/ported to all versions). But if you may need to disable a feature (like that special Floating Action Button that you created) just to reach those devices, I think it does not worth.
So, based on that table, you define the audience
In my case for example, I like to build apps for devices with API from API_16 to API_24.
Usually, we always want to use maximum API available. Today, 24.
This way, I could reach ~97% of the people using Android.
But this is optional... I could select min API as 13... or 14.. or 4.. This is up to you..
After defining the audience
Target SDK
I usually set the target API according to the MAX API I want to support. So, for example, if the MAX API I want to support is API_24, this will be my target API and will download the SDK v24 (7.0).
Usually, you always will have the latest SDK installed since you always want to reach latest android version and enjoy all the new features.
MIN API
Now, you also have defined the min API version that you want to support. So, lets use API 16 for example (first JB version).
You will set this in your project file (AndroidManifest.xml). You don't need to download SDK 16 just because of that.
Setting Eclipse
As I said, min SDK will be set in your project. That would be done in your Android Manifest
Here, you can see that targetSdk is 24. It means that I just need to download SDK v24 to build this project. Even then, I'll be able to install this App in devices with API 16 or later.
Eclipse (AndroidManifest.xml)
<manifest>
....
<uses-sdk
android:minSdkVersion="16"
android:targetSdkVersion="24" />
...
</manifest>
Android Studio (build.gradle)
compileSdkVersion 24
buildToolsVersion "24.0.0"
minSdkVersion "16"
targetSdkVersion "24"
minSdkVersion Does Not Guarantee that your app will work
Note that settings above only allow your app to run in devices with API>=16 or API<=24. However, your app may crash or does not work in all devices within that range. This usually happens because some View Components or Methods were added or removed according to API version.
For example, Fragment was added only on API11. So, if you try to install your app in a phone with APIv11, it will work. However, if you install it in a device with API4, it will crash.
Another example is method Fragment.onAttach(Context context) which was added only in API 23.
That's why we use Support Library
Support Design Library it is a library created by Google which enables the developer to use features from new Android Versions in old Android versions.
So, for example, to add a Fragment which is compatible with devices with API<11, you should import and use Fragment class from package android.support.v4.app.Fragment instead of default version included in SDK (android.app.Fragment).
This way, your app wont crash.
Of course this is very basic example. It is just to illustrate...
Anyway, I hope I could help you
Regards
I know there are plenty of documents over the internet but I have still some doubts about what SDK to install on my computer to create an android application for nearly %100 devices to working with. Google Play says that if I use API 8 (which is Android 2.2) then my application work nearly all Android devices.
So I downloaded API 8 and API 22 (Android 5.1, was default installed by Android Studio itself) and I don't know if it works or not if I select Minimum SDK to API 8 while creating a new project.
So seriously guys, what the heck is going on?
What SDK Platform(s) you install has little to no impact on what versions of Android you can support.
If you create a new Android Studio project via the new-project wizard, you will find an app/build.gradle file. In there, you will find a setting named compileSdkVersion. This controls what version of the Android SDK you are compiling against (i.e., what JAR is used to satisfy compile-time references to Java classes like Activity and TextView). Whatever value you specify for compileSdkVersion must be an "SDK Platform" that you have installed from the SDK Manager.
In a newly-created project given your setup description from your question, you will see that compileSdkVersion is 22, lining up with pre-established API Level 22 edition of the SDK Platform.
However, this does not mean that your app will only run on API Level 22+ devices. Much of what is in the API Level 22 edition of the Android SDK has existed in previous versions of the SDK.
The minSdkVersion property in the same app/build.gradle file says how old you are willing to go -- what is the lowest API level you are willing to support. Right now, I think a new project will be set up with minSdkVersion of 15, though that varies over time. More importantly, you can change it to be whatever you want, and you do not need the SDK Platform installed for whatever level you choose.
If, in your code, you reference stuff in the Android SDK that is valid for your compileSdkVersion but is newer than the minSdkVersion, the build tools will point out the discrepancy, so you can make sure that you know what you are doing. This is how Android handles progressive enhancement -- you see what version of Android you are running on (Build.VERSION.SDK_INT) and use newer APIs where you can, falling back to older APIs as needed.
TL;DR: So long as your compileSdkVersion has a value for which you have an installed SDK Platform, you're set.
It depends on the application you are developing. And the resources that it will need. It's true that if you use the oldest version (API 8) and your application is simple enough, then it will work on any device.
But there are limitations to it. on older APIs you will not be able to use new features as Navigation drawer for example
I would recommend API 11 or 14, that covers most of the devices and features nowadays.
You should consider the design you want to create on your app
You can see the market share of the different api versions here: https://developer.android.com/about/dashboards/index.html
Then you have a trade-off of how advanced APIs you want to use vs. how many devices you want to support.
I was following through a Udacity course on android , and these terms seem to confuse me
(i use android studio 1.x latest version)
In my build.gradle i have these
compileSdkVersion 21
buildToolsVersion "21.1.2"
......
minSdkVersion 10
targetSdkVersion 20
versionCode 1
versionName "1.0"
....
compile 'com.android.support:appcompat-v7:20.0.0'
My assumption
If I leave the app theme as default that is in my manifest file,i set it to use app:theme and in styles.xml it is by default
appcompat.light.darkaction bar
I figured out the appcompat theme means ,it changes to use the theme for the version of the target SDK irrespective of the device OS version
when i chose API 21 ,it looked like a material app
when i chose API 20, it looked like a kitkat app
(both on my device which runs ICS)
so target SDK is contolling the look and feel of my app irrespective of device OS,
it defines what highest version of android the device can support , right?and by default the look and feel change to the latest or the target API look and feel whilst using app:compat theme still enabling it to run on lower sdks ,,as low as API 10
and minsdk is the minumum supported ,
am i right till here?
Now what confuses me is
what's compile SDK , should it always be the latest available ?
Example : material didnt show app icon in action bar icon , i didn't like it , and switched to API 20
to follow with the MOOC videos
but should i leave compile sdk as 21 , wont that make the app look like material , cause i'm confused as it didnt?
And a final question ,
I want to test the app on devices running gingerbread, i don't have any,
can you suggest some typical AVD config for gingerbread devices(cause i know a lotta people still use it in developing nation),
what ram,screen size and pixel density should i use that fits a typical gingerbread device?
so target SDK is controlling the look and feel of my app irrespective of device OS,
Yes. (among other things)
it defines what highest version of android the device can support , right?
No ! The target SDK indicates the SDK you use to test your app. You can use a target SDK 20 and run your app on a device with API 21 installed : it will use the KitKat l&f (i.e level 20).
How is it possible ? When an app targeting API 20 is running on a device with API 21 : the system will automatically enable some backward compatibility hook so that your app behaves just like it behave on older versions (i.e. targetVersion) of the OS.
The maximum sdk supported is the maxSdk attribute (rarely used and not recommended). If you specify a maxSdk 20 : you won't be able to install your app on a device running SDK 21+
The compile SDK level is the version of the sdk you use to compile your app. If you choose the latest one : the users of the latest android version will benefit of code that is optimized for them. It will allow you to use the latest features of the sdk... but be careful when you write code using new apis since it will crash on older devices.(see here under)
The minimum sdk version may be lower than the compile sdk. In your example you are declaring that your code can be executed on API level 10, but compiled with api level 21... that's OK but you MUST ensure that every calls to API that don't exist in API-10 won't be executed on a device running API-10.
Let's illustrate this tricky point. Assume : compileSdk = 20 ; targetSdk = 20 and minSdk = 10
if (Build.VERSION.SDK_INT >= 13) {
apiCallToSomethingAvailableOnlySinceApi13();
}else {
//put here some alternative code to perform something similar
//(but probably degraded) feature
//on device running API 10, 11 or 12
//device with api 9 or lower are exclude anyway (because minSdk is 10)
}
To summarize :
minSDK : it is possible to install the app on a device with at least this level and the developer wrote defensive code to ensure that all calls to api more recent than minSdk won't be executed on device running the minSdk version.
targetSDK : the app was tested on this level and more recent devices must enable backward compatibility hook so that the app still behave as if it was running on this level even on more recent devices.
compileSDK : the code is optimized to run on this level. (usually safe to put it the same as targetSDK)
maxSDK : you cannot install the app on a device running higher API (not recommended and most of the time not useful).
I'm working on an application which uses ActionBarSherlock. As it's documentation points out:
[...] the library requires that both it and your project are
compiled with Android 4.0 or newer. The project also requires that
you are compiling with JDK 1.6 in both your editor and any build
systems that you may be using.
So, that means I'll compile my application (and the library) against Android 4.X but in my Manifest, I declare that I'm targeting (e.g.) API Level 9.
This all works fine and well but there is something that disturbs me. From the FAQ:
What API level should I target in my manifest when using the library?
Targetting API level 11 or newer is required as it will cause Android
to automatically add the native action bar when run on newer devices.
Since you will be compiling against new APIs but your app will likely
be run on devices with older versions of Android extra care must be
taken to either avoid using or properly check and call any methods
that were introduced after your minimum SDK version.
That means, that I'll have to manually check every method call, so I don't use any that are not available in my targeted API Level (9 in my case)? This sounds wrong to me.
Is there a way to tell my IDE (IntelliJ), that I'm only using the API Level 9 (so I don't get any auto-completion for non-existing methods/classes and don't use them by accident) and then choose to compile it against another Android version?
Or can I use some automated checks (which run at compile time) to check for that?
The ADT's lint feature should take care of this by warning when API calls are being made for the wrong API version.
You should be compiling both ABS and your project with the latest SDK available (at present, 4.1). Your manifest should have a targetSdkVersion as high as possible (ideally matching your compilation SDK) and your minSdkVersion should be set to the lowest version you support.
Lint is partially integrated with IntelliJ IDEA and is also available as a command line tool.
You temporarily set your target SDK to the various lower ones and debug with it. Your final build then is with the latest SDK.
Set a Build target similar to that you have mentioned in your manifest.
as always , you should set the targetSdk to the maximum available on both the manifest and the project.properties file (as recommended by google on one of their videos) , so that the ADT&SDK would be able to optimize the ADK accordingly.
set the minSdk to the one that you wish to support your app from , and let Lint to tell you if there are any problems in case you use too-new-features.
So I wrote an Android app a while ago, and I'm trying to update it. I'm wanting to build in code sections where if the phone they're on is less than 3.0, do something one way, otherwise do it another way.
My build target is set to 11 in the project.properties file, but it still seems to run on Android versions < 3.0? Is this normal? Will I see some crash at some point? Everything seems to be working... My minSDKVersion is 8, but happens when I run this app with Android 3.0 code on Android 2.3.3?
It will in general run OK on platforms as far back as API level 8, since that's what you have as your minSdkVersion. It will, however, crash on earlier (pre-11) platforms if you try to call any APIs which were introduced at level 11 or later. To avoid this, you should check the OS version at runtime before calling any such methods. See Retrieving Android API version programmatically for advice on how to do this.
It is usually best to work from lower APIs up when approaching this kind of development. Each time you've finished a working version for an API, make sure it compiles without error before moving up to the next level. The manifest will warn you if you're targetSdkVersion and your minSdkVersion are different; however, this is mostly just to make sure that you are careful not to call methods from higher APIs. A useful work around might be:
private static int getApiLevel() {
return Integer.parseInt(android.os.Build.VERSION.SDK);
}
I think I was having a dumb moment.
If I set my minSDK to 8, then anything newer than 8 should work fine.
If I set my build target to 11, and then do checks before running any code that is newer than 8 on phones with SDKs older than 11, then that should cover all the bases.
I just got a little confused when I was messing with the targetSDK and the minSDK
Thanks for the comments.