I just discovered something weird about Android studio: it has some configuration options in the build.gradle file that override what is specified in the AndroidManifest.xml file.
For instance, I had the following lines in build.gradle:
android {
compileSdkVersion 18
buildToolsVersion "18.1.1"
defaultConfig {
minSdkVersion 10
targetSdkVersion 10
}
...
}
which was overriding the corresponding tag in AndroidManifest.xml:
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="8"/>
I don't really like to have the same settings spread in two different files, so I am wondering if I can safely remove it either from build.gradle or AndroidManifest.xml and where it makes more sense to keep it.
Gradle overrides the manifest values, and I prefer to update the build.gradle file rather than the manifest. Probably this is the right way using Gradle. Gradle supports product flavours which can be controlled via an IDE and those product flavors can change many things in our Manifest like package name, version code, version name, target SDK and many other. Then by one click in Android Studio you can change many properties and generate another apk.
You can leave the manifest as it is and do all configuration in build.gradle. You can safely remove
<uses-sdk></uses-sdk>
from manifest as well as version codes.
From the Android docs:
Note: If your app defines the app version directly in the element, the version values in the Gradle build file will override the settings in the manifest. Additionally, defining these settings in the Gradle build files allows you to specify different values for different versions of your app. For greater flexibility and to avoid potential overwriting when the manifest is merged, you should remove these attributes from the element and define your version settings in the Gradle build files instead.
https://developer.android.com/studio/publish/versioning.html#appversioning
Related
I have developed an Android project with Android Studio and I want to install it on a device. The problem is that I want to install 2 versions of it. The only difference between them will only be the name.
I hope that you could help me.
As well as the name you will also have to change the applicationId.
The applicationId is what Android uses to detect if an app is unique.
If you are using gradle it will be within your modules build.gradle file like this
...
android {
...
defaultConfig {
applicationId "com.mycompany.appname"
...
}
You may also have to change provider authorities in your AndroidManifest.xml if you use them.
Gradle gives the ability to set some manifest attributes pretty simply like:
targetSdkVersion and minSdkVersion
Is there any way to add the android:testOnly application attribute with gradle without touching the manifest by hand
https://developer.android.com/guide/topics/manifest/application-element.html#testOnly
You can create a custom resource value with Gradle. E.g. in your app module's build.gradle under android -> defaultConfig
resValue("bool", "test_only", "true")
And then in your AndroidManifest.xml
android:testOnly="#bool/test_only"
E.g. you can set this to different values for different flavors
We're dropping support for Android 2.3 (API level 9) devices because most of our users have a newer Android version on their phones. I've updated the minimum SDK version to api level 14.
android {
compileSdkVersion 23
buildToolsVersion "23.0.2"
defaultConfig {
minSdkVersion 14
targetSdkVersion 23
}
}
However I'm still able to install the app on Android 2.3 devices manually (not by store). Is this expected behavior or am I doing something wrong? I couldn't find the answer somewhere else.
Another strange issue is that Lint doesn't detect the correct api level.
listView.setFastScrollAlwaysVisible(true);
This results in the warning: Call requires api level 11 (current min is 9).
However my current minimum is now 14. So this indicates to me that i did something wrong. I tried cleaning and rebuilding the project, restarting Android Studio. It all didn't work.
Can anyone help me out?
Edit
Based on Sufians comment I started fiddling around with my gradle files and I came to the following solution. However some questions still remain.
My project structure looks like this:
android.gradle (top-level build file which contains SDK versions)
main module (contains base code for other modules)
build.gradle (apply from: '../android.gradle')
sub module A (module specific changes)
build.gradle (has dependency on main module)
sub module B (module specific changes)
build.gradle (has dependency on main module)
I have a top-level build file android.gradle which contains the SDK versions. My modules then include the build file by apply from: '../android.gradle'. If I put the minSdkVersion directly in de main module the warnings disappear. Is that the way it should be? or do I need to set an minSdkVersion for every submodule? Or is there another way so that the SDK versions can stay within the android.gradle file?
Ok... I finally realized that there is nothing wrong in my project structure. The only thing I needed to do was press the little 'Sync Project with Gradle Files' button. After that all errors disappear.
Also I concluded that it's possible to install unsupported apps manually.
However the Google Play Store should prevent users from installing or updating the app.
i have personally never developed anything for android but when installing apps the device has never complained when installing an .apk that wasn't supported by the OS version.
even when the store said it wasn't supported i'm always able to install it as a .apk so i think it can't really be blocked.
Yes, you can install the app manually on your device as long the minimum API level specified in your manifest is less than your device's API level.
When you upload your app to the store, the store will not show your app to users with devices having Android version less than the min API level specified (API level 9 in your case).
As for the Lint warnings, make sure that the minimum/maximum SDK versions in your manifest file match those specified in the build.gradle file.
and you can also make sure that new APIs are not executed on older API levels by checking the OS version in the code.
http://developer.android.com/reference/android/os/Build.VERSION.html
If I put the minSdkVersion directly in de main module the warnings
disappear. Is that the way it should be?
Your main module's minimum and target SDKs (i.e inside the build.gradle of the module) will be that of your application.
The project's build.gradle should not contain any of this information.
or do I need to set an
minSdkVersion for every submodule? Or is there another way so that the
SDK versions can stay within the android.gradle file?
Each module defines its own minimum SDK. If you're using a third party module/library, you better not change it, unless you know what you're doing.
Based on this Google document I'm expecting Gradle to update my manifest.xml file with a version number, notably this quoted section:
The defaultConfig element configures core settings and entries in the manifest file (AndroidManifest.xml) dynamically from the build system. The values in defaultConfig override those in the manifest file.
However when I change the version code or version name of my Gradle file, the values arent' changed in my manifest.
Is this normal behavior?
Which values, between the manifest and the gradle build, are stting version codes and names?
How can I make the connection between the manifest versions and the gradle build more visible?
Even I am facing the similar issue. It is the default behaviour of gradle system I guess. You need to update both AndroidManifest.xml and build.gradle seperately if there is any changes in sdk versions, version code, version name,etc. I am looking forward that these kinda issues must be fixed in upcoming releases.
I have versionCode(1.0.3) and versionName(8) in my build.gradle only and it had worked correctly for me in past.
Now I updated the versionCode to 1.0.4 and versionName to 1 but it kept on giving me error on Google play. I even tried adding the new versionCode and versionName to AndroidManifest.xml but it did not help. Only thing that worked was updating the versionName to a higher number (9). Something seems broken in the Google Play upload apk and verify mechanism. Hopefully my answer would save someone else's 1 hour for solving this silly bug.
I just discovered something weird about Android studio: it has some configuration options in the build.gradle file that override what is specified in the AndroidManifest.xml file.
For instance, I had the following lines in build.gradle:
android {
compileSdkVersion 18
buildToolsVersion "18.1.1"
defaultConfig {
minSdkVersion 10
targetSdkVersion 10
}
...
}
which was overriding the corresponding tag in AndroidManifest.xml:
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="8"/>
I don't really like to have the same settings spread in two different files, so I am wondering if I can safely remove it either from build.gradle or AndroidManifest.xml and where it makes more sense to keep it.
Gradle overrides the manifest values, and I prefer to update the build.gradle file rather than the manifest. Probably this is the right way using Gradle. Gradle supports product flavours which can be controlled via an IDE and those product flavors can change many things in our Manifest like package name, version code, version name, target SDK and many other. Then by one click in Android Studio you can change many properties and generate another apk.
You can leave the manifest as it is and do all configuration in build.gradle. You can safely remove
<uses-sdk></uses-sdk>
from manifest as well as version codes.
From the Android docs:
Note: If your app defines the app version directly in the element, the version values in the Gradle build file will override the settings in the manifest. Additionally, defining these settings in the Gradle build files allows you to specify different values for different versions of your app. For greater flexibility and to avoid potential overwriting when the manifest is merged, you should remove these attributes from the element and define your version settings in the Gradle build files instead.
https://developer.android.com/studio/publish/versioning.html#appversioning