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.

Using maxSdkVersion for light version of an app

I'm facing [LinearAlloc exceeded capacity][1] error when I try to install our app on devices running Gingerbread. So we decided to break our app in two versions: a light one with just some of our features (targeting API 8+) and another one one with our full features (targeting minSdkVersion=11).
My question is: should I set the light version with maxSdkVersion=10 in this case? The problem is that the developer guide highly recommends to avoid using this property. But I also would like the user to see only the best version of our app for his device.
Our project is really complex and the performance on old devices is becoming bad.
I've found some workarounds for this error but all of them uses Ant, and we've already moved to Gradle. And we still have a considerable number of Gingerbread users, we must consider them.
Is this approach ok?

The downside to adding the maxSdkVersion is that should the device get upgraded in the future your app would be removed in the process.
You have to wonder if someone would bother upgrading a 2-3 year old device though or if there is even an update available.
However, to cover all scenarios you could simply add a check in the "light" version that notifies the user that they can install the full app on a device with SDK >= 11. You could also link to it directly in Google Play.

You may try bringing multiple APK support to your app.
http://developer.android.com/google/play/publishing/multiple-apks.html#HowItWorks
The answer to your question
Should I set the light version with maxSdkVersion=10 in this case?
is here:
You should avoid using android:maxSdkVersion in general, because as
long as you've properly developed your application with public APIs,
it is always compatible with future versions of Android. If you want
to publish a different APK for higher API levels, you still do not
need to specify the maximum version, because if the
android:minSdkVersion is "4" in one APK and "8" in another, devices
that support API level 8 or higher will always receive the second APK
(because it's version code is higher, as per the previous note).
So differentiating your APKs in their manifests by only specifying different android:minSdkVersion values should be enough.

Android: How do you keep compatibility between specific version to latest android version

As a newbie I am not sure how do I make sure my app works between certain android version range. According to latest statistics, it seems that 2.3.3 (gingerbread) is still heavily used out there (other than ICS and JB). But now that Kitkat has made its way, many apps are updated to support that as well while still keeping compatibility with older versions of android.
So essentially what are general guidelines to support latest version of android as well as specified minimum old version. For example, how do I make sure my app works starting from 2.3.3 (gingerbread) to latest 4.4 kitkat ?
Also can emulators be used to make sure app works in specified range?
P.S: I know that can be specified via app manifest file but that's not my question I am just looking for how to actually make app compatible between the two versions.
Thanks for your suggestions and helpful ideas :)

You have different approaches to reach that goal.
First thing:
Despite the min sdk you want to support you should always use the latest sdk to build your app.
At this point, choose the min sdk you want to support and declare it inside the manifest.
If you are using eclipse with lint enabled it will be very easy at this point to spot if you are using unsupported api for that platform level.
If you want to use a new api and make it only available on newer devices you have basically two approaches:
use reflection (discouraged)
use #TargetApi annotation on the methods that use new api and call
those methods only on devices on which those api are available
if(Integer.valueOf(android.os.Build.VERSION.SDK)>whatlevelyouwant){
callMethodWithNewAPI();
}

You can find a lot of information on Google's 'Support Different Versions' Site: http://developer.android.com/training/basics/supporting-devices/platforms.html
Generally it says that you should support 90% of the devices out there (which means you can leave out Android 2.2, but should start with 2.3).
However, some new apps don't start with 2.3 but start with 4.0. This makes life much easier in words of testing.

In ADT you can use the ADV to generate differents emulators, one for each Android version you want to support and test.
It´s not as good as a real device but a useful starting point

You can define MinSdk and maxSdk in your manifest file.. This will define which Android Versions will be supported by your application.
android:minSdkVersion
An integer designating the minimum API Level required for the application to run.
android:maxSdkVersion
An integer designating the maximum API Level on which the application is designed to run.
So if you want your app to be compatible with 2.3 to the latest version you can define in your manifest file :
<uses-sdk
android:minSdkVersion="8" />
If you don't specify maxSdkVersion, it will take the latest released android version. So this line impllies your application is compatible with all devices having android 2.3 or above ..

Android Min SDK Version and Max SDK Version setting

I have an app which I want to install on ICS only . So i have set the min and max sdk versions as below.
<uses-sdk android:minSdkVersion="14" android:maxSdkVersion="15" />
Ideally this should work. But some how it is able to install on Jellybean version also.
ICS(API 14-15)
JellBean (API 16-18)
What am I Missing here? Please help

According to the documentation:
Future versions of Android (beyond Android 2.0.1) will no longer check
or enforce the maxSdkVersion attribute during installation or
re-validation. Google Play will continue to use the attribute as a
filter, however, when presenting users with applications available for
download.
The behaviour seen is expected. However, if you publish to Google Play, the application will be filtered.
Unless you have some feature that absolutely requires only older APIs (airplane mode comes to mind), then such a limitation does not serve much purpose.
If you're concerned about non Google Play sources or users sideloading the app, you can always do a runtime check for the Android version and either restrict features or close the app.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLYBEAN){
//do something about the Android version being too new
}
Keep in mind that if you want your app to reach the largest userbase, you will have to address the issues caused by the new Android versions at some point.

Per the maxSdkVersion documentation:
Future versions of Android (beyond Android 2.0.1) will no longer check or enforce the maxSdkVersion attribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.
Filtering will still work from Google Play, but you can sideload the app onto any device with a higher SDK version than the minimum.