Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I would Like to make an Android App .I am just a Beginner .As am at the first stage I need to Know if I make an App for 2.2 version will it work for 2.2 and above it .?
Theres multiple details you should account for.
From the official android developers site:
Applications can use a manifest element provided by the framework API
— — to describe the minimum and maximum API Levels under
which they are able to run, as well as the preferred API Level that
they are designed to support. The element offers three key attributes:
android:minSdkVersion — Specifies the minimum API Level on which the application is able to run. The default value is "1".
android:targetSdkVersion — Specifies the API Level on which the application is designed to run. In some cases, this allows the application to use manifest elements or behaviors defined in the target API Level, rather than being restricted to using only those defined for the minimum API Level.
android:maxSdkVersion — Specifies the maximum API Level on which the application is able to run. Important: Please read the <uses-sdk> documentation before using this attribute.
You can define a target SDK version, a maximum and a minimum SDK version. This means your app will run from minSDKVersion to maxSDKVersion.
You can define this in your Manifest.xml.
To know more about this attribute, and to know what are the pros and cons of your decision, check this.
Each new Android version provides an additional/incremental set of features (to the API) compared to the previous version. So creating an application for 2.2 limits you in the available 'modern' functionality (as it was not yet provided/added).
If you do not require any of the functionality of Android 2.2+, then you design your application for 2.2 and it will (most likely) work on higher versions of Android as well.
Note that some of the 'modern' functionality is provided by the (backwards compatibility) support libraries for older Android versions. So you are still able to use this functionality.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
I think I am not understanding how the programming knowledge of Android Studio works. I mean, I have seen many courses on the internet that are focused in a certain version of Android Studio. So if I learn Kotlin of android 10 will be useless beause now only Kotilin of android 12 is usefull? Will i have to learn a new kotlin lenguage everytime a new version of android is comming? I am studying the programming language of "c" and it doesn´t matter what version you are using that everything you learned of "c" will be useful for any period of time. But I have seen that in kotlin is different,so, does the programming language of Kotlin change depending on the version of android that you are working on? What is the difference between working on Kotlin android version 11 that Kotlin android version 12 on Android Studio? Thanks
No it won't be useless. You need to distinguish between the programming language Kotlin and the Android Framework and its APIs.
If a new Android version comes out, it doesn't mean we start writing apps from tabula rasa.
Every year, with a new Android version, Google introduces a few changes to how things work or extend the capabilities. For us as Android developers that means that we might need to consider new restrictions to permission management or things like that.
To summarize: The Android OS version has nothing to do with the programming language Kotlin itself. You are programming against the Android API version using Kotlin. You don't need to learn everything from the beginning when the next Android version comes out.
Old, abandoned Android apps generally work perfectly fine without modifications on newer devices - I still use plenty of such apps to this day.
However, if you were the developer of such an app, and you wanted to, say, push a small update to fix one minor thing, you would be forced to update your app to meet the standards of current Android versions first, or otherwise your update wouldn't be accepted on Google Play.
Example: in the past apps used to ask for all the permissions at once before installing, and while you probably can still find such apps in the Play Store, you wouldn't be able to publish such an app nowadays.
Instead, you would need to adapt your hypothetical old app to use this new pattern of asking for permissions right before they are needed first.
The Kotlin programming language is the same Kotlin programming language, there are no differences here between Android versions. New Kotlin releases generally only add new language features, they don't delete anything that matters, there is no need for you to worry about this.
For each Android app you make you choose a target Android version and minimum Android version (you can change them later).
Target version
The target version should generally be the current most up-to-date Android version. That is the version of Android that you designed your app in mind with. You should only later increase this number after you learn what the new guidelines, standards, features, etc. are in the new Android version - you will often need to change something in your app when you decide to "upgrade".
Minimum version
The minimum version is the oldest version that you want to have to keep in mind.
I don't really have good examples at hand here, but imagine support for flashlights was added in Android 5. So if set your minimum version to, say, Android 3, you would need to add a condition if your code to define what happens when the user is on Android 3 or 4 that doesn't have the support for flashlights. You would need to display a message to them for example, or make the your flashlight button grayed out and unclickable.
On the other hand, you could just set the minimum version to Android 5, and then you wouldn't have to write this code, because you could just assume that all devices that will be able to run your app know what a flashlight is. So that's less hassle for you, but it also means that less devices will be able to use your app.
Changing Android versions means improving Android phones operation system with new features. It does not have any kind of impact on Kotlin or Java language. You will use same Kotlin for all Android versions.
This question already has answers here:
Is there any reason to use the support.v4 library in Android?
(3 answers)
Closed 6 years ago.
When I hear the name "compatibility library", it sounds like something that I would use if I want to make my app compatible with something. Each Android compatibility library has an API level associated with it, e.g. "7". This evidently means that I can build against API level 24 but ensure that the app can be run on anything way back to 7.
This makes sense to me.
However, it seems that these "compatibility libraries" also contain features that are not available elsewhere, even in Android itself. For example DrawerLayout is something found in support-v4 but evidently nowhere else. This means that you can set your minSdkVersion to "15" but you still need to declare support-v4 as a dependency if you want to use DrawerLayout even though you don't need compatibility way back to API level 4.
However, I haven't been able to find anything that states this explicitly. Have I read between the lines correctly, or is there something I am not getting?
Your basic understanding of the Android support libraries is correct. The libraries are intended for backwards compatibility. However, Android can introduce new features in the support libraries that aren't in the core framework. Android uses this because every device is slightly different, and therefore apps look different on different devices. (You can easily see an example, run ConnectBot on Android 2.3 and 4.1, or any two versions that look significantly different). The support libraries try to help unify the experience across all devices.
I hope this answers your question.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Via developer.android I still see that API 10 (2.3.3) still has a large usage, and it would seem to be good to support it; however, I do see that API 16+ (4.1+) are increasing in usage pretty fast. It looks like it is doing so by reducing usage of API 10.
I have been wanting to see a chart that could have showed be the usage of API 10 over the years and see the RATE at which it is being reduced by. I have looked at Google's Cached version, but that only take me back a week. I have looked at Wayback Machine's version, but they don't contain the pictures anymore!!
I know that API 10 (basically all of Gingerbread) is being used less and less, and I am just trying to figure out how long from now (based on trajectories) when API 10 will be basically a real question if it should be built for or not...right now it kind of is a necessity (33%)...IF you look at it in a static context!!
Is it worth the time and money to implement API 10 if in 6 months (or 1 year) from now that percentage is only 5 - 10%?
According to the docs:
The dashboard for Platform Versions is updated regularly to show the
distribution of active devices running each version of Android, based
on the number of devices that visit the Google Play Store. Generally,
it’s a good practice to support about 90% of the active devices, while
targeting your app to the latest version.
emphasis added
IMO, it doesn't matter if Gingerbread will vanished within 6 months. Until there you could lose a lot of clients to your competitors.
OK, a lot of the ideas of whether to do this are subjective in nature. I have seen suggestions pointed out by Exception-al before...with it being good practice to support 90% of all active devices. I do agree with that on a high level; however, my question was pointed at the (near) future, and trying to predict that from past data via information Google releases in its Dashboards.
In a static context, the 33% would seem very reasonable to implement it as a minSdkVersion. However, with my research, I stated This is subjective, but seems like the drop in usage will be large in the next 6 - 12 months. I just want to know if I am right...or wrong., and I have recieved the following I think your time frame and percentage estimations are reasonable. – FoamyGuy
However, that is still very subjective! I want data to back up my thoughts.
I found this one chart before...now I can only find a YouTube video with it here, but the level of detail is bad. However, I just found Android Platform Usage in Wikipedia! Which has a saved history!!
This is NOT the best format...but it gives me some actual real data to go off of. I guess I will start a discussion there if someone could go through all the info and publish that data on that Wiki, or elsewhere.
NOTE: If anyone else finds something better, then I will accept there answer
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
from the above link
Selecting a platform version and API Level
When you are developing your application, you will need to choose the platform version against which you will compile the application. In general, you should compile your application against the lowest possible version of the platform that your application can support.
You can determine the lowest possible platform version by compiling the application against successively lower build targets. After you determine the lowest version, you should create an AVD using the corresponding platform version (and API Level) and fully test your application. Make sure to declare a android:minSdkVersion attribute in the application's manifest and set its value to the API Level of the platform version.
Set your min sdk to the lowest api level that will support your app. Set your target api level to the highest api level available.
Examples of setting min to 18
Using Network Device Manager so home networks are aware of your app.
Using low power bluetooth
Examples of setting min to 7
Using the action bar (support v7 library)
Examples of setting min to 4
Using fragments (with support library v4)
What is the difference between targetSdkVersion set in the Manifest file and the Project build target set in the building environment (e.g. Eclipse) ?
I have tried to find more information on these two features, but I couldn't find any clear and specific explanation.
It seems like the Project build target decides on the API compatibility level, to be used during the compilation. When the targetSdkVersion only affects the visibility of the manifest elements of the given API level.
Could anyone confirm/expound this?
EDIT: Thanks guys for prompt responses. I forgot to mention in my question that I have read all the topics on Android Dev regarding these features and also googled it and searched it on Stack Overflow. So I understand the basic purpose of min/target/maxSdkVersion to be used in Android Market and in the Android System itself. However, according to other posts from people having problems with this Manifest option, it seems uses-sdk does actually have impact on how the the API level is interpreted. At least that is what I suspect.
A really good explanation is given here:
http://developer.android.com/guide/appendix/api-levels.html
However, it is still unclear for me whether the targetSdkVersion does affect the compilation/runtime of the APK on Android System? Or it is only for validation as the uses-sdk documentation suggests?
The targetSdkVersion attribute does indeed affect an application's runtime behavior.
Depending on what you set it to will determine whether compatibility features are enabled/disabled in the Android framework.
For example, once you set targetSdkVersion=11, your application's default theme will be set to #android:style/Theme.Holo -- meaning your application will have a Honeycomb-style UI widgets, will get an Action Bar, and will not have an Options Menu button at the bottom of the screen.
If you set targetSdkVersion to a lower value than, your default theme will continue to be #android:style/Theme -- regardless of which API level you're actually building against.
The targetSdkLevel also affects what the default values are for the <supports-screens> element, which in turn will determine whether your application runs in density compatibility mode.
Interesting note: Android Market doesn't actually use the targetSdkLevel attribute for anything at the moment. It's purely used at runtime for compatibility purposes, and possibly at compile time -- though I haven't looked into the behavior there. If people are curious about the compiler, I could check with the SDK team to get more information.
Of course, it's entirely possible that Market could decide to do something with this in the future.
The Build Target is used to know which SDK to compile your APK with. This means that if there are any Classes or methods that aren't available in your min SDK version, but are in versions after that, those Classes or methods will still be available to use. You will just have to make sure to check when you're using those and do alternate approaches if the user's SDK version isn't compatible with those classes/methods.
android:targetSdkVersion
An integer designating the API Level that the application is targetting.
With this attribute set, the application says that it is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here. Specifying this target version allows the platform to disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications. This does not mean that you can program different features for different versions of the platform—it simply informs the platform that you have tested against the target version and the platform should not perform any extra work to maintain forward-compatibility with the target version.
You can find more information by referring to this URL:
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
There's also a good article written by google on checking to make sure you're current users Android OS version will use the appropriate Classes/methods
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
In your "Create Project"-dialog in Eclipse, you specify the minSdkVersion. This is the API-Level that is required to run your application.
The targetSdkVersion-attribute only tells the Android Market that your App was developed (and maybe optimized) to run under the specified API-Level.
Build target is the one on which you will be testing the app. targetSdkVersion is the one your app was specifically developed for. Both are same most of the times.
You will find a detailed explanation here.
targetSdkVersion attribute informs the system that you have tested your app against the given version (api level) and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to minSdkVersion).
For further detail - http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
This question has already been adequately answered, but I want to point out that it is no longer entirely correct that the Google Play store does not use targetSdkVersion at all.
In the specific case where you set targetSdkVersion to 23 (Marshmallow 6.0) and upload your APK, even if you are uploading a Beta version, you will not be able to ever again submit an APK for that app that has a lower targetSdkVersion than 23.
This is because of changes to permissions between 22 and 23 which are not allowed to be reversed for a given app.
This can be a bit of a trap if you were just trying out 23 in Beta and not sure you were ready to support it yet.
I currently have a application targeted at android 2.3 (api level 10), but went thinking that probably people using android 2.1/2.2 or older won't even be able to see the application in the market.
So I thought that using api level 3 would be the best to use, but I don't know if this will maybe make certain elements in my app work less good, and probably buggier, since it actually uses old android code. Is there a good way to find out which API level I should use, and also, how do I convert my application to that level?
You can find a breakdown of the different versions of Android in use here. Currently, if you target 2.1 (API 7) you'll only miss out on about 3% of the market. Targeting 2.2 will miss just under 20%, or a fifth of the market.
As for converting your app, you can check what API level things are available for in the Android Reference. You'll note a checkbox and dropdown menu on the top right of the browsing area that allows you to filter by API level - that's one way to help converting. The other is to set the target and minimum SDK versions which will help Eclipse know what to complain about in your code. The easiest way to see if something needs conversion, however, is to emulate and test.
EDIT: The API level dropdown moved from the top right to the top left, over the list of APIs.
This graph may help you make up your mind.
It is good to look at backward compatibility and in general, you should compile your application against the lowest possible version of the platform that your application can support.
You can determine the lowest possible platform version by compiling the application against successively lower build targets. After you determine the lowest version, you should create an AVD using the corresponding platform version (and API Level) and fully test your application. Make sure to declare a android:minSdkVersion attribute in the application's manifest and set its value to the API Level of the platform version. Good luck!
If you have
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="10"/>
then it will appear right down to 1.6, but make sure you don't use antyhing that they don't have in their API
edit: Don't bother with 3! :)
I started out developing for 1.5, but soon realized that only a small percentage of people still run 1.5. I generally develop at the 2.1 level, and leave it at that (unless you need features at a higher level). To change it, open your project properties, and while I don't have my environment open, there is an Android option where you will select what API level you want to target.
The Best API Level is contains follows
1) The best API covers 100% market but all are not prefect so our app should be covered at least 90% with all devices .
2)We have to care about backward compatibility issues and our code would adapt itself for upcoming versions.
3) Using the new Android SDK is a requirement to use any of the new APIs added in that level. It should be emphasized ... It is ultimately a business decision on whether supporting an additional 3% of devices is worth the development and testing .
4) check out this link https://developer.android.com/guide/practices/compatibility.html#defined
5) Finally choose the best API you will find best API