I have an About box in my App that displays information about the App, the phone and the data it uses. It's very useful when a user has a problem. I can get the phone's SDK version using "android.os.Build.VERSION.SDK_INT". However, I haven't found a way to get the value of "CompileSdkversion" which indicates the SDK version the App was compiled with. This is the value that is set in the build.gradle file.
While the Android OS version varies by user, the compileSdkVersion does not. For version X.Y.Z of your app, the compileSdkVersion is whatever you said it was when you compiled that app version. So long as your about box contains the app version, you know what compileSdkVersion that you used, if you keep track of that (e.g., check what it was in your version control system).
But, if you really want to have it be available to you at runtime, you have two options.
If your minSdkVersion is 31 or higher, you can use compileSdkVersion on ApplicationInfo. However, most likely, if you are reading this before the year 2026, your minSdkVersion is lower than that.
For older devices than Android 12, you could add a BuildConfig field for it, at least with newer versions of the Android Gradle Plugin:
android {
compileSdk 31
defaultConfig {
applicationId "com.commonsware.android.myapplication"
minSdk 23
targetSdk 31
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
buildConfigField "int", "COMPILE_SDK_VERSION", "$compileSdk"
}
// other stuff goes here
}
This takes your defined value for compileSdk and hoists it into BuildConfig.COMPILE_SDK_VERSION, so you can reference it at runtime. This was tested using a scrap Arctic Fox project, using Gradle 7.0.2 and 7.0.3 of the Android Gradle Plugin.
Here is the relationship between the three values:
minSdkVersion (lowest possible) <=
targetSdkVersion == compileSdkVersion (latest SDK)
CompileSdkVersion has nothing to do with what devices can and cannot run your app. Usually, you set this to be the latest version of the Android SDK.
And the targetSdkVersion should be fully tested and less or equal to compileSdkVersion.(It depends on your app)
If you are using the features of API level of 26 then you need to use compileSdkVersion 26, the lower version will give you an error.
Android supports backward compatibility
(i.e. an app compiled on 26 can also run on a phone having API level 26 or lower).
Considering your use-case, wouldn't a better approach be just to show the current app version? If you know the version, you could look up how/when it was created (via git tags, for example) and then find out the SDK version it was compiled with.
Related
everyone!
I'm new to android programming, so simple things sometimes become a problem.
I have my application. It should work on devices with Android 5 and higher.
The question is what is proper strategy of sdkVersion defining?
What I mean.
For example, I need to acheive permision to use bluetooth.
If my target sdkVersion is 7 and minimum sdkVersion is 5 I should ask permission in manifest file and then acheive it in runtime. Like this
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
...
}
But if my target sdkVersion is 5 even Build.VERSION_CODES.M cannot be resolved.
So the question is : what is proper approach to choose sdkVersion? Where can I read about it?
I read here https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#target
but I didn't get what is best practice. So please share your experience.
Read this article from Ian Lake: Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion
compileSdkVersion:
compileSdkVersion is your way to tell Gradle what version of the
Android SDK to compile your app with. Using the new Android SDK is a
requirement to use any of the new APIs added in that level.
minSdkVersion:
If compileSdkVersion sets the newest APIs available to you,
minSdkVersion is the lower bound for your app. The minSdkVersion is
one of the signals the Google Play Store uses to determine which of a
user’s devices an app can be installed on.
targetSdkVersion:
The most interesting of the three, however, is targetSdkVersion.
targetSdkVersion is the main way Android provides forward
compatibility by not applying behavior changes unless the
targetSdkVersion is updated. This allows you to use new APIs (as you
did update your compileSdkVersion right?) prior to working through the
behavior changes.
Ideally, the relationship would look more like this in the steady state:
minSdkVersion (lowest possible) <=
targetSdkVersion == compileSdkVersion (latest SDK)
I suppose you are using Android Studio and build.gradle. If not, I recommend you to get it. All of the following is relevant for Android Studio and gradle build system.
Your main mistake is that SDK version in build.gradle of app module is not the same as Android Version. Here is the list of Platform Codenames, Versions, API Levels. What you need for SDK version is number in API level column of first table.
This is how android section of build.gradle for app targeting Android 5.0 and newer should look like.
android {
compileSdkVersion 25
buildToolsVersion "25.0.3"
defaultConfig {
applicationId "net.eraga.myobjectives"
minSdkVersion 21
targetSdkVersion 25
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
Read more about targetSdkVersion, minSdkVersion and compileSdkVersion here.
In this case, your minSdkVersion should be 21 (android 5.0) and targetSdkVersion along with compileSdkVersionshould be 25 (android 7.1).
I'm developing an Android app on Android Studio and I'm calling a method from API level 19. My build.gradle looks like this:
android {
compileSdkVersion 24
buildToolsVersion '24.0.2'
productFlavors {
// Define separate dev and prod product flavors.
dev {
// dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
// to pre-dex each module and produce an APK that can be tested on
// Android Lollipop without time consuming dex merging processes.
minSdkVersion 21
}
prod {
// The actual minSdkVersion for the application.
minSdkVersion 16
}
}
defaultConfig {
applicationId "com.myapp"
minSdkVersion 16
multiDexEnabled true
targetSdkVersion 24
versionCode 1
versionName "1.0"
}
}
I have no lint.xml files in my project, so no lint checks are overriden.
The problem is that the lint check "Calling new methods on older versions." doesn't find the method call for API level 19. If I open the build variants panel and select prodDebug or prodRelease the method gets underlined in red, but the project builds well. How can I get Android Studio to effectively show the aforementioned method in the analyze result or to block me from correctly building the project?
Edit
I found a way to search for methods not complying with the minimum SDK. By going to the Gradle panel on the right and running the lint task, an HTML report is generated, which finally shows the API 19 call along with other calls. Why is this not implemented into Android Studio?
Since this still does not work in Android Studio per se, but rather in Gradle, I'm not closing the question yet.
Gradle won't tell you if you are using the methods that are not supported in you minSDK if your compiled SDK version is not the minimum one. read more about it
So simply the solution is use lint feature i.e inspectcode
right click , either on project/class then => analyze=>inspectCode
android studio is currently supporting vector assets. according to the literature I can
Create separate APKs for different API levels. When you don’t include
the corresponding raster images in the APK for Android 5.0 (API level
21) and higher, the APK can be much smaller in size. For more
information, see Multiple APK Support.
so I tried creating 2 APIs: -
the pre-lollipop version contains the generated pngs without the vector assets,
while the lollipop version contains only the vectors assets
In http://developer.android.com/google/play/publishing/multiple-apks.html
If an APK you've uploaded for API levels 4 and above (Android 1.6+) has a version code of 0400, then an APK for API levels 8 and above (Android 2.2+) must be 0401 or greater. In this case, the API level is the only supported filter used, so the version codes must increase in correlation with the API level support for each APK, so that users get an update when they receive a system update.
The following is my gradle build file.
compileSdkVersion 23
buildToolsVersion "23.0.2"
defaultConfig {
applicationId "twitch.angelandroidapps.matchit"
}
productFlavors {
lollipopConfig {
minSdkVersion 21
targetSdkVersion 23
versionCode 3
versionName "21.1.0"
}
preLollipopConfig {
minSdkVersion 10
maxSdkVersion 20
targetSdkVersion 17
versionCode 2
versionName "10.1.0"
}
}
:
//snipped the rest of the build config...
:
however, when I deploy the pre-lollipop version first, followed by the lollipop version, then the pre-lollipop version got archived (and vice-versa).
Any advice on how I can get both versions to be deployed in the play store?
I had it figured out.
When i first deploy the lollipops and pre-lollipops, they get auto-archived.
For some strange reason, I have to manually shift the pre-lollipop version back into production by clicking "Move to Prod" for it to work.
After that, the playstore will show a new "API LEVELS" column.
Also the literature about having a larger versionCode seems to be wrong. Pre-lollipop version needs to always be a lower VersionCode (probably because my API levels do not overlap?). Anyway, I can now deploy new pre-lollipop versions without getting the previous version archived.
In the end, I used the naming convention of
21xxxx for lollipop versions and
10xxxx for pre-lollipop versions
Hope it helps.
I am about to release my first app and targeted lollipop when writing it in the hope that the uptake would of been greater by the time I was done. As well all know, it is still awful.
In my build.gradle I have this line:
android {
signingConfigs {
}
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "com.xxx.xxxx.toolbox"
minSdkVersion 21
targetSdkVersion 21
versionCode 7
versionName "1.15"
}
If I change the min SDK version to 19, the app will try and install on a device running API level 19. It crashes, but does not give me any feedback as to why (I have obviously used some methods from higher APIs). Is there any way to quickly figure out which methods I have used that need to be changed?
thanks,
Matt
If you set minSdkVersion to some version and recompile your application, Lint should automatically mark all instances where you use higher API as errors. That is, unless you annotate it with #TargetApi.
Also, if your application crashes, check LogCat. There will be an exception describing what went wrong and where.
meet face to face with trouble that :
java.lang.UnsupportedOperationException: Robolectric does not support API level 1, sorry!
properties in my build gradle :
android {
compileSdkVersion 19
buildToolsVersion '19.0.1'
defaultConfig {
minSdkVersion 14
targetSdkVersion 19
versionCode 1
What it can be?
versionCode in your code example is 1, the exception says API level 1 is not supported...I have the impression that "versionCode" represents the API level. What happens if you increase the versionCode - Value?
am not sure about your environment or tool setup, just make sure that your jenkins build is configued to build using gradle/gradle based build tool (only they will parse build.gradle file and generate a Manifest with proper fields) or if u r using some other build tool update the AndroidManifest with appropriate api level values