Develop Reference

How does an android app fit in all different APIs? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
When you download an APP, the layout was fine regardless of what API the phone has. When I was making an APP for a school project, I used a different API to what my phone has in development , the layout was so messed up. Does the programmer release different versions for different APIs and when you download the APK, the app store determines which API you have and provides you with the corresponding version?

"When I was making an APP for a school course last semester, I used a
different API to what my phone has in development , the layout was so
messed up."
even the apk is compiled against certain api version the difference could be a result of:
implementation eg of components per os version (the implementation on device is different than the one the developer has compiled the app against)
mixing and usage of different support library version the app is compiled against - to maintain compatibility developer could use a support library or newest framework called androidx
each vendor/oem (original equipment manufacture) may alter the aosp but it need to maintain CDD [difference for altered framework / res / theming - vary by device oem] eg. deprecated overlays
usage of JIT
result of bugs
constantly changing android/gradle build tools altering the result of newly compiled the same source code of apk
the dev could use a custom class loader which may produce a different result each time the app is launched - eg like google uses its own network class loader in the account manager to create on device google accounts
the app could be an instant app or module app
mostly is a result of theming [styleables, attributes, even produced by os drawables]
for more info please refer to:
https://developer.android.com/topic/libraries/support-library/
https://source.android.com/compatibility/overview
https://source.android.com/devices/architecture/
"Does the programmer release different versions for different APIs and
when you download the APK, the app store determines which API you have
and provides you with the corresponding version?"
MOSTLY NO but the dev could make per configuration or architecture apk's so the play store could serve different one based on device type
see:
https://developer.android.com/google/play/publishing/multiple-apks

The same version of APK is used for every versions of android supported by the app. The fact that the app looks identical across different versions of Android is most of the time due to the usage of Android Support Libraries (or android x).
Nevertheless, with the new Android Bundles , the developer can define portions of the app which are available only to specific versions of Android.

As said in the Android documentation:
"Platform version
Different devices may run different versions of the Android platform, such as Android 4.0 or Android 4.4. Each successive platform version often adds new APIs not available in the previous version. To indicate which set of APIs are available, each platform version specifies an API level. For instance, Android 1.0 is API level 1 and Android 4.4 is API level 19.
The API level allows you to declare the minimum version with which your app is compatible, using the manifest tag and its minSdkVersion attribute. For example, the Calendar Provider APIs were added in Android 4.0 (API level 14). If your app cannot function without these APIs, you should declare API level 14 as your app's minimum supported version.
The minSdkVersion attribute declares the minimum version with which your app is compatible and the targetSdkVersion attribute declares the highest version on which you've optimized your app"
In your build.gradle (Module: app) file you always have something like:
android {
defaultConfig {
applicationId 'com.example.myapp'
// Defines the minimum API level required to run the app.
minSdkVersion 15
// Specifies the API level used to test the app.
targetSdkVersion 28
...
}
}
"Each successive version of Android provides compatibility for apps that were built using the APIs from previous platform versions, so your app should always be compatible with future versions of Android while using the documented Android APIs"
I think it is also very nice the note in the same link:
Note: The targetSdkVersion attribute does not prevent your app from
being installed on platform versions that are higher than the
specified value, but it is important because it indicates to the
system whether your app should inherit behavior changes in newer
versions. If you don't update the targetSdkVersion to the latest
version, the system assumes that your app requires some
backward-compatibility behaviors when running on the latest version.
For example, among the behavior changes in Android 4.4, alarms created
with the AlarmManager APIs are now inexact by default so the system
can batch app alarms and preserve system power, but the system will
retain the previous API behavior for your app if your target API level
is lower than "19"
More details on the setup of the Android Support Libraries needed to guarantee the Backward Compatibility for newer APIs can be found here
With regard to fixing the minSdkVersion the documentation comes to help again:
"If your app uses APIs added in a more recent platform version, but does not require them for its primary functionality, you should check the API level at runtime and gracefully degrade the corresponding features when the API level is too low. In this case, set the minSdkVersion to the lowest value possible for your app's primary functionality, then compare the current system's version, SDK_INT, to one the codename constants in Build.VERSION_CODES that corresponds to the API level you want to check. For example:"
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
// Running on something older than API level 11, so disable
// the drag/drop features that use <code>ClipboardManager</code> APIs
disableDragAndDrop();
}
Another very important point that not reported yet in that link is that "Starting on the dates listed below, the Play Console will require that APK uploads target at least Android 8.0 (API level 26)" source
so to be compliant you have to set up the preceding build.gradle file with nothing less than:
targetSdkVersion 26
This one is another very good link that tells more about the "Google Play's target API level requirement", outlining all the suggestions to update your app
Finally, if you can't manage to deploy the app with a single apk this link provides you directions to "Create multiple APKs for different API levels". Please note that in the same link they do NOT recommend this solution, unless strictly necessary
It may seem at the outset as though multiple APK support is the best solution, but this often isn’t the case

Difference between API Level and SDK Version [duplicate]

I'm new to Android developing, and I would like to know what is the connection or difference between the version and the API level. What is each one referring to? And what does it mean when I decide to develop some app for API 14 or for android version 4.0?
Or is one a subset of the other? I simply didn't get the difference, and why are there two counters?
Thanks

Well, API is for development, so the changes in new API version are more "inside". But new version of Android usually adds more features for users, that are "visible".
Check this page http://developer.android.com/guide/appendix/api-levels.html, there is a table that shows relations between versions and API levels.

Multiple versions of Android can have the same API level but the API as an integer allows developers to more easily target devices. The chart below will give you an idea of their relationship but only the documentation contains exhaustive listings of the API levels and how they differ from each other.
Source: developer.android.com.
Because this data is gathered from the new Google Play Store app, which supports Android 2.2 and above, devices running older versions are not included. However, in August, 2013, versions older than Android 2.2 accounted for about 1% of devices that checked in to Google servers (not those that actually visited Google Play Store).

In addition to the answers provided, there is a detailed explanation of the Android Platform usage on Wikipedia (permalink).
This table will give you a highlight of Android API vs Version.

API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
You can have a new Android version with the same API release as the previous version.
Check out https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

A device running Android with version X will usually support applications written for API X and below.
This means if you want your app to support API 8, devices ver 8 will be able to run it, but also devices of ver 9, 10, 11, etc.
Here is the table which explains the ties between the numbers:
http://developer.android.com/guide/appendix/api-levels.html

In a short note:
Main difference between them is that API level for android application development framework API on the other hand android version is maintained to mention new features to user level.
In details:
API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
The Android platform provides a framework API that applications can use to interact with the underlying Android system. The framework API consists of:
A core set of packages and classes
A set of XML elements and attributes for declaring a manifest file
A set of XML elements and attributes for declaring and accessing resources
A set of Intents
A set of permissions that applications can request, as well as permission enforcements
included in the system
For more details you can visit this link:
https://developer.android.com/guide/topics/manifest/uses-sdk-element#ApiLevels

API = a set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other service.
Android = Android is a mobile operating system developed by Google.
So if we develop new API with new features they can be not supported in old android operation system, so we take old operation system , ++ version add support for new API and there we go (:
on the other hand if we have new operation system with new features we want to upgrade old API to support it, so we ++ version of the API.
Sound weird yeah ?

In simple words:
Android Version : Android is basically a mobile operating system developed by a consortium of developers known as the Open Handset Alliance and commercially sponsored by Google and they keep on updating Android by adding new features. So every new version of android have a version number known as Android version
API Level : API Level allow us to specify an app's/application's compatibility with one or more versions of Android, by means of an integer. Each versions of Android is associated with an API Level. So on a device the API Level expressed by an app/application is compared to the API Level associated with the version of the Android installed on the device.

In libGDX, can I target lower API level, than the framework requires?

I've downloaded the latest version of libGDX framework, which is meant for API level 20. Now, I'd like to target API level 19, since it's market share is HUGE, but the framework's developers "strongly discourage" using older versions. I could create the project using API level 20 SDK, then change the SDK when I import it to Android Studio, but I have no idea how it'll work out. Is it going to work, or I must use an older version to reach API level 20? (Maybe alternatives?)
The documentation wasn't too helpful, and I haven't seen anyone else having a problem like this, so I might have missed something.

Typically, you always want to target the most recent API version available, and set your minSdkVersion as low as you are willing to put the effort into supporting.
However, LibGDX is only officially tested up to level 20, so this is the safe target to use. You only need to go higher than 20 if there are some new API features you want to use. If you do that, make sure you test on a device with that API or later, since LibGDX hasn't officially started supporting it.
If you target 20, it will still work fine on later versions.
When Android gets API or behavior changes that have the potential to break old apps, the change only takes effect on apps that target the new API or higher. So all the old apps sitting in the store that haven't been updated will not be affected by the new API, because they don't target the new API.
I release LibGDX apps that target 20 and go to min version 9. These apps are installable and run fine on any device running Gingerbread or higher. I always compile with the latest SDK because I don't want to bother with keeping multiple SDK versions installed.

Problems with intention of using Android API 10

I'm about to build a new app. I'm just making an alarm and I'm aiming to help old people mainly (I assume they don't follow technology as geeks and they can use old phones like 5-6 years old) and max user count not shiny new features. So I can ignore API 8's 0.1% according to Android Dev but I don't want to ignore API 10-15's ~5%.
So I decided to use API 10 as min SDK level. While downloading API 10 inside Android Studio I encountered with Obsolete warning as shown in the image:
Okay maybe it's shown here wrong and better to do this directly from Android SDK Manager. It was same and I had an extra warning for SDK platform is not compatible with Windows:
If I remember right it was not obsolete in late of 2015. Google confused me with API levels since they are refusing to be backwards compatible. Anyway here is my pile of questions inside my head:
Does this mean Google doesn't care that ~5% (API 10-15 users and developers) anymore?
What does obsolete mean? Just not supported by Google anymore?
Is it a bad idea to use this API for new projects? What are the problems I can face if I use it now and future?
If I choose a newer API like level 18+, what I'm gonna do after 5 years until API become obsolete? If I won't add any new functionality except basic things and fixes, do I have to upgrade API that time?

It says the "Google APIs" is obsolete, not the platform.
Yes, it is not supported anymore. (Once again, not the platform)
Yes, do not use anything that is deprecated or obsolete.
Most likely you Android application will still work but it is important that you update is periodically in order to keep/retain and grow your users.

Will 2.3 android app run on 2.2 if it doesnt use any extra APIs introduced in 2.3?

I am trying to decide what target API should I choose to build my next android app. I know that Gingerbread was a major upgrade over Froyo and thus I want to use API 10(2.3.3). Also the report from Google tells me that Gingerbread 2.3.3 now has 61.5% of market share(http://developer.android.com/resources/dashboard/platform-versions.html).
The thing is at this point of my project I am not very sure if the LocationManager and other API enchancement in Gingerbread will if of use, though my app will definitely use them. If I use 2.2 for development then I can target a greater audience.
My question is, will it be possible for 2.2(Froyo) users to install and run my 2.3.3(gingerbread) app if I dont use any new API's introduced in 2.3 SDK?
Edit : If the answer is no, what would you guys suggest me to do, being it March 2012 now and the pace with which updates are coming? Should developers start with minimum 2.3.3 now, seeing the bugfixes and enhancements been introduced in it, not to mention the top market shareholder.

You could target 10 as API level, but define a minSdkVersion of 8 or so in your manifest. This will enable users of Froyo devices to install your app. But you have to ensure, that you don't use any API calls which are exclusive to API level 10. If you need to use functions introduced in API level 10 you should use them via reflection and either reimplement the missing functionality for pre API level 10 or notify the user of the missing functionaltiy.

If you target your application at API 10, 2.2 users won't be able to install it, even if you don't use any new API methods.
If you keep your application at Android 2.2, 2.3 users will still be able to install and use it. See the documentation for more.