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
Related
I can't lower the target sdk to 29 because it's the new requirement from google play(Target API level 30 (Android 11) or above)
Has anyone had the same issue?
No issue with target 29 and play-service 12
implementation 'com.google.android.gms:play-services-ads:12.0.1'
Play-services-ads version 12 is a bit old(released 3 years ago), it's possible that API-29 to 30 update deprecated & removed some stuff that makes version 12 work, you will probably need to update to a later version of ads(19-20 are the most recent ones as of this moment).
I suggest you if, you convert version low then some methods you 'll get deprecated.
So, When you upload an APK, it needs to meet Google Play’s target API level requirements. New apps and app updates must target Android 10 (API level 29) or higher; except for Wear OS apps, which must target API level 28 or higher.
As you update the target API level for your apps, consider adopting recent platform features to modernize your apps and delight your users.
Consider using CameraX, which is in Beta, to make the most of using the camera.
Use Jetpack components to help you follow best practices, free you from writing boilerplate code, and simplify complex tasks so that you can focus on the code you care about.
Use Kotlin to write better apps faster, and with less code.
Ensure you are following privacy requirements and best practices.
Add dark theme support to your apps.
Add gesture navigation support to your apps.
Migrate your app from Google Cloud Messaging (GCM) to the latest version of Firebase Cloud Messaging.
Take advantage of advanced window management.
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.
After going through the Android Documentation for Max SDK version i am unclear with effectiveness from 2.1 onward.
Two Statements from Docs :
1)
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.
2) WARNING:
note that in some cases, declaring the attribute can result in your application being
removed from users' devices after a system update to a higher API Level. Most devices on which your >application is likely to be installed will receive periodic system updates over
the air, so you should consider their effect on your application before setting this attribute.
Can some one make me clear the above two statements.
Reference : http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
After version Android 2.0.1, maxSdkVersion will not be used to check and re-validate apk after apk upgrade or system upgrade, however Google play still use this tag to do some filter and present to user according to their device system version. Here is a more detailed description.
The TARGET SDK version serves to acknowledge that the application was verified and tested by the developers for at most that API level.
Of course it can and should work with compatibility mode in new APIs, but it might not.
So it is always important to update to new API levels to assure that it is fully working in those new APIs.
EDIT: The max SDK serves for making the application only run at a maximum SDK and not devices with higher SDK level. It is not recommended because it takes out the possibility of users with higher SDK levels in which the app could run very well in their devices because they are fully backward compatible.
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.
I am new to Android, and working with a beginner-level test application. I want to complete it with tab-bar and actionbar. I managed to do tab-bar, but I have difficulties implementing action bar. I imported a demo project, but when I run it, a prompt appears, saying that my device is not compatible, which is what confuses me.
My question is, how to decide about the API levels, min and target SDK versions, compatibility devices, AVDs? I am confused. I need an article that clears all this confusion.
Any help will greatly be appreciated!
Check this document to know about API Levels of Android and to know about Minimum SDK Version and Target SDK Version, check this document.
First document states that:
API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
Second Document states that:
android:minSdkVersion
An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.
android:targetSdkVersion
An integer designating the API Level that the application targets. If not set, the default value equals that given to minSdkVersion.
This attribute informs the system that you have tested against the target version 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).
It depends on your requirements.
Tab-bar's are common so don't worry about the API level. Actionbars are added in Android 3.0+ (API 11). If you are ok with not to support Android 2.x then you can set your min sdk to level 11. If you want to support Android 2.x you need to implement an actionbar yourself. There is a library for that called ActionBarSherlock but it will take some more effort to make it compatible for Android 2.x.